Re: [TLS] predictability of inputs in ESNI

Eric Rescorla <ekr@rtfm.com> Fri, 01 November 2019 23:04 UTC

Return-Path: <ekr@rtfm.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 6A4FF120A55 for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 16:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 zzAT0JVfVHPq for <tls@ietfa.amsl.com>; Fri, 1 Nov 2019 16:04:11 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 323B3120ACE for <tls@ietf.org>; Fri, 1 Nov 2019 16:04:11 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id j14so8306763lfb.8 for <tls@ietf.org>; Fri, 01 Nov 2019 16:04:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9JvmCylMOcXUW1nSYd6NcPbOAo5FsszsY1MdWHt+QqM=; b=A2CXf4fL+Gwc88c9aCa5+JOtQsIhDbcZkiVDvnbgBn/LoI1peQkM6CTsot5cg+GmrT n7z9+5USrWGn/s/I6SNPheHr/hG1C8o+9IKw0h9m9rvHjsuwolVVMVllGdb1iuIJJKWj cXphYTkOzBIqiNaQrnbmmeCcHoOrOJ0+9Ng0UXQgQJY5auOw9O+VNQ/Sa/ancunxLp56 c/uDy0c9RhXdG5ptEvPrs/UHpi1cfoISO1cTPEcCAcwmsn5nIUHNrJxocsgsJ4xALplF zxgcF8Nwc7nrBc90E8UNE0Zdf/zl+P5Bhrsud+nKgVjOinABBqn7bghc3+i0XQw7jtgm 95UA==
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=9JvmCylMOcXUW1nSYd6NcPbOAo5FsszsY1MdWHt+QqM=; b=AuBYR3F41tLw1edDIXBfFUbiR0DNrR52b+5O4C+H3ojxvS4EwEXbtloh39WNVYOMa1 F/hybtPMmMbOG5UsbSnjzKNDgjtaJOhCHnJLBjlGH2VMnHWNeIShqAudARJDk5ZZkwEC pktFkKKnCEGRKJ4HzOu0gsMtxONamzYjbSLxosOqHtIuLZSE1JrbCVbxtsWk6pIM+TI8 VwVxrbLDfFt2YYL6I1rh93bWu5iZLtxr58fw2cal3Sgn5NIWTZbNtL13sC+dts3MeFM9 eYD6AeFf0EyLaqLGrLbuL7+dqh3ktLbJi0faRIQtKFkPj8QxPoeCdDp0X87Qnr+fLoPs xbqQ==
X-Gm-Message-State: APjAAAUiyPoM362d1SyAMf7FXkXSYc+pXEkUePCzwxcu6wFz9WGy/L50 CoWi8Z+gmRwt0JMNOxeMxDjxGmbo9LI7jKlYHoDtSg==
X-Google-Smtp-Source: APXvYqyJ8p89draNbZ0UAesXhubv9oaHsNlWgwGa8SCXZs9ee9chtSQ5xBMAcHnH6YLK6SsA1R9EFve6AN8DcWACWVo=
X-Received: by 2002:a05:6512:75:: with SMTP id i21mr8528700lfo.180.1572649449328; Fri, 01 Nov 2019 16:04:09 -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>
In-Reply-To: <CAChr6Sxx3eni+1FLJNnyoimhYJofOoKg70Mev0xqvvDHHG=AYw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 1 Nov 2019 16:03:32 -0700
Message-ID: <CABcZeBO293Vdvfv1bAJofxqQqqmgwhmVhzdbSqb_b6zhhZwsTg@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
Cc: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c8b590059650fbb4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_mfvnDZNgyJ4JgKl3U7UOcKkmew>
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:04:15 -0000

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 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.

-Ekr