Subject: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

From: Peter van Dijk <[email-masked]>
Date: Tue, 19 May 2020 11:24:30 +0200

Hello DNS privacy people,

please find below all details about our proposal for enabling DoT from
resolver to authoritative.

This work is based on Manu Bretelle's presentation in Prague over a
year ago, after which we spent a lot of time figuring out how to
squeeze the DoT signal and key pin into the constraints of DNSKEY/DS
records.

We have some running code (linked in the draft) to show feasibility of
the approach.

The draft is managed on GitHub in .md format at 
https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin

Looking forward to your comments,
Peter, Manu & Robin

-------- Forwarded Message --------
From: [email-masked]
To: Peter van Dijk <[email-masked]>, Emmanuel Bretelle <
[email-masked]>, Robin Geuze <[email-masked]>
Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds-
dot-signal-and-pin-00.txt
Date: Tue, 19 May 2020 02:18:23 -0700

A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:		draft-vandijk-dprive-ds-dot-signal-and-pin
Revision:	00
Title:		Signalling Authoritative DoT support in DS records, with key pinning
Document date:	2020-05-19
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/
Htmlized:       https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vandijk-dprive-ds-dot-signal-and-pin

Abstract:
   This document specifies a way to signal the usage of DoT, and the
   pinned keys for that DoT usage, in authoritative servers.  This
   signal lives on the parent side of delegations, in DS records.  To
   ensure easy deployment, the signal is defined in terms of (C)DNSKEY.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 May 2020 11:51:44 +0200 (CEST)

> resolver to authoritative.

Thanks, interesting approach.

Some thoughts...

"If the DoT connection is unsuccessful or the public key
    supplied the server does not match one of the DS digests, the
    resolver MUST NOT fall back to unencrypted Do53."

Can we somehow make this behavior configurable by means of a flag (or 
something) by the domain holder? To say if fallback is ok or not?

Also, when I want to roll keys, can I specify multiple keys during this 
key roll period?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 19 May 2020 10:56:12 +0100

> Name:		draft-vandijk-dprive-ds-dot-signal-and-pin

It's almost-but-not-quite DANE, and a TLSA record.  Why (not)?
-- 
Cheers,
  Jeremy

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 May 2020 11:46:20 -0400 (EDT)

> https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin

This is ..... interesting.

We first added the KEY RRTYPE in the 1990's to allow generic public
keys in DNS. Then the DNS (and CA) people got upset at the KEY record
being used for something else than securing DNS. So KEY was obsoleted
for DNSKEY that signified it is for DNSSEC only.

This draft now tries to shoehorn a TLS key into the DNSKEY record.

A much cleaner solution would be to use a proper TLSA record. If you
want to signal securely within DNSSEC that encrypted DNS is available,
use a DNSKEY flag on the existing DNSKEYs to signal that (similar to
the DELEGATION_ONLY flag). You only need 1 bit and TLSA records - which
are port specific - can be used to signify presence of DoT or DoH. Or
if you want to support both on port 443 for middleware circumvention,
you can use _dot and _doh prefixed (eg _443._dot.nohats.ca IN TLSA <blob>

The TLSA records can also be of different types, so you can pin the TLSA
record to a pubkey, certificate or specific CA. This would allow the DoH
or DoT maintainer to change/update their keys witout needing to update
or have access to the DNSSEC signer to update the DNS.

Let's not create "pseudo DNS records".

Paul

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 20 May 2020 15:55:48 +0200

> Thanks, interesting approach.

Thanks!

> something) by the domain holder? To say if fallback is ok or not?

Yes, we have imagined a few ways to make that possible:

* careful use of DNSKEY flags
* a special DNSKEY value ('empty')

But we've had trouble figuring out a decent use case for allowing the
fallback.

With my 'resolver developer' hat on, I don't want probing/fallback code
in the hot resolution path, it adds complexity and hurts performance.

> Also, when I want to roll keys, can I specify multiple keys during this 

Yes, specifying multiple keys (i.e. placing multiple DS records) is allowed. This is necessary because separate NSes might have different keys, and conveniently this enables key rolling as well.

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

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 20 May 2020 16:12:49 +0200

> It's almost-but-not-quite DANE, and a TLSA record.  Why (not)?

I've thought about many ways to use actual TLSA records, and have read previous drafts and proposals in emails to this group. None of it seemed satisfactory to me.

There are some terse and biased notes in https://github.com/PowerDNS/parent-signals-dot/blob/master/README.md - happy to elaborate on anything I wrote in there.

(There's a side-issue with TLSA, depending on how you use it: in many TLSA 'modes', you are expected to confidently know the name of the thing you are connecting to. NS records in delegations are not signed, so if you misdesign something based on TLSA, you could end up connecting to ns.attacker.example with its entirely valid key/certificate.)

Kind regards,

---

From: Petr Špaček <[email-masked]>
Date: Thu, 21 May 2020 09:59:59 +0200

> https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin

I support this.

It is hacky but has very nice properties which are not explicitly described in the document:
- It does not require any extra round-trips to determine if DoT is supported on the auth side.
- Is downgrade-resistant.
- Potentially closes all cleartext leaks (if parent domains are also secured).
- DS "compatibility" makes it deployable in practice.
- CDS/CDNSKEY makes management from auth side easier.

Personally I think any proposal which requires major protocol changes (e.g. new parent-side record type) will take many years to get deployed, so this seems like feasible way forward.

Petr Špaček  @  CZ.NIC

---

From: Peter van Dijk <[email-masked]>
Date: Sat, 23 May 2020 19:59:39 +0200

> for DNSKEY that signified it is for DNSSEC only.

And we are forever stuck with a '3' that I keep forgetting the meaning
of :)

