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

[Hubert Kario <[e-mail]>]

On Thursday, 15 March 2018 22:51:49 CET Benjamin Kaduk wrote:
> On Thu, Mar 15, 2018 at 12:25:38PM +0100, Hubert Kario wrote:
> > On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote:
> > > 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...
> > 
> > not my fault that what we called just "PSK"s in TLS 1.2 is now "external
> > PSKs" in TLS 1.3... I wanted to be unambiguous, so please, can we discuss
> > the issue, not semiotics?
> 
> Sure!  (I still don't see how an ephemeral in-server key would be
> used as/with an external PSK.)

aah, that's were the confusion is, I was talking ("only because the server was 
restarted") about resumption PSKs, I didn't think you were proposing ("then 
aborting the handshake on binder failure would be the correct choice") that 
behaviour only for external PSKs — you can't differentiate resumption PSKs 
based on being able to verify the identify (assuming it's a RFC 5077-style 
ticket) because you can't be sure you have all the keys to verify them
(not to mention that the tickets could have been established by a TLS 
implementation that was used on this server yesterday or the identity can be a 
database lookup key, session_id style)

so there's no reliable way to say that, yes, this identity is or is not a 
resumption ticket, if I can't decrypt it

> > > > 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.
> > 
> > we do not have a reliable mechanism of differentiating between external
> > and
> > resumption PSKs while parsing Client Hello
> 
> Well, a valid external PSK (identity) the server will of course
> recognize, and we have a SHOULD-level requirement that the
> obfuscated_ticket_age is zero for external PSKs.  I haven't gotten
> to think through whether there is still potential for information
> leakage about external PSK identities, but it seems like there would
> not be, provided that the server prefers resumption to external-PSK
> full handshakes.

SHOULD means we can't depend on it — it's not reliable

if we say that resumption PSKs MUST have zero age and resumption ticket MUST 
NOT be zero (even if that means fudging the time a bit), then yes, there would 
be a way to differentiate them

that doesn't help against attackers that have one valid identity and want to 
find out other identities configured on the server though

I'd really prefer we exhaust other possibilities before sacrificing support 
for multiple external PSK. With TLS 1.2 we had ticket_hint to guide PSK 
selection, now we're left with just server IP or hostname.
(I do admit that requiring one external PSK, having way to identify them with 
no false positives and negatives, and ignoring it completely in case of binder 
verification failure does look solid)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic