At the bottom of page 136, the current draft says: Note: TLS does not currently permit the server to send a certificate_request message in non-certificate-based handshakes (e.g., PSK). If this restriction were to be relaxed in future, the client's signature would not cover the server's certificate directly. However, if the PSK was established through a NewSessionTicket, the client's signature would transitively cover the server's certificate through the PSK binder. [PSK-FINISHED] describes a concrete attack on constructions that do not bind to the server's certificate (see also [Kraw16]). It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/ key-id pair with two different endpoints. Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server.
[PSK-FINISHED] tells why it is not safe to do client authentication after resumption. [Kraw16] says two things: (1) using a PSK from a previous handshake and adding client authentication is not secure; and (2)does not work; and the client signature must cover the public key. So, the final sentence in the quoted paragraph seems to be too broad. I do not see why we forbid an external PSK and certificate-based authentication in an initial handshake. I acknowledge that TLS 1.3 does not support it, but I have been expecting an extension to be specified to do just that once the TLS 1.3 base specification is finished. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
