Re: [TLS] Proposals to address ESNI issues

Rob Sayre <sayrer@gmail.com> Tue, 05 November 2019 22:32 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 27DB71200CC for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 14:32:18 -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 MD5Qzb5fyzap for <tls@ietfa.amsl.com>; Tue, 5 Nov 2019 14:32:16 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 69321120025 for <tls@ietf.org>; Tue, 5 Nov 2019 14:31:25 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id g15so3197471iob.9 for <tls@ietf.org>; Tue, 05 Nov 2019 14:31:25 -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=yGci1Y3a123LN8AXnoYUt+V/iNry5GmWAWJ/wlHxIfU=; b=Ktw8eAa2oL93KuOAM7Nu1j033vsaUb8zXlnbykxJxHuC1CfVS7xS9wHkOcF5WHul7Z 8l4nYki674cadUg3k985/WbeKUAqPE4rsUEc0gAjuOrV8wCEqAP+3AFarGJ4iMMQCrwU FPeikllcSWPhjK2Qzbdv/2F43orPitGwCrwEA07h+w4MAbqXnVh89LshnlFU2psyPm9h bJMwWkYA9Z4+kCDuYbq99Sd7IJVWOAH1KggOwD7u7tNHjqQ34nw9nFIXL5pScim3ILJz F+Y+T8Ta7Ir8/qgOqfHWzbgsrgxS/LDMJMtYGiqoBtb2ODI7LNvUfgAtQfpj8eOOJkRu HBVQ==
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=yGci1Y3a123LN8AXnoYUt+V/iNry5GmWAWJ/wlHxIfU=; b=tlTbx8GcOxNwou4x5yvOlVl+QQDog2Zs0Th+mlYSZUX51aJ0t5DtzUH3uwV4/xv2xF HK/+/kJFl0dB6P9z6h3488TsuEsPyLGroKBQHn8uKZYVgS7exP/2n8VwtyeGYCI4Iwlp mOCPbDs6u0lx/L91jZKMmZygz4aX8HgdTWmu/4LJmvlzpzsgbBg8NAWXVo2Q8G2zOV8B J8/AK2inaq9Jx21x+mvZRoce/ZuKMSqUrpI9EgflSaw2PO2T6QvbQpg88vFz7uUP2yI2 kYUTfFW0NWhqRGIIlyb0oi0bEEKGpooIm3G+4xJ3cbDDQSD4M8HNdHV3V6yCzghtT5vp pf3g==
X-Gm-Message-State: APjAAAXMTaMNeZjOFmAHw9n3v7PZ9SD1p2nawznRl1L5wUvgmB8vKQL1 OEGJ/kx8V7BH3Qjft5gCztWsGkffPqK+Ia2f91M=
X-Google-Smtp-Source: APXvYqyUSKT67ZuqiNKFWHf6h10+A9gqiEDBZGVrvU26pI5YQrr+HkY9X+62nhyEPHL6+2FwUywP+yP0TmECyi9/gVM=
X-Received: by 2002:a02:82:: with SMTP id 124mr12341113jaa.131.1572993084511; Tue, 05 Nov 2019 14:31:24 -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>
In-Reply-To: <CABcZeBMcRyx7vvP4_jKce3dgq6W=YoCY08VrAw=XYKJEVZB0iA@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Tue, 5 Nov 2019 14:31:12 -0800
Message-ID: <CAChr6Szzm=tuOejcGoumPMKkAV7+vQVK-nvcPazAqFDzzyUj6g@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="0000000000000959320596a0fef1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z9k_BBk4Vc2bfN4x8Nnn9Bsd3ew>
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:32:18 -0000

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

>
>
> On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre <sayrer@gmail.com>; wrote:
>
>> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood <caw@heapingbits.net>;
>> wrote:
>>
>>> >
>>> > The attacks on ESNI security above seem to stem from two problems:
>>> >
>>> > 1. The ESNI contents are not fully bound to the ClientHello contents.
>>>
>>
>> This seems right to me. I was surprised that the current ESNI drafts only
>> require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt
>> function. Additionally, I've raised the point that even that arrangement
>> seems to imply that the client's key share message should appear before the
>> ESNI, or that the server must perform some input buffering.
>>
>> Perhaps a variation on the "Tunnel CH" idea is in order: require that an
>> "Encrypted Client Hello" is the last extension in a ClientHello message.
>>
>
> This wouldn't change the situation in the tunnel CH, because
> ClientHelloInner does not depend at all on the outer part of the CH.
>

I think my suggestion was that ClientHelloInner should depend on the outer
part, by requiring that it be the last extension, and using all of the
previous input in the AAD parameter.



>
>
>
>>
>>> > 2. The handshake secrets are not bound to the ESNI contents. If this
>>> were not the case, servers could not choose attacker-controlled keying
>>> material yet proceed with victim-controlled parameters (SNIs).
>>>
>>
>> I had a hard time parsing this point. Doesn't the current protocol
>> require echoing some encrypted content?
>>
>
> Yes, but that doesn't affect the HRR splicing attack. This is laid out in
> S 2.2 of the document Chris forwarded.
>

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?



> I think the draft might need to address the case where servers ignore the
>> SNI and ESNI messages.
>>
>
> I'm not sure what you mean by "address" this case. The purpose of the
> nonce checking is to detect when ESNI was not processed.
>

I've found that existing clients do not fail when the ESNI is not
processed. Unfortunately, I discovered this by writing a buggy client. :)

thanks,
Rob