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

Reply via email to