Hi Russ, I just saw this in the draft:
Thus, a certificate MUST NOT be used with a resumption PSK. I think that this is grounded on an invalid basis: However, TLS 1.3 does not permit an external PSK to be used in the same fashion as a resumption PSK, and this extension does not alter those restrictions. TLS 1.3 is pretty clear that the difference derives primarily from the provenance of a resumption PSK providing additional contextual information: "When PSKs are provisioned out of band, the PSK identity and the KDF hash algorithm to be used with the PSK MUST also be provisioned." In fact, the section on early_data establishes more requirements for 0-RTT: "The parameters for the 0-RTT data (version, symmetric cipher suite, ALPN protocol, etc.) are those associated with the PSK in use. For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK." So I would conclude that the two are in fact able to be used in the same way, even if the two are forcibly distinguished in the key schedule through the use of different labels. On Fri, Mar 2, 2018 at 9:14 AM, Russ Housley <hous...@vigilsec.com> wrote: > 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. That's a consequence of a choice not to make the key exclusive pairwise, not the protocol you describe. If the key meets the usage requirements for 0-RTT, then why prohibit use with 0-RTT? To uplevel a little, if the concern is that the server can be impersonated due to weaknesses in the certificate authentication, you just created a situation where all the entities with the PSK are now a threat to session integrity. That seems like a poor outcome. >> 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. That's unfortunate, but I can see how that works. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
