Subject: [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

From: Sean Turner <[email-masked]>
Date: Fri, 01 Oct 2010 18:04:07 -0400

While writing an update for the MD2, MD4, and MD5 security 
considerations, somebody pointed out that we should do the same for 
SHA-1.  We ended up doing SHA-0 too.  Below is a link to the draft. 
Please send comments to saag/cfrg.

spt

-------- Original Message --------
Subject: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt
Date: Fri,  1 Oct 2010 13:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Security Considerations for the SHA-0 and SHA-1 
Message-Digest Algorithms
	Author(s)	: T. Polk, S. Turner, L. Chen
	Filename	: draft-turner-sha0-sha1-seccon-00.txt
	Pages		: 7
	Date		: 2010-10-1
	
    This document updates the security considerations for the SHA-1
    message digest algorithm.  Additionally, it discusses security
    considerations for the SHA-0 message digest algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-turner-sha0-sha1-seccon-00.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Oct 2010 09:25:25 -0700

At 6:04 PM -0400 10/1/10, Sean Turner wrote:
>While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we should do the same for SHA-1.  We ended up doing SHA-0 too.  Below is a link to the draft. Please send comments to saag/cfrg.

4. Guidance

   SHA-1 no longer provides an acceptable security level when used in
   digital signature applications.  IETF protocol designers SHOULD NOT
   specify digital signature algorithms using SHA-1 as mandatory to
   implement.  IETF protocols that rely on SHA-1 based digital
   signatures MUST include countermeasures that mitigate SHA-1's reduced
   collision resistance by randomized hashing (e.g., as specified in
   [SP800-107]).

   HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm
   for IETF protocol design.

   As noted above, any use of SHA-0 is strongly discouraged. Discussions
   regarding the strength of SHA-0 were included for completeness only.
   SHA-0 has no functional or performance advantage, and SHA-1 is
   considered significantly more secure.

There are many serious issues here. First the procedural ones.

- It is not "guidance" if you use "MUST": it is a mandate. In this case, it is not clear why the authors get to make a mandate on IETF protocol designers. If it is because two of the authors are Security ADs, the document should say so explicitly (although then you have to explain why you dragged Lily into it). If it is because two of the authors are from NIST, the document should say so explicitly (although then you have to explain why you dragged Sean into it).

- The "SHOULD NOT" in the first paragraph does not say when it is OK to do so anyway, so this goes against RFC 2119.

- There is no explanation of why an Informational RFC have any effect on IETF standards-track documents.

Next the security issues.

- The first sentence is obviously wrong unless you believe that >95% of all financial transaction in the world today are insecure. This type of hyperbole does not belong in IETF documents.

- The third sentence, on randomized hashing, is not based on reality. Few if any of the current IETF protocols show how to carry the random number used. This sentence essentially says "all IETF protocols must use an unspecified protocol".

- The third paragraph makes it sound like there is a security problem that needs to be solved, but there isn't. A quick search shows that exactly two RFCs even mention SHA-0, and neither RFC is a protocol.

If the authors really did mean to give useful guidance, I propose the following replacement for this section:

=====
SHA-1 provides less collision resistance than was originally
expected, and collision resistance has been shown to affect some (but
not all) applications that use digital signatures. Even if SHA-1's
collision resistance was as good as was expected, SHA-256's collision
resistance and resistance to finding pre-images are much higher by
design.

Because of this, designers of IETF protocols should put a strong
preference for signature algorithms with SHA-256 in their protocols.
The typical way to give such a preference is to make the algorithm
that uses SHA-256 mandatory, while the algorithm using SHA-1 being
optional. Of course, SHA-0 should continue to not be used in any IETF
protocol.

Nearly all IETF protocols that use signatures assume existing public
key infrastructures, and SHA-1 is still used in signatures nearly
everywhere. Therefore, it is unwise to prohibit the use of SHA-1 in
signature algorithms. However, it is certainly useful to point out in
the security considerations for those protocols that SHA-1 is not as
strong as SHA-256.

A protocol designer might want to consider the use of SHA-1 with
randomized hashing such as is specified in [SP800-107]. However, such
use will still not be stronger than the normal use of SHA-256, and it
expands the size of signatures and requires them to carry material
that is not needed today.

HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm
for IETF protocol design.
=====

You can then remove the reference to RFC 2119.

--Paul Hoffman, Director
--VPN Consortium

---

From: der Mouse <[email-masked]>
Date: Sat, 2 Oct 2010 20:53:30 -0400 (EDT)

> - The third sentence, on randomized hashing, is not based on reality.
> Few if any of the current IETF protocols show how to carry the random
> number used.

This is not necessarily a reason not to use randomized hashes; the
random number could, for example, be prepended to the "real" hash.

> This sentence essentially says "all IETF protocols must use an
> unspecified protocol".

This, however, is valid...absent a standardized way to package the
random number together with the "real" hash, at least.

> [proposed alternative text]
> Even if SHA-1's collision resistance was as good as was expected,

While I realize the subjunctive is on its way out in English, there's
no need to hurry the process, and there are still people, like me, who
have a little internal voice piping up saying something uncomplimentary
about the literacy level of the author upon seeing something like this.

You might want to fix it, if only to avoid the negative emotional
colour it provokes in some readers.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 03 Oct 2010 21:50:49 +0100

Must say I agree with Paul's concerns below (and in particular
hesitated too when I read the intended "MUST NOT" effect of a guidance
informational draft on standards documents).
However, I think the general idea to write a guidance ID is a good idea
from Tim, et al.

