Re: [dns-privacy] Some additional signalling ideas

[Ilari Liusvaara <[e-mail]>]

On Fri, Apr 05, 2019 at 10:50:35AM +0200, Peter van Dijk wrote:
> On 31 Mar 2019, at 16:22, Ilari Liusvaara wrote:
> 
> > DS is signed, and has algorithm field. Supposedly unknown algorithms
> > are ignored, but there are buggy nameservers out there that break if
> > all DS entries have unknown algorithm. And turns out abusing DS
> > records also runs into issues with "cloud" DNS provoders.
> 
> Do you know of any name servers out there that have a problem with it, other
> than Knot Resolver, 1.1.1.1 and 8.8.8.8? (who all should be fixed soonish)

No. And yes, apparently 1.1.1.1 has problems with it.

> > Adding another RRtype with needed magic properties would take Standards
> > Action (as expert review requires RRtype not to be magic) and then
> > updating parent nameservers to be able to deal with the RRtype (since
> > it can not be generically handled). And trying to add extra fields to
> > NS or DS is sure to cause horrible borkage.
> 
> I think adding fields might be even more painful than adding a new type.
> Neither seem feasible options to me.

Yes, that sort of thing is not going to be feasible.

> > Adding records at child side of cut has its own issues, namely that
> > retroactive authentication can be annoying to implement, and it is
> > more difficult to make the thing work without full DNSSEC chain
> > (glue records, if parent supports that?).
> 
> manu’s proposal explicitly targeted unsigned delegations, which I also think
> is an important use case.
> 
> Glue records are never signed.

Well, one could get weak authentication if parent supports
authenticated transport.

The issue with retroactive authentication is that it is annoying to
implement in way that is not trivially broken. But it is certainly
possible to implement.

So it is preferable if authentication credentials can be obtained
either before starting handshake, or stapled into the handshake itself.


-Ilari