Re: [TLS] Problems with TLS 1.3 handshake protocol

["Dan Harkins" <[e-mail]>]

  Hello,

On Wed, August 20, 2014 9:45 am, Ilari Liusvaara wrote:
[snip]
> 6) Problems with SRP:
> ---------------------
>
> SRP in general needs ServerKeyExchange before ClientKeyExchange.
> Now, if client is able to guess the exchange group, the order
> of those two can be inverted.
>
> Also, the key exchange messages have their own format.
>
> Some additional issues:
> - The key shares are relatively large (multiplicative group!)
> - The key shares are relatively slow to generate (ditto)
> - The usual SRP groups do not match named groups.
>
> There is no straightforward way to make ECC SRP.

  All of these issues are addressed by draft-ietf-tls-pwd--
it can use ECC, supports named groups, and can have key
shares that are smaller and faster to generate.

> Also, SRP is seemingly pretty much unused in context of TLS.
>
> Proposal: Does this need to be supported?

  The overwhelming majority of use of TLS is browser based
and there really isn't a compelling use for SRP (or any similar
kind of password-authenticated key exchange) in a browser
but there is in other uses of TLS, notably EST (RFC 7030).

  EST requires maintenance of a trust anchor database so
you need a certificate to get a certificate. By using a TLS
cipher suite that does not require a certificate, like TLS-pwd,
this problem is mitigated. It's much easier to use an app
that implements EST and it's much less likely that such an
app would be misconfigured.

  For this reason alone I think such a cipher suite needs
to be supported.

  regards,

  Dan.