Subject: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Jul 2017 13:20:12 +1000

In its current form, I had a hard time extracting the goals of this
document from the text, even though the abstract is clear, the
introduction isn't clear enough on the specifics, see below.

I think that Scott's draft does a much better job of the SHA-1 removal
and attempting to do this all at once in this document isn't helping
its clarity at all.  (Also, this practice of patching RFCs by
providing replacement for statements in them makes reading the update
as a standalone document unnecessarily difficult in my opinion.)

On hashing here: hash everything.  Ed25519 might be the last algorithm
that has a key that is this small.  Uniformity is more valuable than
space here.

On PSS: I think that the idea is to retain the existing primitive with
the fingerprint-based mode, so we should define "rsafp" as using
PKCS#1v1.5 and accept the shortcomings of that.  I would support the
addition of a PSS-based scheme.

Introduction

The framing of this document needs to be improved.  The point of this
draft is to define new ways to sign e-mail messages that are stronger
than what the existing mechanisms allow.

The first paragraph here is good, it establishes that the existing
mechanism (the only one!) is limited by real practical concerns.

The second paragraph should instead say that it is introducing
signature algorithms:

~~~
This document adds two signing mechanisms for DKIM.  A mechanism using
the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] is
defined in Section 3.  A variant of RSA signatures that uses the
existing underlying RSA primitives is defined in Section 4.  This RSA
variant uses a hashed representation of the public key that allows for
use of larger keys.
~~~

Section 3

This could be more direct:
~~~
3. Signature with Ed25519

The "ed25519" signature algorithm uses Ed25519 [RFC8032] and SHA-256 [SHA-2].

To use this signature method, the message is canonicalized according
to [RFC6376] then hashed using SHA-256.  The hash is signed using the
Pure variant of Ed25519.

This signature algorithm is identified with the value "ed25519" in the
"k=" parameter of a textual key representation and the value
"ed25519-sha256" in the "a=" parameter of the DKIM-Signature header
field.
~~~

IMPORTANT: This should be "ed25519" instead of "eddsa"; we've started
identifying a single primitive in other protocols, and you don't want
to contort things if you ever have to add Ed448.

Section 4

In the same way, this could be direct.  This is defining a new
signature algorithm.  The description can explain how this diverges
from the existing norm, but still be a complete specification.

~~~
The "rsafp" signature algorithm uses the same RSA-PKCS#1v1.5 [RSA-REF]
primitive to sign as that used in "rsa".  However, this algorithm
places a hash of the public key in textual representation in place of
the DER-encoded RSAPublicKey defined in [RFC6376].  This allows for
use of larger keys without the need for larger textual
representations, which might otherwise exceed the space in DNS TXT
records.

The method for signing a message is the same as that described for
"rsa-sha256" in [RFC6376].  The signer MUST also include a "p="
parameter in the DKIM-Signature header field (see Section XXX).  This
parameter includes the base64- and DER-encoded RSAPublicKey that was
used to generate the signature.

Textual representations of "rsafp" keys are identical to that of
"rsa-sha256", except that the "p=" parameter contains a SHA-256 hash
of the DER-encoded RSAPublicKey.  This limits the size of the textual
representation.

In addition to verifying the signature using this public key, a
verifier MUST also ensure that the decoded "p=" parameter that
accompanies the signature is equal to the SHA-256 hash of the decoded
"p=" parameter from the textual representation of the key.

This signature algorithm is identified with the value "rsafp" in the
"k=" parameter of a textual key representation and the value
"rsafp-sha256" in the "a=" parameter of the DKIM-Signature header
field.
~~~

IMPORTANT: The document then needs a new section defining "p=" for use
in DKIM-Signature.

This paragraph doesn't seem to be adding any value:

   Section 3.7 of [RFC6376], on computing the message hashes, is not
   modified.  Since the key in the k= tag is known in advance, it [is]
   included in the signature in the same manner as all of the other
   signature fields other than b=.

Sections 3 and 4

Both Section 3 and Section 4 need to explicitly say that the "h="
parameter is not valid for the algorithms defined in this document and
that SHA-256 is the only allowed hash algorithm that can be used with
these.  The current structure does not permit the use of a different
hash algorithm for the fingerprint; we should be prepared to define a
new identifier if we ever need to provide a SHA-256 alternative.

Nits

Capitalize "section" throughout.

There is a reference to FIPS-180 in a table, but it doesn't appear in
the references section.

