Re: [TLS] Proposals to address ESNI issues

Rob Sayre <sayrer@gmail.com> Tue, 05 November 2019 22:54 UTC

Return-Path: <sayrer@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 13683120025 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 14:54:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, 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 4T_CGn1TPXfK for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 14:54:33 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 F29F8120018 for <tls@ietf.org>; Tue, 5 Nov 2019 14:54:32 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id r144so24670302iod.8 for <tls@ietf.org>; Tue, 05 Nov 2019 14:54:32 -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=CE+IuNw+7S5CRzWOOQkdYepSycoVvGpr4lyE7EagOIU=; b=R5h7Yv2I6Bymz+EJ9Y+cqct7k3hkFk3NVIhh6lAooil3EzIwF8LAkAYMrjxw5VbunP wHlv15KTK43iD/7oscWMhsb2gENumCpMNOjwZLtr4+J9o8ajU9opibWL5EuQBXJ/3ibo DDG/rJ+rrHskDultQh8VMI/8HGsEl6Z/8rc1oXWf2iTrEC9t4zxWeaE7Qw+lWu+81Y1c uDAcJE1FoXWm6Xj7hlaIHWiyF2Qng5zEPEAfscXRnBkJlR/Aq2JqpaX9FVK3NVQs+8Wx AKLkBch9QtyNgi/9Ru6bD4HbGCoAbtNPEICuozOknXEoOH5Zp36rFxbq3QADKk741o4m TfyQ==
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=CE+IuNw+7S5CRzWOOQkdYepSycoVvGpr4lyE7EagOIU=; b=X7JhZ7dafh/IQ3ArL8hWJbvcvnDtl1c/SJOAxJpTKkPlRNfY+OYsbhkk9IO9WKZOiZ eVv2ILbdl0l9XgxnW7VY/3XAz5dsE6u05aY2RLL+EE8/qNkhPr3yBCVFr49b1Ngm7b6z v9ohoCuOQdtWljtIuWGydT0ltOzBgl2jzZX7G/6FO+bVvZqg0bdB61+0ZXUqi4hLrc/P oz/paxIlmzDfISp68IVLyiYKLvqPRTSs/3DY72p2csjnVay+GJ7u3qXEtbpDw0gdD6J8 F9m4AWOWkR+brlYQrp1gVvKDypSjB7OkU4ZqOKcNpT/CgZlSTb5WPz0Vk3GmcLMivWbK Ef4Q==
X-Gm-Message-State: APjAAAXsIA10GvGVwAnmDNLKSY42wPcs6FFN/Pfi5sg59rMMYXilAIan Mw2OYat26Yo0CJaIQf+XZUX1fRlUZ4ZsvsWpacA=
X-Google-Smtp-Source: APXvYqwdPdxE99DprSxHldBqdqpfEl8cj6xSXfkRs7Cnp5EhqbVoO6dkiqGpXyNz8Hmg5i92dBut/iew3AcZDjfZAJg=
X-Received: by 2002:a6b:400e:: with SMTP id k14mr6644127ioa.254.1572994472244; Tue, 05 Nov 2019 14:54:32 -0800 (PST)
MIME-Version: 1.0
References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> <a8a394f7-0586-47cd-9865-429d8a64f056@www.fastmail.com> <CAChr6SydvwjnvbDLvoch8zpyeZm_sFawR_hJfExNrWCzJrx=Bw@mail.gmail.com> <CABcZeBMcRyx7vvP4_jKce3dgq6W=YoCY08VrAw=XYKJEVZB0iA@mail.gmail.com> <CAChr6Szzm=tuOejcGoumPMKkAV7+vQVK-nvcPazAqFDzzyUj6g@mail.gmail.com> <CABcZeBM3T0nXsdUJ6RQixRiRx=oFTfFBnf2GEkxx84tdQedcFA@mail.gmail.com>
In-Reply-To: <CABcZeBM3T0nXsdUJ6RQixRiRx=oFTfFBnf2GEkxx84tdQedcFA@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Tue, 5 Nov 2019 14:54:19 -0800
Message-ID: <CAChr6SxSpa3VXWWd+r2gbe5i-b9kDay11SVyXpeeqMhi4pR+yw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Christopher Wood <caw@heapingbits.net>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c079ad0596a1505d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P7lgQ1DxEzo71B9hD7447W7fbuI>
Subject: Re: [TLS] Proposals to address ESNI issues
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: Tue, 05 Nov 2019 22:54:35 -0000

On Tue, Nov 5, 2019 at 2:43 PM Eric Rescorla <ekr@rtfm.com>; wrote:

>
>> Isn't the HRR attack detailed in that section of the PDF (attachment 0 in
>> Chris's message) contingent on using only the "KeyShareClientHello" as
>> input to the AAD?
>>
>
> No. In the HRR attack, the ESNI block is provided by the attacker. This is
> laid out in S 2.2.
>
> " his reveals the basic source of the problem: in order to prevent
> mix-and- match attacks on the client’s key share, the ESNI encryption binds
> in gx. How- ever, if the server uses the SNI from first ClientHello and
> then the key share from the second ClientHello, which is
> attacker-controlled, then the attacker is free to generate their own ESNI
> extension containing a bogus ESNI and nonce. The server correctly verifies
> that these correspond to ga but because these are all supplied by the
> attacker, this check succeeds and the server encrypts the certificate to
> the attacker with a key known to the attacker."
>
>
Ok, maybe I have misread this section.  It says: "and then the key share
from the second ClientHello, which is attacker-controlled". Wouldn't
including more of the initial ClientHello in the AAD parameter prevent this?

thanks,
Rob