Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 5 May 2017 08:30:18 -0400

> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <[email-masked]> wrote:
>> 
> 
> We kind of restarted the draft adopting RSASSA-PSS, so please can you
> review it this time from scratch without looking at the diff?
> 
> Many of the examples will need updating once algorithm numbers are
> assigned for them (as for some calculations, the algorithm number is an
> input), so we didn't spend time on wrapping the long lines in this
> revision.
> 

Ok I will bite and be the grumpy old man. 

I strongly advocate against the adoption of this document in current from. 
It violates basic interoperability guidelines by defining way to many 
algorithms with no justification why any of them are better or worse than others. 
There is no useful guidance on why these new algorithms are better even among themselves. 

One of the biggest hurdles to deployment is not in the 5-20 DNS software packages in wide use; but in all the 1000’s of Provision systems around the world,
and the crypto libraries found on various Enterprise systems that have life time of 4-8 years with security-only updates. 
Lets learn the lessons documented in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 <https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04>

I’m not convinced that SHA3 vs SHA2 matter at all given the constraint small data with strict constraints on order and contents is being signed. 

Thus why define 
    -  5 new  RSA algorithms proposed, why why ? ? 
    -  2 new ECDSA algorithms proposed why why ? ?
In another document there 2 other algorithms being proposed at the same time, that I support as they represent new and
faster technology.
All this will do is to cause confusion!

The RSA KEY size allowed for these new supposed stronger Digest algorithms is still left at 1024 or 1280 bytes, even though number of other parts of the the Internet community will not consider signatures by keys with less than 2048 bits. 

If there is any reason to go down the path of this document it should pick ONE RSA and ONE ECDSA algorithm.
RSA should be defined sensible guidelines on key sizes;  i.e. no keys below some stronger value in the 1536-2048 byte range.

The document is proposing two new DS algorithms WHY?
The basic reason for new a  DIS digest algorithm is “much better” so pick one and live with it. 

There was an interesting discussion on a resolver software mailing list few weeks back about what the RFC’s mean when there are DS records with different digest 
algorithm numbers: A domain had 2 DS records one with digest 1 one with digest 2; 
They both referred to the same key, but there was a typo/error in the digest with algorithm 2; 
Question what should the validator do ? 
a) only trust the highest digest number? 
b) trust any DS record ? 
I.e. a higher number was interpreted by the implementor to mean better thus only the highest supported number was the only one tried. 

Additionally this document in its current form contains proposed algorithm values which IMHO is a NoNo and I hope is removed from future versions. 
If there are interoperability tests you can define the numbers you want to use on web page; not in an internet draft that someone may go ahead and
implement not realizing that the final RFC will have a different number(s). 

Olafur

---

From: Russ Housley <[email-masked]>
Date: Fri, 5 May 2017 13:21:06 -0400

> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman <[email-masked] <mailto:[email-masked]>> wrote:
> 

I suggest that many of the options be dropped from this document before the working group accepts it.

I strongly support the move toward RSASSA-PSS or ECDSA.  Both of these offer an improvement over RSA PKCS#1 v1.5.  That said, we have a lot of experience that shows algorithm transitions are slow, so I think the working group should pick one of these signature algorithms, not both.

Why does this document support both SHA2 and SHA3?  We know that theses families of hash algorithms offer the same security.  That is, SHA2-256 and SHA3-256 offer exactly the same security.  One could argue that the reason to support both is because a flaw might be found in one and the other is there for safety.  Instead, I suggest that picking one family of hash algorithms already provides that safety.  One can use SHA2-384 or SHA2-512 if a flaw is discovered in SHA2-256.  So, again, pick one, not both.

Russ

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 May 2017 12:46:21 -0400 (EDT)

On Fri, 5 May 2017, Olafur Gudmundsson wrote:

> Lets learn the lessons documented in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04
> 

I agree. Especially in the light of how hard it is to remove obsolete
algorithms. We should have very good reasons to add new ones.

