Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

[Eric Rescorla <[e-mail]>]

Karthik,

Thanks for sending this. Some initial thoughts below.

> After implementing and analyzing TLS 1.3, here are a few suggestions for
discussion.
>
> 1) Early Data Extension
>
> The current early-data extension is too DH-specific.
> When using PSK, we now have to look at both early_data and pre_shared
extensions.
> I suggest reusing the same extension for both, with the following
interpretation:
>
>         struct {
>           select (Role) {
>               case client:
>                   opaque id<1..2^16-1>;
>                   opaque context<0..255>;
>                   CipherSuite cipher_suite;
>                   Extension extensions<0..2^16-1>;
>
>               case server:
>                  struct {};
>                 }
>         } EarlyDataIndication;
>
>
> In the semi-static DH case:
> - id is the configuration id
> - context is the hash of the ServerConfiguration + Server Certificate +
CertificateRequest
>
> In the PSK resumption case:
> - id is the session ticket
> - context is a *public* value unique to the derived session. For example,
it could be defined as the session hash of the original handshake,
>   or it could be derived by the client as HKDF(RMS, “early data context”)
>
> In the pure PSK case
> - id is the PSK identifier
> - context is unique to the PSK and its allowed use.
>   For example, it can be generated (out-of-band) as HKDF(PSK, “early data
context”)

There seem to be several ideas here:

1. Dispose of PreSharedKey and only use EarlyDataIndication.
2. Have an explicit context field that is derived in a deterministic
fashion.


I'm not sure that the first of these is a good idea, for several reasons.

1. While it's not sensible to have 0-RTT data encrypted with multiple
PSKs, it's not at all silly for the client to offer multiple PSKs to
the server. Note that the current TLS 1.2 PSK extension allows the
server to provide a hint on the theory that the client might have more
than one PSK. Having separate extensions allows this.

2. It burdens servers and clients which don't want to do 0-RTT (but do
want to do PSK-resumption) with 0-RTT machinery. This is a particular
concern with the extension version proposed above because it doesn't
give the client any way to say "this is just a resumption, I'm not
sending any 0-RTT data". This means that servers have to at least
implement the 0-RTT skipping algorithm even if they refuse 0-RTT. [You
could say that the server had indicated "I won't accept 0-RTT" when it
established the ticket, and then act as if the client complied but
that produces a really ugly decryption failure rather than a handshake
failure]. We'd at least want to restore the EarlyDataType value from
previous versions of EarlyDataIndication so that the client could
express what it did here.


The second idea seems sensible, and I do like the idea of binding the
session hash of the previous handshake into PSK-Resumption. One thing
that seems unclear would be what the responsibilities of the server
are with respect to the context. In the current draft, the client
and server both digest it explicitly but it's not signalled, which
has the disadvantage that you can't just run the session transcript
forward. If the client just provides it to the server, then that
seems to have different security properties unless we require the
server to verify it. Is that what you have in mind here?

I note that the context value here was intended for a different
purpose, namely tying the handshake to some external context (for
instance, if you have an external anti-replay mechanism). I'm not sure
if that's still valuable, but if we wanted to do so, then we'll need a
separate field somewhere.


Another possible design here would be:

        struct {
           opaque psk_identity<0..2^16-1>;
           opaque context<0..255>;
        } PreSharedKeyInfo;

        struct {
           select (Role) {
               case client:
                   PreSharedKeyInfo keys<2..2^16-1>;

               case server:
                   uint16 index;  // The selected index
           }
         } PreSharedKeyExtension;


         struct {
           select (Role) {
               case client:
                   CipherSuite cipher_suite;
                   select (key_exchange) {
                      case PSK:
                         uint16 index;   // PSK index

                      case (EC)DHE
                         opaque configuration_id<1..2^16-1>;
                         opaque server_context<0..255>; //
ServerConfiguration + Server Certificate + CertificateRequest
                   }
                   Extension extensions<0..2^16-1>;

               case server:
                  struct {};
                 }
         } EarlyDataIndication;

