I brought up an alternate construction in BKK for draft-wood-tls-external-psk-importer-00 which might have some potentially better properties. I didn't get time to explain then, so here it is:
One issue I think with the current construction in the draft with external psk is that if the client uses the external psk with a different hash function due to configuration error, then it turns into a fatal connection error because TLS endpoints are required to tear down the connections on binder mismatch. The client does not recover until it stops using the external psk.. An alternate approach to solve this could be to have a construction like: [hash of (psk identity + ImportedIdentity)] [psk identity] A server that uses the psk would perform the following steps during the resumption 1. Negotiate the cipher suite to use 2. If an external psk is used, strip off the first hash length of the psk identity where the hash length depends on the cipher suite. 3. Compute the hash of pskidentity + imported identity and compare it against (2) 4. If it doesn't match, don't use the PSK and fallback to full handshake.. I think this a subtle change, because if you treat this case as if you were not willing to use the PSK, then you can ignore the binder. This might be operationally easier to deploy and reason about than a hard failure. Subodh
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
