Re: [dns-privacy] DOTPIN, TLSA, and DiS

[Brian Dickson <[e-mail]>]

On Fri, Nov 20, 2020 at 11:47 AM Vladimír Čunát <[e-mail]>
wrote:

> On 11/19/20 2:05 PM, Peter van Dijk wrote:
> > 1. auth operators publish TLSA records for their NSes
> > 2. the registry, while generating zone files, queries for those TLSA
> records
> > 3. from the found TLSA records, the registry generates DOTPIN DSes
> > 4. the DOTPIN DSes are published alongside the domain owner's NSes,
> DSes, and perhaps the DiS
>
> Intriguing but isn't it unnecessarily complicated? If we assume that
> DiS-like is possible, I'd rather replace the DOTPIN-related parts by
> some simple flag that tells if the zone's policy is to avoid cleartext.
>
> I.e., in comparison with today, the parent side would additionally sign:
> (a) the NS set - e.g. via DiS; that's because signing certs directly has
> those scalability issues
> (b) and this "policy flag" in some way (say, yet another DS alg like
> DiS, but there are other ways).
> The reasons are that I believe we want a possibility of downgrade
> resistance.
>
> More details: the rest of the trust chain could be TLSA or something
> similar on those NSs, looked up separately by a supporting resolver,
> assuming these can again be DNSSEC-validated (for now let me avoid
> trying to define the case when they can't).  Maybe this "policy flag"
> could be more than binary, too, e.g. allowing to indicate that the NSs
> may support DoT but it's OK if the supporting resolver isn't strict -
> and a third case might mean that resolvers shouldn't even attempt a
> secure transport (as optimization).  Of course, it's still not as nice
> as I'd like it (but maybe no perfect solution exists anyway), e.g.:
> - the TLSA lookup would add latency (at least I expect its TTL high
> enough to amortize for larger NSs), and
> - there are edge cases like privacy being hard for zones containing
> those TLSA records (circular dependencies; I expect we can sacrifice
> privacy of those TLSAs at least), and
> - it again assumes abusing DS - that's avoidable in theory but it may be
> too difficult to make the parent-side sign and return the necessary
> information in other ways (soon-ish).
>
> In retrospect I see that what I wrote is very similar to Manu's "Do9"
> except for replacing WebPKI by TLSA, with all their pros and cons:
>
> https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01
>
>
I think we (the three of us and maybe Tony Finch, if not the whole DNS
community) may be converging on a design that will, I believe, work.

I just checked on something that was nagging at me:
Is there a way to secure the NS set without requiring the delegated zone to
be signed?
I believe the answer is "yes", at least assuming implementers follow RFC
4035 correctly.

In section 5.2, the Nth paragraph reads:
    " If the validator does not support any of the algorithms listed in an

   authenticated DS RRset, then the resolver has no supported
   authentication path leading from the parent to the child.  The
   resolver should treat this case as it would the case of an
   authenticated NSEC RRset proving that no DS RRset exists, as
   described above."


So, using a new algorithm for whatever we do, should be 100% backward
compatible.

The assumption is any resolver supporting the new algorithm does so
correctly, and

that any resolver that does not support the new algorithm does the
right thing (treat like unsigned).


This means the design can be as simple as "put stuff in an apex DNSKEY
record with a new algorithm)",

plus put the corresponding DS (hash of DNSKEY elements that DS uses)
in the parent zone, is sufficient.

Note that for TLDs, the mechanism for this would be EPP sending of DS
(or DNSKEY), and/or using

the CDS/CDNSKEY mechanisms.


There is likely use cases for separate new algorithms for protected
delegation items NS, A, and AAAA,

all of which would be non-authoritative (and thus not signed by the
parent, but if encoded this way in

a DNSKEY, hashed as a DS, and signed indirectly by the parent, achieve
equivalency on protection).


Time to test some stuff and do some POC coding, and collaborate on a
draft with some folks.


Yay!


Brian