Re: [TLS] Universal PSKs

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 20 June 2018 10: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 1CD0D130DEB for <tls@ietfa.amsl.com>; Wed, 20 Jun 2018 03:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 pbe_kXNhM1Nw for <tls@ietfa.amsl.com>; Wed, 20 Jun 2018 03:00:15 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D7C130DD0 for <tls@ietf.org>; Wed, 20 Jun 2018 03:00:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id F3A8B4EF6E; Wed, 20 Jun 2018 13:00:13 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id fs9nOgkpg79o; Wed, 20 Jun 2018 13:00:13 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4CFF772; Wed, 20 Jun 2018 13:00:11 +0300 (EEST)
Date: Wed, 20 Jun 2018 12:59:56 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180620095956.GB23612@LK-Perkele-VII>
References: <CAF8qwaB3GH8WbXD=snEwjA==Jx02gtWejyNTXXO6nVW0Cp1YHA@mail.gmail.com> <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <3a8d1eab6bbf042c396da1085427f49da8d4c2f4.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <3a8d1eab6bbf042c396da1085427f49da8d4c2f4.camel@redhat.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BRU5vwrpZKWXs764rsIlEgnLphU>
Subject: Re: [TLS] Universal PSKs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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, 20 Jun 2018 10:00:18 -0000

On Mon, Jun 18, 2018 at 11:47:25AM +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2018-06-15 at 14:24 +0000, Salz, Rich wrote:
> > >    that's not workable.
> > 
> >   
> > It's not great, however
> >   
> > >    the reason why implementations chose to use old API to provision
> > > TLS 1.3 PSKs 
> > 
> >     was to make the upgrade process as smooth as possible, disabling
> > TLS 1.3 is 
> >     quite antithetical to that
> >   
> > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect
> > most uses, and seems the only way forward.
> > 
> > Do you have an alternative solution?
> 
> TLS 1.3 provides a solution. These secrets under TLS1.3 are restricted
> to using the SHA256 PRF. That's how we have implemented it in gnutls.

One thing to be careful with here is interoperability. In fact, with
using PSKs across protocol versions and hashes in all sorts of ways the
specifications say they should not, that is the prinicpal worry I have,
above security implications.

Specifically, one has PSK usable for TLS 1.2 and 1.3: Is that PSK the
same for both protocols or is there something like universal-PSK (which
causes the effective PSK not to be the same) going on?


I tried to cook up attacks against using PSKs across protocol versions
and and hashes. Everything I could come up with stopped at literially
the first hash encountered, unless at least one of:

- The hash has some pathological properties.
- The hash has some other properties that cast serious doubt on
  its security.
- The hash is outright broken (which breaks TLS 1.2 and TLS 1.3
  anyway).
- The ciphersuite on TLS 1.2 side uses non-conventional PRF.
- PSK has insufficient entropy and is vulernable to brute-force.


Of course, formally proving anything like this is extremely hard at
best, and most probably impossible (the pathological hashes alone would
already cause extreme trouble, or outright block any proof). And given
the usefulness of proofs in finding various (subtle) mistakes, there
could still be severe problems.



-Ilari