> The RSA KEY size allowed for these new supposed stronger Digest algorithms is still left at 1024 or 1280 bytes, even though number
> of other parts of the the Internet community will not consider signatures by keys with less than 2048 bits. 

Not only that, but the reason specified is to bump RSA from
RSASSA-PKCS1-v1_5 to RSASSA-PSS. As far as I know, the security
issues of RSASSA-PKCS1-v1_5 are that when using it to _encrypt_
bogus data, it can be used as an oracle to obtain private key
bits. That means there is no on-the-wire security issue with
RSASSA-PKCS1-v1_5 for Digital Signatures. And if HSMs are used
to protect access to private keys, those keys should be marked
as "signing only keys" to avoid exposing the private key via this
attack if the machine with the HSM is compromised.

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 8 May 2017 22:45:57 +0530

Hi Paul

> attack if the machine with the HSM is compromised.

It isn't that the RSASSA-PKCS1-v1_5 signature scheme is currently
broken. Revision 00 of the draft had used the RSASSA-PKCS1-v1_5 scheme
to make it easier for implementations, and so I was defending it among
colleagues at first.

However, RSASSA-PSS is a more robust signature scheme with a more exact
proof of security. We evaluated our choice and switched to that for use
with SHA-3 in revision 01 after it was pointed out on this list.

See "The Exact Security of Digital Signatures - How to Sign with RSA and
Rabin", Bellare and Rogaway for why it is an improvement (vs. FDH).

http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf

One nusiance of PSS is that it uses entropy during signing (a salt value
per signature) that may make it inconvenient for signing in environments
without an entropy source. However it is possible to to create
signatures with a non-random salt (so it was made a "SHOULD" in the
draft) with equivalent security to FDH. With the random salt, it is a
far more robust scheme for RSA signatures.

RSASSA-PKCS1-v1_5 is no longer allowed for new application due to its
lack of exact security.

I'll reply to the other comments soon.

		Mukund

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 May 2017 13:46:52 -0400

> On May 8, 2017, at 12:46 PM, Paul Wouters <[email-masked]> wrote:
> 

If we are going to stick with RSA signatures, then I agree that we should move toward RSASSA-PSS.  However, if we are going to make a change, then it is probably time to move toward the shorter public keys offered by elliptic cure cryptography.

Russ

---

From: Petr Špaček <[email-masked]>
Date: Tue, 16 May 2017 00:42:28 +0200

On 5.5.2017 14:30, Olafur Gudmundsson wrote:
> One of the biggest hurdles to deployment is not in the 5-20 DNS software
> packages in wide use; but in all the 1000’s of Provision systems around
> the world,
> and the crypto libraries found on various Enterprise systems that have
> life time of 4-8 years with security-only updates. 
> Lets learn the lessons documented
> in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04
> 
> I’m not convinced that SHA3 vs SHA2 matter at all given the constraint
> small data with strict constraints on order and contents is being signed. 
> 
> Thus why define 
> In another document there 2 other algorithms being proposed at the same
> time, that I support as they represent new and
> faster technology.
> The RSA KEY size allowed for these new supposed stronger Digest
> algorithms is still left at 1024 or 1280 bytes, even though number of
> other parts of the the Internet community will not consider signatures
> by keys with less than 2048 bits. 
> 
> RSA should be defined sensible guidelines on key sizes;  i.e. no keys
> below some stronger value in the 1536-2048 byte range.
> 
> There was an interesting discussion on a resolver software mailing list
> few weeks back about what the RFC’s mean when there are DS records with
> different digest 
> I.e. a higher number was interpreted by the implementor to mean better
> thus only the highest supported number was the only one tried. 
> 
> Additionally this document in its current form contains proposed
> algorithm values which IMHO is a NoNo and I hope is removed from future
> versions. 
> If there are interoperability tests you can define the numbers you want
> to use on web page; not in an internet draft that someone may go ahead and

Very well said, Olafur. I'm also against adoption of this document in
its current form.

-- 
Petr Špaček  @  CZ.NIC