Subject: [Dcrup] I do not like the dcrup ECC document

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jul 2017 16:14:09 +0000

Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wrong.

It specifies curve P256 and ECDSA.  The IETF is moving off of ECDSA to deterministic ECC signatures, and also moving toward the 25519 and 448 curves.

As this is a completely new signature use, unencumbered by an installed base (and probably codebase), I think we should specify the mechanisms in https://datatracker.ietf.org/doc/rfc8032/

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 6 Jul 2017 10:04:42 -0700

Salz, Rich <[email-masked]> writes:

> It specifies curve P256 and ECDSA. The IETF is moving off of ECDSA to
> deterministic ECC signatures, and also moving toward the 25519 and 448
> curves.

+1 I support use of 25519..

> As this is a completely new signature use, unencumbered by an
> installed base (and probably codebase), I think we should specify the
> mechanisms in https://datatracker.ietf.org/doc/rfc8032/

This seems reasonable to me.

	-- Mark

---

From: "Rose, Scott" <[email-masked]>
Date: Fri, 7 Jul 2017 09:15:40 -0400

Some deployments have an additional requirements on using FIPS-140 
approved algorithms.  There is work on trying to get the Edwards curves 
on that list, there isn’t a reliable timeframe for when that will 
happen.

Until then, this is a proposed option to get those DKIM users an option 
that they can use.

Scott

> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup

===================================
Scott Rose
NIST ITL
[email-masked]
+1-301-975-8439
GV: +1-571-249-3671
===================================

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Jul 2017 15:09:39 +0000

Since the entire IETF is moving to the Edwards curves, is there a deployment requirement for FIPS P256 now?  Or can those who need FIPS algorithms for signing keys stick with RSA?

If P256 is needed now, then I think we should have one document that covers Ed25519 and P256, or at least modify the draft names and titles to make it clear that this is “a” choice, not “the” choice for ECC DKIM signatures.

If DNS operators aren’t well versed in crypto, do we need to be concerned about them deploying DSA?
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 7 Jul 2017 08:25:07 -0700

Salz, Rich <[email-masked]> writes:

> Since the entire IETF is moving to the Edwards curves, is there a
> deployment requirement for FIPS P256 now? 

Given the NSA IAD Commercial National Security Algorithm Suite letter
(URL: https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm)

The trend seems to be against P256. Of course, "top secret" documents
will NOT be sent via SMTP in any case.

> Or can those who need FIPS algorithms for signing keys stick with RSA?

If what I heard at the ICMC17 conference this year is correct, then I
believe that Ed 25519 and/or Ed 448 will be getting added to the list of
approved algorithms before too long (within the next year).

	-- Mark

---

From: "Rose, Scott" <[email-masked]>
Date: Fri, 7 Jul 2017 11:29:54 -0400

> approved algorithms before too long (within the next year).

 From inter-office talk, yes it will be added, and everyone wants to be 
added.  Bureaucracy and sudden fire drills slow things down.

I would like for this draft to not be needed, and one option is to just 
continue to use 2048-bit RSA for DKIM until the curves are added.  That 
is the only apparent way forward for now.

Scott

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Jul 2017 11:30:12 -0400

On Friday, July 07, 2017 03:09:39 PM Salz, Rich wrote:
> Since the entire IETF is moving to the Edwards curves, is there a deployment
> requirement for FIPS P256 now?  Or can those who need FIPS algorithms for
> signing keys stick with RSA?
 
> If P256 is needed now, then I think we should have one document that covers
> Ed25519 and P256, or at least modify the draft names and titles to make it
> clear that this is “a” choice, not “the” choice for ECC DKIM signatures.
 
> about them deploying DSA?

