Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01

"Christopher Wood" <caw@heapingbits.net> Thu, 04 April 2019 13:00 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A111204D4 for <tls@ietfa.amsl.com>; Thu, 4 Apr 2019 06:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FROM_FMBLA_NEWDOM=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=wuHtQ5K2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z2wnagmL
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzj7IGp_KiEV for <tls@ietfa.amsl.com>; Thu, 4 Apr 2019 06:00:52 -0700 (PDT)
Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291071204ED for <TLS@ietf.org>; Thu, 4 Apr 2019 06:00:51 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 934F0FF57; Thu, 4 Apr 2019 09:00:48 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 04 Apr 2019 09:00:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=+ARHYNV4VO1daGliqqNfw5OnQSg8 bt9/eD/gBG46EF4=; b=wuHtQ5K2E6vSVl1kscKsIgQ6hi0A+MxgKU/o+23BFmNR 3HDO5jebmWSMdG6M0T0xh3eeVjztFA38Ipr6spNmpPhuwWRGdHO7Wxuw5yf4dc+e 4BTz6P78187in/zapsLCsIMqR96nGzeHQHiWKz6loUkQyUIsrrnzFyfcxS8CXGTq 2/DOWyctGVW6dMYfQlKy+zGmbFJvwboqMGg131/qbJE9+mV77W7kMfP1zSWEM12V nda6mZKSaV4tgswow5rC62XYM7UwXTsFj28gR3OHm+iStDUwTOcWaOIlrk1x+iuv q6BJ7WAh3zzkTafU6/QvlahHoeTRUHWs88wmpCDR2g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+ARHYN V4VO1daGliqqNfw5OnQSg8bt9/eD/gBG46EF4=; b=z2wnagmLvjhryuejyc2+0s izZ5i4rsQ31tkypjvPRz2to70J3TPg+DaXtikfZXq0Om2RxXf0QYqvzIxXQrCesZ pq/Wgmo9zLhXe5plCwz70PwQ013y+tm6uxRIy3ZtGF9JxgTtvmHbPAUYf+7EEOwV a6qjf9UhbATSnUBQ0uXWsYKGfypZymj+5DBW2ixB1LpwrWGf+df91uIcmBPmtWMp MVDJXTcbRmpA8jmzVW/yyNEX1bJ4KVHnfwCgTaHiim1h/YkuwFhaBZRQdbbNCbF6 7ycW/Thga8734SmGHypuM9d0mu4zd2+VUO3dCKTINn7xFUWdL/9EOAL4I5eHTO4A ==
X-ME-Sender: <xms:_v-lXEt4q-e5DPxDoIBKRStS-idQROTUPPwGERKuzWuBaUxcAxTxHQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdehgdehkeculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreej necuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrph hinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgv rghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:_v-lXCIBMdBBuOHCIcLEb4hxc92QjWrpxwAS74v1u1YI3NIFFNmviA> <xmx:_v-lXETZCpYcLNA0y5Y4p-VvrBNIqB76QHeloL7_UrrOQEVcJMH8gA> <xmx:_v-lXHsj1PZl1IrEhAR9_eHpFgCrzEv9hhGnSS-Bv_ix4Ud9lFKkeg> <xmx:__-lXD6IWxY08BPNG3X4nSWFYvwuC_Pzfcx9kHtb2vGI3wbiv7FHg7s0QEc>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A3062602F; Thu, 4 Apr 2019 09:00:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 94902928
Message-Id: <e5518e68-d264-44b0-99e1-7d38a86e0560@www.fastmail.com>
In-Reply-To: <E98C5FE0-324D-4A92-AC3B-2219A0E26BC3@ericsson.com>
References: <89127FF7-CE3F-4DF1-98A5-B1006C5FF56B@ericsson.com> <CC00A43F-4E77-4E13-8DB2-9BF221784673@heapingbits.net> <E98C5FE0-324D-4A92-AC3B-2219A0E26BC3@ericsson.com>
Date: Thu, 04 Apr 2019 09:00:45 -0400
From: Christopher Wood <caw@heapingbits.net>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: "TLS@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="843e2817e4cb4bdd8c3654245d697589"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/kK9CqYvH9nEe425xIXfcawaj_K8>
Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 13:00:56 -0000


On Wed, Apr 3, 2019, at 11:22 PM, John Mattsson wrote:
> Hi Christopher,
> 
> Thanks for the clarifications.
> 
> >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.
> 
> I think "this requires both endpoints to adopt the change simultaneously" is a problem as it makes it impossible to introduce this mechanism in many existing deployments. I would expect a solution that can be introduced gradually (some nodes at a time) in existing deployments supporting RFC 8446 and/or RFC 5246.

I think perhaps my response was unclear. In your scenario, adding key import support is essentially the same as adding a new PSK to a node. Some nodes may offer (or accept) the PSK, while others do not. Successful use of an imported PSK will only occur if both endpoints have imported the same PSK. Gradual deployment is possible.

> 
> But, if you want to change the behaviour of the using the same external PSK in both TLS 1.2 and TLS 1.3 as allowed by RFC 8446, a solution not requiring "simultaneous change" is probably not possible.
> 
> The requirement that "this requires both endpoints to adopt the change simultaneously" should probably be highlighted in the document.
> 
> The current mechanism does not seem to be deployable for e.g. 3GPP until TLS 1.4 is introduced, and then only for TLS 1.4 and later... on the other hand, being limited to SHA-256 for PSK may be ok for 3GPP. (and 3GPP could just derive a Separate SHA-384 PSK if needed).
> 
> Some more comment:
> 
> - Which label should be used by various versions of DTLS?

Likely the same labels as the TLS counterparts, since the label more or less specifies the *handshake* variant.

> 
> - "If a client or server wish to deprecate a hash function and no longer
> use it for TLS 1.3, they may remove this hash function from the set
> of hashes used during while importing keys. This does not affect the
> KDF operation used to derive concrete PSKs."
> 
> If someone deprecates the use of a hash function inside TLS 1.3 (used by Transcript-Hash and HKDF), does it then makes sense to keep deriving keys outside of TLS with that same deprecated hash function?

No. If this deprecation occurs, then they would follow the advisory text and not use the old hash when importing keys.

> 
> - "To mitigate these problems, external PSKs can be bound to a specific hash function when used in TLS 1.3"
> 
> I would change to "are bound to a specific". If the application does not specify anything, the keys are bound to SHA-256.

Works for me. I’ll file an issue to track the change.

Thanks,
Chris 

> 
> Cheers,
> John
> 
>  -----Original Message-----
> From: Christopher Wood <caw@heapingbits.net>
> Date: Wednesday, 3 April 2019 at 16:25
> To: John Mattsson <john.mattsson@ericsson.com>
> Cc: "TLS@ietf.org" <TLS@ietf.org>
> Subject: Re: [TLS] Comments on draft-wood-tls-external-psk-importer-01
> 
>  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
> 
> 
>