Dịch vụ 1.1.1.1 của Cloudflare chính thức hỗ trợ DNSSEC hậu lượng tử

1.1.1.1 hiện đã xác thực các chữ ký DNSSEC được tạo bằng ML-DSA-44, một thuật toán chữ ký hậu lượng tử được chuẩn hóa bởi Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST). Đây là bước đầu tiên trong việc chuẩn bị cho DNSSEC trước một tương lai mà các thuật toán chữ ký hiện nay không còn an toàn.

Cloudflare dự định đạt được khả năng bảo mật hậu lượng tử toàn diện vào năm 2029. Phần lớn công việc cho đến nay tập trung vào TLS, nhưng mật mã khóa công khai còn được sử dụng trong nhiều hệ thống khác, bao gồm cả DNSSEC.

Mặc dù chúng tôi đã bắt đầu thử nghiệm thỏa thuận khóa hậu lượng tử trong TLS từ năm 2019 và kích hoạt hỗ trợ cho tất cả khách hàng vào năm 2022, các chữ ký hậu lượng tử vẫn chưa nhận được sự thử nghiệm tương đương trong DNSSEC. Vấn đề này cũng khá cấp bách. Việc áp dụng TLS hậu lượng tử rộng rãi trên các client đã mất nhiều năm, một phần vì các thông điệp lớn hơn đã làm lộ ra những giả định và lỗi trong phần mềm mạng hiện có. Trải nghiệm đó cho thấy lý do tại sao việc thử nghiệm quy mô lớn từ sớm lại quan trọng. Chúng ta không thể chờ đợi cho đến khi máy tính lượng tử trở thành mối đe dọa trực tiếp.

Vấn đề nằm ở chỗ các chữ ký hậu lượng tử có kích thước rất lớn. Mỗi chữ ký ML-DSA-44 nặng 2.420 byte, vượt quá giới hạn thông thường của DNS-over-UDP trước khi phản hồi kịp chứa bất kỳ dữ liệu nào khác. Đồng thời, các vùng (zones) sẽ cần phải xuất bản các chữ ký truyền thống cho các trình phân giải (resolvers) cũ hơn trong nhiều năm, tạo ra một con đường hạ cấp tiềm ẩn nếu không được xác thực đúng cách. Thách thức đặt ra là truyền tải các phản hồi lớn hơn này một cách đáng tin cậy mà không làm suy yếu khả năng bảo vệ cho các trình phân giải mới hơn do phải duy trì tính tương thích với các trình phân giải cũ.

Với việc kích hoạt xác thực ML-DSA-44, 1.1.1.1 cho phép chúng tôi kiểm tra cả hai thách thức ở quy mô Internet: truyền tải các phản hồi DNS lớn hơn và ngăn chặn việc quay trở lại sử dụng các chữ ký truyền thống.

Tại sao DNSSEC hậu lượng tử lại quan trọng

Các phản hồi DNS mặc định không được xác thực. Một kẻ tấn công có thể giả mạo phản hồi để chuyển hướng người dùng đến một địa chỉ mà chúng chọn. DNSSEC ngăn chặn điều này bằng cách ký vào các bản ghi DNS. Một trình phân giải xác thực như 1.1.1.1 sẽ theo dõi chuỗi các bản ghi đã ký từ gốc DNS (DNS root) đến tên miền được yêu cầu, kiểm tra xem câu trả lời có xác thực và không bị sửa đổi hay không.

DNSSEC hỗ trợ nhiều thuật toán chữ ký, nhưng hầu hết các thuật toán được sử dụng hiện nay đều dễ bị tổn thương trước các máy tính lượng tử trong tương lai. RSA và ECDSA dựa trên các bài toán toán học được cho là không khả thi đối với các máy tính thông thường khi sử dụng kích thước khóa hiện tại. Chúng tôi đang chuẩn bị cho khả năng vào năm 2030, một máy tính lượng tử đủ mạnh có thể được chế tạo để bẻ khóa các khóa này. Khi đó, kẻ tấn công có thể khôi phục khóa riêng tương ứng và tạo ra các chữ ký giả mạo mà các trình xác thực sẽ chấp nhận. Con đường tấn công được hiển thị dưới đây.