One further comment: I am a bit uncertain to why you refer to SHA-256
from the SHA-2 family only (and thus not mention/exclude SHA-512)?

Tobias

On 10/02/2010 05:25 PM, Paul Hoffman wrote:
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 3 Oct 2010 14:35:23 -0700

>However, I think the general idea to write a guidance ID is a good idea

Fully agree (certainly more useful than such guidance coming from you or I). However, it would be nice if the document said why they were the ones writing it.

>from the SHA-2 family only (and thus not mention/exclude SHA-512)?

Because the IETF almost always deals only with 128-bit strength security, and using SHA-384 or SHA-512 is just as waste of processor and network resources in such cases.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 04 Oct 2010 11:02:55 +0200

> following replacement for this section:

Re-reading the original text and Paul's proposed text below, I strongly
prefer the latter one.  The situation is not as simple as the original
text implies, and this needs to be conveyed by the document somehow.
Avoiding RFC 2119 language, which doesn't make sense for an
Informational document anyway, is a good way to achieve this.

/Simon

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 4 Oct 2010 10:51:38 -0700 (PDT)

On Sun, October 3, 2010 2:35 pm, Paul Hoffman wrote:
> Because the IETF almost always deals only with 128-bit strength security,
> and using SHA-384 or SHA-512 is just as waste of processor and network
> resources in such cases.

  That's an odd statement. There is suite B guidance for use of quite alot
of IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME-- that provide for more
than "128-bit strength security". The qualifier ("almost always") even adds
to the oddness. Check out the D-H groups for use in IKE. They run the gamut
of strength estimates. Arguably neither of the cryptographic suites for
IPsec from RFC 4308, of which you are the author, provides 128-bits of
strength security (the required D-H groups afford approximately 80 to
"VPN-A" and 112 bits to "VPN-B").

  We continue to define the use of ciphers with > 128 bit keys. We
continue to define the use of D-H groups that produce shared secrets
of > 128 bits of approximate strength. Hash algorithms that can be used
in key derivation, key confirmation, and digital signatures which afford
greater than 128-bits of approximate strength should not be excluded.

  Dan.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Oct 2010 11:13:15 -0700

>"VPN-A" and 112 bits to "VPN-B").

Right; this my purposeful vagueness above.

>greater than 128-bits of approximate strength should not be excluded.

All true, but not relevant to the text I gave. The draft as it stands *also* doesn't say what to do for signatures that are meant to be at strengths greater than 128 bits; it is about not using SHA-0 at all and not specifying SHA-1 as the default.

If there is a desire for a different document that tells security protocol writers what signature algorithms would be good to include as mandatory, that's fine, but it should not be this document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Oct 2010 13:58:33 -0500

On Sat, Oct 02, 2010 at 09:25:25AM -0700, Paul Hoffman wrote:
> - It is not "guidance" if you use "MUST": it is a mandate. In this
> case, it is not clear why the authors get to make a mandate on IETF
> protocol designers. [...]

RFCs can impose mandates on protocol designers the same way that the
U.S. Congress can pass laws that bind future Congresses.  I.e., Congress
can only pretend, but can't really bind future Congresses (or even the
same Congress).  But, so what?  RFCs are the tool that we have for
communicating such non-protocol matters as IETF process, so we might as
well use them to "impose" mandates on protocol designers.

> on IETF standards-track documents.

Even if it were a standards track RFC it still couldn't have any more
effect on future standards-track RFCs than... the IESG and IETF are
willing to enforce when reviewing future submissions.  See above.
Guidance such as this belongs in a BCP, if anything...

For the rest, I mostly agree with Paul.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 04 Oct 2010 17:44:51 -0400

> willing to enforce when reviewing future submissions.  See above.

No, there's a big difference here.  A published BCP represents IETF 
consensus on an issue, and authors of later documents should expect to be 
consistent with that consensus, demonstrate (to the level of a new IETF 
consensus) why the new dociment should be differnet, or not have the new 
document progress.

For example, if you try to progress a document that defines a new security 
protocol which doesn't include automatic key management, you'd better 
explain why that's OK or expect me to throe RFC4107 at you.  In such a 
situation, I don't need to build an IETF consensus that automatic key 
management is a good idea and that you need to demonstrate why manual 
keying is appropriate for your protocol -- BCP107 represents such a 
consensus, both in the security area and, presumably, in the IETF as a 
whole.

