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

[Peter van Dijk <[e-mail]>]

On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> On Sun, 24 May 2020, Peter van Dijk wrote:
> > 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?
> 
> You confused me with "pseudo DNSKEY record". You meant to say "pseudo DS
> 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
> similar then I originally understood.

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

> The draft currently has:
> 
>  	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;
      }

>  	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.

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
> information is extracted and used.

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

> 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.

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'.

> > > Conveying that you can do DoT using DS can only really be done by
> > > overloading the record type.
> > 
> > Which field do you mean by 'the record type'? We chose the algorithm
> > field for it.
> 
> 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.

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.

> I thought using keytag 0, which cannot happen normally, would allow
> 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.

> > > 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.
> 
> 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.

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

> > > If we want to offer hard fail,
> > > then some draft is still useful.
> > 
> > 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 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!

> > > I would use the keytag record set to 0 to mean this DS record is not
> > > 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.
> 
> 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,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/