RFC 8463

RFC 8463 dotyczy alternatywnych algorytmów podpisu wykorzystywanych w standardzie DKIM.

RFC 8463 – czym jest i jaki problem porządkuje

RFC 8463 to dokument techniczny opisujący sposób wykorzystania alternatywnych algorytmów podpisu w mechanizmie DKIM, czyli DomainKeys Identified Mail. DKIM służy do kryptograficznego powiązania wiadomości e-mail z domeną nadawcy. W praktyce serwer wysyłający umieszcza w nagłówku wiadomości podpis, a serwer odbierający pobiera odpowiedni klucz publiczny z systemu DNS i sprawdza, czy podpis pasuje do treści oraz wybranych nagłówków. Jeżeli weryfikacja przebiega poprawnie, można uznać, że wiadomość nie została zmieniona po podpisaniu i została wysłana w imieniu domeny wskazanej w podpisie.

Przez długi czas podstawowym rozwiązaniem stosowanym przez DKIM był algorytm RSA. RFC 8463 opisuje alternatywę opartą na krzywych eliptycznych, przede wszystkim Ed25519. Celem takiego podejścia jest zapewnienie porównywalnego poziomu ochrony kryptograficznej przy użyciu krótszych kluczy i podpisów. Ma to znaczenie między innymi dla rozmiaru rekordów DNS, wielkości nagłówków pocztowych oraz sprawności operacji kryptograficznych. Dokument nie zastępuje całej specyfikacji DKIM, lecz rozszerza ją o dodatkowy wariant algorytmu.

Należy rozróżnić trzy elementy: sam standard DKIM, sposób publikacji klucza w DNS oraz algorytm używany do utworzenia i sprawdzenia podpisu. RFC 8463 dotyczy przede wszystkim tego trzeciego elementu, ale jego wdrożenie wpływa również na konfigurację DNS, oprogramowanie serwera pocztowego i zgodność z serwerami odbiorczymi.

RFC 8463 w kontekście DKIM, DNS i innych metod ochrony poczty

Podpis DKIM powstaje na podstawie określonego zestawu nagłówków oraz treści wiadomości. Przed podpisaniem treść jest normalizowana według wybranego trybu kanonikalizacji, a następnie obliczany jest skrót kryptograficzny. Podpis zawiera między innymi identyfikator domeny, selektor, listę podpisanych nagłówków, zastosowany algorytm oraz wartość podpisu. Odbiorca odczytuje te informacje, pobiera klucz publiczny z rekordu TXT w DNS i wykonuje weryfikację.

W przypadku tradycyjnego podpisu RSA rekord DNS zawiera klucz publiczny zakodowany w polu przeznaczonym dla tego algorytmu. Dla Ed25519 używa się innego oznaczenia typu klucza, a serwer odbierający musi rozumieć zarówno format rekordu, jak i sposób weryfikacji. Samo opublikowanie klucza nie gwarantuje więc skutecznego działania. Potrzebne jest wsparcie po stronie systemu wysyłającego oraz po stronie odbiorcy.

Porównanie RSA i Ed25519 nie powinno sprowadzać się do pytania, który algorytm jest zawsze korzystniejszy. RSA jest bardzo szeroko obsługiwany przez starsze i nowsze systemy pocztowe, dlatego pozostaje rozwiązaniem kompatybilnym w wielu środowiskach. Ed25519 może ograniczyć rozmiar klucza i podpisu, ale wymaga sprawdzenia, czy używane serwery, biblioteki oraz usługi pośredniczące potrafią go obsłużyć. W praktyce możliwe jest utrzymywanie kilku selektorów i stopniowe wprowadzanie nowego algorytmu, o ile polityka organizacji i używane oprogramowanie na to pozwalają.