It's not super-elegant to have a switch here in the decode for
EarlyDataIndication, but they actually are semantically different, so
I'm not sure it's that bad. The idea here would be to design to a
different invariant, namely:

- The client gets to offer the server a bunch of options for the
  1-RTT handshake. The server picks one.

- The client offers the server exactly one option for 0-RTT and
  the server can take it or leave it.

This is the way that 0-RTT DHE works now. It does open the door
to the server somehow picking a different option for 1-RTT than
the client chose for 0-RTT, but this is something we could forbid.


> 2) New Session Ticket
>
> The NewSessionTicket message needs to indicate whether the server will
accept 0-RTT,
> and what ciphersuites it is willing to accept (e.g. pure PSK resumption
vs only PSK-ECDHE).

> I suggest the following modification to this message:
>         struct {
>          uint32 ticket_lifetime;
>          opaque ticket<0..2^16-1>;
>          CipherSuite cipher_suites<2..2^16-2>;
>          EarlyDataType early_data_type
>         } NewSessionTicket;

The cipher suites indication seems generally sensible.


>         enum {
>           no_early_data_allowed(0),
>           replayable_early_data_allowed (1),
>           all_early_data_allowed(2),
>           (65535)
>        } EarlyDataType;
>
> The interpretation of the early_data_type field is that the server is
either:
> (a) unwilling to accept 0-RTT (no_early_data_allowed),
> (b) willing to accept 0-RTT, but it has no replay cache
(replayable_early_data_allowed),
> (c) willing to accept 0-RTT and has a replay cache that it uses to
prevent replay (all_early_data_allowed)

This is an interested suggestion. I agree that it's important to
be able to say "don't send me 0-RTT data" (see above). ISTM that
"all_early_data_allowed" would be useful primarily if we allowed
clients who received it to use the ordinary TLS 1.3 API for sending
0-RTT data. That would be a real advantage, it seems to me.



> There has been much discussion on 0-RTT replay and here’s a quick summary
of my understanding.
> We already knew that an active attacker, or a lossy network, or an
overzealous web browser could
> and would cause 0-RTT (and even 1-RTT) data to be replayed to the server.
This can already happen
> in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.
>
> The new concerns on the mailing list (and in my TRON talk which was based
on a ProVerif model)
> are that unlike TLS 1.2:
> (a) even a passive attacker could replay 0-RTT data, long after the
client has gone away,

Nit: This doesn't sound like a passive attacker to me...


> Even if we eliminate client certificate authentication from 0-RTT, this
notion of “context" is still useful for two reasons:
> (a) the application may use TokenBinding or some such protocol to
authenticate 0-RTT data, and we need to understand what “channel binding”
to provide for this case,
> (b) in PSK resumption mode, since the handshake log does not contain much
information that is specific to the previous connection, it would be more
robust to add an explicit context.

Yes, I agree that this is an improvement.

-Ekr


On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan <
[e-mail]> wrote:

