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

[Rene Struik <[e-mail]>]

To me, this seems to be an entirely new perspective on what it means to be an engineer or scientist :(((.

==
So, why would you care when things are going fine anyway?

On 2/12/2014 12:11 PM, Hannes Tschofenig wrote:
> Hi Rene,
>
> my impression was that until recently many IETF participants just
> trusted NIST to do the right thing. So, why would you care when things
> are going fine anyway?
>
> During the last few months that impression might have changed a bit and
> there might be more energy to improve transparency and to explore new
> directions.
>
> Ciao
> Hannes
>
> On 02/10/2014 08:05 PM, Rene Struik wrote:
>> 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]