Re: [TLS] ESNIKeys over complex

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 21 November 2018 01:27 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 47905130E18 for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 17:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 il142tjGMVSx for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 17:27:25 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DEC12896A for <tls@ietf.org>; Tue, 20 Nov 2018 17:27:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4458CBE55; Wed, 21 Nov 2018 01:27:23 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X18bx8IdCGgT; Wed, 21 Nov 2018 01:27:21 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1D995BE4D; Wed, 21 Nov 2018 01:27:21 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542763641; bh=gzK1xCGRhpeImRITUrz1mTeuWyt9MZlP3vfDxfbvYs8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=SIu+emSTKRTa0hMuX2/r+RnD6RsiYcLyuajVB/0nFOOy6UxkVEQm878UJF4cmDQTV yGix68EwEGn4n2RDAbbI0BaOccnxgk2i1Nab8js63lrRyT1c8l2eEZ3hL2jT0lAhaw PQ4KHuSBzJQ6n7loWSpax+NufPycHDs8JQULgHBg=
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
References: <797cd94d-b5be-24fd-923c-53b614cbc2c5@cs.tcd.ie> <CABcZeBMNqkepLzdoPFV7UTuKUqPU6_AJjU7iMnUhDpdK6qr6RA@mail.gmail.com> <70290643-cf98-44de-ca6e-2cae4584d750@cs.tcd.ie> <CABcZeBOp+auFAwc7_+DjEy0JJbvqzs-1Z30h-tFveesm9gwHEg@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <8546c227-a5e1-e17b-edce-ca173c8cfa81@cs.tcd.ie>
Date: Wed, 21 Nov 2018 01:27:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBOp+auFAwc7_+DjEy0JJbvqzs-1Z30h-tFveesm9gwHEg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1wzIT3UR7d5GcbIGDqsNXng7BEcm02RP4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/C37Ae_1P8dulpc5M6Q3o-8-k8kQ>
Subject: Re: [TLS] ESNIKeys over complex
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, 21 Nov 2018 01:27:29 -0000

(Trimming bits down...)

On 21/11/2018 00:59, Eric Rescorla wrote:
> On Tue, Nov 20, 2018 at 4:36 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
>> Aren't DNS answers RRsets? I may be wrong but I thought DNS
>> clients have to handle that anyway,
> 
> 
> Not really, because any of them is co-valid. 

Sure, in DNS terms.

> We currently permit >1 RR, but
> actually
> I suspect that it would be better to try to restrict this. 

Not sure we can and I suspect that'd raise DNS-folks' hackles,
but maybe I'm wrong.

>> That said, >1 ciphersuite wouldn't be so bad if that were
>> the only list per RData instance. Or maybe one could get
>> rid of it entirely via some conditional link the to set
>> of suites in the CH, not sure. (Or just go fully experimental
>> and say everyone doing esni for now has to use the same
>> suite all the time.)
>>
> 
> I've implemented this and did not find it to be a major obstacle.
> I do not think unnecessary duplication is a good tradeoff for
> such a trivial implementation complexity reduction.

Sure a list of ciphersuites isn't bad. But the current
design has a set of keys and a set of ciphersuites and a
set of extensions and a set of Rdata values in the RRset.

Surely we can collapse at least most of those down to
one list without too much of a problem. And as to trivial,
I'd bet a beer on such complexity being a source of bugs
every time.

> I don't see any advantage to choosing a suboptimal design, just
> based on it being Experimental.

All designs are suboptimal for someone:-)

>>> - get rid of not_before/not_after - I don't believe those
>>>>   are useful given TTLs and they'll just lead to failures
>>>>
>>>
>>> I'm mostly ambivalent on this, but on balance, I think these are useful,
>>> as they are not tied to potentially fragile DNS TTLs.
>>
>> If there were a justification offered for 'em I'd be
>> ok with it, but TBH, I'm not seeing it. And my main
>> experience of the similar dates on RRSIGs are that they
>> just break things and don't help.
> 
> 
> This has a totally different expiry behavior from RRSIGs, so I'm
> not sure that's that useful an analogy.

Disagree. They're both specifying a time window for DNS data.
Same problems will arise is my bet.

My main ask though for these time values is that their presence
be explicitly justified. That's missing now, and I suspect won't
be convincing, but maybe I'll turn out to be wrong.

>> Put another way, I
>> don't know what sensible code to write to decide between
>> not connecting or sending SNI in clear if one of these
>> dates is out of whack. (I be tempted to just ignore the
>> time constraints and try send the SNI encrypted instead.)
>>
> 
> You should connect with SNI in the clear.

As a generic browser, I guess so. As some specialised
privacy sensitive application, not sure. As a library
that could be used for either, I'm not clear there's a
good answer other than ignoring the artificial time
window and encrypting anyway.

> And having to deploy a cron job equivalent for the DNS
>> data is an order of magnitude harder than not.
>>
> 
> Nothing stops you having an infinite expiry.

Nothing stops us deleting the useless dates:-)

> They will also use different keys for x and y, so they will
> have different records and can have different pad lengghts.

All going well, yes. All not going well, the pad lengths
may get out of whack, exposing names.

> How about rounding up to the nearest power of 2 that's
>> bigger than 5? (Or some such.)
> 
> I don't know what this means.

Ah sorry. I meant just take the length of the server
name and pad to the shortest of 32, 64, 128 or 256
octets. (Or some other breakpoints.) I'm sure we could
do some measurement so that an acceptable fraction of
names fit in the shortest bucket. (Didn't DKG do work
on that for DNS padding?)

>> (As a
>> nasty hack, you could even derive the padded_length
>> from the value of the key_share and fronters could just
>> keep generating shares until they get one that works:-)
> 
> I thought you were complaining about complexity

That's not complex, it's just waay hacky:-) It'd actually
be simpler for the client to just take some (e.g. low order)
bits of the key share as the padded_length. More work for
the people generating the key share yes, (they need to keep
iterating 'till they find a key share that works for their
preferred padding_length) but that's easy, offline, done by
fewer folks and removes a way of screwing up the ops.

All-in-all, while it's too hacky it's not complex at all.

Cheers,
S.

> 
> -Ekr
> 
> 
>>> - I'm not convinced the checksum is useful, but it's not
>>>>   hard to handle
>>>> - (Possibly) drop the base64 encoding, make it DNS operator
>>>>   friendly text (or else binary with a zonefile text format
>>>>   defined in addition)
>>>>
>>>
>>> We are likely to drop the base64 encoding.
>>
>> Ack.
>>
>> And just to note again - I suspect a bunch of the above would
>> be better sorted out as ancillary changes once a multi-CDN
>> proposal is figured out.
>>
>> Cheers,
>> S.
>>
>>>
>>> -Ekr
>>>
>>>
>>>
>>>> [1] https://github.com/sftcd/openssl/tree/master/esnistuff
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>
>>
>