[TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction

David Benjamin <davidben@chromium.org> Tue, 21 May 2024 13:46 UTC

Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF752C169426 for <tls@ietfa.amsl.com>; Tue, 21 May 2024 06:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.827
X-Spam-Level:
X-Spam-Status: No, score=-9.827 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrU7bgoCWb8Q for <tls@ietfa.amsl.com>; Tue, 21 May 2024 06:46:06 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9BCC14F74E for <tls@ietf.org>; Tue, 21 May 2024 06:46:06 -0700 (PDT)
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-61be613d903so40251317b3.0 for <tls@ietf.org>; Tue, 21 May 2024 06:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1716299165; x=1716903965; 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=KGI4v4bxtDhmpADyb8mlGDyCLpWVvl4Vx9jhpy10OAg=; b=E+h+KsDObR9zvxZGSF3W9DI62d0RPAYCoA+4UOms8V57xnM3dD1C5U1NKbga1dyVbE hxavIjuZHqaq9SAtJj/VHwYD9cS/BtxQfZ7tLiqH8/v7wmpZqtsQFOTN7EpTni79M0eV jX3XubuFuiu9dV0e9qLrZhit8jVArTYuyRjNw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716299165; x=1716903965; 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=KGI4v4bxtDhmpADyb8mlGDyCLpWVvl4Vx9jhpy10OAg=; b=MZSdIcwicd1eXkSnQZlXtnI+SiCqfDmimbrIlCKEw/RIpbj1S6JxizES5Otcg9I8Cj LP1n/5FFkr/yHnZmM6ehpgNhquyD8+OMfNvyldoUviuX+5zurcC5nxC924HxMnsLyPdV igNe/US06uaDSnzjo3AA3D57TBxTo0ei8cHHSpHxBBTmHn99hLROnDZJJwiGZZMa7+uv K0yytbvwYcXqZXO1wQnxsrhIWcQ00sg/AvoTnBdgoKD6VpIdH6ICLXraKyfd0jhWXEi6 HaODwZ2RjtmIcntwPFEBUhyyDluy5ac9NpSyuB4SFVvS8j2ZEHm2uEjLpzIMyw/VAdSC bTCA==
X-Forwarded-Encrypted: i=1; AJvYcCW68sv2Y3Bgbso72pOC2lyo04b/uvgVEchEluPEMhs1jTpv96kLR5oY90bT5w0AkoQ7MKGFXCNgVzo6t0I=
X-Gm-Message-State: AOJu0Yzzb3qSoqVzscVhcehSnGJQaYlsGR/gczyYTx7E3Fy5VjkNl9w6 u84lOb+hzWrGGnNKkeya3L6REc5M8NRwnpFvooPOHfYFUZ7r57AA/SQEnvjEC1DJU9uJnydmkQl F5IUXwvUegurcdOjHZZDaxKUVuqaQ59lP8gCaJv7R2WyIgRqP
X-Google-Smtp-Source: AGHT+IEwqMDABdIYqaZBCMq6wem0N8qIJ7XXIylaeIRGrgRNpmS2koAsw6NBZ1pbHMi8ztGZcqC0/zYIGl0SVzn12bA=
X-Received: by 2002:a05:690c:893:b0:60a:66c0:d5fe with SMTP id 00721157ae682-622aff5b21amr385437707b3.13.1716299164078; Tue, 21 May 2024 06:46:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAOgPGoA8-t_x7WLOjZ7kWaoPn9n2m-RM3VGUFaVttBiFrbjZHw@mail.gmail.com> <CABcZeBNwEh7PDC9FC6FXj5tk1=_ULRCdaycYWGWBEE-7iVmq+g@mail.gmail.com>
In-Reply-To: <CABcZeBNwEh7PDC9FC6FXj5tk1=_ULRCdaycYWGWBEE-7iVmq+g@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 21 May 2024 09:45:51 -0400
Message-ID: <CAF8qwaC9K8d8aJGaTDLBXxHobCL1y7XrXy_Orzew475sXDxZfg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="0000000000000152580618f70a78"
Message-ID-Hash: CUMPQSTBQLIY5UPMNLPCPVBGNJJMGPT5
X-Message-ID-Hash: CUMPQSTBQLIY5UPMNLPCPVBGNJJMGPT5
X-MailFrom: davidben@google.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: "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Re: Adoption Call for draft-davidben-tls-key-share-prediction
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/Vh_sBURGTPaJnutdn08Q70mhMTY>
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>

Off the cuff, folding it into the transcript sounds tricky, since existing
TLS servers won't know to do it, and, as with any other DNS hints, we need
to accommodate the DNS being out of sync with the server. It'll also be
more difficult to deploy due to needing changes in the TLS stack and
generally require much, much tighter coordination between DNS and TLS. I'd
like for that coordination to be more viable (see my comments on the
.well-known draft), but I don't think we're there yet.

But I'm certainly open to continue discussing it and this problem space!
The original version of the draft actually tried a lot harder to handle the
downgrade story. Rather than mess with the transcript, it defined away all
the negotiation algorithms where this would be a problem and keyed the
NamedGroup codepoints to know when you could be guaranteed of the narrower
server behavior.

My read of the feedback was that people thought this was an unnecessary
complication and that servers doing a key-share-first selection were doing
so intentionally because they believed the options roughly equivalent. So I
took all that out and replaced it with text to that effect.

David


On Tue, May 21, 2024, 08:54 Eric Rescorla <ekr@rtfm.com> wrote:

> I agree that it's attractive to be able to hint in the HTTPS RR, but I'm
> less sure about addressing the basic insecurity of the DNS channel with the
> approach this draft takes. I don't have a complete thought here, but what
> if we were to somehow fold the hint into the handshake transcript? I
> suppose we can sort this out post-adoption, but I'd like the question to be
> on the table.
>
> -Ekr
>
>
> On Fri, May 3, 2024 at 3:05 PM Joseph Salowey <joe@salowey.net> wrote:
>
>> This is a working group call for adoption
>> for draft-davidben-tls-key-share-prediction.  This document was presented
>> at IET 118 and has undergone some revision based on feedback since then.
>> The current draft is available here:
>> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/.
>> Please read the document and indicate if and why you support or do not
>> support adoption as a TLS working group item. If you support adoption
>> please, state if you will help review and contribute text to the document.
>> Please respond to this call by May 20, 2024.
>>
>> Thanks,
>>
>> Joe, Deidre, and Sean
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>