DKIM nie działa w oderwaniu od pozostałych mechanizmów pocztowych. SPF sprawdza, czy serwer wysyłający znajduje się na liście uprawnionych systemów, natomiast DMARC pozwala określić sposób postępowania z wiadomościami, które nie przejdą kontroli SPF lub DKIM. DKIM chroni integralność wybranych elementów wiadomości, ale nie potwierdza samodzielnie, że każda informacja widoczna w polu nadawcy jest prawdziwa. Dlatego przy analizie dostarczalności należy brać pod uwagę zgodność domen, politykę DMARC, reputację adresu IP i zachowanie serwerów pośrednich.

RFC 8463 a typowe problemy z podpisem Ed25519

Jednym z częstszych problemów jest brak obsługi algorytmu po stronie serwera odbiorczego. Wiadomość może być prawidłowo podpisana, a mimo to odbiorca nie będzie w stanie zweryfikować podpisu. W takim przypadku w logach mogą pojawić się informacje o nieznanym typie klucza, niewspieranym algorytmie albo pominięciu podpisu. Nie musi to oznaczać błędu w samym rekordzie DNS, ponieważ przyczyna może znajdować się w wersji oprogramowania lub w konfiguracji odbiorcy.

Inną przyczyną niepowodzenia jest niezgodność między selektorem podanym w nagłówku DKIM a nazwą rekordu DNS. Klucz jest publikowany pod adresem zależnym od selektora i domeny podpisującej, dlatego nawet niewielka różnica w nazwie może uniemożliwić pobranie właściwego rekordu. Należy sprawdzić pisownię selektora, domenę, obecność rekordu TXT, podział długiej wartości na fragmenty oraz sposób łączenia tych fragmentów przez serwer DNS.

Weryfikacja może nie przejść również wtedy, gdy wiadomość została zmieniona po podpisaniu. Czasami modyfikację wykonuje filtr antyspamowy, bramka pocztowa, system archiwizujący albo program dopisujący stopkę. Znaczenie ma także sposób kanonikalizacji oraz zakres podpisanych nagłówków. Jeśli podpis obejmuje elementy, które są później zmieniane, odbiorca może otrzymać wynik negatywny mimo poprawnej konfiguracji początkowej.

Problemy pojawiają się także przy rotacji kluczy. Podczas zmiany selektora trzeba zachować ciągłość działania, ponieważ wiadomości już wysłane mogą być sprawdzane po pewnym czasie. Zbyt szybkie usunięcie starego rekordu DNS może spowodować błędy dla wiadomości znajdujących się jeszcze w kolejkach lub przetwarzanych przez serwery opóźniające dostarczenie. Bezpieczniej jest najpierw opublikować nowy klucz, rozpocząć podpisywanie nowym selektorem, a dopiero po odpowiednim okresie wycofać poprzedni rekord.

Warto pamiętać, że wygenerowanie krótkiego klucza Ed25519 nie rozwiązuje problemów związanych z przejęciem konta, błędną polityką DNS ani nieprawidłowym zarządzaniem dostępem do klucza prywatnego. Klucz prywatny powinien być chroniony przed odczytem przez nieuprawnione procesy, a jego użycie powinno być ograniczone do systemu, który rzeczywiście podpisuje wiadomości.

RFC 8463 – praktyczne wskazówki dotyczące wdrożenia i kontroli

Przed zmianą algorytmu należy ustalić, które systemy wysyłają pocztę w imieniu danej domeny. Dotyczy to nie tylko głównego serwera, lecz także formularzy internetowych, systemów powiadomień, platform transakcyjnych i narzędzi używanych przez pracowników. Każdy dodatkowy nadawca może mieć własny selektor DKIM albo korzystać z podpisywania realizowanego przez zewnętrzną usługę. Brak pełnej listy nadawców utrudnia ocenę wyników i może prowadzić do niespójnej konfiguracji.

