Re: https at ietf.org
Doug Barton <dougb@dougbarton.us> Tue, 10 December 2013 19:44 UTC
Return-Path: <dougb@dougbarton.us>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7134D1AE20F for <ietf@ietfa.amsl.com>; Tue, 10 Dec 2013 11:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 kERpdX74JRgY for <ietf@ietfa.amsl.com>; Tue, 10 Dec 2013 11:44:02 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1CA1ADFF5 for <ietf@ietf.org>; Tue, 10 Dec 2013 11:44:02 -0800 (PST)
Received: from [IPv6:2001:470:d:5e7:440b:a268:c270:bc99] (unknown [IPv6:2001:470:d:5e7:440b:a268:c270:bc99]) by dougbarton.us (Postfix) with ESMTPSA id C3FBD22B12 for <ietf@ietf.org>; Tue, 10 Dec 2013 19:43:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1386704636; bh=upln23zNgCie+fzQ6zHhZqvOs88zcQMbHS1RALGzWqk=; h=Date:From:To:Subject:References:In-Reply-To; b=G7cfkruHYcrA0WW9CZ7poJ8afJBaiH+mvs26uLz9h1/+7W0Qqt++KWoz63uWL0bj3 8BUP0J39iHZ3i9xDrgcfP/z9I0+REHN7N45VEpnS5oFt27Ux/Awg4GFIA5glkvQCOJ fnvjDaBkc853CZ/ObEcRuGeKFDAQJcF42P4Or+J0=
Message-ID: <52A76EFB.4040004@dougbarton.us>
Date: Tue, 10 Dec 2013 11:43:55 -0800
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: https at ietf.org
References: <20131125180608.55454.qmail@joyce.lan> <E5836934-317D-4E73-80CC-B8847047852A@virtualized.org> <CAMm+LwhXb6uYJLie1FmJE34aC0EO39_t7331X1O0iD=-gmSEvw@mail.gmail.com> <38B94CB1-C62A-4BAC-85D4-B08FB7315CE9@virtualized.org> <CAMm+LwhF5-nEdM0Rjh1XtK1X=_xo6GkqPnZgfGaCEJ19g8ULrg@mail.gmail.com> <52A176E0.1050708@dougbarton.us> <CAMm+LwiH=1446tXZLKxUyz+jpMHy573aAd5zg1_+Z4kEbVc33A@mail.gmail.com> <52A52972.3020601@dougbarton.us> <CAMm+LwiHwKkK1C7K+DG-LTBS=Edsn=AjH5hCe+9LOukVZbPjmQ@mail.gmail.com> <52A64A1A.2020000@dougbarton.us> <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@mail.gmail.com> <20131210005259.169F9B6E2F1@rock.dv.isc.org> <CAMm+LwhyXaOP8k8tZ6-cPrmmyXXjfgO=Jr5Jyf4S+WAZus1CWQ@mail.gmail.com> <E4EC4C3190EA749BAE7898DF@JcK-HP8200.jck.com>
In-Reply-To: <E4EC4C3190EA749BAE7898DF@JcK-HP8200.jck.com>
X-Enigmail-Version: 1.6
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 19:44:04 -0000
On 12/10/2013 06:00 AM, John C Klensin wrote: > > > --On Monday, December 09, 2013 22:39 -0500 Phillip Hallam-Baker > <hallam@gmail.com> wrote: > >> ... >>> For a similar reason removal of TLD's can't happen as people >>> can still graft on namespace and establish TA's for the >>> grafted on namespace. >> >> >> It is trivial to fix when the validation is taking place in a >> service in the cloud (aka a resolver). >> >> Rather less easy to do if people drink the DANE cool-aid and >> do the job at the end point. >> >> Now you can take this point as either arguing against doing >> DANE or considering the risk and deploying the appropriate >> control. But you do have to consider it. >> >> >> What you are in effect asserting is that the resolver >> providers are the apex of the trust chain and so there is a >> diffuse trust surface rather than a sharp point. Which is true >> when the validation takes place in the resolver. > > I am probably going to regret getting involved in this thread, GMTA :) > but I would draw two rather different conclusions from the above > and a number of other comments: > > (1) We have seriously oversold DNSSEC as a data quality and > reliability mechanism when it is merely a transmission integrity > mechanism. The former is about the DNS and associated > registration database (e.g., "whois") records being accurate, > secure, and maybe even information-containing. The latter is > merely about an assurance that the data one receives hasn't been > altered in transit in the DNS. > > Now most of the people who have been involved in the design and > implementation of DNSSEC have been quite careful about the > above, at least most of the time. But sometimes they are sloppy > about their language, sometimes they say "DNNSEC" and people > hear "DNS Security" and make inferences to data quality. More > important, there is an (illogical) chain of reasoning from > "DNSSEC is in use" to "[now] the DNS is secure" to "all of the > data provided by the DNS or its supplemental databases are of > high quality". > > While the integrity checks of DNSSEC provide some protection > against some types of attacks on the "data quality" part of the > DNS environment, the attacks they protect against are very > difficult. John, IMO you're spot on with all of the above. Especially about being careful with our language about what DNSSEC is designed to do. I try very hard to be precise, but it's good to have this reminder periodically. > An attacker with the resources to apply them would > almost certainly find it easier, less resource-expensive, and > harder to detect to attack registry databases (before data are > entered into DNS zones and signed), registrar practices, or > post-validation servers. Non-technical attacks, such as the > oft-cited hypothetical NSL, are easily applied at those points > as well -- much more easily than tampering with keys or > signatures. As previously mentioned, these attacks are theoretically possible, but they are trivially detectable since all of the critical data is visible in the DNS. They may not be _immediately_ detectable, and in fact likely would not be detected immediately; where "immediate" is going to vary widely depending on the value/profile of the target. But we have plenty of experience with people noticing DNS problems for critical resources. Even in the DNSSEC case we have major players doing DNSSEC validation now (Comcast and Google leap to mind) so shenanigans involving DNSSEC are going to be noticed. The point I'm trying to get across here is that any sort of manipulation of the DNS by a 3rd party (such as a malicious hack, NSL, etc.) is valuable only to the extent that it can go unnoticed, and therefore cause innocent end users to depend on the 3rd party's resources instead of the valid ones _without their knowledge_. We don't need DNSSEC to see that this sort of thing only works for a limited time. We have had lots of events where high profile sites have had their registrar data changed, and there is a huge public hue and cry. Of course a skillful attacker could create a phishing page that looks enough like the real site to gather a non-trivial number of user passwords, but again, we don't need DNSSEC for that. In fact, if the sophisticated attacker manages to socially engineer the registrar credentials (the most popular form of this type of attack) then they can update the DS record in addition to the NS records, and have a fake site that validates perfectly. But even that sort of attack would only work for a short period of time. More importantly, the ability to slide the malicious data into the DNS at all is going to be proportional to the location of the resource in the tree. We already know that individual zones are vulnerable to registrar attacks. However new TLD DS records in the root are greeted with fanfare (at least amongst a fairly substantial number of DNS wonks), so the ability to slip stuff in at that level is minimal at best. This is more true at the root itself. So to be concise (yeah, I know, too late) claiming that DNSSEC is vulnerable to external manipulation at the root or TLD level is almost certainly wrong. There are theoretical attacks that could be launched, but their practical value is nil. If someone has a valid attack that uses a method I haven't taken into account, they should find a trusted channel to make that known. > (2) In a different version of some of the comments on the > thread, the "where to validate" question is important. If one > tries to validate at the endpoints, endpoint systems, including > embedded ones, should have the code and resources needed to > validate certs and handle rollovers, even under hostile > conditions, and that isn't easy. If one relies on intermediate, > especially third-party, servers to validate, than much of the > expected integrity protection is gone... and the number of times > such servers have been compromised would make this a > non-theoretical problem even without concerns about > governmental-type attacks (NSL and otherwise) on those servers. > No easy solutions here. Again, spot on. I've been saying for many years now that the most interesting part of DNSSEC is going to be local on the end user side. Pushing validation all the way down is critical. > I don't know where that combination of situations leaves > initiatives like DANE, but I suspect we should be looking at > trust conditions and relationships a lot more carefully than the > discussions and claims I've seen suggest we have been doing. I like DANE a lot, and I think it has a critical role going forward. The problem is that it is only as valid as the registrar data for the zone. So it's not clear that DANE is going to be a complete replacement for a CA-provided cert. Doug
- Re: https at ietf.org Eric Burger
- https at ietf.org Tim Bray
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org David Morris
- Re: https at ietf.org Paul Wouters
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Dean Willis
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org Hector Santos
- Re: https at ietf.org Marco Davids (Prive)
- Re: https at ietf.org Hector Santos
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org Thiago Marinello
- Re: https at ietf.org Bjoern Hoehrmann
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org Ted Lemon
- authentication without https (was Re: https at ie… Dave Crocker
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: authentication without https (was Re: https a… Ted Lemon
- Re: https at ietf.org MAISONNEUVE, JULIEN (JULIEN)
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Marco Davids (Prive)
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Carsten Bormann
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Carsten Bormann
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org t.p.
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Arturo Servin
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org Chris Inacio
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org t.p.
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Chris Inacio
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Douglas Otis
- Re: https at ietf.org Pranesh Prakash
- Re: https at ietf.org Pranesh Prakash
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org John R Levine
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Joe Abley
- Coercion S Moonesamy
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org John Levine
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Michael Richardson
- Reconstruct the key S Moonesamy
- Re: https at ietf.org Randy Bush
- Re: https at ietf.org Randy Bush
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Sean Turner
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Doug Barton
- Re: [IETF] https at ietf.org Warren Kumari
- Re: [IETF] https at ietf.org Michael Richardson
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Mark Andrews
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Douglas Otis