Subject: [Dcrup] draft-ietf-dcrup-dkim-crypto-00

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 19 May 2017 04:51:47 -0700

Hi,

I suggest that 2048 bit RSA be considered the minimum key size.
Samller sizes are not really safe these days.

In any update of RSA, you really need to determine if your RSA keys will
be using RSASSA-PSS or PKCS#1 v1.5 padding and be careful in the
signature verification methods being used as well as specifying the use
of the SHA2 hash to be used if the key size is greater than RSA 3072
which is the largest that should probably use SHA2-256. RSA key sizes in
excess of 3072-bit keys may want to consider SHA2-384 or SHA2-512
hashes.

I note that you are suggesting signing using ECDH and wonder if you
intended to specify ECDSA or EdDSA as a way to digitally sign using
Elliptic Curve methods as generally ECDH is used for key agreement
protocols.

In section 5, you ask

[[ is there any reason to allow or require RSA keys longer than 2048 ? ]] 

I do not believe that this is required today. However, it will probably
be true in a short number of years.

The IETF CURDLE (CURves, Deprecating and a Little more Encryption) WG
has a few drafts you may wish to read such as

  draft-ietf-curdle-cms-eddsa-signatures

For this draft and others, you may visit:

  https://datatracker.ietf.org/wg/curdle/documents/

An informative reference for your consideration:

The National Institute of Standards and Technology (NIST) Special
Publication 800-131A [800-131A] disallows the use of RSA and DSA keys
shorter than 2048 bits for US government use after 2013.

  http://dx.doi.org/10.6028/NIST.SP.800-131Ar1

Another informative reference:

  Fault-Based Attack of RSA Authentication
  Andrea Pellegrini, Valeria Bertacco and Todd Austin
  http://web.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf

I hope you find the above information useful.

	Enjoy!
	-- Mark

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 May 2017 12:49:23 +0000

On May 19, 2017 7:51:47 AM EDT, "Mark D. Baushke" <[email-masked]> wrote:
>Smaller sizes are not really safe these days.

2048 bit keys present operational problems in common DNS provisioning systems.  What advice should we offer those not currently able to publish a TXT record long enough for 2048?

I don't think the answer is don't bother with DKIM because it's pointless with a key < 2048.  Given the ephemeral nature of a DKIM signature's value, there's probably a combination of shorter keys and key rotation that's perfectly fine.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 May 2017 13:48:36 +0000

> 2048 bit keys present operational problems in common DNS provisioning
> systems.  What advice should we offer those not currently able to publish a
> TXT record long enough for 2048?

Move to ECC which has much shorter keys with equivalent strength?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 May 2017 14:24:38 +0000

>Move to ECC which has much shorter keys with equivalent strength?

Eventually, sure, but sha-1 and sha-256 are what DKIM libraries support today.  The WG does need to answer questions about the future when new software can be developed and deployed, but IMO improved guidance for today's systems is much more urgent.  Keep in mind the current minimum is 512.

If we could spit out a document that says nothing more than:

MUST NOT sign/verify sha-1
MUST sign/verify sha-256

Key size MUST be 1024 and SHOULD be 2048

it would be an easy, quick win while we work on consensus about the next algorithm that should be added.

I volunteer to draft it if there's interest.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 19 May 2017 14:30:49 -0000

In article <[email-masked]> you write:
>2048 bit keys present operational problems in common DNS provisioning systems.  What advice
>should we offer those not currently able to publish a TXT record long enough for 2048?

Perhaps to read section 4 of the draft?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 May 2017 14:41:51 +0000

On May 19, 2017 10:30:49 AM EDT, John Levine <[email-masked]> wrote:
>systems.  What advice

What currently available DKIM software supports that approach?  I don't think any, so I believe that the question of what operators should do until new software can be developed and deployed is still open.

Until new signing key management/publishing or crypto achieve similar successful verification rates to what's currently fielded, they aren't suitable replacements.

For anything that requires code changes on the part of verifiers, it's going to take years before enough support new functionality that the d can be dropped.  What do people do in the meantime?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 19 May 2017 14:42:43 -0000

