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

[Aaron Zauner]

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.

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.

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

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140628/39be3f27/attachment.sig>