On Mon, Feb 13, 2017 at 12:32:53PM +0000, Cas Cremers wrote: > > The main takeaway is that the client never really receives any > acknowledgement of whether the verification provided was successful or > rejected through an in-band mechanism. > > The context of the keys does not include the client’s authentication status > (nor the client’s certificate), and is the same in both cases. From a > formal analysis point of view, this results in a mismatch where the client > and server may not agree on the mutual authentication status, which is the > main point we wanted to raise.
It is not just problem of "context of keys". TLS 1.3 explicitly allows silently rejecting client authentication. No fatal error, no NAK, no nothing. Which impiles that client and server can disagree even about status of in-handshake authentication. Including in resumption, even if the RMS supposedly includes client's authentication status in its context. This problem actually cuts protocol layers, and that's why it is so hard. And things get even more fun when resumption is involved. I expect there will be quite a bit of implementations that won't trigger any errors if EE key can be parsed and the client signature verified (due to layering rendering that way pretty natural). > Assuming now that the key context will not be changed, we suggest to > explicitly mention in the security guarantees section that the client, > after sending authentication messages, cannot be sure at any point that the > server has received these messages and considers the connection to be > mutually authenticated. If the client wishes to obtain such a guarantee, it > has to be informed by the server’s application. See above why changing "context" won't fix the problem. And yeah, "if you want to be sure, ask application layer" is probably about the best that can be done. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
