Subject: Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik

From: Simon Josefsson <[email-masked]>
Date: Mon, 01 Feb 2016 14:09:00 +0100

I believe that publishing the document below would conflict with ongoing
work in the IETF to provide secure block ciphers that we can use on the
Internet.  It is not in the best interest of the IETF nor the Internet
at large to publish RFCs of national ciphers if there is no immediate
desire to use them in Internet protocols.

/Simon

Alexey Melnikov <[email-masked]> writes:

> Dear CFRG participants,
>
> On February 4th the IESG will be doing the conflict review for a draft
> [1] that describes GOST R 34.12-2015: Block Cipher
> "Kuznyechik". Stephen Farrell is handling this document on behalf of
> IESG. Stephen asked for feedback from CFRG.
>
> Since national algorithms are typically documented as independent
> submission stream RFCs, I think this one does not represent a conflict
> with ongoing IETF work or process. If you disagree, please let Stephen
> and CFRG chairs know.
>
> Should someone want code points for using this algorithm in IETF
> protocols, that would of course go through the normal IETF consensus
> process. See RFC 5742 [2] for details of what this bit of process is
> about.
>
> If you have comments on the draft content then please send those to
> the authors and cc the independent submissions editor, Nevil Brownlee
> ([email-masked]).
>
> Best Regards,
> Alexey, on behalf of CFRG chairs.
>
> [1] https://datatracker.ietf.org/doc/draft-dolmatov-kuznyechik/
> [2] https://tools.ietf.org/html/rfc5742
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 1 Feb 2016 13:24:39 +0000

> Internet.  It is not in the best interest of the IETF nor the Internet at large to
> publish RFCs of national ciphers if there is no immediate desire to use them
> in Internet protocols.

As someone who's written more "let's document this so we can use it in the IETF" RFC's than anyone else, let me ask you a question.  Is it better to have it already written, available to use if needed, or better to scramble and get something written just as the need arises?

---

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Feb 2016 15:54:53 +0200

> On 1 Feb 2016, at 3:09 PM, Simon Josefsson <[email-masked]> wrote:
> 

Hi.

There definitely is a desire to use this cipher. True, all potential users come from the same country, but that should not be blocking.

As a vendor, we often get a request to provide an IPsec and/or TLS implementation with GOST ciphers, and this is the new GOST cipher.

OTOH there is no RFC describing AES either. We usually point to a NIST document. Similarly, there are GOST documents describing kuznyechik. They are even referenced by the draft. So I’m not sure what this draft is supposed to accomplish. Is it merely an English translation? Regardless, this is an algorithm that is going to be used on the Internet and documenting it is a good thing. I don’t see how this interferes with our goal or providing secure block and streamish ciphers.

Yoav

---

From: Василий Долматов <[email-masked]>
Date: Mon, 1 Feb 2016 17:29:35 +0300

> 1 февр. 2016 г., в 16:54, Yoav Nir <[email-masked]> написал(а):
> 
> 
> OTOH there is no RFC describing AES either. We usually point to a NIST document.
Which is the document of the _National_ Institute of Standards. ;)

> Similarly, there are GOST documents describing kuznyechik. They are even referenced by the draft. So I’m not sure what this draft is supposed to accomplish. Is it merely an English translation?
Yes.
There were (and is) a noticeable demand of English texts of GOST standards in order to make their review and analysis easier.

Though it is not an _official_ translation, but it was thoroughly reviewed be several different groups of specialists to ensure its relevance and quality.

> Regardless, this is an algorithm that is going to be used on the Internet and documenting it is a good thing.
Agree.

> I don’t see how this interferes with our goal or providing secure block and streamish ciphers.
Neither do I.

dol@

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 01 Feb 2016 15:45:57 +0100

"Salz, Rich" <[email-masked]> writes:

> As someone who's written more "let's document this so we can use it in
> the IETF" RFC's than anyone else, let me ask you a question.  Is it
> better to have it already written, available to use if needed, or
> better to scramble and get something written just as the need arises?

I believe you have to make a risk assessment.

