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

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

Received on Wednesday, 8 July 2020 05:47:49 UTC