IETF Logo Mail Archive

Re: [TLS] [ECH] Reverting the config ID change

Jonathan Hoyland <jonathan.hoyland@gmail.com> Wed, 17 February 2021 16:33 UTC

Return-Path: <jonathan.hoyland@gmail.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 D33783A1B5F for <tls@ietfa.amsl.com>; Wed, 17 Feb 2021 08:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6iqQCu5dhaj for <tls@ietfa.amsl.com>; Wed, 17 Feb 2021 08:33:08 -0800 (PST)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459E33A1B5D for <tls@ietf.org>; Wed, 17 Feb 2021 08:33:08 -0800 (PST)
Received: by mail-qv1-xf32.google.com with SMTP id c25so6533338qvb.4 for <tls@ietf.org>; Wed, 17 Feb 2021 08:33:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mzfudWo9iWUTpSpZpRD6T94/xUnbiaGw41veulQnZI8=; b=L43YefY2gRxiXEkuUBz6Z2yGIvVkFIZQj0Jd92GKi1hR4sBLtSEwyeCBUDTZ4P444g MtctgRY6tpLhxls7n6sDnZ8Qtg24DJEC0kLRAXTu1u0yKt+BX5wU70/sr6YkphBTVkpS 71jvgePv4BgRpBeP74UKQ3PBEX9yLgqfSe39limi2walslpa88CBRzyauCaKX7MsRR0e NY1I5USizOeKc+IFc0hBf3nhZUE6ALwnhVQ7LWZYF9SHeKmWXDFz6uB97vupzY+7uyCm DPRoaXEveKn2VQU6GLZSwKLDOHdWK1xRfbP5RyM++oyyPhWWLWaCNl6kXB1RaEngGjCO 35LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mzfudWo9iWUTpSpZpRD6T94/xUnbiaGw41veulQnZI8=; b=cTzsAhHh27b7lS9Z+zmQdc1P1xKnvXz4NRJ0GCVK34jWwtgN1xDjrIFvD5Ki/C4A74 FKkmahz4cNwGazyvSQopG840+f3NdOpmj1XImAWK/vWW8IfDBTTm5GoK/INTano4JzbT orMPe5WZXa0YIH85a2kmKA9+VX7m5QB7a+Iw3XXv/MDcm1qKeWByQFB3NDMCxDzVoKqn 68jjN++Rpetassxd1pAckl9EEgdKIfe+p+D2uVLCLPbjq9IgosYUVEQF/8CTyxioDak8 08UpfLGkO/JW23kQfzjcGRe8HasY9DbPeRsW/mHgF5QYri/2F4gGgCQGKN6ZJMol+8mB 1LSw==
X-Gm-Message-State: AOAM532ihSIgWW1JXs9zFo0WNCVR1HjXZSPGmkQCEWtSq9TyEF40NQgm N7+ANwpLXw3LTMSBAA+ySKh9p393fubjm9NZ5szxJBXVtkM=
X-Google-Smtp-Source: ABdhPJwuZZ2vHQY52fcswH5sX1m/RzWxSr2aJ7pvvlXyJJiMdeN+b2OPvwXPCP/4kmBz37PR+PD2gmldoP+Mv7gTXr8=
X-Received: by 2002:a0c:fd64:: with SMTP id k4mr25215083qvs.3.1613579587259; Wed, 17 Feb 2021 08:33:07 -0800 (PST)
MIME-Version: 1.0
References: <e44be9d1-bd0a-4e99-b092-b1b21c517b0e@www.fastmail.com> <7925717a-bcba-4b29-b12b-b47e622c62b3@www.fastmail.com> <CABcZeBO20+09dZ+9ckdm=N-RigMh_O+Svx3m51NsXZY1QFZ73Q@mail.gmail.com> <e55a60e4-e948-4cc5-ad1a-0a1086485305@www.fastmail.com> <b35c4e78-d0ff-8fed-5297-4f16667f18d8@cs.tcd.ie> <CABcZeBPT8mhsqJz_EiCQnzpNiC+S30uMA=S50kV-6Jc7EnciZw@mail.gmail.com> <f3e974b5-fb97-d92b-9257-5910f2b54245@cs.tcd.ie> <CABcZeBPWVv2dDoKTabS6fOUMRT_V7DoygXsG62C1MJiCArxVSA@mail.gmail.com> <b9007c4f-18c7-d85f-eaee-62f0f004a6aa@cs.tcd.ie>
In-Reply-To: <b9007c4f-18c7-d85f-eaee-62f0f004a6aa@cs.tcd.ie>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Wed, 17 Feb 2021 16:35:03 +0000
Message-ID: <CACykbs3qzyPQwepnqV-BGhB+SuUWrC61=sDRrmQTyuPUut15Yw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Eric Rescorla <ekr@rtfm.com>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001d92df05bb8ac621"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jX5EcUBokaTQ-4vZdf3PAMEW4lw>
Subject: Re: [TLS] [ECH] Reverting the config ID change
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Feb 2021 16:33:10 -0000

I know that ECH doesn't provide security against probing attackers, but
such an attacker could easily maintain a list of active keys, and drop
connections using them.
If the key ID is very long, this would be highly effective at allowing
grease ECH connections, but blocking real ECH connections.

An adversary using this strategy against a one byte id would have high
collateral damage, but against an eight byte id would virtually none.

Providing some resistance to probing adversaries is a nice-to-have, even if
we can't provide complete protection.

My preference would be for a shorter id.

Regards,

Jonathan

On Wed, 17 Feb 2021 at 16:25, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
>
> On 17/02/2021 16:00, Eric Rescorla wrote:
> > On Tue, Feb 16, 2021 at 4:44 PM Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> > wrote:
> >
> >>
> >>
> >> On 17/02/2021 00:34, Eric Rescorla wrote:
> >>> How is it any harder to manage a multi-octet server-chosen value than a
> >>> single-octet server-chosen value?
> >>
> >> Easier for the library on the server side. If it's >1 octet
> >> then someone will want some semantics. If ==1 then they'll
> >> have to accept none and possible collisions so it can be
> >> handled independently inside the library.
> >>
> >
> > The server is free to enforce 1 byte.
>
> A server operator would be free to do that. The person
> writing the code likely would not be as some server
> operator would also be free to try impose semantics
> on a multibyte field.
>
> S.
>
>
> >
> > -Ekr
> >
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email