In this case, I believe the risk that people implements and use this
without understanding the consequences is far far greater than the minor
advantage that there is an RFC available for citation in case a need
arise.

Remember that the text IS already written.  It is ready as a draft if we
ever decide that GOST is the cipher we want to run on the Internet.

Also consider that AES isn't an RFC: the disadvantage of that does not
seem to be stopping us from using it.

To me, publishing this is distracting and steals momentum from other
work the IETF is doing.

/Simon

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 1 Feb 2016 18:37:00 +0300

Hi Simon,

> advantage that there is an RFC available for citation in case a need

I don't think we'll see a "GOST rush" among implementers if this RFC is published.
But as Yoav has pointed out there are groups of people who do want
to use this cipher.

> ever decide that GOST is the cipher we want to run on the Internet.

Some people do want to use it today.

> seem to be stopping us from using it.

Situation with AES is different - it is documented in English.
Camellia is a better example - and it was published (RFC 3713).
Do you think that many people have implemented it since then
without understanding the consequences?

> To me, publishing this is distracting and steals momentum from other

I don't think so.

> /Simon

Regards,
Valery Smyslov.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 1 Feb 2016 16:21:57 +0000

On 2/1/16, 10:37 , "Cfrg on behalf of Valery Smyslov"
<[email-masked] on behalf of [email-masked]> wrote:

>>>> Internet.

1. That sounds like uber-over-dramatization.
2. Contrary to what some might believe, IETF does NOT provide block
ciphers, secure or otherwise.

>>I believe you have to make a risk assessment.

Now “risk”? Oh my.

>...

It is a valid option.

Neither do I.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 01 Feb 2016 17:27:20 +0100

> without understanding the consequences?

Yes.  I think Camellia is a good example here.  I recall seeing
implementations that preferred Camellia over AES when both were
available, which I suspect was due to misunderstanding or mistake.  The
document can inform the reader about some aspects, but sometimes having
too much rope available causes bad things to happen.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 1 Feb 2016 16:33:44 +0000

Hi Simon,

On the higher level, I agree with those who think this is
not a 5742 conflict, but I'll point the rest of the IESG
at this thread so they can read about it themselves.

> too much rope available causes bad things to happen.

I agree that that happened and was undesirable, but I think
that the mistake then was in the TLS code point allocation.
We (the IETF) should've made sure that the registry or the
specification that created the code points clarified things
for implementers. With TLS1.3, I think the TLS WG have
decided to structure the IANA registries so this'll end up
better. I forget if that'd also mean re-structuring the
registries for earlier TLS versions or not, but in any case
the issue is one for the TLS WG (or IPSECME or whoever) and
not something that the ISE ought handle in the basic spec
describing the algorithm details.

Cheers,
S.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 1 Feb 2016 16:36:02 +0000

On 2/1/16, 11:27 , "Cfrg on behalf of Simon Josefsson"
<[email-masked] on behalf of [email-masked]> wrote:

>I recall seeing implementations that preferred Camellia over AES when
>both were
>available, which I suspect was due to misunderstanding or mistake.

Can you imagine an organization or a business that is bound by a policy
requiring use of a certain cipher in preference over other ciphers?

And I’m not talking about paranoids, for who the mere fact that NSA is OK
with AES implies that there’s something wrong with it. :-)

---

From: Watson Ladd <[email-masked]>
Date: Mon, 1 Feb 2016 08:48:52 -0800

> with AES implies that there’s something wrong with it. :-)

But why else does Kuznyechik exist? It still has the same S-box lookup
problems as AES, is yet another S-P network, efficiency doesn't seem
to be significantly better, etc. The whole "bound by policy" argument
is really a different word for "I don't wanna, and I call it policy".

The cost for protocols to support *any* options is extreme. Until
recently no one had studied secure options negotiation, and
unsurprisingly it's often wrong.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 2 Feb 2016 12:40:40 +0300

Dear Stephen,

> describing the algorithm details.

I am not sure that it's a good idea to avoid code point allocation.
As nation-wide regulation requires using nation-specific algorithms,
there will appear specifications for using these algorithms with TLS etc.

