Subject: [Dcrup] Open issue -- sha1 must not generate [and|or] accept

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jul 2017 19:29:35 +0000

At last week's IETF we discussion  https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage

The biggest discussion point was about the deprecation.  Consensus in the room was to use MUST NOT for both generating and accepting SHA1 and short RSA keys.

In order to make sure that we have heard all sides of this issue,  would those who support something other than MUST NOT please post by next Wednesday?

Thank you!

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Jul 2017 12:53:51 -0700

> In order to make sure that we have heard all sides of this issue,  would those who support something other than MUST NOT please post by next Wednesday?

As I have said before, I support MUST NOT sign but oppose MUST NOT
accept. The argument for MUST NOT accept is that we need the force the
issue to get people to stop signing with SHA1.

I don't agree with this argument because:

1. While we want to get people off SHA1, it doesn't enable an attack and
none is anticipated in the near (next several years) future. By
"attack", here means that someone is able to sign a different message
given an existing DKIM signed message (or many of them). I believe this
would require somewhere between a first and second preimage attack.

2. In the absence of an anticipated successful attack, I lean toward
interoperability.

3. MUST NOT sign should be sufficient to get domains to do the right thing.

I am even more opposed to "MUST NOT implement SHA1". Our standards
should be dictating what to do, not prohibiting code from existing in
implementations.

-Jim

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jul 2017 19:56:47 +0000

> should be dictating what to do, not prohibiting code from existing in

We should not say MUST NOT implement.  Do we?

---

From: Jim Fenton <[email-masked]>
Date: Mon, 24 Jul 2017 13:04:44 -0700

> We should not say MUST NOT implement.  Do we?
Other IETF standards say MUST NOT implement, RFC 6944 for example. I
thought I heard someone mention that wording in the WG meeting the other
day which is why I brought it up.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jul 2017 20:05:49 +0000

> thought I heard someone mention that wording in the WG meeting the
> other day which is why I brought it up.

Timo brought it up and said that it cause[sd] problems for IPsec and that we shouldn't do it.

---

From: "A. Schulze" <[email-masked]>
Date: Mon, 24 Jul 2017 22:34:04 +0200

> We should not say MUST NOT implement.  Do we?

I like "MUST NOT implement".

I see no benefit on "SHOULD NOT validate SHA1"
My server - my rules - but my users, too. "MUST NOT validate" is a justification to /my/ users.
They don't ask if any other organization behave wrong, they ask me (as their ISP)
Responding with "the sender MUST NOT sign" is not enough.

Users understand "SHA1 = broken". That's what we, the industry, claim for more then 10 years.
But they don't distinguish the fine difference between "SHA1 is bad in certificates but still acceptable in DKIM signatures" ?

SHA1: MUST NOT implement.

any operator running a software that implement SHA1 is free to not enforce MUST NOT for it's local requirements.
So there is no real damage...

Andreas

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jul 2017 20:42:09 +0000

I am sorry, I used the word "implement" and then said "we should not use that."

Let me rephrase.  Do not generate, do not validate SHA1 and short-key RSA.

Jim disagrees and wants validation to remain.

> But they don't distinguish the fine difference between "SHA1 is bad in
> certificates but still acceptable in DKIM signatures" ?

Yes, the chance of confusing the user community seems very high.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Jul 2017 00:26:04 +0200

> Yes, the chance of confusing the user community seems very high.

Really?  To whom are you referring when you say "users" and "user
community"?  Surely not the vast majority of email users in the world,
almost none of whom have the slightest idea what SHA1 is, much less
whether or not it's broken.

If what you're referring to by "users" is the set of people who are
responsible for deploying DKIM software, well... those aren't "users",
and, anyway, most of them don't look at the DKIM specs anyway.
Someone's going to sell them software along with configuration advice,
and they're going to install it and configure it based on that advice.

If what you're referring to by "users" is the set of people to
develop/code DKIM implementations, well... those are the people who
are, or at least ought to be, reading the DKIM specs.  We need to make
sure we're saying the right thing to those people, so they can right
code that works and interoperates and configuration advice that helps
the group in the paragraph above properly configure their systems.

If you really think *that* group of people will be confused by the
advice we're giving on SHA1, then it's pretty easy to include an
explanation of *why* we care as far as we do and not farther, and why
we want to get people to stop using SHA1 but aren't ready to drop a
bomb on it yet.

Barry

---

