Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

[Dave Garrett <[e-mail]>]

On Monday, April 13, 2015 12:49:45 pm Daniel Kahn Gillmor wrote:
> On Mon 2015-04-13 12:00:00 -0400, Dave Garrett wrote:
> > The thought process was 0 for N/A in the case of PSK without
> > (EC)DHE. I would much prefer that only (EC)DHE_PSK be permitted, which
> > would make this a non-issue.
> 
> Hm, let's look at the representations of ((EC)DHE_)PSK in the scheme you
> propose.  You've split the suite using these terms and mechanisms:
> 
>  "symmetric" (indicated by ciphersuite list)
> 
>  "handshake" (indicated by known_groups extension)
> 
>  "signature" (indicated by signature_algorithms extension)
> 
> I'd recommend using slightly different terminology, since at least
> "handshake" is already overloaded to mean something broader in TLS.
> 
>   "symmetric" (ciphersuite list)
> 
>   "key agreement" (known_groups extension)
> 
>   "authentication" (signature_algorithms extension)

Yes, this could avoid some miscommunication. The "handshake" includes both key agreement and authentication, so it would be better to be explicit.

In fact, if we're already renaming the extension, elliptic_curves/supported_groups could be better named as key_agreement_algorithms to better align with the signature_algorithms naming and explain its purpose better.

> In this model, ECDHE_PSK would have:
> 
>    key agreement: ECDHE
>   authentication: PSK
> 
> while non-(EC)DHE PSK would have:
> 
>    key agreement: PSK
>   authentication: PSK
> 
> right?

Yes.

> we'd only need a key agreement codepoint for PSK in the case we have
> non-(EC)DHE, but i have heard some constrained-devices people arguing
> for that in the WG, so that seems like a likely outcome.

Yes.

Not sure if allowing non-FS is a given, though. If they're really constrained, I think a much better alternative would be to define some (EC)DHE optimized for performance but only providing a minimum reasonable level of forward secrecy, even if not ideal.

> So if we have to have non-(EC)DHE PSK, what would it mean if a TLS peer
> were to try to negotiate:
> 
>   key agreement: PSK
>  authentication: RSA-PSS
> 
> Do we just say "don't do that"?

SGTM

> As for placing the known_groups codepoint at 0: it's conceivable that in
> the future someone wants to resurrect SRP or add some other PAKE or any
> other non-DH key agreement scheme (with or without forward secrecy and
> with or without authentication), in which case it would be aesthetically
> nice to have a block of "neighbors" with similar properties -- using 0
> doesn't let us do that grouping.

The codepoint is of course rather arbitrary, so picking some other value for future-proofing is fine. It's a 16-bit space so there's plenty of room.


Dave