Rekord DKIM

Rekord DKIM to parametr monitoringu stron internetowych, który sprawdza, czy w DNS opublikowany jest klucz publiczny DKIM, czyli rekord TXT pod nazwą selektor._domainkey.domena. Wynikiem jest klucz znaleziony albo brak rozstrzygnięcia. DKIM (DomainKeys Identified Mail) pozwala domenie przyjąć odpowiedzialność za wiadomość przez podpis kryptograficzny, który odbiorca weryfikuje kluczem pobranym z DNS ^[1].

Jak działa

Serwer nadawcy podpisuje treść i wybrane pola nagłówka kluczem prywatnym i dodaje do wiadomości pole DKIM-Signature ^[1]. Pole zawiera m.in. algorytm (a=), skrót treści (bh=), podpis (b=), domenę podpisującą (d=), selektor (s=) i listę podpisanych pól (h=) ^[1]. Selektor dzieli przestrzeń kluczy domeny, więc jedna domena może mieć wiele kluczy. Dla d=example.com i s=foo.bar odbiorca pyta DNS o rekord foo.bar._domainkey.example.com ^[1].

RYS. 1.1Podpis i pobranie klucza

Gdy rekordu klucza nie ma, weryfikator musi zwrócić PERMFAIL, a gdy DNS nie odpowiada, może zwrócić TEMPFAIL i spróbować później ^[1]. Pusta wartość p= oznacza klucz unieważniony ^[1]. Flaga t=y w rekordzie oznacza, że domena testuje DKIM, a weryfikator nie może traktować jej wiadomości inaczej niż niepodpisanych, nawet gdy podpis się nie zgadza ^[1].

RYS. 1.2Od nagłówka do wyniku

Z zewnątrz, bez dostępu do poczty, selektor jest nieznany: zapisuje go tylko pole s= podpisu w wiadomości ^[1]. RFC 6376 nie narzuca nazw selektorów i zauważa, że część domen nadaje je tak, by osoby z zewnątrz nie mogły zbierać z nich danych, np. jako losowe wartości ^[1]. Da się sprawdzić selektory typowe dla dostawców: Google Workspace domyślnie używa prefiksu google ^[7], a Microsoft 365 nazw selector1._domainkey i selector2._domainkey publikowanych jako CNAME ^[8]. Trafienie potwierdza obecność klucza. Brak trafienia nie dowodzi braku DKIM, bo domena może podpisywać pod innym selektorem. Pewny odczyt daje dopiero nagłówek odebranej wiadomości.

Standardy i specyfikacje

• RFC 6376 definiuje podpis, selektory, rekord _domainkey i kroki weryfikacji ^[1]. Relację podpisu z domeną nadawcy widoczną w polu From opisuje artykuł DMARC.
• RFC 8301 zakazuje algorytmu rsa-sha1 przy podpisywaniu i weryfikacji. Podpisujący muszą używać kluczy RSA o długości co najmniej 1024 bitów, a powinni 2048 bitów; podpisów z kluczami krótszymi niż 1024 bity weryfikator nie może uznać za ważne ^[3].
• RFC 8463 dodaje algorytm ed25519-sha256 i typ klucza k=ed25519. Klucz publiczny w base64 ma 44 oktety, więc zwykle mieści się w jednym 255-bajtowym ciągu TXT ^[2]. Weryfikatorzy muszą obsługiwać ten algorytm, a podpisujący mogą dodać kilka podpisów starym i nowym algorytmem pod różnymi selektorami ^[2].
• Google od 1 lutego 2024 r. wymaga od wszystkich nadawców do kont Gmail SPF lub DKIM, a od wysyłających ponad 5000 wiadomości dziennie SPF i DKIM oraz DMARC. Klucz DKIM musi mieć co najmniej 1024 bity, zalecane jest 2048 ^[5]. Yahoo wymaga od nadawców masowych SPF i DKIM, a w zaleceniach podaje podpisywanie każdej wiadomości kluczem co najmniej 1024-bitowym ^[6].

Zagrożenia i skutki

Brak podpisu. RFC 6376 zaleca, by odbiorca nie odrzucał wiadomości wyłącznie z powodu braku podpisu albo podpisu, którego nie da się zweryfikować ^[1]. U dużych dostawców brak uwierzytelnienia może jednak skończyć się oznaczeniem jako spam albo odrzuceniem z błędem 5.7.26 ^[5].

Krótki klucz. Według M3AAWG złamanie 512-bitowego klucza DKIM zajęło w 2012 r. około 72 godzin i kosztowało około 75 dolarów w chmurze, a klucze 1024-bitowe są na granicy możliwości ataku dla komputerów ogólnego przeznaczenia ^[4]. Publikacja kluczy RSA od 1024 bitów wzwyż wymaga z kolei, by serwery DNS obsługiwały długie rekordy TXT, czyli EDNS0 albo zapytania przez TCP ^[4].

Brak rotacji. M3AAWG zaleca wymianę kluczy co najmniej co sześć miesięcy, bo ogranicza to czas, przez który wykradziony lub złamany klucz nadaje się do użycia ^[4]. RFC 6376 opisuje wymianę przez nowy selektor: oba klucze są publikowane jednocześnie, a stary znika po okresie przejściowym. Ponowne użycie selektora z nowym kluczem uniemożliwia odróżnienie wiadomości z nieaktualnym kluczem od sfałszowanej ^[1].

Powtórzenie wiadomości. Spamer może wysłać wiadomość przez serwer, który ją podpisze, a potem rozesłać ją do wielu odbiorców, korzystając z reputacji domeny podpisującej ^[1].

Przykłady

Odczyt	Znaczenie
TXT pod google._domainkey z niepustym p=	klucz opublikowany pod selektorem dostawcy [7]
CNAME selector1._domainkey do dostawcy	klucz utrzymywany przez Microsoft 365 [8]
rekord z pustym p=	klucz unieważniony [1]
rekord z k=ed25519	klucz Ed25519 [2]
brak rekordu pod typowymi selektorami	brak rozstrzygnięcia, selektor może być inny [1]
pole s= w nagłówku odebranej wiadomości	pewny selektor do sprawdzenia [1]