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

Christopher Wood <caw@heapingbits.net> Tue, 19 May 2020 16:24 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 0D3603A0ACF for <tls@ietfa.amsl.com>; Tue, 19 May 2020 09:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=KCJ+b7LI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hHRY/Oql
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 5WDBohrb1k1F for <tls@ietfa.amsl.com>; Tue, 19 May 2020 09:24:10 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CAD3A0ACC for <TLS@ietf.org>; Tue, 19 May 2020 09:24:10 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8E1A37A7; Tue, 19 May 2020 12:24:09 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 19 May 2020 12:24:09 -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=AeBn2baMMeuE7tJJhMBdRNAx24SMd95 w4Osc+8q7Zfs=; b=KCJ+b7LI9IftjCLdztQjVyRqkITNA1q0nHZ9MB3TGLcUIxC Y1xkF8bpJchHhvqMUQFeBWUoo1Ol4Bz4l7e5WRpeYQhU1wyyPGcNS+Hqnw1g+DDw YBVMrYoPjzcte+1/o6MLQTVrtJBBpNOkurHP+oHyHfifg6/fS1IAQzcDM5ORYdfK +AIeBCNsSaG28dRFZGMNzpDAP89oh6j51CGbmJgDEsBsbqU0IPUQBCTw34aI9r+1 U4wD3ot+Csh9vu+PGYHmQTrAn4qmTxCNMRM/Zt+F4OT3xkU/1HG97Nu1zhmkNsLF E3Oxyf2yF0tf2JnlD8+lOtcAv2xBQYHMJc4bd2w==
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=AeBn2b aMMeuE7tJJhMBdRNAx24SMd95w4Osc+8q7Zfs=; b=hHRY/Oql27psRat78h+8CE lXkcgzEYHVHH9nQtargtWduLk4V+k4RVo80JDxt4Znur+hsn35ly2Mn1L+xG9cv3 AtpTtssrnsGf/Ot0R4wzyysqUuD3e3pJVHMZx9Vjk+9Y58S7OpOHxVqyoKV2q0ev bw9M+hzHgS+oh7IxOAow7WZszQUQ1fldR6bLoCMblQmnBXi8a9bcKo5PfXvUoMCa cUuYXKAl3peIP2XX1J7vFjs97iqzqaX5GAw5jc00XTVYdd89eDerYPv7tF52GLAT uGv1XHaFI0vBwM3rX1GLYqQS1Mldi7DIecCpKXhJWZNfgs7W4CzMRP3y4Z422xRg ==
X-ME-Sender: <xms:KAjEXtiVXFX1VBT4kxJNZr2jqkbNwfGToQWZPhczhOaExGmRk7f1JA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtjedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepveekgedtgfdtjefhteeifeejhfdtgfdufedufeeljeeu vdejtdfhvefgvefgvedtnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhi nhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:KAjEXiD5IUJxOSPI0GqFoirkqQXCW1HZ4hGmKw6UnMcYi4qFHD0l2A> <xmx:KAjEXtEqKg922YoYp_xMXqmHjSyNBpTeG7fqNe7ZSdZAdViHZMWaAQ> <xmx:KAjEXiRt-1JdHwbyWt0IERaMFVcUJsW0UbcBx31h7r4dhePQ-VPtoA> <xmx:KQjEXp_jiN4Xd5JnDmYQA33KzyOOziiK_dsI-SoA3yMthcwUNZ32Cg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AFDAF3C00A1; Tue, 19 May 2020 12:24:08 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-464-g810d66a-fmstable-20200518v1
Mime-Version: 1.0
Message-Id: <c5e10555-8096-4156-84c5-53235016d223@www.fastmail.com>
In-Reply-To: <f61e7163478d49a9a0a92a8da38cb226@verisign.com>
References: <fb7c3f894dfa49efb5917d2e39c4ea78@verisign.com> <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com> <acd71cd2e3b7412aafc98595161bfb1d@verisign.com> <8fd481c1-7edb-4d9c-bc6d-f1a3f67e8bcf@www.fastmail.com> <f61e7163478d49a9a0a92a8da38cb226@verisign.com>
Date: Tue, 19 May 2020 09:23:34 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "TLS@ietf.org" <TLS@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ohA3VIvGPoveXm5kb1qVqv9UXB4>
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: Tue, 19 May 2020 16:24:12 -0000

We chatted offline and updated the draft to refine some points:

   https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/36

Thanks for helping improving the document!

Best,
Chris

On Mon, Apr 27, 2020, at 7:08 AM, Hollenbeck, Scott wrote:
> > -----Original Message-----
> > From: Christopher Wood <caw@heapingbits.net>
> > Sent: Friday, April 24, 2020 7:09 PM
> > To: Hollenbeck, Scott <shollenbeck@verisign.com>; TLS@ietf.org
> > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-
> > importer-04
> 
> [snip]
> 
> > > > 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!
> > >
> > > Agree with that as the goal.  Here's our concern in brief.  If our
> > > understanding is correct, prior to this draft, the client could use an
> > > EPSK k in two ways:
> > >
> > > * as input to the TLS 1.2 PRF (based on any hash function)
> > > * as input to the TLS 1.3 key schedule via HKDF-extract (based on a
> > > single hash function)
> > >
> > > Following this draft, the client could use k in two ways:
> > >
> > > * as input to the TLS 1.2 PRF (based on any hash function) [same as
> > > before]
> > > * as input to the importer function via HKDF-extract (based on a
> > > single hash function)
> > >
> > > So there is still a potential cryptographic overlap in the use of k
> > > between TLS 1.2 and TLS 1.3.  The imported keys don't have this
> > > overlap, because they're separated from one another and from the
> > > underlying EPSK through the use of the importer function.  But doesn't
> > > the security proof for k still need to take into account that the
> > > input to HKDF-extract might also be input to the TLS 1.2 PRF (with the
> > > same or a different hash function)?
> > >
> > > In other words, if it was a problem for the security proof that k
> > > could be input to the PRF and to HKDF-extract before the draft, isn't
> > > it still a problem afterwards?  The conclusion that there are no
> > > cross-protocol collisions depends on the specifics of the TLS 1.2 PRF
> > > and how it's used, compared to HKDF-extract.
> > >
> > > We're not suggesting there is any attack here, just trying to
> > > understand the design actually addresses the statement in the
> > > introduction that k "could possibly be re-used in two different
> > > contexts with the same hash functions during key derivation".
> > 
> > For lack of a better way to describe this (sorry!), we're trying to avoid this
> > input collision during the key derivation process of a TLS connection. As the
> > importer happens before a connection, and can be viewed as part of the
> > provisioning process that produces unique PSKs for each target hash
> > function, we achieve the goal for TLS 1.3 of not re-using a PSK with different
> > hash functions.
> > 
> > I'm not sure how to better clarify that right now, so suggestions are very
> > much welcome.
> 
> We're okay with the arguments in the draft that the design preserves 
> security proofs when the same EPSK is used to produce internal PSKs 
> associated with different hash functions within TLS 1.3 only. However, 
> it isn't clear enough to us how the design preserves security proofs 
> when the same EPSK is used with both TLS 1.2 and TLS 1.3.  I don't yet 
> have any text to suggest, because we're not sure we understand the 
> rationale. What is the rationale for the design in that situation?
> 
> Scott
>