Martin: > > This seems like a welcome addition. I'm not sure why you think that > PQ needs are a good motivation for this work though. Managing > external PSKs is so unwieldy that it almost seems like this would do > more harm than good in that regard. I find this more interesting from > the perspective of providing continuing proof of possession for keys > while also permitting the use of 0-RTT (and session continuation more > generally).
The key management would be pretty onerous if a different external PSK is distributed to each client-server pair. I was pretty careful to make sure that the key schedule would work out even if the external PSK is know to a group of clients and a group of servers because the (EC)DHE key will be pairwise. If the external PSK is not pairwise, I do not think it can be used for 0-RTT traffic, which is why the I-D does not allow early data. > FWIW, I don't see any reason that this approach would be a problem > given that it is additive, the problem that Sam Scott et. al. from > before was a result of important contextual information being omitted > from the transcript. I did not see a problem, but we should make sure that there is not something subtle. > Why didn't you consider a new codepoint on psk_key_exchange_modes that > permits/requires use of the certificate? The purpose of that > extension is to signal that a) you want PSK, and b) what additional > things are permitted alongside that PSK. Because of this text in the TLS 1.3 base specification: ... Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension. That steered me toward an additional extension. > It's not clear from your text on client certificate authentication > whether your mode permits the server to omit its Certificate, but then > send CertificateRequest. You should clarify that one way or other. That was intended by: When the "tls_cert_with_extern_psk" extension is successfully negotiated, authentication of the server depends upon the ability to generate a signature that can be validated with the public key in the server's certificate. This is accomplished by the server sending the Certificate and CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 of [I-D.ietf-tls-tls13]. But I see that it should be reworded to include a MUST statement. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
