Subject: Encryption boundary and transport handshake

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 5 Dec 2016 18:03:22 +0100

Hi once again,

for this point I believe there is first of all some specification missing, mainly in section 5.2.1 (transport parameters and options) because it’s really not clear what to do with the specified parameters. However (without having read the tls-draft in detail), I think the boundary between transport and crypto is very blurry here. I understand that the goal is to more tightly integrate them, mostly to avoid additional RTTs, however, I still think this can be clearly separated in the spec. I’m thinking here a little bit about the approach we finally took in tcpinc where you have tcp-eno that specifies the TCP option to negotiate crypto and potentially related information and then you can use this to either negotiate the use of tcpcrypt or TLS. Again, I know the goal is to not spend extra RTTs on negotiation but I think we should really ask which information is crypto-specific and which information is needed for all crypto schemes and can be provided by the transport part such as the STK potentially. Also I said this in my previous mail, the transport spec needs to have all information and mechanism that makes it possible to replace the crypto scheme at a later point of time. This seems not fully be the case yet.

The other rated point here, which also was made previously, is that is not clear which information is (always) sent in clear and with information should always be encrypted. Note that there are the two cases: having a first connection or session resumption. These cases should also be discussed in the transport draft.

Mirja