Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04

Christopher Wood <caw@heapingbits.net> Wed, 22 April 2020 01:56 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 0D4473A0A74 for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 18:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, 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=N9bEfNSI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fyfj/6a+
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 e-SeFU9HFSjw for <tls@ietfa.amsl.com>; Tue, 21 Apr 2020 18:56:57 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224813A0A73 for <TLS@ietf.org>; Tue, 21 Apr 2020 18:56:57 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6039A77F for <TLS@ietf.org>; Tue, 21 Apr 2020 21:56:56 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 21:56:56 -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 :subject:content-type; s=fm1; bh=mAzWWQ/iEXRw0CcpYsIrU+NopJ1GuB7 zA83bdREozBQ=; b=N9bEfNSIuL2pRuVOcdIBfYJT+sKQuR0UQzr5eMsrZtjVwJe we3AS8tXAMNr11isOdP8+L+pQTJzJYhl7Nswgjg93REmF0kmXBnK6azCOOaQeL9o MECRTF8wM3INOWNwI5HJef2qjqMYRD0Pz66lT2ciK/ZcAVbhQYPOfnhUbDa6+iW4 67Vo/f4wGwOyotoz2YQwsr4gZWK6poQZQIhc3530DRPxFtl51p+FTIJNYWHdqh6t LnCqIE8S3W2Ot5AuFVoVWsYOgcr5YlB4tncksZTwB2EjW7CeOPS51XAXPviN6dOm fud3xgZfch0kBw+yLfqV57cWSC/lXb+hDTTW/Lg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=mAzWWQ /iEXRw0CcpYsIrU+NopJ1GuB7zA83bdREozBQ=; b=fyfj/6a+J0MDD7i30yCN8Q /OcfumqUhPaUdK8BJ6ktoGTQOYGcszVQy5pM745Y5hiD/FoLwLsL4m8ARYfxDrAy 6hOxYy0t8Loar/pQ0slHwCidGFVdp7Z+XAE2gIOc34d1etQRGQBLFOJEbUYBCy3N CFlepSEeRIoBwl52rHHBi5B/KbEiVmgGxjSLSe5vNiBwtWPmWr21U7pN7O2BAqWo 50W1/UgsvM9XxFBsCfTlaRpQWeDUkKSt+hi5voGDvxyF0GZoKAkekWerZbCqnrqO DxB8oY7afzCvW75xc+DisLG/4kiIM7nvM+peKbLKGblPCO95gI5T5IcatABnocPw ==
X-ME-Sender: <xms:Z6SfXuh1n2NrNTVf2yvfOTOF_HMahywlmrjgaWDREFvKJxqB3wav0w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeeigdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgif sehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:Z6SfXhVIrS3RN6_1W3HvDpv2oNLxJDfMGiG2Goumo-Dw2-bTxrlGpA> <xmx:Z6SfXkzsuecoJYMqWgC5Vk7oNBNxtiMfhh3bPIL4FPM2hxHQRSYEVg> <xmx:Z6SfXkP6suv98ILZmvBQ-FfR_w4FMd8gWdpFkjCeRONfJguM4CKIiQ> <xmx:Z6SfXk6SRf1B0oFltJJ6ZXSSMw1UgqRn9r7sABWfHsBNC8NGITbMFw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D1B1180093; Tue, 21 Apr 2020 21:56:55 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com>
In-Reply-To: <fb7c3f894dfa49efb5917d2e39c4ea78@verisign.com>
References: <fb7c3f894dfa49efb5917d2e39c4ea78@verisign.com>
Date: Tue, 21 Apr 2020 18:56:35 -0700
From: Christopher Wood <caw@heapingbits.net>
To: "TLS@ietf.org" <TLS@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hnBGgbiPbddAfGy2wt9pCMTSRg8>
Subject: Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04
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: Wed, 22 Apr 2020 01:56:59 -0000

Thanks for the feedback, Scott! Please see inline below.

On Tue, Apr 21, 2020, at 6:57 AM, Hollenbeck, Scott wrote:
> 2. Technical comments. 
> 
> a. Distinct identities?  Sec. 3 states "Non-imported and imported PSKs 
> are distinct since their identities are different on the wire."  We 
> have two concerns about this statement.  First, the statement appears 
> to suggest that if two EPSKs have different identities, then they must 
> have different secret values.  But couldn't two EPSKs have the same 
> secret value yet employ different identities for convenience?  For 
> example, an endpoint might identify the same EPSK with a domain name in 
> some cases and with an IP address in others.  

This seems like a reasonable editorial improvement to make. I filed:

   https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/31

