Subject: Re: [dns-privacy] [Ext] New draft on authenticated recursive <-> authoritative

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Mar 2021 05:36:17 -0800

On Sun, Feb 28, 2021 at 7:09 PM Paul Wouters <[email-masked]> wrote:

> On Thu, 25 Feb 2021, Eric Rescorla wrote:
>
> > There are (at least) three reasons:
> > 1. Semantically, TLSA does not mean "I support TLS", but rather "if you
> are to do TLS, do it this way. SVCB means something
> > different.
>
> We tried hard to make it mean "You should only use TLS", but the webpki
> people freaked out and blocked the DANE WG until this compromise was
> reached. In my opinion, any client that publishes TLSA records for a
> service means that you should reach it over TLS and hard-fail. No
> one really means "you may do TLS but if insecure cleartext is your cup
> of tea, that's fine with me too".
>

ISTM that these are the precise common semantics of the Web. I.e., it's
quite common
for hosts to be reachable over both HTTP and HTTPS, with the method of
connection
being defined by the referring URL. Indeed, they're different origins and
sometimes the
servers serve different content depending on the access method. This is one
of the things
that makes it somewhat difficult to build systems like HTTPS Everywhere.

HSTS allows the host to override this, but the basic semantic of "I offer
TLS" is
not "you must reach me over TLS"

> > No, because there are existing deployments, so we can't just retcon the
> meaning.
>
> That would be the retcon of "If you can do TLS, please prefer TLS over
> insecure cleartext" instead of the original meaning "This is my TLS. It
> is secure but you are welcome to use this completely insecure
> version instead - I claim no preference"
>

I'm not quite sure what you mean by "original" meaning, but the relevant
meaning
is what's encoded in the specifications.

I don't necessarily object to having this be TLSA, but given that we are
standardizing
a record whose precise purpose is to signal what services are available at
a given
location, it seems to me natural to use that.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Mar 2021 15:28:56 +0000

On Mar 1, 2021, at 5:36 AM, Eric Rescorla <[email-masked]> wrote:
> I don't necessarily object to having this be TLSA, but given that we are standardizing
> a record whose precise purpose is to signal what services are available at a given

+1. I used TLSA because PaulW had proposed it and no one objected to the proposal, but a new purpose-built signal seems fine.

Having said that, I'm a bit hesitant if that new signal also recreates TLSA semantics for the public key, given how hard it was for the DANE WG to settle on those, but maybe it won't be so rough this time (or maybe we can use TLSA for the public key info).

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Mar 2021 10:46:55 -0500 (EST)

>> location, it seems to me natural to use that.

I can't fully parse the sentence.

> +1. I used TLSA because PaulW had proposed it and no one objected to the proposal, but a new purpose-built signal seems fine.

Note that I did not object to TLSA. I prefer it over SVCB. I don't think
it is realistiv for any new kind of glue record to be invented and that
seemed to have been the reason in the proposal to use SVCB? To serve
it at the parent side of the zone cut?

Another reason for SVCB was that you can define the transports in one
place, instead of having them _prefix'ed at different places for TLSA.
And as a method to specify DoH. I don't think these are an issue because
DoH is a bad fit for this solution anyway as previously discussed. So
it would be just querying for the DoT or DoQ port number per nameserver.

In the case of DNS it is clear that no one will disable port 53 if a
TLSA record is there, and I'm sure the final document will reflect
that.

> Having said that, I'm a bit hesitant if that new signal also recreates TLSA semantics for the public key, given how hard it was for the DANE WG to settle on those, but maybe it won't be so rough th…

If the DNSSEC PKI is used, I think the semantics for Usage and Selector
are obvious. In the case of WebPKI, it can be as weak as people want? Eg
putting a TLSA record there for the LetsEncrypt CA. I wouldn't limit it
to enforce it to be the Selector for SBKI.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Mar 2021 08:00:16 -0800

> I can't fully parse the sentence.

Rephrased: TLSA might work, but given that SVCB is designed for this
purpose,
my prior is to favor it.

> > +1. I used TLSA because PaulW had proposed it and no one objected to the
> proposal, but a new purpose-built signal seems fine.
>

I do think serving this at the parent side of the zone cut is a good idea,
but that's not the reason for SVCB.

> DoH is a bad fit for this solution anyway as previously discussed.

I don't necessarily agree that DoH is a bad fit. I just don't see any point
in arguing
about it, because I think SVCB is better for other reasons.

> Having said that, I'm a bit hesitant if that new signal also recreates
> TLSA semantics for the public key, given how hard it was for the DANE WG to
> settle on those, but maybe it won't be so rough this time (or maybe we can
> use TLSA for the public key info).
>

As has been discussed extensively, the general feeling among people who
work with
the WebPKI is that pinning has turned out to be a bad idea. For this
reason, it's
important to be able to have an available way to say "just use the WebPKI",
even
if it's also possible to be more specific.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Mar 2021 11:32:35 -0500 (EST)

On Mon, 1 Mar 2021, Eric Rescorla wrote:

> Rephrased: TLSA might work, but given that SVCB is designed for this purpose,
> my prior is to favor it.

Thanks, that clarified it for me.

> but that's not the reason for SVCB.

You would need to write an RFC for the EPP extension. You would need to wait
for most TLD's EPP systems to support this new record. Then you need to
wait for Registrars to update their EPP software. Then you need to wait
for Resellers like OpenSRS to update their software to resellers.

Then you need to write an RFC on adding SVCB records to a parent zone so
that current DNS software doesn't immediately reject it as out-of-zone
data. Then you need to push opensource implementors. Then you need to
push TLDs to deploy, and the big DNS appliance vendors. Then you have to
wait for old DNS products to be updated or replaced at the enterprise.

That's a 5-10 year time line. You would need an interim solution. If you
have such a solution, there is even less incentive to get this work done.

> As has been discussed extensively, the general feeling among people who work with
> the WebPKI is that pinning has turned out to be a bad idea. For this reason, it's
> important to be able to have an available way to say "just use the WebPKI", even

DNS is not the web. DNSSEC already "pins" via the DS record in a
hierarchical way with DNSKEYs. Adding another public key here is
not that different.

Reducing the hierarchical security of DNS (with or without DNSSEC) by
replacing it with what is defacto the LetsEncrypt Root CA seems a bad
idea. If you plan to use this new sentinel without any kind of public
key, then this proposal is yet another workaround to hack WwebPKI into
somewhere where it doesn't belong or fit, and I must object.

I don't know what (cc)TLD operator's opinions and rules are on having
their nameserver public key verification operation subjected to a single
California non-profit organization. And all the anti-DNSSEC people who
objected to a single root key would have a similar problem here as well.

So I guess we might be looking at two different standards then. One that
uses the advantage of the DNS hierarchy with DNSSEC based on TLSA, and
one that flattens the DNS hierarchy using an SVCB for WebPKI.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 1 Mar 2021 17:50:00 -0800

On Mon, Mar 1, 2021 at 8:32 AM Paul Wouters <[email-masked]> wrote:

> >       > +1. I used TLSA because PaulW had proposed it and no one
> objected to the proposal, but a new purpose-built
> >       signal seems fine.
> >

> have such a solution, there is even less incentive to get this work done.

This seems like something to discuss live in the session, but at a high
level,
one doesn't need universal deployment to get value here. Given the relative
concentration of both a small number of high value TLDs and large-scale
authoritative nameservers, we should be able to get *some* encryption
fairly quickly even if the long tail takes a while.

> hierarchical way with DNSKEYs. Adding another public key here is

Given the low rate of DNSSEC deployment and the high rate of
misconfiguration
(https://dl.acm.org/doi/pdf/10.1145/3131365.3131373) I don't find this
particularly
encouraging.

> somewhere where it doesn't belong or fit, and I must object.

Sounds like a good discussion to have in the meeting.

I'm not sure why this has to be a war between WebPKI and DNSSEC.
Our for this draft is to give the nameserver the choice of how to
authenticate,
I appreciate that you feel that it would be better to root the security of
ADoT
in DNSSEC, but given that we effectively have no ADoT now, ISTM that our
first priority should be to get some. If that turns out to be substantially
easier to deploy with WebPKI, then that's what we should do. If on the
other hand, rooting it in the DNSSEC turns out to be better, then we should
do that. Specifying a mechanism which allows people to do both will
let us find out, rather than letting the best be the enemy of the good.

 -Ekr

---

From: Rob Sayre <[email-masked]>
Date: Mon, 1 Mar 2021 17:58:49 -0800

> (https://dl.acm.org/doi/pdf/10.1145/3131365.3131373) I don't find this

I tend to just ignore DNSSEC arguments. Whatever its merits, there must be
something about DNSSEC that doesn't work.

thanks,
Rob

---

From: Erik Nygren <[email-masked]>
Date: Mon, 1 Mar 2021 23:13:15 -0500

See also Tim April's draft for an SVCB-based NS2 record:

https://tools.ietf.org/html/draft-tapril-ns2-01

It has quite a bit of similarity to this latest draft, but differs in a
number of ways
based on a bunch of discussions we had last year to refine something that
worked well with common operational models and DNSSEC.

I'd be interested in seeing something that was a convergence of Tim's NS2
draft
and this draft from ekr.  (Tim who thought about this lots last year will
hopefully
jump into this conversation later this week.)

     Erik

On Sat, Feb 27, 2021 at 12:51 PM Ilari Liusvaara <[email-masked]>
wrote:

> On Thu, Feb 25, 2021 at 01:25:25PM -0800, Eric Rescorla wrote:
> > On Thu, Feb 25, 2021 at 1:10 PM Paul Hoffman <[email-masked]>
> wrote:
> >
> > > On Feb 25, 2021, at 12:44 PM, Eric Rescorla <[email-masked]> wrote:
> > >
> > > On Thu, Feb 25, 2021 at 12:15 PM Paul Hoffman <[email-masked]>
> > > wrote:
> > >
> > >> The idea of doing discovery in a new type of glue in the parent seems
> > >> interesting. For the unauthenticated use case, it potentially removes
> a
> > >> round trip, and doing so is quite valuable. If the WG likes the idea
> of
> > >> new-glue-type-in-parent, Peter and I can add it to the draft covering
> > >> unauthenticated ADoT to keep the two use cases in sync.
> > >>
> > >> Question: why does this draft use an SVCB record instead of a TLSA
> record
> > >> for that new glue? The only advantage I see is that SVCB can indicate
> the
> > >> DoH template, but the WG has so far not shown interest in DoH over
> DoT.
> > >
> > >
> > > are to do TLS, do it this way. SVCB means something different.
> > >
> > >
> > > Fair point. However, given that we get to say what a particular usage
> of a
> > > particular RRtype is, that is not fatal.
> > >
> >
> I still think that there should be new RRTYPE that lives in nsname node
> and carries service info. Putting it anywhere else means it can get out
> of sync. Not that it is fully coherent even then, but at least one could
> get rid of most coherence issues.
>
> > > 2. It's not clear that the certificate binding properties of TLSA are
> > > desirable in the glue in this case, for a number of reasons, including
> the
> > > "getting out of sync" problem that Ben Schwartz pointed out, and the
> > > possibility that  we will want to use WebPKI.
> > >
> > The document is intended to be agnostic about WebPKI versus TLSA. Can you
> > point out what makes you think it favors it?
>
> I also read the document as seemingly preferring WebPKI (through not
> explicitly saying so).
>
> My views of using WebPKI being a very bad idea have not changed:
>
> - WebPKI does not support service scoping.
> - WebPKI fundamentially relies on DNS authoritatives, causing circular
>   dependency if used for DNS recursive<->authoritative communications.
> - WebPKI has the rootstore mess.
> - Using WebPKI would cause issues to both DNS system and WebPKI itself,
>   due to change mismatch.
>
> > In any case, it's quite different to have the TLSA records in the parent
> > and in the server, because the server can ensure they don't get out of
> sync
> > with itself in a way that is harder than with the parent.
>
> All the possibilities of relation between child, parent and nsname are:
>
> 1) Nsname is in child zone
> 2) Nsname is in descendant of child zone.
> 3) Nsname is in parent zone
> 4) None of the above.
>
> - Cases 1) and 2) need glue.
> - Both 1) and 4) are common.
> - gTLDs look to be limited to either 2) or 4).
> - ccTLDs can do whatever they want, and at least some do 1).
>
> And it is the nsname node that currently carries the IP addresses of the
> nameserver (A/AAAA records).
>
> And it is not obvious to me that contacting nameserer in the clear to
> obtain its encrypted transport information (in case child is
> authoriative for its nsname) blows the cover: There is no obvious to
> me way to tell if it is in-zone nameserver or out-zone nameserver of
> another zone. And I consider nsnames as blown anyway.
>
>
> > > 2. SVCB does not just let you signal DoH versus DoT it also allows you
> to
> > > signal DoQ, which has obvious advantages.
> > >
> > >
> > > TLSA also lets you signal DoQ. If it didn't, we would have rejected it
> out
> > > of hand.
> > >
> >
> > I think it depends what you mean by "signal". TLSA can signal the
> > certificate which is to be expected for a QUIC connection, but AFAICT it
> > has no way to indicate that the server supports QUIC, whereas with SVCB
> you
> > can do this with ALPN (h3, doq). Your draft has a TODO here, so I'm not
> > sure what you have in mind.
>
> I think that allowing signaling DoH versus DoT and DoH3 versus DoQ is
> unnecressary, as DoH(3) seems to only bring complexity over DoT/DoQ,
> seemingly without any significant benefits. And I consider already the
> complexity of DoQ scary.
>
> - The traffic stands out like sore thumb due to endpoints involved.
> - Without server push, DoT and DoH have the same capabilties: out-
>   of-order request-response on stream transport.
> - Server push is effectively dead, and the only thing it would add is
>   allowing sending negative responses without DNSSEC (with suitably
>   advanced resolved). But it would be easy to add capability to send
>   negative responses to DNS, and such capability would be useful outside
> - Similarly, without server push DoQ and DoH3 have the same
>   capabilities: full out-of-order request-response. Not sure if HTTP/3
>   has server push, but if it does, what it adds would be the same as
>   in HTTP/2 case.
>
> There may be need for simpler transport optimized for low resource use,
> only intended for transporting DNS QUERY messages and their responses.
>
> > > In addition, if it becomes necessary to signal what kind of credentials
> > > the server has. SVCB has a natural way to add that.
> > >
> > > Well, you said that in your draft, but I don't see that as a
> possibility
> > > in Ben's draft. It could be added, but there is no extension mechanism
> > > there.
> > >
> >
> > Huh? You just define a new SvcParamKey:
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-03#section-14.3
>
> The kinds of credentials I see as possibly useful:
>
> - No credentials (oppurtunistic-only)
> - Server will staple its credentials with DNSSEC chain/signature.
>   (there should be only one mechanism for this, e.g. subset of
>   draft-dukhovni-tls-dnssec-chain).
> - Hash of server hostkey.
> - Hash of self-signed root certificate.
>
> And there is obviously issues with trusting values if this information
> is not protected with DNSSEC, including the case where records are sent
> as glue, as glue is never signed.
>
>
>
> -Ilari
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 02 Mar 2021 15:50:07 +0100

