Subject: Re: [DNSOP] zonemd/xhash versus nothing new

From: Petr Špaček <[email-masked]>
Date: Wed, 1 Aug 2018 09:43:08 +0200

On 31.7.2018 16:58, Tony Finch wrote:
> Petr Špaček <[email-masked]> wrote:
>> On 30.7.2018 15:32, Tony Finch wrote:
>>>
>>> I keep thinking it might make sense to sign non-authoritative delegation
>>> records, though it's really hard to see how we could get there from here.
>>> For instance, there isn't a flags field in RRSIG so you can't explicitly
>>> mark an RRset as being non-authoritative.
>>
>> It is! RRSIG has signer name field which points to node with particular
>> DNSKEY. If signer name is shorter than zone apex name the signature was
>> created by someone up the tree.
> 
> It would be nice if that is enough :-) For NS records the RRSIG signer
> will either be the same as the owner (apex RRset) or shorter (delegation
> RRset). For glue it's not so clear-cut if you don't have any
> apex/delegation records to hand. But maybe the other context is enough -
> the section that the records appear in, the RFC 2181 priority order.
> 
> The other question I can't answer is whether existing validators will be
> discombobulated by an RRSIG of unknown algorithm on a delegation NS
> RRset...

Well, there is a posibility not to send out these RRSIGs for normal
queries. Auth server has to have special code to handle delegations
anyway so I can imagine that these parent-side RRSIGs are present only
in zone transfer.

One problem I can see is that these additional RRSIGs effectively
prevent modification of data but not removal of glue (or NS in out-out
intervals) ...

-- 
Petr Špaček  @  CZ.NIC

---

From: Tony Finch <[email-masked]>
Date: Wed, 1 Aug 2018 12:29:36 +0100

> prevent modification of data but not removal of glue (or NS in out-out

I was kind of assuming that the NSEC chain would include the glue -
obviously delegations and glue in opt-out intervals are not protected at
all.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: South or southwest 4 or 5,
occasionally 6 at first in Cromarty and Forth, then becoming variable 3 at
times. Slight throughout in Tyne and Dogger, but elsewhere slight or moderate.
Fair then rain at times. Good, occasionally moderate.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Aug 2018 12:02:49 +0000

>obviously delegations and glue in opt-out intervals are not protected at

The reason cut point information is not signed is that the copies are not authoritative, that is, the delegating zone is not the source of the records, they are merely hints.

The reason this wasn't seen as an oversight is the thought that if bad glue were followed, the DNSSEC chain would not work (for the data set sought) so long as the private keys (involved) were private.

The reason there is no overall zone signature is that the goal was data (set) integrity, not zone transfer integrity.

If the issue is zone transfer integrity, a solution will need to go beyond what DNSSEC is defined to be now.  (Not saying this is an obstacle, pointing out that DNSSEC wasn't designed to do accomplish that.)

FWIW, there's TSIG protection of AXFR messages (hop-by-hop), which isn't DNSSEC and then other operational practices, as examples of other tools.  (That is obvious to many, just including for completeness.)

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 01 Aug 2018 09:14:42 -0700

Maybe changing RFC 4034 and RFC 4035 to have RRSIGs over 
non-authoritative data is not the right way to go. It could break some 
current validators, and it would be hard to let zones sign some but not 
all of the non-authoritative data. (For example, I could imagine a zone 
owner wanting to sign the child NS records but not the glue records.)

Instead, of the WG wants this functionality, it might be cleaner to 
create a new record that acts like RRSIG but is used only on 
non-authoritative data. Think of it as NONAUTH-RRSIG. We would need to 
define the new RRtype (with a lot of pointers to RFC 4034), how it is 
used to sign (with a lot of pointers to RFC 4035), how authoritative 
servers would include those records in responses, and how validators 
would handle the records (this would probably be the trickiest part).

This would lead to a cleaner upgrade path both for authoritative servers 
and resolvers, and thus maybe make it more palatable to the current 
DNSSEC-using population.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Aug 2018 09:31:45 -0700

I strongly prefer a regular rrtype over any kind of special processing or complicating dnssec further.

If axfr signatures aren’t enough because people envision non-dns zonefile transports, do a single ZONEMD, which signs the whole thing or only all records without RRSIG.

Paul

Sent from my phone

> On Aug 1, 2018, at 09:14, Paul Hoffman <[email-masked]> wrote:
> 
> Maybe changing RFC 4034 and RFC 4035 to have RRSIGs over non-authoritative data is not the right way to go. It could break some current validators, and it would be hard to let zones sign some but not all of the non-authoritative data. (For example, I could imagine a zone owner wanting to sign the child NS records but not the glue records.)
> 
> Instead, of the WG wants this functionality, it might be cleaner to create a new record that acts like RRSIG but is used only on non-authoritative data. Think of it as NONAUTH-RRSIG. We would need to define the new RRtype (with a lot of pointers to RFC 4034), how it is used to sign (with a lot of pointers to RFC 4035), how authoritative servers would include those records in responses, and how validators would handle the records (this would probably be the trickiest part).
> 
> This would lead to a cleaner upgrade path both for authoritative servers and resolvers, and thus maybe make it more palatable to the current DNSSEC-using population.
> 
> --Paul Hoffman
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 01 Aug 2018 09:45:34 -0700

> or complicating dnssec further.

Agree.

> If axfr signatures aren’t enough because people envision non-dns 
> zonefile transports, do a single ZONEMD, which signs the whole thing 
> or only all records without RRSIG.

My proposed NONAUTH-RRSIG is not exclusively for zonefile transport. It 
would be useful for normal resolver-authoritative queries as well.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Wed, 1 Aug 2018 12:57:45 -0400

Hi Paul,

I agree that it would be foolish to change 4034/4035 without understanding the implications of doing so (e.g. breaking validators).

However, it's possible that it would be a fairly minor semantic change, e.g. if signing records with an owner name below a zone cut was optional and if validator code paths were not much affected (they could either validate when they saw the RRSIG or ignore the RRSIG, either way it's possible that things would not break).

Before the idea of using RRSIGs to sign records that are currently specified not to be signed is thrown away, is it perhaps worth exploring it a little more deeply?

Joe

> On Aug 1, 2018, at 12:14, Paul Hoffman <[email-masked]> wrote:
>