Subject: [Add] questions about the Examples section of svcb-dns-02

From: Peter van Dijk <[email-masked]>
Date: Wed, 07 Apr 2021 22:31:57 +0200

Hello Ben, and rest of WG,

https://tools.ietf.org/html/draft-schwartz-svcb-dns-02#section-8 has an
example RRset for a resolver, containing 3 SVCB RRs. This example is
very useful!

However, I have a few questions/comments about it:

(1) Can you reorder the bullet list to match the order in the RRset?
(i.e. put the TLS one second)

(2) I see one SVCB record (with priority 2) advertising a DoT server
(by leaving out the ALPN). It has port=8530. Yet, the text above says
there's DoT on 853 and 8530. Where does 853 come into play, if the
prio=2 SVCB record says port=8530?

(3) All three example RRs have an echconfig parameter. While I
understand it makes sense for an operator to be consistent in doing ECH
over all their offerings, it somewhat looks like everybody is expected
to do echconfig - perhaps it would be clearer to not have echconfig on
all three? Then, maybe clarify that it would in fact be better to have
it always, but say that the svcb-dns protocol does not demand it.

For (2) it's entirely possible I'm missing something - please let me
know. Thanks!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 7 Apr 2021 20:36:14 -0400

Thanks for the questions!  I've adjusted the text [1] to make the examples
clearer.

DoT is the "default ALPN" in this draft, so unless it is explicitly removed
(by no-default-alpn), it is present, and uses port 853 unless "port-..." is
specified.  This is good for compactness but can be surprising, which is
why I used that example.

