Re: nearing completion for HTTPS RR type (and SVCB RR type)

FYI, I've written a proposed change that avoids using "origin" for this
purpose, and emphasizes the connection to URIs:
https://github.com/MikeBishop/dns-alt-svc/pull/204.  Comments welcome.

On Wed, Jul 8, 2020 at 1:47 AM Mark Nottingham <mnot@mnot.net> wrote:

>
>
> > On 25 Jun 2020, at 12:20 pm, Ben Schwartz <bemasc@google.com> wrote:
> >
> > On Tue, Jun 23, 2020 at 1:48 AM Mark Nottingham <mnot@mnot.net> wrote:
> > Hi Erik,
> >
> > Thanks for that. Reading through the document for the first time in a
> while, a few questions pop to mind:
> >
> > * For those who haven't been following, can you explain why it was
> thought best to decouple form Alt-Svc?
> >
> > Analyzing the interaction between Encrypted ClientHello (ECH), SVCB, and
> Alt-Svc became extremely complex, and the resulting behaviors seemed likely
> to be brittle.  One key point is that Alt-Svc was designed to be optional
> (fallback to direct connection is always allowed), but this is not true for
> any medium that can transfer ECH public keys ("ECHConfigs"), due to the
> need for downgrade-attack resistance.  Retrofitting a no-fallback mode onto
> Alt-Svc raised concerns about ECH key rotation (Alt-Svc cache lifetimes are
> very long), ALPN negotiation, and CDN transitions/multi-CDN.
> >
> > You can see a much more detailed discussion here:
> > https://github.com/MikeBishop/dns-alt-svc/issues/105.
> > https://github.com/MikeBishop/dns-alt-svc/issues/60
> > https://github.com/MikeBishop/dns-alt-svc/issues/58
> >
> > * The introduction talks about SVCB 'provid[ing] clients with complete
> instructions for access to an origin.' 'origin' is a Web-specific term; is
> there a more neutral term you can use to distinguish it from HTTPS? I see
> in Terminology that you justify this for alignment with Alt-Svc, but that
> seems to assume that other protocols will have an origin concept -- in
> particular, a scheme (I'm not against aligning all potential protocols to
> this model, just a bit surprised that it's got this far).
> >
> > SVCB is designed for use with URIs, so a scheme is required.  (Section
> 10, "The scheme SHOULD have an entry in the IANA URI Schemes Registry".)
> URIs that concern a domain name presumably have an "authority" in their URI
> that contains a "host", and might contain a "port".
> >
> > If you can think of a better name for "scheme, host, and
> port-if-applicable", we can certainly adjust.
>
> I think it's fine, it might be good however to call attention to the fact
> that this is for URI-based protocols early on...
>
>
> >  * That brings to mind the SRV framework; is there any attempt to relate
> the SVCB framework to it -- especially since this appears to embed the ALPN
> view of the world? I'm sure some will want to know...
> >
> > There's no explicit connection to SRV.  Personally, I view SVCB as a
> successor to SRV, but it's certainly not intended to replace SRV where SRV
> is already working well.
>
> Fair enough.
>
>
> > * Did you consider publishing these as two separate documents? That
> might make the layering more clear.
> >
> > It would of course be possible to separate them, but I think it might be
> confusing, because SVCB's design choices are easiest to understand in the
> context of a realistic example, and HTTPS is the only example that is
> initially specified.
> >
> > * Do we have statements of support for the delegation use cases from
> client implementers? This was a key purpose for Alt-Svc, but it wasn't
> implemented by clients widely.
> >
> > I believe we do.
> >
> > * Section 7.5 gives the HTTPS record effective HSTS semantics. Has there
> been engagement with / review from the security community on this?
> >
> > I would say so, e.g. https://github.com/MikeBishop/dns-alt-svc/issues/87
> >
> > In particular:
> >   * Are the presumably shorter DNS TTLs suitable for HSTS use cases?
> >
> > TTL is not strictly relevant here.  Unlike the HSTS header, this
> semantic works perfectly well even with TTL=0.  The HSTS header relies on
> the user having had a "clean network path" in the (recent) past.  The
> HTTPS-upgrade here instead relies on the user currently having a "clean DNS
> path", e.g. inside DoH.
> >
> >   * Are there any other fixes / enhancements to HSTS that we want to
> layer in?
> >
> > Suggestions welcome!
> >
> >
> > Cheers,
> >
> >
> >
> > > On 18 Jun 2020, at 12:48 pm, Erik Nygren <erik+ietf@nygren.org> wrote:
> > >
> > > We're hoping to start WGLC in DNSOP sometime in the next month or two
> > > for the HTTPS RR type (formerly "HTTPSSVC", along with SVCB).
> > > We submitted an early code point allocation request for the DNS RR
> types.
> > > As such, now would be a good time to take another read through.
> > >
> > > Remaining issues are tracked here (and can be discussed here,
> > > in dnsop, or in the issue tracker as appropriate):
> > >
> > >     https://github.com/MikeBishop/dns-alt-svc/issues
> > >
> > > The most relevant to the HTTP WG are:
> > >
> > > * Consider SVCB-Used header
> > > * Parameter to indicate no HSTS-like behavior
> > > * Consider a way to indicate some keys as "mandatory"
> > >
> > > Note that the current draft decouples itself fully from Alt-Svc.
> > > That there are a few areas for future improvement to Alt-Svc
> > > that came out of discussion here, but are not covered in the current
> draft.
> > >
> > > The latest authors' draft (for pull requests) is at:
> > >
> > >
> https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md
> > >
> > > and latest published is at:
> > >
> > >
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00
> > >
> > > Best, Erik
> > >
> > >
> > > ---------- Forwarded message ---------
> > > From: <internet-drafts@ietf.org>
> > > Date: Fri, Jun 12, 2020 at 4:18 PM
> > > Subject: New Version Notification for
> draft-ietf-dnsop-svcb-https-00.txt
> > > To: Benjamin Schwartz <bemasc@google.com>, Erik Nygren <
> erik+ietf@nygren.org>, Mike Bishop <mbishop@evequefou.be>
> > >
> > >
> > >
> > > A new version of I-D, draft-ietf-dnsop-svcb-https-00.txt
> > > has been successfully submitted by Ben Schwartz and posted to the
> > > IETF repository.
> > >
> > > Name:           draft-ietf-dnsop-svcb-https
> > > Revision:       00
> > > Title:          Service binding and parameter specification via the
> DNS (DNS SVCB and HTTPS RRs)
> > > Document date:  2020-06-12
> > > Group:          dnsop
> > > Pages:          39
> > > URL:
> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-svcb-https-00.txt
> > > Status:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
> > > Htmlized:
> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00
> > > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sConsider a
> "mandatory" key rangesvcb-https
> > >
> > >
> > > Abstract:
> > >    This document specifies the "SVCB" and "HTTPS" DNS resource record
> > >    (RR) 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 keys for encrypting the TLS ClientHello).  They
> > >    also enable aliasing of apex domains, which is not possible with
> > >    CNAME.  The HTTPS 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: This document is being collaborated on in Github at:
> > >    https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
> > >    working version of the document, open issues, etc. should all be
> > >    available there.  The authors (gratefully) accept pull requests.
> > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>