> Second, and more 
> fundamentally, the statement assumes that a non-imported EPSK, by 
> definition, cannot be misinterpreted as an imported PSK.  But isn't the 
> identifier of a non-imported EPSK just an opaque string?  A 
> non-imported EPSK identity could therefore have the same "bits on the 
> wire" as an IPSK identity, if the client and server employ an 
> identifier system that whose encoding happens to coincide with the 
> ImportedIdentity structure defined in the draft.  (
>  Moreover, the identifier of a resumption PSK is just an opaque string 
> -- so couldn't this also collide with ImportedIdentity values?  Perhaps 
> we are missing something even more fundamental in our reading.)  
> ([draft-dt-tls-external-psk-guidance-01] covers similar issues in its 
> Sec. 6.1.2, "PSK Identity Collisions.")

Yes, certainly it's possible for a non-imported EPSK to have an identity which matches the constructed identity of an imported PSK. We can't do anything to prevent applications from crafting such identities, so I'm inclined to just note this as a possibility, if anything. 
 
> b. Attack impact.  If it's possible for an opaque identifier for a 
> non-imported EPSK identity to have the same encoding as an 
> ImportedIdentity value, then how does the server recognize 
> unambiguously that the opaque identifier is intended to be an imported 
> identity?  The server could take an optimistic approach and assume that 
> an identifier that meets the ImportedIdentity syntax is probably an 
> imported identity, and run the code path for imported identities first. 

Yep, that's what I envisioned servers would do.

>  If that path fails, however -- either because the server doesn't 
> accept the EPSK or associated parameters, or because the binder value 
> is incorrect -- then the server may need to run the code path for 
> non-imported identities as a fallback, checking next to see if the 
> opaque string is recognized as an ordinary EPSK identity.  But this 
> practice just puts more burden on a server against an attacker who 
> replays (or makes up) the PSKIdentity.identity value:  two code paths 
> are exercised for the price of one attempted handshake. 

I don't think this is a particularly useful attack, though I do agree that it causes more work for the server. I'm curious to hear what others think. 

> c.  Mitigations.  One way to reduce the burden is to impose a new 
> requirement that the opaque string can only have the ImportedIdentity 
> syntax if the client (or server in the case of hints) indeed intends to 
> use the import mechanism. An ordinary EPSK could have any other value, 
> just not this kind.  But this may not be compatible with the installed 
> base, especially with implementations that allow clients and servers to 
> specify arbitrary EPSK identities. (Consider the case where an 
> application adopts the imported identity syntax for the use intended in 
> this draft, and then decides to reuse the syntax for other purposes, 
> including ordinary EPSK identities.)  
> 
> Another way to ensure distinctness is to add a flag that indicates that 
> the PSK identity is an imported identity. But it's not clear where this 
> flag would go, given that the PskIdentity syntax isn't extensible.  
> Perhaps there could be an overall flag indicating that _all PSK 
> identities are imported identities? Or a new extension for imported 
> PSKs?

Since this draft is meant to fix an annoyance in TLS 1.3, I think anything more than a different Identity encoding is overkill. I absolutely agree that the rigidity of PskIdentity is something we might want to fix. I'm just not sure that should be done here.

> d.  Key separation.  Note that the foregoing discussion about EPSK 
> identifiers potentially colliding is separate from the question about 
> what happens if an IPSK happens to collide with a non-imported EPSK.  
> The draft handles this effectively with different inputs to the binder 
> derivation ("ext binder" vs. "imp binder").  But this happens after the 
> implementation has already decided whether to interpret the identifier 
> as external or imported. 
> 
> e.  Incremental deployment.  Section 6 states that " the derived PSK 
> will not be the same [as the underlying EPSK] since the importer 
> differentiates the PSK via the identity, target protocol and target key 
> KDF."  However, the next statement does not follow directly:  "Thus, 
> PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and 
> thereby avoid cross-protocol collisions."  Rather, the statement also 
> depends on the requirement in Section 3 that clients (and servers) 
> don't deliberately use EPSKs or IPSKs for other purposes, and the 
> security properties of the KDF that produces the IPSK (which ensures 
> that collisions don't occur accidentally).   But there also seems to be 
> an implication in Section 6 that the use of the KDF in the TLS 1.3 
> importer doesn't conflict with the cryptographic functions used for 
> obtaining the TLS 1.2 pre-master secret.  If so, this distinction 
> should be spelled out.

Hmm, not quite. The statement intends to say that if you need EPSK k into an importer and into TLS 1.2 then the resulting keys used in TLS 1.3 and 1.2 are different. I'm not sure further clarification is needed, though I'm happy to review suggestions if you have them!

> Related to this, where Section 3 states, "Clients which import external 
> keys MUST NOT use either the external keys or the derived keys for any 
> other purpose," should "Clients" be "Clients and servers" or simply 
> "Endpoints"?

Yep, that's a good editorial improvement. I filed this issue to track it:

   https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/30

Thanks again for your review and feedback!

Best,
Chris