Subject: Re: [dns-privacy] Some additional signalling ideas

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Apr 2019 09:21:25 +0100

On 01/04/2019 07:19, Alexander Mayrhofer wrote:
> I have some experience in creating drafts for "funny" EDNS0-options
> (RFC7830), so I'd volunteer :-P
Actually, that maybe raises a point. If use of DoT to secure
recursive to authoritative traffic also requires padding (and
I can't see why that's different from the stub-recursive
situation), then presumably deployment of this EDNS0-option is
needed in any case, so does that imply that a new option for
signalling would actually be just as practical, in deployment
terms?

Cheers,
S.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 1 Apr 2019 10:32:11 +0200

> Actually, that maybe raises a point. If use of DoT to secure recursive to
> authoritative traffic also requires padding (and I can't see why that's
> different from the stub-recursive situation), then presumably deployment of
> this EDNS0-option is needed in any case, so does that imply that a new
> option for signalling would actually be just as practical, in deployment terms?

[AM] Hmm.. It's April 1st, so why not abuse the EDNS0 padding payload to convey certificate fingerprints? Oh, well, we excluded the use of Padding for unencrypted transport.. hmm.

;)

Best,
Alex

---

From: Tony Finch <[email-masked]>
Date: Mon, 1 Apr 2019 12:24:52 +0100

Ilari Liusvaara <[email-masked]> wrote:
>
> 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).

Don't forget the implications for EPP and the zoo of registrar UIs
and APIs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin: Southwest veering west, then becoming cyclonic later, 5 to 7. Moderate
or rough, becoming rough or very rough, occasionally high later. Rain then
wintry showers. Good, occasionally poor.

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 05 Apr 2019 10:50:35 +0200

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)

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

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

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 5 Apr 2019 15:12:45 +0300

On Fri, Apr 05, 2019 at 10:50:35AM +0200, Peter van Dijk wrote:
> 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.

> Neither seem feasible options to me.

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

> manu’s proposal explicitly targeted unsigned delegations, which I also think
> is an important use case.
> 

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

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 05 Apr 2019 14:21:17 +0200

Moin!

On 5 Apr 2019, at 10:50, Peter van Dijk wrote:

> manu’s proposal explicitly targeted unsigned delegations, which I 
> also think is an important use case.
No it isn’t. Can we please just use the technology we have to secure 
data in the DNS instead of coming up with yet another solution for it. 
If people don’t want to DNSSEC sign their own/primary domains they 
should put the name server into different domains that can be signed and 
thus authenticated.

> Glue records are never signed.
Which isn’t a problem as one can easily validate the records in the 
child.

So long
-Ralf
—--
Ralf Weber