[tcpinc] Review of https://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-05

[Kyle Rose <[e-mail]>]

(1) §2: "If the TLS handshake fails for non-cryptographic reasons such as
   failure to negotiate a compatible cipher or the like, endpoints
   SHOULD behave as if the the TCP-TLS option was not present."

David is right that this conflicts with TCP-ENO, but I'd actually
advocate changing the ENO draft and moving in the opposite direction
in order to be most in-line with the spirit of the WG: that failure to
negotiate TCPINC means fallback to unencrypted TCP.

To that end I'd suggest that any failure to negotiate TLS, except a
loss of sync resulting in an inability to deserialize the record
stream, should result in fallback to TCP. It should then be up to the
application to decide whether or not to proceed in the absence of
encryption. This still leaves a huge DoS attack surface for certain
classes of attackers, but much of that can be addressed with TCP-AO,
so I think we still gain a lot by requiring this.

(2) §3: "but encourage implementations to implement only TLS 1.3". If
this is the case, 1.2 would be mostly useless outside of custom
installations, which is not really the point of the WG as custom
installations can (and probably do) support TLS directly. Requiring
interoperability with the rare TLS 1.2-supporting implementations
would mostly just add complexity and additional attack surface. I'd
strike it and require TLS 1.3.

(3) §3.1.2.2.1: "ServerConfiguration [6.3.7]" Maybe reiterate here
that this is optional? Otherwise, the wording at the top of the
section suggests that every record in the sequence is required.

(4) §3.1.2: What is the point of the server certificate, the signature
in CertficateVerify, and authenticating said signature on the client?
As the public key is either made up on the spot, or its provenance
explicitly ignored ("it SHOULD NOT attempt to validate the
certificate"), It seems to provide no value and consumes CPU. Any
actual authentication of the channel's privacy would have to occur
either out-of-band or at the application layer using the TLS
Exporter-derived session ID, requiring yet another signature, or at
least an indication from the application that, yes, the client really
should check the signature on the certificate.

IMO, Certificate and CertificateVerify should be eliminated, and
authentication explicitly moved into the application layer.

(5) §3.1.4 and 3.1.5:

 "(Application Data)"

 "() Indicates messages protected using keys
                  derived from the static secret."

 "The 0-RTT traffic keys are derived solely from ES"

This seems to be in conflict. In general, the terminology around the
various secrets needs to be clarified.

(6) Given that applications will bootstrap authentication on top of
TCPINC, it's important that the same attention to replay attacks be
paid to this profile of TLS as it was to the full TLS 1.3. Clearly
this concern isn't as important for applications making use only of
OE, as they were already subject to replay attacks, but once
application layer authentication is enabled, the expectations for what
TCPINC provides are higher.

(7) §5: IPv6 does not have checksums at the TCP layer.

(8) Ekr, what are your thoughts on how TCP-ENO negotiation should
proceed in the presence of an application that wants TLS
authentication? E.g., let's say both client and server support
TCP-ENO, and the client browser and web server support TLS directly.
I'm thinking what you want is for the server not to negotiate
TCP-use-TLS, but to fall back to unencrypted TCP and then do the TLS
handshake in userspace, but I'd like to hear your thoughts.

Kyle