Subject: [Dcrup] rsa-sha1 usage

From: James Cloos <[email-masked]>
Date: Mon, 12 Jun 2017 17:00:38 -0400

I looked at a corpus of email from this year.  3265010 emails,
including all of spam, good automated and good from humans.

The vast majority of the latter were deliverred via mailing lists.

Just under half (1443757) had a dkim sig.

The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces
to about 6.270:1.

So there is a ways to do before sha1 signers disappear.

Nonetheless, I still agree that the update should deprecate sha1.

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

---

From: Brandon Long <[email-masked]>
Date: Mon, 12 Jun 2017 16:25:28 -0700

It would be good to know where the source is, ie if its say the default in
opendkim or something, then hopefully a change to that would eventually hit
these.

We don't currently log the algorithm, guess we can change that to take a
look.

Brandon

On Mon, Jun 12, 2017 at 2:00 PM, James Cloos <[email-masked]> wrote:

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

---

From: Brandon Long <[email-masked]>
Date: Mon, 12 Jun 2017 16:30:56 -0700

hm, dmarc reports don't report the algorithm either, though I'm not sure if
that's generally useful enough to add that.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jun 2017 16:32:32 -0700

> We don't currently log the algorithm, guess we can change that to take a

If OpenDKIM was compiled against OpenSSL 0.9.8e or later, it supports both
rsa-sha1 and rsa-sha256 and defaults to the latter.  Otherwise, it only
supports rsa-sha1, because that's the only thing it can support with an
older OpenSSL.

-MSK

---

From: Brandon Long <[email-masked]>
Date: Mon, 12 Jun 2017 16:35:45 -0700

On Mon, Jun 12, 2017 at 4:32 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> It would be good to know where the source is, ie if its say the default
>> in opendkim or something, then hopefully a change to that would eventually
>> hit these.
>>

and if people are still using openssl 0.9.8d or earlier... expectations of
updates will be low/slow

Brandon

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Jun 2017 23:51:24 +0000

How are messages that are signed with both rsa-sha1 and rsa-sha256 counted?  For this purpose they should be in the rsa-sha256 pile.

Scott K

On June 12, 2017 7:25:28 PM EDT, Brandon Long <[email-masked]> wrote:
>in

---

From: James Cloos <[email-masked]>
Date: Mon, 12 Jun 2017 20:10:15 -0400

>>>>> "BL" == Brandon Long <[email-masked]> writes:

BL> It would be good to know where the source is

When calculating those, I grep(1)ed for /^DKIM-Signature:/.

195704 sha1 dkims which had their d= on that line.  The result of:

:; grep sha1 dkim-lines|tr \  \\n|grep ^d=|sort|uniq -c|sort -nr|head 

is:

  55567 d=gcc.gnu.org;
  46147 d=github.com;
  32100 d=sendgrid.me;
  28126 d=sourceware.org;
   6865 d=
   4560 d=listbox.com;
   1980 d=pobox.com;
    922 d=zx2c4.com;
    891 d=itsqueeze.com;
    661 d=travis-ci.org;

The gcc.gnu.org ones are from the mailing lists @gcc.gnu.org, including
the automated ones like gcc-testresults and gcc-bugs.

For github, roughly half were a=rsa-sha1 and half a=rsa-sha256.
I found a sha2 example from 2017/02/14 and a sha1 from 2017/02/15.
The sha1 included a Received line referencing sendgrid between the
ones referencing github itself.

Getting those top four fixed would reduce significantly the sha1 cases.

In all, there were 4217 distinct d= lines in the a=rsa-sha1 subset.

But, again, the counts ignored cases where the a= and/or d= were not on
the first line of the DKIM-Signature: header.

-JimC

---

From: Peter Goldstein <[email-masked]>
Date: Mon, 12 Jun 2017 23:41:21 -0700

When looking at the global usage of SHA-1, it's important to note that
several of the largest email service providers still use rsa-sha1
signatures.  I don't necessarily want to call out any companies on this
list, but there are at least 3 large ESPs that in aggregate send billions
of messages per day that are DKIM signed with rsa-sha1 (and only rsa-sha1).

Getting this small number of ESPs to change to rsa-sha256 will fix this
problem for email sent from a very large number of domains.  On the
referenced corpus I'm pretty sure it would address both the d=github.com
and d=travis-ci.org signed messages.  And I suspect it would represent a
much larger fraction of rsa-sha1 signed email in the average email user's
inbox.

