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

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?

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

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

* Did you consider publishing these as two separate documents? That might make the layering more clear.

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

* Section 7.5 gives the HTTPS record effective HSTS semantics. Has there been engagement with / review from the security community on this? In particular:
  * Are the presumably shorter DNS TTLs suitable for HSTS use cases?
  * Are there any other fixes / enhancements to HSTS that we want to layer in?

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/

Received on Tuesday, 23 June 2020 05:45:01 UTC