I have reviewed this document and have a few minor comments. I also have many editorial notes that can be addressed out of band.
In the abstract and introduction, we have text about the properties that TLS is expected to provide, like confidentiality, authentication, etc. Do we want to say anything about avoiding side channels that might leak information about the data being exchanged? I know that we are not 100% confident at what exactly we currently achieve in this area, but since we have mechanisms that attempt to achieve it, maybe it is worth mentioning. (In a similar vein, as davidben reminded me recently, an attacker “who has complete control of the network”, as is our stated adversary, can do things like trickle packets in one by one and try to see, e.g., where the end of early data is and query handshake state. So some things may not be avoidable.) In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to ensure that the peer is well-behaved and isn’t forcing the local system into a small subgroup. Somehow I thought that additional checks were needed to avoid being forced into a small subgroup, but I guess that depends on what group it’s in, and I didn’t pull up the RFC 7919 reference when I was reading this document. In section 4.2.7, we note that the server MUST NOT send the “psk_key_exchange_modes” extension, with the implication that the client must observer the types of handshake messages that are subsequently received in order to determine what the server selected. I think that we had talked about this already some time ago, but just wanted to confirm that we are okay with increasing the size of the client state machine in this manner. In section 4.5.1 we note that when client auth is not used, servers MAY compute the remainder of the client-sent messages for the transcript so as to issue a NewSessionTicket immediately after the server Finished. Do we want to say anything about why a server might wish to do so? The coverage of record payload protection (around section 5.2) seems to not always make careful distinction between TLSPlaintext, TLSCiphertext, TLSInnerPlaintext, and the fields therein. In some sense this is editorial, but there were a lot of places that I flagged, so I wanted to call it out to the broader audience and get more eyes on it. I also didn’t find a description of where the length of the AEAD authentication tag gets included into a length field for the ciphertext. At the end of section 6.1 we have this little note that “it is assumed that closing a connection reliably delivers pending data before destroying the transport”, which, if I remember correctly previous discussion on this list, is not actually true for linux. It is perhaps problematic to have an assumption that we know is not going to be held for a large proportion of implementations. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
