Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
Paul Wouters <paul@nohats.ca> Tue, 05 June 2018 13:51 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 6B04F130DCA for <tls@ietfa.amsl.com>; Tue, 5 Jun 2018 06:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable 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 waomIa4q9Ay8 for <tls@ietfa.amsl.com>; Tue, 5 Jun 2018 06:51:14 -0700 (PDT)
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 2CE8C130E31 for <tls@ietf.org>; Tue, 5 Jun 2018 06:51:14 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 410Y9m6kbzzDvS; Tue, 5 Jun 2018 15:51:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1528206669; bh=UNxkyfRKzD+yntPq4ckwz0MY8igpsvPzCe/EwOm281g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PKGaNBB7K5zagbCniqD/H3W5CHxqdbFREXeWQJseJAL9NBjOMBUw35s3Pw2S8zFI0 pn0S32t7/PGst1r8DeEh9joeZuRzvYkd8n/pH5PgYxt6blgnKE37Svrd4F3BTwMmY3 l7GjH4NlA0wxb40+n+I0ODDNglagqWQ+asOY1HGo=
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 01w5WZzzmy84; Tue, 5 Jun 2018 15:51:05 +0200 (CEST)
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; Tue, 5 Jun 2018 15:51:04 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CCBAB4FB76B; Tue, 5 Jun 2018 09:51:03 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CCBAB4FB76B
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C421B418A9B9; Tue, 5 Jun 2018 09:51:03 -0400 (EDT)
Date: Tue, 05 Jun 2018 09:51:03 -0400
From: Paul Wouters <paul@nohats.ca>
To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org>
cc: tls@ietf.org
In-Reply-To: <20180604203947.GW13834@akamai.com>
Message-ID: <alpine.LRH.2.21.1806050858340.8057@bofh.nohats.ca>
References: <20180604203947.GW13834@akamai.com>
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/jGr7tm9Vp4j8p0llT_1MDoR3AGo>
Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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, 05 Jun 2018 13:51:19 -0000
On Mon, 4 Jun 2018, Benjamin Kaduk wrote: Hi Ben, > I've taken a stab at putting together some security considerations text for > draft-ietf-tls-dnssec-chain-extension that reflects my understanding of the > current state of affairs. It's in a pull request at > https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with Viktor's > commit to update the text about the actual DNS records involved (which as > far as I can tell seems to improve the technical accuracy of the text), and > also inserting a variable-length array that's reserved for future attempts > to mitigate the (now-)documented security considerations. Thanks for writing the proposed text. The new opaque Reserved field along with the denial of existence changes you propose addresses all my concerns. One corner case that might be worth mentioning with the proposed DoE text is the odd corner case of hitting a server with a Host header for which it is not configured. You will hit the "default vhost" but you have no appropriate extension data to populate for that hostname. So either the server will return the (cached) TLSA/DoA data of the 'wrong' hostname, or it could just omit the extension. I'd mostly like to say something to prevent an implementation of forgetting this corner case and causing some vulnerability in their code later on by pointing to bogus memory or crashing on dereferencing a NULL. Some nits: If the server supports this extension it performs the appropriate DNS queries, In my PR I had changed this into "obtains the appropriate DNS RRsets", because I envision that TLS servers might not do DNS lookups themselves, but just read this via a file or other method. Eg a cron job that regenerates these hourly for all the hosted domains. It also reduces some fear that all TLS servers suddenly could need to link against a DNSSEC library. They don't if they can just reload a blob from disk regularly to serve up. Similarly: it will need to rebuild is better written as "it will need rebuilt data" "authenticates the chain" That should probably be "validate the chain", but the document has more mixups of validate vs authenticate. In my PR request I had not corrected them in an effort to keep the diff as small as possible. I had modified the examples slightly, so the NSEC example would show a simpler NSEC chain (from www to zzz) instead of the one wrapping around from www to the zone apex. The example quoted is the wrong NSEC record (the one from apex to www.example.com does not show that the _443._tcp.www.example.com does not exist, you need the one from www.example.com to the apex at the end of the zone) I'm not sure what you mean with: validated negative TTL I guess you mean to say the shortest TTL of any data in the chain? But sometimes the negative cache time is larger then the TTL (eg if TTL = 0) Since this is just generic DNS handling, I would probably just write something like "up to the appropriate lifetime" and leave it out of this document. denial of existence RRset Technically that should be "RRsets" since you usually will need more then one RRset to prove this (to disprove existence of the wildcard record) - DNSSEC authentication chain extension from a server, SHOULD use this + DNSSEC authentication chain extension from a server, uses this I'm not sure why the SHOULD was removed here? Since it is describing TLS client behaviour the "uses this" confuses me as I dont know if that means MAY, SHOULD or MUST. + Specifically, the relevant DANE records are included + in the TLS handshake transcript hash, so both sides + possess identical records; I'm not sure why you suggest to add this text. A TLS client might still have cached a valid TLSA records from a previous connection 1 second ago and might decide to not use this information at all. Also, it seems to suggest that the transscript hash protects this data, but it is "protection" using the webpki or proof of lack of MITM, but the data does not need this protecting as it is protected by DNSSEC signatures. + the client remains responsible + for actually performing the domain name validation of + the DANE records. Well, if it just fired up a previous TLS connection, perhaps it will be content with the same pubkey used and skip re-validating this data? I guess we sort of say the same thing due to the lack of a MUST ? + The Reserved field is reserved for future updates to this + document; in particular it is hoped that the issues discussed + in <xref target="increasing-trust" /> can be addressed. + Implementations of this specification MUST send a zero-length vector Perhaps that last line can be clarified a bit: Implementation not implementing any updates to this document MUST send a zero-length vector This sentence does not parse: "whether or not to the exclusion" This text is a little confusing to me: + certified by the DNS key hierarchy, that the + server does not support DANE authentication The TLS server itself might support "DANE authentication", but there is simply no data. Perhaps say that the server's configured hostname does not support DANE authentication? Thanks again for the write up! Paul
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Nico Williams
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Joseph Salowey
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Paul Wouters
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Bill Frantz
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Allison Mankin
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Paul Wouters
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Eric Rescorla
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Melinda Shore
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Eric Rescorla
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Martin Thomson
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Eric Rescorla
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Paul Wouters
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Paul Wouters
- [TLS] draft-ietf-tls-dnssec-chain-extensions secu… Benjamin Kaduk
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Viktor Dukhovni
- Re: [TLS] draft-ietf-tls-dnssec-chain-extensions … Paul Wouters