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

Lanlan Pan <abbypan@gmail.com> Thu, 24 September 2020 08:40 UTC

Return-Path: <abbypan@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 164DD3A09E7 for <tls@ietfa.amsl.com>; Thu, 24 Sep 2020 01:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xWtmlj0soBsc for <tls@ietfa.amsl.com>; Thu, 24 Sep 2020 01:40:45 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 C2DDD3A09E1 for <tls@ietf.org>; Thu, 24 Sep 2020 01:40:44 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id n10so2340522qtv.3 for <tls@ietf.org>; Thu, 24 Sep 2020 01:40:44 -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=aBzsM+fWeTNjpnAZyi2HvoG1IqALRU+jq5vwdGuW6CI=; b=j5ZSXZGqva7ujEScvhBoXXbp7wUuRzlOLWtt76Nxsu2Dl3DAON3L88lGqoXB+BhnD5 VmP6IOpKSuFK7w9DQhvpC63q3lctCERM6V/dpseb8gI1PoGE3stPk+zHUejmF0NiAw0g VK3nyfSmnn9j2fVysTkgjYDFGinPUBUNSUTxL9dP+IrjQ1szlpI/DLG2M6UPOkRgzTrl 8RX+0JhSHVFLhCayktL+kQdQ4mgrlDFO1PnIqxwuWT3EhpFcQUeM140+do0g+G1u96Yz j9hvUZdtNivANRiVALn3R9j/1k/tMAO3ppynuwfSM/KB6RodHi844x3+QbchTYNkN8b3 XuMA==
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=aBzsM+fWeTNjpnAZyi2HvoG1IqALRU+jq5vwdGuW6CI=; b=Lf9qxcBnKiau53aRjCZjE2TQ2AbBnRLWq0ttrtMWxwfsLz4aF80vL3y2FhDK9+MudD OpnNbOyU9g2986TtLMTYnyQ7uoJcIURzfnGeTzcSbVncWJIqRGoE/JF55cK76aLXLoM3 1RPR0FBmRInRu/+AUStqUNGZTVArETO4lYX5iXHDM5gSCDxPMjtL8aOQBTfupEteGzlc JrbRbLlFrB9hLpwgdxpYhPM+c3By/ndzKTu+WZwAi0lW9KlgycpqGCgC2mCbh5W58Oee jDzKdgy/ZKAvvXetlHH243IqfBeyfXuACNDne6FzWMC182SI34lv/C/8cqwfiJhk4jVC xkhQ==
X-Gm-Message-State: AOAM532h7ReuRqcorRwzkzS0aOKyHOSwdHPElrQDyd9YXNbP6FHJwAI3 hp8st+mC8/qyniE7d+v2NmNf9BO9HOu9iAnGuz4=
X-Google-Smtp-Source: ABdhPJwsqjshf7TbnRQ+XiFYlk0moOqbRdWdb7TcQE+xunWQU+4HCMQ0LUuiGrvjH/MEO1nGAyromfd9y2agwADpL18=
X-Received: by 2002:ac8:3fee:: with SMTP id v43mr4298017qtk.192.1600936843763; Thu, 24 Sep 2020 01:40:43 -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> <CAF8qwaA6pc1vqFLJ5EnhSyVWqx=axEeHF4_T-WA6aitVuECypg@mail.gmail.com>
In-Reply-To: <CAF8qwaA6pc1vqFLJ5EnhSyVWqx=axEeHF4_T-WA6aitVuECypg@mail.gmail.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Thu, 24 Sep 2020 16:40:30 +0800
Message-ID: <CANLjSvXk-WhLJC80cGabU0SL0GDt-Br5yZEH9yoLdBTAfU9VEQ@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>, "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e1647e05b00b2725"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9WPD9c3eOwPlRvqHWvWqCyF6ek4>
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: Thu, 24 Sep 2020 08:40:47 -0000

David Benjamin <davidben@chromium.org> 于2020年9月24日周四 上午12:32写道:

> 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...
>

+1,  psk_ecdhe_ke is  useful at IoT scenario without certificate.

maybe we can just mark N for those who doesn't provide forward secrecy.


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