One of the valuable services that DCRUP can provide is demonstrating to
these ESPs that SHA-1 support is actively being deprecated, and that they
will need to make the shift to rsa-sha256 to ensure future deliverability.
It's M3AAWG this week, and I'm planning on having that conversation with
several folks from companies that are using rsa-sha1, to encourage them to
make the change sooner rather than later.

Similarly, I'd suggest that participants in mailing lists that are signing
with rsa-sha1 reach out to the mailing list administrators and encourage
them to make this change.

Best,

Peter

-- 

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[email-masked]
+1.415.793.5783 <(415)%20793-5783>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Jun 2017 12:05:25 +0000

As a newcomer to DKIM (I come from the crypto side of things) I am a bit confused.

Certificates last for a couple of years, and so there was a strong motivation to move off MD5 and then SHA1, because of the concern that someone would find a collision and create a bogus certificate during the original cert’s lifetime.

But I’ve heard that DKIM “trust lifetime” is much shorter.  Is it?  What is the expected lifetime for relying on a DKIM signature?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jun 2017 06:21:08 -0700

Hi Peter,

> make the change sooner rather than later.

I think we should be careful not to assume that us issuing RFCs or updating
IANA registries will compel the long tail to do anything.  What will get
them to change is receivers no longer accepting their signatures and
affecting their mail's delivery, but our work here won't necessarily compel
that either.

We should say the right things in the right ways, and stop.

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Tue, 13 Jun 2017 07:41:42 -0700

On 6/13/17 5:05 AM, Salz, Rich wrote:
> Certificates last for a couple of years, and so there was a strong
> motivation to move off MD5 and then SHA1, because of the concern that
> someone would find a collision and create a bogus certificate during
> the original cert’s lifetime.
>
>  
>
> But I’ve heard that DKIM “trust lifetime” is much shorter.  Is it? 
> What is the expected lifetime for relying on a DKIM signature?
>

The expected lifetime is on the order of a week (message delivery
timeout). But the signature doesn't have an expiration time, so if
someone can construct a second message with the same hash, they could
replay the signature, potentially much later if the public key is still
in DNS.

IMO it seems very unlikely, even with the known weaknesses in SHA-1,
that in the near future someone would be able to construct such a
message that would be exploitable by an attacker (e.g., spam or a
phishing attack). That will likely change in the future, so we should
tell signers to stop using SHA-1 ASAP and tell verifiers to stop
accepting those signatures sometime later.

If anyone knows something yet more serious about exploitability of
rsa-sha1, please set me straight.

-Jim

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Jun 2017 15:53:42 +0100

Well, this would require a second preimage. My sense is that nobody is
close to that at all with SHA-1....

-Ekr

On Tue, Jun 13, 2017 at 3:41 PM, Jim Fenton <[email-masked]> wrote:

> someone would find a collision and create a bogus certificate during the
> original cert’s lifetime.
>
>
>
> But I’ve heard that DKIM “trust lifetime” is much shorter.  Is it?  What
> is the expected lifetime for relying on a DKIM signature?
>
>
> timeout). But the signature doesn't have an expiration time, so if someone
> can construct a second message with the same hash, they could replay the
> signature, potentially much later if the public key is still in DNS.
>
> IMO it seems very unlikely, even with the known weaknesses in SHA-1, that
> in the near future someone would be able to construct such a message that
> would be exploitable by an attacker (e.g., spam or a phishing attack). That
> will likely change in the future, so we should tell signers to stop using
> SHA-1 ASAP and tell verifiers to stop accepting those signatures sometime
> later.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 11:14:19 -0400

The issue of trust lifetime is now very problematic due to the use
DKIM signatures are being put to. In particular the verification of
purported leaks from the DNC and other places.

The DNC material was verified by means of the DKIM signatures. Other
material has been exposed as fake by the lack of signatures. And
please, let us not get into idiot discussions of whether people who
hack into politicians email might redact, suppress or forge material,
of course they would. People who use dishonest tactics are going to do
anything they can get away with and no, nobody is going to be able to
guarantee the material is genuine without a mechanism such as DKIM.

As it stands, the break in SHA-1 is not sufficient to introduce a
forgery but could certainly be used for mischief (if you can't see
how, you lack imagination). Remember that in this campaign, the
opponent is hacking into infrastructure because simply planting a seed
of doubt serves their malignant ends.

So the SHA-1 issue is very clearly a security issue. It is in fact a
critical national security issue. The question is what to do about it.

