Re: [TLS] Universal PSKs

Hubert Kario <hkario@redhat.com> Mon, 18 June 2018 11:22 UTC

Return-Path: <hkario@redhat.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 7D5F8130E96 for <tls@ietfa.amsl.com>; Mon, 18 Jun 2018 04:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 5rV7Q_Rr7f27 for <tls@ietfa.amsl.com>; Mon, 18 Jun 2018 04:22:12 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F01D124BE5 for <tls@ietf.org>; Mon, 18 Jun 2018 04:22:12 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9045F7DAC3; Mon, 18 Jun 2018 11:22:11 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1DFEF2026D68; Mon, 18 Jun 2018 11:22:10 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Date: Mon, 18 Jun 2018 13:22:04 +0200
Message-ID: <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com>
In-Reply-To: <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com>
References: <CAF8qwaB3GH8WbXD=snEwjA==Jx02gtWejyNTXXO6nVW0Cp1YHA@mail.gmail.com> <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2571722.glvm2Kta8V"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 18 Jun 2018 11:22:11 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 18 Jun 2018 11:22:11 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/paDl6y-sses7n4HobVSouTm58JQ>
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: Mon, 18 Jun 2018 11:22:20 -0000

On Friday, 15 June 2018 16:24:58 CEST 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?

I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after the 
release TLS 1.3, even if you consider it small fragmentation.

Correct solution was to include it in the TLS 1.3 proper.

Now we have a TLS 1.3 draft which says:

   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 below).  If this
   value is not present or does not validate, the server MUST abort the
   handshake. 

and a proposed change to it that doesn't say anything about differentiating 
between universal binders and regular binders. And forces those new binders to 
SHA-256 where previously it was selectable.

So, either it is a severe issue and we should rework TLS 1.3 draft, or this 
draft needs to be significantly reworked before it will not cause huge 
interoperability headaches – signalling extension is the bare minimum, most 
likely a new PSK extension is necessary.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic