Re: [TLS] Universal PSKs

Jonathan Hoyland <jonathan.hoyland@gmail.com> Mon, 18 June 2018 11:56 UTC

Return-Path: <jonathan.hoyland@gmail.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 EBE3E130EA5 for <tls@ietfa.amsl.com>; Mon, 18 Jun 2018 04:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1VVsYn7ln3eb for <tls@ietfa.amsl.com>; Mon, 18 Jun 2018 04:56:14 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0D6130E96 for <tls@ietf.org>; Mon, 18 Jun 2018 04:56:14 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id z16-v6so10469606uaz.10 for <tls@ietf.org>; Mon, 18 Jun 2018 04:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xim4i6JbvGHULQ6Xyz65HiuwNtVQEneZapTN6Szcjkw=; b=gUaXg190l5hDafjF4Dkdu1+4Vosju2hptCczAa0HClfImc5J1Lcitko57XcWve6yzG GI+oX5gd2LnimjXmKiqbKUMRqbAxy0TxvY468Wg2q8QxkISpyLMQvJd9Y6KK0Vm4/CB7 Fz1RDPRWc+e/7GWg7yW/Oj1dqad/x4baQ3FNI0mLoh+pMxUQHACenlAzmce9tRUt9/d0 hMOHk07Jjl/iELdW2Fkcz84tAvrYHWu2CdXnkJSx5l9nt/uLwXcF5A6IOmjU9NmYpYHT K/D0n1UuaDJGXbWKjMaccZ5yMZ1c7qmQfjHaxuYEFoHb/VKOWOvkjtb3IyJePS/itEjw /adA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xim4i6JbvGHULQ6Xyz65HiuwNtVQEneZapTN6Szcjkw=; b=fPU3/IfbUO9l/CcWiyDlFfppSI2y1pm6i65s7rCbsQzrifoSoAhSbEntrAnLukhC0J ruTgtUcxLgY/+ujzIRM4HMwNo85/vP16asU89LhuVYNl2nq2dh1FW8jFcr2+X0mMPOZp SbuLwvIQZdQolLExbg/eA6n07eoibQ5KOs4DK5ngSaR7L7C5/HmTk1fiAzGeM0kQng2N eIU3+FV1BJ5LqPS6ATOOxktfhEaS6LmCHmV/UIFA2XIHdm+6GKJ4L+6olvGjP4xcGtcZ dDpyP29+H/zoRWrZB0Xx6x5GxCQmHcnarIr7MTBS855UKBiItJcIhE00brKri9YeUj7l Fceg==
X-Gm-Message-State: APt69E3WDClTKpe0wBh4xQW4t2vg1mFqqsQVKPA5aWCAoYLDBRpPzCTM 0AOTkEj+DnXbTmer4U3T0bdUF8peE6+tyScrs/8=
X-Google-Smtp-Source: ADUXVKL3gNM5+abotS070Uf++Py6KuduD9Ajhqym/fhq+gn9WVxjENOwncsbqn0l6bH95MnzW5Y1wM/Tb3Rivrz/mwY=
X-Received: by 2002:ab0:49ce:: with SMTP id f14-v6mr7490146uad.143.1529322973363; Mon, 18 Jun 2018 04:56:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaB3GH8WbXD=snEwjA==Jx02gtWejyNTXXO6nVW0Cp1YHA@mail.gmail.com> <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com>
In-Reply-To: <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Mon, 18 Jun 2018 13:56:01 +0200
Message-ID: <CACykbs0w_N=ZeVPbnamSFKCOP0K9f7Ssn1gObwM5hmSpJPo-Wg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009303dd056ee940f4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CveIVwJMucWLyRTcwJZXSooSBZU>
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:56:18 -0000

The issue with the current draft is that it leaves a single PSK with two
potential interpretations.
If the draft also changed the PSK identity value then each PSK would have a
single interpretation.
If the draft changes the identity then it can also change the PSK key
without having to change the manner in which the binder is computed.
In that case universal PSKs and regular PSKs do not need to be
distinguished, because they are both validated in the same way.

A server unaware of universal PSKs would simply see an unrecognised PSK
identity.
If both the unmodified and the modified PSKs are sent, then it can simply
select the unmodified version, ignoring the other.
A server that recognises both values can choose which to use.

If the modified PSK identity was a channel binding, then the modified
version would have stronger security properties, and thus presumably would
be preferable.
In this case the hash function used for the binder remains selectable.

Would that resolve your issue?

Regards,

Jonathan Hoyland

On Mon, 18 Jun 2018 at 12:22 Hubert Kario <hkario@redhat.com>; wrote:

> 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_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>