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

[Rene Struik <[e-mail]>]

Hi Hannes:

Historically, not that many CFRG/IETF people seem to have participated 
in solicitations for public review of NIST draft publications. I wonder, 
therefore, what makes you feel this would change dramatically, should 
CFRG/IETF take on an effort as complement or partially duplicated effort 
of what NIST has already done.

Note - data suggests this has been pretty consistent over time, both for 
the last solicited draft crypto recommendation review and for those in 
the last few years.

Best regards, Rene

==
[excerpt of email Hannes Tschofenig, February 7,2014, 4:37pm EST]

b) I do, however, believe that the CFRG could play an interesting role.
I am curious whether it would be possible to move some of the tasks that
are currently done in NIST to the IRTF, namely the cryptographic
algorithm selections. I know that this is a job that is today not done
by the IETF/IRTF but I believe it could be done since the ingredients are:
* open and transparent process for publishing, commenting, and selecting
an algorithm
* a suitable way for publishing these documents.

On 2/10/2014 2:18 PM, David McGrew wrote:
> HI Hannes,
>
> On 02/07/2014 04:37 PM, Hannes Tschofenig wrote:
>> Hi David,
>>
>> good discussion points.
>>
>> Here are my views:
>>
>> a) If we look at the problems at the entire Internet software lifecycle,
>> as I did in
>> http://tools.ietf.org/html/draft-tschofenig-perpass-surveillance-01,
>> then I believe it is fair to say that the problems at the level of
>> cryptographic primitives are the least challenging issues with Internet
>> security. That's good news.
>
> thanks for chiming in, I think you are right regarding primitives; let 
> me note that weak protocols and insecure deployment practices are 
> perfectly in scope for CFRG  as well as primitives.   But the other 
> major category of weakness, widespread exploitable vulnerabilities in 
> software implementations, is one that is hugely important, and which 
> is out of scope for CFRG.   The problem of exploitable vulnerabilities 
> doesn't get the air-time that it deserves, relative to the other 
> issues.   An exploit could force its victim to do all sorts of bad 
> cryptographic practices, such as leak a key in an IV, or use a fixed 
> or low-entropy key.
>
>>
>> The problems you mentioned with RADIUS have little to do with work that
>> would be done in the CFRG. RADIUS, similarly to Diameter, does not offer
>> end-to-end security and that's something that could be fixed in the IETF
>> (and there is work ongoing in the DIME working group for Diameter at
>> least). The main challenge, however, is the attitude problem of those
>> deploying the protocol.
>
> I agree about the attitude, but I don't agree that CFRG couldn't 
> help.    Surely we don't need new crypto mechanisms to solve the 
> problems with RADIUS, but analyzing and documenting security issues 
> and helping to socialize them with the IETF and the user base are all 
> in charter and are worth doing.
>
>>
>> b) I do, however, believe that the CFRG could play an interesting role.
>> I am curious whether it would be possible to move some of the tasks that
>> are currently done in NIST to the IRTF, namely the cryptographic
>> algorithm selections. I know that this is a job that is today not done
>> by the IETF/IRTF but I believe it could be done since the ingredients 
>> are:
>> * open and transparent process for publishing, commenting, and selecting
>> an algorithm
>> * a suitable way for publishing these documents.
>>
>> Doing this work in a global standards organization also gives it more
>> credibility. I am also confident that the IETF/IRTF community could
>> reach out to researchers working on hash algorithms, encryption
>> algorithms, etc.
>>
>> Just a thought...
>
> Agree that IETF is and should be willing to act as an international 
> standards body for crypto, and that CFRG could support that process.   
> We need to be careful not to over-commit in this area, but if the IETF 
> wanted CFRG to vet some crypto standards options, we should be able to 
> do that.
>
> David
>
>>
>> Ciao
>> Hannes
>>
>>
>> On 02/07/2014 07:04 PM, David McGrew wrote:
>>> 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
>>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]