Re: [TLS] predictability of inputs in ESNI

Rob Sayre <sayrer@gmail.com> Fri, 01 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 4F5E1120828 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 15:54:15 -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 aC2k2seHnKHU for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 15:54:13 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 6487E120801 for <tls@ietf.org>; Fri, 1 Nov 2019 15:54:13 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id j2so7843032ilc.10 for <tls@ietf.org>; Fri, 01 Nov 2019 15:54:13 -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=o8khKGrX0KYCoNj3Dl45E6gUOVAXvxEsricAtwCQpQA=; b=t6mCSyIQ1zpmUjBFAXXkyzgdsP1rJccqdkSGgBduRmsNVa4TkvhEqMxG+q25Zz9cCt 6cxWggoP0NUXsiiYIEMZjOratQxNttbc5Qop35gOnU4EF95TrXOrXVWpNndxX9j8xLE2 1fUflRBi/GMwSFbGyRUX1ySu84Hm+7bFGn/ZuIuTs+tsEzw20g7b7DR8S8dv5DfMF2z2 bV90ic4vUDcYwTmVlYLVjUhqXGmPfbHpb25BtKFRtQLBz2V3Q7z8OUxCRnXI7hAGwXnr qqOQfrjr3b+mv4/GIvzZcaE8b84NItS23fQ/lO7DZ1ACSRxki89r831dNO/OugL3KkKp LGxg==
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=o8khKGrX0KYCoNj3Dl45E6gUOVAXvxEsricAtwCQpQA=; b=CA00SG1dIhOIqQCd9h/OGhkv22lp2roTiaLALCWoz4Wsr6B0pe6oQLWkN8GR5UBVFH z8dKQF8ZmYm0oLm8zoRv7Sn6LPQ99jP7tjdbXpO0p4ZBP2Zc36/xVhmi0OKBoDkuKgGZ ZxcPHfr5cepg1n4eUf8UAkSkSLA6njZwuct3xRmmWVnDep6XrcJPVGe2X8JoVYC+fn58 Au0EpWmMylMqBvOrv0ZuNmDPwmgl4hxMvYQWRZ6W5OppIoZbmkHgLESlR/7/p9/MerxW BpYypNNCIvvkd4aljeM+e1I2soyeHc4Dz7SyRBHZFZ0EpKYbIrgOGDSzpHOANtqQ8wdB ypOg==
X-Gm-Message-State: APjAAAUixvQ7N4JvnwM/yMFnA2CXc/LgNhJjRlmfPfej56k92erNmkC7 qmZ0r3OFdCLUjWjpwLzF96+87G3GczBfjbhLlvhXj5ijP5I=
X-Google-Smtp-Source: APXvYqwtRzrTj1gv7xn9WwU4FTDJ6GoZsWKs+MHQ9tZgUkPSHxOQpQl7m+blH8gFCNyd2ZnaBSYTvj9wvAesjKbanDE=
X-Received: by 2002:a05:6e02:a:: with SMTP id h10mr15123763ilr.254.1572648852392; Fri, 01 Nov 2019 15:54:12 -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>
In-Reply-To: <CABcZeBPBGmYaaqDRnhHk=i5cBYA2_1cwkkRvVStEdT-OGoR-0A@mail.gmail.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Fri, 1 Nov 2019 15:54:01 -0700
Message-ID: <CAChr6Sxx3eni+1FLJNnyoimhYJofOoKg70Mev0xqvvDHHG=AYw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000034128f059650d837"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fzzT15pWcignKl1Nh3JTaA7zjZg>
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 22:54:16 -0000

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.



> 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD
>>>> input (<https://github.com/tlswg/draft-ietf-tls-esni/issues/190>)
>>>>
>>>
>>> I believe you're misreading the code. For historical reasons, the
>>> internal NSS TLS AEAD API prefixes the AAD argument with the sequence
>>> number. When we repurposed this code for ESNI, we just passed in a 0
>>> sequence number. That value is stripped off and is not part of the AAD
>>> computation.
>>>
>>
>> I see, so you're saying that NSS adds 8 bytes to the AAD input, and then
>> strips it off at some later point?
>>
>
> No. I'm saying that the function argument is called |additionalData| but
> that's not what's used as AAD in the actual cryptographic function.
>
>
> 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.



>
> Maybe something to fix?
>>
>
> This is not on topic for this mailing list.
>

I think it is, since no one could read any ESNI draft and get the DNS
record's checksum right, at the very least. So, there are some issues where
it can be hard to tell if the spec is wrong, my implementation is wrong, or
another implementation is wrong.

thanks,
Rob