O technologii DKIM, která nabízí prostředky ke zvýšení důvěryhodnosti elektronických dopisů, jsme psali už dvakrát. Stručně připomeňme, že při použití DKIM poštovní servery přidávají do elektronického dopisu digitální podpisy, jimiž potvrzují, že jimi dopis v dané podobě skutečně prošel – viz DKIM – dopisy ověřeného původu. Později se objevila doplňková specifikace ADSP, která umožňuje organizaci prohlásit „My své dopisy podepisujeme.“ a případně i „Nepodepsané zahoďte.“ Podrobnosti najdete v článku DKIM v roce 2010 – chcete zkusit ADSP?
Od posledního článku uplynuly dva roky a DKIM během nich opět prodělalo určitý vývoj a přidalo nové možnosti. V první řadě je třeba zmínit, že v loňském roce vyšla v RFC 6376 aktualizovaná specifikace vlastního DKIM. Žádná velká revoluce se nekonala, šlo spíše o ladění detailů, opravy chyb a vysvětlování nejasných míst. Z věcných změn stojí za zmínku odstranění položky g= z DNS záznamu pro veřejný klíč, která reálně nebyla používána. Letos se pak objevily dva doplňky rozšiřující funkce, které DKIM nabízí. Podívejme se na ně podrobněji.
Delegace podepisování, čili ATPS
DKIM podpis může připojit každý poštovní server, jímž dopis během své cesty Internetem prochází. Je ale otázkou, jakou váhu má. ADSP rozdělilo podpisy do dvou kategorií – podpis z autorovy domény (tedy podpis od serveru z domény, která se shoduje s doménou v adrese odesilatele) a všechny ostatní.
Problém vznikne, pokud chcete dopisy podepisovat, ale neprovozujete vlastní poštovní server. Původní myšlenka byla taková, že provozovateli poštovního serveru, jehož prostřednictvím odesíláte dopisy ze své domény, předáte příslušný soukromý klíč a on jím bude vaši odchozí korespondenci podepisovat.
Authorized Third-Party Signatures (ATPS) definované v RFC 6541 nabízí elegantnější řešení. Místo chřestění s klíči vám umožňuje jednoduše sdělit „podpisy z domény XY jsou stejně dobré jako mé vlastní“. Abychom se nezbláznili z neurčitého označování domén, ilustrujeme ATPS na příkladu. Řekněme, že vlastník domény vslib.cz by rád, aby jeho poštu podepisovali na serveru pro tul.cz.
Věc pochopitelně vyžaduje spolupráci obou stran. Operátor poštovního serveru tul.cz musí být ochoten podepisovat poštu z vslib.cz. Podepisuje ji ovšem svým vlastním klíčem – v položce d= uvede vlastní doménu ( d=tul.cz) a příslušný veřejný klíč má v DNS záznamu ve své zóně. K podpisu ovšem přidá nově definované položky atps= a atpsh=. Hodnotou první je doména, jejímž jménem podepisuje ( atps=vslib.cz). Druhá identifikuje hashovací funkci a dostaneme se k ní za chvíli, zatím předpokládejme atpsh=none. Poštovní server podepisující za tul.cz tedy do dopisů s odesilateli z domény vslib.cz přidá hlavičku
DKIM-Signature: ...d=tul.cz; atps=vslib.cz; atpsh=none;...
Aby bylo dílo dokonáno, musí ještě strana, která se při podpisu nechává zastupovat, potvrdit tuto skutečnost ve své DNS zóně prostřednictvím tak zvaného ATPS záznamu. Do vslib.cz by proto byl vložen záznam typu TXT, jehož jméno vznikne spojením domény pověřené podepisováním (uvedené v d= u podpisu), konstanty _atps a vlastní domény. V našem případě by záznam byl uložen pod jménem tul.cz._atps.vslib.cz.
Textový obsah záznamu je tvořen v DKIM obvyklými dvojicemi jméno= hodnota oddělenými středníky. Povinná je položka v=ATPS1 a doporučená položka d= obsahující podepisující doménu. V našem případě by záznam vypadal takto:
tul.cz._atps.vslib.cz. 300 IN TXT "v=ATPS1\; d=tul.cz"
Pokud by jméno domény pověřené podepisování bylo příliš dlouhé, lze je nahradit hashem. K tomu právě slouží položka atpsh= v podpisu, která určuje hashovací funkci. Při hledání ATPS záznamu se pak na začátku nepoužije doménové jméno z d=, ale jeho hash.
Program, který ověřuje podpis, provede standardní ověření podle DKIM s veřejným klíčem v doméně podle d=. Následně podle údajů z d= a atps= poptá v DNS záznam potvrzující ATPS pověření. Pokud se podaří úspěšně ověřit podpis i pověření podepisujícího, je třeba podpis brát, jako by se jednalo o podpis z autorovy domény. A to i pro posuzování podle ADSP.
Autor sám se netají názorem, že podepisování třetí stranou je problematické a má své nedostatky. Proto je RFC 6541 deklarováno jako experimentální. Zároveň žádá o zkušenosti s nasazením ATPS, jeho chováním a zátěží jednotlivých komponent. Pokud by odezva byla jednoznačně kladná, hodlá usilovat o jeho standardizaci.
Automatické hlášení chyb
Specifikace DKIM a doprovodných mechanismů zatím neřešily signalizaci chyb. Pokud se nepodařilo ověřit podpis, nebo dopis neodpovídal politice deklarované v ADSP, s dopisem se nějak naložilo a případně se problém zapsal do protokolu o činnosti ověřujícího programu. Podepisující strana nebyla nijak informována.
RFC 6651 se to snaží změnit. Nejedná se o izolovanou aktivitu, ale o součást skupiny specifikací směřujících k automatickému ohlašování různých neplech, kterou vyvíjí pracovní skupina Marf.
Konkrétně v případě DKIM umožňuje podepisujícímu, aby si řídil, zda a jak chce být o případných problémech informován. Technicky je vše realizováno opět kombinací nových položek v DKIM podpisu a příslušných DNS záznamů. Zásah do podpisu je v tomto případě zcela minimální, podepisující server jednoduše přidá do hlavičky DKIM-Siganture položku r=y („r“ podle reports).
Všechno ostatní je uloženo v DNS. Konkrétně v textovém záznamu, jehož jméno vznikne spojením konstanty _report._domainkey a domény uvedené v položce d= u podpisu. Obsahuje-li tedy dopis
DKIM-Signature: ... d=tul.cz; r=y;...
bude se hledat záznam typu TXT se jménem _report._domainkey.tul.cz. Obsahuje opět dvojice jméno= hodnota, kde pro jméno jsou k dispozici tyto možnosti:
ra= |
poštovní adresa, na kterou se má poslat hlášení; obsahuje jen uživatelské jméno, za které se připojí zavináč a doména podle d= z podpisu |
rp= |
jaké procento případů se má hlásit; ověřující stroj vylosuje náhodné číslo od 0 do 99 a pokud je menší než hodnota v rp=, pošle zprávu |
rr= |
jaké typy událostí se mají hlásit; jedná se o jednopísmenné kódy oddělované dvojtečkami |
rs= |
řetězec, který má být vložen v protokolu SMTP do odpovědi na příkaz DATA pro daný dopis |
Jestliže dojde k problému s ověřením podpisu a doména v něm uvedená neobsahuje záznam _report._domainkey, chybová zpráva se neposílá. V opačném případě se postupuje podle instrukcí v záznamu.
RFC 6651 zavádí tato rozšíření i pro hodnotu ADSP záznamu, aby organizace mohla být informována o problémech způsobených porušením podpisové politiky. Zejména tato služba by mohla být cenná, protože problémy cestujících uživatelů používajících nestandardní poštovní servery jsou jedním z bolestivých míst DKIM & spol. Díky tomuto signalizačnímu mechanismu o nich správce může být informován a mít tak lepší podklady pro řešení.
Na rozdíl od experimentálního ATPS je podpora chybových hlášení pro DKIM na cestě k internetovému standardu.
