Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Apr 2015 14:37:20 +0000

Derek Atkins <[email-masked]> writes:
>Peter Gutmann <[email-masked]> writes:
>> ianG <[email-masked]> writes:
>>
>>>Again, these are envelope calculations, at the margin.  They aren't features.
>>>They literally only exist because *there is a choice*.  If there was no
>>>choice, I'm pretty sure that they'd figure it out...
>>
>> That's an interesting point, what's the tail and what's the dog?  Tell users
>> that they can choose, among other things, options like
>> TLS_DHE_RSA_WITH_CAMELLIA_3D_ROUNDED_CORNERS_RSS_PUSH_NOTIFICATION_AND_SPINNERS
>> and they'll discover they have an absolutely mission-critical requirement for
>> just that.  Tell them "TLS_DHE_RSA_WITH_AES_SHA256, like it or leave it" and
>> they'll say "yeah, that'll do".
>
>... except when it doesn't.  :)

Well it's going to have to do because they won't be given a choice.  Any suite
you like as long as it's TLS_DHE_RSA_WITH_AES_SHA256.

Ref: http://psycnet.apa.org/psycinfo/2000-16701-012

(http://faculty.washington.edu/jdb/345/345%20Articles/Iyengar%20%26%20Lepper%20(2000).pdf 
 for the non-paywalled version)

Peter.

---

From: ianG <[email-masked]>
Date: Wed, 15 Apr 2015 15:47:26 +0100

>> ... except when it doesn't.  :)

Yup.  At the margin, there will always be losers.

Case A.  If you choose TLS_DHE_RSA_WITH_AES_SHA256, there will be losers 
that can't do it.

Case B.  In the alternate, if you choose the current brain-destroying 
situation of httpd config files, there are all the losers who failed to 
get it going because it is so complicated, and all the losers who got it 
going but left a stupid suite in there because they didn't understand.

How to pick your losers?  Getting the most users with some security trumps.

>   for the non-paywalled version)

Priceless!  And we feel better and do better work with less choice!

iang

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Apr 2015 14:56:51 +0000

>Priceless!  And we feel better and do better work with less choice!

Yup.  Every time I go to dinner with Apple-enabled friends and we spend longer
on i-whatever-it-is choosing a film to watch than it takes to actually watch
the film, I think of that, and other work done by Iyengar on the psychology of
choice, and why less is more (or at least better).

(If you want a more accessible version, try "The Art of Choosing", same author).

Peter.

---

From: "Derek Atkins" <[email-masked]>
Date: Wed, 15 Apr 2015 11:20:09 -0400

> you like as long as it's TLS_DHE_RSA_WITH_AES_SHA256.

Okay, so you have effectively written off IoT.  If that is the answer then
I'm sure another solution will be created to handle them.  Personally I'd
prefer a TLS that enables IoT support instead of requiring IoT to be
completely incompatible.

For example, I can't use GCM, nor can I use RSA, and frankly even ECC is a
stretch.

>  for the non-paywalled version)

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 15 Apr 2015 15:28:19 +0000

Derek Atkins ‎<[email-masked]> writes:

>Okay, so you have effectively written off IoT.  

What Things?  All the embedded stuff I've worked with that talks TLS manages
(somehow, it's pretty ugly in many cases) to talk at least
TLS_RSA_WITH_AES_SHA1 (if not _DHE), because they have to do what all the
browsers do, and that's the most common one.

If you're really space-constrained then you don't run TLS in the first place,
because it's a huge resource hog.  OTOH if you need to be controllable via a
browser/web services/AJAX/whatever then you run the most common denominator
spoken by the other side, which is typically RSA + AES + SHA1 (I used DHE and
SHA256 to avoid getting sidetracked into a discussion over hash algorithms and
whatnot).

>Personally I'd prefer a TLS that enables IoT support instead of requiring IoT
>to be completely incompatible.

See above, either the IoT device will speak the most common implementation, or
it won't do TLS at all.

Peter.

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Apr 2015 10:27:26 -0400

Peter,

> browsers do, and that's the most common one.

All I'm suggesting is that there are other algorithms that exist that
would better support these devices, so I'd prefer we don't rule out
supporting those algorithms.

> SHA256 to avoid getting sidetracked into a discussion over hash algorithms and

There are different kinds of contraints on IoT; space is one knob.
Power and CPU is another.  Many of the devices I work with are more
constrained with Power and CPU than with Space (although they are still
relatively space constrained, certainly compared to a laptop or mobile
phone).

> See above, either the IoT device will speak the most common implementation, or

And I'm only suggesting that we keep our options open for algorithms
that could be out there and enable support (albeit in a future
implementation).  Keep in mind we're talking TLS1.3, which *nobody*
supports ;)

-derek

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Apr 2015 10:42:06 +0900

[ as discussed privately ]

there will always be massive machines at the 'top' and what we think of
as 'tiny' ones at the bottom.  we should let neither drive our concepts
of architecture.

randy

---

From: Derek Atkins <[email-masked]>
Date: Fri, 17 Apr 2015 09:27:23 -0400

> as 'tiny' ones at the bottom.  we should let neither drive our concepts

I'm not suggesting it drive our architecture.  The architecture *works*
as designed.  I'm just suggesting that we not limit our choices of
ciphers to only those that work at the top or middle, and to consider
also including ciphers that enable us to work at the bottom.

I.e., I'm suggesting that we keep an open mind on parameter selection,
which is IMHO completely separate from the architecture selection.

-derek