Some things I noticed: * Section 6.1 -- the semantics of 'no-default-alpn' are not actually specified anywhere, as far as I can see; the reader has to infer them from context.
* Section 8 -- 'This section specifies the mapping for HTTPS and HTTP.' It would be good if the HTTP Semantics document were referenced here. * Section 8.2.1 -- 'clients are encouraged to offer additional ALPNs that they support.' I think you mean services, not clients. * Section 8.2.2 -- 'The DNS resolution process is treated as an untrusted channel that learns only the QNAME, and is prevented from mounting any attack beyond denial of service.' a) saying that the DNS resolution process is prevented from mounting any attack is a bit odd; perhaps 'being used as a channel for an attack'? b) what about downgrade (as discussed in security considerations)? * Section 8.3 -- ' If present, the HTTPS record's TargetName and port override the alt-authority.' a) The process for applying this override isn't specified; it has to be inferred from the example, and it's not clear for what purposes the override is in effect. b) This effectively changes the Alt-Svc processing, so that implies this document updates that RFC. * Section 8.2 -- ' • HTTPS over TCP to alt.example:443 (Consistent with both Alt-Svc and its HTTPS record)' Probably clearer to say 'HTTP/2' rather than 'HTTPS' here. * Section 8.3 -- ' • HTTP/3 to alt3.example:9443 (Consistent with both Alt-Svc and its HTTPS record)' Clearer to say '(Consistent with HTTP record and not conflicting with Alt-Svc)' * Section 8.3 -- 'The following connection attempts would be allowed only if the client does not support ECH,' Is it *support* or *use*? * Section 8.5 -- 'By publishing a usable HTTPS RR, the server operator indicates that all useful HTTP resources on that origin are reachable over HTTPS' a) What does 'that origin' refer to? http://example.com and https://example.com are two separate origins. b) If I understand the intent correctly here, it means that sites where http:// and https:// are intentionally different won't be able to deploy this record. While they're in the minority, they do exist, so this needs to be carefully considered for impact on deployability (both of the record and protocols that depends upon it). If it remains, this limitation needs to be documented more prominently. * Section 8.6 -- Use of the phrase 'HTTP-based protocols' is going to conflict with the meaning established in BCP56bis. Choose something else? Cheers, -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
