Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Benjamin Kaduk <[e-mail]>]

On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote:
> On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote:
> > It seems like we get ourselves in trouble by allowing multiple
> > external PSKs to be present.  If we allowed at most one external
> > PSK in a given ClientHello, then aborting the handshake on binder
> > failure would be the correct choice, as discovering a valid identity
> > would require discovering a valid key/password as well.
> 
> but identity/binder may be invalid only because the server was restarted and 
> generated a new in-memory key; we don't want to abort connection in such 

For an external PSK?  That hardly sounds like "external" to me...

> situation, continuing to a regular handshake is necessary then for good user 
> experience (and likely, even security, given the history of TLS version 
> fallbacks)
>  
> > Disallowing multiple external PSKs would make migration scenarios a
> > little more annoying, but perhaps not fatally so.
> 
> not only migration, but session resumption and regular PSK at the same time 
> too - for session resumption you may not do DH, while for initial handshake 
> with PSK you may want to to gain PFS...
> 
> so as tempting as the removal of multiple PSKs from ClientHello is, I'm afraid 
> the fallout is far too large to do it

I did not say removal of multiple PSKs, rather removal of multiple
*external* PSKs.

-Ben(jamin)