Po wygenerowaniu pary kluczy należy opublikować klucz publiczny pod właściwym selektorem i zweryfikować odpowiedź DNS z kilku niezależnych resolverów. Warto sprawdzić, czy rekord nie jest obcinany, czy nie zawiera niepotrzebnych znaków oraz czy serwer odpowiada zgodnie z oczekiwanym typem rekordu. Klucz prywatny nie powinien być umieszczany w publicznych repozytoriach, załącznikach ani dokumentach dostępnych dla szerokiego grona osób.

Testy powinny obejmować wiadomości kierowane do różnych dostawców poczty, ponieważ obsługa algorytmów może się różnić. W nagłówkach odebranej wiadomości należy odszukać rezultat kontroli DKIM, nazwę domeny podpisującej, selektor i informację o zastosowanym algorytmie. Przydatne są również logi serwera wysyłającego oraz raporty DMARC. Pojedynczy wynik nie zawsze wystarcza do oceny konfiguracji, zwłaszcza gdy wiadomość przechodzi przez kilka bramek.

Nie należy zmieniać jednocześnie wielu elementów bez zachowania punktu odniesienia. Jeśli równocześnie zmienione zostaną selektor, rekord DNS, sposób kanonikalizacji i polityka DMARC, ustalenie źródła problemu będzie trudniejsze. Rozsądny proces obejmuje utworzenie kopii bieżącej konfiguracji, zmianę jednego obszaru, wykonanie testów, obserwację logów i dopiero późniejsze porządki w starych rekordach.

Przydatne jest również ustalenie procedury na wypadek podejrzenia ujawnienia klucza prywatnego. W takiej sytuacji powinien zostać wygenerowany nowy klucz, opublikowany pod nowym selektorem, a poprzedni selektor powinien zostać wycofany po zakończeniu kontrolowanej rotacji. Szczegóły zależą od używanego serwera pocztowego, systemu DNS oraz sposobu zarządzania dostępem.

RFC 8463 – kiedy potrzebna jest pomoc serwisu komputerowego

Do serwisu warto zgłosić się wtedy, gdy występują powtarzające się błędy podpisu DKIM, wiadomości są odrzucane mimo prawidłowego adresu nadawcy albo po zmianie konfiguracji pojawiają się trudne do wyjaśnienia różnice między odbiorcami. Pomoc może obejmować sprawdzenie ustawień systemu pocztowego, analizę logów, kontrolę rekordów DNS oraz ocenę, czy używane oprogramowanie obsługuje rozwiązania opisane w RFC 8463.

Ważne jest przygotowanie informacji o domenie, używanym serwerze pocztowym, selektorze, czasie wystąpienia problemu i pełnych nagłówkach przykładowej wiadomości. Nie należy przekazywać klucza prywatnego. Do analizy wystarcza klucz publiczny, rekord DNS, komunikat błędu i dane diagnostyczne pozbawione poufnej treści. W razie potrzeby Warszawskie Pogotowie Komputerowe 24/7 może zająć się taką diagnostyką, a naprawy z reguły realizowane są do 3 dni roboczych.

Przy zgłoszeniu problemu warto opisać, czy błąd dotyczy wszystkich wiadomości, tylko jednego odbiorcy, czy wyłącznie wiadomości przechodzących przez konkretną bramkę. Znaczenie ma również to, czy problem pojawił się po zmianie serwera, domeny, rekordów DNS lub oprogramowania. Takie informacje pozwalają odróżnić brak obsługi algorytmu od błędnej publikacji klucza albo modyfikacji wiadomości po podpisaniu.

RFC 8463 jest więc istotne przede wszystkim jako rozszerzenie możliwości DKIM. Wdrożenie alternatywnego algorytmu może poprawić efektywność podpisywania i ograniczyć rozmiar danych kryptograficznych, ale wymaga sprawdzenia zgodności całego łańcucha: od generowania podpisu, przez DNS, aż po serwery odbierające. Najbezpieczniejsze podejście opiera się na stopniowej zmianie, obserwacji wyników i zachowaniu możliwości powrotu do wcześniej działającej konfiguracji.