> you can use _dot and _doh prefixed (eg _443._dot.nohats.ca IN TLSA <blob>

As I remarked in my reply to Jeremy, I spent quite some time thinking
about how to do the signalling&pinning with actual TLSA records, but I
never ended up with a satisfactory solution. 
https://github.com/PowerDNS/parent-signals-dot/blob/master/README.md
has some terse notes on fitting TLSA to this problem. Perhaps we should add similar notes to the draft in a not-for-publication section?

For your specific proposal, how would I see the DOT_TLSA flag on the
nohats.ca DNSKEY without first querying for that DNSKEY over a plain
text connection to your name servers?

Also, as Petr pointed out, our DNSKEY/DS-based proposal does not
involve additional queries and thus roundtrips; as far as I can
imagine, anything using TLSA would need extra queries.

> or have access to the DNSSEC signer to update the DNS.

In our 'emulation' (or perhaps re-syntaxing) of TLSA, we explicitly
chose to only map TLSA Certificate Usage 3, because all other forms
require that you are confident about the name of the remote end you are
connecting to. As delegation NS records are not signed, those usages
would be susceptible to attack if the TLSA records are not somehow tied
to both the delegated domain name -and- the names of its name servers. 
'_443._dot.nohats.ca' (ignoring, for a moment, that it lives in the
child zone and thus is not available when the resolver needs it for
safely connecting to the nohats.ca name servers) does not tie itself to
the names of the name servers, and thus cannot support anything other
than TLSA Certificate Usage 3.

Of course, I've had to read between the lines of your proposal a bit,
as it was specified very tersely. If you, or somebody else, comes up
with a fully fleshed out proposal based on TLSA, I would be very
interested in reading it! 

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 May 2020 13:43:26 -0400 (EDT)

> never ended up with a satisfactory solution.

But I don't think your current solution is satisfactory either. It is
basically the same thing we told djb about dnscurve - you cannot abuse
an RRtype for something else. Whether you put a pubkey in the NS record
LHS, or a TLS key inside a DNSKEY - you are abusing the RRtype system.

But I also don't see the gains of abusing DNSKEY, because you already
need to query the DNSKEY of the domain to get the pesudeo-DNSKEY key,
and then you already lost your privacy.

I think it is worth it to take a step back and consider what we are
trying to protect here.

If we are trying to prevent someone from seeing I am going to go to
nohats.ca, then revealing I'm querying for the DNSKEY RRset for
nohats.ca means we already failed. So I'm going to define DNS privacy
as "Prevent leaking information that I am going to domain XXXX". It
hardly matters what we query of domain XXXX. The content of the A record
is not the loss of privacy. The loss of privacy is that we were trying
to go to domain XXXX.

Let's assume we can connect to the .ca nameservers securely and
privately. We query for nohats.ca. If there is no DS, all bets
are off as the child cannot signal anything to us securely. If
there is a DS, we also got NS records, and possibly A/AAAA glue.

In the case of getting A/AAAA glue, we can connect using DoT if
we knew this was an option (eg signaled in the DS record).

In the case of getting only NS records, we would have to securely and
privately look up those records first. Let's say we get ns.example.com
and no glue, we go through another iteration of this until we get A/AAAA
glue and can connect using DoT if the DS record could have signaled
this.

If the DS record somehow conveyed "yes you can do DoT", you can now
connect to that IP on port 853 and send your query. We still need to
authenticate this TLS channel.

Conveying that you can do DoT using DS can only really be done by
overloading the record type. I don't like it, but the other other
choice we have to opportunistically just try port 853, and in 20 years
perhaps we can shut down port 53 like we are now getting ready to shut
down port 80. The opportunistic part is tricky, because it does allow
an attacker to RST/filter your 853 connection and downgrading you to
plaintext - where as if we signal this in the DS record, we could
prevent downgrade and hard fail if privacy is that important to us
that we prefer not to connect over leaking that we are trying to
connect. If we don't want to hard fail, then I think we should just
drop this draft and use opportunistic. If we want to offer hard fail,
then some draft is still useful.

I would use the keytag record set to 0 to mean this DS record is not
a real DNSKEY but "something else". Whether you need anything else
is debatable. You could use the digest field to stuff in a public key.
Then you can connect to the nameserver, and presuming that it is a
large DNS hoster like godaddy, you could verify the TLS connection
before sending your first nohats.ca related query. You can optimize
this with False Start, Session Resumption, etc.

At the child, you can leave a CDS record of the identical special DS
record at the parent, as cryptogrpahic proof that the special DS record
for DoT at the parent was actually something the child wanted its parent
to publish.  Again, this would require another round trip to confirm
that the parent wasn't sending you to a rogue nameserver. But at least
you are ensured the parent isn't running a global TLS MITM nameserver
that logs and forwards all queries.

No additional pseudo-DNSKEYs are needed.

In your draft, you cannot connect with privacy until you obtain the
base64 encoded TLS key embedded in the DNSKEY RRset. I'm saying this
is too late - you already revealed the only important bit of
information, that you are trying to visit "nohats.ca". There might
be exceptions, like subdomain.wordpress.com or subdomain.livejournal.com
but in 99% of the cases, the domain name itself is the valuable
information to keep private.

> imagine, anything using TLSA would need extra queries.

I don't believe a working solution cannot be allowed to introduce an
extra roundtrip. With the amount of CNAME's splattered all over the
world, I think trying to hack around avoiding a roundtrip is not worth
it. Especially for DNSKEY/DS records, which should not have TTL=1 and
are happilly cached for extended periods of time.

As I pointed out above. If you want to protect losing privacy to a rogue
parent, a number of additional roundtrips are required anyway. Saving
one of them isn't worth creating pseudo-DNSKEY records for.

Paul

---

From: Christian Huitema <[email-masked]>
Date: Sun, 24 May 2020 10:59:33 -0700

> we knew this was an option (eg signaled in the DS record).

Paul,

The privacy risks or gains depend on the "anonymity set", which in this
case means "all the domains served by the DNS server to which the client
is sending the query". Getting the data directly from a TLD server mixes
the query in the anonymity set of that TLD server; getting the data from
an authoritative server mixes the query in the anonymity set of that
authoritative server. Which one is largest depends on circumstances. Is
the anonymity set of .CA larger than that of Route 53, or Dyn DNS?

This brings of course the complex relationship between privacy and
centralization. One one hand, big services provide large anonymity sets.
On the other hand, these big services can track queries to lots of
domains. If the client really wants privacy, then maybe it should use
ToR or some other mixer to hide its IP address, in which case the debate
is moot.

-- Christian Huitema

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 24 May 2020 22:20:34 +0200

> and then you already lost your privacy.

The draft says 'The pseudo DNSKEY record MUST NOT be present in the
zone.' What can we add to the text to make it clear that no query is
sent to the zone's name servers -until- their TLS key has been
verified?

> authenticate this TLS channel.

In our proposal, the DS record conveys 'do DoT' and also authenticates
the TLS channel.

> overloading the record type.

Which field do you mean by 'the record type'? We chose the algorithm
field for it.

> If we don't want to hard fail, then I think we should just
> drop this draft and use opportunistic.

This draft, that signals and key-pins, with hard failure, would not
prevent an opportunistic draft/RFC to also exist.

(But, repeating myself from another reply, with my 'resolver developer'
hat on, and on behalf of our users with their 'resolver operator' hats
on, opportunistic is a software complexity and user-experienced-latency 
burden that I'm not a big fan of.)

> If we want to offer hard fail,

Why not this draft then? :)

> a real DNSKEY but "something else".

This will require changes in registry software all over the world, or
some hack . I'm not saying that's prohibitive, but our draft is the way
it is because this is one of the many hurdles we wanted to avoid.

> Whether you need anything else

We stuff the hash of the public key (with the rest of the DNSKEY format
prefixed) in the DS.

> before sending your first nohats.ca related query.

Which is exactly what the draft provides.

> base64 encoded TLS key embedded in the DNSKEY RRset.

No, that's simply not the case. Apparently the draft is unclear - can
you help us make the language better so this confusion does not occur?

> extra roundtrip.

I also do not believe that, but it's nice that we can do without the
extra roundtrip anyway!

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 May 2020 17:36:13 -0400 (EDT)

> sent to the zone's name servers -until- their TLS key has been

You confused me with "pseudo DNSKEY record". You meant to say "pseudo DS
record". Now it makes more sense that our suggestions are a lot more
similar then I originally understood.

The draft currently has:

 	The pseudo DNSKEY record MUST contain Base64 encoded [...]

 	The pseudo DNSKEY record MUST NOT be present in the zone.

Also, instead of showing openssl commands, explain to the reader the
process of the resolver. What does it fetch, when does it fetch it, what
information is extracted and used.

Your draft also state:

 	The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in
 	[RFC7344]) records.  These records MAY be present in the zone.

I think that should be a MUST, not a MAY. Or else a rogue parent
inserting DS records to MITM the TLS cannot be detected.

