IETF Logo Mail Archive

Re: [TLS] ESNIKeys over complex

Eric Rescorla <ekr@rtfm.com> Tue, 20 November 2018 23:31 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 CFBA0126CC7 for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 15:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VW1pnV-vsgJW for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 15:31:30 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 F05D112D7EA for <tls@ietf.org>; Tue, 20 Nov 2018 15:31:29 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id u6-v6so3199557ljd.1 for <tls@ietf.org>; Tue, 20 Nov 2018 15:31:29 -0800 (PST)
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=Nbp4Ko7LHVqoxvwYE37WTc+yQJaKD6CW+9GIK8XJbcQ=; b=JxOFgUW1iSbGH4Sbryku4E292DR/A4mtL7L55cG0C083QZGPSaZyNXoOm2+I67iaXx Z9Ga/R3OP05FgiexIQ6VATjW3aZBHsvMdClWK13+rtWXVBCUNWNvZstPhx4rAPsyl4rn EiRf/KjNUdKDPjsmLBedLQwKj3cT+ohZIOLonZ46evP2hy9JmWIx+yYM55xIKOC+ZCMI ewFBhDfmfUx3/YNONp8NQF3Rt3eatfL6hFJCtZIQvcN/2icVvl723gdd+9fPEhEhUh0Z KwEU2VXV6ob73qUIhxQnz8tKYKjeycBLuYQlCBifuds3DUn4zbhA+WrOYxlaiZIw4Ae9 E06Q==
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=Nbp4Ko7LHVqoxvwYE37WTc+yQJaKD6CW+9GIK8XJbcQ=; b=BaG0ZVrhkO6a1MA1ZHKDTaI9P8hoedMCebVVa5E3ESTufG0pmb2YqLCyZTdtCXMfMu 5uo0pUlrZvItDY8t4viV90+9vZRaHPt99x9oSiyVPqGwt0p12LWk3SUSjX4orUpSjF0r XJm0WqEjFC/573oT0bmVQqMuArlTG10XglYxsaIR/p+FTqUP1hkFNVczWs6kmZoYeCk0 vXo+FnDGLOwNUtBsXLeQvoKyq89yEWzQJs3IF5DN7NAlMEM98Yxmm6QXiLOpQqedCGrf 6OWKGHRJnUe2GZXc6f4Z/v0C0hAuPaZTQn2bqbL6cvUYjviSgnWrh8NMlDNLCcKEdzSH Aw1g==
X-Gm-Message-State: AA+aEWbKq6PgqJzHunWCaMMcKV2uB8GJvk0B0d1PuKE6rzDWJQkTG/Np GRNR23I+TSAq87AbWDWPvmlgIVLmSM8dcb9INAaeLQ==
X-Google-Smtp-Source: AFSGD/X3tnDIv67bTVwyuiBBIToM3MWmEy5rP4lJf2hWeUMO6qo/PcnnRxEYXISXWLNFam94WO2BsCUoqO12So6KfqE=
X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr2634585ljb.51.1542756688075; Tue, 20 Nov 2018 15:31:28 -0800 (PST)
MIME-Version: 1.0
References: <797cd94d-b5be-24fd-923c-53b614cbc2c5@cs.tcd.ie>
In-Reply-To: <797cd94d-b5be-24fd-923c-53b614cbc2c5@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 20 Nov 2018 15:30:51 -0800
Message-ID: <CABcZeBMNqkepLzdoPFV7UTuKUqPU6_AJjU7iMnUhDpdK6qr6RA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005e36cd057b210898"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VjOg0MMlh9_QLhP4Lec-qyX10Yc>
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: Tue, 20 Nov 2018 23:31:33 -0000

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.

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

   - no extensions (make an even newer RR or version-bump:-)
>

Again, not a fan of this. It leads to redundancy.


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


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


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.




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

-Ekr



> [1] https://github.com/sftcd/openssl/tree/master/esnistuff
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email