[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt

Eric Rescorla <ekr@rtfm.com> Mon, 17 March 2025 16:38 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3D8F0D1DF52 for <tls@mail2.ietf.org>; Mon, 17 Mar 2025 09:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qBqE5TLias7 for <tls@mail2.ietf.org>; Mon, 17 Mar 2025 09:38:52 -0700 (PDT)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id F2BF8D1DF37 for <tls@ietf.org>; Mon, 17 Mar 2025 09:38:51 -0700 (PDT)
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6ff0c9d1761so40856237b3.1 for <tls@ietf.org>; Mon, 17 Mar 2025 09:38:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1742229531; x=1742834331; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=F9/uj4OuXs3ykKNGPx1/sX5VBhCyXClYU9Jxkb7wGyA=; b=oCQWxLpl/HZ2BMISU0zuOHl4rvtXDxur1QCzVvT1mjEHnTzaSsTkrU3lF7rwZq/8qr 90m+RmfX3dXwJv1sRbPXg92O6wKcu8xGrnTWhCFulSocOvTgLyMbt1MQfMZSY/5b7voj 2r9HapJZqkZtggMvx3vA6Ef65Sw82uLCET3Sq/iwH8Wjiba4v69CPTNhAyryH1KbJ1cj /7Q6Bxvh+cjUE1BDgD8tBG7Z+CDes7a7EW5Vv5yqCXaAAcmHA93JDdiFRBL0Giw9AyDw pnJIoXRWX2zYX2eeO5zHgYwp34iAyP6gFzI3pjBil6XzyIpWBY16df7nBds1+Ud1x4SK StrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742229531; x=1742834331; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F9/uj4OuXs3ykKNGPx1/sX5VBhCyXClYU9Jxkb7wGyA=; b=FCyMabcGzPun3pFgiDVAgZN6364JPNoxyPTbjyVIFEQ+kz56CE2Ib0FTbR6ZakauyT tdZaLX+5T4W31cTl8plmSHi0h4EiFK8AAxL86Mdh0pAIEv1ZQ7xRasZ5ww0vf8yEZLtL AIIyytv56u/OaHZoka42xW4ug/ucXiUfLrkTNp6kosc/LCNOMiG3xht6gPUhgGt2ktQ2 bM4Et2ulf6NTpAOvZkZOWUuaHwRAVbZZKAWeqL2IQmz2PVsaV5h4XCjlQA2Mhp2+vHKk ulafRUnyppwAyEnC0f4RnnvK6ThAMe8JuKYYZBFammTZwdSApQiQxjJmo3lM22DHLZGX GZdg==
X-Forwarded-Encrypted: i=1; AJvYcCV798IYwCFFjhFU0SdpU/BfDH2QMWkSlw+ZUyGG99md/FTPxXyptRzXK9h4LTrxbtbcKSQ=@ietf.org
X-Gm-Message-State: AOJu0YytTE4PVuMmqtdFT/Y7Ke0aeW+uWpTDeDIUODIxZFtx5EhWf/bW 00gD9KgVgbCanDGqu1H5Ryvfl3hpFEp0ctLhFK4vatnA+RBp0t0HYUv5PhdECMgBi/iN4b/b6Gc iW5VFu+BeuYkRR4BvFu/xAsgTO5Xifu4mlHu6iA==
X-Gm-Gg: ASbGncvgZXa+ql+sijZZK+M0wCnKuCRDYAsk5sSnXH/BpzqmQCoJObVy63fwHLROakK pjGr8OuTLvxZg3z9t+RHt7pJV5dNHWo0n3iW4lropNeIrZINolpaTmSS9tbJEWyYfb0ulAdFfuM fRcrwg8H9TNkc8SySyWIjMO94JN2qPHUzakKrKqHo=
X-Google-Smtp-Source: AGHT+IFEwE+ck3ZcK/h6/kAUWP18Kx7MXvmxSNAoxoNieMkU+xTkNeWl1mc+C46wJF+ynpSdm/oXEAfA4dBIitnhWWM=
X-Received: by 2002:a05:690c:358a:b0:6fd:485c:9dd4 with SMTP id 00721157ae682-6ff46024b25mr168426827b3.32.1742229531420; Mon, 17 Mar 2025 09:38:51 -0700 (PDT)
MIME-Version: 1.0
References: <05B28816-9AA9-4035-B451-8ACFFBE2D4DE@apple.com> <CAChr6Sy1Eew1J5z9at3qEwLRWn+7ZLm0f564LobNQGMD7ANQaA@mail.gmail.com> <CABcZeBOpk2cYAyie4=G5=c6V43HvGB70fKVf_e_bQqnt_4C9WQ@mail.gmail.com> <CAF8qwaAoYEZj_t56unUAqz+SaKw6CvMFJ2NmqNmE8skmjKKSpA@mail.gmail.com> <CAChr6Sw+9bZxjcaJMNbY8UZBbmv5ZDnyb7aGtCjXcrtxvfeoew@mail.gmail.com> <CABcZeBNFPLWcYDhv1axqSwTX_w_yatfbJyih8CUMhZfkK5484g@mail.gmail.com> <CAChr6Syji7TKs6GumtmpZ8_tKXb5UK10_b6HdR1PU8Oni0pTkw@mail.gmail.com>
In-Reply-To: <CAChr6Syji7TKs6GumtmpZ8_tKXb5UK10_b6HdR1PU8Oni0pTkw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Mar 2025 09:38:15 -0700
X-Gm-Features: AQ5f1JqcmQ9Dkl3FpDHI46ncCI7xxv5osVlWN4nVvv2h5L7Iw-okaviFyJzfwk4
Message-ID: <CABcZeBOHSGBOj_4R0bVdCpaRTcVV6=uHOzvWcY9HFei7PbC1fw@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000568d0406308c6c07"
Message-ID-Hash: TSEKNJUIWVFTILAGCI3VTSMNRGKOQVTA
X-Message-ID-Hash: TSEKNJUIWVFTILAGCI3VTSMNRGKOQVTA
X-MailFrom: ekr@rtfm.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Laura Bauman <l_bauman=40apple.com@dmarc.ietf.org>, tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nBYtWuEi1z35xF1COjTkmjJIVG8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Mon, Mar 17, 2025 at 9:22 AM Rob Sayre <sayrer@gmail.com> wrote:

>
>
> On Mon, Mar 17, 2025 at 8:49 AM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Mon, Mar 17, 2025 at 8:37 AM Rob Sayre <sayrer@gmail.com> wrote:
>>
>>> On Sun, Mar 16, 2025 at 7:52 PM David Benjamin <davidben@chromium.org>
>>> wrote:
>>>
>>>>
>>>> I'd also add that, *if* we want something PAKE-shaped in a web-like
>>>> context, I don't think TLS-PAKE is a good fit for it. (Which is fine! Not
>>>> everything needs to be for every use case.)
>>>>
>>>
>>> Yes, I was thinking of mobile phone sign-in use cases. I think web
>>> browsers could also offer "native" sign-in UI for people that want to use
>>> it. It wouldn't be much different from my bank iOS app that lets me sign in
>>> with FaceID. This kind of thing:
>>>
>>>
>>> https://developer.apple.com/documentation/sign_in_with_apple/authenticating-users-with-sign-in-with-apple
>>>
>>
>> The current workflow is that the user goes to example.com, which prompts
>> them for their password. They then type their password into some form.
>>
>
> Yes, this is the current experience.
>
>
>> With PAKE, what we want them to do is at this point to instead type it
>> into
>> some browser affordance, so that the site never sees the password.
>>
>
> Well, with that flow above, the user doesn't type their password. It looks
> like this:
> https://youtu.be/TmS66WNL1GE?si=pkEcjcPg1YdnDbSb&t=196
>

Well, yes, but that's because this is a third party login system, so it's
qualitatively
different from password systems. The idea with a PAKE is to bootstrap the
existing
trust relationships (i.e., the pairwise password) onto a safer
technological base.
I'm not saying that third party authentication isn't valuable, but we
already have
that without PAKEs. The implicit problem statement here is how to provide a
more
secure primary authentication experience.


>
>> As I
>> said previously, this is technically straightforward but also phishable
>> because
>> training users to only type the password into the browser chrome is very
>> difficult.
>>
>> Can you explain specifically the experience you have in mind that you
>> think
>> would avoid that risk?
>>
>
> In that ladder diagram in the link above, both sides have enough
> information to bootstrap a PAKE, but the acronym is a bit of a misnomer in
> this case. So, the PAKE registration process is the existing "Sign In /
> Sign Up" feature. Then that data is used in the TLS handshake, but you only
> need an identifier in the ClientHello to get started, because you've
> verified their tokens during registration. This way is much less general
> than this draft, and assumes that kind of sign-in flow. But, it's a pretty
> popular pattern.
>

As above, I don't see what this has to do with PAKEs at all. If you have a
third
party authentication system, whether sign in with Apple, Google, or some SSO
provider, then you don't need to share any secret with the relying party.

-Ekr