On Wed, 2021-02-24 at 14:06 -0500, Paul Wouters wrote:
> 
> It seemed the DS record idea stalled, because the authors didn't really
> like the additional RTTs needed. 

You have been repeating that we actively refuse to deal with the
additional RTTs. This is untrue and unfair to the point of rudeness. We
have repeatedly stated being open to this child verification, if the WG
had interest, but it did not - only you. Now repeating that claim
again, and even stretching it to be the reason the draft stalled, is
hard to explain other than as some confused arrogance.

DOTPIN stalled because people, quite rightfully, did not like the idea
of putting a pin for one NSset in the DS records for a million domains.
All other concerns (such as deciding the exact level of protocol abuse
DOTPIN is) are minor in comparison.

A later informal proposal to make that the registry's problem (
https://mailarchive.ietf.org/arch/msg/dns-privacy/xOVfHOR6FFFPxsFqM8eB44J-Db0/
) never made it into a draft, because at the time it did not seem like
the right direction for the WG.

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 2 Mar 2021 11:09:20 -0500 (EST)

On Tue, 2 Mar 2021, Peter van Dijk wrote:

> have repeatedly stated being open to this child verification

It was not my impression the authors were open to it. That is good to
know. Since from what I saw, the discussion stopped here, I thought
the two were related. I'm happy to hear it is not, but also sad to
hear there are other reasons for the document being given up. My
apologies for misinterpreted the situation.

