This is my review of draft-rescorla-tcpinc-tls-option-04.txt.
Circumstances were such that I had to print it out and review it on
paper. Given the tight dependency on TLS1.3, this means my review is
light on the question of integration with TLS, and more geared towards
interaction with sockets and TCP-ENO. Fortunately, the latter is
probably where I can add the most value.
At a very high level, I think if you are going to combine TCP-ENO and
TLS, this is basically the natural way to do it. Use of ENO to enable
TLS seems good. Use of an extractor for the session ID with ENO
transcript seems appropriate. Assignment of the A and B roles to client
and server respectively also seems right. However, I do have some
concerns with the draft.
* 0-RTT
My most serious concern is that of the 0-RTT mode will introduce both
security and correctness limitations, and therefore that if it is there
at all it should not be on by default. The security issue is that 0-RTT
lacks forward secrecy for the full connection and is vulnerable to
replay attacks. Hence, this is not something that should be enabled
transparently to applications.
The functionality issue is that I don't understand how Figure 2 would
line up with various system calls including requests for the session ID.
For the sake of concreteness, let's imagine mapping this to a socket
interface. On the active opener, there are two main events:
1. A call to connect(), initiating the connection, and
2. A point at which connect "finishes." By default, this event is
indicated by the connect system call returning. However, in the
event that fcntl F_GETFD has been used to set the O_NONBLOCK flag,
this event is indicated *poll() or select() considering the file
descriptor writable.
I'm trying to figure out how these two events map to Figure 2 (message
flow for a zero round trip handshake). You would only have application
data to send after event #2. Yet since the TCP stack doesn't know for a
fact that the client will write first, it doesn't want to delay sending
the other parts of the initial message (ClientHello, etc.).
Things get even more complicated when you throw in the ENO Session ID
("ESID"). What happens when an application requests the ESID between
points 1 and 2? I assume you get EAGAIN (or maybe EWOULDBLOCK on
systems that distinguish and use EWOULDBLOCK for connect). What happens
when an application requests the ESID after point 2? My assumption was
that the call would return an ESID immediately. Other possibilities
include blocking until the ServerHello (highly problematic when
O_NONBLOCK is set), returning EAGAIN, or returning some other error that
could be interpreted as TCPINC disabled. All three of those
possibilities seem like they could really trip up applications. Yet if
you return the ESID before the ServerHello, I don't actually see how the
chosen ESID can be secure. (You're vulnerable to replay at that point.)
* Negotiation failure
Section 2 states:
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.
Currently this is in contradiction with TCP-ENO, which states:
Conversely, if a host receives an ACK segment containing an ENO
option, then encryption MUST be enabled. From this point the
host MUST follow the encryption protocol of the negotiated spec
and MUST NOT present raw TCP payload data to the application.
Now of course we can change TCP-ENO if this is something we want, but
doing so is unfortunate as it means you might have negotiated something
else that works with ENO, yet now it's too late to go back and try a
different encryption spec. Therefore I'd like to propose something
different: requiring all implementations to have some minimum cipher
suite.
While normally we wouldn't want to mandate some ciphersuite, I think ENO
makes this acceptable because of the upgrade path. This would mean that
instead of requesting an ENO suboption for "TCP-TLS", you would request
an ENO suboption for "TCP-TLS with mandatory P256/AES128GCM..." or some
such. The other alternative would be to use a variable-length suboption
and include a bitmask of supported cipher suites.
* More general comments
This document was very hard to read without the TLS1.3 draft. A bit
more context on a lot of questions would greatly have improved
readability. For example, how does one distinguish between an X.509
certificate and a raw public key? Why do you even need a public key if
you have ECDH parameters?
I realize that the working group doesn't like APIs creeping into
protocol documents, but a more concrete discussion of the API changes
you envision would make it easier to follow the protocol. I would urge
that either for the sake of the draft, there be a non-normative section
on possible API extensions, or that there be some companion informative
document (along the lines of draft-bittau-tcpinc-api) that we can refer
to. After all, configuration comes in to play in, e.g., section
3.1.2.3, and it's hard to follow in the abstract.
Related to both the public key and API points, I found the mention of
TOFU uses in section 3.1.1 very vague. Some more detail would be really
helpful.
The document lays out two use cases: transport-level and application
level. I would strongly recommend requesting two different ENO
suboptions for the two cases. Only the transport-level suboption would
really seem to be in scope for the TCPINC working group. If an extra
ENO suboption could be of benefit to the TLS working group, then maybe
that's an ancillary benefit of standardizing ENO. However, if TCPINC
chooses TLS, we should go with only simplest most stripped down
TLS1.3-only protocol, so whatever ENO suboption TCPINC adopts should not
permit 1.2 as a fallback.
Section 3.1 states:
In order to facilitate implementation, this section provides a
non-normative description of the parts of TLS 1.3 which are
relevant to TCPINC and defines a baseline of algorithms and
modes which MUST be supported.
Assuming this sentence is intended to mean what I think it means, I
would insert the word normative as follows:
In order to facilitate implementation, this section provides a
non-normative description of the parts of TLS 1.3 which are
relevant to TCPINC and defines a normative baseline of
^^^^^^^^^
algorithms and modes which MUST be supported.
* NITs
ENO in SYN-ACK is already reported.
** Section 3.1.1
"(see Figure 2" is missing right parenthesis.
"In both case, the server" -> "... cases, ..."
** Section 3.1.2.1.2
"(see {{server-first-flight)" is clearly some typo intended to be a
reference.
** Section 3.1.2.2.1
"The server respond's" -> "... responds"
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
