Re: [TLS] The future of external PSK in TLS 1.3

David Benjamin <davidben@chromium.org> Wed, 23 September 2020 16:32 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 7432F3A12AA for <tls@ietfa.amsl.com>; Wed, 23 Sep 2020 09:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.944
X-Spam-Level:
X-Spam-Status: No, score=-10.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable 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 GuUwCCgjVB3P for <tls@ietfa.amsl.com>; Wed, 23 Sep 2020 09:32:14 -0700 (PDT)
Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) (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 9711F3A12C2 for <tls@ietf.org>; Wed, 23 Sep 2020 09:32:14 -0700 (PDT)
Received: by mail-pj1-x1043.google.com with SMTP id kk9so3431475pjb.2 for <tls@ietf.org>; Wed, 23 Sep 2020 09:32:14 -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=m3JZuZubbnqSuwy5WHltDlgkr3ERNX77fp9GSGXuixE=; b=QVlQFXFxKbcyjt/Pf8ZWpSQx20v8gEXsZHq1s9UvzG7Vca2vRZQ/Oh8a9ocZ0oW+a3 DWnqvcHQImjEF0Rf3tXGC79/GuchDSS1frTsWUGIVUkzI+O54fxPFt9vABKmX2Ud0zvp ObQDIO/eSWfXZ9S6SGyEixUgbRC81raHLUBuc=
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=m3JZuZubbnqSuwy5WHltDlgkr3ERNX77fp9GSGXuixE=; b=DGcgDu3gzxtws/7rQRkWJNy5EN3NbvWSQ5Jfmu+NezeSHqolyI2yzhAyntpoyuZt5x GD72F9DgdCYEVHEDulvmYZEZ0L/pvCJR+WjICHH0gg1gAX84WW+xvux/KuRlzXq2fUrs ua+aRry1cY8LVlqZ1fbJ2taXyNc83bd0RcBqFCsgVQGV/XSX5jNpyrzj6lwvpjWX2YcZ tuVVRGxidwnO0JROsfueEsy6DltNto5fEo9aLRgaGeGto99OlSdZq/LXRt0puPwQSZP6 eNJ3f2RC+qEpbjxjwUdy+JhHLAp9LgEEZyCjAgY846y6IQ+jj02v39nIY70rRlSWGtQd xEBQ==
X-Gm-Message-State: AOAM530vpYTmRhXEDUlyo8tusjoxOR8yD+kyYJyevV0Tvf7gQ/GX8Zbn O78K1QFnPjUyoF+uxYcg+pEeNwoo7I+d7lfdQTLgqESCUY/s
X-Google-Smtp-Source: ABdhPJwT2Z9R31IvTCcJfBNQYC+zm6EaKpEZ37+S4fMuVWkATYB1k1kO8GWbSGydBXDLBAH+HiSgwj3C3Bs2gtj6hvQ=
X-Received: by 2002:a17:90b:905:: with SMTP id bo5mr186514pjb.73.1600878733710; Wed, 23 Sep 2020 09:32:13 -0700 (PDT)
MIME-Version: 1.0
References: <77039F11-188E-4408-8B39-57B908DDCB80@ericsson.com> <1600516093048.75181@cs.auckland.ac.nz> <2f2ecb30-bef5-414a-8ff7-d707d773c7ea@www.fastmail.com> <FDD012C2-9B37-461D-BC81-854135EE994E@icloud.com> <AM0PR08MB3716861B782527DAB3C1EA1BFA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <DF3B268F-2E80-4444-B643-D33BC0C7151E@icloud.com> <AM0PR08MB371678103D9EEB89C9AA44C1FA380@AM0PR08MB3716.eurprd08.prod.outlook.com> <ff5f77a9-ea45-4a72-b075-65c2d5e8ab45@www.fastmail.com> <AM0PR08MB37168140C95EB4620ED0FE92FA380@AM0PR08MB3716.eurprd08.prod.outlook.com> <809E2772-DFA1-4E4F-AAD7-8CBF97F5C9AC@akamai.com> <CAF8qwaDvBWrCedJK9qPnmq8bdc54tht3G=LKWMinUhabY=RVZg@mail.gmail.com> <AM0PR08MB37160FA097D2AE52FEDE1551FA380@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB37160FA097D2AE52FEDE1551FA380@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 23 Sep 2020 12:31:56 -0400
Message-ID: <CAF8qwaA6pc1vqFLJ5EnhSyVWqx=axEeHF4_T-WA6aitVuECypg@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Filippo Valsorda <filippo@ml.filippo.io>, Carrick Bartle <cbartle891@icloud.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000040d3e505affda015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/86NNj-CswIjGPZm6cKxQvu7OpD8>
Subject: Re: [TLS] The future of external PSK in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Sep 2020 16:32:17 -0000

It sounds like the registry may be confusing, so perhaps we, independent of
the existing criteria for Y vs N, need to do a better job of presenting the
information. That sounds like an orthogonal issue to whether psk_ke should
be marked as recommended. There are plenty of recommended = N cipher suites
in the registry that went through the IETF process. Security expectations
evolve or we may make mistakes, and this is one tool we have for realigning
things when that happens.

Regarding how psk_ke should be marked, we have already marked the analogous
cipher suite in TLS 1.2, TLS_PSK_WITH_AES_128_GCM_SHA256, as N. There is
indeed a problem with the use of that mode. TLS 1.3 was intended to provide
forward secrecy, and psk_ke does not do so. This is especially problematic
with external PSKs, such as the smartcards folks mentioned, because it
means all traffic hinges on a long-lived shared secret. The one footnote is
that TLS 1.3 uses the same code points for external PSKs and resumption,
and the precedent is less clear for resumption. But TLS 1.2 resumption's
lack of fresh key exchange is a well-documented problem that we happily
fixed with psk_dhe_ke, so I'm perfectly fine extending the status to psk_ke
with resumption.

This is separate from psk_dhe_ke, which is analogous to TLS 1.2's
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256. That one is still recommended Y. For
that matter, psk_dhe_ke is used in ECDH-ful resumption, so if the WG wants
to say something stronger about external PSKs, we'd need a new values in
that column anyway...

(An aside, psk_dhe_ke and psk_ke are PSK key exchange modes, not cipher
suites.)

On Wed, Sep 23, 2020 at 12:03 PM Hannes Tschofenig <
Hannes.Tschofenig@arm.com> wrote:

> Hi David,
>
>
>
> my problem is that the IANA registry only says “not recommended” but it
> does not say for what environments these ciphersuites are not recommended.
> Worse, it also wants to indicate whether the specification has gone through
> the IETF process.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* David Benjamin <davidben@chromium.org>
> *Sent:* Wednesday, September 23, 2020 5:47 PM
> *To:* Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>
> *Cc:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; Filippo Valsorda <
> filippo@ml.filippo.io>gt;; Carrick Bartle <cbartle891@icloud.com>om>;
> tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> There are two different code points involved in TLS 1.3 PSK, and I think
> there may be some mixup here:
>
> 1. Whether TLS 1.3 psk_ke should be marked N
>
> 2. Whether TLS 1.3. psk_dhe_ke should be marked N
>
>
>
> Avoiding psk_ke does not remove compatibility with any authentication
> method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
> the handshake mixes an additional (EC)DH exchange into the key schedule.
> We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
> seems to me psk_ke with an external PSK should be similar. Handshakes using
> psk_ke with an external PSK incorporate no secrets in the key exchange
> apart from a (often long-lived) external symmetric secret. Compromise that
> secret, and all traffic ever authenticated with that PSK is compromised.
> Resumption PSKs use short-lived keys, so psk_ke is less immediately
> disastrous but given the equivalent construction in TLS 1.2 has forward
> secrecy issues
> <https://www.imperialviolet.org/2013/06/27/botchingpfs.html>, marking it
> as N across the board seems a good idea to me. (BoringSSL does not
> implement psk_ke for this reason. Looks like Go and NSS do not implement it
> either.)
>
>
>
> psk_dhe_ke I suppose depends on how one interprets "specific use case", so
> I don't feel very strongly here.
>
>
>
> David
>
>
>
> On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich <rsalz=
> 40akamai.com@dmarc.ietf.org> wrote:
>
> I agree with Hannes’s reasoning.
>
>
>
> I am also concerned about devolving TLS to be just Web browser/server.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>