Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

From: Roy Arends <[email-masked]>
Date: Tue, 28 Feb 2017 21:19:34 +0000

I have reviewed the draft.

Since the last update of this draft, a full collision has been found. 

Do the authors intend to update the draft to state that SHA1 SHOULD NOT be used for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC Delegation (DS and CDS algorithm 1) ?

Please also refrain from using MUST- SHOULD+ and SHOULD-.

Roy

> On 5 Jan 2017, at 21:28, Tim Wicinski <[email-masked]> wrote:
> 
> All
> 
> Since we're having so much fun on adopting work, let's have another one.  We discussed this work in Seoul, and there was a solid hum on adopting this work.
> 
> This starts a Call for Adoption for:
> draft-wouters-sury-dnsop-algorithm-update
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-algorithm-update/
> 
> Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 19 January 2017
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Feb 2017 16:35:40 -0500 (EST)

> Do the authors intend to update the draft to state that SHA1 SHOULD NOT be used for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC Delegation (DS and CDS algorithm 1) ?

That seems a bit dramatic to this author :)

We can't stuff PDF prefixes into this, there are a lot less bytes
for an attacker to play with.

> Please also refrain from using MUST- SHOULD+ and SHOULD-.

For this SHA1 case or in general? I'd say we could update the DNSSEC
Signing entry from MUST- to SHOULD NOT but I would leave SHA1 for
DNSSEC validation at MUST-.

There is a need to move people away from SHA1, but I don't think this
specific attack changing anything with respect to DNSSEC.

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 28 Feb 2017 13:45:06 -0800

The recommendations in the document are completely unclear if it is 
talking about:

- what should be in signer implementations
- what should be in validator implementations
- what someone who is starting to sign today SHOULD/MUST use
- what someone who is already signing SHOULD/MUST use

I think those four lists are probably different. Before the document is 
picked up by the WG, it would be good if it made clear which lists it is 
for.

My personal feeling is that if we do the third, we should say MUST NOT 
with any SHA1 algorithm because they're going to get nailed in the 
future by people who refuse to validate it. If we do the fourth, I would 
say SHOULD NOT use now and SHOULD change within two years (or some moral 
equivalent of that).

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Feb 2017 16:55:05 -0500 (EST)

On Tue, 28 Feb 2017, Paul Hoffman wrote:

> The recommendations in the document are completely unclear if it is talking 
> about:
>

That is clearly Section 3 in two seperate columns

> - what someone who is starting to sign today SHOULD/MUST use

Obviously pick one of the mandatory-to-implement DNSSEC Signing"
algortihms of Sesction 3. Obviously, picking a MUST over a SHOULD
would be a safer bet.

> - what someone who is already signing SHOULD/MUST use

Try to do the same as above, provided their software is fully testing
and can handle algorithm rollovers.

> I think those four lists are probably different.

The Signer / Validator column is obviously different, as the validator
needs to deal with the long tail versus insecurity, whereas the signer
software can be a little more aggressive in dropping support for weak
things. I don't see why the recommendation of "already signing" and
"newly signing" should be different, other then "ensure you can do an
algorithm rollover".

> Before the document is 
> picked up by the WG, it would be good if it made clear which lists it is for.

I do not think that is needed.

> My personal feeling is that if we do the third, we should say MUST NOT with 
> any SHA1 algorithm because they're going to get nailed in the future by 
> people who refuse to validate it. If we do the fourth, I would say SHOULD NOT 
> use now and SHOULD change within two years (or some moral equivalent of 
> that).

I don't think adding that much more flavours and granularity brings more
clarity. Heck, someone just said that our + and - symbols was already
too much granularity :P

And then we have some software people who say "we will never remove
anything because that can break our users' scripts".....

Paul

---

From: Roy Arends <[email-masked]>
Date: Tue, 28 Feb 2017 22:08:03 +0000

> On 28 Feb 2017, at 21:35, Paul Wouters <[email-masked]> wrote:
> 
> We can't stuff PDF prefixes into this,

We don’t need to.

> there are a lot less bytes

A CNAME chain will give you plenty of bytes to futz with. 

> For this SHA1 case or in general?

In general.

> I'd say we could update the DNSSEC
> Signing entry from MUST- to SHOULD NOT

Good. That is exactly my request.

> but I would leave SHA1 for

I’d say you have to update that as well to SHOULD NOT.

> There is a need to move people away from SHA1,

Yes, there is.

Roy

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Feb 2017 20:56:48 -0500 (EST)

> A CNAME chain will give you plenty of bytes to futz with.

None of the SHA1 hases we use are covering a chain of records.

>> For this SHA1 case or in general?

I disagree then. Did you read the motivation of why we use
those terms to clarify that we expect an algorithm to be
promoted or demoted in a future update?

> Good. That is exactly my request.

This is still only meaningful if the signer software vendors
in general agree with this. If they will just ignore this
document, then I feel there isn't much point in proceeding
with it.

> I’d say you have to update that as well to SHOULD NOT.

That is just unreasonable. Do you want half the the DNSSEC
signed zones in the world to go insecure or bogus?

Migration should be done responsibly.

Paul