> We currently allow 0-RTT with Semi-static DH, with PSK resumption, and
> with pure PSK.
> Whether or not we keep all of these, it would be good to clean up the
> protocol design
> so that both the client and server have a uniform way of signaling their
> preferences.
>
> After implementing and analyzing TLS 1.3, here are a few suggestions for
> discussion.
>
> 1) Early Data Extension
>
> The current early-data extension is too DH-specific.
> When using PSK, we now have to look at both early_data and pre_shared
> extensions.
> I suggest reusing the same extension for both, with the following
> interpretation:
>
>         struct {
>           select (Role) {
>               case client:
>                   opaque id<1..2^16-1>;
>                   opaque context<0..255>;
>                   CipherSuite cipher_suite;
>                   Extension extensions<0..2^16-1>;
>
>               case server:
>                  struct {};
>                 }
>         } EarlyDataIndication;
>
>
> In the semi-static DH case:
> - id is the configuration id
> - context is the hash of the ServerConfiguration + Server Certificate +
> CertificateRequest
>
> In the PSK resumption case:
> - id is the session ticket
> - context is a *public* value unique to the derived session. For example,
> it could be defined as the session hash of the original handshake,
>   or it could be derived by the client as HKDF(RMS, “early data context”)
>
> In the pure PSK case
> - id is the PSK identifier
> - context is unique to the PSK and its allowed use.
>   For example, it can be generated (out-of-band) as HKDF(PSK, “early data
> context”)
>
> 2) New Session Ticket
>
> The NewSessionTicket message needs to indicate whether the server will
> accept 0-RTT,
> and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs
> only PSK-ECDHE).
>
> I suggest the following modification to this message:
>         struct {
>          uint32 ticket_lifetime;
>          opaque ticket<0..2^16-1>;
>          CipherSuite cipher_suites<2..2^16-2>;
>          EarlyDataType early_data_type
>         } NewSessionTicket;
>
>         enum {
>           no_early_data_allowed(0),
>           replayable_early_data_allowed (1),
>           all_early_data_allowed(2),
>           (65535)
>        } EarlyDataType;
>
> The interpretation of the early_data_type field is that the server is
> either:
> (a) unwilling to accept 0-RTT (no_early_data_allowed),
> (b) willing to accept 0-RTT, but it has no replay cache
> (replayable_early_data_allowed),
> (c) willing to accept 0-RTT and has a replay cache that it uses to prevent
> replay (all_early_data_allowed)
>
> The client’s response to this ticket message should be to store it in its
> session along with the “context” (session hash or derived from RMS),
> the allowed cipher suites, and the early_data_indication.
>
> When resuming with this ticket:
> - the client should not send any 0-RTT data if no_early_data_allowed
> - the client should only send replayable data if
> replayable_early_data_allowed (e.g. GET requests)
> - the client can send any 0-RTT data if all_early_data_allowed, trusting
> the server to do the right thing.
>
>
> A note on replay
> ----------------------
>
> There has been much discussion on 0-RTT replay and here’s a quick summary
> of my understanding.
> We already knew that an active attacker, or a lossy network, or an
> overzealous web browser could
> and would cause 0-RTT (and even 1-RTT) data to be replayed to the server.
> This can already happen
> in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.
>
> The new concerns on the mailing list (and in my TRON talk which was based
> on a ProVerif model)
> are that unlike TLS 1.2:
> (a) even a passive attacker could replay 0-RTT data, long after the client
> has gone away,
> (b) replaying authenticated 0-RTT data can be more damaging (whether
> authenticated with client cert or with a cookie), and
> (c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT
> data which opens up new attack vectors.
>
> As a result of these new concerns, I would say that TLS 1.3 should
> recommend that all servers SHOULD
> implement a replay cache, and those that cannot should clearly signal this
> to the client, so that the client
> can adjust its 0-RTT use case and its expectations accordingly.
>
> A note on authenticating the 0-RTT “context”
> ----------------------------------------------------------
>
> When trying to figure out how to authenticate 0-RTT DH mode in an earlier
> draft, we came upon the
> design of signing the Handshake Context that consists of the ClientHello +
> additional information from the previous handshake.
> This construction prevents 0-RTT authentication from unknown key share
> attacks.
>
> Even if we eliminate client certificate authentication from 0-RTT, this
> notion of “context" is still useful for two reasons:
> (a) the application may use TokenBinding or some such protocol to
> authenticate 0-RTT data, and we need to understand what “channel binding”
> to provide for this case,
> (b) in PSK resumption mode, since the handshake log does not contain much
> information that is specific to the previous connection, it would be more
> robust to add an explicit context.
>
> If we accept the definition of “context” in the EarlyDataIndication
> extension, then we can use the hash of the ClientHello uniformly in all
> 0-RTT modes for deriving keys, and for deriving a channel binding for the
> application. Furthermore, we can safely introduce a PSK_ECDHE
> mode where the server sends its Certificate and CertificateVerify and its
> signature is correctly bound to the PSK (via the “context” field).
>
> Best regards,
> Karthik
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>