>Samller sizes are not really safe these days.

I'm surprised to hear this.  Remember that DKIM signatures are
relatively low value and not intended to be archival.  They're
typically verified within a day of being signed, and the design
encourages key rotation (although I admit that in practice most people
don't rotate very often.)

How much effort does it take to crack a 1k signature?

>excess of 3072-bit keys may want to consider SHA2-384 or SHA2-512

I don't purport to be a crypto expert and haven't a clue.  In practice
people use whatever "openssl genrsa" provides.  I'm not too worried
about keys bigger than 3K since I expect that by the time 2K keys
are too weak, people will migrate to a different algorithm.

>Elliptic Curve methods as generally ECDH is used for key agreement

Beats me.  What should we use to maximize interoperability and have
lots of free libraries ready to use?

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 May 2017 07:55:59 -0700

> don't rotate very often.)

Factoring a key gives the attacker the ability to sign messages, so how
quickly the signature is verified and its not being intended to be
archival is not relevant. Frequency of key rotation is the only thing
that matters (along with the value of the signature).
> How much effort does it take to crack a 1k signature?

From 2012: https://www.wired.com/2012/10/dkim-vulnerability-widespread/

tl;dr: factored a 512-bit key on AWS in 72 hours for $75. But that was 5
years ago. I haven't extrapolated to current compute costs/speeds or the
longer key.

-Jim

---

From: "John Levine" <[email-masked]>
Date: 19 May 2017 15:06:39 -0000

>What currently available DKIM software supports that approach?  I don't think any, so I believe that the question of what operators should do until new software can be developed and deployed is stil…

None.  In fact, I am reasonably sure that 1K keys are plenty strong
for DKIM for the next few years.  As I noted, DKIM keys and signatures
are intended to be short lived.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 19 May 2017 15:13:11 -0000

>years ago. I haven't extrapolated to current compute costs/speeds or the

Doesn't the factoring effort double with every added bit?  That would
suggest that 1K keys are still impractical to factor unless you have a
great deal of money and a great deal of time.

We knew 512 bit keys were too weak in 2006, but we had (perhaps
misplaced) pity for people running beta libraries.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 May 2017 15:28:06 +0000

> Until new signing key management/publishing or crypto achieve similar
> successful verification rates to what's currently fielded, they aren't suitable
> replacements.

ECC keys are already comparable.
 
> For anything that requires code changes on the part of verifiers, it's going to
> take years before enough support new functionality that the d can be
> dropped.  What do people do in the meantime?

This WG is chartered to do a couple of things:  document what should be done now, and giving advice.  I think Scott should write up a draft and offer it for adoption as it's clearly in-scope.  I think the existing "new crypto" should use new ECC based signatures and also, if necessary as a middle step, approach how to do RSA 2K.  Given DNS TXT contraints, I think it makes sense to have RSA 2K be a separate document from "ECC for DKIM."

Does this make sense to the WG members?

---

From: "John Levine" <[email-masked]>
Date: 19 May 2017 15:50:06 -0000

In article <[email-masked]> you write:
>use new ECC based signatures and also, if necessary as a middle step, approach how to do RSA 2K.  Given DNS TXT
>contraints, I think it makes sense to have RSA 2K be a separate document from "ECC for DKIM."
>

Given how short they both are, I'd like to keep them together for now.

R's,
John

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 May 2017 13:02:27 -0400

> How much effort does it take to crack a 1k signature?

NIST has told everyone to move away from SHA-1 for for all uses except HMAC-SHA-1.

NIST has told everyone to move toward RSA with 2048 bit keys, even for entity authentication applications like DKIM.

If RSA keys of that size are a problem, then it it time to start the transition to Elliptic Curve.  We know it will not happen the day the RFC gets published.

Russ

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 May 2017 13:18:17 -0400

On Friday, May 19, 2017 03:28:06 PM Salz, Rich wrote:
> > successful verification rates to what's currently fielded, they aren't
> > suitable replacements.
> 
...

Generally, yes, but DKIM verifiers don't support it currently, so for this 
purpose, not yet.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 May 2017 17:20:43 +0000

> Generally, yes, but DKIM verifiers don't support it currently, so for this

This issue of "we need to move forward; we have an installed base" is not new.  RSA2K doesn't fit in many DNS TXT records, so I think that will be an additional driver to upgrade.  You may disagree.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 May 2017 17:36:29 +0000

> Given how short they both are, I'd like to keep them together for now.

Ok.

Speaking as an individual, I'd like to emphasize what Mark said.  ECDH is a key exchange protocol, not a signing protocol.  For elliptic curve signatures, the document should use https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ which is now in IESG last call.  Note that the hash mechanism is implicit in the signature algorithm.

The key fingerprint needs more clarification.  For 25519 keys, there is a "natural and obvious" byte representation, but for RSA keys what is  being fingerprinted?  The DER OCTET STRING?

---

From: Peter Goldstein <[email-masked]>
Date: Fri, 19 May 2017 10:40:10 -0700

It's going to be hard to move straight to 2048 bit RSA as the minimum key
size.

The challenges with 2048 bit RSA are largely an issue of the limitations of
the DNS infrastructure in use by the sending domain.  In some DNS managers,
the Web UIs (and occasionally the underlying infrastructure) don't allow
domain owners to enter records that are larger than 512 octets.  Users of
these DNS managers generally cannot provision 2048 bit key DKIM TXT
records.  That's a problem for self-managed infrastrucutre and email
services that provide TXT records for DKIM.

Also, as far as I'm aware almost none of the existing email service
providers offers the option of a 2048 bit DKIM key out of the box.  For
those systems that use CNAMEs, upgrading to 2048 bit keys will be
relatively straightforward.  But for those that distribute TXT records
(most of them), they will face more of a challenge to upgrade their users
to 2048 bit keys - both because of the above domain limitations and because
they're going to need to get their customers to make DNS changes.

Given the above, Scott's suggested approach for RSA sounds like the right
one - especially if we can combine it with statements from the large
receivers that they will plan to sunset support for 1024 bit keys (much as
they did for 512 bit keys) at some point in the future.  That will both
incentivize domain owners and email services to upgrade their key size to
2048 and give the ecosystem time to adjust.
That said, I think it's also important to start the process of
transitioning to Elliptic Curve.  Defining the updates to the spec, getting
some software to support it (i.e. OpenDKIM), and working with the large
receivers to get them onboard are all steps that can be taken in parallel
with Scott's suggested approach for RSA keys.

Best,

Peter

On Fri, May 19, 2017 at 10:02 AM, Russ Housley <[email-masked]> wrote:

> NIST has told everyone to move toward RSA with 2048 bit keys, even for
> entity authentication applications like DKIM.
>
> If RSA keys of that size are a problem, then it it time to start the
> transition to Elliptic Curve.  We know it will not happen the day the RFC
> gets published.
>
> Russ
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: "John Levine" <[email-masked]>
Date: 19 May 2017 17:42:07 -0000

In article <[email-masked]> you write:
>This issue of "we need to move forward; we have an installed base" is not new.  RSA2K doesn't fit in many DNS TXT
>records, so I think that will be an additional driver to upgrade.  You may disagree.

Just to make it clear, 2K keys fit in TXT records just fine.  The
problem is provisioning crudware that can't handle TXT records with
more than one string.  This is a really stupid problem, but it's one
that is not going away any time soon, hence the two approaches to
putting shorter keys or key hashes in the DNS.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 May 2017 13:46:27 -0400

On Friday, May 19, 2017 05:20:43 PM Salz, Rich wrote:
> This issue of "we need to move forward; we have an installed base" is not
> new.  RSA2K doesn't fit in many DNS TXT records, so I think that will be an
> additional driver to upgrade.  You may disagree.

I agree there will be drivers to upgrade, but regardless of the drivers, 
upgrades take time.  I think we have two problems to address:

1.  What can be done within the scope of deployed software that was developed 
based on the RFC 6376 requirements (which can be deployed now)

2.  What should be done to modernize crypto for DKIM for the longer term that, 
while it will require software upgrades, will keep DKIM fit for purpose for a 
long (FSVO long) time.

I think they both are important.  I think the first one is really easy to 
specify and cross off the list (I am personally very interested in being able 
to tell people "No, I don't have to verify your 512 bit key.  RFC 6376 has 
been updated by RFC XXXX.  Please join the latter half of the second decade of 
the 21st century).

It's likely we disagree less than I infer you imagine.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 May 2017 17:51:50 +0000

> It's likely we disagree less than I infer you imagine.

I think we don't disagree at all.  I'm just more optimistic about ECC deployment. :)