By contrast, an Informational RFC does not necessarily represent such a 
consensus, and the process for approving one is not designed to ensure that 
it does.  This is one of the reasons we use BCP's to define IETF process - 
a BCP represents community consensus, while an Informational RFC does not.

So yes, if this document intends to impose a mandate, then it needs to be 
published as a BCP with an appropriate IETF-wide last call period.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Oct 2010 16:52:28 -0500

On Mon, Oct 04, 2010 at 05:44:51PM -0400, Jeffrey Hutzelman wrote:
> consensus on an issue, and authors of later documents should expect
> to be consistent with that consensus, demonstrate (to the level of a
> new IETF consensus) why the new dociment should be differnet, or not
> have the new document progress.

Sure.  But BCP != Standards-Track.  Also, I did state that
"[g]uidance such as this belongs in a BCP" -- my reply to Paul wasn't so
long that you could have missed that :)

And still, BCPs are not self-enforcing.  The IETF and the IESG need to
enforce them actively.

I think we're in agreement.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Oct 2010 15:07:16 -0700

At 4:52 PM -0500 10/4/10, Nicolas Williams wrote:
>Sure.  But BCP != Standards-Track.

BCP ~= Standards Track. From RFC 2026:

5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

>And still, BCPs are not self-enforcing.  The IETF and the IESG need to

Indeed.

>I think we're in agreement.

Indeed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 05 Oct 2010 16:41:16 +1300

"Dan Harkins" <[email-masked]> writes:

>That's an odd statement. There is suite B guidance for use of quite alot of
>IETF protocols-- TLS, SSH, IKE/IPsec, S/MIME

And how many of those have you see used outside the USG, which operates more
or less in its own world anyway?

Peter.

---

From: SM <[email-masked]>
Date: Tue, 05 Oct 2010 13:29:31 -0700

At 14:44 04-10-10, Jeffrey Hutzelman wrote:
>By contrast, an Informational RFC does not necessarily represent 
>such a consensus, and the process for approving one is not designed 
>to ensure that it does.  This is one of the reasons we use BCP's to 
>define IETF process - a BCP represents community consensus, while an 
>Informational RFC does not.

Please see the "Status of This Memo" in RFC 5968, RFC 5982 RFC 5997, 
RFC 6007 and RFC 6018.  According to the text, the Informational RFC 
represents the consensus of the IETF community.

Regards,
-sm

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 3 Oct 2010 18:12:39 -0400

Given the uncertainty surrounding the SHA-2 construction, use of the 512 bit
version which has more rounds would appear prudent.

Also, given that SHA-3 is going to arrive and have 256 and 512 bit versions,
it is probably a good idea to start using the full name SHA2-256.

On Sun, Oct 3, 2010 at 5:35 PM, Paul Hoffman <[email-masked]> wrote:

> Fully agree (certainly more useful than such guidance coming from you or
> I). However, it would be nice if the document said why they were the ones
> writing it.
>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Oct 2010 09:22:28 -0400

AES and SHA-2 are part of Suite B and more or less everyone uses them.

Plenty of people require stronger crypto than 128 bit. While 128 bit
work-factor is more than ample if you believe that the algorithms are sound,
the 256 bit variants offer more rounds and more rounds means a stronger
scheme.

If you are encrypting medical data that is required to be confidential for
the lifetime of a 6 month old patient, you might well be obliged to use 256
bit.

These issues tend not to affect IETF much because most of what we do is
communications protocols and the sensitivity of the traffic is mostly
limited to a few months. Knowing the internals of a $1 billion merger deal
would be very valuable to an attacker before the announcement but worthless
afterwards.

But on the standards issue, I have for many years thought that we should
have an RFC that lists the set of base crypto that compliant applications
MUST support and MUST deprecate.

So then an S/MIME implementation would advertise itself as compliant with
RFC5751and RFC6666 and this would mean that it supported all the crypto
suites in the MUST implement list and does not generate content in the MUST
deprecate list in the 'normal' mode of use.

The reason I have not gone further with this proposal is that it really
requires a policy layer in the Internet stack before it is useful.

On Mon, Oct 4, 2010 at 11:41 PM, Peter Gutmann <[email-masked]>wrote:

> of

---

From: Sean Turner <[email-masked]>
Date: Wed, 06 Oct 2010 21:20:29 -0400

> Fully agree (certainly more useful than such guidance coming from you or I). However, it would be nice if the document said why they were the ones writing it.

The 2119 language should not have been included.  We're only trying to 
update the security considerations not provide mandates.  This draft 
should have followed the same format as the recent MD2/4/5 security 
consideration update drafts and those don't include 2119 language. 
I'm sorry for any confusion.

We wrote this draft because somebody asked for it as part of their 
comments on the MD2/4/5 drafts (and I thought it was low hanging 
fruit).  I assure you there is no sinister plan.

We'll update the draft with the Paul's wording, remove the 2119 
reference, and address off-list comments from Ran and Sheila.

spt