I suggest the following:

Signers MUST NOT use SHA-1 or RSA 1024.
Verifiers MAY accept SHA-1 or RSA 1024.

The rationale here is that you do not get better security from
introducing a new algorithm. You only improve security by withdrawing
an insecure algorithm.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 13 Jun 2017 15:43:25 +0000

>rsa-sha1, please set me straight.

I'm not an expert at all, but at least to the degree I understand it, I think your understanding of the rsa-sha1 situation is correct.

I think your proposed remedy is too mild though.  Given the degree to which the SHOULD NOT sign rsa-sha1 has been ignored for the last decade, I don't believe anything other than MUST NOT sign/MUST NOT verify rsa-sha1 is very useful.

The thing about weaknesses​ in cryptographic algorithms is that the timeline for their discovery isn't predictable.  I believe that most cryptographic experts anticipate that such weaknesses exist and will be found, we just don't know when.

Given that we have rsa-sha256 available, I think it would be irresponsible not to remove rsa-sha1 from the DKIM protocol.  Operational practice​ isn't closely coupled with standards changes.  Killing off rsa-sha1 now is the best thing we can do to minimize​the panic when a problem does become known.

To the extent standards changes matter, engineering resources don't get assigned beyond the minimum needed.  I imagine a manager dropping our RFC on the (metaphorical) desk of one​ of their engineers and asking what's the minimum change required by the RFC.  If the answer leaves rsa-sha1 in use, I think it's a mistake.

Scott K

---

From: James Cloos <[email-masked]>
Date: Tue, 13 Jun 2017 16:35:26 -0400

>>>>> "SK" == Scott Kitterman <[email-masked]> writes:

SK> How are messages that are signed with both rsa-sha1 and rsa-sha256
SK> counted?  For this purpose they should be in the rsa-sha256 pile.

Indeed they should.  But my earlier report counted ^DKIM lines separately.

Rechecking on them, I found that one spam had 500 DKIM-Signature: blocks.
(All from the same sha256 signer. :)

I just checked by splitting them into sha1 files and sha256 files,
running:

;: diff -U999 .sha*|egrep '^ '

reported 5821 lines.

Many are from mailing lists, where the list signed with 256 and the
sender with 1.  Or similar, but via something like mandrill.

-JimC

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jun 2017 18:40:05 -0700

On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman <[email-masked]>
wrote:

> I think your proposed remedy is too mild though.  Given the degree to
> which the SHOULD NOT sign rsa-sha1 has been ignored for the last decade, I
> don't believe anything other than MUST NOT sign/MUST NOT verify rsa-sha1 is
> very useful.
>

That being the case, why do we think people will pay attention to a MUST
NOT today?

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Tue, 13 Jun 2017 18:55:47 -0700

On 6/13/17 6:40 PM, Murray S. Kucherawy wrote:
> On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I think your proposed remedy is too mild though.  Given the degree
>     to which the SHOULD NOT sign rsa-sha1 has been ignored for the
>     last decade, I don't believe anything other than MUST NOT
>     sign/MUST NOT verify rsa-sha1 is very useful.
>
But it isn't a simple SHOULD NOT, because it's followed by:

INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
      senders might prefer to use rsa-sha1 when balancing security
      strength against performance, complexity, or other needs.  In
      general, however, rsa-sha256 should always be used whenever
      possible.

Basically this seems to be giving signers an out to use rsa-sha1 because
performance of rsa-sha256 is worse (although I doubt that it is
significantly so). Granted, I'm probably reading a lot more nuance into
the specification than many readers are.
>
> That being the case, why do we think people will pay attention to a
> MUST NOT today?

Because implementations will stop supporting rsa-sha1, forcing the issue
for any who upgrade. I'm all for having them stop supporting signing
with rsa-sha1, but they should continue to support verification for a while.

-Jim

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Jun 2017 22:11:34 -0400

On Tue, Jun 13, 2017 at 9:40 PM, Murray S. Kucherawy
<[email-masked]> wrote:
> That being the case, why do we think people will pay attention to a MUST NOT
> today?

MUST NOT sign is perfectly viable and proper and will be followed by
anything that has the right to call itself compliant with the new
spec.

MUST NOT verify is not supported by the state of the crypto and is
guaranteed to be ignored. It is an utterly illogical criteria since
there is no requirement to sign at all.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jun 2017 20:16:11 -0700

On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton <[email-masked]> wrote:

> for any who upgrade. I'm all for having them stop supporting signing with
> rsa-sha1, but they should continue to support verification for a while.
>

We can't have this logic both ways.  Scott claimed nobody pays attention to
the advice in RFCs ("Operational practice​ isn't closely coupled with
standards changes").  If that's true, then there's no meat to a MUST NOT
anyway, and it really only matters what people will implement.  And if
that's true, then saying current implementations neither sign with nor
verify "rsa-sha1" because it's deprecated suffices, and we're done.

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Tue, 13 Jun 2017 20:20:42 -0700

On 6/13/17 8:16 PM, Murray S. Kucherawy wrote:
> On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>     That being the case, why do we think people will pay attention to
>>     a MUST NOT today?
>
>     Because implementations will stop supporting rsa-sha1, forcing the
>     issue for any who upgrade. I'm all for having them stop supporting
>     signing with rsa-sha1, but they should continue to support
>     verification for a while.
>
>
> We can't have this logic both ways.  Scott claimed nobody pays
> attention to the advice in RFCs ("Operational practice​ isn't closely
> coupled with standards changes").  If that's true, then there's no
> meat to a MUST NOT anyway, and it really only matters what people will
> implement.  And if that's true, then saying current implementations
> neither sign with nor verify "rsa-sha1" because it's deprecated
> suffices, and we're done.

Based on no supporting data whatsoever, my conjecture is that
implementers pay a lot more attention to what RFCs say than people who
are deploying others' implementations. Which basically boils down to
MUSTs having a significant effect and SHOULDs having little. Which is
why I favor making signing with rsa-sha1 a MUST NOT prior to making
verification of rsa-sha1 signatures a MUST NOT.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Jun 2017 03:28:29 +0000

>verification of rsa-sha1 signatures a MUST NOT.

I agree on the importance of MUST versus SHOULD to implementors.  In general terms, MUST tells me what I have to implement and SHOULD tells me the defaults.

I still think we should MUST NOT both signing and verification for rsa-sha1 if for no other reason than to not require implementations to support three algorithms, but I am starting to get the sense I'm in the rough on that.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jun 2017 20:29:00 -0700

On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> We can't have this logic both ways.  Scott claimed nobody pays attention
> to the advice in RFCs ("Operational practice​ isn't closely coupled with

As Pete Resnick loves to point out, RFC prose can be normative without
using RFC2119 words.

The text of RFC2119 counsels against unnecessary use of the words it
defines.  It also contains this language: "...actually required for
interoperation" (which use of rsa-sha1 clearly does not impede) "or to
limit behavior which has potential for causing harm".  I suppose this
latter is the key issue.

Still, I don't find it necessary or appropriate with respect to deprecating
rsa-sha1, for reasons previously given.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Jun 2017 03:35:35 +0000

On June 13, 2017 11:16:11 PM EDT, "Murray S. Kucherawy" <[email-masked]> wrote:
>MUST
>issue
>with
>attention to

What I should have said is sometimes standards lead and sometimes they follow.  Bumping up the minimum RSA key size is the standards community catching up to what the operational community did half a decade ago.  OTOH, I think rsa-sha1 usage will decline once there is strong MUST NOT guidance published.  Not immediately, but considering the mail system development, deployment, upgrade life cycle it's much better to give things a good push in that direction now, before its time to panic..

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Tue, 13 Jun 2017 21:18:09 -0700

On 6/13/17 8:29 PM, Murray S. Kucherawy wrote:
> On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>>         That being the case, why do we think people will pay
>>         attention to a MUST NOT today?
>
>         Because implementations will stop supporting rsa-sha1, forcing
>         the issue for any who upgrade. I'm all for having them stop
>         supporting signing with rsa-sha1, but they should continue to
>         support verification for a while.
>
>
>     attention to the advice in RFCs ("Operational practice​ isn't
>     closely coupled with standards changes").  If that's true, then
>     there's no meat to a MUST NOT anyway, and it really only matters
>     what people will implement.  And if that's true, then saying
>     current implementations neither sign with nor verify "rsa-sha1"
>     because it's deprecated suffices, and we're done.
>
>

With respect to whether you need to include the MUST NOT (a point you
made earlier), I'll defer to whatever the accepted practices are on the
wording.

> close to that at all with SHA-1....
which I interpret as little potential for causing harm in the near future.

-Jim

P.S. It would be helpful for you to identify which of your comments are
made as chair and which are made hats-off.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Jun 2017 00:24:47 -0400

> I still think we should MUST NOT both signing and verification for rsa-sha1 if for no other reason than to not require implementations to support three algorithms, but I am starting to get the sens…

It is a two step process in my view. First you rip out the generate,
then once the transition is complete, you rip out the accept.

SHA-1 is causing lots of issues as folk find 'funny' japes such as
bjorking GIT repos by uploading the pdf from the shattering. H(A1) =
H(A2) but H(Zip {A1, B, D, E, F}) <> H(Zip {A1, B, D, E, F})

Getting rid of SHA1 is the long term plan. But not in one go.

---

From: denis bider <[email-masked]>
Date: Wed, 14 Jun 2017 02:31:58 -0600

Overall, I think there is currently too much being said on this list, and
too little substance in it. However, to the extent that a decision is to be
made, I support Phillip's below reasoning.

+1.

On Tue, Jun 13, 2017 at 8:11 PM, Phillip Hallam-Baker <[email-masked]

> NOT

---

From: Seth Blank <[email-masked]>
Date: Wed, 14 Jun 2017 11:02:17 +0100

On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker <[email-masked]
> then once the transition is complete, you rip out the accept.

I disagree. SHA-1 has been deprecated for far too long, but is still in
wide use by major players. I'd argue step 1 was taken ages ago (with a
SHOULD, not a MUST, but still...) and we're at step 2 *now* because senders
aren't complying with up-to-date crypto standards on their own.

While a large number of senders may not pay attention to language in an
RFC, in my experience the verifiers have a strong incentive to follow the
RFC language to a tee whenever possible to maximize interoperability. And
the senders don't change unless the receivers make them.

At this point, why don't we call a spade a spade, and say that the only way
to kill SHA-1 in the wild dead is by saying verifiers MUST NOT verify
SHA-1. Then the verifiers will do what they always do, and reach out to
those not playing by standards and say "upgrade your implementation or
it'll start being rejected in 90 days" and letting the problem solve itself.

I believe this is exactly what draft-01 accomplishes.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Jun 2017 04:53:37 -0700

On Tue, Jun 13, 2017 at 9:18 PM, Jim Fenton <[email-masked]> wrote:

> With respect to whether you need to include the MUST NOT (a point you made
> earlier), I'll defer to whatever the accepted practices are on the wording.
>

This actually leads me to believe that there's no urgency to deprecate
rsa-sha1 at all.

> made as chair and which are made hats-off.

Unless you see me explicitly saying the hat is on, especially in a
technical discussion, the hat is always off.  I'm participating.

I don't think it's ever appropriate for a chair to make hatted assertions
about technical topics unless being called on to make a decision when the
WG is deadlocked, and that should be exceptional.  In the chair role, we
just run the process.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Jun 2017 08:15:23 -0400

> This actually leads me to believe that there's no urgency to deprecate

The thing about surprises is that they don't show up when expected.  Given we 
have rsa-sha256 and want to add another algorithm, taking the MUST NOT sign 
step now for rsa-sha1 so it's a short putt to remove it entirely when such a 
weakness is unearthed is a prudent step forward.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Jun 2017 05:34:41 -0700

On Wed, Jun 14, 2017 at 3:02 AM, Seth Blank <[email-masked]> wrote:

> On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>>
> [...]

I think that's an interesting perspective, specifically that step 1 was
taken a while ago, and I agree.  What we're discussing is the right way to
"rip out the accept".

I don't believe that either actor will be compelled to do anything more by
"MUST NOT" than by simply "We don't use that anymore because $REASONS."
I've been a medium-sized receiver before, and I work for a large sender
now.  If I decide I'm going to comply with the update, either prose is
compelling to me.  Am I exceptional in that regard?  Maybe I'm atypical
because I'm an IETF participant, but to me the general issue here plain old
operational inertia rather than the absence of an RFC telling them what to
do.

If a receiver says "update within 90 days or else", it will happen no
matter what the text says.  It could happen today even without us
publishing anything at all.  I would even posit that it's more likely for
M3AAWG to trigger that action than the IETF.

Please note that I'm not only being sticky on this point because I think
it's wrong.  Unnecessary use of RFC2119 language is a topic that's come up
with nearly every email-related standards track RFC where I've been a
contributor and has resulted in DISCUSSes during IESG Evaluation.  I'm
hoping to head off some of that back-and-forth later by getting it sorted
out now.

-MSK

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 14 Jun 2017 13:00:03 +0000

As an indvidiual, I first thought there was no urgency given how DKIM is used.  But PHB's message (the one that included the phrase national security) convinced me otherwise.  We do/could have nation-state agencies involved here.  Time to move off SHA1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Jun 2017 10:06:01 -0400

On Wed, Jun 14, 2017 at 8:34 AM, Murray S. Kucherawy
<[email-masked]> wrote:
>> On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker
>> <[email-masked]> wrote:
>>>
> I've been a medium-sized receiver before, and I work for a large sender now.
> If I decide I'm going to comply with the update, either prose is compelling
> to me.  Am I exceptional in that regard?  Maybe I'm atypical because I'm an
> IETF participant, but to me the general issue here plain old operational
> inertia rather than the absence of an RFC telling them what to do.

I don't understand your line of reasoning. I certainly disagree with it.

DKIM is an IETF specification. If IETF makes a change then M3AAWG will
almost certainly follow suit. But I do not think it at all likely
M3AAWG would start making suggestions on technical matters like this
in preference to IETF action.

People ignore standards all the time. But there are consequences.
Getting people to upgrade their crypto is actually one of the easier
things to persuade people to do. The only circumstance when it becomes
hard is when the new crypto is not widely understood by the
applications that must receive the messages and there is no way to
negotiate an upgrade. That is why S/MIME was stuck doing 3DES for a
decade.

Any transition has to be driven by the state of the deployed
infrastructure. The sequence of facts that need to be gathered are as
follows:

X = proportion of implementations that accept RSA/SHA-2-256 signatures.

Y = proportion of implementations that accept Ed25519 signatures

>From these facts we then build a state machine that guarantees that
95-99% of all messages will be correctly processed by the deployed
infrastructure.

Phase 1) Dual sign with RSA/SHA-1 and RSA/SHA-2-256

Phase 2) Sign with RSA/SHA-2-256

Phase 3) Sign with Ed25519