> Which field do you mean by 'the record type'? We chose the algorithm

I meant key tag. We have seen issues in the past with both resolver
behaviour with unknown algorithms and registries limiting their drop
down menus for DS components to only valid algorithms.
I thought using keytag 0, which cannot happen normally, would allow
you to leave algorithm and other values more real.

> prevent an opportunistic draft/RFC to also exist.

Once the document gets further along, a Security Considerations section
is needed to explain the details of pinning and how it interacts with
TLS level pinning.

> Why not this draft then? :)

Now I understand data is in the DS record, perhaps it can. It does all
depend on whether we want to add limiting on/off signaling in the DS
record only, or if we really want to stuff TLS public keys into the DS.
I'm still not convinced of the latter, but might be persuaded.

> it is because this is one of the many hurdles we wanted to avoid.

A similar problem will happen for new algorithms.

> I also do not believe that, but it's nice that we can do without the

I'd really like to get the security and threat model cleared up before
making decisions about 1 RTT. For instance, protection against a rogue
parent is not something the draft currently tries to protect against.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 25 May 2020 01:10:58 +0200

On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> record".

We chose that language because the DS record is a very real thing that
exists in the parent zone - but it is hashed from a DNSKEY record that
only exists in the memory of the resolver, and of the tooling that
sends the DNSKEY to the parent (via EPP, CDNSKEY, etc.). That's how we
meant the word 'pseudo'. We have thought about different terminology
for it, and clearly we were right to doubt ourselves about the wording.

I don't think 'pseudo DS records' covers what we are doing in, but I'm
open to suggestions for better wording.

>  Now it makes more sense that our suggestions are a lot more

That makes me very happy! This will make discussion a lot easier.

>  	The pseudo DNSKEY record MUST contain Base64 encoded [...]

That phrasing focuses on presentation format - the resolver code
wouldn't actually involve Base64.

This code from a dig-like tool adapted to the draft does not use Base64
anywhere, and the same would apply to the actual resolver process:

(handler is a TLS connection object that has connected to the remote
853 port, and performed a TLS handshake without any certificate/key
checking)

      DNSKEYRecordContent drc;
      drc.d_algorithm = dotpinalg;
      drc.d_key = handler.getPeerPubKey(); // DER, no base64 involved
      drc.d_protocol = 3;
      cerr<<drc.getZoneRepresentation()<<endl;
      // FIXME: the hardcoded 2 is bad
      auto dsrc = makeDSFromDNSKey(dotpinzone, drc, 2);
      vector<DNSZoneRecord> dsset;
      auto ret = stubDoResolve(dotpinzone, QType::DS, dsset);
      bool verified = false;
      for (const auto &ds : dsset) {
        if (*ds.dr.d_content == dsrc) {
          verified = true;
          break;
        }
      }

      if (verified) {
        cout<<"server pubkey matches a DS"<<endl;
      } else {
        cout<<"server pubkey does not match any DS"<<endl;
      }

> process of the resolver.

I agree.

We chose the openssl format because it is unambiguous, but it is not
the best form for an explanation. We chose to keep the draft short by
not reiterating the protocol for the separate implementation paths (a
client uploading a DS, a client uploading a DNSKEY, and a resolver
doing the pin validation) for -00. We felt it would be better to have
the protocol fully hashed out before describing it in multiple
contexts.

>  What does it fetch, when does it fetch it, what

I hope the sample above helps. We'll work on improving the draft for
this.

> inserting DS records to MITM the TLS cannot be detected.

Your previous email also mentioned something like this, and I've been
thinking about it. What I get stuck on is 'if the parent does that,
they might as well also change the NS records and the DS records
related to actual DNSKEYs'.

> down menus for DS components to only valid algorithms.

For resolvers: in January 2019, when the idea for this draft started to
form based on Manu Bretelle's DSPKI draft, we did some experiments to
find out how big this problem is. At the time, Unbound, PowerDNS
Recursor and BIND were fine with unknown algorithms not having real
DNSKEYs. Google Public DNS, Knot Resolver (and by extension, 1.1.1.1)
did choke on it. Both have been fixed since.

For registries: yes, many of them limit their drop down menus (or EPP
interfaces, or CDS/CDNSKEY interfaces) to valid algorithms. We trust
that an IANA registration for algorithm 'TBD' will eventually fix that.

> you to leave algorithm and other values more real.

If the registry interface is 'DNSKEY', there is no way to set the key
tag to zero. We wrote the draft as it is now, precisely to be
compatible with registries that expect (C)DNSKEY instead of DS.

> is needed to explain the details of pinning and how it interacts with

I don't think I follow what interaction you are talking about, can you
please explain?

> I'm still not convinced of the latter, but might be persuaded.

It is very similar to 'You could use the digest field to stuff in a
public key.' from your previous email - working from what you said, we
added a step to the process to deal with registries that do not
directly take DS from their delegated domain owners. The DS digest
field is just sitting there, I feel it would be a waste not to use it!

> A similar problem will happen for new algorithms.

Definitely. We've tried to limit the scope of that problem to be
equivalent to 'there is a new DNSKEY algorithm'. Some registries needed
a year (not kidding) to allow 13/14, and after that several months for
15/16. This, apparently, is an accepted reality. Our draft is designed
to suffer no -more- pain than that process.

Kind regards,

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 26 May 2020 09:10:52 +0200

Hi Peter and Paul,

> On 24 May 2020, at 19:43, Paul Wouters <[email-masked]> wrote:
> 

So, the RFC4034 has to say something about DNSKEY:

>    Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
>    then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
>    owner name MUST be the name of a zone.  If bit 7 has value 0, then
>    the DNSKEY record holds some other type of DNS public key and MUST
>    NOT be used to verify RRSIGs that cover RRsets.

and also:

>    The DNSKEY RR is not intended as a record for storing arbitrary
>    public keys and MUST NOT be used to store certificates or public keys
>    that do not directly relate to the DNS infrastructure.

So, while my first though was same as Paul’s - this is abuse…  I came to
conclusion, it actually isn’t.

That said - I think this needs some modifications:

1. Bit 7 of the Flags fields needs to be 0.

2. This needs a new Protocol number

3. And since we now have non-„DNS zone key“ with a different protocol we might get a separate IANA registry for the algorithms (if needed).

I think only then it won’t feel like an abuse of the protocol.

Cheers,
Ondrej
--
Ondřej Surý
[email-masked]

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 26 May 2020 15:23:57 +0200

Hello Ondřej,

> 1. Bit 7 of the Flags fields needs to be 0.

Definitely - it is not explicit but the examples in draft -00, and the
PoC code, all use 0 for the flags. In 
https://github.com/PowerDNS/parent-signals-dot/issues/20 I noted
earlier that whatever flags we might need, it's definitely *not* ZONE
and SEP.

> 2. This needs a new Protocol number

I understand why you would say that, but I'd love to avoid doing that.
I wonder how much 'IETF' pain specifying another protocol number would
be, but what worries me more, ironically, is how it changes the format
away from normal DNSSEC. The draft was written such that a lot of
existing software needs no changes at all - I don't know if changing
the protocol number is compatible with that goal.

> 3. And since we now have non-„DNS zone key“ with a different protocol we might get a separate IANA registry for the algorithms (if needed).

