Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Hubert Kario]

On Tuesday 12 January 2016 05:32:08 Viktor Dukhovni wrote:
> On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote:
> > No sane person disputes that MD5 needs to be eradicated ASAP. We're
> > keeping MD5||SHA1 in old TLS for compatibility and we are well
> > aware that needs to go eventually too. Thus, I suggest we publish
> > an MD5 diediedie standards track RFC to prohibit ALL standalone MD5
> > use in ALL IETF
> > protocols/standards.
> 
> With some exceptions, for example:
> 
> * As you note in your last comment, X.509 self-signatures via
> MD5 may continue to be ignored, once MD5 is "banned" in the same
> way that they should have been ignored before it was "banned".
> 
> * S/MIME parsers may continue to parse old S/MIME messages with
>   MD/5 signatures.  More generally, Encrypted data at rest may
>   need support for MD5 for the lifetime of the data (until
>   re-encrypted, ...).

in case of digital signatures, that means "lifetime of the data", you 
can't expect them being possible to re-sign

so it must not completely forbid use of MD-5 in implementations of stuff 
like PAdES-A. Though it should strongly recommend allowing its use in 
only *very* specific circumstances.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Stephen Farrell]

A few notes on this:

- Calling for the IETF to do something isn't how it works. People
who want thing X to be done need to write the draft and then see
if it gets support. I suspect an md5-die-die-die draft would get
quite a bit of support but...

- The points Victor made about long-term stored data are valid.
In various cases it simply wouldn't be a good plan to re-encrypt
or re-sign old data. Yes, that stored data may not be as secure
as it once was, but it may be impractical to re-encrypt it all.
The openpgp wg [1] are dealing with this particular issue as they
work to do updates, so feel free to get involved in that debate
there if it's of interest.

- If your envisaged scope is for all IETF protocols, then I'm sad
to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing
folks just won't let die it seems, even though we formally obsoleted
that [3] 5 years ago. (And yes, that really is sad.)

- Lastly, and again if your envisaged scope is to deprecate MD5 for
all IETF protocols then that might better fit the charter of the new
curdle wg. [4] And your draft might be an update to RFC6151 [5] I
guess, depending on how you wrote it.

So by all means, write the draft and post a link to the curdle
list (maybe cc'ing this).

Cheers,
S.

[1] https://tools.ietf.org/wg/openpgp/
[2] https://tools.ietf.org/html/rfc2385
[3] https://tools.ietf.org/html/rfc5925
[4] https://tools.ietf.org/wg/curdle
[5] https://tools.ietf.org/html/rfc6151


On 12/01/16 03:42, Dave Garrett wrote:
> On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote:
>> My understanding is TLS 1.2 specifically was amended to allow MD5 
>> signatures even though this was not the case in previous TLS
>> versions, or at least that was the claim of the miTLS presenters on
>> SLOTH at RealWorldCrypto 2016.
>> 
>> If this is the case, this seems like a big regression in TLS 1.2.
> 
> I'd like to propose killing the low hanging fruit first, and then
> continue to build on top of that.
> 
> No sane person disputes that MD5 needs to be eradicated ASAP. We're
> keeping MD5||SHA1 in old TLS for compatibility and we are well aware
> that needs to go eventually too. Thus, I suggest we publish an MD5
> diediedie standards track RFC to prohibit ALL standalone MD5 use in
> ALL IETF protocols/standards. Constructions using MD5 with something
> else (namely MD5||SHA1) would also be explicitly recommended against
> in existing specifications, and explicitly prohibited in all new
> drafts (even if unlikely).
> 
> Also, when I say "prohibited" here, I mean _completely_. No MD5
> function should remain in the relevant codebase; if MD5||SHA1 support
> is continued, there should be one function that does only that
> without any way to get a plain MD5 hash. (and no "it's fine for this"
> junk; non-broken hashes are also fine for that, and if you're wrong,
> it's safer) There are too many implementation bugs in this realm to
> not state this explicitly [0].
> 
> Note that continued support of trust anchors with MD5 hashes is not
> dependent on this, as we've already agreed they don't need to be
> validated. (they need to be phased out, but with less urgency) If
> used within this specific context, nothing even needs the ability to
> understand MD5 hashes at all in order to handle these; the
> certificate as a whole is trusted or not.
> 
> 
> Dave
> 
> 
> PS To whomever came up with the "diediedie" term, thank you. ;)
> 
> 
> [0] Note the 3 disabled-but-accepted bugs listed here: 
> https://www.mitls.org/pages/attacks/SLOTH#disclosure
> 
> ___ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Viktor Dukhovni]

On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote:

> No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping
> MD5||SHA1 in old TLS for compatibility and we are well aware that needs
> to go eventually too. Thus, I suggest we publish an MD5 diediedie standards
> track RFC to prohibit ALL standalone MD5 use in ALL IETF
> protocols/standards. 

With some exceptions, for example:

* As you note in your last comment, X.509 self-signatures via
MD5 may continue to be ignored, once MD5 is "banned" in the same
way that they should have been ignored before it was "banned".

* S/MIME parsers may continue to parse old S/MIME messages with
  MD/5 signatures.  More generally, Encrypted data at rest may
  need support for MD5 for the lifetime of the data (until
  re-encrypted, ...).

* PEM files holding RSA private encrypted keys may continue
to use the legacy MD5-based KDF so that the keys can be
decrypted.

> Also, when I say "prohibited" here, I mean _completely_.

There is no Internet police, and the IETF does not get to prohibit
the use of MD5, we only get to write protocol standards.

