Re: [TLS] ESNIKeys over complex

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 21 November 2018 00:36 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 398A2130EAE for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 16:36:50 -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 v4FPF_NCCbly for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 16:36:47 -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 18222130E11 for <tls@ietf.org>; Tue, 20 Nov 2018 16:36:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CA248BE55; Wed, 21 Nov 2018 00:36:44 +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 ToyF9Us75elK; Wed, 21 Nov 2018 00:36:42 +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 A4595BE2C; Wed, 21 Nov 2018 00:36:42 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1542760602; bh=x7INueWJEwm1FRbnQNzbKtT19jSfKfnRmOUIekiDJG4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=biyEb02A50mxug/l1VIl1z73EvhZ9ppGuDoumgi771tO0yEEwJq0s5uFaKFCPrTcy Q+FMklC0yrmXEQm46J154EEGnvvrXUC8T7WPtEax/3YMJ0ZLj/EcLyexf2ZfdUs8n1 NNTT50rXUp9ctMO2vzKODdwKtjXNi4ktIfVI3rhc=
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>
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: <70290643-cf98-44de-ca6e-2cae4584d750@cs.tcd.ie>
Date: Wed, 21 Nov 2018 00:36:41 +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: <CABcZeBMNqkepLzdoPFV7UTuKUqPU6_AJjU7iMnUhDpdK6qr6RA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JvXuiO5eCkgTXWZenzpWKwufCfaFDXXOZ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ksQcHIFqclKVjFJcyly87B2TOPw>
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 00:36:50 -0000

Hiya,

On 20/11/2018 23:30, Eric Rescorla wrote:
> On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
> wrote:
> 
>>
>> Hiya,
>>
>> I've started to try code up an openssl version of this. [1]
>> (Don't be scared though, it'll likely be taken over by a
>> student in the new year:-)
>>
> 
> Thanks for your comments. Responses below.

Ditto.

> 
>>From doing that I think the ESNIKeys structure is too
>> complicated and could do with a bunch of changes. The ones
>> I'd argue for would be:
>>
>> - use a new RR, not TXT
>>
> 
> This is likely to happen.
> 
> - have values of ESNIKey each only encode a single option
>>   (so no lists at all) since >1 value needs to be supported
>>   at the DNS level anyway
>>    - that'd mean exactly one ciphersuite
>>    - exactly one key share
>>
> 
> I don't agree with this. It is going to lead to a lot of redundancy because
> many
> servers will support >1 cipher suite with the same key share. Moreover, from
> an implementation perspective, supporting >1 RR would be quite a bit more
> work.

Aren't DNS answers RRsets? I may be wrong but I thought DNS
clients have to handle that anyway, and I'd expect use of
RRsets to be a part of figuring out a multi-CDN stpry.

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

> 
>    - no extensions (make an even newer RR or version-bump:-)
>>
> 
> Again, not a fan of this. It leads to redundancy.

That's reasonable. OTOH, it's equally reasonable to say that
we're dealing with an experimental draft and a future PS
version could use another RRytpe and add extensions if they
end up needed.

> 
> 
> - 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. 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.)
And having to deploy a cron job equivalent for the DNS
data is an order of magnitude harder than not.

> 
> - get rid of padded_length - just say everyone must
>>   always use the max (260?) -
> 
> 
> I'm not in favor of this. The CH is big enough as it is, and this has a
> pretty big impact on that, especially for QUIC. There are plenty of
> scenarios where the upper  limit is known and << 160.

True, big CH's are a bit naff, but my (perhaps wrong)
assumption was that nobody cared since the F5 bug. It
seems a bit wrong though to have every domain that's
behind the same front have to publish this. I'm also
not sure it'll work well if we ever end up with cases
where domains A and B both use fronts/CDNs x and y and
can't figure out a good value as x prefers 132 and y
prefers 260.

How about rounding up to the nearest power of 2 that's
bigger than 5? (Or some such.) Very long names might
lose some protection, but I'm not sure that's a big
deal and one can likely just register a shorter name
for applications using ESNI.

> 
> 
> that needs to be the same
>>   for all encrypted sni values anyway so depending on
>>   'em all to co-ordinate the same value in DNS seems
>>   fragile
>>
> 
> It only has to be the same for all the ones in the anonymity set, and they
> already need to coordinate on the key.

Saying that every key share in DNS needs to be published
with the same padded_length would be ok actually. (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'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
>>
>