Re: [TLS] draft on new TLS key exchange

[Yoav Nir <[e-mail]>]

On Oct 6, 2011, at 4:17 AM, Dan Harkins wrote:

> 
> On Wed, October 5, 2011 6:49 pm, Peter Gutmann wrote:
>> "Dan Harkins" <[e-mail]> writes:
>> 
>>> TLS-PSK: resistance to dictionary attack
>>> TLS-SRP: elliptic curve support, divorcing domain parameter set from
>>>    the password
>> 
>> So it's a proposal that adds a few obscure geeky features to two existing
>> mechanisms that vendors have already decided not to adopt (wrongly, in my
>> opinion, but that doesn't change the lack of adoption).  Why would they
>> suddenly rush to support this one if they've ignored the other two (and a
>> string of earlier drafts along the same lines)?
> 
>  This came out of some discussions around security for "smart energy"
> applications whose specifications do much hand waving and assume that
> certificates magically appear on the most unlikely of places and are
> all used properly. They also make it highly problematic for any
> off-the-shelf device that is supposed to be integrated into a network
> of other "smart energy" devices from working properly. They assume an
> unrealistic level of security clue on the people installing and
> provisioning the device. Having Joe Random enter a simple password on
> the UI of his thermostat, for instance, is much more believable.

Joe Random will throw out a thermostat that regularly requires entering a password. The use case is more likely entering the password once at installation, and then that password is one chosen by the utility. For the last 17 years, Microsoft has trained us all to enter 30-digit numbers. Once. In that use case the passwords can be (relatively) high entropy, and then TLS-PSK is acceptable. I am far more interested in using a password method for TLS for authenticating to web sites.

>>> I'm curious why you are not asking the authors of the SEED, Camellia, and
>>> Clefia drafts what those drafts give us that the AES ciphersuites don't
>>> already do.

Oh, they get a lot of grief every time they come up with "XXXX and its use in IPSec/TLS/SSH". They always get that question, and they say something about it being a standard of some national government. Sometimes the documents end up as proposed standards (SEED, Camelia), and other times they end up as Informational (GOST).

Protocol changes get a lot more scrutiny than algorithms, probably because many more of us think we are qualified to have informed opinions about protocols than about algorithms. And protocol changes are far less likely to be published. 

>> 
>> Those three are fashion-statement RFCs whose reasons for existence have
>> little
>> (if anything) to do with security.  Does that mean this draft is also a
>> fashion statement?
> 
>  No, it's not a fashion statement. I just don't like following a whole
> bunch of other people only to have the door slammed in my face. It
> does not jibe with my notion of fairness.

Peter and I have been trying to push draft-nir-tls-eap for over 4 years now, and the TLS WG is not biting. You are following a bunch of people who have already had the door slammed in their faces.

Yoav