[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
- [TLS] Feedback on draft-bmw-tls-pake13-01.txt Laura Bauman
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Rob Sayre
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Eric Rescorla
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt David Benjamin
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Björn Haase
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Rob Sayre
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Eric Rescorla
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Rob Sayre
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Eric Rescorla
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Rob Sayre
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Rob Sayre
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Laura Bauman
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Rob Sayre
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Christopher Patton
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Eric Rescorla
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Christopher Patton
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Eric Rescorla
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Martin Thomson
- [TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt Eric Rescorla