I look forward to your draft!

---

From: Steve Atkins <[email-masked]>
Date: Fri, 19 May 2017 11:01:01 -0700

> On May 19, 2017, at 8:06 AM, John Levine <[email-masked]> wrote:
> 
> for DKIM for the next few years.  

Likely big enough for the near future, yes (and 1.5k keys for longer still, and even 2k keys are less than 400 bytes long, which still leaves plenty of space in a 512 byte response).

> As I noted, DKIM keys and signatures

That was the plan, but in practice DKIM selectors (and presumably the associated key pairs) seem to be commonly deployed once, when the user sets up DKIM and never changed until the mail infrastructure is next updated.

The organizations represented here are probably better at key rotation than most and here I see selectors of "jan2016.eng", "20161025" and "ietf1", none of which suggest regular rotation.

They're not short-lived and (unless we somehow enforce key rotation) our crypto decisions should probably be informed by that.

Cheers,
  Steve

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 May 2017 14:18:02 -0400

> On May 19, 2017, at 1:36 PM, Salz, Rich <[email-masked]> wrote:
> 

I can make argument for both Ed25519 and ECDSA P256 with SHA-256.  I know that the second one is widely available via OpenSSL.

Russ

---

From: "John R Levine" <[email-masked]>
Date: 19 May 2017 14:48:38 -0400

