Subject: [DNSOP] Last Call: <draft-ietf-dnsop-svcb-https-07.txt> (Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 05 Aug 2021 09:42:26 -0700

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Service binding and parameter
specification via the DNS (DNS SVCB and
   HTTPS RRs)'
  <draft-ietf-dnsop-svcb-https-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2021-08-19. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, 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 document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc
   (https://github.com/MikeBishop/dns-alt-svc).  The most recent working
   version of the document, open issues, etc. should all be available
   there.  The authors (gratefully) accept pull requests.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc7871: Client Subnet in DNS Queries (Informational - Internet Engineering Task Force (IETF))
    draft-ietf-tls-esni: TLS Encrypted Client Hello (None - Internet Engineering Task Force (IETF))

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Aug 2021 17:29:52 +1000

Some things I noticed:

* Section 6.1 -- the semantics of 'no-default-alpn' are not actually specified anywhere, as far as I can see; the reader has to infer them from context.

* Section 8 -- 'This section specifies the mapping for HTTPS and HTTP.'  It would be good if the HTTP Semantics document were referenced here.

* Section 8.2.1 -- 'clients are encouraged to offer additional ALPNs that they support.'  I think you mean services, not clients.

* Section 8.2.2 -- 'The DNS resolution process is treated as an untrusted channel that learns only the QNAME, and is prevented from mounting any attack beyond denial of service.'
   a) saying that the DNS resolution process is prevented from mounting any attack is a bit odd; perhaps 'being used as a channel for an attack'?
   b) what about downgrade (as discussed in security considerations)?

* Section 8.3 -- ' If present, the HTTPS record's TargetName and port override the alt-authority.'   
  a) The process for applying this override isn't specified; it has to be inferred from the example, and it's not clear for what purposes the override is in effect.
  b) This effectively changes the Alt-Svc processing, so that implies this document updates that RFC.

* Section 8.2 -- '	• HTTPS over TCP to alt.example:443 (Consistent with both Alt-Svc and its HTTPS record)'   Probably clearer to say 'HTTP/2' rather than 'HTTPS' here.

* Section 8.3 -- '	• HTTP/3 to alt3.example:9443 (Consistent with both Alt-Svc and its HTTPS record)'   Clearer to say '(Consistent with HTTP record and not conflicting with Alt-Svc)'

* Section 8.3 -- 'The following connection attempts would be allowed only if the client does not support ECH,'   Is it *support* or *use*?

* Section 8.5 -- 'By publishing a usable HTTPS RR, the server operator indicates that all useful HTTP resources on that origin are reachable over HTTPS'   
   a) What does 'that origin' refer to?   http://example.com and https://example.com are two separate origins. 
   b) If I understand the intent correctly here, it means that sites where http:// and https:// are intentionally different won't be able to deploy this record. While they're in the minority, they do exist, so this needs to be carefully considered for impact on deployability (both of the record and protocols that depends upon it). If it remains, this limitation needs to be documented more prominently. 

* Section 8.6 -- Use of the phrase 'HTTP-based protocols' is going to conflict with the meaning established in BCP56bis. Choose something else?  

Cheers,
 
--
Mark Nottingham   https://www.mnot.net/

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 12 Aug 2021 14:14:28 -0400

-last-call

Thanks Mark.  I've opened a PR to address most of these points (
https://github.com/MikeBishop/dns-alt-svc/pull/334/files).

Some additional comments inline.

On Thu, Aug 12, 2021 at 3:30 AM Mark Nottingham <[email-masked]> wrote:

> Some things I noticed:
>
> * Section 6.1 -- the semantics of 'no-default-alpn' are not actually
> specified anywhere, as far as I can see; the reader has to infer them from
> context.
>

The semantics of "alpn" and "no-default-alpn" are specified together,
because they are not very meaningful independently.  I've proposed a
rearrangement to try to make this clearer.

...

> * Section 8.2.1 -- 'clients are encouraged to offer additional ALPNs that
> they support.'  I think you mean services, not clients.
>

No, we mean clients.  If the HTTPS record says "I only support HTTP/1.1",
the client should still offer HTTP/1.1 and HTTP/2 in the ClientHello, and
let the TLS handshake do what it will.

...

>   a) The process for applying this override isn't specified; it has to be
> inferred from the example, and it's not clear for what purposes the
> override is in effect.

I've adjusted the wording here to emphasize that this step is just slotting
in below Alt-Svc, just like it slots in below normal request processing.  I
haven't added the "Updates" tag, but I'm open to that if folks still think
it's necessary.

...

> * Section 8.3 -- 'The following connection attempts would be allowed only
> if the client does not support ECH,'   Is it *support* or *use*?
>

Support.  Clients that support ECH have to disable ECH-to-non-ECH fallback,
which is only relevant if ECH _isn't_ actually used.

---

From: Michael Sheldon <[email-masked]>
Date: Wed, 18 Aug 2021 08:59:08 -0700

Just a question.

2.4.2.  AliasMode

    In AliasMode, the SVCB record aliases a service to a TargetName.
    SVCB RRSets SHOULD only have a single resource record in AliasMode.
    If multiple are present, clients or recursive resolvers SHOULD pick
    one at random.

Why the limit of one AliasMode record? I cannot come up with any 
technical reason for the limitation.
And I can definitely think of reasons to allow more than one (Multiple 
CDNs for redundancy/reliability)

--
Michael Sheldon
Principal Developer
GoDaddy Managed DNS

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 18 Aug 2021 13:32:48 -0400

> technical reason for the limitation.

This requirement is written in such a way that it could be relaxed in the
future, if warranted, without creating compatibility problems.  However, I
think the current recommendation to present a single AliasMode RR is sound
and technically well-motivated.

Concretely, presenting multiple AliasMode records creates a challenge for
Additional Section processing.  If we allow multiple-alias architectures,
we create the potential for an exponential explosion of Additional records,
as a recursive resolver attempts to chase all the leaves of an alias tree
to include them in the response.  Using a single alias at each step limits
the tree to a linked list, making it much easier to reason about the impact
on recursive resolvers.

Fallback across CDNs also raises a number of issues.  For example, if one
CDN offers stronger security (e.g. with ECH), it's not clear whether to
allow fallback across them, or how to prioritize connection attempts.

Ultimately, I think it's just much easier to reason about "aliases" that
only alias to one target.  Zones that want to use multi-CDN hosting can do
so using the same tricks used at present, as discussed in Section 10.3.4.

> CDNs for redundancy/reliability)

SVCB is designed to be compatible with simple versions of this (e.g. "hot
standby" deployments).  What it does not offer, at present, is a way to
tell clients to try multiple CDNs without copying any CDN configuration
into the customer domain.