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

Eric Rescorla <ekr@rtfm.com> Mon, 17 March 2025 15:49 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 05FC1D11127 for <tls@mail2.ietf.org>; Mon, 17 Mar 2025 08:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_BLOCKED=0.001, 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 M3EXUx4YPiou for <tls@mail2.ietf.org>; Mon, 17 Mar 2025 08:49:22 -0700 (PDT)
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 A3C31D1110A for <tls@ietf.org>; Mon, 17 Mar 2025 08:49:22 -0700 (PDT)
Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-6fd80f30ba5so30219697b3.3 for <tls@ietf.org>; Mon, 17 Mar 2025 08:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1742226562; x=1742831362; 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=V+3zivjNohKmkYqFI/sOxkxRemaA0jJxpakxjRA4NAc=; b=Xu1/sMutblsGmqpgUOPq+ZXYQvDC0Y+G7qh2xda6Pbunvn5S4KZ1lwwaZsAsEjlYB6 IkOPToDz5tJ4ChuztiUC3CksqdGlIg3KZetPx8KbYLctGtkecpWcK5XvYflO1TqBrK4K fXJASopfgt6tt9U+bt5Qr0mSSkfCiPcgg+dsbSLxumOQzsoJzU/DdnjX2mlSJ7XnOAXJ CbHJGKRE0aUySx+9ZUsJK/VMk+3lceJ5NHYkIzpd+p3vOAUZC15XELw7Jgizwtm+2800 CKvn8CMyymjUcIpHtM4BjGywV2BwwzB9FY2n30c9I9QSNtdUrwZg3djxktqqFK2tbPbD 3y0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742226562; x=1742831362; 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=V+3zivjNohKmkYqFI/sOxkxRemaA0jJxpakxjRA4NAc=; b=JiKfCSAfDIDuS1UydMSj3zVW4uZ/yYsrMz88GPYu8eebAsaBl0kACOCJp2jPzd/ilH HpGD5lAX7ov9z8sUwgBNdm5iHp+Xew4Jges7ThcTwjbj/2C3llHYFpe8J11whygidKUH FxpeUN9yoQxFt7oYn3YFPmwUam//O7C5EjXtRuxya20XCCwYJrYPzxhtVlRIA8AuP5Fw DQ48N5jd4xu/2KRqditObRWdcWpJ9URSp7gbm7DCmR4wsJq6VyGxBOXnM5ADsLdGmWD3 SRFZL8lTD5EWaCAqXtQEskd1i759hssk4JZsipbsGPbjTrxERcfq22locu6LvgZs5mVX KWAw==
X-Forwarded-Encrypted: i=1; AJvYcCVRZHeJI5tapAZHUqPovxlSEIWfRiICrLQGz/9/uCrD6s9Uh70/ATUcQYatb5oJCWYJJK0=@ietf.org
X-Gm-Message-State: AOJu0YwICFafXnspCMeYvRvYaoT09a14JpuZF+D3lWi+bE7or7f2FwwM oJm3LpqmHRESDazEBPV4wjjpBSEmOntQO/Zr7AHv95W95AFtzQm4Z01XzLtNybONkpcQIXWd4iC GooCaWS6vgDrzdpzPl0ssFD1KJTjD4e0AYyHfJOyAlXmQG/kc
X-Gm-Gg: ASbGncss5t8Qe7A04fBJMEugGhpPQtZPgW+Ky1aFGVj7ugkrIhesyxGzWV5j08/9vq5 QLO19r3CxdgYdnt/q73x3aF4J2Z6QvnsFIOOAdjc14NFirps9/c6AAHM0Oidv+mTKUCludV2ces 4XI67pv7s0naSdSMB/f/9K6xCi+iv7
X-Google-Smtp-Source: AGHT+IEqaz9hCvVec3pev2HsPNQeUcY2kd9xosV3s0VdqtmAaLGkcivdF6oXo2EWZwvmWAxE0j7+BNKDSWh9/3DqFg8=
X-Received: by 2002:a05:690c:d1d:b0:6fd:2f47:f4e6 with SMTP id 00721157ae682-6ff45f4975dmr161481287b3.12.1742226562162; Mon, 17 Mar 2025 08:49:22 -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>
In-Reply-To: <CAChr6Sw+9bZxjcaJMNbY8UZBbmv5ZDnyb7aGtCjXcrtxvfeoew@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Mar 2025 08:48:45 -0700
X-Gm-Features: AQ5f1JoLCIUqC8F5HDKC7oQ1O-5cGohwCpvFNwbzgjxdrpMZffOoApFns2wz6sw
Message-ID: <CABcZeBNFPLWcYDhv1axqSwTX_w_yatfbJyih8CUMhZfkK5484g@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005b3e3206308bbbd7"
Message-ID-Hash: Z5B4N3IZSGOXAB3KFFH3KLHCGAE5URVE
X-Message-ID-Hash: Z5B4N3IZSGOXAB3KFFH3KLHCGAE5URVE
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/BWL7r6o9rVdMgDzONLDG7L2AwLY>
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 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.
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. 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?



> Couldn't it be click "Sign In", and start the TLS key schedule from there,
>>>> instead of "0"? No extensions necessary.
>>>>
>>>
>>> Regardless of the point above, I do not believe this would work. You
>>> need some protocol to carry the PAKE information and if that's not going in
>>> the TLS handshake, where is it going?
>>>
>>
> Oh, right. I had some scheme to carry it in another extension (I think I
> tried a few) with the aim of "Do Not Stick Out", but it occurs to me that,
> these days, you could put these only inside the ECH ClientHelloInner if you
> don't want it to be obvious that you're using a PAKE.
>

Note that this stanza is in response to me, not davidben.

-Ekr


>
> thanks,
> Rob
>
>