> No MD5 function should remain in the relevant codebase;

In particular the IETF does not get to tell anyone which functions
they get to include in their codebase.  So no IETF document saying
such a thing makes much difference.

> if MD5||SHA1 support is continued,
> there should be one function that does only that without any way to get
> a plain MD5 hash.

This turns out to be a good idea anyway, thus, for example, OpenSSL
1.1.0-apha2 just recently added an EVP_md5_sha1() hash function.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Tony Arcieri]

On Mon, Jan 11, 2016 at 9:32 PM, Viktor Dukhovni 
wrote:

> > No MD5 function should remain in the relevant codebase;
>
> In particular the IETF does not get to tell anyone which functions
> they get to include in their codebase.  So no IETF document saying
> such a thing makes much difference.


Not being the person who called "diediedie", but being in total agreement
with the OP, "diediedie" should represent a "burn notice" from the IETF to
all implementers:

DO NOT DO THIS!!!

Clearly many TLS stacks still implement MD5, and there are no TLS police to
arrest the people who are ignoring the IETF RFCs and still shipping
diediedie-filled crypto, but if we want any modicum of security want any
sort of security guarantees from TLS, all stacks *MUST* abandon MD5 in its
entirety.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Loganaden Velvindron]

On Tue, Jan 12, 2016 at 3:42 AM, Dave Garrett  wrote:
> On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote:
>> My understanding is TLS 1.2 specifically was amended to allow MD5
>> signatures even though this was not the case in previous TLS versions, or
>> at least that was the claim of the miTLS presenters on SLOTH at
>> RealWorldCrypto 2016.
>>
>> If this is the case, this seems like a big regression in TLS 1.2.
>
> I'd like to propose killing the low hanging fruit first, and then continue to 
> build on top of that.
>
> No sane person disputes that MD5 needs to be eradicated ASAP. We're keeping 
> MD5||SHA1 in old TLS for compatibility and we are well aware that needs to go 
> eventually too. Thus, I suggest we publish an MD5 diediedie standards track 
> RFC to prohibit ALL standalone MD5 use in ALL IETF protocols/standards. 
> Constructions using MD5 with something else (namely MD5||SHA1) would also be 
> explicitly recommended against in existing specifications, and explicitly 
> prohibited in all new drafts (even if unlikely).
>
> Also, when I say "prohibited" here, I mean _completely_. No MD5 function 
> should remain in the relevant codebase; if MD5||SHA1 support is continued, 
> there should be one function that does only that without any way to get a 
> plain MD5 hash. (and no "it's fine for this" junk; non-broken hashes are also 
> fine for that, and if you're wrong, it's safer) There are too many 
> implementation bugs in this realm to not state this explicitly [0].
>

I completely agree. At least one open source SSL/TLS implementation is
looking at purging their code of MD5 functions.


> Note that continued support of trust anchors with MD5 hashes is not dependent 
> on this, as we've already agreed they don't need to be validated. (they need 
> to be phased out, but with less urgency) If used within this specific 
> context, nothing even needs the ability to understand MD5 hashes at all in 
> order to handle these; the certificate as a whole is trusted or not.
>
>
> Dave
>
>
> PS
> To whomever came up with the "diediedie" term, thank you. ;)
>
>
> [0] Note the 3 disabled-but-accepted bugs listed here:
> https://www.mitls.org/pages/attacks/SLOTH#disclosure
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Dave Garrett]

On Tuesday, January 12, 2016 12:32:08 am Viktor Dukhovni wrote:
> > Also, when I say "prohibited" here, I mean _completely_.
> 
> There is no Internet police, and the IETF does not get to prohibit
> the use of MD5, we only get to write protocol standards.

Of course, but the IETF can state that MD5 is not considered secure, must not 
be used in any of its old specifications (I do agree that a short list of 
exceptions will be needed), and put forth a set of basic requirements to 
continue to use IETF specifications with any intent of considering them even 
slightly secure. The IETF can't directly enforce this, but plenty of 
organizations do take this sort of thing seriously, even if others ignore it 
completely. I would hope that lawyers that wish to reduce their companies' 
liability for ever-frequent data breaches might pay attention when a primary 
standards body officially disavows things they're still using as insecure.

> > No MD5 function should remain in the relevant codebase;
> 
> In particular the IETF does not get to tell anyone which functions
> they get to include in their codebase.  So no IETF document saying
> such a thing makes much difference.

It's not a list of demands; it's basic specifications maintenance. It's just a 
matter of stating what's necessary to avoid well-known security problems when 
using IETF specs. We know it's a problem and should say so, loudly, on the 
standards track, as we are well aware that obsolete standards are still in 
regular use and are dangerous unless their implementations are properly 
handling all issues discovered since initial release.

I am of course aware that the IETF doesn't like to wade into implementation 
issues in this kind of detail, but just blaming implementations for screw ups 
isn't an answer. We should be reliably telling implementors what's needed to 
avoid them.

The disabled-but-accepted nonsense is a common enough high-risk issue that 
comes up way too often, and not prominently specifying how to deal with it is 
irresponsible. An argument could be made for coding/API safety issues like this 
being in a separate BCP RFC, especially if we actually wanted to cover other 
things like this, but that's a much larger proposal than what I'm currently 
talking about.

> > if MD5||SHA1 support is continued,
> > there should be one function that does only that without any way to get
> > a plain MD5 hash.
> 
> This turns out to be a good idea anyway, thus, for example, OpenSSL
> 1.1.0-apha2 just recently added an EVP_md5_sha1() hash function.

Ah, good to hear. Thanks for the info.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls