Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https

From: Tim Wicinski <[email-masked]>
Date: Thu, 18 Mar 2021 16:53:39 -0400

This starts a Working Group Last Call for draft-ietf-dnsop-svcb-https

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

The Current Intended Status of this document is: Proposed Standard

Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:  2
April 2021

thanks
tim

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 19 Mar 2021 11:13:24 +0100

Hello WG,

On 3/18/21 9:53 PM, Tim Wicinski wrote:
> If someone feels the document is *not* ready for publication, please
> speak out with your reasons.

I re-read the draft-03 last week and just had a look at the diff to -04.

There are two things I find unclear about the current draft, and that is
the handling of automatic mandatory keys. Especially the rules on how to
verify the record is consistent (section 7).

The draft mentions

  The SvcParamKey "mandatory" is used to indicate any mandatory keys for
  this RR, in addition to any automatically mandatory keys that are
  present.

and

  This SvcParamKey is always automatically mandatory, and MUST NOT
  appear in its own value-list.  Other automatically mandatory keys
  SHOULD NOT appear in the list either.  (Including them wastes space
  and otherwise has no effect.)

This means an HTTPS record MUST have a port and a no-default-alpn
SVCParam in both the presentation and wire format, without the keys
being present in the mandatory key? It would be good to add an example
or some clarification here.

The second question arises for the "default set" of ALPNs. Section 6.1 says

   Each scheme that uses this SvcParamKey defines a "default set" of
   supported ALPNs, which SHOULD NOT be empty.  To determine the set of
   protocol suites supported by an endpoint (the "SVCB ALPN set"), the
   client adds the default set to the list of "alpn-id"s unless the "no-
   default-alpn" SvcParamKey is present.  The presence of an ALPN
   protocol in the SVCB ALPN set indicates that this service endpoint,
   described by TargetName and the other parameters (e.g. "port") offers
   service with the protocol suite associated with this ALPN protocol.

The HTTPS record mentions that no-default-alpn is automatically
mandatory, but also that alpn has a default value. Which would mean that
that the default alpn is never used?

Or is mandatory a hint to the end-client that it MUST understand the
keys mentioned in order to use the RR? If that is the case, a few words
to that effect would be good.

I hope the rambling above makes the question clear.

Cheers,

Pieter
-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 19 Mar 2021 16:57:58 -0400

On Fri, Mar 19, 2021 at 6:13 AM Pieter Lexis <[email-masked]>
wrote:

> keys mentioned in order to use the RR?

Exactly.

If that is the case, a few words
> to that effect would be good.

Section 7 says:

   In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
>    RR will not function correctly for clients that ignore this
>    SvcParamKey.

...

>    A ServiceMode RR is considered "compatible" with a client if the
>    client recognizes all the mandatory keys, and their values indicate
>    that successful connection establishment is possible.  If the SVCB
>    RRSet contains no compatible RRs, the client will generally act as if
>    the RRSet is empty.

Can you suggest a clarification?