> Speaking as an individual, I'd like to emphasize what Mark said.  ECDH is a key exchange protocol, not a signing protocol.  For elliptic curve signatures, the document should use https://datatracke…

That's fine, like I said I don't purport to be a crypto expert.  Even 
better, send text.

> The key fingerprint needs more clarification.  For 25519 keys, there is 
> a "natural and obvious" byte representation, but for RSA keys what is 
> being fingerprinted?  The DER OCTET STRING?

IIM had key fingerprints.  Perhaps Jim can tell us what it did.

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 May 2017 11:58:09 -0700

On 5/19/17 11:48 AM, John R Levine wrote:
>> Speaking as an individual, I'd like to emphasize what Mark said. 
>> ECDH is a key exchange protocol, not a signing protocol.  For
>> elliptic curve signatures, the document should use
>> https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/
>> which is now in IESG last call.  Note that the hash mechanism is
>> implicit in the signature algorithm.
>
>> The key fingerprint needs more clarification.  For 25519 keys, there
>> is a "natural and obvious" byte representation, but for RSA keys what
>> is being fingerprinted?  The DER OCTET STRING?
>

>From https://www.ietf.org/archive/id/draft-fenton-identified-mail-02.txt :

The fingerprint is created as follows: create the binary
representation of the RSA exponent (e) and modulus (n) and
concatenate them as e|n.  Run this value through SHA1 over the
full length and convert the first 12 bytes of the output of the
SHA1 operation to base 64.  That is, base64 (TRUNC (SHA1 ((e|n)),12)

-Jim

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 19 May 2017 19:00:37 +0000

> representation of the RSA exponent (e) and modulus (n) and

What is the binary representation?  Is it the DER or the native BIGNUM format?

---

From: Jim Fenton <[email-masked]>
Date: Fri, 19 May 2017 12:08:56 -0700

> What is the binary representation?  Is it the DER or the native BIGNUM format?

I can't remember; this was back in 2005 and Mike Thomas did the
implementation.

Regardless, I wouldn't do the same thing today. Use SHA256 instead of
SHA1, and I'm not sure the truncation is a good idea.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 May 2017 16:52:53 -0400

> I look forward to your draft!

Your turn:

Submission status: Awaiting Initial Version Approval

The submission is pending approval by the group chairs.

Scott K