Re: [Cfrg] NSA sabotaging crypto standards

["Blumenthal, Uri - 0558 - MITLL" <[e-mail]>]

1. Yes, those objections were informed - and based on the best data we *all* had *back then*. (I personally discussed it with Don Johnson, and Don Coppersmith, which was easy as we worked in the same building. There is *a lot* to say on the subject, but it does not matter now.)
This is the blessing of and the problem with the hindsight. We did Encrypt-then-MAC mostly for performance reasons, and hoped there were no unforeseen negative security implications. A decade later it turned out that our approach was preferable from security point of view, and now (2+ decades later) people are criticized for not embracing our method... But for sure I can't call my colleagues of that time "mistaken".

Who knows what we'll learn in the next ten years?

2. "Blunder" is a strong word. I cannot call what happened in those WG a "blunder" (much unlike the [in]famous WEP).

What should be done? A good question. Theoretically, impacted standards and implementations should be re-done to address the problems we know about now. Practically, considering the inertia of the industry and the leg irons of backwards compatibility? With the money considerations (cost of the changes vs expected revenue from them) thrown in this mix?  Off-hand, I don't know.

On one hand, IETF needs a (better) ability to deprecate algorithms and protocols (as Dave McGrew just said). On the other hand, there is no enforcement arm, and if (for the sake of the argument) Microsoft decides to keep a deprecated protocol alive, you and I can criticize it all we want, but it won't take it off the 90% of the world's desktops and who knows what percentage of the servers that must communicate with those desktops. 

3. Regarding the new protocols? It should be simpler, as they rarely carry the burden of compatibility with something we may or may not like. IETF is trying to steer things away from bad by making statements like "No new protocol shall use MD5" (back then, or SHA-1, in later days). 

IMHO, one way to improve things is getting out IESG statements like "Construct X was shown to be vulnerable to A, B, and C - and must not be used in any new protocol", and "Construct Y was shown to be strong/good for D, E, and F - and new protocols doing those should employ Y"... Security AD  would be a reasonable source of such statements. It is up to the individual members to create, analyze/debug/vet such statements, and submit them for AD's consideration. If such a statement were coming from CFRG rather than a single individual, it would be even better.

Describing attacks against proposed protocols, together with recommended fixes, would also help. The more practical and specific the attacks are - the likelier it is that the WG would listen (and vs versa). Availability and usability of the fixes is a factor too...

One caveat: security proofs is a tricky field. I remember having fun reading proofs and "dis-proofs" on MQV/HMQV/FHMQV. It is far from, e.g., proofs in geometry or algebra that we're so used to rely upon. :-). So I personally tale security proofs with a good grain of salt, and try to look at the assumptions much more closely than at the actual proofs.

Also, implementers positively hate designs/protocols encumbered by IPR. They would much rather take a chance of a weird attack than of a potential litigation. If a good protocol is patented - it won't be touched with a 10-foot pole (e.g., think EKE), no matter how great security proofs or performance advantages it has. 

GPL license is great (when available :), but it doesn't cover all the needs of the industry...

I better stop here before I lose too much of coherence. :-)

Would be happy to answer specific questions, or discuss specific steps.

TNX!
--
Regards,
Uri Blumenthal                            Voice: [phone]
Cyber Systems and Technology   Fax:   [phone]
MIT Lincoln Laboratory                Cell:  [phone]
244 Wood Street                        Email: <[e-mail]>
Lexington, MA  02420-9185       

Web:  http://www.ll.mit.edu/CST/

 

MIT LL Root CA: 

 <https://www.ll.mit.edu/labcertificateauthority.html>


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Watson Ladd [mailto:[e-mail]]
Sent: Friday, February 07, 2014 12:10 PM
To: Blumenthal, Uri - 0558 - MITLL
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Cfrg] NSA sabotaging crypto standards

On Fri, Feb 7, 2014 at 8:39 AM, Blumenthal, Uri - 0558 - MITLL
<[e-mail]> wrote:
> Don Johnson, for one. Carl Meyer. (Yes, those guys who invented Lucifer and DES ciphers.)
>
> You keep forgetting (or simply aren't old enough to be aware?) of how things were done back when the "Cryptography: The New Dimension" book was published.
>
> The standard was "MAC, then Encrypt", and it had reasons for doing things in that order. In fact, SNMP was the first IETF protocol (circa 1992-1994) to diverge from that approach, and it took some flak for not doing what was the conventional wisdom of that day.

Was that flack informed? Or was it coming from people who didn't
really understand the mathematics behind crypto? Were those reasons
informed? Just because everyone was making the same mistakes doesn't
make those mistakes less serious. Even if we make Bellare-Nampare the
point at which no one should have done MAC then Encrypt, that was 13
years ago. Bard explained BEAST 9 years before the demonstration.

The best you can say is that the TLS WG was woefully slow in
responding to the changing situation.

>
> Since then the priorities and the attacks changed, and now "Encrypt-then-MAC" is the standard.
>
> Watson, I'd like to join other suggesting that you become less combative here. I'm not a "peacenik" myself, but any patience has a limit.

What should the CFRG and the IETF do more broadly to ensure that
blunders as serious as the ones above don't happen again? What has the
CFRG done to ensure that other 90's era protocols have these problems
addressed, particularly when the WGs responsible have disbanded?
Should we simply let sleeping dogs lie, and work on ensuring that new
protocols don't make similar mistakes?
I'm here to fix the problems: explain what I need to do to fix them,
and I'll do it.

Sincerely,
Watson
>
> --
> Regards,
> Uri Blumenthal                            Voice: [phone]
> Cyber Systems and Technology   Fax:   [phone]
> MIT Lincoln Laboratory                Cell:  [phone]
> 244 Wood Street                        Email: <[e-mail]>
> Lexington, MA  02420-9185
>
> Web:  http://www.ll.mit.edu/CST/
>
>
>
> MIT LL Root CA:
>
>  <https://www.ll.mit.edu/labcertificateauthority.html>
>
>
> DSN:   478-5980 ask Lincoln ext.1638
>
> ----- Original Message -----
> From: Watson Ladd [mailto:[e-mail]]
> Sent: Friday, February 07, 2014 11:28 AM
> To: Nikos Mavrogiannopoulos <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Subject: Re: [Cfrg] NSA sabotaging crypto standards
>
> On Fri, Feb 7, 2014 at 8:11 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> On 02/07/2014 04:59 PM, Watson Ladd wrote:
>>
>>> But let's go into detail about how well the cryptographers did in TLS.
>>> In 1995 Phil Rogaway tells everyone to use encrypt-then-MAC.
>>
>> I believe you are oversimplifying things. Indeed Rogaway suggested
>> encrypt-then-MAC, but other cryptographers were suggesting
>> MAC-then-Encrypt (authenticate what is meant not what is sent). There
>> was also no attack known for MAC-then-encrypt.
>
> Show me one cryptographer who recommended MAC-then-Encrypt.
> Also, absence of known attacks is not the same as absence of attacks.
> Encrypt-then-MAC was the conservative choice.
>
>>
>> In general it is very easy to see the obvious solution 20 years later,
>> but the challenge is to properly decide at the right time.
>
> It was obvious then: encrypt-then-MAC was known secure, while
> MAC-then-encrypt was not.
> Any excuse vanishes with Bellare-Nampare (2000). Of course, even if we
> take the best interpretation, the TLS WG frittered away 9 years after
> being informed of an attack.
>
> Sincerely,
> Watson Ladd
>>
>> regards,
>> Nikos
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin