[Cfrg] how can CFRG improve cryptography in the Internet?

[David McGrew <[e-mail]>]

Hi All,

it is healthy to have a discussion on what CFRG and IETF can do 
differently to improve security and privacy in the Internet.

Ultimately, we are not limited by the current CFRG charter, but rather 
by our collective willingness to do the work that needs to be done, and 
I suppose on our ability to develop enough rough consensus about what 
needs to be done.   We do have a charter that we need to stick to at 
present, but we can do more within that charter, and we can consider 
changes to the charter if we think those are needed.   (Though note that 
we would need to get those changes approved.)

An approach that might work for us is to develop replacement mechanisms 
for the ones in current use that we think need to be replaced, keeping 
in mind that the actual replacement might take ten years or so, or might 
never happen.   At the same time, we can document the problems with 
existing mechanisms, to help provide a motivation for that replacement.

It is worthwhile to keep in mind the interoperability problems that can 
be caused by changes in cryptography, and the inertia created by all of 
those millions of crypto implementations that are currently in use.   We 
can't expect new crypto to appear in a five year old piece of software 
that is no longer supported by its creator, for instance, and that will 
slow down adoption of newer crypto, no matter how much better it is.   
As a practical matter, we also need to realize that many users of 
cryptography believe that there is no economic justification for 
deploying new crypto until breaking the old crypto scheme is so easy 
that a script kiddie can do it with a backtrack CD-ROM.   The burden is 
on us to provide this justification.

At the same time, I share the frustration that too much bad cryptography 
is in use, which should have been replaced long ago. The fact that it 
might take years to replace is no excuse not to start the process now.   
I'm thinking of RADIUS and other protocols that are used with 
human-generated passwords (and are not PAKE systems) in particular.   It 
would be *great* to have CFRG document what protocols are bad, and how 
bad they are, in a way that we could demonstrate expert consensus on our 
opinions. If we did a decent job, I bet we could get a slot in front of 
the IESG or some other responsible IETF group.   I am confident that, if 
we can offer IETF good information about the security of current 
standards, they will find a way to propagate and use that information.

An aside: a history of crypto protocols at IETF might provide some 
useful perspective; maybe a couple of people who were involved would be 
willing to write up something?    It might be useful to focus on one 
case study where things were done wrong, and one where things were done 
right.

David

On 02/07/2014 12:10 PM, Watson Ladd wrote:
> 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
>
>