Re: [TLS] draft-ietf-tls-esni feedback

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 23 October 2019 17:38 UTC

Return-Path: <ilariliusvaara@welho.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 BFC5A120BD0 for <tls@ietfa.amsl.com>; Wed, 23 Oct 2019 10:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 29Cw-wUyL0cn for <tls@ietfa.amsl.com>; Wed, 23 Oct 2019 10:37:58 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE78A120C34 for <tls@ietf.org>; Wed, 23 Oct 2019 10:37:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 83AC3350F; Wed, 23 Oct 2019 20:37:28 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 38DsIUIJKRNU; Wed, 23 Oct 2019 20:37:28 +0300 (EEST)
Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A865F7A; Wed, 23 Oct 2019 20:37:24 +0300 (EEST)
Date: Wed, 23 Oct 2019 20:37:24 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Rob Sayre <sayrer@gmail.com>, "TLS@ietf.org" <tls@ietf.org>
Message-ID: <20191023173724.GA472723@LK-Perkele-VII>
References: <CAHbrMsA0PFwvu3hvZgXMbe2Buzq9dQHgNJJLOqtyMUzb-qpc0A@mail.gmail.com> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <CAChr6SySVXsH1J7KGDJjjB=wdxhdaCe207pLn2fGFMmDb1q82w@mail.gmail.com> <BE5E7283-6EF4-4113-ADBA-7790A5DFACD8@akamai.com> <e20daa2c-b239-11e0-87e7-beaebb80aebf@cs.tcd.ie> <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> <CAChr6SyU_ArsKi16Bj47eZWVRMJ8wekFKAzFLENkUB31fSgPKw@mail.gmail.com> <CCF5D107-76AD-4311-A931-F0FB4D393147@akamai.com> <CAChr6SwM0cAH4ShJdw6WpV3rwLUPoaqB+imvv61XohLaLiS7jA@mail.gmail.com> <CACsn0ckMxahbVJAqJXVMpxjMQYG7y_qF+4KudYo-y1f9+DWyug@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CACsn0ckMxahbVJAqJXVMpxjMQYG7y_qF+4KudYo-y1f9+DWyug@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WlEPlu49knqcu09jvjYKzaKKrE4>
Subject: Re: [TLS] draft-ietf-tls-esni feedback
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: Wed, 23 Oct 2019 17:38:06 -0000

On Tue, Oct 22, 2019 at 10:39:24PM -0700, Watson Ladd wrote:
> 
> At the same time Client Hello sizes aren't constrained to be tiny, but
> the next problem of 1280 bytes is not that far off either. So we
> should be judicious in spending those bytes.

I do not think 1280 bytes is a big issue.

- If using QUIC, one expects fragmentation above 1200 bytes. I am not
  sure if fragmentation is presently allowed, but I am sure it is not
  pleasant to implement in robust way.
- For classical TLS over TCP, in practice one can push something like
  1400 octets or so in a single packet over virtually all paths.
- Present handshake sizes are AFAIK bit north of 256 bytes (still
  mostly padded to 512 to avoid old TLS server bugs). So sticking even
  350 bytes (256 for name plus 80 bytes crypto overhead plus few odd
  other bytes) extra would not blow any soft limits.
- With post-quantum, you are going to bust single packet limits no
  matter what, since:
  - SIKE is slow, so server operators probably prefer lattices as
    those are like two orders of magnitude faster than SIKE (or SIDH).
  - Lattices are roughly 800 bytes at minimum at reasonable security
    levels.
  - You are going to need two keys, because all the post-quantum
    ways of sharing one key are both even slower and more exciting
    (not in a good way) than anything in NISTPQC.


-Ilari