Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt

From: [email-masked]
Date: Sat, 01 Jul 2017 18:17:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DKIM Crypto Update of the IETF.

        Title           : Cryptographic Update to DKIM
        Author          : John Levine
	Filename        : draft-ietf-dcrup-dkim-crypto-03.txt
	Pages           : 7
	Date            : 2017-07-01

Abstract:
   DKIM was designed to allow new cryptographic algorithms to be added.
   This document adds a new signing algorithm and a new way to represent
   signature validation keys, and deprecates an obsolete signing
   algorithm.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-03
https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

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

This version addresses Jim's comments, reorganizes the draft somewhat to 
put all the syntax changes in one place, and makes one significant change.

SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints.  Since 
an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, 
there's no point to eddsa fingerprints, so I took them out.

If there is an actual problem that eddsa fingerprints would solve 
("symmetry" isn't a problem), let me know.  Otherwise I'll leave them out 
since we now have less code to write and verify.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Jul 2017 19:41:10 -0700

On Sat, Jul 1, 2017 at 7:17 PM, John R Levine <[email-masked]> wrote:

> ("symmetry" isn't a problem), let me know.

Well, actually the value at hand here is consistency, not "symmetry".

In any case,  it's not true that eddsa keys are 256 bits. Eddsa keys are
256 bits when you are using X25519 but not when you are using X448. To the
extent to which you believe that it's redundant to have both non-FP and FP
variants, the answer is to *always* use a fingerprint.

-Ekr

Otherwise I'll leave them out since we now have less code to write and
> verify.
>
> R's,
> John
>
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: "John Levine" <[email-masked]>
Date: 2 Jul 2017 02:56:50 -0000

>variants, the answer is to *always* use a fingerprint.

The only eddsa algorithm we're adding is ed25519.

The point of the fingerprints was to make it easier to use long RSA keys.  We're
stuck with unfingerprinted RSA keys because they're what we have now.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Jul 2017 20:35:00 -0700

> The only eddsa algorithm we're adding is ed25519.

Right now yes, but I'm interested in thinking past this document.

The point of the fingerprints was to make it easier to use long RSA keys.

That may have been your point, but when I suggested it, my objective was to
future proof the protocol against other algorithms with larger keys as well.

>   We're

Yes, but that doesn't mean we need to continue that trend for future
algorithms.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 1 Jul 2017 23:41:45 -0400

> future proof the protocol against other algorithms with larger keys as well.

I'm wondering how likely that is.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 2 Jul 2017 15:15:23 +0000

From the key type, can’t one infer if it’s a hash or the actual key?  I think avoiding the indirection can be useful.

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2017 11:33:19 -0400

> From the key type, can’t one infer if it’s a hash or the actual key?  I think avoiding the indirection can be useful.

It's in the algorithm type -- an RSA key is rsa, RSA key fingerprint is 
rsafp.

In the signature, the a= algorithm tag also includes the message hash 
algorithm so it's a=rsa-sha256 or a=rsafp-sha256 or a=eddsa-sha256, with 
no default.  In the key record, the k= key tag is k=rsa or k=rsafp or 
k=eddsa, with the default being rsa for backward compatibility.

The previous draft also had eddsafp.  I took it out since the point of the 
hash is to make the key records smaller, but for eddsa the hash is the 
same size as the key.

I suppose it's possible that in the distant future we'll find some problem 
with both rsa and ed25519 so that we'll need to add yet another signature 
algorithm and that algorithm will have keys big enough (more than 1100 
bits) to make hashes attractive, but that seems speculative in the extreme 
and we'd need to do another revision of the DKIM spec and code anyway.

To me it seems more likely that ed25519 is good enough that it'll last 
until we deprecate all of DKIM in favor of something different.

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 2 Jul 2017 15:44:02 +0000

> To me it seems more likely that ed25519 is good enough that it'll last until we
> deprecate all of DKIM in favor of something different.

As an individual, I think this is reasonable.

As co-chair, does anyone in the WG disagree?

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 12:16:55 -0700

On Sun, Jul 2, 2017 at 8:44 AM, Salz, Rich <[email-masked]> wrote:

> until we

I don't agree that we should design to this assumption.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 12:18:09 -0700

> I'm wondering how likely that is.

Given that (a) we already have algorithms that are bigger and (b)
post-quantum keys
might be quite a bit bigger, it seems unwise to design under the assumption
that it will
not happen.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2017 15:53:18 -0400

> post-quantum keys might be quite a bit bigger, it seems unwise to design 
> under the assumption that it will not happen.

Well, OK, but concretely, what do you want us to do now?

DKIM has had algorithm tags since it was defined a decade ago.  This draft 
adds two new algorithm tags (rsafp-sha256 and eddsa-sha256) and deprecates 
one old one (rsa-sha1) and as part of that adds RSA key hashes as a key 
verification method.  If it turns out that we need to switch signature 
algorithms, we'll revise DKIM again, and add and deprecate tags and 
algorithms as needed.  Maybe new algorithms will use key hashes, maybe 
they won't, but at that point we can define whatever we need.

Right now, today, I don't see that hasned ed25519 keys solve any problem, 
so I'm not going to include them unless there is something I don't 
understand that they can do that plain ed25519 keys in the key records 
don't.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 02 Jul 2017 20:00:44 +0000

>understand that they can do that plain ed25519 keys in the key records 

+1

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 2 Jul 2017 20:21:04 +0000

I think post-quantum crypto is out of scope, but maybe I’m in the rough.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 2 Jul 2017 20:23:25 +0000

>As co-chair, does anyone in the WG disagree?

Ekr

> I don't agree that we should design to this assumption.

I'd like to know what other members of the WG think.  As it's a major holiday in the US and a short week, I expect we should plan on discussing this in Prague.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 13:58:01 -0700

> Well, OK, but concretely, what do you want us to do now?

I thought I made that clear: I think the default representation should be
hashed, not unhashed.

> understand that they can do that plain ed25519 keys in the key records

Uh, the way this works isn't that the editor decides what happens and
everyone needs to persuade him. Rather, the draft needs to represent
consensus of the WG. Happy to talk about this in Prague, of course.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 13:58:43 -0700

> I think post-quantum crypto is out of scope, but maybe I’m in the rough.
I agree it's out of scope. I'm talking about having a design which cleanly
scales from what we have now to new algorithms, and I don't think that
that's out of scope.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 14:02:53 -0700

> I thought I made that clear: I think the default representation should be

I'd also be fine with having both representations, though I think it's
confusing. However, I don't think it's great to have just unhashed in the
future.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2017 17:16:47 -0400

> confusing. However, I don't think it's great to have just unhashed in the

Since nobody is currently proposing that, and as far as I can tell nobody 
in this thread has ever proposed that, I really don't understand what 
we're arguing about.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 2 Jul 2017 17:34:52 -0400

> As co-chair, does anyone in the WG disagree?
​I would phrase it differently. We will use DKIM until we start using
something different to SMTP.​ I can't see a viable transition path out of
DKIM without re-designing SMTP.

The only thing I see on the horizon that might force us away from ed25529
is quantum and that is going to be so different that backwards
compatibility just isn't going to be a concern.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 15:02:55 -0700

On Sun, Jul 2, 2017 at 2:16 PM, John R Levine <[email-masked]> wrote:

> in this thread has ever proposed that, I really don't understand what we're
> arguing about.

I'm responding to this change:
"SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints.  Since
an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits,
there's no point to eddsa fingerprints, so I took them out."

My point is that you should revert it.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2017 18:28:51 -0400

> My point is that you should revert it.

The current draft is substantially rewritten so it's not that simple. 
Please identify the sections and lines of the -03 draft to which you 
object.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 15:36:25 -0700

On Sun, Jul 2, 2017 at 3:28 PM, John R Levine <[email-masked]> wrote:

>>> we're
> Please identify the sections and lines of the -03 draft to which you object.
>

Is the document on Github? I'll send you a PR.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 2 Jul 2017 19:16:32 -0400

> Is the document on Github? I'll send you a PR.

No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place.  Just tell us 
which sections should change, or if you want you can send a diff to the 
XML but that's probably overkill.

Perhaps this will help:

SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than 
three, rsafp for RSA with key fingerprints in the DNS, and eddsa for 
ed25519 with keys in the DNS.

NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what 
signature schemes, key representations, and/or message hashes might be 
added or changed in future versions of DKIM.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jul 2017 17:00:51 -0700

On Sun, Jul 2, 2017 at 4:16 PM, John R Levine <[email-masked]> wrote:

> No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place.  Just tell
> us which sections should change, or if you want you can send a diff to the

I'll send you comments, but it won't be before Prague.

-Ekr

---

From: denis bider <[email-masked]>
Date: Mon, 3 Jul 2017 18:49:48 -0600

I agree with John's reasoning, and the +1 from Scott K, and think this
request is unwarranted. I see no gain from reverting this removal.

The current design defines algorithms on a case-by-case basis. Both X25519
and X448 have keys small enough to be represented without hashing. Hashed
keys cannot be made default at this point. That ship sailed 10 years ago.
SMTP is a 40 year old protocol. At this point we should all understand that
things are basically forever once they become widely accepted.

2048-bit RSA can be represented as-is unhashed. The only reason unhashed
RSA would therefore go away is if 2048-bit RSA is broken and becomes
deprecated. If that happens, chances are we'll need post-quantum crypto,
and EDDSA will be deprecated as well.

Hashed keys will not be default until post-quantum is a strict requirement,
and we're not in a position to specify that right now. There is no purpose
served by adding "eddsafp".

---

From: Jim Fenton <[email-masked]>
Date: Mon, 3 Jul 2017 21:26:26 -1000

I agree with ekr on this one: publishing a key fingerprint is the more general solution, even if right now we can't think of keys that require it other than RSA. So why not, in the future, always publish key fingerprints?

Related side question: in my last review I asked whether we should make provision in the protocol for different hash algorithms to be used for key fingerprints. The answer was "no" because we would not be able to use them without doing another dcrup-ish effort. I suppose that is reasonable, except that we had included the h= tag in DKIM selector records; it seems inconsistent to not be able to specify the algorithm here too.

-Jim

> On Jul 2, 2017, at 2:00 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place.  Just tell us which sections should change, or if you want you can send a diff to the XML but that's probably overkill.
>> 
>> Perhaps this will help:
>> 
>> SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than three, rsafp for RSA with key fingerprints in the DNS, and eddsa for ed25519 with keys in the DNS.
>> 
>> NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what signature schemes, key representations, and/or message hashes might be added or changed in future versions of DKIM.
>

---

From: "John R Levine" <[email-masked]>
Date: 4 Jul 2017 11:09:33 -0400

> I agree with ekr on this one: publishing a key fingerprint is the more general solution, even if right now we can't think of keys that require it other than RSA. So why not, in the future, always p…

1)  For the next decade or so, to the extent anyone uses a signature other
    than plain rsa, I expect they'll use eddsa since it's faster than rsa
    and the keys are smaller.  (Librariess will have the code since they
    need it to verify other people's signatures, the only question is
    whether they use it, just like sha-1 and sha-256 body hashes now.)
    Key hashes use more time and space while providing no benefit to eddsa
    signatures.  It doesn't seem like great design to pessimize the common
    case.

B)  Barring surprises, eddsa should be good enough to last as long as DKIM
    does.  But if we have surprises, they tend to be, you know, surprising.
    Maybe we'll switch to some other elliptic curve which has keys smaller
    than 1100 bits, in which case key hashes still have no benefit.  Or
    maybe some mega-parellel rainbow table scheme will come out of left
    field and we'll deprecate all of the sha-N hashes.  It doesn't seem
    like great design to plan for stuff that we can't predict and that will
    probably never happen.  Our crystal ball has never been great: back in
    2006 would anyone have suggested that crudware that can't handle
    multi-string TXT records would be a design issue a decade later?

iii)  It seems unliely that Cisco will assert your patent, but until they
    say something one way or the other, who knows.  It'd be prudent to be
    prepared for the eventuality, particularly since it costs us nothing to
    do so.

Regards,

---

From: Peter Goldstein <[email-masked]>
Date: Tue, 4 Jul 2017 09:06:11 -0700

I agree with John here.  If we don't have even a single concrete notion of
a future key type that would need fingerprinting, why should we try to bias
the implementation in that direction?

It's also not clear to me why fingerprints are the more 'general'
solution.  As John notes, fingerprints wind up using more time and space -
an additional hash computation, and the addition of the base64 key to all
signed messages.  Fingerprints provide no benefit, other than a workaround
for DNS crudware that can't handle multi-string TXT records.  And in the
EdDSA case it doesn't even provide that benefit.  There's no compelling
reason to make fingerprints the default.

+1 to moving forward with the -03 draft.

Best,

Peter

On Tue, Jul 4, 2017 at 8:09 AM, John R Levine <[email-masked]> wrote:

> I agree with ekr on this one: publishing a key fingerprint is the more
>> general solution, even if right now we can't think of keys that require it
>> other than RSA. So why not, in the future, always publish key fingerprints?
>>
>

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783