Re: [TLS] Universal PSKs

David Benjamin <davidben@chromium.org> Fri, 15 June 2018 13:12 UTC

Return-Path: <davidben@google.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 8293B130E73 for <tls@ietfa.amsl.com>; Fri, 15 Jun 2018 06:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.951
X-Spam-Level:
X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 uj9HQBeFlrMa for <tls@ietfa.amsl.com>; Fri, 15 Jun 2018 06:12:01 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 6EB571292F1 for <tls@ietf.org>; Fri, 15 Jun 2018 06:12:01 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id j12-v6so5546094qkk.4 for <tls@ietf.org>; Fri, 15 Jun 2018 06:12:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wbnBbXzTse25OgP1aU0Tz4KPX5se0zCuv/NUZzBX0HU=; b=C2xx84+HLvXklmtGjlfjXZkCkL16uf9+6n57pBrdOASmCaI3VjBEOMREd3jJJqTI89 wOBRiPrITvENQunloBM3UtKiOIV4WuKxEh9TCXesbFOdDnf9bgYwIm8p8U4WGLX7Hd67 5ld+IgLs3Ks9cozXtxNEPFxkJVf2CznPGjp0Q=
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=wbnBbXzTse25OgP1aU0Tz4KPX5se0zCuv/NUZzBX0HU=; b=qg0Bv765t5XnoPHyCte1V158SWUPGYfKjzjAH8YUCe/AId2m0LKd8qjab/Zzt2lSsC 13YDs1oP7IczQHjjqVPaGq2+LRFp5EYnx5fDuZXBvrUNmZFA9lLt0AF2lFtCE2hAXlB/ phElMUhA6mAyAnFigxmI/95+54M27J7SGCGDo/IgD7BlhnS5mKdfY6e5EDA885/i3q/A 2pP4W8qHhw35vtks/27flFfJOh/gQzTZuB0VB/E6rnVZM92naFygOgqfYuVtKRiWH2AO miKyWjL/gwPNY26K7RiekFcHNl3Thvv4w+tO4JCYIaIKTT0zhPw+jQVtPxzRS1r6okE1 cGTg==
X-Gm-Message-State: APt69E00DXYibraWAnSZRi6LCkNkQK+es13QMRbAVbyTbqRwkoEvewq7 0WbkqyUGWtDtWCgqH55XDkuYAXZ65U1VzS/SOP75
X-Google-Smtp-Source: ADUXVKIK/v1aoJRD9DQXfxkoSXU6KbPtsoD18M3Z7OvAzahtTJhkzxGwmtBR7k4/vDw7s/JuSCGuprzzvtkNG/pQTtk=
X-Received: by 2002:a37:285e:: with SMTP id o91-v6mr1216566qkh.129.1529068320356; Fri, 15 Jun 2018 06:12:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaB3GH8WbXD=snEwjA==Jx02gtWejyNTXXO6nVW0Cp1YHA@mail.gmail.com> <2132206.KQKFhKinhY@pintsize.usersys.redhat.com>
In-Reply-To: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 15 Jun 2018 09:11:48 -0400
Message-ID: <CAF8qwaDLn7khENg3BfNa2eaMkLTUtQWMPYQaReq0dJ7qSEA1hw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000013080a056eadf637"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-fcd61F6KdS9h48QrmIjkdVP3NY>
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: Fri, 15 Jun 2018 13:12:04 -0000

On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario <hkario@redhat.com>; wrote:

> On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote:
> > Thoughts? If the WG likes this design, I would suggest:
> >
> > - Most folks who want to use TLS 1.3 with external PSKs should probably
> > design their protocols to provision universal PSKs instead, after it
> > stabilizes.
> >
> > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the
> > compatibility derivation in this draft, after it stabilizes.
> >
> > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API
> > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off
> by
> > default if that API is used and, in a future release, use the
> compatibility
> > derivation after it stabilizes.
>
> that's not workable.
>
> 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
>

Indeed. That is why the TLS 1.2 compatibility section exists. :-) So that
implementations in that position can reuse TLS 1.2 PSK APIs in TLS 1.3
while honoring the security proof.

But, unfortunately, there's a slight timing issue. There's no way some
random draft published yesterday will be finalized before TLS 1.3. So
implementations with TLS 1.2 PSK APIs would need to either violate the TLS
1.3 security proof or not ship TLS 1.3 until this draft finalizes.

Neither seems great, so turning TLS 1.3 for PSK users in the initial TLS
1.3 implementation releases seems a reasonable stopgap approach, until the
solution for this issue is finalized, at which point a latter release can
enable TLS 1.3 across the board.

David