Re: [dane] DANE, constrains and CT and similar....

Warren Kumari <warren@kumari.net> Tue, 10 December 2013 16:24 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E024C1AE08E for <dane@ietfa.amsl.com>; Tue, 10 Dec 2013 08:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 kjTSgymBYB98 for <dane@ietfa.amsl.com>; Tue, 10 Dec 2013 08:24:02 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A93F1AE07B for <dane@ietf.org>; Tue, 10 Dec 2013 08:24:02 -0800 (PST)
Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id EAC821B405C5; Tue, 10 Dec 2013 11:23:55 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <CABrd9SR8ttfj5Ymp6GGAmKTQ8KkCHUn_aQrZyZ0+B=tEt_wVTw@mail.gmail.com>
Date: Tue, 10 Dec 2013 11:23:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C699FAA6-3CC1-4F9A-AFCF-66A086A0A700@kumari.net>
References: <A06891E1-01E0-40CC-A9A2-171CAA39AB79@kumari.net> <20131205175314.GH761@mournblade.imrryr.org> <E78C07CA-B742-43B2-8848-33DEB22A8014@kumari.net> <201312080234.rB82YeoW029387@new.toad.com> <m3y53tg0c3.fsf@carbon.jhcloos.org> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> <CABrd9SSSPFOe7HGyFiH=8oP=cvQ-g6HEqBytY8h=bbVonwNR7w@mail.gmail.com> <52A73074.1050904@bbn.com> <CABrd9SR8ttfj5Ymp6GGAmKTQ8KkCHUn_aQrZyZ0+B=tEt_wVTw@mail.gmail.com>
To: Ben Laurie <benl@google.com>
X-Mailer: Apple Mail (2.1822)
Cc: IETF DANE WG list <dane@ietf.org>
Subject: Re: [dane] DANE, constrains and CT and similar....
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 16:24:05 -0000

[ No hats] 
[ Changed the subject to hopefully more correctly identify the discussion ] 


On Dec 10, 2013, at 10:22 AM, Ben Laurie <benl@google.com> wrote:
> 
>> On 10 December 2013 15:17, Stephen Kent <kent@bbn.com> wrote:
>>> Ben,
>>> ...
>>> 
>>> 
>>> I'm willing to consider it. But I'm still concerned that without something akin to CT, DANE is more dangerous than the existing PKI.
>>> 
>> Can you elaborate, without reference to CY :-)? DANE seems preferable because the DNS hierarchy constrains the range of names that a node may assert (validly), unlike the WebPKI model.
>> 
> I agree that there is this additional constraint. It doesn't really address the core problem, though, which is that registries and registrars, like CAs, are vulnerable to error, coercion and getting pwned. Registries are also in a great position to mount targeted attacks, unlike CAs.
> 
So, we had numerous discussions on this topic back at the beginning.

At the core of the discussion was the fact that an attacker who is able to manipulate the DNS can get a CA signed cert (the attacker points the MX to a box under their control, applies for a DV cert at www.certs-r-us.com, receives the authentication cookie mail and sends it back to the CA). This attack doesn’t allow the attacker to get a cert that requires special validation, and also doesn’t work for the special golden names)…

When we were having these discussions I think that a number of us had a somewhat different (and some would say naive) view of the threat landscape. I personally was more focused on the lone attacker scenario, and not the "nation state who doesn’t mind being noticed” attack.

In many / most cases the ccTLD operator is in country (I believe that ICANN now requires the cc Admin contact to be in county) and could be compelled to publish fake DS and NS records for a specific domain and serve a parallel DNS tree[0]. This would be technically tricky (what with caching and the difficulty of correctly doing key rolls even which all parties co-operating), but not impossible. It would (probably) be fairly noticeable, but this might be acceptable to the attacker.

The above is conceptually similar to just seizing the domain (like the ICE / DHS counterfeit seizures), but with DANE could allow the attacker to also get a lock icon.

Having something like CT but for DANE / DNSSEC would (IMO) be very useful — I believe that there was some activity on this front, any updates?

> Experience suggests that their record, on the whole, is less good than CAs.
> 

[0]: I’m using cc’s as an example here, but the same applies to gTLDs in the attacking country.

P.S: Apologies — for some reason my MUA refused to understand Ben’s quoting level. I tried to requote correctly but may be misattributing.


> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett