IETF Last Call Review of draft-farrell-tls-pemesni-11
review-farrell-tls-pemesni-11-dnsdir-lc-reid-2025-12-05-00
| Request | Review of | draft-farrell-tls-pemesni |
|---|---|---|
| Requested revision | No specific revision (document currently at 13) | |
| Type | IETF Last Call Review | |
| Team | DNS Directorate (dnsdir) | |
| Deadline | 2026-01-01 | |
| Requested | 2025-12-04 | |
| Authors | Stephen Farrell | |
| I-D last updated | 2026-03-04 (Latest revision 2026-01-23) | |
| Completed reviews |
Dnsdir IETF Last Call review of -11
by Jim Reid
(diff)
Genart IETF Last Call review of -11 by Linda Dunbar (diff) Dnsdir Telechat review of -12 by Jim Reid (diff) |
|
| Assignment | Reviewer | Jim Reid |
| State | Completed | |
| Request | IETF Last Call review on draft-farrell-tls-pemesni by DNS Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/dnsdir/41_yY8qM3GTKAuk0LFC7NH4NW1Q | |
| Reviewed revision | 11 (document currently at 13) | |
| Result | Ready w/issues | |
| Completed | 2025-12-05 |
review-farrell-tls-pemesni-11-dnsdir-lc-reid-2025-12-05-00
I'm the DNS Directorate reviewer of this I-D. IMO the document needs a little more work/clarification. Sorry Stephen. Section 3 says "the public key...can also be published in the DNS". It does not explain which RRytpe or owner-name is to be used for that purpose. Presumably this key will be found in the ECHConfigList element of some HTTPS or SVCB record. This should be more explicit. An example RRtype corresponding to the ECHConfig PEM File given in Figure 1 would be helpful. There's an unstated implication that the private key can be found in the ECHConfigList. As written "the public key...can also be published in the DNS" suggests the private key is already there. Which I'm sure is not what the author intended. Deleting "also" here could help avoid any confusion. However I think it would be much better if the Security Considerations section clearly stated that private keys MUST NOT be published in the DNS. I think the I-D needs to recommend using DNSSEC and/or encrypted DNS transport to ensure the integrity of the data in the DNS responses. However I don't know enough about the ECH threat model to make a judgement on whether that is or isn't a valid concern.