We still have a significant outstanding TLS 1.3 issue affecting involving which key to use for handshake and data records. Antoine Delignat-Lavaud, Bjoern Tackmann, Cas Cremers, Eric Rescorla, Felix Guenther and Markulf Kohlweiss put together a summary of the issue which is included below. We need to close on an approach to this issue so we can begin a final cryptographic review of the protocol. The plan is to have discussion of this issue for a week after which the chairs will start a week consensus call based on this discussion. After the chairs judge consensus, the author will produce a draft reflecting the consensus that can go out for review by the cryptographic community.
Thanks, J&S BACKGROUND TLS 1.3 currently encrypts post-handshake handshake messages (NewSessionTicket, KeyUpdate, and post-handshake client authentication) with the application traffic keys. This makes it hard to do certain kinds of proofs, particularly cryptographic style proofs that make statements about the entire handshake (including encrypted post-handshake messages) being composable with application traffic. These proofs rely on having separate keys for these handshake-type messages and the application traffic. Unfortunately, the TLS record framing is not easily compatible with having multiple keys used simultaneously: because we encrypt the content type, it is not possible to use it to determine which key to use to decrypt. We examined a number of proposals which would allow you to simultaneously have encrypted content types and separate keys, but they all appear to be nonviable for one reason or another: - Trial decryption has serious implementation problems - Double-encrypting handshake messages in both the handshake key and the application key does not actually provide the required key separation - Separately encrypting the content type is inefficient in a number of ways, especially for DTLS (and would need separate security analysis). This is probably the most viable of the “try to get both” designs. This leaves us with two primary alternatives: 1. Use the same key (as in the current draft-13) 2. Restore a public content type and different keys I discuss these in a bit more detail below USE THE SAME KEY As stated above, using the same key for handshake and application traffic precludes certain types of proof. However, this is not to say that either it is insecure to use the same key or that no proof is possible. Specifically: - Using the same key is not an obstacle for symbolic proof methodologies. - In particular, if one is willing to restrict the proof of the handshake to the original handshake messages, then TLS 1.3 still provides key separation. - Hugo Krawczyk has a forthcoming paper which demonstrates the security of the current keying model using cryptographic techniques in a “secure channels” model. Also, the miTLS proof of TLS 1.3 does not rely on separation, as it considers the record protocol together with the handshake. Nevertheless, there was broad and strong agreement at TRON that key separation considerably simplifies cryptographic proofs in the computational model by enabling modular analysis of handshake encryption and the record protocol. The motivation for switching keys from handshake to application traffic is somewhat undermined by late handshake messages being encrypted under the application traffic key. This can be viewed as a design compromise that breaks the separation principle for post-handshake messages while still incurring some of the overhead of separate keys in the handshake. PUBLIC CONTENT TYPES Clearly, having a public content type and separate keys for handshake and application data provides full key separation, at the cost of revealing whether a given record is handshake or application data (and potentially alerts). The major question that the group had was whether it was actually possible to conceal this information effectively, even with encrypted content types, since hiding the handshake messages in the application traffic requires detailed knowledge about the application traffic pattern (e.g., packet lengths, timing, response patterns, etc.). It’s clear some analysis of this is needed. In addition, changing to public content types would potentially necessitate changes to the packet format: the current record design uses the fact that the content type is nonzero to overload it as a padding delimiter, and if we were to add a public content type, we would either need to duplicate the content type in both locations or remove the inner content type and find some new way to make the padding unambiguous. Note that because we already have a dummy content type, even having two copies would not make the packet longer currently, though we are hoping to eventually remove the external content type, in which case we might end up having the record not shrink by as much as one might like [0]. [0] There are probably designs that would actually let us keep the minimal packet size if we were willing to break the format on the wire. One potential design would be to retain the inner encrypted content type but rob a bit from the length (which currently has the first bit always set to low) to indicate which key is in use.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
