Return-Path: <cpatton@cloudflare.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 A04A4119D36B
	for <tls@mail2.ietf.org>; Mon, 24 Mar 2025 08:34:19 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1,
	DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
	HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
	SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key)
	header.d=cloudflare.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 a1kKDOgvJyRv for <tls@mail2.ietf.org>;
	Mon, 24 Mar 2025 08:34:19 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com
 [IPv6:2607:f8b0:4864:20::82e])
	(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 40E20119D360
	for <tls@ietf.org>; Mon, 24 Mar 2025 08:34:19 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id
 d75a77b69052e-476a1acf61eso42326721cf.1
        for <tls@ietf.org>; Mon, 24 Mar 2025 08:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=cloudflare.com; s=google09082023; t=1742830458; x=1743435258;
 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=byBXCINifKMCRiw3Dyx70YOrl/pp02twTGHT0UFeCRI=;
        b=NpK4515PStxT/M8+cq81MfYgO81MX9hrWqZQDulYWc3FXOnONn94OkVwLkn8zp2Vnz
         lE5/pS/DXYLUb89XIx/a1dVaVg8/Et8XIuezThITrlFHm8bddBAlG+wlBobHlR559BsT
         bmaLXM6cuc+bUW6jhBQwh8Mct7sJ4S9uTNi6+NA02pNcO06pBsLPvzFPnkdiqAu+AuCz
         GPy9Ku4STdMHNyielDMB1oR0E5cSK7fVHXHTdojNbl0ZBpW07+cQ8kKjaUrLPrvwloGX
         IUnX31452sBfxWoO6sQtuDwd6Ad4mcgNOd4dw/aiIVX6DYrrtsNafymzB9GU0yrFlhIt
         7Nxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742830458; x=1743435258;
        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=byBXCINifKMCRiw3Dyx70YOrl/pp02twTGHT0UFeCRI=;
        b=TCUpxtio1ps5XI1ohWHZISwODmotszJ7lqty1QvNJ+WX1PnnNHHw6ZRAAtbdQ3aE/u
         RnIeIPI2mp+RyLpXf8IDEPm+uZiDZ/+FDJO3YKAF0b6V7kcgL1lg8ZAaczcj8nAlR+PT
         K9rrCR4jCws9cNbR9n3O0QtVbhQ2RLNzd6lgQ+dBlkcpC0KmjhkcE+U5d2K7q1kVx4Lb
         nRcTWdcD1IJfQxtJKfbuUJeU/VB6A77ekvp503jRffZP5M7aMbCu8jixraDykYdp2aSz
         OZpUnprMgOyc+XNQFX9Shp+ezOt5UXCF7hAXfFcFdKn6UKfkOvAVYo9R3mvnzLfOlbQE
         yFyQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCVQ8MMpyZHN2FywfJhwjDdRLtHx+zMqdDqZ6/FPMUQJ5RzYXldm1U2FO/HUzToZa5Qm4L4=@ietf.org
X-Gm-Message-State: AOJu0YyL2JnaE3UtQWwaKfRhF7bEWZCCr60JdpEriyz4RyuncY7Wbubt
	VXQNj1tJ4Z5HPS4n/hZlv7/pQgaTcoGZb/iikLVpxaCrneQMpujwqa8Nj6NhzP+jtZZ8ho8jtmy
	/Nh4clW4bc1FHBPzHK2xMHRyC665U8lNMbsdXCA==
X-Gm-Gg: ASbGnct4OqeHl+gtu/Xbs51rUU8WYk9AFWCMantYoTSVubjneUDog4bEOTIy3kU3PiK
	KLSifKrWLtn8MNHqQCLwFwbQV69Up47GHyZgC0R+Qh9y9VNtJJnNc1vGJvGTuDaZ4ntR0R3/byc
	GuXhCval8dIJrCt0QSB2Dx+yFmB8VVSJ7JEkn0xdWj2g9E
X-Google-Smtp-Source: 
 AGHT+IHTAX+xpMaADzTJuRoCif99IOtJMwPFWToGhxxpzla8CXulHwXO4+bgitcrGSKlsYTVWEU93LIq2oxrDmwjNpQ=
X-Received: by 2002:a05:622a:2446:b0:472:167a:6dad with SMTP id
 d75a77b69052e-4771de610efmr229562141cf.47.1742830458549; Mon, 24 Mar 2025
 08:34:18 -0700 (PDT)
MIME-Version: 1.0
References: <05B28816-9AA9-4035-B451-8ACFFBE2D4DE@apple.com>
 <CAG2Zi20JgNC0Y+B2ANqdf5O-uFXOkYXeqc8S7u7=4fWGDRiirw@mail.gmail.com>
 <CABcZeBPvmw5O8Xhx7iCqH7a9mgZ-T8qCkeAs3Ts16CgB15WZaA@mail.gmail.com>
In-Reply-To: 
 <CABcZeBPvmw5O8Xhx7iCqH7a9mgZ-T8qCkeAs3Ts16CgB15WZaA@mail.gmail.com>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Mon, 24 Mar 2025 08:34:07 -0700
X-Gm-Features: AQ5f1JpyG5PTHTK1piw6ixG1RRvTGC52nLs-jZe4Vv1LeSwaL4PdjnDUtXHlLMI
Message-ID: 
 <CAG2Zi20OGx2zAdH0uqiOy9P6YTQ2t3CCndr-GEfCeNrGK_pBnw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="00000000000062d3ed06311856f1"
Message-ID-Hash: L6GH75FWPOYG3SUNXPIDXCGHEVL7H7BZ
X-Message-ID-Hash: L6GH75FWPOYG3SUNXPIDXCGHEVL7H7BZ
X-MailFrom: cpatton@cloudflare.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@apple.com>, tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Feedback_on_draft-bmw-tls-pake13-01=2Etxt?=
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/hNDVZRsD-98ITS0dQWGaG-2i56Q>
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>

--00000000000062d3ed06311856f1
Content-Type: text/plain; charset="UTF-8"

Hi EKR,


> I agree we shouldn't *disable* key_share, but it seems like the right
> answer here is to instead combine the PAKE output with the existing key
> establishment.
>

I probably just missed this in the discussion, but what would be the
advantage of combining PAKE with the existing key exchange?

I'm not necessarily opposed. My main motivation is to reduce some
complexity in the draft.

Chris P.

--00000000000062d3ed06311856f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Hi EKR,</=
div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div>I agree we shouldn&#39;t *disable* key_share, but it =
seems like the right answer here is to instead combine the PAKE output with=
 the existing key establishment.</div></div></blockquote><div><br></div>I p=
robably just missed this in the discussion, but what would be the advantage=
 of combining PAKE with the existing key exchange?</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">I&#39;m not necessarily oppose=
d. My main motivation is to reduce some complexity in the draft.</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Chris P.</div></=
div>
</div>

--00000000000062d3ed06311856f1--