We liked this, until we realised it will be painful with DS records.

Because the protocol number is not visible in the DS records, a 'pin
signal algo 8' and 'DNSSEC RSASHA256' DS are indistuingishible from
eachother. While validators should accept this, it will make tools like
dnsviz very hard to use if assignments between the existing and this
new registry overlap. So, we'd have to state that the two registries
may not issue overlapping assignments, in which case we might as well
stick with the one registry we have.

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 May 2020 09:40:36 -0400 (EDT)

On Tue, 26 May 2020, Peter van Dijk wrote:

> PoC code, all use 0 for the flags.

> earlier that whatever flags we might need, it's definitely *not* ZONE

Now I am all confused again.

I thought my initial reading this was stored inside a DNSKEY was wrong
and things are actually stored in a DS digest. And DS records do not
have flags of the DNSKEY, so why are we talking again about DNSKEY
flags?

                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           key tag             |  algorithm    |  Digest type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                digest  (length depends on type)               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                (SHA-1 digest is 20 bytes)                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We just have the algorithm which would be set to some special value
of "this is not really a hash(DNSKEY)". I dont know what you will use for
keytag. The digest type would also be some strange number meaning
"not really a DNSKEY digest".

So why talk about DNSKEY flags? Where do these appear in the proposal?

If you want the child to confirm the special record in its parent,
then _really_ you should use only CDS, mirroring the exact binary
blob of the parent, and not CDNSKEY/DNSKEY. Why make life harder
by needing to stuff square things into round boxes twice instead of
once?

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 26 May 2020 16:59:35 +0200

> have flags of the DNSKEY, so why are we talking again about DNSKEY

When I ask my resolver for TXT validpin.dotpin.powerdns.club., the
following things happen in the resolver:

Queries are issued to root, TLD, etc., until the delegation to
validpin.dotpin.powerdns.club from dotpin.powerdns.club is received. It
looks like this:

validpin.dotpin.powerdns.club. NS	pdns-public-ns1.powerdns.com.
validpin.dotpin.powerdns.club. NS	pdns-public-ns2.powerdns.com.
validpin.dotpin.powerdns.club. DS	17418 225 2 ....
validpin.dotpin.powerdns.club. IN	RRSIG	DS ....

In this test deployment, we have chosen algorithm number 225 by fair
dice roll.

The resolver connects to a NS, let's say pdns-public-ns1.powerdns.com,
on port 853. During the handshake, the resolver receives the
SubjectPublicKeyInfo from the name server.

The resolver then constructs, in memory, a DNSKEY:

pdns-public-ns1.powerdns.com. DNSKEY 0 3 225 [base64-encoded SPKI]

The resolver then turns this into a DS with the normal procedure for
DNSKEYs (https://tools.ietf.org/html/rfc4034#section-5.1.4). This
yields a DS with some keytag, algo number 225, and digest type 2
(because that's what we saw in the DS set). The resolver checks if the
resulting DS is in the DS set given by the parent. If so, we are now
connected securely. If not, we disconnect and do not use this name
server.

> I dont know what you will use for keytag.

https://tools.ietf.org/html/rfc4034#appendix-B

>  The digest type would also be some strange number meaning

The digest type is one of the types from 
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml, just as
with normal DNSKEY processing.

> So why talk about DNSKEY flags? Where do these appear in the proposal?

The proposal currently has no need for any flags, so the flags field is
set to zero. If we come up with convincing reasons for flags, we could
define some.

> Why make life harder

Because many registries only accept DNSKEY (via EPP or as CDNSKEY), and insist on doing the digesting into a DS on their end.

Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 26 May 2020 23:13:24 +0200

> you to leave algorithm and other values more real.

This comment made me curious. Why would that be true? So I generated
524726 keys equally split between algorithms 8, 13, and 15.

The result: 2 algo 13 keys with tag 0, 7 algo 15 keys with tag 0. I've
pasted them at 
https://gist.github.com/Habbie/feb0bf288ea1137bee5a2c3d8913ba7f (happy
to provide the related private keys if anybody cares).

None for RSA, though, which I bet was predicted in the work behind 
https://indico.dns-oarc.net/event/22/contributions/315/attachments/316/555/Quest_for_the_missing_keytags.pdf
and 
https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf

Kind regards,

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 26 May 2020 21:27:33 -0400

I like the idea of signalling DoT support in the DS record, but I worry a
bit about putting the SPKI fingerprint in the DS as well.  Having to update
the parent zone whenever the TLSA key needs to be rotated seems cumbersome
and fragile, especially if the nameserver is operated by a third party.
DoT authoritatives would need to keep both the old and new certificates on
hand during the transition, and DoT recursives would need some way to
signal in the ClientHello which one they are expecting.  This is pretty far
from how TLS normally works.

I wonder if you considered using draft-ietf-tls-dnssec-chain-extension
instead? That would provide the same security and performance, using less
volatile information in the parent.  Specifically, I think that the DS
record would have to convey one bit ("DoT enabled") plus the name of the
nameserver (which should probably match the NS record).  That seems
preferable to me.

---

From: Petr Špaček <[email-masked]>
Date: Wed, 27 May 2020 08:45:39 +0200

On 27. 05. 20 3:27, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit about putting the SPKI fingerprint in the DS as well.  Having to update the parent zone whenever the TLSA key needs to be rotated seems cumbersome and fragile, especially if the nameserver is operated by a third party.  DoT authoritatives would need to keep both the old and new certificates on hand during the transition, and DoT recursives would need some way to signal in the ClientHello which one they are expecting.  This is pretty far from how TLS normally works.

The proposed mechanism works the other way around:
Zone can have multiple DS records at a time, thus exposing multiple hashes to resolvers. Rresolver then checks if any of the hashes in DS matches, so the auth side can be use any cert without prior communication with resolver.

> 
> I wonder if you considered using draft-ietf-tls-dnssec-chain-extension instead? That would provide the same security and performance, using less volatile information in the parent.  Specifically, I think that the DS record would have to convey one bit ("DoT enabled") plus the name of the nameserver (which should probably match the NS record).  That seems preferable to me.

I can see three problems, not sure which one is worse:

- I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you see any evidence it is going to change?

- If I'm not mistaken authoritative servers implementing draft-ietf-tls-dnssec-chain-extension would need to add DNS resolver to refresh chain of records leading to TLSA records under their name:
a) Having resolver on auth side is major paradigm change in deployment of auth servers and I'm not convinved auth operators would be happy with it as it adds additional fragility.
b) Auth servers nowadays do not even know all their _names_ and do not care/need to know. How would we solve that?

Petr Špaček  @  CZ.NIC

> 
> On Tue, May 26, 2020 at 5:13 PM Peter van Dijk <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 27 May 2020 10:28:22 +0200

Hello Ben,

On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
> I like the idea of signalling DoT support in the DS record, but I worry a bit about putting the SPKI fingerprint in the DS as well.  Having to update the parent zone whenever the TLSA key needs to be rotated seems cumbersome and fragile, especially if the nameserver is operated by a third party.

I agree, it's the weakest link in the proposition.

>  DoT authoritatives would need to keep both the old and new certificates on hand during the transition

keys, not certificates

> , and DoT recursives would need some way to signal in the ClientHello which one they are expecting.

I don't follow - if the DS set has both the old and new keys, the DoT recursive will accept either. I ki

>   This is pretty far from how TLS normally works.

Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm missing something.

> I wonder if you considered using draft-ietf-tls-dnssec-chain-extension instead? That would provide the same security and performance, using less volatile information in the parent.  Specifically, I…

I considered putting names in DS records; I also considered chain-extension; but I failed to consider them together! With NS names 'verified' by DS, that looks like something that would also be secure. I agree with the problems Petr spotted - I'm aware of roughly zero implementations of dnssec-chain in clients or servers.

> That seems preferable to me.

For me, with 10 domains on two name servers, not having the complexity of chain-extension is preferable. For others, with a million domains, obviously our draft does not scale. I've been assuming we'd end up with two or three separate signals, each fit for purpose for a certain scale. Your proposal seems like a viable candidate to be one of those to me.

Kind regards,

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 27 May 2020 18:33:56 -0400

Thanks for the explanations.  Having multiple TLS-DS records during TLS key
rolls does seem like a pretty good solution.

There are still some potential operational rough edges here.  For example,
an "emergency" certificate replacement (e.g. in event of compromise) is
difficult, because the old fingerprint set might be cached all over the
internet.  Cautious authoritative operators might have to set low TTLs,
resulting in slower lookups and increased load on the parent zones.

In my view, the most important link for ADoT is to the TLD, because the
TLD+1 is typically the most sensitive label.  In this solution, TLS key
agility seems likely to be particularly difficult for TLD operators,
assuming that updating the root zone is relatively slow.

I agree that the TLS DNSSEC chain extension isn't substantially deployed
today, but I don't think that should stop us from using it if it would
help.  This use case is important enough to drive deployment.

Using this extension would indeed require the authoritative server to
provide TLSA records for its own name.  I don't think it actually has to
"resolve its own name", because it can choose a name that is in-bailiwick.
Servers can choose an in-bailiwick authentication name even if existing NS
records have an out-of-bailiwick name.  If an authoritative server has
multiple names, it would presumably identify the right one from the TLS-SNI.

On Wed, May 27, 2020 at 4:28 AM Peter van Dijk <[email-masked]>
wrote:

> hand during the transition
>
>
> keys, not certificates
>
> I considered putting names in DS records; I also considered
> chain-extension; but I failed to consider them together! With NS names
> 'verified' by DS, that looks like something that would also be secure. I
> agree with the problems Petr spotted - I'm aware of roughly zero
> implementations of dnssec-chain in clients or servers.
>
> For me, with 10 domains on two name servers, not having the complexity of
> chain-extension is preferable. For others, with a million domains,
> obviously our draft does not scale. I've been assuming we'd end up with two
> or three separate signals, each fit for purpose for a certain scale. Your
> proposal seems like a viable candidate to be one of those to me.
>
> Kind regards,
> --
> Peter van Dijk

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 May 2020 00:43:24 +0100

Peter van Dijk <[email-masked]> wrote:
> Definitely [...] I noted earlier that whatever flags we might need, it's
> definitely *not* ZONE and SEP.
>

This made me wonder if this pseudorecord should be a KEY instead, and then
I wondered how hard it would be to persuade existing code to generate a DS
from a KEY.

But anyway, this signalling and verification scheme sounds clever and neat.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Southwesterly 5 to 7 at first in north, otherwise southerly
3 to 5. Moderate or rough, becoming moderate later. Drizzle and fog patches
later. Moderate or good, occasionally very poor later.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 May 2020 21:27:39 -0400 (EDT)

On Wed, 27 May 2020, Ben Schwartz wrote:

> I agree that the TLS DNSSEC chain extension isn't substantially deployed today, but I don't think that should stop us from using it if
> it would help.  This use case is important enough to drive deployment.

If people really want to avoid doing an extra RTT, then I guess this
extension could be used. But you would still need to have some kind of
TLS server SAN with FQDN conveyed within the DS record. Having a single
bit in the DS signifying "yes there is DoT", isn't enough if the
additional glue NS records can point to any machine with a valid TLSA
chain.

> Using this extension would indeed require the authoritative server to provide TLSA records for its own name.  I don't think it actually
> has to "resolve its own name", because it can choose a name that is in-bailiwick.  Servers can choose an in-bailiwick authentication
> name even if existing NS records have an out-of-bailiwick name.  If an authoritative server has multiple names, it would presumably
> identify the right one from the TLS-SNI.

The nameserver name has to be known (from DS) before the resolver
connects to the DoT server. How the DoT server would identify itself,
via TLSA or via fake DNSKEY doesn't really matter as it can just provide
whatever we decide to use.

Personally, I think it would be cleanest if we use the DS to signal
the DoT nameserver only by FQDN. Then connect to it and get the TLS
chain containing the TLSA record and the CDS that matches the DS.

That way, we can avoid adding pseudo-DNSKEY records. I understand not
every registry supports DS/CDS, but I think if you want to deploy
this, you cannot be depending on humands anything, so CDS or CDNSKEY
support would be a requirement anyway. Let's just convince those
registries that support CDNSKEY but not CDS, that they need to fix
things. It would make everything a LOT cleaner and we got no bogus
DNSKEY records to ignore in our DNSSEC validation path.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 27 May 2020 21:47:47 -0400

On Wed, May 27, 2020 at 9:27 PM Paul Wouters <[email-masked]> wrote:

> the DoT nameserver only by FQDN.

I agree.  This is the design that I was attempting to describe.

I see now that the chain extension doesn't have to be mandatory.  A
recursive that wants to use the extension can offer it.  If it doesn't get
a chain extension in the reply, it sends a TLSA query over the
(as-yet-unauthenticated) TLS connection, at a cost of 1 RTT.  When it gets
the response, it can validate the certificate, and (if it validates) send
the actual query.

I think this is my preferred design: the DS contains a name and optionally
an SPKI fingerprint.  If the fingerprint is present, it saves a roundtrip
to fetch the TLSA.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 May 2020 21:55:23 -0400 (EDT)

> - I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you see any evidence it is going to change?

The draft has been resubmitted for the ISE stream (not TLS WG) as  draft-dukhovni-tls-dnssec-chain

Stubby already implements it. We do so traction and a lot of interest.
Viktor wants to add support to openssl.

But we are unfortunately waiting on the ISE :/

> - If I'm not mistaken authoritative servers implementing draft-ietf-tls-dnssec-chain-extension would need to add DNS resolver to refresh chain of records leading to TLSA records under their name:

No. An external progam can update the blob and regularly rewrite it. The
DNS auth server can pick it up using inotify or something.

> b) Auth servers nowadays do not even know all their _names_ and do not care/need to know. How would we solve that?

Whatever part talks TLS, knows the certificate it is using, and can pull
the SAN with FQDN from the certificate.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 May 2020 22:00:37 -0400 (EDT)

>       DoT authoritatives would need to keep both the old and new certificates on hand during the transition

I would not rule out that people want to run this using a CA chain.
Limiting the signaling to EE-certs or pubkeys is not needed. Especially
if you use TLSA, it makes no sense to take away that flexibility that
some people want, so they can replace their TLS certs and only pin it
to one (their own?) CA.

> I don't follow - if the DS set has both the old and new keys, the DoT recursive will accept either. I ki

Only signal the name and mandate TLSA via tls-dnssec-chain, and this is
not a problem. Regular TLSA processing applies.

> Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm missing something.

It's a very liited subset of how TLS works :)

> I considered putting names in DS records; I also considered chain-extension; but I failed to consider them together! With NS names
> 'verified' by DS, that looks like something that would also be secure. I agree with the problems Petr spotted - I'm aware of roughly
> zero implementations of dnssec-chain in clients or servers.

stubby

> For me, with 10 domains on two name servers, not having the complexity of chain-extension is preferable. For others, with a million
> domains, obviously our draft does not scale. I've been assuming we'd end up with two or three separate signals, each fit for purpose
> for a certain scale. Your proposal seems like a viable candidate to be one of those to me.

Not having SBKI in CDS/CDNSKEY's would be much cleaner from a protocol

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2020 10:32:54 +0100

> But we are unfortunately waiting on the ISE :/

I hope not for too long, given the TLS WG more
or less sent this to the ISE.

S.

---

From: Petr Špaček <[email-masked]>
Date: Thu, 28 May 2020 15:55:16 +0200

> But we are unfortunately waiting on the ISE :/

I apologize for being too terse, let me clarify my question:

Is there any indication that TLS libraries are going to implement this? (Unmerged patches do not count!)

Having text in form of draft or RFC makes no difference if there are no widely available implementations... IMHO implementations should be done first before drafts become RFCs.

> DNS auth server can pick it up using inotify or something.

You are effectively saying the same thing, just in other words. With your proposal auth server operators need to _also_ operate DNS resolver and tie it together with the auth server. That's very significant change from how authoritative servers are operated today.

> the SAN with FQDN from the certificate.

Ok, hopefully there is not too much of them.

Petr Špaček  @  CZ.NIC

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 May 2020 12:08:06 -0400 (EDT)

> Is there any indication that TLS libraries are going to implement this? (Unmerged patches do not count!)

I thought "indication" to implement would be uhm, unmerged patches?
Otherwise, it would be implemented already and you wouldn't need any
more indication?

> Having text in form of draft or RFC makes no difference if there are no widely available implementations... IMHO implementations should be done first before drafts become RFCs.

Aren't you an implementer? Are you working on this? If not, why not?

> You are effectively saying the same thing, just in other words.

No I am not. A dnssec-chain can be generated by one machine and
distributed to many auth nameservers. The auth nameservers themselves
do not need to do a single DNS recursive query.

> With your proposal auth server operators need to _also_ operate DNS resolver and tie it together with the auth server. That's very significant change from how authoritative servers are operated today.

That change is pretty minor compared to to including a whole TLS stack in
a DNS Auth server. Which btw, you could also do with a different program,
to minimize the traditional auth nameserver code.

Compared to hacking all code at nameservers and registries for mangling
and unmangled DNSKEY records, I think that is a very reasonable trade
of.

> Ok, hopefully there is not too much of them.

The whole point is that you point many domains to this nameserver, and
the TLS connection to the nameserver isn't configured with a different
cert per domain, or otherwise you might as well not offer any TLS
privacy to begin with. I really don't see the use case for this TLS
channel to have more than one TLS certificate chain to use.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Thu, 28 May 2020 12:44:08 -0400

> or less sent this to the ISE.

I haven't read the draft that is the original topic of this thread yet, but
a quick comment on the tls-dnssec-chain draft. It was submitted to the ISE
on December 17th, and acknowledged as received and processing a month
later. No updates since then. I'll ping the ISE to see what the current
status is.

Shumon.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 May 2020 10:50:12 -0700

If you want to use tls-dnssec-chain, there's no reason you have to wait for
the ISE. The code points can be assigned today based on the existence of
the draft.

On Thu, May 28, 2020 at 9:44 AM Shumon Huque <[email-masked]> wrote:

> I haven't read the draft that is the original topic of this thread yet,
> but a quick comment on the tls-dnssec-chain draft. It was submitted to the
> ISE on December 17th, and acknowledged as received and processing a month

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 May 2020 14:28:37 -0400 (EDT)

On Thu, 28 May 2020, Eric Rescorla wrote:

> If you want to use tls-dnssec-chain, there's no reason you have to wait for the ISE. The code points can be assigned today based
> on the existence of the draft.

Thinking about this again. There is actually no strong reason for
tls-dnssec-chain. The TLS channel you are authenticating is the
actually TLS channel you intend to use for DNS queries anyway.
We are not talking about a browser needing to setup a TCP connection
to resolver to then go back to its other TCP/TLS connection it is
actualy trying to use.

And we are not building a huge chain over CNAMEs or other zones
either, so we might not even need RFC 7901 Query Chain support.

The tls-dnssec-chain was much more about full recursive query chains
spanning multiple domains and choices regarding webpki vs dnsec or pinning.

But our queries are only for a single domain here. And the webpki isn't
in use here, and pinning happens via DS/CDS existence.

Let's talk about a full example. Let's lookup www.libreswan.org.

I've connected with DoT to d0.org.afilias-nst.org, I ask for NS/DS of
libreswan.org. I am returned a DS for libreswan.org and NS/A glue
records for ns*.nohats.ca.

I determine the DS record contains a "do DoT" entry that contains
the name "ns0.nohats.ca".

I connect to ns0.nohats.ca following the glue that .org gave me on
the Dot port. I setup a TLS connection, but I haven't authenticated
it yet. It should query it for DNS records for authentication until I
authenticated the TLS layer.

I send a query for TLSA of ns0.nohats.ca over the unverified TLS
channel.

I get back a DNSSEC verifiable answer (DNSKEY, TLSA, RRSIGs)

I DNSSEC verify the data, and can trust the TLSA record contents.
I know know the public key, EE-cert or CA-cert for the DoT connection
on ns0.nohats.ca. I verify my TLS channel.

Now I'm authenticated, and I can send a query for CDS libreswan.org to
confirm the child agrees with the parent on DoT and nameservers. Once
confirmed, I can now query any kind of data for libreswan.org over this
DoT channel.

Where would we gain much by using RFC 7901 Query Chains or tls-dnssec-chain?

Paul

>       On Thu, May 28, 2020 at 5:33 AM Stephen Farrell <[email-masked]> wrote:
>
> I haven't read the draft that is the original topic of this thread yet, but a quick comment on the tls-dnssec-chain draft.
> It was submitted to the ISE on December 17th, and acknowledged as received and processing a month later. No updates since
> then. I'll ping the ISE to see what the current status is.
> 
> Shumon.
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 May 2020 12:08:49 -0700

> Where would we gain much by using RFC 7901 Query Chains or

FWIW, I have no opinion on this. I was just trying to help move the process
piece along.

-Ekr

Paul
> but a quick comment on the tls-dnssec-chain draft.
> > It was submitted to the ISE on December 17th, and acknowledged as
> received and processing a month later. No updates since

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 28 May 2020 23:38:18 -0400

On Thu, May 28, 2020 at 2:28 PM Paul Wouters <[email-masked]> wrote:
...

> I send a query for TLSA of ns0.nohats.ca over the unverified TLS
...

> Where would we gain much by using RFC 7901 Query Chains or

Using tls-dnssec-chain would save a roundtrip.  So would putting an SPKI
pin along with "ns0.nohats.ca" in the DS record.  I think both are
reasonable optimizations, and should be optional*.

