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

[Tommy Pauly <[e-mail]>]

> On Sep 24, 2019, at 7:32 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hi Erik,
> 
> FWIW, if browsers preferred this to an ESNI RR and
> we could forget the ESNI RR then I'd be ok with that.
> I'm not clear if they do or not though.

Regarding the status of which RR we use, I think the main goal for a system (speaking as an operating system vendor, rather than specifically just a browser vendor) would be to minimize the number of records we need to look up in order to get a usable set of information for connecting. To that end, I appreciate the generality and extensibility of the SCVB approach. It should ideally include any functionality needed for an ESNI-only deployment, but also allow for the specification of alt-svc, as well as other extensions that may come in the future.

Thanks,
Tommy

> In the meantime,
> assuming this went ahead instead of or in addition
> to an ESNI RR, I've a few questions below...
> 
> On 24/09/2019 14:21, 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.
> 
> So I think the basic ESNI case where there's no
> name changes nor alt-svc etc would be as below in
> presentation syntax, am I reading that right?
> 
>   example.com <http://example.com/>. 7200  IN HTTPSSVC 0 . ( esnikeys="/wHrAh..." )
> 
> I'm also not clear if that's the exact same as:
> 
>   example.com <http://example.com/>. 7200  IN SVCB 0 . ( esnikeys="/wHrAh..." )
> 
> ...is it? If so, which'd be preferred or would
> clients be expected to be able to handle both?
> And I don't get why two ways to say the same thing
> are useful.
> 
> Secondly, ESNIKeys currently supports versions,
> multiple keys, cipher_suites, extensions and even
> dns_extensions. And we could have >1 rrdata for
> ESNI or for SCVB/HTTPSSVC.
> 
> Would you envisage adoption of SVCB/HTTPSSVC meaning
> that we could drop some of the generality that's
> present in ESNIKeys? If so, what?
> 
> I'd like if ESNIKeys were made simpler FWIW, so if
> this had that effect, then I'd be more for it. If,
> OTOH, this just added complexity (for a library
> implementing ESNI), which currently seems to be the
> case, then it'd be less attractive, to me at least.
> (I guess I'm agreeing with Rich there:-)
> 
> Thanks,
> S.
> 
> 
>> 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.
>> 
>>      Erik
>> 
>> 
>> ---------- Forwarded message ---------
>> From: Erik Nygren <[e-mail]>
>> Date: Tue, Sep 24, 2019 at 9:17 AM
>> Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00
>> To: dnsop WG <[e-mail]>, Ben Schwartz <[e-mail]>, Mike
>> Bishop <[e-mail]>
>> 
>> 
>> Following discussions around the "HTTPSSVC" record proposal in Montreal
>> with the DNSOP, HTTP and TLS WGs, we've updated what was previously
>> "draft-nygren-httpbis-httpssvc-03".  The new version is
>> "draft-nygren-dnsop-svcb-httpssvc-00".   This incorporates much of the
>> feedback from the WG discussions, as well as feedback from discussions with
>> the TLS WG (as we'd like to see this replace the need for a separate ESNI
>> record).
>> 
>> In particular, it generalizes the record into a new "SVCB" record which
>> doesn't have any protocol-specific semantics.  It also defines an
>> "HTTPSSVC" record that is compatible with SVCB (sharing a wire-format and
>> parameter registry) and which defines the HTTP(S)-specific semantics such
>> as bindings to Alt-Svc.  Other protocols can either define bindings
>> directly to SVCB or can define their own RR Type (which should only ever be
>> needed if there is a need to use the record at a zone apex).
>> 
>> We'd like to see this adopted by the DNSOP WG.  Until then, issues and PRs
>> can go against:  https://github.com/MikeBishop/dns-alt-svc
>> 
>> Major changes from "draft-nygren-httpbis-httpssvc-03" include:
>> 
>> * Separation into the SVCB and HTTPSSVC RR Types  (and separated all of the
>> HTTPS-specific functionality and text to its own portion of the document).
>> * Elimination of the SvcRecordType field (and making the SvcRecordType
>> implicit)
>> * Changing the wire format of parameters from being in Alt-Svc text format
>> to a more general binary key/value pair format (with a mapping to Alt-Svc
>> for HTTPSSVC).
>> * Adding optional "ipv4hint" and "ipv6hint" parameters.
>> * Quite a few cleanups and clarifications based on input (and we
>> undoubtedly have more left to go)
>> 
>> This retains support for all of the use-cases that the previous HTTPSSVC
>> record had (such as for covering the ANAME / CNAME-at-the-zone-apex
>> use-case).
>> 
>> Feedback is most welcome.  If the TLS WG is going to use this instead of a
>> separate ESNI record, there is a desire to make progress on this fairy
>> quickly.
>> 
>>       Erik
>> 
>> ---------- Forwarded message ---------
>> 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]>
>> 
>> 
>> 
>> A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
>> has been successfully submitted by Benjamin Schwartz and posted to the
>> IETF repository.
>> 
>> Name:           draft-nygren-dnsop-svcb-httpssvc
>> Revision:       00
>> Title:          Service binding and parameter specification via the DNS
>> (DNS SVCB and HTTPSSVC)
>> Document date:  2019-09-22
>> Group:          Individual Submission
>> Pages:          33
>> URL:
>> https://www.ietf.org/internet-drafts/draft-nygren-dnsop-svcb-httpssvc-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-nygren-dnsop-svcb-httpssvc/
>> Htmlized:
>> https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-nygren-dnsop-svcb-httpssvc
>> 
>> 
>> Abstract:
>>   This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
>>   types to facilitate the lookup of information needed to make
>>   connections for origin resources, such as for HTTPS URLs.  SVCB
>>   records allow an origin to be served from multiple network locations,
>>   each with associated parameters (such as transport protocol
>>   configuration and keying material for encrypting TLS SNI).  They also
>>   enable aliasing of apex domains, which is not possible with CNAME.
>>   The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP
>>   origins.  By providing more information to the client before it
>>   attempts to establish a connection, these records offer potential
>>   benefits to both performance and privacy.
>> 
>>   TO BE REMOVED: This proposal is inspired by and based on recent DNS
>>   usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
>>   standing desires to have SRV or a functional equivalent implemented
>>   for HTTP).  These proposals each provide an important function but
>>   are potentially incompatible with each other, such as when an origin
>>   is load-balanced across multiple hosting providers (multi-CDN).
>>   Furthermore, these each add potential cases for adding additional
>>   record lookups in-addition to AAAA/A lookups.  This design attempts
>>   to provide a unified framework that encompasses the key functionality
>>   of these proposals, as well as providing some extensibility for
>>   addressing similar future challenges.
>> 
>>   TO BE REMOVED: The specific name for this RR type is an open topic
>>   for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as
>>   they are easy to replace.  Other names might include "B", "SRV2",
>>   "SVCHTTPS", "HTTPS", and "ALTSVC".
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> <0x5AB2FAF17B172BEA.asc>_______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>