The decision to use MUST, MUST NOT, etc. is then driven by math.
M3AAWG does not make the decision but they are probably best placed to
collect the data.

---

From: Peter Goldstein <[email-masked]>
Date: Wed, 14 Jun 2017 09:25:42 -0700

> M3AAWG does not make the decision but they are probably best placed to

The phases as described here do not fit the situation at hand.  As written
they mix two separate questions - rsa-sha1 vs rsa-256 and RSA vs Ed25519.
Those need to be considered separately.  Moreover, for the
rsa-sha1/rsa-sha256 the phases are also inappropriate because X is already
~100%

Verifiers were required to support rsa-sha256 by RFC 6376 -
https://tools.ietf.org/html/rfc6376#section-3.3 - and I'm unaware of any
verifier who does not support rsa-sha256.  Combine that with the fact that
a large number of systems (easily the majority of DKIM signers) currently
sign with rsa-sha256 (G Suite, Office365, Facebook, Twitter, etc.) and see
no need to dual sign with rsa-sha1, there's no reason to believe that there
is any significant non-zero population of receivers that validate DKIM for
rsa-sha1 but not for rsa-sha256.  Dual signing with rsa-sha1 and rsa-sha256
is not a necessary step in the rsa-sha1 deprecation process.

Rolling out Ed25519 signing support is a separate question, and it should
not be mixed with the rsa-sha1 deprecation question, even if they are
rolled into one document.  There is, as far as I know, no intention to
deprecate RSA in favor of Ed25519.  Rather the intention is to add Ed25519
as a more modern option for senders that supports shorter keys with better
resistance to attacks.

The current question before the working group is basically a procedural one
- Should we use the RFC2119 MUST NOT language for verifiers and their
acceptance of rsa-sha1 (transitioning from the affirmative SHOULD in RFC
6376) or avoid the use of such language?

Best,

Peter

-- 

Bringing Trust to Email

[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 14 Jun 2017 13:51:23 -0000

>in preference to IETF action.

Hi from the M3AAWG meeting in Lisbon.

M3 publishes the occasional BCP, not standards. There's been a fair
amount of hall conversations about how to get the signers still using
sha-1 to switch.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sun, 18 Jun 2017 10:03:37 -0400

> amount of hall conversations about how to get the signers still using

Are we having a "serious" security issue, yet?  We haven't even 
finished on figuring out how to  trust signatures. Will bad guys 
"switch?" I continue to believe its about "author domain policy" so 
when we look an organization up, they tell us what to expect.  That 
would be a first step, imo.

-- 
HLS