The chain extension is nicely decoupled from the weird-DS questions, so if
we start by assuming an explicit TLSA query, we can forget about the chain
extension for now, and come back to it later.

*: To be precise, I think publishing an SPKI pin should be optional, but
using it (if present) should be mandatory, so that an authoritative server
can include a pin if it can't resolve its own name, as Petr described.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2020 00:01:40 -0400 (EDT)

On Thu, 28 May 2020, Ben Schwartz wrote:

> Using tls-dnssec-chain would save a roundtrip.  So would putting an SPKI pin along with "ns0.nohats.ca" in the DS
> record.  I think both are reasonable optimizations, and should be optional*.

You suggest a hack on top of a hack, to save 1 RTT for a record that
should have a TTL of 4h to 2d (based on parent/child TTL of NS records).
This would be on resolvers that presumbly resolve many domains, multiple
on the same nameserver. So policies for "how long to keep the DoT
connection idle/open" will affect performance a lot more than this 1
RTT.

> *: To be precise, I think publishing an SPKI pin should be optional, but using it (if present) should be mandatory,
> so that an authoritative server can include a pin if it can't resolve its own name, as Petr described.

I think this issue requires more discussion...

Paul

---

From: Petr Špaček <[email-masked]>
Date: Fri, 29 May 2020 09:39:08 +0200

> Otherwise, it would be implemented already and you wouldn't need any

Hmm, apparently I cannot convey idea from my head to text form, sorry! Let me clarify:

Unmerged patches mean nothing _unless_ upstream does say it is interested in working on them and eventually merging them. I or you can submit whatever patches we want to OpenSSL or GnuTLS and it means nothing until maintainers give us their opinion on them.

> Aren't you an implementer? Are you working on this? If not, why not?

The question above is pointless without library support which is what I was attempting to find out above. Nonetheless I'm not convinved this is a good approach, see below.

> do not need to do a single DNS recursive query.

That's understood.

> to minimize the traditional auth nameserver code.

I disagree. Adding TLS server or proxy means adding self-contained code which does not depend on communication with anything else (barring OCSP stapling etc.).

dnssec-chain-extension on auth adds new depedency on resolution chain. No matter how it is implemented that's a pretty big change from how auth servers are operated today:
- Nowadays auth servers depend only on their master server/replication topology.
- tls-dnssec-chain-extension would add either DNS resolver /or/ another replication topology for dnssec-chain-extension /or/ extension to zone transfer mechanism (so it can use the same topology as zone data). None of this seems like (operationally) straightforward change.

Keep in mind that a smallish ccTLD like CZ has hundreds of machines in different corners of planet so adding yet-another-replication-topology for DNS responses just for TLSA is going to be major PITA to operate, and so does operating hundreds on resolver instances on each auth server.

> channel to have more than one TLS certificate chain to use.

That's a good point!

-- 
Petr Špaček  @  CZ.NIC

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 15:55:03 +0200

> I wondered how hard it would be to persuade existing code to generate a DS

That could make semantic sense, but would muddle the connection to
'DNSKEY in EPP' and 'CDNSKEY sync from child to parent'; I think it
would add more confusion than the semantic correctness is worth.

Thanks!
 
Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 16:11:04 +0200

> and unmangled DNSKEY records, I think that is a very reasonable trade

The DNSKEY mangling in a resolver is 10-20 lines of code - I doubt 
tls-dnssec-chain can be done in less?

There is no mangling at registries, they convert DNSKEY to DS like they
do for any existing DNSKEY algorithm.

Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 16:12:45 +0200

On Wed, 2020-05-27 at 21:27 -0400, Paul Wouters wrote:
> It would make everything a LOT cleaner and we got no bogus

What bogus DNSKEY records?
 
Kind regards,

---

From: Tony Finch <[email-masked]>
Date: Fri, 29 May 2020 16:01:28 +0100

> would add more confusion than the semantic correctness is worth.

Right, good point. EPP and CDNSKEY are crucial.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Variable becoming northeast, 2 to 4. Smooth or slight. Mainly fair.
Moderate or good, occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2020 11:25:38 -0400 (EDT)

> What bogus DNSKEY records?

It really all depends on what registry systems you want to support. We
have some combo's:

- Takes any DS    --> give our DS with DoT info embedded
- Takes DS, but verifies it is a real DNSKEY at the child --> we create bogus DNSKEY matching our DS request
- Takes any CDS   --> Put our info in zone as CDS 
- Takes CDS, but verifies it is a real DNSKEY at the child --> we create bogus DNSKEY matching our CDS request
- Takes DNSKEY, only does syntax checks ---> we dont need to publish anything
- Takes DNSKEY, verifies it lives in child --->  we create bogus DNSKEY
- Takes DNSKEY, but verifies it is a supported algorithm --> we have to convince them to support our pseudo alg
- Takes any CDNSKEY  ---> we only need to publish as CDNSKEY, not DNSKEY
- Takes CDNSKEY but verifies it lives in child as DNSKEY ---> we need to publish CDNSKEY and bogus DNSKEY

When I say bogus I mean "not a DNSKEY used for DNSSEC validation of DNS data"

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2020 11:31:11 -0400 (EDT)

Note for DNSKEY algorithm, we could use 253 or 254:

https://tools.ietf.org/html/rfc4034#appendix-A.1.1

A.1.1.  Private Algorithm Types

    Algorithm number 253 is reserved for private use and will never be
    assigned to a specific algorithm.  The public key area in the DNSKEY
    RR and the signature area in the RRSIG RR begin with a wire encoded
    domain name, which MUST NOT be compressed.  The domain name indicates
    the private algorithm to use, and the remainder of the public key
    area is determined by that algorithm.  Entities should only use
    domain names they control to designate their private algorithms.

    Algorithm number 254 is reserved for private use and will never be
    assigned to a specific algorithm.  The public key area in the DNSKEY
    RR and the signature area in the RRSIG RR begin with an unsigned
    length byte followed by a BER encoded Object Identifier (ISO OID) of
    that length.  The OID indicates the private algorithm in use, and the
    remainder of the area is whatever is required by that algorithm.
    Entities should only use OIDs they control to designate their private
    algorithms.

DNS software might already support ignoring these algorithms without
adding too much noise to the DNSSEC validation process of having
"wrong" DNSKEY's.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 17:39:12 +0200

On Fri, 2020-05-29 at 11:25 -0400, Paul Wouters wrote:
> It really all depends on what registry systems you want to support.

Right! Preferably as many as possible - that's why the process in the
draft looks more convoluted than would be desirable.

Note that the DNSSEC validation paths in existing resolvers already
ignore DNSKEYs for algos they do not support.

> We have some combo's:

Thanks, I'm going to go through them one by one just in case you
spotted any interesting edge cases.

> - Takes any DS    --> give our DS with DoT info embedded

Right, easy.

> - Takes DS, but verifies it is a real DNSKEY at the child --> we create bogus DNSKEY matching our DS request

I am hoping, also for 'normal' DNSSEC reasons (like key rolls) that no
registry does this.

> - Takes any CDS   --> Put our info in zone as CDS 

Yes.

> - Takes CDS, but verifies it is a real DNSKEY at the child --> we create bogus DNSKEY matching our CDS request

Hopefully as above.

> - Takes DNSKEY, only does syntax checks ---> we dont need to publish anything

Yes.