From: Hector Santos <[email-masked]>
Date: Tue, 25 Jul 2017 01:05:17 -0400

> We should not say MUST NOT implement.  Do we?

-1, No.

You're not going to stop everyone from covering all existing protocol 
options, including legacy operations.  You're not paying for my 
support issues when complaints come in reporting that our "New DKIM 
package with only SHA256 support" does not support valid incoming mail 
with SHa1.  You're not going to force people to update or upgrade when 
in all honestly SHA1 is still valid today.  Most people don't change 
until a real problem exist and I think this will also cause major 
problems for valid senders who all of a sudden have their SHA1 DKIM 
mail not accepted at SHA256 receivers.

If you want to discuss this in the specification, I think we are smart 
enough to read amd decide, but to try to "enforce" this, I don't think 
that would be right.  I don't consider that "Protocol Development" 
personally.

Note: This doesn't mean I won't change the DKIM signing options on my 
system, but I am not about to add logic to reject/invalidate a SHA1 
message, nor pull the code to handle it, and I really hope others 
don't go about pulling SHA1 support on their system causing problems 
for people who haven't unnecessarily changed yet.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 25 Jul 2017 01:08:00 -0400

Sorry, misread the double negative.

It should be a "SHOULD NOT SIGN" security concept.  Thats it.  Its not 
that difficult.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2017 04:01:09 -0000

>we want to get people to stop using SHA1 but aren't ready to drop a

I hear a lot of large mailers still do SHA-1 largely because they can.  Keeping in
mind that switching from SHA-1 to SHA-256 is just a configuration change (the code's
been there for a decade) how about MUST NOT sign and SHOULD NOT verify?

SHOULD NOT means MUST NOT unless you understand why you're doing it
anyway, which sounds right in this case.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Thu, 27 Jul 2017 04:04:10 +0000

I can get behind this.

Barry

On Thu, Jul 27, 2017 at 12:01 AM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2017 00:14:45 -0400

