nekolik dotazu k odstavci "Tomáš Hála SMTP...."
* ... v případě poštovního řetězce se už uživatel nemá možnost se nic takového dozvědě
na gmailu kdysi zavedli/chteli zavest "not encrypted warnings" (https://www.theregister.co.uk/2015/11/16/google_wants_to_add_not_encrypted_warnings_to_gmail/) - jak je na to gmail nyni, hlasi ty warningy? (nemam gmail, tak nevim)
* Pro kontrolu TLSA stačí jen DNSSEC validující resolver
opravud je potreba pro kontrolu TLSA zaznamu DNSSEC, nejde to i bez nej (pominu-li oslabeni bezpecnosti)? zbezne jsem kouknul na par RFC (7671, 6698) k TLSA a o vyzadujicim DNSSECu jsem se nedocetl (mozna jsem prehledl)
Dix
No, v RFC6698 se v kapitole 1.3 dočtete třeba tohle:
This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be protected by DNSSEC.
Odvolávek na DNSSEC je tam víc, stejně jako v RFC7671.
Je to tak. Pokud zveřejníte TLSA záznam, tak bez jeho ověření skrze DNSSEC bude ignorován. Musí to tak být. Jinak by ověření certifikátu bylo podvrhnutelné stejnými způsoby, jakými můžete podvrhnout např. samotné MX záznamy a tedy by to nedávalo prakticky žádnou přidanou hodnotu oproti stavu bez TLSA.
A proc neignorujes to IPcko? Jakejkoli zaznam v DNS bez DNSEC je o milion radu duveryhodnejsi informace, nez jakekoli libovolnou CA podepsanej cert. Uz minimalne proto, ze zaznam v DNS si muze kdokoli kdykoli mnoha ruznymi zpusoby overit, ale to, ze nejaka CA podepise milion certifikatu pro domeny, u kterych jejich spravci/drzitele vubec netusej ze by nejakej cert chteli, nemas absolutne zadnou moznost zjistit.
Nedava, ale tenhle problem neresi ani RFC 8461 alias MTA-STS (ktere je chte-nechte na DNS zavisle zrovnatak... jako vsecko) - ktery paradoxne protlacuji nejvic prave ti, kterym se do zavadeni DNSSEC moc nechce.
Nejsem obhájce MTA-STS, ale není pravda, že ten problém neřeší. Pokud mi někdo komunikaci naruší, tak všichni, kdo mají z dřívější komunikace záznam v cache, jsou chránění a email u nich zůstane ve frontě, dokud nebude cesta na MX zase nenarušená. Stejně jako s HSTS. Reálný efekt to tedy má (resp. bude mít, až to někdo implementuje). Jiná otázka je, jak je takové řešení vhodné z pohledu komplexity a systematičnosti. Bez ohledu na MTA-STS je implementace DNSSEC dobrý nápad i z mnoha jiných důvodů. DANE je jen jeden z nich.
To ale predpoklada, ze uz jsem s dotycnym cilem nekdy komunikoval (abych mel neco v cache). Pokud jde o prvni kontakt, pak uz tu i ta cache muze byt podvrzena a o naruseni komunikace se clovek tim padem nedozvi. Ve vysledku to vyrabi falesny pocit bezpeci. Jenze uz v navrhu jsou vratka lehce pootevrena a v nekterych situacich utoku nezabrani. To mi prijde na standard tvoreny v 21.stoleti jako dost velky fail.
MTA-STS zapojuje nesmyslne dalsi protokol (krome DNS, bez ktereho se beztak neobejdu jeste HTTPS). Duvody RFC uvadi a jednim ze stezejnich je prave nevole k implementaci DNSSECu a vymysleni workaroundu, kdy se clovek skrabe levou rukou za pravym uchem...
Srovnavani s HSTS ma jednu vadu - jako "uzivatel" muzu sve zarizeni primet k tomu, aby komunikovalo primarne zabezpecenym kanalem (tim, ze mu reknu, ze chci pouzit https). Jenze to SMTP pro MTAtoMTA komunikaci nemuzu, ani kdyz se na hlavu postavim - zadny standard mi to fakticky ani neumoznuje. Pouze muzu doufat, ze mi to STARTTLS nikdo po ceste na tcp/25 "nesezere".
Danny, po technicke strance mas samozrejme pravdu a opakuji, ze nejsem obhajce MTA-STS, ale porad nesouhlasim s tim, ze to ten problem neresi. Resi ho. A pokud je o problematiku prvniho kontaktu, je tu stejne reseni jako u HSTS, tedy MTA-STS preload list ;-)
https://starttls-everywhere.org/policy-list/
A tady vysvetleni k motivaci:
https://www.eff.org/deeplinks/2018/06/announcing-starttls-everywhere-securing-hop-hop-email-delivery
Jsou taci, co proste DNSSEC zavadet nechteji a je pravda, ze za poslednich nekolik let se jeho adopce moc nezvysila. Ani me to netesi, ale jsou to fakta.