Re: [secdir] Secdir review of draft-ietf-tls-falsestart-01

[Bodo Moeller <[e-mail]>]

Charlie,

thanks for your comments.

Some nits:



Section 3 talks about determining whether a TLS server is "false start
> compatible". I believe any server that correctly implements TLS (i.e.,
> following the specification) would be false start compatible. That does not
> imply that all would be, and it would be useful to do some testing to see
> whether most implementations in fact are. Publishing this as an
> experimental RFC is likely to encourage such an effort.


I'm truly not sure about this. By the TLS specification, servers wouldn't
have to expect early handshake messages, so arguably server behavior in
their presence is left unspecified -- however, I'd certainly not be
surprised if all server implementations that aren't false start compatible
are indeed strictly broken (I see no good reasons for TLS servers to *not*
tolerate handshake messages that arrive early).

In any case, I think the concept of a TLS server being "false start
compatible" is useful, so don't think I'd want to make a change to the
document there.

Section 2 paragraph 1 says that TLS requires two full protocol rounds
> before the handshake is complete. While technically this is true, it
> overstates the benefit of this enhancement because TLS rides atop TCP which
> has its own protocol round before it starts carrying application payloads.
> So this enhancement reduces that TLS startup time from three round trips to
> two rather than the more dramatic two to one.


I don't really agree that draft-ietf-tls-falsestart-01 overstates the
benefit, it's just that the round-trip time added by TCP is mostly an
orthogonal issue: RFC7413 (TCP Fast Open) addresses it. I'll discuss that
point and mention that RFC in draft-ietf-tls-falsestart-02.

Bodo