The best solution I can imagine for the real world is allocating code
points
for nation-wide algorithms together with providing comments for the
implementers,
that the corresponding algorithm/ciphersuite/etc is nation-specific and not
mandatory.

-- 
SY, Dmitry Belyavsky

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Feb 2016 09:59:26 +0000

Hiya,

> I am not sure that it's a good idea to avoid code point allocation.

I did not make any argument to avoid codepoint allocations for
national or vanity algorithms. (To be honest, I would personally
prefer that, but it's not achievable, so I don't argue for it.)

I reported that the TLS WG have agreed to clarify which code points
correspond to algorithms that the IETF prefer/recommend and which
do not. National and vanity algorithms will be part (but not all) of the
latter set, except where a national algorithm (like AES) is broadly
accepted as being desirable. Perhaps some day a GOST algorithm will be
in the former set, but for now I don't think any are.

> As nation-wide regulation requires using nation-specific algorithms,

Yes. Those are IMO a bad idea, but a sad reality that we do need
to handle. (To provide just one reason why they are a bad idea,
many more devices and people now are mobile and do cross national
borders, assuming such details of their Internet connectivity can
be "national" seems to me to not recognise reality.)

> that the corresponding algorithm/ciphersuite/etc is nation-specific and not

Yes, that is part of what I think the TLS WG have agreed. The tricky
part IMO is to get the pejorative terms correct:-) Note though that
some algorithms might be outside the preferred set because they are
considered a backup or hedge against analysis, e.g. perhaps TLS
codepoints for curve448 will be handled that way. So not everything
outside the preferred set will be national/vanity/undesirable.

Anyway if you are interested in that, the TLS WG mailing list is the
right venue for discussion of TLS registration schemes and codepoints.
If you want to discuss the topic of national algorithms in the IETF
independent of a particular protocol, then the saag list is the right
venue.

Cheers,
S.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 Feb 2016 11:52:14 +0100

> at this thread so they can read about it themselves.

Hi Stephen, IESG (bcc'd),

If you and others disagree on there being a conflict (something I would
consider being on the wrong side of of balance between practalities and
security), please consider below a suggestion to add text to the
document to somewhat mitigate the consequences of that decision.

> that the mistake then was in the TLS code point allocation.

I don't believe that is the only reason  People use RFCs outside of IETF
protocol context too.  I recall seeing Camellia used in non-IETF
protocols too, with unclear rationale.

> describing the algorithm details.

I believe a discussion of IETF's thoughts on the suitability of a crypto
algorithm ought to be in the crypto specification itself when there are
concerns about the Internet-wide applicability of the algorithm.  This
is for the following reasons:

1) The IETF ought to recognize the best interest and safety of Internet
users as a collective.  I encourage you all to re-read the IETF's
mission statement and consider again whether publishing GOST, with or
without sufficient security considerations, are consistent with that.
https://ietf.org/about/mission.html

2) People use RFCs for non-IETF purposes, especially crypto algorithms.
Consider the number of places HMAC-SHA1 or PBKDF#2 are used.

3) The IETF does not distinguish between different crypto algorithms it
publishes -- they are all informational -- so it is not easy to
understand that Camellia is not a generally recommended cipher these
days.  Especially since there is no RFC on AES which is what I believe
we historically have been encouraging.  Having a discussion in the
document itself is probably the only place the IETF can inform the
reader about what it believes the intended use for the algorithm is.

Thus I suggest that the IESG 1) consider whether they believe publishing
this is consistent with the goal's of the IETF (I believe it conflicts
with the IETF's mission), and 2) propose to add text to the document
explaining that the IETF does not encourage nor recommend the algorithm
for general purpose Internet-wide use.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Feb 2016 11:14:45 +0000

Hi Simon,

On 02/02/16 10:52, Simon Josefsson wrote:
> with the IETF's mission), 

There are arguments for and against, none of which are specific to
this conflict review so if you want to discuss this, maybe the saag
list is a better option. You're proposing a change in how the IETF
operates, so that would need discussion on an IETF list.

> and 2) propose to add text to the document

