Re: [TLS] ESNIKeys over complex

Eric Rescorla <> Tue, 20 November 2018 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFBA0126CC7 for <>; Tue, 20 Nov 2018 15:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VW1pnV-vsgJW for <>; Tue, 20 Nov 2018 15:31:30 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F05D112D7EA for <>; Tue, 20 Nov 2018 15:31:29 -0800 (PST)
Received: by with SMTP id u6-v6so3199557ljd.1 for <>; Tue, 20 Nov 2018 15:31:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Tue, 20 Nov 2018 15:30:51 -0800
Message-ID: <>
To: Stephen Farrell <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000005e36cd057b210898"
Archived-At: <>
Subject: Re: [TLS] ESNIKeys over complex
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Nov 2018 23:31:33 -0000

On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell <>;

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

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


> [1]
> _______________________________________________
> TLS mailing list