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

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 21 September 2016 20:00 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 E19C312B82F for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 13:00:29 -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 lg8VbLO8vasD for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 13:00:27 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6B12B434 for <tls@ietf.org>; Wed, 21 Sep 2016 13:00:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E3FCA13008; Wed, 21 Sep 2016 23:00:25 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id w56PojcFkMGx; Wed, 21 Sep 2016 23:00:25 +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-smtp1.welho.com (Postfix) with ESMTPSA id A5D5DC4; Wed, 21 Sep 2016 23:00:25 +0300 (EEST)
Date: Wed, 21 Sep 2016 23:00:22 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: David Woodhouse <dwmw2@infradead.org>
Message-ID: <20160921200022.GA14520@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1474485375.24595.250.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/3NfHmbSLOMTi7M_zffLJX21l43Y>
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:00:30 -0000

On Wed, Sep 21, 2016 at 08:16:15PM +0100, David Woodhouse wrote:
> On Wed, 2016-09-21 at 17:46 +0000, Raja ashok wrote:
> 
> > [ashok] : I feel sending the selected ID is better, otherwise while
> > process "server hello" msg, client has to maintain the PSK ID list in
> > the same order in which it sent. Already there was a discussion in
> > TLS1.3 group for sending selected ID instead of index. 
> 
> There is also discussion of supporting only a *single* PSK identity in
> TLSv1.3. If that happens, is there a real need for the extension to
> permit more than one identity in TLS <= 1.2. 

Is the intended usecase some "IoT"/"embedded" devices? If so, I think
this is *extremely* bad idea.

Those things tend to have very long lifespans, so one shouldn't put
one out except with cutting-edge stuff. Anything less, and there is
substantial risk of it going bad during lifetime.

It would be possible to retrofit an extension to do multiple identites
at once into TLS 1.3 even if baseline TLS 1.3 allows only one, altough
implementing it probably will not be pleasant.[1]

Also, has anyone done security analysis of doing PSK negotiation that
way in TLS 1.2 (someone has clearly done that for TLS 1.3, given
some of the attacks posted)...


[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).



-Ilari