On Tue, Sep 24, 2019 at 09:21:25AM -0400, Erik Nygren wrote: > Following the discussions in Montreal (as well as with some of the ESNI > authors), > we refactored the HTTPSSVC draft to make it more general. The hope is that > it could be an alternative (or replace the need) for a distinct ESNI record. > The draft generalizes to a protocol-agnostic SVCB record, but also specifies > an HTTPSSVC record for the HTTP(S) use-case. > > Based on discussions with various chairs, the plan is to call for adoption > in the DNSOP WG. > > Comments/feedback are most welcome. > > From: <internet-dra...@ietf.org> > Date: Mon, Sep 23, 2019 at 7:01 PM > Subject: New Version Notification for > draft-nygren-dnsop-svcb-httpssvc-00.txt > To: Mike Bishop <mbis...@evequefou.be>, Erik Nygren <erik+i...@nygren.org>, > Benjamin Schwartz <bem...@google.com> > > Name: draft-nygren-dnsop-svcb-httpssvc > Revision: 00 > Title: Service binding and parameter specification via the DNS > (DNS SVCB and HTTPSSVC)
Couple comments: - Is there need for two resource records? It seems like the two uses could be distinguished by starting point. - What about starting point of protocols that have defined name for SRV records? That thing is of form _foo._tcp.domain.example (or _foo.udp.domain.example). - One possible use for AliasForm with '.' would be to signal that this service does not exist (IIRC, some other rrtype had special "this does not exist" value). - It seems like ALPN and port are fundamential and would be better being their own fields, instead of attributes. - This could be defined to carry out TLS upgrade for any protocol that uses it. However, one would need to allow ALPN to override the behavior (e.g., HTTP/3 needs to change transport from TCP to UDP). - To me, ipv4hint/ipv6hint seem very bad ideas, as they break normalization and ownership, drastically increasing odds for errors. - I would not speculate about records for DNS authorities looking anything like this. That RRtype will be very special snowflake. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
