Re: [TLS] ESNIKeys over complex
Paul Wouters <paul@nohats.ca> Wed, 21 November 2018 07:28 UTC
Return-Path: <paul@nohats.ca>
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 33525130EE2 for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 23:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 FMZkkfeqb9iv for <tls@ietfa.amsl.com>; Tue, 20 Nov 2018 23:28:55 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD27127332 for <tls@ietf.org>; Tue, 20 Nov 2018 23:28:54 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 430Dhg0x0wzLDj; Wed, 21 Nov 2018 08:28:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; 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 mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LpI8mXU117PX; Wed, 21 Nov 2018 08:28:47 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Nov 2018 08:28:46 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 088573797AD; Wed, 21 Nov 2018 02:28:45 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 088573797AD
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F06DD41C3B26; Wed, 21 Nov 2018 02:28:45 -0500 (EST)
Date: Wed, 21 Nov 2018 02:28:45 -0500
From: Paul Wouters <paul@nohats.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: Eric Rescorla <ekr@rtfm.com>, "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <8546c227-a5e1-e17b-edce-ca173c8cfa81@cs.tcd.ie>
Message-ID: <alpine.LRH.2.21.1811210215540.4260@bofh.nohats.ca>
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> <8546c227-a5e1-e17b-edce-ca173c8cfa81@cs.tcd.ie>
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: <https://mailarchive.ietf.org/arch/msg/tls/o_OrVBvYcu54VVjrWkZcTNo9e6U>
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 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. Paul Paul
- [TLS] ESNIKeys over complex Stephen Farrell
- Re: [TLS] ESNIKeys over complex Eric Rescorla
- Re: [TLS] ESNIKeys over complex Stephen Farrell
- Re: [TLS] ESNIKeys over complex Eric Rescorla
- Re: [TLS] ESNIKeys over complex Stephen Farrell
- Re: [TLS] ESNIKeys over complex Salz, Rich
- Re: [TLS] ESNIKeys over complex Eric Rescorla
- Re: [TLS] ESNIKeys over complex Salz, Rich
- Re: [TLS] ESNIKeys over complex Eric Rescorla
- Re: [TLS] ESNIKeys over complex Paul Wouters
- Re: [TLS] ESNIKeys over complex Florian Weimer
- Re: [TLS] ESNIKeys over complex Eric Rescorla
- Re: [TLS] ESNIKeys over complex Ilari Liusvaara
- Re: [TLS] ESNIKeys over complex David Fifield
- Re: [TLS] ESNIKeys over complex Ilari Liusvaara