Re: [DNSOP] draft-fanf-dnsop-trust-anchor-witnesses-00.txt

Joe Abley <> Mon, 24 February 2014 21:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E26E91A0277 for <>; Mon, 24 Feb 2014 13:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eSdpF_Mki1wb for <>; Mon, 24 Feb 2014 13:03:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::236]) by (Postfix) with ESMTP id 136311A018D for <>; Mon, 24 Feb 2014 13:03:06 -0800 (PST)
Received: by with SMTP id w7so7498647qcr.41 for <>; Mon, 24 Feb 2014 13:03:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cXhxJyE6Se8tPEbORgof9hScvqxwtmXEcO+rWTD9etc=; b=ZpzW8N0kDWvdt92/ehu9fuGPpN2EOM08/Ay5P9CbemyNdGOTRWK5duXKPsJ0Rvwm6q t6JwZ6c7tvJ+T5yNg1wftQVM9ftZbpJnVXrUzM4qG3hbavMrWXTqIV3MkKfmsPNBWvy9 KESsSGmQBpnQc7UE1KDb39vdwDD1uAWTDEhA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=cXhxJyE6Se8tPEbORgof9hScvqxwtmXEcO+rWTD9etc=; b=S6kRd1pT0RzGh0v7/27YmD6z+E2Zbid77b6eWOqxzQsPJPgmvrU0UmyF/z0hdZZ7Xw BzEhyKnkH3bnNPRCKqwYeR2L/DNqMaGaDcHUGNIm+raGVE2sli3XSGo4zNxMoQQedDQp HPzRbmy0T01msduVLUDxQpA6QnQKFTGWUHURLqxo76gWt37dQlZVOQeCVsmBRxmwVr0D QGOLAKtL3i/g7BcNLK+XB1jozHqUwl8FOmRpyv9g03vARx4H1dfyWlfHGFqbO9LTAC0R XIZqnmDYdg3PFIo0PGDtRh3yHY70SE6ADpn8X6FgePiqZSIV+1O6eKhF3saQUB/U6J8v 778w==
X-Gm-Message-State: ALoCoQnfVxKpTrr/a1t1EbBf9sPnxJKXk20ktJ1jV3E9qpCEw4i4iCfXhRfQ1uvf/m+g/FDSKAAf
X-Received: by with SMTP id t8mr33266390qat.26.1393275786270; Mon, 24 Feb 2014 13:03:06 -0800 (PST)
Received: from ?IPv6:2001:4900:1042:1:71e9:14e2:dba2:7ffd? ([2001:4900:1042:1:71e9:14e2:dba2:7ffd]) by with ESMTPSA id k61sm27051039qge.12.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 13:03:05 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0E52EFA1-5955-4617-B5F4-18F331FE0C2A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Joe Abley <>
In-Reply-To: <>
Date: Mon, 24 Feb 2014 16:02:56 -0500
Message-Id: <>
References: <> <> <>
To: Tony Finch <>
X-Mailer: Apple Mail (2.1827)
Cc: dnsop <>
Subject: Re: [DNSOP] draft-fanf-dnsop-trust-anchor-witnesses-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2014 21:03:13 -0000

Hi Tony,

On 2014-02-14, at 16:02, Tony Finch <> wrote:

> I think it's fairly obvious that I wrote just enough to get the idea
> across in a reasonably complete form, but didn't bother with thorough
> references (in particular not to your previous work, sorry!) or thorough
> review of formal terminology.

Right, completely understood. That's how I read it.

>>>   o  The concentration of trust in the root is politically
>>>      uncomfortable.
>> This may be true, depending on exactly what you mean, but I doubt it's
>> universally true (perhaps not even widely true). I'm not sure I
>> understand the motivation for including that statement has in a
>> technical specification, especially when you consider that the intended
>> trust mechanisms were designed to be dispersed amongst multiple (e.g.
>> vendor) authorities.
> Unfortunately the X.509 signatures do not disperse trust, they duplicate
> it. A bootstrapping validator trusts (== is vulnerable to compromise of)
> any one of its X.509 CAs.
> The key point of the quorum-of-witnesses idea is that no single witness is
> trusted in the way that an X.509 CA is.

I think there's an inherent assumption here that by validating a certificate, a bootstrapping validator might be vulnerable against any one of the various attacks that have afflicted browsers, the core problem there being that of the browser list and not the mechanics of validating a certificate.

To be clear, what was imagined was that a codebase which already has the ability to validate signatures over (say) software updates would easily be able to validate a certificate retrieved from that has the same kind of signature.

The IANA people imagined that they would solicit specific signatures from specific keys relevant to bootstrapping, not that they would obtain signatures from commercial CAs and trust the browser list to do the right thing.

Since the security of iOS (to choose an example at random) already relies upon the ability to validate signatures made by some Apple private key, using that same key to validate the integrity of a trust anchor bundle retrieved in the clear seemed like a nice easy way to import trust in something for which trust is important.

As I mentioned, no such vendor has done this. This is just for clarification, not because I think it's a better mechanism than the one you proposed.

>> The existing mechanisms (again, lamentably light on implementation)
>> would also facilitate this. The mechanisms in the validator-bootstrap
>> draft I referred to earlier allow trust anchor retrieval with no ability
>> to validate, authenticating the retrieved data using appropriate local
>> methods (e.g. the key that signed the code is used to test the signature
>> of the data the code retrieved).
> However the existing mechanisms rely on a lot of infrastructure which has
> to be accessed with validation turned off. My root witnesses idea uses
> only the DNS and leaves validation switched on while bootstrapping.

I think validation categorically needs to be off until the validator has been bootstrapped (not just for this proposal, but in general). No validation is possible before you have a stable sense of time and a trusted set of local DNSSEC trust anchors. Acting as though you are validating when you can't possibly be seems like a bad idea, since if you can game validators to get stuck in that state you've defeated DNSSEC.

We tried to spell this out in draft-jabley-dnsop-validator-bootstrap.

It occurs to me that we now have three drafts that speak to an active need (and try to fill a gap in DNSSEC deployment that at least some of us think needs to be filled):


It's not entirely obvious that dnsop is the right place for these (maybe we should talk to opsec? homenet, in the sense that these mechanisms need to be automatable without local operators?). But I think if they are going to go anywhere they need thorough working group review, and should not proceed as independent submissions -- this is an important set of definitions for real-world operation of the IANA root zone, and it needs to be as right as we can make it.

Suz/Tim/ADs: opinions on whether this is a useful bundle of work for dnsop? (No, I'm not (necessarily) requesting another agenda slot for London :-)