That can vary by wg. Kerberos folk for example seem friendlier to
Camellia than TLS or IPsec. AFAIK, we do not have an IETF-wide
consensus on a preferred set of algorithms/modes/etc that covers
all protocols. I think it'd be great if we did, but we don't.
Again, if you want to try establish that consensus, feel free to
start the discussion on the saag list.

Cheers,
S.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 2 Feb 2016 11:16:39 +0000

Hi,

Not strictly relevant for this conflict review, but since we're discussing
it anyway...

Is anyone on the CFRG list aware of any cryptanalysis of the block cipher
Kuznyechik? 

I realise it's a relatively new algorithm, although it seems to be a
development of previous ciphers from the same stable, but my search engine
of choice only turned up a couple of references.

So what's the state-of-the-art here?

Cheers

Kenny 

On 30/01/2016 20:39, "Alexey Melnikov" <[email-masked]> wrote:

>[1] that describes GOST R 34.12-2015: Block Cipher "Kuznyechik". Stephen
> Farrell is handling this document on behalf of IESG. Stephen asked for
>feedback from CFRG.
>
>If you have comments on the draft content then please send those to the
>authors and cc the independent submissions editor, Nevil Brownlee

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 2 Feb 2016 14:20:45 +0300

Dear Kenny,

> So what's the state-of-the-art here?

The only reference I know is here:
http://cvo-lab.blogspot.fr/2015/01/the-new-gost-standard-from-russian.html

But I hope that there are some more researches.

-- 
SY, Dmitry Belyavsky

---

From: Watson Ladd <[email-masked]>
Date: Tue, 2 Feb 2016 10:24:03 -0800

> But I hope that there are some more researches.

Why is there no design document comparable to that for Rijndael? Of course
it's possible to write such a document by computing all differentials, the
minimum distance of the linear layer, etc, but it seems strange that this
doesn't exist.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Feb 2016 18:27:57 +0000

Why is there no design document comparable to that for Rijndael?

Perhaps because it wasn't trying to win a global contest for a new crypto standard?

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 2 Feb 2016 18:37:41 +0000

On 2/2/16, 13:27 , "Cfrg on behalf of Salz, Rich" <[email-masked]

>Perhaps because it wasn't trying to win a global contest for a new crypto

A good point - but if I recall correctly, Russia held some kind of
internal competition. There were several candidates, and this one was
selected, somehow. In short, they did try to win some kind of a contest
(unless I’m badly mistaken).

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 2 Feb 2016 19:08:36 +0000

>> > http://cvo-lab.blogspot.fr/2015/01/the-new-gost-standard-from-russian.html

This is better than nothing, but not by much. ;)

These two works (a paper and a presentation) might be of interest:
https://eprint.iacr.org/2015/812.pdf
http://crypto.2015.rump.cr.yp.to/1ea2c6c01144e0e7f6b14b324c5e4562.pdf

> minimum distance of the linear layer, etc, but it seems strange that this

:-)

Still, I think the RFC describing it should be published, to provide
interoperability reference within the IETF protocols for those who need that
algorithm.
Likewise, I’d expect an informational RFC describing Kalyna (Ukrainian
contest winner), which looks somewhat more appealing.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 Feb 2016 21:44:34 +0100

> contest winner), which looks somewhat more appealing.

I see a problem with publishing descriptions of national ciphers without
guidance on suitable use and relevant applicability statements.

/Simon

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Feb 2016 20:46:29 +0000

> guidance on suitable use and relevant applicability statements.

Strongly agree.  That way lies madness.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 2 Feb 2016 21:59:32 +0000

>guidance on suitable use and relevant applicability statements.

The only guidance I see is: if you need "it" or are required to use "it" -
do so, but be aware that people outside of your policy domain may not
interoperate with you using “it” because they may not have “it”
implemented. Implementing “it” is not required to be <whatever
protocol>-compliant.

Do you envision some other kind of guidance?

P.S. I wouldn’t expect US government to use anything but AES, and I
wouldn’t expect Ukrainian government to use anything but Kalyna. As for US
businesses communicating to Ukrainian businesses - off-hand it’s a toss
security-wise, either one would do.