Every option you add, implementers need to add signing and verification code 
for (even if it's just more calls to appropriate libraries).  As far as I know 
there's no security urgency to using ECC now.  The reason to add it now is to 
future proof the protocol.

If there is a transient issue with some implementers not using ECC due to 
internal policy reasons, I don't think that should affect the WG's path.

Adding one ECC DKIM method is enough.  "For now" anyone who doesn't like the 
curves the IETF picked can stick with RSA.  If the IETF needs to be making 
different choices in the ECC arena, I don't think this is the right WG to work 
that out.

So far I'll have to add the sha256 hashed DNS record approach and one ECC 
method.  I think those are reasonable.

Now maybe it's maybe two ECC schemes and adding PSS in addition to supporting 
PKCS#1v1.5 (mentioned in Review of draft-ietf-dcrup-dkim-crypto-03) plus the 
hashing.

Every single option has to be widely deployed by both senders and receivers 
before it can realistically be used in the field.  If we just keep piling on 
the options it gets insane.  Maybe I have to sign a message seven times to get 
interoperability:

rsa-sha1 (because some people use ancient stuff)
rsa-sha256
rsafp
rsa-sha256 PSS
rsafp PSS
ECC Ed25519
ECC P256

If we specify too many new options, that will ensure none of the them get 
deployed until there's a disaster discovered around rsa-sha256.

Personally, I've started work on rsafp and plan to do Ed25519, but there's no 
way I'm up for coding more options just because someone thought it'd be a nice 
idea.

Scott K

---

From: denis bider <[email-masked]>
Date: Fri, 7 Jul 2017 17:29:37 -0600

Agreed. It is a substantial advantage of DKIM as-is that the only algorithm
that needs to be supported is RSA.

Adding "rsafp" and one elliptic curve option makes for 3 algorithms to be
supported by everyone. That's plenty.

If anything, I'd cut "rsafp" so that there are only two options (RSA and
EC). Users affected by crudware can migrate to EC instead of large RSA
keys. But this might not be a popular option.

On Fri, Jul 7, 2017 at 9:30 AM, Scott Kitterman <[email-masked]>
wrote:

> deployment

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2017 20:34:14 -0000

In article <[email-masked]> you write:
>It specifies curve P256 and ECDSA.

Here's what -03 says:

3.  EdDSA-SHA256 Signing Algorithm

   The eddsa-sha256 signing algorithm computes a message hash as defined
   in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA
   algorithm using the edwards25519 curve, as defined in in RFC 8032
   section 5.1 [RFC8032].  The signing algorithm is PureEdDSA as defined
   in RFC 8032 section 4, since the input to the signing algorithm has
   already been hashed.  The DNS record for the verification public key
   MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather
   than RSA key.

If that's not right, please send text.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 13:48:50 -0700

Just as a technical point:

ECDSA works with P-256, P-384, and P-521
EdDSA works with Curve25519 and Curve448

I read the text above as using EdDSA with Curve25519.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Sun, 9 Jul 2017 16:57:37 -0400

> If that's not right, please send text.

PureEdDSA does not take a hash as input, it takes the whole to-be-signed content.

Russ

---

From: "John R Levine" <[email-masked]>
Date: 9 Jul 2017 16:59:22 -0400

> I read the text above as using EdDSA with Curve25519.

That's what I intended.

Not being a crypto geek, I was hoping the people who are crypto geeks 
could let me know if I haven't cribbed the right parts from RFC 8032.

>> If that's not right, please send text.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 9 Jul 2017 17:14:13 -0400

> PureEdDSA does not take a hash as input, it takes the whole to-be-signed content.

RFC 6376 describes in great detail in section 3.7 how to create the 
material to be signed.  What it ends up with is a sha-256 hash, but that's 
not the signing algorithm's problem.  I say PureEdDSA to emphasize that it 
doesn't get hashed again.

As it stands now, the RSA and EdDSA signing algorithms sign the same 
thing.  I suppose I could extensively rewrite the signing instructions so 
that stuff to be signed by RSA is hashed while stuff to be signed by EdDSA 
is not because it'll use HashEdDSA, but that seems a lot of work and a lot 
of code changes for no benefit.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 09 Jul 2017 17:22:12 -0400

> of code changes for no benefit.

The python crypto library I plan to use for this (python-nacl) supports both.  
Given the current structure of the dkimpy code, it would be much simpler to 
support PureEdDSA.  Having looked at how I would implement this (but not 
having done it yet) I agree with your contention about implementation 
complexity.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 9 Jul 2017 23:50:41 -0700

> of code changes for no benefit.

+1, unless there is such benefit and someone could describe it (or point us
to a reference that does so).

-MSK, participatin'

---

From: Brandon Long <[email-masked]>
Date: Mon, 10 Jul 2017 16:08:23 -0700

On Sun, Jul 9, 2017 at 11:50 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> +1, unless there is such benefit and someone could describe it (or point
> us to a reference that does so).
>

Is there any cryptographic reason why doing this is worse?

Brandon