IETF Logo Mail Archive

Re: [TLS] predictability of inputs in ESNI

Rob Sayre <sayrer@gmail.com> Fri, 01 November 2019 23:18 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 C543A1208A5 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 16:18:55 -0700 (PDT)
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 t7siTwkxDHTy for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 16:18:54 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 E77FA12082D for <tls@ietf.org>; Fri, 1 Nov 2019 16:18:51 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id b12so9978855ilf.12 for <tls@ietf.org>; Fri, 01 Nov 2019 16:18:51 -0700 (PDT)
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=PSnSyZK6cYzcUwT/K+bqiXUNR7vTNvjBshFDOaONtTk=; b=Nabckga8HC12R497nE1C26hC46JwBUrEJJbSum5jq6SFHzVOeZt1RSjvK8f8HgevKR J9enkigS879N5vNmlvKe34gCeGpt+bL/Gf4cGOUGMcDXvB78y4nb310dCIhxPZVyotHl YqJiJ4xrz845TJ2EmvALpYCzcqzx6Db+PQgFPLobs3j9icbS//rxCKmQNHfEbDRZxMwm d66iYMh1MLUUBFbCu4wxVIcbYCwJR9Y8Iu167ginWGQNW1GjvFQ9NcVJsjh2ILK8xG53 /FtOn1I9RRV2m1E58m5eJoXeklv20A5+riaj8wZAjepjfbCfcjQi+tQ/DjR1Mr1GE1pC U3DA==
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=PSnSyZK6cYzcUwT/K+bqiXUNR7vTNvjBshFDOaONtTk=; b=GLieHT7/vnOsJThN/swVOOU2DJitoW6+mApVgcSk93NWm3F7lGuvwPwww219JCDhAv zQCXUY9FRdhVusvKF4b1fUp3BPQ0FN2TkI6mKkvSI1IsgaIW49sA+pfXDrXojZycDJPy M4JISLS0EJ+ub/Kbr1UNN4V4x0JwjAN4JWnyF82d1gW40FyKFwYmBwiFg47+/iEzbgqj hIVVYIYvybgNdXkw4JaCGaEP0QVVY+vsHFLXY8VLUqwhVXgiAoN+QVwFicd751XiT7Ex cgdAfSxn4d4k2jLEtKtFQd8MY0Z6LkIyCzcLwGVv5o9P3S5GivrOHLDcgRb5Sm4yxuUY ATOQ==
X-Gm-Message-State: APjAAAX+ts01b9O9/ZfEOGfsPTsZoR+7p+e1k6+yWNwr435EBTQe1XmG c/aL7b/MbAfA0rzGRAm4OEo5BH7AO9AbE3IMLU0=
X-Google-Smtp-Source: APXvYqx3e+gIA0S+WjVMH2I0qzAZHubOxFb2WGSbf/HTrMpJZX9uLo6IaWvshtXXbfcNGVU8x09Mv7eGlxCyEVX8M5k=
X-Received: by 2002:a92:8394:: with SMTP id p20mr15693201ilk.73.1572650331078; Fri, 01 Nov 2019 16:18:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6SxZQkbLExmFYX8obdvMw_oFY2=k9Q3YUTUW67HUo74vLg@mail.gmail.com> <CABcZeBMA0gnsw+pqmx0vtYXvd6aAWxTR6yAybDRxut+XJQonbg@mail.gmail.com> <CAChr6SyxdZvYm4xn2svMRrJuGAKPD=dg4dZmoMW4LEOLmboaFw@mail.gmail.com> <CABcZeBPBGmYaaqDRnhHk=i5cBYA2_1cwkkRvVStEdT-OGoR-0A@mail.gmail.com> <CAChr6Sxx3eni+1FLJNnyoimhYJofOoKg70Mev0xqvvDHHG=AYw@mail.gmail.com> <CABcZeBO293Vdvfv1bAJofxqQqqmgwhmVhzdbSqb_b6zhhZwsTg@mail.gmail.com>
In-Reply-To: <CABcZeBO293Vdvfv1bAJofxqQqqmgwhmVhzdbSqb_b6zhhZwsTg@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Fri, 01 Nov 2019 16:18:39 -0700
Message-ID: <CAChr6Sxauc9vFZS8eyzboGwTrjkpM4Z97PYw1M47xD3VX3_BJg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005706cb05965130a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jPDr7j0EkFnhuj_037Pb42LmR8o>
Subject: Re: [TLS] predictability of inputs in ESNI
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: Fri, 01 Nov 2019 23:18:56 -0000

On Fri, Nov 1, 2019 at 4:04 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Nov 1, 2019 at 3:54 PM Rob Sayre <sayrer@gmail.com> wrote:
>
>>
>>
>> On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>>
>>>>>
>>>> I see. But is there any reason to make these inputs predictably zero by
>>>> spec?
>>>>
>>>
>>> Absent some reason not to, this seems like a reasonable design choice.
>>> At minimum, it has the advantage that it's easy to detect some classes of
>>> implementation errors.
>>>
>>
>> I don't think the current spec is a good idea. It mandates padding with
>> zeros, and lets servers dictate a length. I think the client should dictate
>> the length, at least.
>>
>
> This is a separate issue from the structure of the padding.
>

I think the length of the padding might be fairly considered part of the
"structure of the padding".



>
>
>
>>> I wouldn't exactly call that misreading.
>>>>
>>>
>>> This seems like a definitional question that is not worth debating.
>>>
>>
>> Hey now, you're the one that wrote "misreading" initially. If "additional
>> data" is not what's used as "additional authenticated data" in the end,
>> fine.
>>
>
>  NSS does not include the leading 0s as part of the computation of the AAD
> that appears on the wire. To the extent to which you may have believed
> otherwise based on your reading of the code, that is not a correct
> understanding.
>

I see, so I should chase down every last obfuscated padding byte? I can't
actually read a draft to implement this spec.

I also do not think this issue should have been unilaterally closed:
https://github.com/tlswg/draft-ietf-tls-esni/issues/190

Maybe it's time for some new TLS editors.

thanks,
Rob

v2.23.0 | Report a Bug | By Email