I removed the "echconfig" from the examples, as that is not the focus of
this draft (and isn't even mentioned in the text).

[1]
https://github.com/bemasc/svcb-dns/commit/f61c70ed02b550613fdbb37d3171ab1e6d359e2c

On Wed, Apr 7, 2021 at 4:32 PM Peter van Dijk <[email-masked]>
wrote:

> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 08 Apr 2021 09:38:41 +0200

Hi Ben,

thanks for that. Sadly, I still needed help from two other people to
understand how DoT over 853 came out of this set. (One of them
commented on your commit too.)

(For those reading along still confused, it's this bit:

        SVCB 1 @ alpn=h2,h3 dohpath=/dns-query{?dns}

Because it does not say 'no-default-alpn', it actually means
'alpn=dot,h2,h3' where the dot bit ignores the dohpath.)

I think this could be even more explicit in the draft (I'm happy to
think about some words for that) but I really wonder if the space
savings are worth the confusion at all.

On Wed, 2021-04-07 at 20:36 -0400, Ben Schwartz wrote:
> Thanks for the questions!  I've adjusted the text [1] to make the examples clearer.
> 
> DoT is the "default ALPN" in this draft, so unless it is explicitly removed (by no-default-alpn), it is present, and uses port 853 unless "port-..." is specified.  This is good for compactness but can be surprising, which is why I used that example.
> 
> I removed the "echconfig" from the examples, as that is not the focus of this draft (and isn't even mentioned in the text).
> 
> [1] https://github.com/bemasc/svcb-dns/commit/f61c70ed02b550613fdbb37d3171ab1e6d359e2c
> 
> On Wed, Apr 7, 2021 at 4:32 PM Peter van Dijk <[email-masked]> wrote:

Kind regards,

---

From: David <[email-masked]>
Date: Thu, 8 Apr 2021 08:07:36 -0600

> 'alpn=dot,h2,h3' where the dot bit ignores the dohpath.)

As one of these people I will also echo this seems confusing and 
surprising. A casual observer of these records would need to carefully 
read and understand the draft to realize what it actually does, and 
apparently it took some of us a while to get to that. Having it be 
explicitly required or perhaps iterated more in examples would be good.

I will also point out this would also have DoT clients sending an alpn 
of 'dot' where I believe they do not today. Peter did some testing and 
sounds like that wouldn't really be an issue - but I haven't been 
following closely so not sure if this was brought up before.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Apr 2021 11:05:47 -0400

OK, I've clarified (and corrected, oops) the explanation of the examples,
and added another one to highlight the default-DoT behavior:
https://github.com/bemasc/svcb-dns/commit/e59c995fa976a19b5baf1770afb231d3dcb729e1

We can certainly remove the default ALPN, but personally I like having
empty SvcParams correspond to a common default.  The size savings (~8
bytes) are probably not important, although MTU could become relevant in
the context of SVCB delegation responses as envisioned
by draft-rescorla-dprive-adox.

On Thu, Apr 8, 2021 at 10:07 AM David <[email-masked]> wrote:

> >> DoT is the "default ALPN" in this draft, so unless it is explicitly
> removed (by no-default-alpn), it is present, and uses port 853 unless
> "port-..." is specified.  This is good for compactness but can be
> surprising, which is why I used that example.
> >>
> >> I removed the "echconfig" from the examples, as that is not the focus
> of this draft (and isn't even mentioned in the text).
> >>
> >> [1]

---

From: David <[email-masked]>
Date: Thu, 8 Apr 2021 10:01:06 -0600

> https://github.com/bemasc/svcb-dns/commit/e59c995fa976a19b5baf1770afb231d3dcb729e1

I think this definitely helps. Would you be opposed to one more example 
of a DoH-only endpoint? I think that would be a common use case and 
having the DoT+DoH vs DoH-only examples would provide extra enforcement 
of there being a default.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Apr 2021 13:50:52 -0400

OK, I added a DoH-only example:
https://github.com/bemasc/svcb-dns/commit/3e6614d859355a96bc459bc8c4269d13f1d330e9

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 09 Apr 2021 09:36:50 +0200

Hi Ben,

thank you for adding all those examples, this should unconfuse many
readers.

(I picked this email to reply to, instead of end of thread, because I'm
typing something more inline below).

On Thu, 2021-04-08 at 11:05 -0400, Ben Schwartz wrote:
> OK, I've clarified (and corrected, oops) the explanation of the examples, and added another one to highlight the default-DoT behavior: https://github.com/bemasc/svcb-dns/commit/e59c995fa976a19b5baf1770afb231d3dcb729e1
> 
> We can certainly remove the default ALPN, but personally I like having empty SvcParams correspond to a common default.  The size savings (~8 bytes) are probably not important, although MTU could become relevant in the context of SVCB delegation responses as envisioned by draft-rescorla-dprive-adox.

I think this one hits the core of the problem for me. I'm not confused
about what -empty- SvcParams mean. I am (well, I was) confused by
alpn=h2,h3 meaning alpn=dot,h2,h3.

So I wonder if having a default, but alpn= always *replacing* that
default instead of appending to it, might make more sense. It certainly
feels clearer to me.

In terms of packet size, some records may spend four more bytes on
'dot,' because they do combine it with DoH in one SVCB record. Other
records will spend a few bytes less on not needing no-default-alpn. I
don't know how this balances out in the end.

Kind regards,

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Apr 2021 06:15:23 -0700

On Fri, Apr 9, 2021 at 12:37 AM Peter van Dijk <[email-masked]>
wrote:

> > OK, I've clarified (and corrected, oops) the explanation of the
> examples, and added another one to highlight the default-DoT behavior:
> the context of SVCB delegation responses as envisioned by
> draft-rescorla-dprive-adox.
>

I agree. Merging default with provided is a surprising behavior. If there
is a provided ALPN it should replace the default.

-Ekr

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 9 Apr 2021 10:50:46 -0400

On Fri, Apr 9, 2021 at 9:16 AM Eric Rescorla <[email-masked]> wrote:

>
>
> On Fri, Apr 9, 2021 at 12:37 AM Peter van Dijk <
> [email-masked]> wrote:
>
...

> is a provided ALPN it should replace the default.

This behavior was chosen for SVCB primarily due to concerns about 'alpn=h3'
in the HTTPS context.  Without the merge-default behavior, 'alpn=h3' would
(in some cases) result in clients failing the connection if QUIC is
blocked, and not falling back to TCP (because no TCP-compatible ALPN is
advertised).  Some participants viewed this as a serious "footgun", because
H3-only configurations will generally appear to work in testing but result
in an outage when deployed, and other participants felt it was important to
support H3-only endpoints, so we attempted to make it hard to do this by
accident (but still possible if you really want).

SVCB is in WGLC in DNSOP, so if you think this compromise is not
reasonable, we should probably discuss it there.

>> default instead of appending to it, might make more sense. It certainly
The interpretation of "alpn" and "no-default-alpn" is currently specified
to be protocol-independent in SVCB.  We could override this in the DNS
mapping (e.g. "for DNS, no-default-alpn is not used, and the ALPN is 'dot'
if the alpn key is absent").  Making use of this key subtly different in
each mapping makes me sad, and might make it harder to share code for
handling the ALPN set, but it is possible.

Setting "dot" as the default ALPN seems logical to me.  However, I think it
would also be reasonable to say that there is no default ALPN, because DoT
is not a well-established default for encrypted DNS, in the way that
HTTP/1.1 over TLS is for HTTPS.

>> don't know how this balances out in the end.
I expect that most encrypted DNS servers will implement DoT, especially in
ADoT contexts where size is a concern, so I think the record size question
will favor the current model.  However, I don't think this is a major
concern.

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 09 Apr 2021 18:37:33 +0200

Hi Ben,

On Fri, 2021-04-09 at 10:50 -0400, Ben Schwartz wrote:
> > On Fri, Apr 9, 2021 at 12:37 AM Peter van Dijk <[email-masked]> wrote:
> > 
> ... 
> > I agree. Merging default with provided is a surprising behavior. If there is a provided ALPN it should replace the default.
> > 
> 
> This behavior was chosen for SVCB primarily due to concerns about 'alpn=h3' in the HTTPS context.  Without the merge-default behavior, 'alpn=h3' would (in some cases) result in clients failing the connection if QUIC is blocked, and not falling back to TCP (because no TCP-compatible ALPN is advertised).  Some participants viewed this as a serious "footgun", because H3-only configurations will generally appear to work in testing but result in an outage when deployed, and other participants felt it was important to support H3-only endpoints, so we attempted to make it hard to do this by accident (but still possible if you really want).

Somebody said to me 'but it is exactly like in HTTPS' - my response was
'it would be if the default alpn was do53, not dot'.

> SVCB is in WGLC in DNSOP, so if you think this compromise is not reasonable, we should probably discuss it there.

Making it hard to accidentally drop https/1.1 makes sense to me, so the
compromise is reasonable.

Making it easy to accidentally include dot does not make sense to me,
so the compromise is not reasonable (as long as the default alpn is
dot).

> The interpretation of "alpn" and "no-default-alpn" is currently specified to be protocol-independent in SVCB.  We could override this in the DNS mapping (e.g. "for DNS, no-default-alpn is not used, and the ALPN is 'dot' if the alpn key is absent").  Making use of this key subtly different in each mapping makes me sad, and might make it harder to share code for handling the ALPN set, but it is possible.

I also don't like making the -logic- protocol dependent, and agree we
should avoid that when possible.

> Setting "dot" as the default ALPN seems logical to me.  However, I think it would also be reasonable to say that there is no default ALPN, because DoT is not a well-established default for encrypted DNS, in the way that HTTP/1.1 over TLS is for HTTPS.

Yes! This is exactly the insight I had in an offline conversation.
These protocols are not in the same class for their respective
purposes.

So, if we say there is no default alpn, then 

means DoH, full stop. To mean what it used to mean, it would have to
say alpn=h2,h3,dot.

SVCB 2 @ port=8530

is invalid and would need alpn=dot.

SVCB 3 fooexp ( port=5353 alpn=foo no-default-alpn foo-info=... )

means what it did, with a useless no-default-alpn stanza.

I like this. Making the default alpn empty solves the confusion for
svcb-dns without affecting the https use case.

(If we go this way, it may make sense to put a few words in the parent
draft on choosing a default alpn, including the option of picking
'none', for protocols that use SVCB. I'm happy to try and write
something for that if you like.)

> I expect that most encrypted DNS servers will implement DoT, especially in ADoT contexts where size is a concern, so I think the record size question will favor the current model.  However, I don't think this is a major concern.

I expect that most encrypted DNS *services* will implement DoT; I have
a harder time predicting whether they will do so on the same IPs/names
that serve DoH, DoQ, 'fooexp'. That said, I also don't consider the
size difference between defaultalpn=dot and defaultalpn='' to be a
major concern.

Kind regards,

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 9 Apr 2021 13:27:57 -0400

OK, please review changes at
https://github.com/MikeBishop/dns-alt-svc/pull/314
https://github.com/bemasc/svcb-dns/pull/2

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 09 Apr 2021 20:50:20 +0200

Hi Ben,

> https://github.com/bemasc/svcb-dns/pull/2

That looks perfect to me, thank you. I posted one question on the svcb-dns pull.

Kind regards,