> if the WG had interest, but it did not - only you.

That is not really how security considerations work. I explained that
without it, you would create a TLD scale MITM. You can't ignore that
because you don't like an extra RTT.

> DOTPIN is) are minor in comparison.

Fair enough. Unfortuantely, it seems we are now pushed to another pin,
that being LetsEncrypt Root CA :/  Which in itself depends on (insecure)
DNS. Seems the worst of both worlds.

Paul

---

From: Puneet Sood <[email-masked]>
Date: Mon, 8 Mar 2021 21:00:15 -0500

[late to the discussion, so putting my responses here instead of as
replies to various threads]

* Use of SVCB vs TLSA for signaling secure transport support.
Preference for SVCB since it is specifically meant to represent
transport endpoints and could be extended to new transports,
additional info in the future (DoQ or others).

* Publishing SVCB records in the parent zone in addition to the child zone.
The example used in the draft, shows an out-of-bailiwick SVCB record
returned by the parent nameserver in a response to the resolver. The
benefit of this is saving 1RTT to query the child zone and the
information being more trustworthy w/o depending DNSSEC in the child
zone.

- This is the kind of record that a resolver will discard since it is
out-of-bailiwick. Best reference I could find is the description of
bailiwick in https://datatracker.ietf.org/doc/html/rfc8499.
- Ignoring this issue, if the resolver were to accept the SVCB record
in glue from the parent zone, the information to be saved per zone ->
name server mapping will go up significantly since there is now an
SVCB record in addition to the NS record. If the SVCB information is
tied to the nameserver name, then it needs to be saved only once per
name server or name server set.

* Use of DNSSEC vs WebPKI for authentication.
No opinion on this matter - leave it to experts on this topic.

Clarification question for Eric: You have mentioned elsewhere in this
thread that you expect the protocol will allow both/either DNSSEC and
WebPKI to be used by an operator. Is the expectation that recursive
resolvers will support *both* mechanisms early on? Otherwise if a
resolver supported DNSSEC authentication only while the nameserver for
a zone supported WebPKI only, the two won't be able to communicate
securely.

