On Wed, Sep 13, 2017 at 8:40 AM, Matt Caswell <[email protected]> wrote:
> On 13 September 2017 at 16:12, Eric Rescorla <[email protected]> wrote: > > On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell <[email protected]> wrote: > >> > >> I am looking at trying to implement the TLSv1.3 stateless cookie > >> mechanism (in order to be able to support QUIC stateless retries). > >> > >> I am not clear how cookies are supposed to interact with early_data. > >> Consider the scenario where a server is operating statelessly. Because > >> there is no state each ClientHello looks like the first one it ever > >> saw. The server only knows that a particular ClientHello is actually a > >> ClientHello2 following an HRR because of the state held in the cookie. > >> > >> What happens when a client attempts to send early data to such a > >> server? The server will process the ClientHello and determine that > >> there is no cookie, sends back an HRR and then forgets all of its > >> state and waits for the next ClientHello. However what it actually > >> gets next is early_data. It does not know that that early data > >> followed an earlier ClientHello (because it is stateless) so it does > >> not know to skip the records. It just looks like illegal records so, > >> presumably, it will respond with an alert. > > > > > > It seems like there are three cases here: > > > > 1. TLS over TCP -- you won't do this statelessly, and so you can know to > > dump > > early data. > > 2. DTLS -- you can be stateless, but you don't terminate connections on > > decrypt > > error, so you just discard the packets as you would any other bogus > packet. > > 3. QUIC -- the data looks like an unknown connection (you have dumped the > > conn_id) > > so you silently discard. > > Right - well that's the case right now - I guess we don't know how > this feature might be used for in the future? > True... So in case (3) should this be documented somewhere - either in the > TLSv1.3 spec or the QUIC spec? I think it should go in the QUIC spec, because it's QUIC's responsibility to provide the transport abstraction to TLS. > Perhaps the TLSv1.3 spec should just > state that protocols using the cookie feature should specify how > early_data is to be handled - and then leave it up to QUIC/DTLS to > define the behaviour in each of their cases. > Generally, I'd prefer to keep this in the other specs, because these are issues that arise principally when TLS is embedded in other specs.... If someone has a PR, I can take a look, though. >> I am also unclear what protects against cookies being replayed. If an > >> attacker wishes to perform an amplification attack on a particular IP > >> it awaits a legitimate ClientHello with a cookie coming from that IP > >> and records it. It then replays that ClientHello with cookie to the > >> server many times. The cookie looks valid to the server and it > >> responds with its ServerHello, full Certificate chain etc back to the > >> original IP. What have I missed here? > > > > > > Yes. Cookies aren't generally intended to stop that kind of > amplification, > > they're just designed to prevent blind attacks on IPs you're not on-path > > for. Note that QUIC has an additional defense here of requiring that > > that ClientInitial be a certain minimum size. Note that if you are > on-path > > you can still get a lot of amplification even with TCP at the cost of > > sending SYN, ACK, ClientHello... > > Ok - that makes sense. Perhaps this is worth a note somewhere (not > sure where it would fit). > I filed: https://github.com/tlswg/tls13-spec/issues/1079 > > Matt >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
