[Ach] considering your experience in selecting the perfect config string, would you...

[ianG]

On 28/06/2014 01:33 am, Aaron Zauner wrote:
> 
> 
> ianG wrote:
>> So here's a merry puzzle.
>>
>> Over at IETF, they are trying to create an extension to TCP that
>> opportunistically leaps with gay abandon into encryption mode.  Bless
>> 'em!  This means, if both ends have the extension, TCP will be
>> encrypted, and the devils of mass surveillance will be thwarted.  Yay!
> 
> You are talking about tcpcrypt?
>>
>> However, as with every committee product, the room has bifurcated into
>> WW3 over a question.  Here is the question over which the two sides
>> duel, in two parts, perhaps to tease out just how deeply y'all feel here.
>>
>> Given that this very room has now battled for 6m on producing the mother
>> of all security guides, I'm guessing there are some opinions ;)
> 
> Opinions!
> 
>> Q1:  Case A:  Should crypto-security protocols in general always (MUST)
>> include in-protocol negotiation to choose from a selection of ciphers
>> and hashs and so forth?  This is commonly called "algorithmic agility".
>>
>> OR, case B:
>>
>> Should this not be compulsory (MAY) and some protocols could then impose
>> by specification a single ciphersuite to be used?  One, only!  E.g.,
>> ditch negotiation.
>>
>> (And, it should be said, be limited to version upgrade in the event of a
>> cipher break).  This is sometimes called "the one true cipher suite."
> 
> This is a difficult question and I do not have a clear tendency.
> 
> The problem is: How fast can you update a whole protocol as soon as one
> of it's security components has come under question and how fast can you
> deploy a fix for security threats? Just as Wuerstlein mentioned in the
> previous e-mail.


Well, we have the timeline for TLS.  And the smells of MD5, RC4, DES,
etc.  One of the blackmarks for agility is that the signs were there,
and agility didn't help.  If anything it made things worse.

We're now seeing a rush to a new suite: poly1305chacha20 and some new EC
curves.  We can probably measure the timeline on that work.  It's very
hard for them to retrofit that all in, as they have to make sure all the
other parts are preserved.


> The other problem is that as we have seen from TLS history negotiation
> is a difficult (and expensive - in terms of computing cost) process to
> implement properly in a protocol. There have been discovered various
> attack vectors over the years (MITM, downgrade,..).
> 
> I'd probably keep the ciphersuite as small as possible with some
> remaining "algorithmic agility" as you call it. Use secure and very fast
> symmetric ciphers, get the handshake right, go for AEAD.


One proposal is to use odds&evens pairs.  Which is to say have an A
suite accompanied by a B suite.  Then the next version upgrades to a B
suite accompanies by a C suite.


> for example: ECDHE + (Ed25519(EdDSA) || RSA) + ((AES-GCM ||
> AES-CTR-UMAC) || ChaCha20-Poly1305)
> (Good job here from the OpenSSH team supporting all of that ;))


Yes, if it were today, A would be RSA / AES / some Mac+mode and B should
be Ed25519 / ECDHE / Chacha20-Poly1305.



iang