> On Sep 24, 2019, at 7:32 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > 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 <erik+i...@nygren.org> >> Date: Tue, Sep 24, 2019 at 9:17 AM >> Subject: SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00 >> To: dnsop WG <dn...@ietf.org>, Ben Schwartz <bem...@google.com>, Mike >> Bishop <mbis...@evequefou.be> >> >> >> 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: <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> >> >> >> >> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > <0x5AB2FAF17B172BEA.asc>_______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