Các máy tính lượng tử có khả năng thực hiện những cuộc tấn công này hiện chưa tồn tại. DNSSEC cung cấp tính xác thực thay vì tính bảo mật, vì vậy nó không chịu ảnh hưởng bởi các cuộc tấn công “thu thập bây giờ, giải mã sau”. Lý do cần bắt đầu ngay bây giờ là vì việc thay đổi DNSSEC đòi hỏi sự phối hợp giữa các máy chủ có thẩm quyền (authoritative servers), các cơ quan đăng ký (registries), các nhà đăng ký (registrars) và các trình phân giải xác thực. Quá trình di chuyển cuối cùng phải đạt đến cấp cao nhất của hệ thống phân cấp DNS, nơi một khóa bị xâm phạm sẽ gây ra tác động lớn nhất. Một kẻ tấn công khôi phục được khóa ký vùng gốc (root zone signing key) bằng máy tính lượng tử có thể giả mạo đường dẫn xác thực đến bất kỳ vùng nào bên dưới nó: “bẻ khóa một lần, giả mạo mọi nơi”. ML-DSA-44 cung cấp một điểm khởi đầu chuẩn hóa cho quá trình di chuyển đó, và việc hỗ trợ nó trong 1.1.1.1 cho phép chúng tôi, cũng như toàn bộ hệ sinh thái DNS, tích lũy kinh nghiệm vận hành.

Tại sao việc thay thế thuật toán lại khó khăn

DNSSEC được thiết kế để hỗ trợ các thuật toán mới. Về nguyên tắc, việc hỗ trợ ML-DSA-44 có nghĩa là xuất bản khóa công khai của nó và hướng dẫn các trình xác thực cách kiểm tra chữ ký của nó. Trên thực tế, hai đặc điểm khiến quá trình chuyển đổi trở nên khó khăn: chữ ký có kích thước lớn và thuật toán cũ không phải lúc nào cũng có thể được loại bỏ một cách an toàn.

Chữ ký 2.420 byte làm thay đổi gói tin

Các thuật toán DNSSEC thường được sử dụng hiện nay tạo ra các chữ ký tương đối nhỏ. Ví dụ, ECDSA P-256 tạo ra chữ ký 64 byte. Chữ ký ML-DSA-44 là 2.420 byte, lớn hơn gần 38 lần.

Thuật toán

Số hiệu

Kích thước khóa công khai

Kích thước chữ ký

RSA-2048/SHA-256

260 byte

256 byte

ECDSA P-256

13

64 byte

64 byte

ML-DSA-44

18

1.312 byte

2.420 byte

Sự khác biệt đó rất quan trọng vì nhiều hệ thống gửi, truyền tải và nhận thông điệp DNS rất nhạy cảm với kích thước thông điệp. DNS ban đầu giới hạn các thông điệp gửi qua UDP ở mức 512 byte. Sau đó, EDNS(0) cho phép một trình phân giải quảng bá phản hồi UDP lớn nhất mà nó sẵn sàng chấp nhận từ máy chủ tên miền. Nhiều triển khai DNS sử dụng giới hạn tải trọng UDP thận trọng là 1.232 byte, được chọn để phù hợp với MTU (đơn vị truyền tải tối đa) tối thiểu của IPv6 là 1.280 byte. Gần đây hơn, RFC 9715 khuyến nghị mức tối đa là 1.400 byte cho DNS over UDP. Một chữ ký ML-DSA-44 đã vượt quá ngân sách đó, chưa tính đến RRset đã ký, tên miền, tiêu đề DNS và các bản ghi DNSSEC khác. Việc gửi một phản hồi như vậy dưới dạng UDP phân mảnh là không đáng tin cậy và nên tránh. Thay vào đó, máy chủ có thẩm quyền nên trả về một phản hồi bị cắt bớt (truncated), nhắc trình phân giải thử lại bằng một giao thức truyền tải khác, thường là TCP.

Hiệu ứng này rõ rệt nhất trong các phản hồi DNSKEY, chứa các khóa mà trình phân giải cần để xác thực vùng. Khóa công khai ML-DSA-44 là 1.312 byte, và RRset DNSKEY cũng mang theo một chữ ký 2.420 byte. ML-DSA-44 không thể thay thế hoàn toàn các thuật toán ký truyền thống cho đến khi nó được hỗ trợ rộng rãi trên toàn bộ hệ sinh thái DNS, một quá trình có thể mất nhiều năm. Cho đến lúc đó, các phản hồi DNSKEY có thể chứa cả khóa và chữ ký truyền thống lẫn hậu lượng tử để duy trì tính tương thích với các trình xác thực cũ. Việc xoay vòng khóa (key rollovers) có thể thêm nhiều khóa hơn nữa, khiến các phản hồi này càng lớn hơn.

Việc xử lý DNS qua các giao thức truyền tải khác ngoài UDP không phải là điều bất thường. Cloudflare Radar cho thấy khoảng 85% truy vấn đến 1.1.1.1 đến qua UDP. Nền tảng đằng sau 1.1.1.1, Big Pineapple, cũng cung cấp năng lượng cho các dịch vụ DNS khác, bao gồm cả Gateway DNS. Trên tất cả các dịch vụ được xử lý bởi Big Pineapple, khoảng 60% truy vấn đến qua UDP. 40% còn lại sử dụng các giao thức truyền tải như TCP, DNS over TLS (DoT) và DNS over HTTPS (DoH).

Những con số đó mô tả cách các truy vấn đến các dịch vụ trình phân giải của Cloudflare, chứ không phải cách 1.1.1.1 giao tiếp với các máy chủ có thẩm quyền. Các phản hồi ML-DSA-44 lớn vẫn có thể gây ra các lần thử lại TCP bổ sung ở phía đó, nhưng việc xử lý DNS qua các giao thức truyền tải khác ngoài UDP đã là một phần bình thường trong việc vận hành 1.1.1.1 ở quy mô lớn.

Hỗ trợ hai thuật toán tạo ra rủi ro hạ cấp

Việc thay thế một thuật toán DNSSEC hiện có không thể diễn ra ngay lập tức. Nếu một vùng chỉ xuất bản ML-DSA-44, các trình phân giải không hỗ trợ nó sẽ không thể xác thực vùng đó. Do đó, con đường di chuyển thực tế là xuất bản cả khóa và chữ ký truyền thống lẫn hậu lượng tử cùng nhau.

Điều đó duy trì tính tương thích, nhưng tự nó không cung cấp khả năng bảo mật hậu lượng tử. RFC 6840 quy định rằng “các trình xác thực NÊN chấp nhận bất kỳ đường dẫn hợp lệ đơn lẻ nào”. Quy tắc này cho phép các trình xác thực sử dụng bất kỳ thuật toán nào đã được xuất bản mà chúng hỗ trợ.

Tuy nhiên, khi một thuật toán truyền thống như ECDSA không còn an toàn, hành vi tương tự sẽ tạo ra một con đường hạ cấp. Một kẻ tấn công có thể giả mạo câu trả lời chỉ sử dụng ECDSA mà trình phân giải chấp nhận mặc dù nó hỗ trợ ML-DSA-44, như minh họa dưới đây.

Việc ngăn chặn sự hạ cấp này đòi hỏi một tín hiệu xác thực rằng vùng đó nên được xác thực bằng ML-DSA-44. 1.1.1.1 sử dụng các bản ghi DS do vùng cha xuất bản cho mục đích này. Nếu RRset DS đã xác thực chứa một bản ghi cho thuật toán hậu lượng tử được hỗ trợ, thì tín hiệu đó đã hiện diện.

Sau đó, 1.1.1.1 chủ động áp dụng chính sách xác thực cục bộ hạn chế hơn. Nó yêu cầu ít nhất một đường dẫn xác thực hậu lượng tử hợp lệ; một đường dẫn truyền thống không còn đủ nữa. Nếu không có đường dẫn ML-DSA-44 nào xác thực thành công, quá trình xác thực sẽ thất bại. Đây (chưa) phải là hành vi xác thực DNSSEC thông thường, nhưng RFC 4035 cho phép chính sách trình phân giải cục bộ xác định xem có cần kiểm tra các chữ ký bổ sung hay không và cách xử lý các kết quả xung đột.

Các chữ ký truyền thống có thể vẫn khả dụng cho các trình phân giải cũ mà không cho phép các trình phân giải có khả năng hậu lượng tử quay trở lại sử dụng chúng. Tín hiệu hạ cấp chỉ an toàn hậu lượng tử nếu việc triển khai ML-DSA-44 và bảo vệ hạ cấp mở rộng từ điểm tin cậy (trust anchor) qua mọi sự ủy quyền (delegation). Việc xoay vòng khóa vùng thường xuyên hơn không giải quyết được vấn đề: kẻ tấn công có thể nhắm mục tiêu vào một khóa dễ bị tổn thương ở bất kỳ đâu cao hơn trong chuỗi và giả mạo mọi sự ủy quyền bên dưới nó.