Re: [TLS] Fwd: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

[Ilari Liusvaara <[e-mail]>]

On Tue, Sep 24, 2019 at 12:24:15PM -0400, Ben Schwartz wrote:
> On Tue, Sep 24, 2019 at 11:31 AM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > 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: <[e-mail]>
> > > Date: Mon, Sep 23, 2019 at 7:01 PM
> > > Subject: New Version Notification for
> > > draft-nygren-dnsop-svcb-httpssvc-00.txt
> > > To: Mike Bishop <[e-mail]>, Erik Nygren <
> > [e-mail]>,
> > > Benjamin Schwartz <[e-mail]>
> > >
> > > Name:           draft-nygren-dnsop-svcb-httpssvc
> > > Revision:       00
> > > Title:          Service binding and parameter specification via the DNS
> > > (DNS SVCB and HTTPSSVC)
> >
> > Couple comments:
> >
> - 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).
> >
> 
> Do you mean to ask about how this would coexist with SRV?  Broadly, I view
> this as a successor to SRV, but I think the details of how they interact
> would have to be defined by the protocol mapping document for a specific
> protocol that currently uses SRV.  The correct logic might be different for
> different protocols; I'm not sure.

I mean more of the starting point to use for protocols that already use
SRV.

> If you think there's a universal rule, that would be good to know.
> 
> 
> > - 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).
> >
> 
> Currently, that's effectively indicated by NXDOMAIN/NODATA.  Do you see a
> need for a specific flag?

Well, NODATA could work (except for http(s)://foo.example).

> 
> > - It seems like ALPN and port are fundamential and would be better
> >   being their own fields, instead of attributes.
> >
> 
> ALPN only applies to TLS-based protocols, and even many TLS-based protocols
> don't use it.  For example, a hypothetical mapping of SVCB for SSH would
> have no use for ALPN.

Some sketch-on-napkin stuff I did actually had subprotocol in place of
ALPN, with subtly different meaning (but most of the time it goes
directly to ALPN).

And I have dealt with hacky SSH over TLS (or worse, TELNET over TLS),
and both did use ALPN.
 
One major issue nowadays is that SSH does not have any equivalent of
SNI (I have seen setups where that would have been very useful).

> I agree that ports are nearly universal, but they're often redundant.  For
> example, in HTTPSSVC, the port can be omitted if it is the default port.
> Since the port doesn't apply in the AliasForm, making it a parameter seemed
> like the most convenient representation.

Some sketch-on-napkin stuff I did had port 0 mean "default/as-specified"
(because it is not like you can use port 0 with APIs as they are).
 
> 
> > - 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).
> >
> 
> Yes, SVCB is well-suited for pre-connection "upgrades" of all sorts, and
> hopefully it will be useful for TLS upgrades beyond HTTP.  As you note,
> this can be nontrivial, as in the case of HTTP, where the ALPN can signal a
> transport change!  For that reason, the details of client behavior are left
> to the protocol mappings.

Obviously if the ALPN is something unknown, one can not connect, as the
semantics are unknown.

And yes, most protocols could not deal with transport change.

> > - To me, ipv4hint/ipv6hint seem very bad ideas, as they break
> >   normalization and ownership, drastically increasing odds for errors.
> 
> I admit that these hints are fragile, but they have been a very strong
> request from some browser vendors, and similar hints are also present in
> the ESNI RR proposal.  The concern is that, when the origin is using
> HTTPSSVC delegation, and the client's recursive is not HTTPSSVC-aware, the
> client will have to perform a followup A+AAAA query before it can start
> connecting.  The IP hints allow connection start right away.
> 
> The draft contains a number of mitigations against fragility.  For example,
> the client is still required to perform the A+AAAA queries, and switch to
> one of those "official" IP addresses as soon as they are available.
> Hopefully this limits the amount of mischief that can be made by bad IP
> hints.

I do not regard ESNI spec as example of good design. One way to mitigate
potential problems would be to only honor IPhint fields if target is .
(self). That would still leave things unnormalized but at least fix the
issues with ownership.

> 
> > - I would not speculate about records for DNS authorities looking
> >   anything like this. That RRtype will be very special snowflake.
> >
> 
> I agree, we should probably remove that.  Hopefully many of the SVCB
> conventions will be reusable, but it's too soon to say.

I have some ideas (but no idea just how badly those would break DNS),
and they look pretty much nothing like SVCB. But that is in scope of
DPRIVE, not TLS nor HTTPBIS.


-Ilari