* Authenticating data from root.
For operators willing to do it, running a local root server
(https://www.rfc-editor.org/rfc/rfc8806.html) is a possible solution
to this problem.

-Puneet

On Tue, Feb 23, 2021 at 7:21 PM Eric Rescorla <[email-masked]> wrote:
>
> Hi folks,
>
> I wanted to point people to a new draft by Tommy Pauly, David
> Schinazi, Chris Wood, and myself that defines a mechanism
> for authenticated resolver<->authoritative communication.
>
> At a high level, the design is to use SVCB to indicate that
> a given server supports ADo[THQ]. The expectation is that
> the SVCB record would be supplied in additional_data along
> with the NS records, allowing you to bootstrap to encrypted
> transport without incurring additional transport. More details
> in the draft, but a few points might be worth fleshing out
> here:
>
> - The basic assumption is that the transport to the parent [0]
>   is encrypted, thus preventing attackers from substituting
>   NS or SVCB [1].
>
> - The draft is agnostic on how the authorative server, and
>   is compatible with either TLSA or WebPKI, though there
>   are some details to be worked out if we don't mandate
>   one or the other.
>
> We missed the draft deadline, so in the meantime the draft can be
> found at:
>
> https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
> https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.txt
>
> Comments welcome, etc.
>
> -Ekr
>
> [0] The root may be somewhat tricky here, but there are
> some thoughts in the draft.
> [1] For reasons laid out in the draft, if this isn't the
> case, I'm not sure it's possible to avoid leaking the name
> you are resolving, even with DNSSEC.

---

From: Puneet Sood <[email-masked]>
Date: Mon, 8 Mar 2021 21:00:49 -0500

On Mon, Mar 1, 2021 at 8:51 PM Eric Rescorla <[email-masked]> wrote:
> This seems like something to discuss live in the session, but at a high level,

Citation needed - are there high value TLD operators that have
publicly stated that they are planning to support AuthDoT mechanisms
in the short/medium term?

> Given the low rate of DNSSEC deployment and the high rate of misconfiguration
> (https://dl.acm.org/doi/pdf/10.1145/3131365.3131373) I don't find this particularly
> encouraging.

Without commenting on the benefits of using DNSSEC or WebPKI, a more
up-to-date reference would be
https://www.internetsociety.org/deploy360/dnssec/statistics/ and
linked page from there: http://www.secspider.net/growth.html which
shows about 10x increase in DNSSEC adoption between 2017 and 2021.
Some ccTLDs (SE, NL) have a high DNSSEC adoption rate.

> Our for this draft is to give the nameserver the choice of how to authenticate,
> I appreciate that you feel that it would be better to root the security of ADoT

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Mar 2021 18:39:02 -0800

> name server or name server set.

Yes, I would it expect it to use it for this request but not cache it.

> a zone supported WebPKI only, the two won't be able to communicate

I think we'd need to sort this out. The minimum requirement, I think,
is to allow the SVCB record to indicate what the authoritative supports,
so you don't get downgrade. If you have that, then both sides can
vote with their feet and we can see what is most deployable.

-Ekr

---

From: Puneet Sood <[email-masked]>
Date: Mon, 8 Mar 2021 22:07:11 -0500

> Yes, I would it expect it to use it for this request but not cache it.

And what about the next query for records in the same zone? If it is
not cached, either another query to parent is required; or the
resolver uses cached SVCB information from the nameserver name record
which can be different from what the glue provided.

-Puneet

> vote with their feet and we can see what is most deployable.

So the auth server gets to choose. Can we confirm that the resolver
also has a choice on what mechanism to use?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Mar 2021 22:30:53 -0500 (EST)

> Yes, I would it expect it to use it for this request but not cache it.

I already brought up the fact that SVCB records cannot be served by
parents because the EPP infrastructure and software updates just aren't
there for such a change and won't magically appear in the next several
years to decade. It is really a non-starter.

But adding rules to resolves to treat some resolving paths different
from other paths is not a good design and hard to implement. It also
goes against various RFCs regarding using TTLs etc.

> vote with their feet and we can see what is most deployable.

That's the core problem yes. And the ideas that have come up boil down to:

- Convey via DNSKEY / DS records - but this requires DNSSEC
- Convey via special named NS record (just signal and/or with pubkey/hash)
   (dangerous because the glue isn't signed/authenticated)
- New RRtype about child zone published at parent (non-starter)
- Via TLSA/SVCB at the nameserver name (not child zone name) (and give up
   on protecting zones containing their own nameservers in bailiwick)
- Try opportunisticly and do negative/positive caching of nameserver results
   (with or without tls-dnssec extension)

The key questions are:

- Is encrypted DNS a property of the _zone_ or a property of the _nameserver_ ?
- Can the indicator for encrypted DNS for a _zone_ live in the parent zone ?
- Can the indicator for encrypted DNS for a _zone_ live in the child zone ?
- Can the indicator for encrypted DNS for a _nameserver live in the child zone ?
- Are zone indicators flags or pins ?
- Are nameserver indicators flags or pins ?

Paul