Re: [TLS] draft-jay-tls-psk-identity-extension-01

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 21 September 2016 20:39 UTC

Return-Path: <ilariliusvaara@welho.com>
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 39CB512B578 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 13:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 xkYKvGUWhDmg for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 13:39:21 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3496712BD71 for <tls@ietf.org>; Wed, 21 Sep 2016 13:39:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 5801910E80; Wed, 21 Sep 2016 23:39:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Oft4Bjzu7xcQ; Wed, 21 Sep 2016 23:39:19 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 122D42310; Wed, 21 Sep 2016 23:39:19 +0300 (EEST)
Date: Wed, 21 Sep 2016 23:39:15 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: David Woodhouse <dwmw2@infradead.org>
Message-ID: <20160921203915.GA14873@LK-Perkele-V2.elisa-laajakaista.fi>
References: <1474098807.2070.10.camel@gmail.com> <1474270465.144982.206.camel@infradead.org> <FDFEA8C9B9B6BD4685DCC959079C81F5E18F6DA9@BLREML509-MBX.china.huawei.com> <1474485375.24595.250.camel@infradead.org> <20160921200022.GA14520@LK-Perkele-V2.elisa-laajakaista.fi> <1474489991.30494.5.camel@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1474489991.30494.5.camel@infradead.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fieiRtiZI8-OmgVQeJAzTjNQZM4>
Cc: "tls@ietf.org" <tls@ietf.org>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>, "jayaraghavendran@gmail.com" <jayaraghavendran@gmail.com>
Subject: Re: [TLS] draft-jay-tls-psk-identity-extension-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Sep 2016 20:39:23 -0000

On Wed, Sep 21, 2016 at 09:33:11PM +0100, David Woodhouse wrote:
> On Wed, 2016-09-21 at 23:00 +0300, Ilari Liusvaara wrote:
> > On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> 
> > [1] E.g. altering hello_finished to be a list, one entry for each
> > identity, or omitting it entierely for "implicit finished with the
> > used 0-RTT key before ServerHello" trick I outlined earlier.
> > 
> > (Neither is probably pleasant to implement... The latter is probably
> > easier if the library architecture is suitable).
> 
> I had also suggested including a hello_finished only for the first
> (preferred) PSK identity. If the server doesn't want that one, it can
> send a HelloRetryRequest with a PreSharedKeyExtension indicating which
> PSK identity it *does* want.
> 
> Or did I miss a reason why that wasn't sufficient and *each*
> ClientHello needed to be validated? I confess I've only been looking at
> this for the last day or so.

Basically, you need the binder (finished) for whatever PSK you actually
wind up using, or you have attacks in some cases.

So it would technically be possible to have multiple PSK identites,
and use HRR to change the one used (followed by client signaling
finished for that one in new ClientHello).


-Ilari