---

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

As an individual ...

> I think that Scott's draft does a much better job of the SHA-1 removal and
> attempting to do this all at once in this document isn't helping its clarity at all.

I assume you mean Scott Kitterman and not Scott Rose. :)  I think we should refer to documents by name to avoid the ambiguity (and keep in mind that these are WG documents, not individual authors's).

> On hashing here: hash everything.  Ed25519 might be the last algorithm that
> has a key that is this small.  Uniformity is more valuable than space here.

I disagree, and so far the WG seems to be leaning against this view.  We'll talk in Prague, of course, but right now the only voices for hashing are you and ekr.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Jul 2017 08:30:43 -0700

On Fri, Jul 7, 2017 at 8:06 AM, Salz, Rich <[email-masked]> wrote:

> and
> I assume you mean Scott Kitterman and not Scott Rose. :)  I think we
> should refer to documents by name to avoid the ambiguity (and keep in mind
> that these are WG documents, not individual authors's).
>
> that
> I disagree, and so far the WG seems to be leaning against this view.
> We'll talk in Prague, of course, but right now the only voices for hashing
> are you and ekr.
>

Also Jim Fenton, I believe.
https://www.ietf.org/mail-archive/web/dcrup/current/msg00304.html

-Ekr

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

---

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

> Also Jim Fenton, I believe.

Oops, you are correct.  Thanks.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 7 Jul 2017 07:18:18 -1000

> Oops, you are correct.  Thanks.

Confirming, I favor hashing.

-Jim

---

From: Jon Callas <[email-masked]>
Date: Fri, 7 Jul 2017 12:58:44 -0700

> On Jul 7, 2017, at 10:18 AM, Jim Fenton <[email-masked]> wrote:
> 
> 
> 

For what it's worth, I agree with Jim and Ekr. Hashing is just fine.

	Jon

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Jul 2017 16:02:23 -0400

On Friday, July 07, 2017 12:58:44 PM Jon Callas wrote:
> >>>> We'll talk in Prague, of course, but right now the only voices for
> >>>> hashing are you and ekr.>>> 

For the ECC algorithm we're considering what advantage does it have?  As far 
as I can tell, it adds implementation complexity and provides no gain.  
Anytime you add complexity, you add risk of defects that negatively affect 
interoperability.

I would be a mistake to add more complexity to this, because it is 'just 
fine'.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 8 Jul 2017 02:24:05 +0000

> For what it's worth, I agree with Jim and Ekr. Hashing is just fine.

Is it fine, or is it a required or just good?

Nobody is saying there is anything wrong with hashing.  Several are saying that, given the limitations of some DNS deployments, it is useful to avoid the indirection and just put the key when we can.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 7 Jul 2017 21:08:06 -1000

> Nobody is saying there is anything wrong with hashing.  Several are saying that, given the limitations of some DNS deployments, it is useful to avoid the indirection and just put the key when we ca…

What DNS deployment limitation would be adversely affected by the use of a hash? I can't think of any.

"Avoid the indirection" makes it sound like more network round-trips would be required if a hash is used. No more network traffic is involved; the verifier only needs to compute the hash of the key included in the message and compare that with the fingerprint included in the key lookup response from DNS. The verifier can even check the signature prior to receiving the DNS response, if it wants.

I'm supporting publishing key fingerprints because I think it's slightly more future-proof, and having been burned by that once already, I don't want to make the same mistake again. But if rough consensus decides otherwise, we go with that of course.

I still haven't heard an answer to the following question I posed about the fingerprints, though: Will the fingerprints always be sha256, or do we need to specify the fingerprint algorithm in the DNS record? In other words, will we assume that sha256 will be strong enough for the life of this protocol?

-Jim

---

From: Jon Callas <[email-masked]>
Date: Sat, 8 Jul 2017 00:40:50 -0700

> On Jul 7, 2017, at 7:24 PM, Salz, Rich <[email-masked]> wrote:
> 

Fine. Into just good.

> Nobody is saying there is anything wrong with hashing.  Several are saying that, given the limitations of some DNS deployments, it is useful to avoid the indirection and just put the key when we ca…

Yeah, I know. They've mentioned the limitations of some DNS implementations going back to the original DKIM work. It's true, but I tend to be on the side of just sucking it up and doing a big DNS query over TCP or whatever. 

I'm also with Jim Fenton that I think the fingerprints make things more future-proof, and I'd make some trivial encoding to put the algorithm along with it for even more future-proofing.

	Jon

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 08 Jul 2017 10:00:47 +0000

On July 8, 2017 3:40:50 AM EDT, Jon Callas <[email-masked]> wrote:
>> Nobody is saying there is anything wrong with hashing.  Several are
>saying that, given the limitations of some DNS deployments, it is
>useful to avoid the indirection and just put the key when we can.
>
>Yeah, I know. They've mentioned the limitations of some DNS
>implementations going back to the original DKIM work. It's true, but I
>tend to be on the side of just sucking it up and doing a big DNS query
>over TCP or whatever. 
>
>I'm also with Jim Fenton that I think the fingerprints make things more
>future-proof, and I'd make some trivial encoding to put the algorithm
>along with it for even more future-proofing.

Let's imagine we go down the path of hashing everything.  When we want to add another new algorithm, how does having hashed the ECC key record help?

It will still need a new RFC to define the new algorithm usage.

It will still need new code to use the new algorithm.

What future proofing does it buy?

Also, you don't need to futz with the DNS record format to specify the algorithm.  That's already in the signature, so the verifier has that information before they even do the DNS lookup.

Scott K

---

From: Peter Goldstein <[email-masked]>
Date: Sat, 8 Jul 2017 10:52:00 -0700

I agree with Scott.  I'm not sure what all this talk about future proofing
is about.  In this case hashing is a hack to work around DNS crudware that
doesn't properly support strings in excess of 255 bytes.

Unless I'm misreading RFC 8032 (certainly possible), the base 64 encoded
public key itself for Ed25519 is going to be just 64 characters.  Throw in
the version string and a couple of other tags and we'll be lucky to hit a
max size of 90 octets for the record.  That's well below the 255 byte limit
imposed by DNS crudware.  Even if future signature algorithms had 2x or 3x
bytes in the key, we'd still come in under the 255 byte limit.

Using a fingerprinted representation for Ed25519 just creates more work
with absolutely no benefit.  With fingerprinting the key itself needs to be
included in every single email message (consuming space) and the
fingerprint check needs to be done on each DKIM check (consuming
time/CPU).  And the whole verification process is just more complex.

We might, at some point in the future, have a non-RSA algorithm that
requires records that exceed 255 bytes.  But that's by no means a given, or
even a likelihood.  And per Scott's email, in that case we're still going
to need to define a new RFC, write new code, etc.

Best,

Peter

On Sat, Jul 8, 2017 at 3:00 AM, Scott Kitterman <[email-masked]>
wrote:

> Let's imagine we go down the path of hashing everything.  When we want to
> add another new algorithm, how does having hashed the ECC key record help?
>
> Also, you don't need to futz with the DNS record format to specify the
> algorithm.  That's already in the signature, so the verifier has that
> information before they even do the DNS lookup.
>
> Scott K
>

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783

---

From: James Cloos <[email-masked]>
Date: Sat, 08 Jul 2017 16:14:28 -0400

I haven't written about this because it seemed to be going ok, but I
have to agree that hashing 256-bit keys or signatures with a 256 bit
hash makes no sense.

If there is an attack which such hashing could avoid, that would be a
reason to do it.  Absent any such attack, hashing only adds fragility.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Russ Housley <[email-masked]>
Date: Sun, 9 Jul 2017 06:52:14 -0400

I tend to agree with Jim Fenton on this.

> I'm supporting publishing key fingerprints because I think it's slightly more future-proof, and having been burned by that once already, I don't want to make the same mistake again. But if rough co…

While I recognize that a new RFC will be needed to roll out a different ECC mechanism, using fingerprints in all cases seems like there would be less impact on an implementation to support that new ECC algorithm, especially if the crypto library already includes the curve.  This seems likely if we were to go from ECDSA P256 to ECDSA P384, for example.

> I still haven't heard an answer to the following question I posed about the fingerprints, though: Will the fingerprints always be sha256, or do we need to specify the fingerprint algorithm in the D…

RFC 7093 include the use of SHA-256 for fingerprints, and I am unaware of any reason that it cannot be used for the foreseeable future.

Russ

---

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

>For what it's worth, I agree with Jim and Ekr. Hashing is just fine.

Can't do it.  Unhashed RSA has been in DKIM for a decade and it's not
going away.

R's,
John

---

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

In article <[email-masked]> you write:
>While I recognize that a new RFC will be needed to roll out a different ECC mechanism, using fingerprints in all cases seems like
>there would be less impact on an implementation to support that new ECC algorithm, especially if the crypto library already includes
>the curve.  This seems likely if we were to go from ECDSA P256 to ECDSA P384, for example.

I don't understand what you are proposing here.  All current DKIM
signatures use unhashed RSA keys.  Is the suggestion that we change
the spec so that all signatures must use hashed keys, so existing
unhashed RSA signatures are no longer valid?

Assuming that's not what you mean, we will have unhashed RSA
signatures for a long time, probably forever.  Given that we have both
hashed and unhashed RSA keys, why hash ECC keys?  Why not just hash
when it's useful?  

R's,
John

PS: By the way, the de facto single-string TXT records limit on key
sizes is about 1100 bits.  An unhashed 384 bit key or even an unhashed
1024 bit key would work fine.

---

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

>addition of a PSS-based scheme.

Sorry, I looked at RFC 2313 and have no idea how this would apply to
DKIM other than that there seems to be a redundant message digest code
in the signature.  Starting with the existing message signing defined
in RFC 6376, can you explain what would be different?

R's,
John

---

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

> On Jul 9, 2017, at 4:45 PM, John Levine <[email-masked]> wrote:
> 

No, that is not what I am suggesting.

> hashed and unhashed RSA keys, why hash ECC keys?  Why not just hash

I was just trying to answer Jim's questions, not change the proposal.

Russ

---

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

> I was just trying to answer Jim's questions, not change the proposal.

Oh, OK.  I still don't get the point, though.

Signers and verifiers will all have code to handle both hashed and 
unhashed keys, since unhashed RSA isn't going away.  Since we have the 
code to do both, why hash keys when they are already small enough?

R's,
John

---

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

On Sunday, July 09, 2017 08:45:31 PM John Levine wrote:
> >While I recognize that a new RFC will be needed to roll out a different ECC
> >mechanism, using fingerprints in all cases seems like there would be less
> >impact on an implementation to support that new ECC algorithm, especially
> >if the crypto library already includes the curve.  This seems likely if we
> >were to go from ECDSA P256 to ECDSA P384, for example.

The technical case for hashing RSA key records is very clear: It provides a 
mechanism to continue using RSA with larger keys that exceed the size limits 
many domains are able to publish in DNS.

I still haven't seen any technical argument for hashing ecdsa key records.  
The most I've seen is 'seems nice'.  The technical argument against is, I 
think quite clear:

1.  Solves no actual problem.
2.  Increases protocol complexity.
3.  Increases protocol fragility.
4.  Increases implementation requirements.
5.  Increases the size of every single signed message.

If there's some technical argument for hashing ecdsa key records now beyond it 
may be useful someday for some other signing algorithm, I'd appreciate it if 
someone would make it.  I've entirely missed it.

Scott K

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 14:38:00 -0700

On Sun, Jul 9, 2017 at 2:06 PM, Scott Kitterman <[email-masked]>
wrote:

> The most I've seen is 'seems nice'.

That going forward it would be better to have one way of doing things rather
than two, with the sole exception being the legacy RSA version. And then
at some point when the majority of signatures are hashed, one can simply
delete the old code path.

> The technical argument against is, I
> think quite clear:
>

I don't believe that any of these things are true to any significant
extent.

> 5.  Increases the size of every single signed message.

By a trivial amount, unless your key is very big, in which case hashing
was a good idea.

-Ekr

---

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

On Sunday, July 09, 2017 02:38:00 PM Eric Rescorla wrote:
> > > In article <[email-masked]> you
> > 
> > write:
> > > >While I recognize that a new RFC will be needed to roll out a different
> > 
> > ECC
> > 
> > > >mechanism, using fingerprints in all cases seems like there would be
> > 
> > less
> > 
> > > >impact on an implementation to support that new ECC algorithm,
> > 
> > especially
> > 
> > > >if the crypto library already includes the curve.  This seems likely if
> > 
> > we
> > 
> than two, with the sole exception being the legacy RSA version. And then at
> some point when the majority of signatures are hashed, one can simply

That very much sounds to me like seems nice, maybe someday it would be 
helpful.

I don't see the notional of eventual "all key records are hashed" as having 
any value whatsoever.

If you want implementers to implement new algorithms, I don't think it makes 
it more likely to add pointless additional requirements.

I get my implementation concerns aren't a worry to you, so I don't know how to 
bridge the gap.

Scott K

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 14:56:42 -0700

On Sun, Jul 9, 2017 at 2:49 PM, Scott Kitterman <[email-masked]>
wrote:

> > > The technical case for hashing RSA key records is very clear: It
> provides
> > > a
> at
> > > may be useful someday for some other signing algorithm, I'd appreciate
> it
> > > if

You're certainly entitled to that opinion. Equally, I disagree.

> it more likely to add pointless additional requirements.

What I'm trying to do is reduce the additional complexity of adding new
algorithms
in the future by having a consistent approach going forward.

I get my implementation concerns aren't a worry to you, so I don't know how
> to

Well, it's not like I haven't implemented cryptographic protocols before
(as has
Martin Thomson), so I do think I have a reasonably informed opinion about
how much additional implementation complexity is involved here. As above,
you are free to feel differently.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 10 Jul 2017 00:01:29 -0000

In article <[email-masked]> you write:
>algorithms in the future by having a consistent approach going forward.

Given that we will always have code for both hashed and unhashed keys,
since unhashed RSA isn't going away, my minimal complexity approach is
to add an algorithm with unhashed keys if the keys are small, and with
hashed keys if the keys are large.  

Since DKIM has no opportunity for algorithm negotiation, verifiers
have to implement every algorithm that signers might use, so the
main goal is to minimize the number of algorithms, regardless of
what they are.

At this point I'm inclined to take out hashed RSA, since the problem
it solves only exists due to stupid configuration software, and anyone
who implements hashed RSA would also implent EdDSA which doesn't
have the configuration key size problem.

As I read RFC 8032, the chances are pretty good that ed25519 will last
as long as DKIM does, so we won't have to do this again.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 18:37:54 -0700

> have the configuration key size problem.

Moreover, not having hashed RSA basically commits to EC-only and
I know there are people who would like to keep RSA viable. Moreover,
as I think I've mentioned before, this is a charter item and it was a basic
assumption when the WG was formed.

> as long as DKIM does, so we won't have to do this again.

Again, absent Quantum Computers.

Anyway, I think we're past the point where mailing list discussion is
helpful,
so I suggest we simply pick it up in Prague.

-Ekr

R's,

---

From: denis bider <[email-masked]>
Date: Sun, 9 Jul 2017 20:21:40 -0600

We can break down the following levels of future proofing:

(1) Future event occurs, and no changes are needed by anyone. The event is
already accounted for by configurations, implementations, and
specifications.

(2) Future event occurs, and changes are needed to configurations. The
event is already accounted for by implementations and specifications.

(3) Future event occurs, and changes are needed to implementations, which
must then be deployed. The event is already accounted for by specifications.

(4) Future event occurs, and changes are needed to specifications, which
must then be implemented and deployed. The event is not accounted for.

In this case, when we're talking about "future proofing", we are dealing
with category (4). We cannot do (1), (2), or (3) because although we know
what the future event might be (quantum computing), we do not have a
solution we can specify at this time.

Therefore, we can have no future proofing. All talk of future proofing is
pointless because we cannot future proof for this event until we AT LEAST
can move to category 3 instead of 4. And to move to category 3, we need to
be able to specify something that explicitly addresses the future event.

Requiring fingerprints for ECDSA or EdDSA does nothing for future proofing.
If the future event occurs, we will still be dealing with a category 4
event that requires new specifications, new implementations, and new
deployments. No work will be spared.

On Sat, Jul 8, 2017 at 1:08 AM, Jim Fenton <[email-masked]> wrote:

> saying that, given the limitations of some DNS deployments, it is useful to
> avoid the indirection and just put the key when we can.
>
> "Avoid the indirection" makes it sound like more network round-trips would
> be required if a hash is used. No more network traffic is involved; the
> verifier only needs to compute the hash of the key included in the message
> and compare that with the fingerprint included in the key lookup response
> from DNS. The verifier can even check the signature prior to receiving the
> DNS response, if it wants.
>
> I'm supporting publishing key fingerprints because I think it's slightly
> more future-proof, and having been burned by that once already, I don't
> want to make the same mistake again. But if rough consensus decides
> otherwise, we go with that of course.
>
> I still haven't heard an answer to the following question I posed about
> the fingerprints, though: Will the fingerprints always be sha256, or do we
> need to specify the fingerprint algorithm in the DNS record? In other
> words, will we assume that sha256 will be strong enough for the life of
> this protocol?
>
> -Jim

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 19:26:40 -0700

> solution we can specify at this time.

Actually, this isn't entirely true. We could presumably deploy hash
signatures, they're just not very efficient. In fact, the one thing that we
do know with high probability about any PQ algorithm is that it is likely
to be less efficient than the existing algorithms, and one of the ways in
which it might be less efficient is large public keys, in which case having
hashes will be useful.

Moreover, QC isn't the only possible event that could cause us to wish to
have larger keys. There might be a modest improvement in dlog that would
make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, this
is how we got to the point where we wish to have RSA keys > 1024).

