Re: [TLS] ESNIKeys over complex

Paul Wouters <> Wed, 21 November 2018 07:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33525130EE2 for <>; Tue, 20 Nov 2018 23:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FMZkkfeqb9iv for <>; Tue, 20 Nov 2018 23:28:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBD27127332 for <>; Tue, 20 Nov 2018 23:28:54 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 430Dhg0x0wzLDj; Wed, 21 Nov 2018 08:28:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1542785331; bh=o8JKKh3CMh2LGtAnZz1GfRwOr5sTwbe+4E3cC5sIC0M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XUMHiSk4/55KAz79I8od/XjTzFumGrJg54eZ0ALEeH+pgMYYYGqMQqPkG0oCD9j/R RftXSE3O1blT+CXHMIvKnLpwIBQZrpiLmN2UsWdTfBhFWxFgYFNdMto8a/tCuUO7AF 0YaYUX/Dkj2t2iEeB+VNjaRaoN4296LzGm0YOh74=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LpI8mXU117PX; Wed, 21 Nov 2018 08:28:47 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 21 Nov 2018 08:28:46 +0100 (CET)
Received: by (Postfix, from userid 1000) id 088573797AD; Wed, 21 Nov 2018 02:28:45 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 088573797AD
Received: from localhost (localhost []) by (Postfix) with ESMTP id F06DD41C3B26; Wed, 21 Nov 2018 02:28:45 -0500 (EST)
Date: Wed, 21 Nov 2018 02:28:45 -0500 (EST)
From: Paul Wouters <>
To: Stephen Farrell <>
cc: Eric Rescorla <>, "<>" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
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: Wed, 21 Nov 2018 07:28:58 -0000

On Wed, 21 Nov 2018, Stephen Farrell wrote:

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

I think the SOA record is the only exception allowed (and there
is an exception to that when doing AXFR I believe)

Usually these things are defined as "pick the first DNS RRTYPE
that satisfies you".

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

You mean the problem of not being able to replay old data? :)

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

Note that TTLs are about the caching of data and nothing else. If
the content of your record requires some specific time of death,
you cannot rely on TTL. Note that a TTL on a received RRTYPE can
have any value under the published TTL on the authoritative server
if it was flowing through caching recursive servers. So you cannot
use a TTL for some other kind of expiry value for another protocol.
Also, DNS software sometimes enforces maximum and minimum TTL values,
so again, do not use DNS TTL for other protocol timing parameters.

Although, if I am correct, the epectation is that all of this data
will be used without mandating DNSSEC validation, so all these
security parameters could be modified by any DNS party in transit
to try and break the protocol or privacy of the user. The "not DNSSEC
camel" is growing fast.