On Thursday, July 27, 2017 04:01:09 AM John Levine wrote:
> In article <CAC4RtVCrBNEGJMo8qiZH8N7tg9FBuKmz8Qx-
[email-masked]> you write:
> I hear a lot of large mailers still do SHA-1 largely because they can. 
> Keeping in mind that switching from SHA-1 to SHA-256 is just a
> configuration change (the code's been there for a decade) how about MUST
> NOT sign and SHOULD NOT verify?
> 

No one is forced to claim they've updated to the requirements of this new 
draft.  I think MUST NOT sign/MUST NOT verify is much cleaner and it avoids 
yet another draft later.

How long do we wait before we write that one?

Let's just rip the band-aid off and get it done.

Scott K

---

From: Jon Callas <[email-masked]>
Date: Wed, 26 Jul 2017 23:11:50 -0700

I agree with Rich Salz's previous comments that we should not say MUST NOT.

The purpose of a standard is to provide interoperability. It is a grammar of how to interpret a message. It is not a programming guide nor an implementation manual. If you want to put in scolding language about how SHA-1 will cause hair to grow on the palms of their hands, I can get behind that, too.

In practical terms, as much we all want people to get off of SHA-1, the implementers have to implement. And as much as we might rail about it, they have do deal with our idealism meeting reality. Beyond that, we don't have any teeth in this. If someone implements DKIM and does SHA-1 because their customers demand it, what are we going to do? Type a protest note to them and hit the keys really hard? What if the implementer issues a warning saying that ZOMG, if you use SHA-1, you're not compliant with RFC XXXX?

Lest you think that I'm supporting SHA-1, I'm not. I'm being realistic. Twenty years ago, when MD5 was in a similar state, it was hell getting people to stop using it. You can lead them to water, but you can't make them drink. It's better to say SHOULD NOT and have it all stated out, than to say MUST NOT and have people just know that yeah, yeah, RFCs aren't to be taken seriously.

	Jon

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jul 2017 11:02:46 +0000

> draft.  I think MUST NOT sign/MUST NOT verify is much cleaner and it avoids

Speaking as an individual, I find this reasoning very compelling.

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 14:06:18 -0400

-1, I can't get behind a "SHOULD NOT verify with SHA1."

I don't see me turning off SHA1 verification in my package unless it 
comes with some additional conditions, such as:

    SHOULD NOT verify with SHA1 IFF you don't trust the source,
    i.e. unsolicited, unauthenticated sessions.

or stated another way:

    SHOULD only verify with SHA1 if you trust the source, i.e.
    authenticated sessions.

At best, this is just another local policy consideration, a BCP which 
means that the DKIM specs needs to say both SHA256 and SHA1 MUST be 
implemented for legacy and migration reasons.

-- 
HLS

On 7/27/2017 12:04 AM, Barry Leiba wrote:
> I can get behind this.
>
> Barry
>
> On Thu, Jul 27, 2017 at 12:01 AM John Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     In article
>     <[email-masked] <mailto:[email-masked]>>
>     you write:
> Barry Leiba  ([email-masked] <mailto:[email-masked]>)
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 14:14:51 -0400

> In practical terms, as much we all want people to get off of SHA-1, the implementers have to implement....

Basic engineering insights will suggest it will not be practical 
without a migration path.

I'm all for a POLICY-based system which already exist with the DKIM 
key "h=" tag. If the originating domain is worry about possible SHA1 
exploited mail fraud, then it has the facility to expose what its 
expectations are (h=sha256). It is the verifiers that now needs to 
leverage the policy-based information.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 14:32:51 -0400

> Speaking as an individual, I find this reasoning very compelling.

Not to me.

The problem is that it will immediately put developers and 
implementors in tight positions of technically "violating" the 
specification right out of the box.

Thats not good IETF protocol development for everyone involved.  Can't 
force people to do the "wrong" engineering thing that they believe to 
be true.

SHA1 exist. It is a rare STD status document. We worked hard for it. 
Its a migration issue to remove SHA1 and we have the technical STD 
feature and facility for domains to set h=sha256 in their keys and for 
verifiers to honor it. What the specs could say, if not already, in so 
many words:

    "If the signer domain key has a h=sha256 tag, then the verifier 
MUST NOT
     verify any SHA1 mail."

That effectively invalidates the DKIM message triggering other 
possible local policy mail handling features;

Imo, that's good and fair protocol negotiation engineering for all 
parties involved.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jul 2017 18:37:23 +0000

> The problem is that it will immediately put developers and implementors in
> tight positions of technically "violating" the specification right out of the box.

Speaking as co-chair:
   You are only violating the spec if you claim to support it. So until you can actually STOP doing SHA1, you don't claim support.

Speaking as an individual:
  This draft sends a strong message to everyone to stop generating and verifying SHA1 very soon.  We have been saying "stop" for years now.  It's time to ramp up the pressure.

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 14:54:26 -0400

On 7/27/2017 2:37 PM, Salz, Rich wrote:>>

>     You are only violating the spec if you claim to support it. So until you can actually STOP doing SHA1, you don't claim support.

Yes, and I believe it is also wrong to label anyone of violating the 
specification, in fact, it can be considered "tort,"  when in fact 
there is strong reason the believe the specification was incorrect and 
with excellent possibilities that other current implementators are not 
going follow it as well.  There are many more implementators out there 
that do not hang out here. It will be a big surprise to them.

>    This draft sends a strong message to everyone to stop generating and verifying SHA1 very soon.  We have been saying "stop" for years now.  It's time to ramp up the pressure.

That doesn't work for the reasons stated and chances are good it will 
cause more problems with new implementators learning the hard way. We 
should not ignore the engineering migration considerations by 
leveraging the feature that already exist.

-- 
HLS

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Jul 2017 12:00:22 -0700

> On Jul 27, 2017, at 11:37 AM, Salz, Rich <[email-masked]> wrote:
> 

Sure.

However, let me suppose that I am an implementer and my customers tell me that if I drop SHA1 they'll go to someone else, and also tell me that if I don't support ECC, they'll go to someone else. What do I do?

Strong message aside, and even agreeing with the sentiment to get rid of SHA1, it sounds like our advice is to say that you support RFC XXXX (DKIM with SHA1) and RFC YYYY (DKIM with ECC but no SHA1) and talk out of whichever side of your mouth seems appropriate, and if you have to change mouth sides with every other sentence, do so.

	Jon

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jul 2017 19:02:08 +0000

> However, let me suppose that I am an implementer and my customers tell
> me that if I drop SHA1 they'll go to someone else, and also tell me that if I
> don't support ECC, they'll go to someone else. What do I do?

Should not be a problem; the "don't use SHA1" document is separate from the "use ECC" document, for just this reason.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jul 2017 19:03:46 +0000

Nobody is labelling anyone as being in violation of anything.  The IETF doesn't have a compliance arm, nor even a brand enforcement arm. :)

If you want to sign via SHA2, go ahead.  Nobody is stopping you, and the document says how to do it.

If you want to say you are say you are compliant with the "do not use SHA1" document, then don't use SHA1.

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 15:58:03 -0400

> Nobody is labelling anyone as being in violation of anything.  The IETF doesn't have a compliance arm, nor even a brand enforcement arm. :)

But there is product branding, reputation, support and cost concerns 

> If you want to sign via SHA2, go ahead.  Nobody is stopping you, and the document says how to do it.

Did you mean SHA1?

> If you want to say you are say you are compliant with the "do not use SHA1" document, then don't use SHA1.

My implementation has evolved from the original DKIM drafts to the 
STD76 DKIM-BASE document. https://tools.ietf.org/html/std76.

A new "update" proposal that changes its STD features in regards to 
SHA1 and SHA256 can be supported and compliant by developers who MUST 
deal with all possibilities, including verifying SHA1 mail.   You are 
suggesting they would be violating this
"change" by supporting SHA1 in any way (mostly by verifying because I 
have no issue with the SHA256-only signing recommendation). If so, 
there would be something very IETF wrong about this, especially coming 
from the co-chair.

It fails to see the more completed IETF engineering picture that 
creates or fits the proper protocol for client/server, 
senders/receivers automated negotiations.

This draft proposal needs a discussion on migration which means 
existing developers can consider verifying SHA1 under special 
considerations and still be compliant.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 16:03:01 -0400

> Strong message aside, and even agreeing with the sentiment to get rid of SHA1, it sounds like our advice is to say that you support RFC XXXX (DKIM with SHA1) and RFC YYYY (DKIM with ECC but no SHA1…

Sounds like there should be two documents:

   RFC Update to STD76 that deprecates SHA1
   RFC Update to STD76 that adds ECC

That allows a developer to be supportive of STD76 and the ECC update, 
and choose what he wants to do about the SHA1 update.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jul 2017 20:07:22 +0000

> That allows a developer to be supportive of STD76 and the ECC update, and
> choose what he wants to do about the SHA1 update.

I am confused.  There *are* two documents.

https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/?include_text=1 is about using SHA256 and not using SHA1 for RSA.

https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/?include_text=1 is about using ECC.  And since ECC is brand-new to DKIM, there is no legacy/installed base to deal with so we can just not use SHA1.

Is this okay?  If not, what what is wrong.

---

From: Hector Santos <[email-masked]>
Date: Thu, 27 Jul 2017 16:32:51 -0400

> Is this okay?  If not, what what is wrong.

Sorry, trying to catch up, I was not aware there were two drafts:

1) Cryptographic Algorithm and Key Usage to DKIM
    https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage

2) Defining ECC Algorithms for use with DKIM
    https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc

Ok, perfect!  I thought both ideas was being lump together in the WG 
under one spec change.

Existing Developers will may support #2 and ignore #1 because they 
will continue to support SHA1.  I believe it will cause a problem for 
new developers when they follow #1 by not providing an UI, the SHA1 
features to allow for operators to enable SHA1 verification at a minimum.

Nah, now that I read this draft-ietf-dcrup-dkim-usage proposal, as it 
written for rsa-sha1, I can't support this document.  There are no 
implementation, nor migration notes.  Section 3.1 lacks a discussion 
on the possible operational and support ramifications for 
implementators who follow it.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2017 23:00:52 -0000

In article <[email-masked]> you write:
>https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/?include_text=1 is about using ECC.  And
>since ECC is brand-new to DKIM, there is no legacy/installed base to deal with so we can just not use
>SHA1.
>

Nothing's wrong.  The current draft just says eddsa-sha256, to be renamed ed25519-sha256.

I suppose I should split that from the hashed RSA draft although it's going to be kind of
a pain to cross-reference the new key field in the signature header.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Jul 2017 23:29:39 +0000

> Nah, now that I read this draft-ietf-dcrup-dkim-usage proposal, as it written
> for rsa-sha1, I can't support this document.  There are no implementation,
> nor migration notes.  Section 3.1 lacks a discussion on the possible
> operational and support ramifications for implementators who follow it.

Please consider supplying text.  I think right now the WG has strong consensus, just discussion about MUST or SHOULD.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Jul 2017 09:40:40 +1000

> a pain to cross-reference the new key field in the signature header.

I wouldn't.  The text I provided the other day would be harder to fit
into two documents.