> deployments. No work will be spared.

I don't agree with this for the reasons above.

-Ekr

>> "Avoid the indirection" makes it sound like more network round-trips
>> would be required if a hash is used. No more network traffic is involved;
>> the verifier only needs to compute the hash of the key included in the
>> message and compare that with the fingerprint included in the key lookup
>> response from DNS. The verifier can even check the signature prior to
>> receiving the DNS response, if it wants.
>>

---

From: Peter Goldstein <[email-masked]>
Date: Sun, 9 Jul 2017 20:02:34 -0700

Support for larger keys isn't the issue at hand.  The issue is the 255
character limit imposed by the DNS crudware.  And I think keys for each of
those curves easily fit under the limit.

Based on my math (with 24 additional bytes allocated for version tag/value
and any other key/value pairs), then we've got (assuming my key sizes are
correct):

Curve448 - 114 bytes (key) + 24 bytes = 138 bytes maximum
P-521 - 212 bytes (key) + 24 bytes = 236 bytes maximum

I don't do much low level crypto these days, so if I'm off on my base 64
public key sizes, please let me know.  But in both cases it looks like
there's room to spare.

As for QC, I think John's point earlier in the thread isn't that QC will
require larger keys - but rather than real QC would require fundamental
reconsideration of DKIM as a whole.

