Hi,
Thanks for trying to solve this problem! Not having a way to use the same
external PSK for different cipher suites is definitely a thing missing from TLS
1.3.
As I stated during the wg session, 3GPP have a few use cases that use PSK-ECDHE
between phone and core network. Contrary to what IETF people sometimes believe,
most 3GPP use of TLS (between phone and core network, between core nodes, and
between different operators) use mutual authentication with certificates.
According to the current 3GPP specification, the phone and the core network
would share an external PSK and an external identity. The hash function is
undefined, i.e. SHA-256 is used for TLS 1.3. The phone and the network would
then negotiate TLS 1.2 with any cipher suite or TLS 1.3 with SHA-256.
Some comments
- The draft should make clear if the External PSK and external identity can be
used together with the imported identities. I assume the idea is that they
can’t but I can’t see any text specifying this.
- ”Imported keys do not require negotiation for use, as a client and
server will not agree upon identities if not imported correctly.
Thus, importers induce no protocol changes with the exception of
expanding the set of PSK identities sent on the wire.”
While I see how the defined mechanism can be deployed in a new deployment, I do
not see how to introduce it in an existing deployment. Assuming that the
external PSK cannot be used together with the imported identities, the TLS
client and server must introduce the mechanism at the same time, that is often
not possible to control.
- “struct {
opaque external_identity<1...2^16-1>;
opaque label<0..2^8-1>;
HashAlgorithm hash;
} ImportedIdentity;
”
This scales poorly, A client has to send n*m identities where n is the number
of supported versions and m is the number of supported hash algorithms...
- Would it not be possible to just use the version number as label? I.e. 0x0304
instead of “tls13”. In that way you do at least not have to define a new labels.
- “TLS 1.3 [RFC8446] supports pre-shared key (PSK) resumption, wherein
PSKs can be established via session tickets from prior connections or
externally via some out-of-band mechanism.”
This seems to indicate that all use of PSK is resumption which is not correct.
I suggest changing to “TLS 1.3 [RFC8446] supports pre-shared key (PSK)
authentication”
- “importing external PSK (Pre-Shared Key) into TLS.”
Not sure if “into” is the right word, I think “for” as in the title is better.
The mechanism seems very much external to TLS itself. I see it as a mechanism
to derive several external PSKs from a single external PSK.
- “Similarly, TLS 1.2 and all prior TLS versions should use "tls12" “
The versions prior to TLS 1.2 will soon be deprecated. And why spend time
updating the TLS 1.2 code base instead of moving to TLS 1.3?
Suggestion:
Instead of deriving a large set of new external PSKs, wouldn’t it be possible
to just use different hash functions in different parts of the key hierarchy?
I.e. if SHA-256 is associated with the external PSK and SHA-384 is the hash
algorithms in the chosen cipher suite:
PSK -> HKDF-Extract(SHA-256) = Early Secret
|
+-----> Derive-Secret(., "ext binder" | "res binder", "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic", ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master", ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
v
(EC)DHE -> HKDF-Extract(SHA-384) = Handshake Secret
Support of this could be signalled with the tls_flags extension. If the server
does not support the extension it must according to RFC 8446 chose a cipher
suite with SHA-256.
Cheers,
John
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