> - Takes DNSKEY, verifies it lives in child --->  we create bogus DNSKEY

Hopefully as above.

> - Takes DNSKEY, but verifies it is a supported algorithm --> we have to convince them to support our pseudo alg

Yes, and, we found out and will put in -01: to allow 'weird' flags for
at least that algo.

(Incidentally you might one day run into the same question with
DELEGATION_ONLY, although a zone delegated from a registry would not be
a common place for that flag)

> - Takes any CDNSKEY  ---> we only need to publish as CDNSKEY, not DNSKEY

Yes.

> - Takes CDNSKEY but verifies it lives in child as DNSKEY ---> we need to publish CDNSKEY and bogus DNSKEY

Hopefully as above, again :)

I'm collecting registry issues at 
https://github.com/PowerDNS/parent-signals-dot/issues/22 - I hope that
list never grows a 'demands visible DNSKEY to go with the DS' entry!

> When I say bogus I mean "not a DNSKEY used for DNSSEC validation of DNS data"

Understood now. I think 'bogus' might be the worst possible choice of words though ;)
 
Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2020 11:59:02 -0400 (EDT)

> I am hoping, also for 'normal' DNSSEC reasons (like key rolls) that no

Yes, hopefully, they will limit themselves to checking that DNSSEC
validation with the new DS RRset works - and not try to be clever on
individual DS records.

>> - Takes DNSKEY, only does syntax checks ---> we dont need to publish anything

Actually I was wrong. We still need to publish something so the child
proves the parent was not maliciously publishing a DS record. So we
would probably publish it as a CDS to keep it out of the DNSSEC
validation path and make it easy to compare parent DS to client CDS.

> Yes, and, we found out and will put in -01: to allow 'weird' flags for

See my other email about DNSKEY algo 253 and 254. Since that's in the RFC,
you will have a better case arguing they have to support those.

> a common place for that flag)

Yes I know, it is a similar problem but hopefully smaller.

Paul

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 21:49:04 +0200

> adding too much noise to the DNSSEC validation process of having

PowerDNS does nothing specific for those numbers. A quick grep of the Unbound codebase suggests the same there.

I wouldn't expect any noise from unknown algorithms - have you seen otherwise?

Furthermore, 253 and 254 are specifically targeted at people/organisations/groups that do not want/cannot afford/... an IANA registration. In other words, people that don't want to go through the RFC process. I don't think that's the path we want to be going down here :)

Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 21:56:12 +0200

> validation path and make it easy to compare parent DS to client CDS.

I know you have spent a lot more time thinking about attacks from a
parent to a child zone, so I'm probably missing something that's
obvious to you.

I'm not even sure what my question is, so let's try this: if a
malicious parent has the ability to publish a malicious DS record, why
wouldn't that parent also change the NS records in some subtle way?
Then the real client side CDS becomes invisible. I have trouble seeing
a specific combination of attacker choices that makes sense here.

> you will have a better case arguing they have to support those.

Assuming we (our draft, or some loosely related variant like the couple
of other proposals in this thread) get to RFC, IANA will assign a
number (or perhaps even before that). I'm not worried about getting the
algo number on the registries' allowlist.. eventually.

(see my reply to the other email, that I had missed before, for why I
think 253/254 are not appropriate)

Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 29 May 2020 21:57:56 +0200

On Wed, 2020-05-27 at 21:47 -0400, Ben Schwartz wrote:
> I see now that the chain extension doesn't have to be mandatory.  A recursive that wants to use the extension can offer it.  If it doesn't get a chain extension in the reply, it sends a TLSA query over the

emphasis on:

> (as-yet-unauthenticated) TLS connection

This means the TLSA query is subject to leakage by MITM. How bad that is depends on a bunch of things, but it is a wart.

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2020 16:35:52 -0400 (EDT)

On Fri, 29 May 2020, Peter van Dijk wrote:

> I see now that the chain extension doesn't have to be mandatory.  A recursive that wants to use the extension can offer
> it.  If it doesn't get a chain extension in the reply, it sends a TLSA query over the
> 
> 
> emphasis on:
>

The TLSA query is for the nameserver name, not the target domain name.

Presumbly, by connecting to the IP of that nameserver, you have
already revealed the information you are connecting to that nameserver,
even if none of the traffic to that IP would provide any clue about
the content. The privacy comes from many domain names being hosted by
that nameserver, and not knowing which target domain you are going to
query about.

And ofcourse, thay only works if the A/AAAA records you get back go
to another IP address used by many other domain names (and no SNI
leakage). In the end, the protection from recursive to auth is not
gaining us that much privacy, especially compared to stub to recursive.

I think what does help us is if we break the one to one relationship
between packets from stub to resolvers and from resolvers to auth
servers. But that should probably be written up in another draft document,
by someone with a PhD in statistics :)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 29 May 2020 16:59:17 -0400 (EDT)

> a specific combination of attacker choices that makes sense here.

If a parent is coerced to publish a DoT DS record pointing to a government
run server, the child has no way to defend itself against this, unless
it can confirm in the child zone that the DoT DS is in fact the child
zone policy.

I wouldn't want .ca to start publishing national mandatory DoT servers.
Requiring confirmation of the child zone prevents this, as .ca cannot
put CDS records into my zone signed by my DNSKEY.

For a parent to be co-erced with requiring child zone confirmation,
it basically has to take over the entire child because it needs the
childzone to confirm its roque DS. Which is quite different from just
"publishing an additional DS record in their legally owned zone". Asking
the .ca people to publish a DS record is one thing. Asking them to take
over all .ca zones is quite another.

Yes, a targeted victim with an empty cache is going to lose from any
malicious parent willing to confiscate its child zone. If you have
some cache already, this is a little harder for targetted attacks,
and would have to be done publicly for everyone to see (and audit log)

We can also log the authentication chain of the DoT records. When did the
child pusblish CDS records to be picked up by the parent for DS. When
did the parent change DS records pointing to different DNSKEY records
(whether DNSKEY for resolving or DNSKEY for DoT)

See also the DELEGATION_ONLY and DNSSEC Transparency efforts we are
working on. A new (DoT) DS and CDS would be an auditable event similar to
the Certificate Transparency of seeing a new EE-cert. Cooperating clients
can log these somewhere public as to guarantee that any malicious DS/CDS
record created by the parent for a targetted attack would very likely be
caught by the child owner and become public knowledge, to be resolved by
layer 8.

> think 253/254 are not appropriate)

The fact that current software is not properly ignoring these algorithms
is not the best argument for not using them. I do think it is
interesting to use these because they already come with pre-buildin
concepts of FQDN's before putting in "arbitrary data based on who is
using it for what". It would arguably be less of a squatting on the
DNSKEY record than the current proposal. But I'm okay to try to use a
new algorithm number first, and if squatting becomes an issue moving
forward, we can always pick one of these two.

It is much more important that we agree on the MUST vs MAY of client
side confirmation of DoT servers at the parent.

Paul

---

From: Christian Huitema <[email-masked]>
Date: Sat, 30 May 2020 23:00:07 -0700

Peter,

I am wondering how using the signalling that you propose affects
experimentation with DoQ? I assume that with your proposal, we could
either have several DS records with different "algorithm" values, or a
single record with a flag somewhere stating that both TCP/DoT and
UDP/DoQ are supported. Have you thought about that?

-- Christian Huitema