Best,

Peter

-- 

Bringing Trust to Email

[email-masked]
+1.415.793.5783

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 20:05:53 -0700

> those curves easily fit under the limit.

I'm referring to the claim that hashing doesn't provide any value. For any
curve > 256 bits, it does.

> reconsideration of DKIM as a whole.

It's not clear to me why that would be true, given that the target for
post-quantum algorithms is to have them be drop-in replacements for the
existing algorithms, albeit with inferior performance.

-Ekr

> +1.415.793.5783 <(415)%20793-5783>
>

---

From: Peter Goldstein <[email-masked]>
Date: Sun, 9 Jul 2017 20:49:16 -0700

> Nope, that's the wrong limit in this case.  By itself we have no interest
in whether the hashed key is smaller than the key itself.  Using a hashed
key is always a loss on space (need to include the full key on each
message), time/CPU (computing the hash) and complexity - even when the
hashed key is smaller than the key itself.  It's always a loss - the
question is whether the loss has any offsetting value.

Hashing only provides value if the base64 encoded public key pushes the
record over the 255 byte limit.  The point of my math was to show that the
larger key size EC algorithms work fine within this limit without hashing.
There is a limit, but it's higher than the key size for all plausible EC
algorithms likely to be introduced in the next decade.

If we didn't have to deal with the 255 limit, we wouldn't be talking about
hashing RSA 2048.  We'd just use a bigger key with the existing format and
algorithm and be done with it.  We wouldn't even need a new RFC (support
for 2048 bit keys is required by RFC 6376
https://tools.ietf.org/html/rfc6376#section-3.3.3).

There was zero interest in adding fingerprinting for RSA 1024 bit keys -
even though the fingerprint would be much smaller than the key.  The
existing format works fine for these keys.  So it's safe to say we could
handle any EC curve <= 1024 bits without fingerprinting.

The value of the hashing is entirely in its ability to help DNS
administrators avoid this 255 byte limit.  And my point is that for the
likely alternatives that would be added in the future, larger key RSA
aside, hashing adds no value.

Best,

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 Jul 2017 20:56:08 -0700

I was going to respond, but I'd just be repeating myself. As I said
earlier, it's probably just easier to discuss this in Prague.

-Ekr

On Sun, Jul 9, 2017 at 8:49 PM, Peter Goldstein <[email-masked]> wrote:

>> I'm referring to the claim that hashing doesn't provide any value. For
>>> any curve > 256 bits, it does.
>>
> for 2048 bit keys is required by RFC 6376 https://tools.ietf.org/html/
> rfc6376#section-3.3.3).
>