Thanks for the feedback, John. I filed issues on the GitHub draft
located at [1]. Please see inline below for comments.
On 1 Apr 2019, at 12:00, John Mattsson wrote:
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.
Indeed, that was the intent.
- ”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.
You’re correct that this requires both endpoints to adopt the change
simultaneously. However, that does not contradict the quoted text, which
states that the protocol is not changed.
- “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...
Yes, this is a tradeoff we made by opting to not modify the key
schedule.
- 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.
We probably could, though since the labels are subject to change (see
the TODO about possibly including the HashAlgorithm in the label), we
kept it as is.
- “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”
Good suggestion! We’ll fix it.
- “importing external PSK (Pre-Shared Key) into TLS.”
Not sure if “into” is the right word, I think “for” as in th e
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.
Ditto.
- “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?
We’re just covering our bases here. I tend to agree that the focus
should be on updating to TLS 1.3 instead of “patching” TLS 1.2
stacks.
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.
Modifying the key schedule was discussed in the context of [2]. At the
time, it seemed the desire to not touch the key schedule outweighed the
desire to not inflate the ClientHello.
Best,
Chris
[1] https://github.com/chris-wood/draft-wood-tls-external-psk-importer
[2] https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
