On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara <ilariliusva...@welho.com>
wrote:
>
>
> > PSK is handled by extending the concept of PSK flags that we already
> > have in NewSessionTicket to also include uses of PSKs where you
> > indicate the way in which you are using the PSK (or want it to be
> > used). There a bunch of ways to encode this. I'll give you the one I
> > mostly prefer below and then a one that's a smaller change but I think
> > a little less elegant at the end [note #4].
> >
> > First, we replace the flags word of the different KE modes for the
> > ticket with lists of code points, as below:
> >
> > enum {
> > psk_ke(0), // PSK key exchange
> > psk_dhe_ke(1), // PSK + DHE key exchange
> > (255)
> > } PskKeModes;
>
> In the orthogonalization above, the second entry would be PSK+GDHE
> (any supported key exchange function), but that's probably what you
> meant already.
>
Yes, we're using "dhe == GDHE"
>
> > And then add new code points for being able to use the PSK with and
> > without signatures (from the server). We had pretty rough consensus in
> > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01]
> > is part of the motivation for this idea.
> >
> > enum {
> > psk_auth(0), // PSK only
> > psk_sign_auth(1), // PSK + a signature (as in draft-thomson) [5]
> > (255)
> > } PskAuthModes;
>
> I think that PSK+signature modes are so different that those warrant
> promotion to a new major key exchange type.
>
Hmm... Why?
> > You might ask why you need the server to indicate what it did. The
> > reason is that we would like the client to know in advance (at the
> > time of the ServerHello) whether the server has sent
> > Certificate/CertificateVerify rather than having to figure it out from
> > what messages the server sends. The ke_mode field is redundant
> > (because you also infer it from the server key_shares) but I added it
> > for parity.
>
> Well, figuring out from ServerHello (and even EncryptedExtensions)
> would not be so bad if the rules were clear.
Yes, that's what I'm hoping for.
>
> >
> > 2. One question that comes up at the same time is whether we should
> > allow multiple key shares to be used, which is a structure that this
> > makes pretty easy. Basically, the server would just supply as many
> > counter-shares as it wanted and then we'd need a defined order for how
> > they were inserted into the key schedule. This feature would be nice
> > for enabling post-quantum, but probably better to just define
> > <PQ-Algorithm + Curve> code points.
>
> In order of group number? Or in order of server reply?
>
> (Both orders would be well-defined). Would also avoid the bit of
> special case of zero key in pure-PSK mode...
>
I was thinking in order of group number, but if you do combined code points
you don't
need to do this.
> 5. Note: this would allow for modes where the server signs over a PSK
> > handshake with no DHE at all. The resumption_ctx mechanism is intended
> > to ensure that that is OK, but we'd need to confirm with analysis.
>
> I should also figure out all the attacks I figured out against server
> auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported
> any such modes).
>
> Yeah, if resumption_ctx stuff is actually used, it should do the trick,
> as it binds the PSK key used (and the normal handshake hash binds the
> negotiation).
>
> The resumption_ctx would also bind the key if one kept it as constant
> and omitted Certificate message.
>
Definitely like to hear about this.
-Ekr
>
>
> -Ilari
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
