Subject: [Dcrup] combo update draft-ietf-dcrup-dkim-crypto-01

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2017 11:07:48 +0100

Per recent discussion I just updated the original dcrup draft.  Changes

* new algorithm is now EdDSA, tags updated appropriately

* sha1 hash is moved to historic

* place marker to splice in deprecation text from Scott's draft if we want 
to.

My draft has always provided updated text for section 3.3 of RFC 6376. 
It says which algorithms signers and verifiers are supposed to use.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jun 2017 13:39:38 +0100

Quick comments:

       sig-a-tag-k = "rsa" / "rsafp" / "eddsa" / "eddsafp" x-sig-a-tag-k

This is missing a '/' for the extension piece.  Also, I would instead do:

       sig-a-tag-k /= "rsafp" / "eddsa" / "eddsafp"

I found the description to be hard to follow and I know how this
works.  You really need more information on how the fingerprint-based
schemes work here.

1. You need to explicitly state that the hash function for the
signature scheme is used to construct the fingerprint.

2. You need to explain how to validate a signature.

This description could be made generic so that (for example) PQ
schemes could use this.

On 12 June 2017 at 11:07, John R Levine <[email-masked]> wrote:
> My draft has always provided updated text for section 3.3 of RFC 6376. It
> says which algorithms signers and verifiers are supposed to use.
>
> Regards,
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup

---

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2017 16:07:05 +0100

> This is missing a '/' for the extension piece.  Also, I would instead do:

It's supposed to replace the existing sig-a-tag-k and key-k-tag-type 
rules, not add new ones.  The explanatory wording could use some work.

> signature scheme is used to construct the fingerprint.

Here's what it says now.  This seems reasonably clear.

 	The DNS record contains a sha-256 hash of the public key, stored
         in base64 in the p= tag.  The key type tag MUST be present and
 	contains k=rsafp or k=ecdhfp.

I suppose I could change that to say use the hash of the signing algorithm 
if people think that's a good idea, but if we add algorithms that use 
hashes other than sha-256, we'll need another update anyway.

> 2. You need to explain how to validate a signature.

OK.

> This description could be made generic so that (for example) PQ

No, my goal is to make the minimum changes needed.  The more options, the 
more chances not to interoperate.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Jun 2017 11:57:10 +0100

> more chances not to interoperate.

That's fine with me.

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2017 20:53:09 -0000

Not to nag or anything, but I think this draft addresses everything in the WG's charter, assuming
the charter is adjusted to deprecate SHA-1.

Could people take a look and see if you agree?  If so we could move it to last call and be within
hailing distance of wrapping things up.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Jun 2017 12:38:45 +0000

> Not to nag or anything, but I think this draft addresses everything in the WG's
> charter, assuming the charter is adjusted to deprecate SHA-1.
> 
> Could people take a look and see if you agree?  If so we could move it to last
> call and be within hailing distance of wrapping things up.

Let me be more "official"

Once the charter change is approved (Murray is working on that with Alexsey), I'd like to put this into WGLC.  Any concerns?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Jun 2017 05:56:20 -0700

Giving this document a quick read I see several things I would change.

1. You say you are using EdDSA with SHA-256? Does this mean you intend to
use
the HashEdDSA variant see (
https://tools.ietf.org/rfcmarkup?doc=8032#section-4)?
If so you should say so.

2. I wouldn't specific generic EdDSA but rather EdDSA with a specific
curve. This
is both for practical reasons (I don't want to have to distinguish keys by
len())
and for algorithmic reasons (you want to use a stronger digest algorithm
than
SHA-256 with X448)

3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp)  These keys
are not
intended for use with key exchange but rather signature. The document
actually
seems kinda confused on this point with the text saying one thing and the
table saying another.

-Ekr

On Tue, Jun 20, 2017 at 5:38 AM, Salz, Rich <[email-masked]> wrote:

> Once the charter change is approved (Murray is working on that with
> Alexsey), I'd like to put this into WGLC.  Any concerns?
>

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2017 12:50:07 -0400

> Giving this document a quick read I see several things I would change.

In case it's not clear, I do not purport to be any sort of crypto expert, 
so I'm hoping that you, r$, et al. help us to be sure that what I say 
makes sense.

