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

[Ilari Liusvaara <[e-mail]>]

On Mon, Apr 13, 2015 at 04:45:25PM -0400, Daniel Kahn Gillmor wrote:
> On Mon 2015-04-13 14:55:05 -0400, Ilari Liusvaara wrote:
> > On Mon, Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote:
> >
> >> What do you think an implementation should do when a peer tries to
> >> negotiate the combination above?  Require an RSA-PSS signature from the
> >> server over some material derived in part from the PSK key agreement
> >> mechanism?
> >
> > To me it seems like that combo is quite insecure, unless one handles it as
> > a special case (in which case it is just equivalent to PSK in security,
> > just wastes time with a certificate).
> 
> Can you explain why it's "quite insecure"?
> 
> It doesn't seem any worse than normal (non-DHE) PSK other than the cost
> of signing and verifying.  I suppose that it also proves that an
> attacker has access to both the PSK and the secret key material
> belonging to the cert.

If it is really PSK with RSA-PSS, then it is semi-OK (but see below).

The problem here is:
- If PSK is considered authentication algorithm, then pure PSK has NULL
  key agreement. Which is quite dangerous with any authentication that
  can't provode key material (like any signature algorithm).
- If PSK is considered key agreement algorithm, then what is DHE-PSK
  (since DHE is key agreement).

> So, for example, you could give a dozen clients the same PSK (maybe to
> provide them with indistinguishability from each other to a network
> observer?), but clients that want to be sure they're talking to the
> server (instead of each other) can rely on the server's cert.

Due to how key derivation works with pure PSK, the clients can MITM
each other. And if it is supposed to be DHE-PSK+RSA-PSS, wouldn't
something like using HMAC for client auth work?

> > As list, the key exchange methods TLS v1.2 actually supports (after merging
> > some non-significant distinctions) are:
> > - RSA [going away]
> > - RSA_EXPORT [you have deimplemented this already, right?]
> > - DH_CERT [going away]
> > - DHE_CERT [supported]
> > - DHE_ANON [???]
> > - KRB5 [going away]
> > - PSK [???]
> > - DHE_PSK [???]
> > - RSA_PSK [going away]
> > - SRP [???]
> > - SRP_CERT [???]
> 
> I think this list mixes up key exchange with authentication, which was
> what Dave was trying to tease apart.  For key exchange, there is no
> difference between DHE_CERT and DHE_ANON and DHE_PSK -- they're all DHE.
> the ANON/CERT/PSK parts would be negotiated separately in the
> authentication side of things (via the signature_algorithms extension).

TLS v1.2 also has PSK identity hint, in which server first gives a hint
before client selects the final identity (which obviously is 2RTT process).

To me it seems (DHE-)PSK is quite special.

> (And if we're using supported_groups, the distinctions between different
>  flavors of DHE (FFDHE2048, ECDHEP256, ECDHEX25519, etc) are hardly
>  non-significant, but i guess that's a slightly different discussion.)

What would the difference from TLS standpoint be (apart from some keysize
parameters)?


-Ilari