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

[Ben Schwartz <[e-mail]>]

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:
>
> - Is there need for two resource records? It seems like the two uses
>   could be distinguished by starting point.
>

I believe you're right that a single RR type would suffice, but that RR
type specification would have to contain special-case logic for HTTP and
HTTPS.  We felt it was more elegant to have one purely generic RR type, and
one specialized.  Also, if any other protocol wants an SVCB-compatible type
without prefixing, we'll end up with multiple RR types anyway.

If the WG would prefer a single RR type with a special-case for HTTP(S), I
think we would be able to make that change.

- 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.

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?


> - 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.

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.


> - 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.


> - 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 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.


>
>
> -Ilari
>