> 1. You say you are using EdDSA with SHA-256? Does this mean you intend
>    to use the HashEdDSA variant see (
>    https://tools.ietf.org/rfcmarkup?doc=8032#section-4)?  If so you
>    should say so.

I think the answer is no.  DKIM signatures use two chained hashes.  First 
it hashes a canonicalized version of the message body, and inserts the 
base64 hash into the DKIM-Signature header.  Then it hashes a 
canonicalized version of the headers, signs that hash, and inserts the 
base64 signature of the second hash into the DKIM-Signatuer header.  To 
avoid infinite regress, the verification step pretends the signature 
wasn't in the header when verifying.

As far as I can tell, feeding the canonicalized header text into HashEdDSA 
gives the same result as feeding the hash into PureEdDSA.  Since the 
hashing in DKIM has been defined for a decade and we're not planning to 
change it (other than to deprecate SHA-1) I'd rather say this is a 
PureEdDSA signature of the existing hash.

>    curve. This is both for practical reasons (I don't want to have to
>    distinguish keys by len())  and for algorithmic reasons (you want to
>    use a stronger digest algorithm than SHA-256 with X448)

OK.  Looking at 8032, it appears I want to use Ed25519, right?

>    are not intended for use with key exchange but rather signature. The
>    document actually seems kinda confused on this point with the text
>    saying one thing and the table saying another.

OK.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Jun 2017 10:37:27 -0700

On Tue, Jun 20, 2017 at 9:50 AM, John R Levine <[email-masked]> wrote:

> so I'm hoping that you, r$, et al. help us to be sure that what I say makes
> sense.
>
> base64 hash into the DKIM-Signature header.  Then it hashes a canonicalized
> version of the headers, signs that hash, and inserts the base64 signature
> of the second hash into the DKIM-Signatuer header.  To avoid infinite
> regress, the verification step pretends the signature wasn't in the header
> when verifying.
>

OK, I think this probably needs to be clearer in the document.

> OK.  Looking at 8032, it appears I want to use Ed25519, right?

Yes, I think so.

-Ekr

---

From: Jon Callas <[email-masked]>
Date: Tue, 20 Jun 2017 11:56:04 -0700

> On Jun 20, 2017, at 5:38 AM, Salz, Rich <[email-masked]> wrote:
> 

My biggest concern is about key rollover. I could, should, say more, but every time I write a page I get rantier than I wanted to be.

Suffice it to say that removing and retiring keys (which is easy because they're just in DNS, and there's no revocation etc.) is really important for privacy and downstream issues.

	Jon

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2017 15:15:16 -0400

On Tue, 20 Jun 2017, Jon Callas wrote:
> Suffice it to say that removing and retiring keys (which is easy because 
> they're just in DNS, ...

We talked about this at the M3AAWG meeting.  The main reason that mail 
systems don't rotate keys is that rotating is hard because they're in the 
DNS.  In many organizations, the people who run the DNS are far awy from 
the people who run the mail, and the two groups are not friends.

A proposed hack is to publish two or three key records as CNAMEs that 
point at a DNS server the mail people control, and rotate the target 
records a few times a year.

In large organizations there's also the issue of updating all of the mail 
servers at roughly the same time, but the DNS management is apparently the 
hard part.

In any event, key rotation is a security issue rather than an 
interopration issue.  If you want I can ask the guy who proposed the 
CNAMEs if he'd like to write it up as an information draft.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 15:24:11 -0400

On Tuesday, June 20, 2017 12:38:45 PM Salz, Rich wrote:
> > Not to nag or anything, but I think this draft addresses everything in the
> > WG's charter, assuming the charter is adjusted to deprecate SHA-1.
> > 
> > Could people take a look and see if you agree?  If so we could move it to
> > last call and be within hailing distance of wrapping things up.
> 

This is no doubt reasonably obvious, but for clarity:

I think it's still not clear where the group lies on how dead we should kill 
rsa-sha1.  I think the WG chairs are going to have to evaluate the consensus 
and let us know.  Once that's done, converging on the correct wording should 
be ~easy (whether it ends up in my draft or John's).

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 15:28:19 -0400

> >It says which algorithms signers and verifiers are supposed to use.

As another non-crypto expert, it's not clear to me what the DNS record for the 
new algorithm are supposed to look like?  If it's reasonably clear from what's 
in the exisitng RFCs, perhaps an example?

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 20 Jun 2017 15:44:24 -0400

> in the exisitng RFCs, perhaps an example?

I think the new -02 is clearer.  The format of the key records hasn't 
changed at all other than to add the new algorithms as key tags.

For EdDSA, the p= is the base64 version of the key, just like RSA.

For the fingerprint versions, the p= is the base64 version of the sha-256 
hash of the key.  New text says that you get the key out of the signature 
header, hash it, check that the hash matches the one in the DNS, and then 
use the key as usual.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R. Levine" <[email-masked]>
Date: 20 Jun 2017 16:01:18 -0400

> be ~easy (whether it ends up in my draft or John's).

Given that we are not the Network Police, I don't see this as a very 
meaningful questions We can tell people not to sign with sha-1 or to 
verify sha-1 signatures, but we can't threaten them with penalties if they 
ignore us.

In practice, the known problems with sha-1 aren't yet very relevant to 
short lived signatures like DKIM's since the cost of finding a collision 
remains high, so signers can't be bothered to upgrade their signers.  I 
looked at the last 1000 signed messages I got from non-spam bulkish 
mailers, and 354 of them still had sha1 signatures.  They can't be 
bothered to upgrade, and the IETF has no leverage.

At some point I expect one of the big gorillas will decide to stop 
accepting sha-1 and after a week of panic in the bulk mail community, 
they'll all patch their signers and we'll never see another sha-1 
signature again.

Regards,

PS: Hall of shame:

   67 d=patreon.com;
   37 d=bookbub.com;
   32 d=gbp.co.uk;
   20 d=email.powells.com;
   18 d=audiencerewards.com;
   17 d=astorwines.com;
   16 d=aaas.sciencepubs.org;
   12 d=e.avis.com;
   10 d=email.airbnb.com;
    7 d=mail125.wdc01.mcdlv.net;
    6 d=ebay.com;
    5 d=rocketmiles.com;
    4 d=sendgrid.me;
    4 d=rel1.aeroplan.com;
    4 d=mail63.us4.mcsv.net;
    4 d=e-vanguard.com;
    3 d=subscription.theatlantic.com;
    3 d=emessaging.us.hsbc.com;
    3 d=emails.hertz.com;
    3 d=cmail19.com;
    2 d=your.lufthansa-group.com;
    2 d=ted.com;
    2 d=notify.transunion.com;
    2 d=newsletter.milesandmore.com;
    2 d=mg.expediamail.com;
    2 d=mail70.atl11.rsgsv.net;
    2 d=mail215.atl171.mcdlv.net;
    2 d=mail103.atl161.mcsv.net;
    2 d=kickstarter.com;

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Jun 2017 16:13:37 -0400

On Tuesday, June 20, 2017 04:01:18 PM John R. Levine wrote:
> > I think it's still not clear where the group lies on how dead we should
> > kill rsa-sha1.  I think the WG chairs are going to have to evaluate the
> > consensus and let us know.  Once that's done, converging on the correct
> > wording should be ~easy (whether it ends up in my draft or John's).
> 

Right, and when the panic happens (which is, I agree, when this will change 
for real) I'd like for the engineer getting beat up by his boss to be able to 
say in response to the "Argh! What should be do" question from the PHB [1] "We 
need to upgrade our DKIM like it says in RFC XXXX" [2].  I think what you've 
proposed covers that.

Scott K

[1] The pointy haired boss (see Dilbert), not the other one.
[2] Followed by a mostly silent "Like I've been telling you for a year."

---

From: Peter Goldstein <[email-masked]>
Date: Tue, 20 Jun 2017 14:01:36 -0700

The -02 document looks basically good to me.

The new EdDSA and fingerprinting behavior seems well-defined and
unambiguous.  And the guidance on minimum key length seems fine.  And the
SHA-1 language is clear and unambiguous.

My only question is whether there's any need or desire to support larger
RSA key sizes (e.g. 4096)?  I don't know of a use case that requires such
support that couldn't be met by the use of EdDSA, but I wanted to make sure
the question was considered by the WG.

Best,

Peter

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783