One more thing I wanted to note. The section about when you could receive
prior to Finished was a bit confused. I rewrote it as follows.
Once a side has sent its Finished message and received and validated
the Finished message from its peer, it may begin to send and receive
application data over the connection. There are two settings in
which it is permitted to send data prior to receiving the peer's
Finished:
1. Clients ending 0-RTT data as described in Section 4.2.9.
2. Servers MAY send data after sending their first flight, but
because the handshake is not yet complete, they have no assurance
of either the peer's identity or of it's liveness (i.e., the
ClientHello might have been replayed).
This is not intended to be a normative change but just to capture the
current
state, so if people think I messed it up, or have proposed better wording,
please send PRs
-Ekr
On Mon, Jul 3, 2017 at 5:01 PM, Eric Rescorla <e...@rtfm.com> wrote:
> Hi folks,
>
> I just published draft-21, which incorporates the discussions we've
> been having about 0-RTT replay. This lead to two changes:
>
> - Modifying the key derivation for PSKs so that each session ticket
> is associated with a distinct PSK.
>
> - Adding a very extensive description of 0-RTT nti-replay and
> a SHOULD-level recommendation that servers use some anti-
> replay mechanism that doesn't allow replay within a given
> zone.
>
> In addition, I have followed Richard Barnes's lead and added
> key transition events to the state machine. This also clarified
> that clients should send in-handshake alerts encrypted if they
> can.
>
> I wanted to call the WG's attention to one issue:
>
> Currently the extension table says that server_certificate_type goes
> in the Certificate message, whereas client_certificate_type does
> not. My reasoning for the latter is that the extensions are attached
> to individual certificate elements, so it was non-sensical to have a
> situation where you might have cert A be X.509 and cert B be PGP. I
> think we should just change server_certificate_type to go in EE, and
> then maybe in future if people want something cleverer they can add it
> then. I didn't want to do this without WG discussion, but I think we
> should and if people don't object I'll do it in a -22.
>
> This version also addresses Kathleen's AD Review.
>
> Other comments welcome.
> -Ekr
>
>
> [0] Note that this is a bit tricky when you are also streaming
> Early Data.
>
>
>
>
>
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
