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

Rob Sayre <sayrer@gmail.com> Mon, 17 March 2025 15:37 UTC

Return-Path: <sayrer@gmail.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 A9AABD0D581 for <tls@mail2.ietf.org>; Mon, 17 Mar 2025 08:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UH2GqWbhxbUh for <tls@mail2.ietf.org>; Mon, 17 Mar 2025 08:37:58 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 39EA3D0D574 for <tls@ietf.org>; Mon, 17 Mar 2025 08:37:58 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2ff6cf448b8so4594131a91.3 for <tls@ietf.org>; Mon, 17 Mar 2025 08:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742225877; x=1742830677; 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=Al0Ioi41qf45TLYVMVEHYJfyVlJNUFe7Rm2DiOQFmek=; b=G8pb4RXrUFOq3eXgYoQZT+ndZXyQ8H28cNMrR7O2THQvDxy1kmv07w05BWLNho5jO8 onTT59BxrK+EzIxJxvcByR432HzMvMvmzEiGHPWxbvBbu8c7tIvYL5dq3o+1ZJ8ISTMG 6GgIOmGV3cFF3kLocNBZyiDV6YCwMNPCqdFy/UrAIOQvxk3VVppWxfCzmEDzBIvEt7X4 VnhFnEoC3wbXP/Wt+Rb56krvAEhwLbudxQ3rESqEyTSM+Pzh9pYBhTrh6SNSObT5zsZW PQreDCRx04C12ad/By+gW3IlA7wNHGymNoriLxcYNgam/V3nscxL6tx/7sX7MWPDosyh YZfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742225877; x=1742830677; 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=Al0Ioi41qf45TLYVMVEHYJfyVlJNUFe7Rm2DiOQFmek=; b=JiBX84nT/iw+8BUZG34u627wx8v3zKj01L3YBPDMfFmLwR0EodgLVFfXuZ9uesEz7A AWQM/4kSvbSXU+5SqBJkGPRUsEA4Axo1kr4m6IOYcPqPBMDuXXA977/aMe6L9vgv8P5l Eez6rPVsf5PYTuNGXB06i2pulg0y17Wc9VjSid5010UtQGhmbAZGZEMiFjUMCzXhIjMh VK7LKYFW7CZQhhiRCAdGbiOi9F5PD7Uqg6yHRpxcuj157penudW8wp/rgv7cS/jcgIxo glFZrOwGjrtX+HYU+QEKFOxPUMGNpVbXEjUZhA4OqrAPjUNWKE53krLiNIbXidQrDL2n zQSw==
X-Forwarded-Encrypted: i=1; AJvYcCW49Vd3+QNg2TIcWLtf6xd4OLTMqPKDuNdPZuYGpXTja1KjEB0bhBbnCt4yB5tjuhyI6mM=@ietf.org
X-Gm-Message-State: AOJu0Yx93Kwz8GBdqiosfLixRqLSgY/UV04LJHOFZsasJqlvR1oAJ50S AFswKmoYUlfxWlv7XlD4N++4VHur8YiulzYl9giJhun9jxUrP/JotPFKC5fLMShXxcnnWc/SMoR aDXW8ggN4acmz5tUvz48+nyP0OnM=
X-Gm-Gg: ASbGncsRsT4qkxedNosHWgKOzc/jr8n5yrWg+STWqoDyzVApYnWjrwZ34duoIiJpdf7 0k1DBjR60C3T8PEfVbDr6ceIJhBIWaAr/r0+4FE8wjbuIBihoYfeREzwVhLsG8bJHroqyj78vUS AdnIDGLUkYrbaA+IiprzLtlWOvjjgA4YZSjE8LRtJmyANv
X-Google-Smtp-Source: AGHT+IEjlGh4nd2cwQFxx0FzDIz8WI9mDSEb19eZ/Fwi8O5aKO6b6+CBDUit7UwYRjsfc7TVSmEw2286iT+mN4zKdNo=
X-Received: by 2002:a17:90b:268a:b0:2ff:53ad:a0ec with SMTP id 98e67ed59e1d1-3019e94fda9mr179045a91.21.1742225877102; Mon, 17 Mar 2025 08:37:57 -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>
In-Reply-To: <CAF8qwaAoYEZj_t56unUAqz+SaKw6CvMFJ2NmqNmE8skmjKKSpA@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Mon, 17 Mar 2025 08:37:46 -0700
X-Gm-Features: AQ5f1JqyJXADwndACJedsz-okSgD87s-BX1DFWf59w939JikP9J5vL2tTol2QPI
Message-ID: <CAChr6Sw+9bZxjcaJMNbY8UZBbmv5ZDnyb7aGtCjXcrtxvfeoew@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary="00000000000085f63b06308b920f"
Message-ID-Hash: M5QY74HNF7EZVP3MW5B4MRZXBWHZGJC3
X-Message-ID-Hash: M5QY74HNF7EZVP3MW5B4MRZXBWHZGJC3
X-MailFrom: sayrer@gmail.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/svL-ZO3JCNIevWu-iVga41cIeZw>
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 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


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.

thanks,
Rob