On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley <hous...@vigilsec.com> wrote:
> Only the client ever sends the "psk_key_exchange_modes” extension. In
> fact, the server MUST NOT send a "psk_key_exchange_modes" extension.
>
> The "pre_shared_key” extension is already divided into the structures used
> by the client and the server. Why not add the ke_modes to the client part
> of the "pre_shared_key” extension?
>
This version allows you to tell the server that you would support a
specific set of modes (so it knows whether to send you a ticket or not)
without the need to allow an empty PSK list (with the small side effect
that you can check the minimum 1 requirement at the syntax level.
This would have the advantage that the ke_modes would be integrity
> protected by the HMAC carried in the PskBinderEntry.
>
It already is protected.
-Ekr
>
> If I am not missing something, then the following would be one way to
> accomplish this change:
>
> enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
>
> struct {
> opaque identity<0..2^16-1>;
> PskKeyExchangeMode ke_modes<1..255>;
> uint32 obfuscated_ticket_age;
> } PskIdentity;
>
> opaque PskBinderEntry<32..255>;
>
> struct {
> select (Handshake.msg_type) {
> case client_hello:
> PskIdentity identities<6..2^16-1>;
> PskBinderEntry binders<33..2^16-1>;
>
> case server_hello:
> uint16 selected_identity;
> };
>
> } PreSharedKeyExtension;
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