P.P.S. Quality-wise - on the first look Kalyna looks better than AES,
while Kuznechik doesn’t.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Feb 2016 11:23:00 +0100

> implemented. Implementing “it” is not required to be <whatever

Where do you see this guidance?  I can't find anything like that in the
draft.  In fact the draft talks about itself as a Standard in several
places:

   The cryptographic algorithms specified in this Standard are designed
   both for hardware and software implementation.  They comply with
   modern cryptographic requirements, and put no restrictions on the
   confidentiality level of the protected information.

   The Standard applies to developing, operation, and modernization of
   the information systems of various purposes.

To me this suggests broad applicability.

I would expect to find a discussion on applicability in the Introduction
or in the Security Considerations.  For those who didn't read, the
security considerations is:

   6.  Security Considerations

   This entire document is about security considerations.

Which leaves a lot to desire.

> Do you envision some other kind of guidance?

Yes, see the last paragraph of:
https://www.ietf.org/mail-archive/web/cfrg/current/msg07876.html

/Simon

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 3 Feb 2016 16:09:58 +0000

On 2/3/16, 5:23 , "Simon Josefsson" <[email-masked]> wrote:

>draft.  

Ach… I meant “I see” like “I envision”, not like “it’s already in the
document”. :-(

>To me this suggests broad applicability.

Frankly, I don’t see why “it” (those other-than-AES algorithms) shouldn’t
be “broadly applicable”. AES is mandatory to implement to provide
interoperability. There’s nothing inherently holy about it. If two
communicating entities (which both must have AES support to be compliant)
happened to implement, e.g., Camellia, and want to communicate using it -
it’s not my business (and not your business) to tell them not to.

>or in the Security Considerations.

Introduction - yes.

Security Considerations??? That would apply if there were specific
weaknesses or vulnerabilities exposed by using the given algorithm - in
which case you want to inform the reader/implementor of what those are,
and how best to avoid/mitigate them. In the given case, for all we know
these ciphers are as good as AES. Unless you found (or have read about) an
attack and care to share it here..?

So AFAIS the only thing one can add there (and stay honest/unbiased) is
something like “this algorithm is relatively new, and enjoyed less
attention of the cryptographic community and academia than AES. Thus it is
likelier that a problem could be found in it, than in AES who has been
under scrutiny for the last 16 years."

>For those who didn't read, the security considerations is:
>

Hmm, yes. See above - would that make you happier? ;)

>https://www.ietf.org/mail-archive/web/cfrg/current/msg07876.html

No. Disagree with that email in general, and especially its last
paragraph. Will object against adding it.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 4 Feb 2016 09:18:41 -0800 (PST)

On Wed, February 3, 2016 8:09 am, Blumenthal, Uri - 0553 - MITLL wrote:
> Frankly, I don't see why "it" (those other-than-AES algorithms)
> shouldn't
> be "broadly applicable". AES is mandatory to implement to provide
> interoperability. There's nothing inherently holy about it. If two
> it's not my business (and not your business) to tell them not to.

  Amen! Agree. +1 and all that.

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 4 Feb 2016 11:00:15 -0800

>   Amen! Agree. +1 and all that.

Is that what actually happens? Or do administrators and programmers have no
clue about which primitives are secure, and assume that the protocols will
provide security no matter how configured? We can also add in the disaster
that is the usual API for using these standards, thanks to all the
complexity that implementations feel a need to offer.

We got very badly bitten by making experimental RFCs for MD5 and RC4.
Negotiation of options has only recently been analyzed and is still
something of a dark art, despite wide consensus ylthst it is necessary.

We probably shouldn't endorse NONE, and probably should seek out more
review of ciphers are are considering adopting, especially if it is an AES
lookalike.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Feb 2016 19:07:02 +0000

> We got very badly bitten by making experimental RFCs for MD5 and RC4.

Travel back in time to when this happened.  What alternatives where there?

We got good use out of those two mechanisms.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 Feb 2016 22:38:50 +0200

> On 4 Feb 2016, at 9:00 PM, Watson Ladd <[email-masked]> wrote:
> 
> 
> On Feb 4, 2016 9:18 AM, "Dan Harkins" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> > > On 2/3/16, 5:23 , "Simon Josefsson" <[email-masked] <mailto:[email-masked]>> wrote:
> > >
> Is that what actually happens? Or do administrators and programmers have no clue about which primitives are secure, and assume that the protocols will provide security no matter how configured? We can also add in the disaster that is the usual API for using these standards, thanks to all the complexity that implementations feel a need to offer.
> 
> 

That depends on the administrators and on the programmers. For example, and administrator in Russia whose systems transmit data that the law requires to be encrypted (financial, medical, personnel records, anything to do with strategic industries like oil, gas, and munitions) is going to follow the law and configure GOST-approved algorithms such as kuznyechik regardless of how she feels about the merits of Kuzneychik vs AES or ChaCha20. A programmer who maintains the TLS or IPsec or SSH implementation for such an administrator will include these algorithms in the product.  

Similarly an administrator for a hospital or HMO in the United States is bound by HIPAA to use best practices to protect the data, and although HIPAA does not prescribe specific algorithms, or even encryption at all, such an administrator is likely to configure NIST-approved algorithms and perhaps choose a product that has FIPS certification to avoid liability.

Other administrators might use whatever is the default in the library or product that they use. That leads programmers to optimize the defaults for maximum interoperability, which is why it’s taking so long to get rid of things like RC4 and MD5.

Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 4 Feb 2016 13:55:14 -0800 (PST)

On Thu, February 4, 2016 11:00 am, Watson Ladd wrote:
>> > happened to implement, e.g., Camellia, and want to communicate using
>> it
> -

  I'm sure you can find anecdotal evidence that runs the gamut of
experience and clue.

> something of a dark art, despite wide consensus ylthst it is necessary.

  As the author of RFC 2409 I know all about the problems with options.
You can negotiate the Tiger hash function in IKE. Why? No reason at all!
There are 2 kinds of authentication using public key encryption that
can be negotiated in IKE. Why? Long, ugly, story. Options... ugh.

> review of ciphers are are considering adopting, especially if it is an AES

  That's the thing, we're not "endorsing" anything. There is no imprimatur
of the IETF, or the CFRG, to this publication. As Uri noted, it is none
of our business if two people want to use a non-MTI cipher to communicate
to each other.

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 4 Feb 2016 14:25:11 -0800

> Travel back in time to when this happened.  What alternatives where there?

3DES and SHA-1.
> We got good use out of those two mechanisms.

Both were broken in the same year as their introduction: the initial byte
bias of RC4 was immediate, and collisions in the MD5 collision function not
long after.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Feb 2016 22:27:02 +0000

MD5 1991
SHA1 1993

---

From: Yoav Nir <[email-masked]>
Date: Fri, 5 Feb 2016 00:32:03 +0200

> On 5 Feb 2016, at 12:27 AM, Salz, Rich <[email-masked]> wrote:
> 
> MD5 1991
> SHA1 1993

Yes, but 3DES is from 1978 and SSL (as anything other than a Netscape-only feature) is from 1996, and IPsec is from even later, so those protocols could have been defined without known-weak algorithms.

And TLS 1.2 introducing MD5-based signatures in 2008 where previously there was only SHA-1 concatenated with MD5?  That’s just weird.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 4 Feb 2016 23:21:40 +0000

>> > We got good use out of those two [RC4 and MD5] mechanisms.
> 
> Both were broken in the same year as their introduction: the initial byte bias
> of RC4 was immediate, and collisions in the MD5 collision function not long
> after.

Pure and unadulterated BS. Accompanied by the usual charming manners, and
total disregard for practical realities of the industry.

First collision in MD5 was published in 2004: Collisions for Hash Functions
MD4, MD5, HAVAL-128 and RIPEMD <https://eprint.iacr.org/2004/199>  and Hot
to Break MD5 and Other Hash Functions
<http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf> .

Hans Dobbertin (OBM) published his work that suggested a possibility of
successful attack The Status of MD5 After a Recent Attack
<http://www.ietf.org/mail-archive/web/pkix/current/pdffqfUJq_6HW.pdf>  and
Cryptanalysis of MD5 Compress
<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uac
t=8&ved=0ahUKEwj34aLMnd_KAhUEfxoKHaREAMMQFggdMAA&url=http%3A%2F%2Fcseweb.ucs
d.edu%2F~bsy%2Fdobbertin.ps&usg=AFQjCNGnh9K0NTObOM61gXTdUI1lUvrxWg&sig2=27v7
NhRilr22zza9SWhfvg>  in 1996. He wrote in 1996 in RSA Laboratories
CryptoBytes (if you remember what it is):
> "The presented attack does not yet threaten practical applications of MD5, but
> it comes rather close… in the future MD5 should no longer be implemented …
> where a collision-resistant hash-function is required."

Of course everybody remembers that one of the HMAC claims-to-fame was that
it remains strong even if collisions are found in the underlying hash
function, which is how most protocols that employ hash for authentication
used it.

Not that I hope to convince anybody of anything, or to be heard by those who
probably would've benefited the most from it :), but it felt nice to go back
to those times for a moment.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 4 Feb 2016 17:56:43 -0800

> total disregard for practical realities of the industry.

Here's the September 1994 post revealing RC4:
http://web.archive.org/web/20080207125928/http://cypherpunks.venona.com/archive/1994/09/msg00304.html

By September 1995 Andrew Roos has posted the first distinguisher. He's
actually announced it a few months earlier, according to secondary
sources, but I couldn't find any direct link to the Usenet post. Below
shows that it's on what passed for an eprint server at the time. I'd
call that broken within the year.
https://groups.google.com/forum/#!searchin/sci.crypt/andrew$20roos/sci.crypt/xqwP-3NaTdM/4qn28owcFkoJ

Here's the September response from RSA inc.
https://groups.google.com/forum/#!searchin/sci.crypt/andrew$20roos/sci.crypt/5RXjlNthOFI/hkYx2XjAFQkJ

Was 3DES a viable alternative? Of course: it was the MTI cipher in
SSLv3 etc, where RC4 wasn't. Would this have cost more sparse CPU
time? Of course. But as CPU got cheaper, RC4 stayed enabled, even as
attacks mounted up. The practical reality of this industry is that
people don't change configuration and don't change defaults, that
programmers don't know how to write secure code, and everyone assumes
that the standards people are doing their job.

> MD4, MD5, HAVAL-128 and RIPEMD and Hot to Break MD5 and Other Hash
> Functions.
>
> successful attack The Status of MD5 After a Recent Attack and Cryptanalysis
> of MD5 Compress in 1996. He wrote in 1996 in RSA Laboratories CryptoBytes
> (if you remember what it is):
>
> "The presented attack does not yet threaten practical applications of MD5,
> but it comes rather close… in the future MD5 should no longer be implemented
> … where a collision-resistant hash-function is required."

So what should the response have been according to this very sentence?
Obviously it's to start planning to replace MD5, phase it out across
protocols, start removing it from products, not include it in new
protocols: that's what "no longer should be implemented" means.

Actual IETF response: keep using MD5, insist in 2004 that we can keep
using MD5  despite collisions(https://www.ietf.org/rfc/rfc4270.txt),
do nothing in 2007 in response to Marc Stevens, do nothing in 2008/9
in response to Sotirov, and only in 2011 start depreciating
MD5(https://www.rfc-editor.org/rfc/rfc6151.txt).

Why is this history relevant? Because it shows that if we adopt a
cryptosystem, it will continue to be used for a long time even as
increasingly successful attacks are found against it. Therefore we
should pay careful attention to the security of schemes we do pick.
That's coupled with the susceptibility of many protocols to downgrade
attacks: you are only as secure as the weakest enabled protocol, not
the strongest. Supposedly algorithm agility was supposed to fix this:
in reality it enabled all kinds of attacks while not solving what it
was supposed to solve.

> function, which is how most protocols that employ hash for authentication

This comment completely ignores the use of hash functions in
signatures and to verify integrity of files. That second usage is one
of the most enduring uses of MD5, and that first usage is one where
any collision is immediately fatal.