Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738CC3A69B0 for ; Sun, 31 Oct 2010 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knOaQopE1htr for ; Sun, 31 Oct 2010 10:37:01 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id A4E0F3A69F0 for ; Sun, 31 Oct 2010 10:37:01 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id A75BD63406F; Sun, 31 Oct 2010 10:39:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=XT6jaPZrnqQNugmC0BSp7FFF/+dBe9sMaAbHokGdGY8 yZWpKZ+HMHGcqkFy7yswzVB0R4hP4Mv5AzIVLzj4UEUkBc9Hk4n2GwIfGqjNuZbX gsZWFSuNX87k+g6ycSe0MGMQ7HO0W0qGxF8vqFfapkIjRDLHL14uTMR+8AShYzFU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=EdPjXrpTP6eAau6mgpEhqhLIyKA=; b=kbKjS3W/92 DBBk9Yc7eaoWsNrNvZiCsWOwoTOdpE+/dXwfDYZXp++ekHpHUbAg9gbwuXJaCwg7 LWVPFH+YHiWCrCCdApZK5eh1ex+RXmM1DCYyo8iuhfj1a9ntM0FWHo+TWv5j9bEq KyicZQLaziR6fLW5Yk7dxRhwpUePhfoiY= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 64C3263406C; Sun, 31 Oct 2010 10:39:00 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> <1288470572.1977.210.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Sun, 31 Oct 2010 13:38:58 -0400 Message-ID: <1288546738.2156.52.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 17:37:03 -0000 On Sat, 2010-10-30 at 21:48 -0400, Phillip Hallam-Baker wrote: > We have multiple protocols in use at most sites on a given domain. > > The easiest way to get to critical mass in my view is to enable sites > to deploy for SMTP, IMAP, POP and other protocols where SSL is used > but the clients do not make much use of the CA infrastructure > and there is no use of EV. Umm, all the protocols use the CA infrastructure to make boolean accept/reject decisions for certificates. I guess you mean other use of the certificate information? Sure. But I'd argue the same is true of non-EV web sites: I haven't seen any meaningful use made of the certificate information there. Browsers will show you the certificate under which the main HTML page was received, but that tells you nothing about any other acceptable certificates floating around that might allow others to tamper with the page under the same-origin policy. > To make that practical it has to be possible to have statements of the > form 'only trust these certs for protocol X'. Or simply make the statement "trust this cert" specific to the protocol by placing the record at the SRVName. That seems more elegant to me. > The other reason for wanting something other than a flag is that > managing public keys on a large scale is time consuming and requires > infrastructure. That infrastructure already exists for X.509/PKIX, > many if not most enterprises who would be possible early adopters of > this type of management scheme already have an X.509/PKIX > infrastructure deployed. > > So for those domains it is going to be much easier to publish a > statement 'all valid certs fall under this hierarchy' than 'all valid > certs have a fingerprint'. Good point. This is probably true of my university, which just made a deal with a public CA to provide all their certificates. Will it work to accept a presented certificate that either matches or chains up to a TLSFP certificate? Then one could publish the hash of the end-entity certificate or some intermediate or root certificate, possibly modified (and re-signed, the client doesn't care about the signature anyway) to apply whatever extra PKIX-y restrictions the software might support. Any certificates the client can't be assumed to have and the server doesn't send can be published in unassured CERT records. > No, I am saying that it has been very difficult to get anything that > falls under the 'security policy' bracket accepted as a WG charter > item because security policy is a notorious rat hole. > > What we are proposing is a set of protocol specific security > assertions and not a security policy processing mechanism. > > So what I am saying is that I think we can craft a very precise > statement that allows us to do exactly what we would like to do > without triggering rodent dwelling concerns. Good. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EE33A677E for ; Sun, 31 Oct 2010 09:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GmQzNWIN3hf for ; Sun, 31 Oct 2010 09:38:07 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0B7DF3A69B0 for ; Sun, 31 Oct 2010 09:38:06 -0700 (PDT) Received: by iwn40 with SMTP id 40so6316342iwn.31 for ; Sun, 31 Oct 2010 09:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=TtsGpYToMZIcyFLMAaCtdfL2DhN87R1qK0aqwS13CKs=; b=S/gMVm6csTfnCCwivEzxjVsb8nb9Hprg33NgYVHY2QxpRKcPMFYtRxNtzP3Yy82llk A/Iax2bKZ+prOGylcA4vahjnOxV1qsggDG132hEHrkRnuWgXSlxpiYVYAfoi3evCq8LV e2hasd9jc3XoA1KdGI5i2Pqf76X7b+GGlIyTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zf8vrnSSlFabyIURi9pOzybsUsuQucCng6LhXlPtDxmbJ/UfOGq4aZEBvU8eXJrGp5 GO+rC7T2uZFbGpgqxS69VX8rksMj2opPNU1ZDMbXdLlSj+C5YjsDwvGfv+aQsbvcRrq0 /Yc99Db9SsMSZtE6QyZRL6+qTZWjdgys5d30k= MIME-Version: 1.0 Received: by 10.42.226.196 with SMTP id ix4mr3768609icb.137.1288543202125; Sun, 31 Oct 2010 09:40:02 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Sun, 31 Oct 2010 09:40:02 -0700 (PDT) In-Reply-To: References: <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> <20101031010146.GA4930@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 31 Oct 2010 12:40:02 -0400 Message-ID: From: Phillip Hallam-Baker To: James Cloos Content-Type: multipart/alternative; boundary=20cf30434784d729a90493ec579a Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 16:38:08 -0000 --20cf30434784d729a90493ec579a Content-Type: text/plain; charset=ISO-8859-1 +1 I think that the key to doing this effectively and efficiently is to look carefully at SRV, NAPTR and URI while we do this. Prefix records have some pretty complicated limitations. But I think they are necessary in this case and I think we can avoid all of the problems that they entail. On Sun, Oct 31, 2010 at 12:51 AM, James Cloos wrote: > >>>>> "IL" == Ilari Liusvaara writes: > > IL> If the lookups are done after resolving indirection by SRV, one > IL> could get along with optional port numbers and protocols (as in, > IL> UDP, TCP, SCTP...). > > I do like the idea of using SRV or NAPTR RRs. Of course, if you are > going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to > also resolve _sip._tcp.example.com. IN TLSFP. Maybe it would even be > better to just resolve _sip._tcp.example.com. IN ANY and expect both > in the same reply. (Is that, with the dnssec overhead, still small > enough for a udp packet?) > > IL> Basically, a way to limit some TLSFP record to just some > (protocol,port) > IL> pairs and then the client would remove the entries that have wrong > ports > IL> just like entries that have unknown hash function. > > Makes sense. > > IL> This would also allow the "assure SMTP but not yet HTTP" case (by > putting > IL> an entry that covers just the SMTP ports)... > > IL> But of course that plan wouldn't work as-is if TLSFP lookups would have > IL> to be done before SRV for some reason... > > Unless the TLSFP lookup is for the same name as the SRV lookup, rather > than having to be for the result of the SRV lookup. > > If I have '_sip._tcp.b.net. 3600 IN SRV 0 0 5060 a.b.net.' and someone > wants to talk to sip:eg@b.net , should they expect the TLS > cert to cover > b.net or a.b.net? > > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --20cf30434784d729a90493ec579a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

I think that the key to doing this effectively and ef= ficiently is to look carefully at SRV, NAPTR and URI while we do this.

Prefix records have some pretty complicated limitation= s. But I think they are necessary in this case and I think we can avoid all= of the problems that they entail.



On Sun, O= ct 31, 2010 at 12:51 AM, James Cloos <cloos@jhcloos.com> wrote:
>>>>> "IL" =3D=3D Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writ= es:

IL> If the lookups are done after resolving indirection by SRV, one
IL> could get along with optional port numbers and protocols (as in,
IL> UDP, TCP, SCTP...).

I do like the idea of using SRV or NAPTR RRs. =A0Of course, if you are
going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to
also resolve _sip._tcp= .example.com. IN TLSFP. =A0Maybe it would even be
better to just resolve _sip._tcp.example.com. IN ANY and expect both
in the same reply. =A0(Is that, with the dnssec overhead, still small
enough for a udp packet?)

IL> Basically, a way to limit some TLSFP record to just some (protocol,p= ort)
IL> pairs and then the client would remove the entries that have wrong p= orts
IL> just like entries that have unknown hash function.

Makes sense.

IL> This would also allow the "assure SMTP but not yet HTTP" c= ase (by putting
IL> an entry that covers just the SMTP ports)...

IL> But of course that plan wouldn't work as-is if TLSFP lookups wou= ld have
IL> to be done before SRV for some reason...

Unless the TLSFP lookup is for the same name as the SRV lookup, rather
than having to be for the result of the SRV lookup.

If I have '_sip._tcp.b.n= et. 3600 IN SRV 0 0 5060 a= .b.net.' and someone
wants to talk to sip:eg@b.net, should= they expect the TLS cert to cover
b.net or a.b.net?

-JimC
--
James Cloos <cloos@jhcloos.com&= gt; =A0 =A0 =A0 =A0 OpenPGP: 1024D/ED7DAEA6
_______________________________________________



--
Website: http://hallambaker.com/

--20cf30434784d729a90493ec579a-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843213A6811 for ; Sat, 30 Oct 2010 22:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T4SuEQpAzzy for ; Sat, 30 Oct 2010 22:16:42 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 615543A67B1 for ; Sat, 30 Oct 2010 22:16:42 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 2A4F640605; Sun, 31 Oct 2010 05:18:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1288502320; bh=iQIR1WsVdaRxtO1kUcNcIiHe6xdGXpFBYF0BbK/6AvQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ZOcz4yZdVZ5xRs4wQDVE2Hw+zMlyddPSZtVxdvNIMUibniFZ1QsTU6/tETu+LqDK2 unljgASjCFxtA7qmis6TUz5ms3moHAIGzwSeinXHxzQKVhwKy5mHjr2zrrk645YVKr 1MHpauSwT4VpXOf4WZM6InbYKYKdwKrwAoAh9+Yw= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id F36C11E9B12; Sun, 31 Oct 2010 04:53:54 +0000 (UTC) From: James Cloos To: Warren Kumari In-Reply-To: (Warren Kumari's message of "Sat, 30 Oct 2010 21:02:20 -0400") References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 31 Oct 2010 00:53:54 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:101031:warren@kumari.net::Agic5WeNTCnC36n5:0000000000000000000000000000000000000000000aiJpb X-Hashcash: 1:30:101031:keyassure@ietf.org::PTVjgkp0SGN782bB:000000000000000000000000000000000000000000zCS0y Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 05:16:43 -0000 >>>>> "WK" == Warren Kumari writes: WK> One huge consideration is minimizing the number of DNS lookups WK> needed to make all the magic happen -- if this system requires lots WK> of lookups, the browser folk will be unwilling to implement as the WK> user experience will be horrendous.... Agreed. That was why I posed the 'either/or but use the most specific' as a question. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350D93A6811 for ; Sat, 30 Oct 2010 22:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmEN-P60cKkB for ; Sat, 30 Oct 2010 22:07:17 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id C10653A696E for ; Sat, 30 Oct 2010 22:07:16 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 99A40405A6; Sun, 31 Oct 2010 05:08:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1288501753; bh=tklKtX+qSH5h3OwoVcAWo05YE/Zmr0NAc2HkVETJUB0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UZegLw7HC0b/1mRxt+Ej1lB30ZcP1YN0FVySH4viFhAvU7rlcj5UxCfpiWuPMuqcL o1bZBBCWmIRj0DJ7bjGyp8oU1v2q5guaL2Nn/HAJy8VXVUgF3nGNr5Co1SFyrBUvS3 aCFZvQE99Jajty0974YQRDiSTrRy9HLJ5NgizYt4= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 7B86A1E9B12; Sun, 31 Oct 2010 04:51:32 +0000 (UTC) From: James Cloos To: Ilari Liusvaara In-Reply-To: <20101031010146.GA4930@LK-Perkele-V2.elisa-laajakaista.fi> (Ilari Liusvaara's message of "Sun, 31 Oct 2010 03:01:46 +0200") References: <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> <20101031010146.GA4930@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 31 Oct 2010 00:51:32 -0400 Message-ID: Lines: 35 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:101031:ilari.liusvaara@elisanet.fi::+OWJBYTn2/Q5HM8f:000000000000000000000000000000000jlh/W X-Hashcash: 1:30:101031:keyassure@ietf.org::rIqsKW7Wwsc4+vVi:0000000000000000000000000000000000000000001Q4Ps X-Hashcash: 1:30:101031:sjs@princeton.edu::5G7YK8SFkMODAA2t:0000000000000000000000000000000000000000000qLYCC Cc: Steve Schultze , keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 05:07:19 -0000 >>>>> "IL" == Ilari Liusvaara writes: IL> If the lookups are done after resolving indirection by SRV, one IL> could get along with optional port numbers and protocols (as in, IL> UDP, TCP, SCTP...). I do like the idea of using SRV or NAPTR RRs. Of course, if you are going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to also resolve _sip._tcp.example.com. IN TLSFP. Maybe it would even be better to just resolve _sip._tcp.example.com. IN ANY and expect both in the same reply. (Is that, with the dnssec overhead, still small enough for a udp packet?) IL> Basically, a way to limit some TLSFP record to just some (protocol,port) IL> pairs and then the client would remove the entries that have wrong ports IL> just like entries that have unknown hash function. Makes sense. IL> This would also allow the "assure SMTP but not yet HTTP" case (by putting IL> an entry that covers just the SMTP ports)... IL> But of course that plan wouldn't work as-is if TLSFP lookups would have IL> to be done before SRV for some reason... Unless the TLSFP lookup is for the same name as the SRV lookup, rather than having to be for the result of the SRV lookup. If I have '_sip._tcp.b.net. 3600 IN SRV 0 0 5060 a.b.net.' and someone wants to talk to sip:eg@b.net, should they expect the TLS cert to cover b.net or a.b.net? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C1A3A6827 for ; Sat, 30 Oct 2010 18:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTtDN5s1dKqs for ; Sat, 30 Oct 2010 18:46:44 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0B1503A689A for ; Sat, 30 Oct 2010 18:46:43 -0700 (PDT) Received: by iwn40 with SMTP id 40so5725427iwn.31 for ; Sat, 30 Oct 2010 18:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+MeVJSTh8S+LDFvXHZyVmWw3nKj2jehAz9iZ49DUd4o=; b=W9PKNXT1+/zc6EsUGlmeiVvI3HyafS+FB4m/J6OZPmH74bdNs47ULEokQhjYWDEOo2 L9+EBySjKY2/mWH546tXFaNSCrlor05+BD+TCnZxPl958YriBG3fpcRHeel5FmN1e6Bk 9jTftR1LysYw/5LagKDxv0pmlpQnbC1CfWpL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aRrWTsaDvmJWxW0zAEfu6pZrB9LcMQiCpT0z/LkvW1lWMe5YoQAnNZUewjJ7rTvAUc tOT3mXsK5ylUk4pGYU+NSngwN14lZAqHImvgMavSJWc8pFHYePzm7G5QaOkxQh/mkyE4 a0HoU3v5HGM4I19bC/1MR4bTnDfGZkFrtt/RI= MIME-Version: 1.0 Received: by 10.42.41.196 with SMTP id q4mr1186106ice.482.1288489721662; Sat, 30 Oct 2010 18:48:41 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Sat, 30 Oct 2010 18:48:41 -0700 (PDT) In-Reply-To: <1288470572.1977.210.camel@mattlaptop2.local> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> <1288470572.1977.210.camel@mattlaptop2.local> Date: Sat, 30 Oct 2010 21:48:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=20cf301d42ea280d1a0493dfe431 Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 01:46:51 -0000 --20cf301d42ea280d1a0493dfe431 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 30, 2010 at 4:29 PM, Matt McCutchen wrote: > On Sat, 2010-10-30 at 14:24 -0400, Phillip Hallam-Baker wrote: > > I am fine with this as an option. > > > > But I think that making it useful and scalable requires us to provide > more > > than just a flag. > > Can you provide a specific, compelling example? > We have multiple protocols in use at most sites on a given domain. The easiest way to get to critical mass in my view is to enable sites to deploy for SMTP, IMAP, POP and other protocols where SSL is used but the clients do not make much use of the CA infrastructure and there is no use of EV. To make that practical it has to be possible to have statements of the form 'only trust these certs for protocol X'. The other reason for wanting something other than a flag is that managing public keys on a large scale is time consuming and requires infrastructure. That infrastructure already exists for X.509/PKIX, many if not most enterprises who would be possible early adopters of this type of management scheme already have an X.509/PKIX infrastructure deployed. So for those domains it is going to be much easier to publish a statement 'all valid certs fall under this hierarchy' than 'all valid certs have a fingerprint'. I think we need to offer both options. > > > What we are proposing here is an aspect of security policy. Which gets us > > into territory that is generally considered 'difficult' and every > security > > AD that I have ever discussed this with has expressed extreme skepticism > as > > to whether a WG can get to closure if it addresses security policy. The > term > > 'rat hole' is used. [...] > > The flag has a simple and clear semantic, "I authorize this certificate > and only this certificate for use on my TLS server", and is already > useful to folks like me who can't wait to publish a single exclusive > certificate in DNSSEC and no longer be exposed to the likes of Etisalat. > You seem to be saying that we should hold off on standardizing the > exclusivity flag because there are some use cases that require a more > sophisticated scheme, but also that we might never complete such a > scheme. So what can be the benefit of waiting, compared to > standardizing the flag now? > No, I am saying that it has been very difficult to get anything that falls under the 'security policy' bracket accepted as a WG charter item because security policy is a notorious rat hole. What we are proposing is a set of protocol specific security assertions and not a security policy processing mechanism. So what I am saying is that I think we can craft a very precise statement that allows us to do exactly what we would like to do without triggering rodent dwelling concerns. -- Website: http://hallambaker.com/ --20cf301d42ea280d1a0493dfe431 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 30, 2010 at 4:29 PM, Matt Mc= Cutchen <mat= t@mattmccutchen.net> wrote:
On Sat, 2010-10-30 at 14:24 -0400, Phillip Hallam-Baker w= rote:
> I am fine with this as an option.
>
> But I think that making it useful and scalable requires us to provide = more
> than just a flag.

Can you provide a specific, compelling example?
=
We have multiple protocols in use at most sites on a given d= omain.=A0

The easiest way to get to critical mass = in my view is to enable sites to deploy for SMTP, IMAP, POP and other proto= cols where SSL is used but the clients do not make much use of the CA infra= structure and there is no use of EV.

To make that practical it has to be possible to have st= atements of the form 'only trust these certs for protocol X'.
=


The other reason for wanting something o= ther than a flag is that managing public keys on a large scale is time cons= uming and requires infrastructure. That infrastructure already exists for X= .509/PKIX, many if not most enterprises who would be possible early adopter= s of this type of management scheme already have an X.509/PKIX infrastructu= re deployed.

So for those domains it is going to be much easier to p= ublish a statement 'all valid certs fall under this hierarchy' than= 'all valid certs have a fingerprint'.

I think we need to offer both options.


<= div>=A0

> What we are proposing here is an aspect of security policy. Which gets= us
> into territory that is generally considered 'difficult' and ev= ery security
> AD that I have ever discussed this with has expressed extreme skeptici= sm as
> to whether a WG can get to closure if it addresses security policy. Th= e term
> 'rat hole' is used. [...]

The flag has a simple and clear semantic, "I authorize this certificat= e
and only this certificate for use on my TLS server", and is already useful to folks like me who can't wait to publish a single exclusive certificate in DNSSEC and no longer be exposed to the likes of Etisalat. You seem to be saying that we should hold off on standardizing the
exclusivity flag because there are some use cases that require a more
sophisticated scheme, but also that we might never complete such a
scheme. =A0So what can be the benefit of waiting, compared to
standardizing the flag now?

No, I= am saying that it has been very difficult to get anything that falls under= the 'security policy' bracket accepted as a WG charter item becaus= e security policy is a notorious rat hole.

What we are proposing is a set of protocol specific sec= urity assertions and not a security policy processing mechanism.
=
So what I am saying is that I think we can craft a very prec= ise statement that allows us to do exactly what we would like to do without= triggering rodent dwelling concerns.


--
Website: h= ttp://hallambaker.com/

--20cf301d42ea280d1a0493dfe431-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA423A679C for ; Sat, 30 Oct 2010 18:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsOZkdn2JMun for ; Sat, 30 Oct 2010 18:35:49 -0700 (PDT) Received: from emh05.mail.saunalahti.fi (emh05.mail.saunalahti.fi [62.142.5.111]) by core3.amsl.com (Postfix) with ESMTP id DE9A73A69E4 for ; Sat, 30 Oct 2010 18:35:45 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh05-2.mail.saunalahti.fi (Postfix) with SMTP id 650D68C0F1; Sun, 31 Oct 2010 03:37:42 +0200 (EET) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A046225EC9E; Sun, 31 Oct 2010 03:37:42 +0200 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 3D1E1158A64; Sun, 31 Oct 2010 03:37:35 +0200 (EET) Date: Sun, 31 Oct 2010 03:37:35 +0200 From: Ilari Liusvaara To: Warren Kumari Message-ID: <20101031013735.GA5348@LK-Perkele-V2.elisa-laajakaista.fi> References: <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 01:35:53 -0000 On Sat, Oct 30, 2010 at 09:02:20PM -0400, Warren Kumari wrote: > > On Oct 30, 2010, at 8:07 PM, James Cloos wrote: > > >>>>>> "MM" == Matt McCutchen writes: > > > > The only possible issue is the question of whether the client should > > perform queries for names like www.example.com. or _http._tcp.www.example.com.? > > This is another question that has been repeatedly raised (partly in the guise > of "if you post a record for your webserver it will break mail"). > Another option (which has some (IMO) of the elegance retained, but probably > has scalability and leakage issues) is > foo.example.com IN A 192.0.2.1 > IN KIDNS 443 545254634563546354 > IN KIDNS 993 435245243523452345 > IN KIDNS 5222 23452345435234545 > ) -- basically, have the records for foo.example.com (or just exmaple.com) > all at the same level, but have the ports included in the response. Or allow multiple ports per entry (and also "all ports"?). Multi-port responses could be useful for example for covering webserver supporting upgrades (TCP80/TCP433) or SMTP server supporting upgrades (TCP25/TCP465/TCP587). Oh, and sometimes TCP X and UDP X are not the same service (usually those are). But I think all cases are some legacy services that aren't going to support KIDNS anyway... So just going by port number and forgetting the proto is likely feasible... Designing wire format for that is not difficult. Getting sane master format notation might be... Also, this doesn't solve the service leakage issues. > > > > Or both, preferring the more specific if both exist? > > Oooh, that's interesting -- to be honest I hadn't thought of that... > > One huge consideration is minimizing the number of DNS lookups needed > to make all the magic happen -- if this system requires lots of > lookups, the browser folk will be unwilling to implement as the user > experience will be horrendous.... What's the likely amount of stuff in those _._. spaces? Little enough to make issuing QCLASS * requests feasible? Being able to QCLASS * it could also get other possibly usable stuff (like secure service discovery[1] data, but that's a seperate topic...) [1] Inform client that secure service exists and how to connect to it. -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B4D3A697A for ; Sat, 30 Oct 2010 18:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc5AWghNi+xz for ; Sat, 30 Oct 2010 18:16:59 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 69B5F3A679C for ; Sat, 30 Oct 2010 18:16:59 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id E1BA62284A7E; Sat, 30 Oct 2010 21:17:21 -0400 (EDT) Received: from [192.168.0.238] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 3BDA622847A9; Sat, 30 Oct 2010 21:17:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sat, 30 Oct 2010 21:18:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F40209F-3E18-459F-AAAB-04BDC8FDE134@kumari.net> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> To: Warren Kumari X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 01:17:01 -0000 [ Replying to myself ]=20 Apologies to the list, I have just reinstalled a machine for bringing to = the meeting and forgot to turn off the "Rich Text with Random Markups = and Embedded Garbage" knob in my MUA before replying... While on the topic of list etiquette and similar things, I just wanted = to thank everyone for playing nicely on this thread -- I feel that we = are beginning to make progress again and are (hopefully) starting to see = each others points again... W=20 On Oct 30, 2010, at 9:02 PM, Warren Kumari wrote: >=20 > On Oct 30, 2010, at 8:07 PM, James Cloos wrote: >=20 >>>>>>> "MM" =3D=3D Matt McCutchen writes: >>=20 >> MM> Yes, I think it is cleanest to treat DNSSEC as a black box that >> MM> produces one of the four security states and build from there. >> MM> Here is some proposed text for Section 3. ... >>=20 >> That seems to sum up what I'd like to see from KIDNS: the = possibility >> of using dnssec as one's only trust anchor and also the ability to >> slowly transition from current practice. Clients will need to do the >> latter anyway; any KIDNS standard should cover that explicitly. And >> the former is a big win, long term, over the status quo. >>=20 >> The only possible issue is the question of whether the client should >> perform queries for names like www.example.com. or = _http._tcp.www.example.com.? >=20 > This is another question that has been repeatedly raised (partly in = the guise of "if you post a record for your webserver it will break = mail"). > I (no hats) was against the _selector_ idea as I feel that all records = related to a thingie (technical term) should exist at the same level ( >=20 > foo.example.com IN A 192.0.2.1 > IN BAR 42 > IN KIDNS 54690765349763590 > ), but this is an elegance viewpoint and enough folk have pointed out = that this is a needed feature that I'm open to it as an idea.... >=20 > Another option (which has some (IMO) of the elegance retained, but = probably has scalability and leakage issues) is=20 > foo.example.com IN A 192.0.2.1 > IN KIDNS 443 545254634563546354 > IN KIDNS 993 435245243523452345 > IN KIDNS 5222 23452345435234545 > ) -- basically, have the records for foo.example.com (or just = exmaple.com) all at the same level, but have the ports included in the = response. >=20 >>=20 >> Or both, preferring the more specific if both exist? >=20 > Oooh, that's interesting -- to be honest I hadn't thought of that... = One huge consideration is minimizing the number of DNS lookups needed to = make all the magic happen -- if this system requires lots of lookups, = the browser folk will be unwilling to implement as the user experience = will be horrendous.... >=20 >>=20 >> The more specifc option permits different certs for, eg, _http._tcp >> vs _smtp._tcp vs _sip._tcp, but also means maintaining probably >> identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp. >>=20 >> I can see how each might be perceived as necessary, but also how each >> might be perceived as undesirable. >=20 > Yes, both are (IMO) sub-optimal -- my *personal* view of the world = involves having unique names for each service (www.example.com, = imap.exmaple.com, jabber.example.com) which sidesteps this issue, but = enough folk have raised this issue that it needs to be addressed.... >=20 > As for exactly how (ports in the response, selectors, something else), = that is something that we (with input from DNS folk) need to discuss and = come to agreement on.... >=20 > W=20 >=20 >=20 >>=20 >> (Incidently, in the more-specific case, would the CA for a given = RHS's >> smime certs be sought at _smime.example.org. or = _smime._???.example.org?) >>=20 >> -JimC >> --=20 >> James Cloos OpenPGP: 1024D/ED7DAEA6 >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B780F3A6977 for ; Sat, 30 Oct 2010 18:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzyUfinCPkTi for ; Sat, 30 Oct 2010 18:00:27 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 0FF9D3A6976 for ; Sat, 30 Oct 2010 18:00:27 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id B09582284A7E; Sat, 30 Oct 2010 21:00:49 -0400 (EDT) Received: from [192.168.0.238] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id BBB1522847A9; Sat, 30 Oct 2010 21:00:47 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-942094901 From: Warren Kumari In-Reply-To: Date: Sat, 30 Oct 2010 21:02:20 -0400 Message-Id: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> To: James Cloos X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 01:00:28 -0000 --Apple-Mail-1-942094901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 30, 2010, at 8:07 PM, James Cloos wrote: >>>>>> "MM" =3D=3D Matt McCutchen writes: >=20 > MM> Yes, I think it is cleanest to treat DNSSEC as a black box that > MM> produces one of the four security states and build from there. > MM> Here is some proposed text for Section 3. ... >=20 > That seems to sum up what I'd like to see from KIDNS: the possibility > of using dnssec as one's only trust anchor and also the ability to > slowly transition from current practice. Clients will need to do the > latter anyway; any KIDNS standard should cover that explicitly. And > the former is a big win, long term, over the status quo. >=20 > The only possible issue is the question of whether the client should > perform queries for names like www.example.com. or = _http._tcp.www.example.com.? This is another question that has been repeatedly raised (partly in the = guise of "if you post a record for your webserver it will break mail"). I (no hats) was against the _selector_ idea as I feel that all records = related to a thingie (technical term) should exist at the same level ( foo.example.com IN A 192.0.2.1 IN BAR 42 IN KIDNS 54690765349763590 ), but this is an elegance viewpoint and enough folk have pointed out = that this is a needed feature that I'm open to it as an idea.... Another option (which has some (IMO) of the elegance retained, but = probably has scalability and leakage issues) is=20 foo.example.com IN A 192.0.2.1 IN KIDNS 443 545254634563546354 IN KIDNS 993 435245243523452345 IN KIDNS 5222 23452345435234545 ) -- basically, have the records for foo.example.com (or just = exmaple.com) all at the same level, but have the ports included in the = response. >=20 > Or both, preferring the more specific if both exist? Oooh, that's interesting -- to be honest I hadn't thought of that... One = huge consideration is minimizing the number of DNS lookups needed to = make all the magic happen -- if this system requires lots of lookups, = the browser folk will be unwilling to implement as the user experience = will be horrendous.... >=20 > The more specifc option permits different certs for, eg, _http._tcp > vs _smtp._tcp vs _sip._tcp, but also means maintaining probably > identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp. >=20 > I can see how each might be perceived as necessary, but also how each > might be perceived as undesirable. Yes, both are (IMO) sub-optimal -- my *personal* view of the world = involves having unique names for each service (www.example.com, = imap.exmaple.com, jabber.example.com) which sidesteps this issue, but = enough folk have raised this issue that it needs to be addressed.... As for exactly how (ports in the response, selectors, something else), = that is something that we (with input from DNS folk) need to discuss and = come to agreement on.... W=20 >=20 > (Incidently, in the more-specific case, would the CA for a given RHS's > smime certs be sought at _smime.example.org. or = _smime._???.example.org?) >=20 > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --Apple-Mail-1-942094901 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 30, 2010, at 8:07 PM, James Cloos = wrote:

"MM" =3D=3D Matt McCutchen <matt@mattmccutchen.net> = writes:

MM> Yes, I think it is cleanest to treat DNSSEC as a black = box that
MM> produces one of the four security states and build = from there.
MM> Here is some proposed text for Section 3. = ...

That seems to sum up what I'd like to see from KIDNS: =  the possibility
of using dnssec as one's only trust anchor and = also the ability to
slowly transition from current practice. =  Clients will need to do the
latter anyway; any KIDNS standard = should cover that explicitly.  And
the former is a big win, long = term, over the status quo.

The only possible issue is the = question of whether the client should
perform queries for names like = www.example.com. or = _http._tcp.www.example.com.?

This is another question that has been repeatedly = raised (partly in the guise of "if you post a record for your webserver = it will break mail").
I (no hats) was against the _selector_ idea as I = feel that all records related to a thingie (technical term) should exist = at the same level (

foo.example.com       =   IN   A     192.0.2.1
= IN =   BAR     42
     =                    IN =   KIDNS  54690765349763590
), but this is an = elegance viewpoint and enough folk have pointed out that this is a = needed feature that I'm open to it as an idea....

Another option (which has some (IMO) of the = elegance retained, but probably has scalability and leakage issues) = is 
foo.example.com     IN A = 192.0.2.1
             =        IN KIDNS 443 = 545254634563546354
             =        IN KIDNS 993 = 435245243523452345
             =        IN KIDNS 5222 = 23452345435234545
) -- basically, have the records for foo.example.com (or just exmaple.com) all at the same level, but = have the ports included in the response.


Or both, preferring the more specific if both = exist?

Oooh, that's = interesting -- to be honest I hadn't thought of that... One huge = consideration is minimizing the number of DNS lookups needed to make all = the magic happen -- if this system requires lots of lookups, the browser = folk will be unwilling to implement as the user experience will be = horrendous....


The more specifc = option permits different certs for, eg, _http._tcp
vs _smtp._tcp vs = _sip._tcp, but also means maintaining probably
identical RRs for eg = _sip._tcp, _sip._udp and _sip._sctp.

I can see how each might be = perceived as necessary, but also how each
might be perceived as = undesirable.

Yes, both = are (IMO) sub-optimal -- my *personal* view of the world involves having = unique names for each service (www.example.com, imap.exmaple.com, jabber.example.com) which = sidesteps this issue, but enough folk have raised this issue that it = needs to be addressed....

As for exactly how = (ports in the response, selectors, something else), that is something = that we (with input from DNS folk) need to discuss and come to agreement = on....

W 



(Incidently, in the more-specific case, would the CA for a = given RHS's
smime certs be sought at _smime.example.org. or = _smime._???.example.org?)

-JimC
--
James Cloos <cloos@jhcloos.com> =         OpenPGP: = 1024D/ED7DAEA6
_______________________________________________
keyas= sure mailing list
keyassure@ietf.org
https://www.i= etf.org/mailman/listinfo/keyassure

= = --Apple-Mail-1-942094901-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9203A697A for ; Sat, 30 Oct 2010 17:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ESbTMydWDB5 for ; Sat, 30 Oct 2010 17:59:53 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id BD4673A6976 for ; Sat, 30 Oct 2010 17:59:53 -0700 (PDT) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 259FEC8186; Sun, 31 Oct 2010 03:01:50 +0200 (EET) Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A07F03176E2; Sun, 31 Oct 2010 03:01:50 +0200 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 3FEED1C6383; Sun, 31 Oct 2010 03:01:46 +0200 (EET) Date: Sun, 31 Oct 2010 03:01:46 +0200 From: Ilari Liusvaara To: James Cloos Message-ID: <20101031010146.GA4930@LK-Perkele-V2.elisa-laajakaista.fi> References: <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Steve Schultze , keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 00:59:55 -0000 On Sat, Oct 30, 2010 at 08:07:18PM -0400, James Cloos wrote: > >>>>> "MM" == Matt McCutchen writes: > > MM> Yes, I think it is cleanest to treat DNSSEC as a black box that > MM> produces one of the four security states and build from there. > MM> Here is some proposed text for Section 3. ... > > > The only possible issue is the question of whether the client should > perform queries for names like www.example.com. or _http._tcp.www.example.com.? > > Or both, preferring the more specific if both exist? If the lookups are done after resolving indirection by SRV, one could get along with optional port numbers and protocols (as in, UDP, TCP, SCTP...). Basically, a way to limit some TLSFP record to just some (protocol,port) pairs and then the client would remove the entries that have wrong ports just like entries that have unknown hash function. This would also allow the "assure SMTP but not yet HTTP" case (by putting an entry that covers just the SMTP ports)... But of course that plan wouldn't work as-is if TLSFP lookups would have to be done before SRV for some reason... -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121383A69FA for ; Sat, 30 Oct 2010 17:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48fFZ8QzaCTl for ; Sat, 30 Oct 2010 17:28:06 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 9C2553A6976 for ; Sat, 30 Oct 2010 17:28:06 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 5B72E2284A7E; Sat, 30 Oct 2010 20:28:29 -0400 (EDT) Received: from [192.168.0.238] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id EC86422847A9; Sat, 30 Oct 2010 20:28:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sat, 30 Oct 2010 20:30:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08CA452F-9EBF-4425-A1A0-6B1635DB5AFF@kumari.net> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> To: Steve Schultze X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 00:28:08 -0000 On Oct 30, 2010, at 11:05 AM, Steve Schultze wrote: > Ben, I'm porting your comment below into this thread for the sake of = subject-line clarity (none of this is WG-formation specific, I believe). >=20 > On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: >> Paul wants client policy to decide whether to trust PKIX, DNSSEC or >> some mixture of the two. This seems not only reasonable, but >> unavoidable: clients will implement what suits them, and we are in no >> position to change that. >>=20 >> Phillip wants the domain in question to be able to state its >> intentions w.r.t. the policy clients should use. This seems not >> unreasonable, also. Clients can choose to follow this or not. >=20 > What effect does this have on the MUST vs. MAY suggestions I made to = the draft-hoffman-keys-linkage-from-dns-03 text? I believe that what = you are saying is that the spec should leave it open to the client how = to react to different validation outcome permutations from PKIX and = DNSSEC-secured KIDNS. In that case, the two excerpts I quoted should be = MAY, as I suggested. This also means that I disagree with Paul, who = thinks that MUST should be used. >=20 > I would note that, presuming KIDNS only affects client behavior when = the client can directly verify that the records were validly = DNSSEC-signed (is this everybody's assumption?), using a MUST creates a = downgrade attack in which a MITM can force PKIX-only validation by = simply blocking DNSSEC-validated DNS results. Actually, a MITM who is blocking DNSSEC-validated DNS results is = detectable and (IMO) evidence that Something Bad(tm) is happening, and = that you should take your ball and go home....=20 Also, not quite sure that this is the best place to bring this up (but I = couldn't find a better place in the thread), but the "client can = directly verify that records were validly DNSSEC-signed" has some = subtleties -- there are three options (although I could have forgotten = some): 1: The client just blindly trusts the AD bit (a bit set by the recursive = resolver to say (basically) "I have done the DNSSEC verification magic = and this is all authenticated data, trust me...."). I'm assuming that = everyone here agrees that this is a horrendous idea. 2: The client performs all of the DNSSEC verification itself -- I'm = assuming again that everyone here agrees that (from a security = standpoint) this is good. 3: The client trusts a response with the AD bit set but ONLY if it has = received this response over some sort of "secure" channel that provides = authentication of the transport and validation that you are talking to = the correct recursive resolver, and the client has some reason to trust = the resolver. An example of this would be a VPN (or SIG(0)) to a = corporate or contracted resolver operator. To me, while still much much = better than option 1, it is not actually a *good* idea -- I would like = to know what the list thinks though.... W >=20 > "If the application receives zero usable certificate associations, it = [MUST] process TLS in the normal fashion." >=20 > We want the client to be able to choose to require DNSSEC-validated = KIDNS for all requests, if it wishes. Otherwise what we're doing offers = no greater security than the status quo. >=20 > On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: >> Thank you for being explicit! >>=20 >> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >>> Having now caught up with the many recent messages, I'd also >>> be a bit concerned about the impact of: >>>=20 >>>> "If a match between the certificate association(s) and the >>>> server's end entity certificate in TLS is not found, the >>>> TLS client MUST abort the handshake with an "access_denied" error." >>>=20 >>> The concerns I have about it would include: >>>=20 >>> - I'm not really sure if that same rule would be appropriate >>> for all applications that use TLS, nor for all deployments >>> of each protocol using TLS - basically the policy slippery >>> slope PHB is raising (from time to time:-) >>=20 >> OK, maybe try being more explicit. For example, if this document was = in fact an update to TLS, would you have the same concern? Or, if you = want a SHOULD rather than a MUST, what would the specific exceptions be = (or are you asking for a typical IETF mushy SHOULD)? >=20 > I don't know what Stephen Farrell is arguing for, but I'm arguing for = an even more mushy MAY ;) >=20 > However, this is a feature because it gives the clients more = options... including the option to improve upon the status quo of PKIX = security even in the presence of a MITM (our assumed threat model). It = does so without forcing all clients to do this on day one, an = impractical requirement. >=20 > On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: >> "If the application receives zero usable certificate associations, it = process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's = end entity certificate in TLS is not found, the TLS client MUST abort = the handshake with an "access_denied" error." >>=20 >> I suggest: >>=20 >> "If the application receives zero usable certificate associations, it = MAY process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's = end entity certificate in TLS is not found, the TLS client MAY abort the = handshake with an "access_denied" error." >=20 >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CDD3A697A for ; Sat, 30 Oct 2010 17:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tgb3eZ-eLYSO for ; Sat, 30 Oct 2010 17:27:45 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 931AB3A6976 for ; Sat, 30 Oct 2010 17:27:45 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id EFE772284A7E; Sat, 30 Oct 2010 20:28:07 -0400 (EDT) Received: from [192.168.0.238] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 63B7122847A9; Sat, 30 Oct 2010 20:28:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sat, 30 Oct 2010 20:28:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE38670-7D32-4C49-A805-6DB163B662A2@kumari.net> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> To: Steve Schultze X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 00:27:47 -0000 On Oct 30, 2010, at 11:05 AM, Steve Schultze wrote: > Ben, I'm porting your comment below into this thread for the sake of = subject-line clarity (none of this is WG-formation specific, I believe). >=20 > On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: >> Paul wants client policy to decide whether to trust PKIX, DNSSEC or >> some mixture of the two. This seems not only reasonable, but >> unavoidable: clients will implement what suits them, and we are in no >> position to change that. >>=20 >> Phillip wants the domain in question to be able to state its >> intentions w.r.t. the policy clients should use. This seems not >> unreasonable, also. Clients can choose to follow this or not. >=20 > What effect does this have on the MUST vs. MAY suggestions I made to = the draft-hoffman-keys-linkage-from-dns-03 text? I believe that what = you are saying is that the spec should leave it open to the client how = to react to different validation outcome permutations from PKIX and = DNSSEC-secured KIDNS. In that case, the two excerpts I quoted should be = MAY, as I suggested. This also means that I disagree with Paul, who = thinks that MUST should be used. >=20 > I would note that, presuming KIDNS only affects client behavior when = the client can directly verify that the records were validly = DNSSEC-signed (is this everybody's assumption?), using a MUST creates a = downgrade attack in which a MITM can force PKIX-only validation by = simply blocking DNSSEC-validated DNS results. Actually, a MITM who is blocking DNSSEC-validated DNS results is = detectable and (IMO) evidence that Something Bad(tm) is happening, and = that you should take your ball and go home....=20 Also, not quite sure that this is the best place to bring this up (but I = couldn't find a better place in the thread), but the "client can = directly verify that records were validly DNSSEC-signed" has some = subtleties -- there are three options (although I could have forgotten = some): 1: The client just blindly trusts the AD bit (a bit set by the recursive = resolver to say (basically) "I have done the DNSSEC verification magic = and this is all authenticated data, trust me...."). I'm assuming that = everyone here agrees that this is a horrendous idea. 2: The client performs all of the DNSSEC verification itself -- I'm = assuming again that everyone here agrees that (from a security = standpoint) this is good. 3: The client trusts a response with the AD bit set but ONLY if it has = received this response over some sort of "secure" channel that provides = authentication of the transport and validation that you are talking to = the correct recursive resolver, and the client has some reason to trust = the resolver. An example of this would be a VPN (or SIG(0)) to a = corporate or contracted resolver operator. To me, while still much much = better than option 1, it is not actually a *good* idea -- I would like = to know what the list thinks though.... W >=20 > "If the application receives zero usable certificate associations, it = [MUST] process TLS in the normal fashion." >=20 > We want the client to be able to choose to require DNSSEC-validated = KIDNS for all requests, if it wishes. Otherwise what we're doing offers = no greater security than the status quo. >=20 > On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: >> Thank you for being explicit! >>=20 >> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >>> Having now caught up with the many recent messages, I'd also >>> be a bit concerned about the impact of: >>>=20 >>>> "If a match between the certificate association(s) and the >>>> server's end entity certificate in TLS is not found, the >>>> TLS client MUST abort the handshake with an "access_denied" error." >>>=20 >>> The concerns I have about it would include: >>>=20 >>> - I'm not really sure if that same rule would be appropriate >>> for all applications that use TLS, nor for all deployments >>> of each protocol using TLS - basically the policy slippery >>> slope PHB is raising (from time to time:-) >>=20 >> OK, maybe try being more explicit. For example, if this document was = in fact an update to TLS, would you have the same concern? Or, if you = want a SHOULD rather than a MUST, what would the specific exceptions be = (or are you asking for a typical IETF mushy SHOULD)? >=20 > I don't know what Stephen Farrell is arguing for, but I'm arguing for = an even more mushy MAY ;) >=20 > However, this is a feature because it gives the clients more = options... including the option to improve upon the status quo of PKIX = security even in the presence of a MITM (our assumed threat model). It = does so without forcing all clients to do this on day one, an = impractical requirement. >=20 > On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: >> "If the application receives zero usable certificate associations, it = process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's = end entity certificate in TLS is not found, the TLS client MUST abort = the handshake with an "access_denied" error." >>=20 >> I suggest: >>=20 >> "If the application receives zero usable certificate associations, it = MAY process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's = end entity certificate in TLS is not found, the TLS client MAY abort the = handshake with an "access_denied" error." >=20 >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F013A6976 for ; Sat, 30 Oct 2010 17:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pM3eaVgJAUE for ; Sat, 30 Oct 2010 17:23:38 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 521F93A6975 for ; Sat, 30 Oct 2010 17:23:38 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id DC981400B0; Sun, 31 Oct 2010 00:25:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1288484734; bh=uWaQ5NMGAI0DbLwX2pUI6tcQLvYV2vOWUOcv3Ad4Q80=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mv6NB+HXNc4cmmtweCB1SvjZzblZy+3TKVPIZIIgPZPgUN0wcjNUgCigs+7ulSDUF DVoRnUhM7VGHUm23V8L4vT/UpRw8fpxYzSMksVUOkUQ7NqbhD/wUoXuoqJJIk4RPah WJIhigHAUcwOlSbwclv0Cm3KaHVmUGccGWqWnYaM= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id E5E7F1EA63B; Sun, 31 Oct 2010 00:07:18 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: <1288477403.1977.319.camel@mattlaptop2.local> (Matt McCutchen's message of "Sat, 30 Oct 2010 18:23:23 -0400") References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 30 Oct 2010 20:07:18 -0400 Message-ID: Lines: 30 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:101031:keyassure@ietf.org::+Pz1xGgnb1OrSSEs:0000000000000000000000000000000000000000003CyCg X-Hashcash: 1:30:101031:matt@mattmccutchen.net::ni5vOn8zsuvaKQ0O:000000000000000000000000000000000000004W0t7 X-Hashcash: 1:30:101031:sjs@princeton.edu::ufNMZDs6ug8kQIaB:0000000000000000000000000000000000000000000cd3To Cc: Steve Schultze Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 00:23:40 -0000 >>>>> "MM" == Matt McCutchen writes: MM> Yes, I think it is cleanest to treat DNSSEC as a black box that MM> produces one of the four security states and build from there. MM> Here is some proposed text for Section 3. ... That seems to sum up what I'd like to see from KIDNS: the possibility of using dnssec as one's only trust anchor and also the ability to slowly transition from current practice. Clients will need to do the latter anyway; any KIDNS standard should cover that explicitly. And the former is a big win, long term, over the status quo. The only possible issue is the question of whether the client should perform queries for names like www.example.com. or _http._tcp.www.example.com.? Or both, preferring the more specific if both exist? The more specifc option permits different certs for, eg, _http._tcp vs _smtp._tcp vs _sip._tcp, but also means maintaining probably identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp. I can see how each might be perceived as necessary, but also how each might be perceived as undesirable. (Incidently, in the more-specific case, would the CA for a given RHS's smime certs be sought at _smime.example.org. or _smime._???.example.org?) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51113A6817 for ; Sat, 30 Oct 2010 16:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWYSO6OexzRT for ; Sat, 30 Oct 2010 16:19:55 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by core3.amsl.com (Postfix) with ESMTP id 9858A3A6974 for ; Sat, 30 Oct 2010 16:19:55 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh01-2.mail.saunalahti.fi (Postfix) with SMTP id 63BEB8C6D5; Sun, 31 Oct 2010 02:21:51 +0300 (EEST) Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A00F09609D5; Sun, 31 Oct 2010 02:21:51 +0300 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 1E6D21C6382; Sun, 31 Oct 2010 02:21:47 +0300 (EEST) Date: Sun, 31 Oct 2010 02:22:02 +0300 From: Ilari Liusvaara To: Matt McCutchen Message-ID: <20101030232202.GA4320@LK-Perkele-V2.elisa-laajakaista.fi> References: <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> <1288477403.1977.319.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1288477403.1977.319.camel@mattlaptop2.local> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Steve Schultze , keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 23:19:57 -0000 On Sat, Oct 30, 2010 at 06:23:23PM -0400, Matt McCutchen wrote: > On Sat, 2010-10-30 at 16:39 -0400, Steve Schultze wrote: > > If any query cannot be completed or gives a "bogus" result as described > in RFC 4033 section 5, validation MUST fail and the client MUST abort > the TLS handshake (if it has been started) with a "TBD" error. > Otherwise, if any query gives an "insecure" or "indeterminate" result, > KIDNS cannot be used with this TLS server, and the client MAY use an > alternative certificate validation method. Looking at the list of error codes, the only ones that I think could apply would be codes 80(internal_error) and 90(user_canceled). -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC983A68F0 for ; Sat, 30 Oct 2010 15:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2YVQoSydh6n for ; Sat, 30 Oct 2010 15:21:27 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id DEDBB3A67D0 for ; Sat, 30 Oct 2010 15:21:26 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 9042C25C064; Sat, 30 Oct 2010 15:23:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=AMfpnv5ciz0YnzhrKtd0ryE67+ZdvPXDvEe8E6Divz1 Usp3grhpqNhHiZSYxO2V/mwq7B4b7ZJNg/hggJf5vqZWacgVoCJieGidox0+FwPg +WT2e98jbGBB3FiW892NlYPBBg4K37Ow3xW4plodJ192YKXESRQYQRRw9naLSrG0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=OVo4cshSFNvjtAtyjMJJy52qyfU=; b=m5ybdHH18j 9WWcZwzVl9xSxxikS++FnaIKMHIhqV2OYoR12bA9Y1lRgk1EVcJCVa9I0vuSbvaX G1Dt2Edmz28TRLvbHTWTIp5M9oDlkcgvTmM19eCrSnatViUDSEhjCQOTiejExfip lCvEO/ogU8l1ooOlxP5w0wSe+Ct7FmGtE= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 4D84F25C063; Sat, 30 Oct 2010 15:23:24 -0700 (PDT) From: Matt McCutchen To: Steve Schultze In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Sat, 30 Oct 2010 18:23:23 -0400 Message-ID: <1288477403.1977.319.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 22:21:30 -0000 On Sat, 2010-10-30 at 16:39 -0400, Steve Schultze wrote: > What the current draft does not say is what the client MUST or MAY do > if the client is not able to request, perform, or verify DNSSEC > validation at all. The answer will affect the viability of my MITM > scenario. Yes, I think it is cleanest to treat DNSSEC as a black box that produces one of the four security states and build from there. Here is some proposed text for Section 3. ----- To validate the certificate of a TLS server using KIDNS, the client SHALL perform a DNSSEC query for TLSFP and TLSRQ records at the domain name of the TLS server. If a TLSRQ record is returned, the client SHALL perform a second query based on the certificate actually presented by the TLS server as described in section 2.2. If any query cannot be completed or gives a "bogus" result as described in RFC 4033 section 5, validation MUST fail and the client MUST abort the TLS handshake (if it has been started) with a "TBD" error. Otherwise, if any query gives an "insecure" or "indeterminate" result, KIDNS cannot be used with this TLS server, and the client MAY use an alternative certificate validation method. In the remaining case, all queries have given "secure" results. The client collects all TLSFP records from the initial query and the second query if applicable and discards any whose hash types it does not understand. If no records remain, KIDNS does not apply and the client MAY use an alternative method. Otherwise, if the certificate presented by the server matches any of the TLSFP records, validation succeeds; if not, it fails and the client MUST abort the TLS handshake with an "unknown_ca" error. ----- Note, I think the proper error when the certificate doesn't match any of the TLSFP records is "unknown_ca", by analogy to a certificate that doesn't chain to any PKIX trust anchor. Based on the description in RFC 5246, I think "access_denied" is for a server to tell a properly authenticated client that authorization to use the service is denied. I'm not sure what would be the best error for when the DNSSEC query fails. This is still assuming TLSFP is exclusive. If that were made a flag, then we would just change the last case (presented certificate doesn't match any TLSFP) to fall back to the alternative method if the flag is off. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB68B3A6801 for ; Sat, 30 Oct 2010 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, HTML_NONELEMENT_30_40=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVDQL1DRPkVR for ; Sat, 30 Oct 2010 13:52:18 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 61ED83A67F3 for ; Sat, 30 Oct 2010 13:52:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=kEfR9QVKyVl//1MY3xDzbjcNWxrccBxj29MZ7EGeKZhGRl0gqFaUzQeBZxzygien; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PCIRL-0003mN-Ka for keyassure@ietf.org; Sat, 30 Oct 2010 16:54:15 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 30 Oct 2010 16:54:15 -0400 Message-ID: <1711640.1288472055596.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Sat, 30 Oct 2010 15:54:15 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: keyassure@ietf.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688f7ce3d057db42fa2626e325ff772eee6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 20:52:20 -0000


-----Original Message-----
From: Steve Schultze
Sent: Oct 30, 2010 3:39 PM
To: keyassure@ietf.org
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns


On Oct 30, 2010, at 4:13 PM, Matt McCutchen wrote:
Ok, and I am suggesting the client should be allowed to do that in our
spec.  In the language of RFC 4033, it seems that the client would
require  "secure" state plus a valid KIDNS record.

Right.

Or a "secure" denial of existence of an exclusive KIDNS record.  Signed
zones don't necessarily use exclusive KIDNS.  People would be up in arms
if signing their zone suddenly broke all their TLS servers.

Right.

They might also allow an "insecure" state plus a validating PKIX cert.

Right, that is the idea for a backward-compatible client.  "Secure"
zones that opt in to exclusive KIDNS get the presumed security benefits,
everyone else's traditional PKIX certificates continue to work.

Right.

The vulnerability would only manifest itself if the client allowed
"indeterminate" state and a validating PKIX cert.

As I read it, "indeterminate" means the zone is not within the scope of
any of the configured trust anchors.  This is basically equivalent to
"insecure": in both cases, the client knows that, with respect to its
trust anchor configuration, the zone is not signed.  This condition
cannot be faked by a MITM attacker.
Right,
 
  Unless the trust anchor was the culprit OR the Trust anchor had itself been compermised in some
way, and/or the CA Cert Database had been corrupted accordingly.
Yes, "indeterminate" == "insecure" if the client requires DNSSEC validation. But that would require a MUST NOT in place of the current (implied) MUST in draft-hoffman-keys-linkage-from-dns:

"If the application receives zero usable certificate associations, it [MUST] process TLS in the normal fashion."

...or maybe that's not actually the right place because it presumes that the response is already validated by DNSSEC:

"The DNSSEC signature MUST be validated on all responses in order to assure the proof of origin of the data."

What the current draft does not say is what the client MUST or MAY do if the client is not able to request, perform, or verify DNSSEC validation at all.  The answer will affect the viability of my MITM scenario.

DNSSEC guarantees that if the client queries a zone that is signed (with
respect to its trust anchor configuration), it either gets an
authenticated answer or fails.  We can build upon this property to
distribute KIDNS info in signed zones and know that KIDNS-aware clients
will not proceed without it. 

It's not clear to me, at least in the draft-hoffman-keys-linkage-from-dns draft, that we can "know that KIDNS-aware clients
will not proceed without it."  I don't see any explicit statement to this effect.  I encourage Paul or the others to chime in as to whether this was their intent.
 
  Good point and I agree.  Diliniating the intent is important here.
 
Regards,
 
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827


Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3ED73A67EF for ; Sat, 30 Oct 2010 13:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDETy6hhBvFN for ; Sat, 30 Oct 2010 13:37:28 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 9FC883A6403 for ; Sat, 30 Oct 2010 13:37:28 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o9UKdPxw023899 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Oct 2010 16:39:25 -0400 Received: from new-host-3.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9UKdOS8003577 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Oct 2010 16:39:25 -0400 (EDT) From: Steve Schultze Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-2-926319224 Date: Sat, 30 Oct 2010 16:39:24 -0400 In-Reply-To: <1288469609.1977.178.camel@mattlaptop2.local> To: keyassure@ietf.org References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> <1288469609.1977.178.camel@mattlaptop2.local> Message-Id: X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6152 signatures=648724 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010300119 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 20:37:31 -0000 --Apple-Mail-2-926319224 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 30, 2010, at 4:13 PM, Matt McCutchen wrote: >> Ok, and I am suggesting the client should be allowed to do that in = our >> spec. In the language of RFC 4033, it seems that the client would >> require "secure" state plus a valid KIDNS record. >=20 > Right. >=20 > Or a "secure" denial of existence of an exclusive KIDNS record. = Signed > zones don't necessarily use exclusive KIDNS. People would be up in = arms > if signing their zone suddenly broke all their TLS servers. Right. >> They might also allow an "insecure" state plus a validating PKIX = cert. >=20 > Right, that is the idea for a backward-compatible client. "Secure" > zones that opt in to exclusive KIDNS get the presumed security = benefits, > everyone else's traditional PKIX certificates continue to work. Right. >> The vulnerability would only manifest itself if the client allowed >> "indeterminate" state and a validating PKIX cert. >=20 > As I read it, "indeterminate" means the zone is not within the scope = of > any of the configured trust anchors. This is basically equivalent to > "insecure": in both cases, the client knows that, with respect to its > trust anchor configuration, the zone is not signed. This condition > cannot be faked by a MITM attacker. Yes, "indeterminate" =3D=3D "insecure" if the client requires DNSSEC = validation. But that would require a MUST NOT in place of the current = (implied) MUST in draft-hoffman-keys-linkage-from-dns: "If the application receives zero usable certificate associations, it = [MUST] process TLS in the normal fashion." ...or maybe that's not actually the right place because it presumes that = the response is already validated by DNSSEC: "The DNSSEC signature MUST be validated on all responses in order to = assure the proof of origin of the data." What the current draft does not say is what the client MUST or MAY do if = the client is not able to request, perform, or verify DNSSEC validation = at all. The answer will affect the viability of my MITM scenario. > DNSSEC guarantees that if the client queries a zone that is signed = (with > respect to its trust anchor configuration), it either gets an > authenticated answer or fails. We can build upon this property to > distribute KIDNS info in signed zones and know that KIDNS-aware = clients > will not proceed without it.=20 It's not clear to me, at least in the = draft-hoffman-keys-linkage-from-dns draft, that we can "know that = KIDNS-aware clients will not proceed without it." I don't see any explicit statement to = this effect. I encourage Paul or the others to chime in as to whether = this was their intent. --Apple-Mail-2-926319224 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Ok, = and I am suggesting the client should be allowed to do that in = our
spec.  In the = language of RFC 4033, it seems that the client = would
require  "secure" = state plus a valid KIDNS record.

Right.

Or a = "secure" denial of existence of an exclusive KIDNS record. =  Signed
zones don't necessarily use exclusive KIDNS. =  People would be up in arms
if signing their zone suddenly broke = all their TLS = servers.

Right.

They might also allow = an "insecure" state plus a validating PKIX = cert.

Right, that is the idea for a = backward-compatible client.  "Secure"
zones that opt in to = exclusive KIDNS get the presumed security benefits,
everyone else's = traditional PKIX certificates continue to = work.

Right.

The vulnerability would = only manifest itself if the client allowed
"indeterminate" state and a validating PKIX = cert.

As I read it, "indeterminate" means the zone = is not within the scope of
any of the configured trust anchors. =  This is basically equivalent to
"insecure": in both cases, the = client knows that, with respect to its
trust anchor configuration, = the zone is not signed.  This condition
cannot be faked by a = MITM attacker.

Yes, = "indeterminate" =3D=3D "insecure" if the client requires DNSSEC = validation. But that would require a MUST NOT in place of the current = (implied) MUST = in draft-hoffman-keys-linkage-from-dns:

"If the application receives zero usable certificate associations, it = [MUST] process TLS in the normal = fashion."

...or maybe that's not actually = the right place because it presumes that the response is already = validated by DNSSEC:

"The DNSSEC signature MUST = be validated on all responses in order to assure the proof of origin of = the data."

What the current draft does not say = is what the client MUST or MAY do if the client is not able to request, = perform, or verify DNSSEC validation at all.  The answer will = affect the viability of my MITM scenario.

DNSSEC guarantees that if the client queries a zone = that is signed (with
respect to its trust anchor configuration), it = either gets an
authenticated answer or fails.  We can build upon = this property to
distribute KIDNS info in signed zones and know that = KIDNS-aware clients
will not proceed without = it. 

It's not clear to me, at = least in the draft-hoffman-keys-linkage-from-dns draft, that we can = "know that KIDNS-aware clients
will not proceed without = it."  I don't see any explicit statement to this effect. =  I encourage Paul or the others to chime in as to whether this was = their intent.

= --Apple-Mail-2-926319224-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1B93A6452 for ; Sat, 30 Oct 2010 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6bSggjCF3Jz for ; Sat, 30 Oct 2010 13:27:36 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 958903A6403 for ; Sat, 30 Oct 2010 13:27:36 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id C733C63406F; Sat, 30 Oct 2010 13:29:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=hJMpwlJUDST2NqmhubINMk9iqWtfTasl4fV3c3NUVa8 UUTd3wSnGwWV0NyV72tFkkypl14eWDSPvd6uLcp3zNikCyyBPYAI3ebJXpD/VN5U LHezyFD6PMb2nETJI92nk5Me4acQZtkdO1QG+9FOpQoHVNUEp7YyHXCkuvAsQznA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=vGduyMYpywLIdtn7JXy5GDwVIk4=; b=PQ9yAtox9K yJcw7b48x+mWm5fzFvCWLCX5OP4n4tSoLu2cp37c05eKUOmtKvGTxEHtmPvyTKed qAZSpYZn7piZ5Np4vZO7qNMV2myPPojEGEK3k31mYlZVjl7iNPZE/Cv2ewOhnIpc BC2fRe9S+Hmlu8f0JfALiVWA+59jKUVvg= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 8404263406E; Sat, 30 Oct 2010 13:29:33 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> Content-Type: text/plain; charset="UTF-8" Date: Sat, 30 Oct 2010 16:29:32 -0400 Message-ID: <1288470572.1977.210.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 20:27:38 -0000 On Sat, 2010-10-30 at 14:24 -0400, Phillip Hallam-Baker wrote: > I am fine with this as an option. > > But I think that making it useful and scalable requires us to provide more > than just a flag. Can you provide a specific, compelling example? > What we are proposing here is an aspect of security policy. Which gets us > into territory that is generally considered 'difficult' and every security > AD that I have ever discussed this with has expressed extreme skepticism as > to whether a WG can get to closure if it addresses security policy. The term > 'rat hole' is used. [...] The flag has a simple and clear semantic, "I authorize this certificate and only this certificate for use on my TLS server", and is already useful to folks like me who can't wait to publish a single exclusive certificate in DNSSEC and no longer be exposed to the likes of Etisalat. You seem to be saying that we should hold off on standardizing the exclusivity flag because there are some use cases that require a more sophisticated scheme, but also that we might never complete such a scheme. So what can be the benefit of waiting, compared to standardizing the flag now? -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EA23A67EF for ; Sat, 30 Oct 2010 13:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJAqJmOZ4Yj6 for ; Sat, 30 Oct 2010 13:11:33 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 9ECB13A6774 for ; Sat, 30 Oct 2010 13:11:33 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 254FD70407D; Sat, 30 Oct 2010 13:13:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=DzkEfL9gzQmOoMwleVcghktKP4tp2HeGUdmcEZm25o3 Ezd3lTurGuM6nkqtt/GRbWDr9LGJxFknV808nxo9wSKB03+WbMLAJmkhUKlTcSSz 2l7igyMnJXnaPf/lSu0iytJP2lBxfdIezeJFQ5yxwVPX0UA7juoIHcUT9CTS67Wo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=mLgiEXyhiEdSZUtSyR2gNuC7I3U=; b=EWZAgZnLtH cBzAyBShh75mBU/pdKOyoYFrMMTAdINk/y/n5Vw0e62iyG35BRLz4kD4UUGDXfps 49UMwYO3n66tWGzigsYwVIzqoFbctbNp1KJarm8ZkHDiU788syBh6i5DXGFH3zPU 762udLsnntZ+MFCU+GglXtWaGbpVcunj4= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id CF19E70407C; Sat, 30 Oct 2010 13:13:30 -0700 (PDT) From: Matt McCutchen To: Steve Schultze In-Reply-To: <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> Content-Type: text/plain; charset="UTF-8" Date: Sat, 30 Oct 2010 16:13:29 -0400 Message-ID: <1288469609.1977.178.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 20:11:34 -0000 On Sat, 2010-10-30 at 15:04 -0400, Steve Schultze wrote: > On Oct 30, 2010, at 2:20 PM, Matt McCutchen wrote: > > On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote: > >> On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote: > >>>> I would note that, presuming KIDNS only affects client behavior > >>>> when the client can directly verify that the records were validly > >>>> DNSSEC-signed (is this everybody's assumption?), using a MUST creates > >>>> a downgrade attack in which a MITM can force PKIX-only validation by > >>>> simply blocking DNSSEC-validated DNS results. > >>> > >>> Surely not - in this case the client sees DNS failures, rather than a > >>> lack of results and so should squawk about that problem. > >> > >> There would only be DNS failures if the MITM were blocking responses > >> altogether, rather than returning bogus responses containing no KIDNS > >> (non-DNSSEC-validated, of course). Unless you assumed that a client > >> would always bail unless it got a validated DNSSEC response, which is > >> not viable to mandate... especially on day one. > > > > DNSSEC was specifically designed to address this concern (see RFC 4033 > > section 5). > > Ah, interesting. The four states described there is illuminating. > > > The client can require either a valid DNSSEC response > > Ok, and I am suggesting the client should be allowed to do that in our > spec. In the language of RFC 4033, it seems that the client would > require "secure" state plus a valid KIDNS record. Right. > They might also allow an "insecure" state Or a "secure" denial of existence of an exclusive KIDNS record. Signed zones don't necessarily use exclusive KIDNS. People would be up in arms if signing their zone suddenly broke all their TLS servers. > plus a validating PKIX cert. Right, that is the idea for a backward-compatible client. "Secure" zones that opt in to exclusive KIDNS get the presumed security benefits, everyone else's traditional PKIX certificates continue to work. > The vulnerability would only manifest itself if the client allowed > "indeterminate" state and a validating PKIX cert. As I read it, "indeterminate" means the zone is not within the scope of any of the configured trust anchors. This is basically equivalent to "insecure": in both cases, the client knows that, with respect to its trust anchor configuration, the zone is not signed. This condition cannot be faked by a MITM attacker. Note that if you use the IANA trust anchor for the root zone, nothing will be indeterminate. > I think that it is just another way of expressing what I was > describing. I'm not sure what you mean. DNSSEC guarantees that if the client queries a zone that is signed (with respect to its trust anchor configuration), it either gets an authenticated answer or fails. We can build upon this property to distribute KIDNS info in signed zones and know that KIDNS-aware clients will not proceed without it. For everyone else (signed zones without KIDNS info, and zones known to be unsigned), the old semantics apply. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 205B03A677D for ; Sat, 30 Oct 2010 12:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.984 X-Spam-Level: X-Spam-Status: No, score=-3.984 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c--nCIXkHRBa for ; Sat, 30 Oct 2010 12:02:09 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 07DA83A65A5 for ; Sat, 30 Oct 2010 12:02:08 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o9UJ45tj015947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Oct 2010 15:04:06 -0400 Received: from new-host-3.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9UJ45S8012618 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Oct 2010 15:04:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Schultze In-Reply-To: <1288462840.1977.4.camel@mattlaptop2.local> Date: Sat, 30 Oct 2010 15:04:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69345A7D-4834-40E4-99C2-EDF3FC2DDEB3@Princeton.EDU> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <1288462840.1977.4.camel@mattlaptop2.local> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6152 signatures=648724 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010300109 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 19:02:10 -0000 On Oct 30, 2010, at 2:20 PM, Matt McCutchen wrote: > On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote: >> On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote: >>>> I would note that, presuming KIDNS only affects client behavior >>>> when the client can directly verify that the records were validly >>>> DNSSEC-signed (is this everybody's assumption?), using a MUST = creates >>>> a downgrade attack in which a MITM can force PKIX-only validation = by >>>> simply blocking DNSSEC-validated DNS results. >>>=20 >>> Surely not - in this case the client sees DNS failures, rather than = a >>> lack of results and so should squawk about that problem. >>=20 >> There would only be DNS failures if the MITM were blocking responses >> altogether, rather than returning bogus responses containing no KIDNS >> (non-DNSSEC-validated, of course). Unless you assumed that a client >> would always bail unless it got a validated DNSSEC response, which is >> not viable to mandate... especially on day one. >=20 > DNSSEC was specifically designed to address this concern (see RFC 4033 > section 5). =20 Ah, interesting. The four states described there is illuminating. > The client can require either a valid DNSSEC response Ok, and I am suggesting the client should be allowed to do that in our = spec. In the language of RFC 4033, it seems that the client would = require "secure" state plus a valid KIDNS record. They might also = allow an "insecure" state plus a validating PKIX cert. The = vulnerability would only manifest itself if the client allowed = "indeterminate" state and a validating PKIX cert. I think that it is = just another way of expressing what I was describing. Presuming the = client can know these states, or the default behavior of the client's = resolving code prohibits "indeterminate" responses (is this likely?), I = think you're right that it solves my problem. Right? > or a proof that the target zone is not using DNSSEC Of course this _also_ requires a valid DNSSEC response in the state of = "insecure", per Section 5: "at some delegation point, signed proof of the non-existence of a DS = record" > in which case the client behaves as if the zone contains no KIDNS = information. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DBA3A6855 for ; Sat, 30 Oct 2010 11:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2pr6g5X0jyg for ; Sat, 30 Oct 2010 11:24:40 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D49593A67EF for ; Sat, 30 Oct 2010 11:24:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RjZH8YGU9s/P6h/UZvskrrvONk6HyRh6I1mMNqLDacfPJ0TDG0lJ2DTMx4pJazBQ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PCG8T-00068U-8G for keyassure@ietf.org; Sat, 30 Oct 2010 14:26:37 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 30 Oct 2010 14:26:36 -0400 Message-ID: <18953194.1288463197009.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Sat, 30 Oct 2010 13:26:36 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606887ec0280474f1b256671cf0925e08ad6d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 18:24:41 -0000 Steve and all, -----Original Message----- >From: Steve Schultze >Sent: Oct 30, 2010 12:50 PM >To: keyassure@ietf.org >Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns > >On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote: >>> I would note that, presuming KIDNS only affects client behavior when the client can directly verify that the records were validly DNSSEC-signed (is this everybody's assumption?), using a MUST creates a downgrade attack in which a MITM can force PKIX-only validation by simply blocking DNSSEC-validated DNS results. >> >> Surely not - in this case the client sees DNS failures, rather than a >> lack of results and so should squawk about that problem. > >There would only be DNS failures if the MITM were blocking responses altogether, rather than returning bogus responses containing no KIDNS (non-DNSSEC-validated, of course). Unless you assumed that a client would always bail unless it got a validated DNSSEC response, which is not viable to mandate... especially on day one. Good reiterated point, and agreed. Especially that we do not now, nor can I ever invision that we can ever will have absolute trust that ALL DNSSEC responses that fail or not, are properly/accurately validated although they may be "authoritatively". >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 Network Eng. SR. Eng. Network data security ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9033A67EF for ; Sat, 30 Oct 2010 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUbvphxhRCM9 for ; Sat, 30 Oct 2010 11:22:17 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CB6DE3A63C9 for ; Sat, 30 Oct 2010 11:22:16 -0700 (PDT) Received: by iwn40 with SMTP id 40so5419630iwn.31 for ; Sat, 30 Oct 2010 11:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6iGsgYw4Kh6s9gX5F8FweNBk5wFEsWk9af02YX7sbJM=; b=FR60ZgINcqsEDQu3Yx3owuFHavZXvOaHtJQEkeQ/RWIJ7gEnG7SV/6jCiSVhSJ7aEf T20zpm+Qf+w/mikCV5n146ZQNzPTn7cuB7hPFlRi73TAQW3+tUL3l823twfrfm+i0jM2 1N1qRKe+A3W6n0Lpo5Dwvd/D7N4HPfEpULqpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FuriI3ZYp0dmqAUO49DdX3vdT69syarymLDEJGFoCt/YbsM772F6JSAevxZtaJy/lD TeiGDeAPStbP0R8fl7a9cDORhNH/7OFnrHl5WgOKX6MumnnUORAZP9jGXrXxLlI63lvV AQHwhBLpmvMEpM7VQCum9PZqBFQ6cTaph7Wds= MIME-Version: 1.0 Received: by 10.42.170.197 with SMTP id g5mr10872810icz.347.1288463052263; Sat, 30 Oct 2010 11:24:12 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Sat, 30 Oct 2010 11:24:12 -0700 (PDT) In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> Date: Sat, 30 Oct 2010 14:24:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Steve Schultze Content-Type: multipart/alternative; boundary=90e6ba6e89648952820493d9aece Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 18:22:18 -0000 --90e6ba6e89648952820493d9aece Content-Type: text/plain; charset=ISO-8859-1 I am fine with this as an option. But I think that making it useful and scalable requires us to provide more than just a flag. What we are proposing here is an aspect of security policy. Which gets us into territory that is generally considered 'difficult' and every security AD that I have ever discussed this with has expressed extreme skepticism as to whether a WG can get to closure if it addresses security policy. The term 'rat hole' is used. I think that we have to divide the security policy into two parts. The first part is providing inputs to security policy, the second part is security policy processing. I think we can point to a lot of experience in defining standards for presenting information in a form that can be used as input to security policy processing. We have many proof points for being able to get to closure (DKIM, SAML, etc.) The second half, security policy processing is where it is very difficult to get agreement on in my view. That is the place that we could not address usefully in SAML, it is also a minefield for IPR. If we can agree on a mechanism for specifying 'my valid keys look like X', I think we can certainly agree on 'I always offer SSL on SMTP'. On Sat, Oct 30, 2010 at 1:58 PM, Steve Schultze wrote: > On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote: > > What I do have a problem with is 'this is the fingerprint of the ONLY > certificate(s) I will use". > > > +1 on Ben's question. Would you be fine if the semantics allow the holder > to specify that it is exclusive? If so, assume that case in my comments > below. > > On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote: > > > The only role that the client can play is to choose to respect those >> semantics or not. >> >> And in my version this is the case. The client decides whether a >> validated KIDNS record is sufficient or necessary. >> > > That is only possible if you have an expectation that every domain that > publishes the records will publish them for every certificate and keep them > up to date. > > > What is only possible? Allowing the client to choose? I don't understand > what you're getting at. There should be no reason why a client shouldn't be > able to say "I will only accept connections when the cert is validated via > DNSSEC-KIDNS." Sure, this means they can't connect to any sites that > haven't done that, but that's the point. > > If you want to have interoperability every client has to draw the same > semantics from a given record. They do not have to react in the same way but > they do have to interpret the intention of the domain holder in the same > way. > > > I don't see how we disagree. If all that is needed is to have a flag such > that the holder can indicate exclusivity, then let's do that and we all > agree. > > In the PKIX model and the OpenPGP model the certificates have the exact > same semantics for every relying party. > > Different relying parties may react differently because the local site > policy is different. In some cases a client may be allowed to act on a > certificate with only a partial understanding of those semantics., in others > the critical bit is set to force a client to ignore a cert it does not fully > understand. > > > Again, presuming a "yes" answer to Ben's question I think we all agree. > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > -- Website: http://hallambaker.com/ --90e6ba6e89648952820493d9aece Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am fine with this as an option.

But I think that makin= g it useful and scalable requires us to provide more than just a flag.


What we are proposing here is an aspect= of security policy. Which gets us into territory that is generally conside= red 'difficult' and every security AD that I have ever discussed th= is with has expressed extreme skepticism as to whether a WG can get to clos= ure if it addresses security policy. The term 'rat hole' is used.

I think that we have to divide the security policy into= two parts. The first part is providing inputs to security policy, the seco= nd part is security policy processing.

I think we = can point to a lot of experience in defining standards for presenting infor= mation in a form that can be used as input to security policy processing. W= e have many proof points for being able to get to closure (DKIM, SAML, etc.= )


The second half, security policy process= ing is where it is very difficult to get agreement on in my view. That is t= he place that we could not address usefully in SAML, it is also a minefield= for IPR.

If we can agree on a mechanism for specifying 'my v= alid keys look like X', I think we can certainly agree on 'I always= offer SSL on SMTP'.


On Sa= t, Oct 30, 2010 at 1:58 PM, Steve Schultze <sjs@princeton.edu> wrote:
On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
What I do have a problem= with is 'this is the fingerprint of the ONLY certificate(s) I will use= ".

+1 on Ben's question. =A0Would you be fine i= f the semantics allow the holder to specify that it is exclusive? =A0If so,= assume that case in my comments below.

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
> The only role that the client can play is to choose to respect th= ose semantics or not.

And in my version this is the case. =A0T= he client decides whether a validated KIDNS record is sufficient or necessa= ry.

That is only possible if you have an expec= tation that every domain that publishes the records will publish them for e= very certificate and keep them up to date.

What is only possible? =A0Allowing the client to choos= e? =A0I don't understand what you're getting at. =A0There should be= no reason why a client shouldn't be able to say "I will only acce= pt connections when the cert is validated via DNSSEC-KIDNS." =A0Sure, = this means they can't connect to any sites that haven't done that, = but that's the point.

If you want to have interoperability every client has to draw the same sema= ntics from a given record. They do not have to react in the same way but th= ey do have to interpret the intention of the domain holder in the same way.=

I don't see how we disagree. = =A0If all that is needed is to have a flag such that the holder can indicat= e exclusivity, then let's do that and we all agree.

In the PKIX model and the OpenPGP model the certificates have the exact sam= e semantics for every relying party.

Different rel= ying parties may react differently because the local site policy is differe= nt. In some cases a client may be allowed to act on a certificate with only= a partial understanding of those semantics., in others the critical bit is= set to force a client to ignore a cert it does not fully understand.

Again, presuming a "yes"= answer to Ben's question I think we all agree.

__= _____________________________________________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure




--
Website: http://hallambaker.com/

--90e6ba6e89648952820493d9aece-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988CE3A67E7 for ; Sat, 30 Oct 2010 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB243xuCGxKv for ; Sat, 30 Oct 2010 11:18:44 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 771AC3A63C9 for ; Sat, 30 Oct 2010 11:18:44 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id C0B3F28006D; Sat, 30 Oct 2010 11:20:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=jn/cOVQRTF0zYfpzjh41byZgFgYdo8Zkp5YvuQs9ZgO f2Dp4qy4kde3ZCQOQijEKpE0KwCnMgdpVDwSi7vpW3mEtq/sVijpjy9TwCvw5omM SbUc/vvSbwlXZQMC2esY4i21V+10y19MqfRQKDN7ORD5YUSjM2PkHY04kZeSMVYY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=maExV0JhEz6zj8C3tZM69vPWjmM=; b=qgsj3nPf8i zB7dJT94JC578cmxI06sF+7ZE0dhoKz3MAcR7qBvc3sb4u8cMhEWrjkY/BqDOEjG DXfSbHIzkaen6B+zExLdhhRuDOvkR1bu1rflWG0CzqPfSAzH3q8JUGP2DfdBC9av JZ44dqk3TL862Mrli1pLeWLLowx9+NO4U= Received: from [10.108.67.58] (unknown [129.2.129.81]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 75B94280061; Sat, 30 Oct 2010 11:20:41 -0700 (PDT) From: Matt McCutchen To: Steve Schultze In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" Date: Sat, 30 Oct 2010 14:20:40 -0400 Message-ID: <1288462840.1977.4.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 18:18:45 -0000 On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote: > On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote: > >> I would note that, presuming KIDNS only affects client behavior > when the client can directly verify that the records were validly > DNSSEC-signed (is this everybody's assumption?), using a MUST creates > a downgrade attack in which a MITM can force PKIX-only validation by > simply blocking DNSSEC-validated DNS results. > > > > Surely not - in this case the client sees DNS failures, rather than > a > > lack of results and so should squawk about that problem. > > There would only be DNS failures if the MITM were blocking responses > altogether, rather than returning bogus responses containing no KIDNS > (non-DNSSEC-validated, of course). Unless you assumed that a client > would always bail unless it got a validated DNSSEC response, which is > not viable to mandate... especially on day one. DNSSEC was specifically designed to address this concern (see RFC 4033 section 5). The client can require either a valid DNSSEC response or a proof that the target zone is not using DNSSEC, in which case the client behaves as if the zone contains no KIDNS information. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510B53A67CF for ; Sat, 30 Oct 2010 11:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, HTML_NONELEMENT_30_40=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU2egIABGddG for ; Sat, 30 Oct 2010 11:17:18 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id EE88D3A63C9 for ; Sat, 30 Oct 2010 11:17:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=kRi/zhiBMd461m93KVmMdIw6T4fA7hWHXRDaDFGU3CxxL8h5fKKoYYJvLyuRb4Vz; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PCG1K-0003fr-TN; Sat, 30 Oct 2010 14:19:15 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 30 Oct 2010 14:19:14 -0400 Message-ID: <26228660.1288462754881.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Sat, 30 Oct 2010 13:19:14 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Steve Schultze , keyassure@ietf.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688af03cf30dfabf9b2e8a6d262781a8588350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 18:17:19 -0000

Steve and all,

 

  I think we all agree here.  I also think that perhaps there is and has been a language conjugation

problem here.  That being how someone else specifically understands the conjugation of

anothers writing...  But I do think that Phillip is right that the language in draft-hoffman-keys-linkage-from-dns

misses the mark in respect to it's explicitness and as such lends it self to perhaps some interpratation,

which has already been pointed out before and seemingly again here, as to it's lack of clarity in some

respects. 


-----Original Message-----
From: Steve Schultze
Sent: Oct 30, 2010 12:58 PM
To: keyassure@ietf.org
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
What I do have a problem with is 'this is the fingerprint of the ONLY certificate(s) I will use".

+1 on Ben's question.  Would you be fine if the semantics allow the holder to specify that it is exclusive?  If so, assume that case in my comments below.

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:
> The only role that the client can play is to choose to respect those semantics or not.

And in my version this is the case.  The client decides whether a validated KIDNS record is sufficient or necessary.

That is only possible if you have an expectation that every domain that publishes the records will publish them for every certificate and keep them up to date.

What is only possible?  Allowing the client to choose?  I don't understand what you're getting at.  There should be no reason why a client shouldn't be able to say "I will only accept connections when the cert is validated via DNSSEC-KIDNS."  Sure, this means they can't connect to any sites that haven't done that, but that's the point.

If you want to have interoperability every client has to draw the same semantics from a given record. They do not have to react in the same way but they do have to interpret the intention of the domain holder in the same way.

I don't see how we disagree.  If all that is needed is to have a flag such that the holder can indicate exclusivity, then let's do that and we all agree.

In the PKIX model and the OpenPGP model the certificates have the exact same semantics for every relying party.

Different relying parties may react differently because the local site policy is different. In some cases a client may be allowed to act on a certificate with only a partial understanding of those semantics., in others the critical bit is set to force a client to ignore a cert it does not fully understand.

Again, presuming a "yes" answer to Ben's question I think we all agree.
 
Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827

Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383213A67CF for ; Sat, 30 Oct 2010 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuoPpjdYh6Lv for ; Sat, 30 Oct 2010 10:56:57 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E0B703A63C9 for ; Sat, 30 Oct 2010 10:56:56 -0700 (PDT) Received: by iwn40 with SMTP id 40so5399731iwn.31 for ; Sat, 30 Oct 2010 10:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GfmIV3Pa7QBHbBoqjU3l9W3zQ/DCDyRLN9clFDMeNGY=; b=eYYO4DhmpWV5lIQA5LRJE9eCaPecWjB0Bt2ebY5xEkc72VQzZ1L+IsSg6C2YP5CGu1 EUdrpcAhg9rcvTLsL7ItVHJVE37FgkVVr2/+evrAvpPDApT8TtGcbfcxdINa6xlXeMMj TuNX4Vmnu7eckDJrvZ122t7Nl0rlptMLOKO5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ui9oyk39kowL8+6ujtz8n3Eza754LZD2LECOTfw4zU2fwUlf7bD7vm5tL+Bqyot2jr oUFKJ0w9i7DOBXzwCHib9aEfZ/jriLkf2T91hbRRxuIlj1uD/oNCYpnftBy01PjsLNkq SHNdS4AKVXnQKu/jkDsEsdgtoi5kWTyPDcQqI= MIME-Version: 1.0 Received: by 10.42.170.197 with SMTP id g5mr10860526icz.347.1288461533941; Sat, 30 Oct 2010 10:58:53 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Sat, 30 Oct 2010 10:58:53 -0700 (PDT) In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> Date: Sat, 30 Oct 2010 13:58:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=90e6ba6e89640991b10493d95481 Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:56:58 -0000 --90e6ba6e89640991b10493d95481 Content-Type: text/plain; charset=ISO-8859-1 Yes, the holder should have the option. But it does need to be an option and not something that is automatically assumed. And it has to be something that is considered explicitly in the design. On Sat, Oct 30, 2010 at 1:16 PM, Ben Laurie wrote: > On 30 October 2010 18:03, Phillip Hallam-Baker wrote: > > > > > > On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze > wrote: > >> What is being suggested is that the domain name holder has the semantics > >> to say, "this is the fingerprint of the certificate I will use." > > > > Which I have no problem with. > > What I do have a problem with is 'this is the fingerprint of the ONLY > > certificate(s) I will use". > > You do agree that the holder should have the _option_ to say that, right? > -- Website: http://hallambaker.com/ --90e6ba6e89640991b10493d95481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, the holder should have the option.

But it does need= to be an option and not something that is automatically assumed.

And it has to be something that is considered explicitly in= the design.


On Sat, Oct 30, 2010 at = 1:16 PM, Ben Laurie <benl@google.com> wrote:
On 30 October 2010 18:03, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>
> On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze <sjs@princeton.edu> wrote:
>> What is being suggested is that the domain= name holder has the semantics
>> to say, "this is the fingerprint of the certificate I will us= e."
>
> Which I have no problem with.
> What I do have a problem with is 'this is the fingerprint of the O= NLY
> certificate(s) I will use".

You do agree that the holder should have the _option_ to say that, ri= ght?



--
Website: http://hallambaker.com/

--90e6ba6e89640991b10493d95481-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAC23A67CF for ; Sat, 30 Oct 2010 10:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vdpXMrT5Eb4 for ; Sat, 30 Oct 2010 10:56:26 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id 8469C3A63C9 for ; Sat, 30 Oct 2010 10:56:26 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o9UHwMKM026335 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Oct 2010 13:58:22 -0400 Received: from new-host-3.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9UHwLS8027694 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Oct 2010 13:58:22 -0400 (EDT) From: Steve Schultze Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1-916655826 Date: Sat, 30 Oct 2010 13:58:20 -0400 In-Reply-To: To: keyassure@ietf.org References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> Message-Id: X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6152 signatures=648724 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010300100 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:56:28 -0000 --Apple-Mail-1-916655826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote: > What I do have a problem with is 'this is the fingerprint of the ONLY = certificate(s) I will use". +1 on Ben's question. Would you be fine if the semantics allow the = holder to specify that it is exclusive? If so, assume that case in my = comments below. On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote: > > The only role that the client can play is to choose to respect those = semantics or not. >=20 > And in my version this is the case. The client decides whether a = validated KIDNS record is sufficient or necessary. >=20 > That is only possible if you have an expectation that every domain = that publishes the records will publish them for every certificate and = keep them up to date. What is only possible? Allowing the client to choose? I don't = understand what you're getting at. There should be no reason why a = client shouldn't be able to say "I will only accept connections when the = cert is validated via DNSSEC-KIDNS." Sure, this means they can't = connect to any sites that haven't done that, but that's the point. > If you want to have interoperability every client has to draw the same = semantics from a given record. They do not have to react in the same way = but they do have to interpret the intention of the domain holder in the = same way. I don't see how we disagree. If all that is needed is to have a flag = such that the holder can indicate exclusivity, then let's do that and we = all agree. > In the PKIX model and the OpenPGP model the certificates have the = exact same semantics for every relying party. >=20 > Different relying parties may react differently because the local site = policy is different. In some cases a client may be allowed to act on a = certificate with only a partial understanding of those semantics., in = others the critical bit is set to force a client to ignore a cert it = does not fully understand. Again, presuming a "yes" answer to Ben's question I think we all agree.= --Apple-Mail-1-916655826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii What I do = have a problem with is 'this is the fingerprint of the ONLY = certificate(s) I will use".

+1 = on Ben's question.  Would you be fine if the semantics allow the = holder to specify that it is exclusive?  If so, assume that case in = my comments below.

On Oct 30, 2010, at 1:03 PM, = Phillip Hallam-Baker wrote:
> The only role that the client can play is to choose to = respect those semantics or not.

And in my version this is = the case.  The client decides whether a validated KIDNS record is = sufficient or necessary.

That is = only possible if you have an expectation that every domain that = publishes the records will publish them for every certificate and keep = them up to date.

What is = only possible?  Allowing the client to choose?  I don't = understand what you're getting at.  There should be no reason why a = client shouldn't be able to say "I will only accept connections when the = cert is validated via DNSSEC-KIDNS."  Sure, this means they can't = connect to any sites that haven't done that, but that's the = point.

If you = want to have interoperability every client has to draw the same = semantics from a given record. They do not have to react in the same way = but they do have to interpret the intention of the domain holder in the = same way.

I don't see how we = disagree.  If all that is needed is to have a flag such that the = holder can indicate exclusivity, then let's do that and we all = agree.

In the = PKIX model and the OpenPGP model the certificates have the exact same = semantics for every relying party.

Different = relying parties may react differently because the local site policy is = different. In some cases a client may be allowed to act on a certificate = with only a partial understanding of those semantics., in others the = critical bit is set to force a client to ignore a cert it does not fully = understand.

Again, presuming a = "yes" answer to Ben's question I think we all = agree.
= --Apple-Mail-1-916655826-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C1E3A67BE for ; Sat, 30 Oct 2010 10:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNt4-v1uXAIn for ; Sat, 30 Oct 2010 10:48:50 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id BDD6F3A63C9 for ; Sat, 30 Oct 2010 10:48:49 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o9UHok53024742 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Oct 2010 13:50:46 -0400 Received: from new-host-3.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9UHojKO016842 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Oct 2010 13:50:46 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Schultze In-Reply-To: Date: Sat, 30 Oct 2010 13:50:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6152 signatures=648724 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010300099 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:48:53 -0000 On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote: >> I would note that, presuming KIDNS only affects client behavior when = the client can directly verify that the records were validly = DNSSEC-signed (is this everybody's assumption?), using a MUST creates a = downgrade attack in which a MITM can force PKIX-only validation by = simply blocking DNSSEC-validated DNS results. >=20 > Surely not - in this case the client sees DNS failures, rather than a > lack of results and so should squawk about that problem. There would only be DNS failures if the MITM were blocking responses = altogether, rather than returning bogus responses containing no KIDNS = (non-DNSSEC-validated, of course). Unless you assumed that a client = would always bail unless it got a validated DNSSEC response, which is = not viable to mandate... especially on day one.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130E83A67BE for ; Sat, 30 Oct 2010 10:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.121 X-Spam-Level: X-Spam-Status: No, score=-108.121 tagged_above=-999 required=5 tests=[AWL=1.856, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4p1cBgZ5Lhr for ; Sat, 30 Oct 2010 10:14:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id EAF1A3A67EB for ; Sat, 30 Oct 2010 10:14:16 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o9UHGCjB000659 for ; Sat, 30 Oct 2010 10:16:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288458973; bh=SjrTc9wdoUJB4KZ7Sf8F4sTmDDw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=t/YFsAk0y5u2Hh7xc/JBqN3250mcJJbuMuDfhwmcCACy1oKwT880rrbTi2H3dYHKn pCqCjoG06KK463UwZliHA== Received: from pxi13 (pxi13.prod.google.com [10.243.27.13]) by kpbe19.cbf.corp.google.com with ESMTP id o9UHGAsR000410 for ; Sat, 30 Oct 2010 10:16:11 -0700 Received: by pxi13 with SMTP id 13so262081pxi.3 for ; Sat, 30 Oct 2010 10:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5IA6furGMaRqZAW1vjvcTNjHqQadudpTw7NM3o92PUA=; b=ideg9cPhlWZpVGzuhBkNQxx8KstCDTnlL/+QP6Ga17cBKvNyGA0c/BM2wIYcJpO8Eu fVtoqJPx4pPOg/0ibhvw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v7qwmapFdJOUE3Mhrydy7ac+5kyGxFDic6ywJXP/rmqCycgGohqt7sPP5+Vejr+ODs KBk4tpCud663z+sLbeew== MIME-Version: 1.0 Received: by 10.142.134.15 with SMTP id h15mr2212058wfd.397.1288458970583; Sat, 30 Oct 2010 10:16:10 -0700 (PDT) Received: by 10.142.13.17 with HTTP; Sat, 30 Oct 2010 10:16:10 -0700 (PDT) In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> Date: Sat, 30 Oct 2010 18:16:10 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:14:18 -0000 On 30 October 2010 18:03, Phillip Hallam-Baker wrote: > > > On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze wrote: >> What is being suggested is that the domain name holder has the semantics >> to say, "this is the fingerprint of the certificate I will use." > > Which I have no problem with. > What I do have a problem with is 'this is the fingerprint of the ONLY > certificate(s) I will use". You do agree that the holder should have the _option_ to say that, right? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08D3B3A67BE for ; Sat, 30 Oct 2010 10:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOWvQuu9nFnc for ; Sat, 30 Oct 2010 10:01:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7EEA83A677D for ; Sat, 30 Oct 2010 10:01:13 -0700 (PDT) Received: by gya6 with SMTP id 6so2752075gya.31 for ; Sat, 30 Oct 2010 10:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rv/U74TB1OHwnNrCoo+vHKuBT3GFMajDDHi73S1mGlc=; b=iq11IewUSN5vfU4yXtDUYRbaWaNqvu5MoOoAwE2/YndfzIiZA24NvnTp0wpfgzqPac xp/67JeY3yqxgyljdLyU8wl+nm6b2B83q1hUkKPsn2mYzqvA2B7S/xDocGoR6nT0soyw idwGFEOLB4jt3XO07vxN/FBBVcA8JNE6xnZ+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HaNRPXOtA6SbNVCdo6PyJwtlKwcZKfW3cCiJlzp9v83SMpkUv70xixeUUEPSoo19Gv 8W88DbEImulbjUlzCe0ZJ5CablTSKN0MpKK9zjuTO4AWGoNxPSitV8KLyPKp1VH6OAyz 0bjJ8xiVBPZNNzauq8dIG4qxC2jLnPcDV/uBk= MIME-Version: 1.0 Received: by 10.42.11.12 with SMTP id s12mr11029209ics.101.1288458190384; Sat, 30 Oct 2010 10:03:10 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Sat, 30 Oct 2010 10:03:10 -0700 (PDT) In-Reply-To: <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> Date: Sat, 30 Oct 2010 13:03:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Steve Schultze Content-Type: multipart/alternative; boundary=20cf30434864bef0f00493d88c82 Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 17:01:15 -0000 --20cf30434864bef0f00493d88c82 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze wrote: > On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote: > > What it sounds like to me is that people are suggesting that it is up to > the client to decide what semantics that the domain name holder intended > when they published the record. > > What is being suggested is that the domain name holder has the semantics to > say, "this is the fingerprint of the certificate I will use." Which I have no problem with. What I do have a problem with is 'this is the fingerprint of the ONLY certificate(s) I will use". We cannot have interoperability unless the clients all have a precise agreement on the intended semantics. The person (or robot) who publishes the name in the domain needs to understand precisely how clients will react and plan for the most restrictive case. > > The only role that the client can play is to choose to respect those > semantics or not. > > And in my version this is the case. The client decides whether a validated > KIDNS record is sufficient or necessary. > That is only possible if you have an expectation that every domain that publishes the records will publish them for every certificate and keep them up to date. If you want to have interoperability every client has to draw the same semantics from a given record. They do not have to react in the same way but they do have to interpret the intention of the domain holder in the same way. > (There may be other things that the domain holder can state in DNS, along > the lines of what you have suggested elsewhere, which I think are equally > subject to client discretion in the same fashion.) > > This is parallel to what we have today with the PKIX/CA model. Servers > present certs which the client decides to trust or not, based on its root > cert store, customized trust bits, and user override. This is a feature > because it allows clients with different trust preferences to operate in a > way that respects those. In the PKIX model and the OpenPGP model the certificates have the exact same semantics for every relying party. Different relying parties may react differently because the local site policy is different. In some cases a client may be allowed to act on a certificate with only a partial understanding of those semantics., in others the critical bit is set to force a client to ignore a cert it does not fully understand. Specifying standards for specifying local security policy is hard and possibly unnecessary. SAML specifies attributes for Authentication, Authentication and Attributes, all of which provide inputs to security policy but does not specify how those inputs are to be processed. -- Website: http://hallambaker.com/ --20cf30434864bef0f00493d88c82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 30, 2010 at 11:42 AM, Steve = Schultze <sjs@pri= nceton.edu> wrote:
On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote:=
> What it sounds like to me is that people are suggesting that it is up = to the client to decide what semantics that the domain name holder intended= when they published the record.

What is being suggested is that the domain name holder has the semant= ics to say, "this is the fingerprint of the certificate I will use.&qu= ot;

Which I have no problem with.

What I do have a problem with is 'this is the finge= rprint of the ONLY certificate(s) I will use".


We cannot have interoperability unless the clients all hav= e a precise agreement on the intended semantics. The person (or robot) who = publishes the name in the domain needs to understand precisely how clients = will react and plan for the most restrictive case.

=A0
> The only role that the client can play is to choose to respect those s= emantics or not.

And in my version this is the case. =A0The client decides whether a v= alidated KIDNS record is sufficient or necessary.

=
That is only possible if you have an expectation that every doma= in that publishes the records will publish them for every certificate and k= eep them up to date.

If you want to have interoperability every client has t= o draw the same semantics from a given record. They do not have to react in= the same way but they do have to interpret the intention of the domain hol= der in the same way.

=A0
(There may be other things that the domain holder can state in DNS, along t= he lines of what you have suggested elsewhere, which I think are equally su= bject to client discretion in the same fashion.)

This is parallel to what we have today with the PKIX/CA model. =A0Servers p= resent certs which the client decides to trust or not, based on its root ce= rt store, customized trust bits, and user override. =A0This is a feature be= cause it allows clients with different trust preferences to operate in a wa= y that respects those.

In the PKIX model and the OpenPGP model the certificate= s have the exact same semantics for every relying party.

Different relying parties may react differently because the local si= te policy is different. In some cases a client may be allowed to act on a c= ertificate with only a partial understanding of those semantics., in others= the critical bit is set to force a client to ignore a cert it does not ful= ly understand.


Specifying standards for specifying loca= l security policy is hard and possibly unnecessary. SAML specifies attribut= es for Authentication, Authentication and Attributes, all of which provide = inputs to security policy but does not specify how those inputs are to be p= rocessed.


--
Website: http://hallambaker.com/

--20cf30434864bef0f00493d88c82-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE7A3A659A for ; Sat, 30 Oct 2010 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAg3L5dQZFHC for ; Sat, 30 Oct 2010 09:26:52 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 819983A63C9 for ; Sat, 30 Oct 2010 09:26:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=CBjS9hJ5+ehhtN0P5B/EbKdy+ln3KFLowxjz3D4uSYA1QptktcuJAf3MGcMGydDh; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PCEIT-0004qS-Dg; Sat, 30 Oct 2010 12:28:49 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 30 Oct 2010 12:28:49 -0400 Message-ID: <7638201.1288456129362.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Sat, 30 Oct 2010 11:28:49 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Steve Schultze , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068821bbfae57e8457c401a32ad3e125bd67350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 16:26:54 -0000 Steve and all, -----Original Message----- >From: Steve Schultze >Sent: Oct 30, 2010 10:05 AM >To: keyassure@ietf.org >Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns > >Ben, I'm porting your comment below into this thread for the sake of subject-line clarity (none of this is WG-formation specific, I believe). > >On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: >> Paul wants client policy to decide whether to trust PKIX, DNSSEC or >> some mixture of the two. This seems not only reasonable, but >> unavoidable: clients will implement what suits them, and we are in no >> position to change that. >> >> Phillip wants the domain in question to be able to state its >> intentions w.r.t. the policy clients should use. This seems not >> unreasonable, also. Clients can choose to follow this or not. > >What effect does this have on the MUST vs. MAY suggestions I made to the draft-hoffman-keys-linkage-from-dns-03 text? I believe that what you are saying is that the spec should leave it open to the client how to react to different validation outcome permutations from PKIX and DNSSEC-secured KIDNS. In that case, the two excerpts I quoted should be MAY, as I suggested. This also means that I disagree with Paul, who thinks that MUST should be used. I prefer MAY over must, but only barely. I thought Paul H. suggested MAY? Anyway, MAY covers the corner cases discussed, which is why I only barely prefer it. > >I would note that, presuming KIDNS only affects client behavior when the client can directly verify that the records were validly DNSSEC-signed (is this everybody's assumption?), using a MUST creates a downgrade attack in which a MITM can force PKIX-only validation by simply blocking DNSSEC-validated DNS results. Very good point! And yes to your question from me anyway. > >"If the application receives zero usable certificate associations, it [MUST] process TLS in the normal fashion." > >We want the client to be able to choose to require DNSSEC-validated KIDNS for all requests, if it wishes. Otherwise what we're doing offers no greater security than the status quo. I agree. > >On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: >> Thank you for being explicit! >> >> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >>> Having now caught up with the many recent messages, I'd also >>> be a bit concerned about the impact of: >>> >>>> "If a match between the certificate association(s) and the >>>> server's end entity certificate in TLS is not found, the >>>> TLS client MUST abort the handshake with an "access_denied" error." >>> >>> The concerns I have about it would include: >>> >>> - I'm not really sure if that same rule would be appropriate >>> for all applications that use TLS, nor for all deployments >>> of each protocol using TLS - basically the policy slippery >>> slope PHB is raising (from time to time:-) >> >> OK, maybe try being more explicit. For example, if this document was in fact an update to TLS, would you have the same concern? Or, if you want a SHOULD rather than a MUST, what would the specific exceptions be (or are you asking for a typical IETF mushy SHOULD)? > >I don't know what Stephen Farrell is arguing for, but I'm arguing for an even more mushy MAY ;) > >However, this is a feature because it gives the clients more options... including the option to improve upon the status quo of PKIX security even in the presence of a MITM (our assumed threat model). It does so without forcing all clients to do this on day one, an impractical requirement. > >On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: >> "If the application receives zero usable certificate associations, it process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error." >> >> I suggest: >> >> "If the application receives zero usable certificate associations, it MAY process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MAY abort the handshake with an "access_denied" error." > > >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 Network Eng. SR. Eng. Network data security ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422813A6A20 for ; Sat, 30 Oct 2010 09:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIBI+-s6c-6e for ; Sat, 30 Oct 2010 09:19:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9D8523A6A1B for ; Sat, 30 Oct 2010 09:19:39 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id o9UGLaK1000529 for ; Sat, 30 Oct 2010 09:21:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288455696; bh=4ma5g4RViE/jpprxSdZDNcCoNFc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=fGvVnTziCZPPaEO+35YrNxZoiAOf85QmXF4M+b658yI15jUbudBZA7FTvzCF9xnZx E66cOLKn64V4jmtRfhkLw== Received: from pwi7 (pwi7.prod.google.com [10.241.219.7]) by wpaz9.hot.corp.google.com with ESMTP id o9UGLZ3q032187 for ; Sat, 30 Oct 2010 09:21:35 -0700 Received: by pwi7 with SMTP id 7so985404pwi.16 for ; Sat, 30 Oct 2010 09:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J5G66bVjNdiGRoSigQFG7U9PsGfebOZr06H7t5bJvyE=; b=khvj9MOtZrkAHNl6uKYEMeHfwahI1Jdty+O4stFmT0lHjWZ5cDF0zW+rPCrNY5CmBV 6fPAbiKKuqk85RmlyvTg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wCuubseizjAKJIhuRgsqK+w1UiQM7cKcVIL4wKH+EMu/1tdqgPUVAuSt65ZVBUjXdv AlVRP4HIoGGtbdq3VO5A== MIME-Version: 1.0 Received: by 10.142.204.7 with SMTP id b7mr2529994wfg.304.1288455694767; Sat, 30 Oct 2010 09:21:34 -0700 (PDT) Received: by 10.142.13.17 with HTTP; Sat, 30 Oct 2010 09:21:34 -0700 (PDT) In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> Date: Sat, 30 Oct 2010 17:21:34 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 16:19:41 -0000 On 30 October 2010 16:28, Phillip Hallam-Baker wrote: > Lets think about 'client makes a choice' > > What it sounds like to me is that people are suggesting that it is up to = the > client to decide what semantics that the domain name holder intended when > they published the record. > That cannot possibly work. > The publisher of the record has to have sole control of what the semantic= s > of the record are. > The only role that the client can play is to choose to respect those > semantics or not. Exactly, though it could also be that the semantics even if respected give the client choice about how to react. > We cannot address this 'Phill wants one thing', 'others want another' by > deciding that client can interpret the same set of bits in different ways= . > We have to have different bits for the two purposes. > > I want to have a clean separation because the only way I can see support = for > draft-hoffman being feasible is if either the site operates its own PKI a= nd > DNS or the CA operates both the DNS and the certs for the site. > I know what everyone here (myself included) would prefer the first. I wou= ld > much rather be teaching people how to run their DNS CA infrastructure at > $800 per person per day through my private consulting business or selling > them training videos. But most people just want this to be something they > just sign a cheque for and forget. > > On Sat, Oct 30, 2010 at 11:05 AM, Steve Schultze wrot= e: >> >> Ben, I'm porting your comment below into this thread for the sake of >> subject-line clarity (none of this is WG-formation specific, I believe). >> >> On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: >> > Paul wants client policy to decide whether to trust PKIX, DNSSEC or >> > some mixture of the two. This seems not only reasonable, but >> > unavoidable: clients will implement what suits them, and we are in no >> > position to change that. >> > >> > Phillip wants the domain in question to be able to state its >> > intentions w.r.t. the policy clients should use. This seems not >> > unreasonable, also. Clients can choose to follow this or not. >> >> What effect does this have on the MUST vs. MAY suggestions I made to the >> draft-hoffman-keys-linkage-from-dns-03 text? =A0I believe that what you = are >> saying is that the spec should leave it open to the client how to react = to >> different validation outcome permutations from PKIX and DNSSEC-secured >> KIDNS. =A0In that case, the two excerpts I quoted should be MAY, as I >> suggested. =A0This also means that I disagree with Paul, who thinks that= MUST >> should be used. >> >> I would note that, presuming KIDNS only affects client behavior when the >> client can directly verify that the records were validly DNSSEC-signed (= is >> this everybody's assumption?), using a MUST creates a downgrade attack i= n >> which a MITM can force PKIX-only validation by simply blocking >> DNSSEC-validated DNS results. >> >> "If the application receives zero usable certificate associations, it >> [MUST] process TLS in the normal fashion." >> >> We want the client to be able to choose to require DNSSEC-validated KIDN= S >> for all requests, if it wishes. =A0Otherwise what we're doing offers no >> greater security than the status quo. >> >> On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: >> > Thank you for being explicit! >> > >> > At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >> >> Having now caught up with the many recent messages, I'd also >> >> be a bit concerned about the impact of: >> >> >> >>> "If a match between the certificate association(s) and the >> >>> server's end entity certificate in TLS is not found, the >> >>> TLS client MUST abort the handshake with an "access_denied" error." >> >> >> >> The concerns I have about it would include: >> >> >> >> - I'm not really sure if that same rule would be appropriate >> >> for all applications that use TLS, nor for all deployments >> >> of each protocol using TLS - basically the policy slippery >> >> slope PHB is raising (from time to time:-) >> > >> > OK, maybe try being more explicit. For example, if this document was i= n >> > fact an update to TLS, would you have the same concern? Or, if you wan= t a >> > SHOULD rather than a MUST, what would the specific exceptions be (or a= re you >> > asking for a typical IETF mushy SHOULD)? >> >> I don't know what Stephen Farrell is arguing for, but I'm arguing for an >> even more mushy MAY ;) >> >> However, this is a feature because it gives the clients more options... >> including the option to improve upon the status quo of PKIX security eve= n in >> the presence of a MITM (our assumed threat model). =A0It does so without >> forcing all clients to do this on day one, an impractical requirement. >> >> On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: >> > "If the application receives zero usable certificate associations, it >> > process TLS in the normal fashion." >> > "If a match between the certificate association(s) and the server's en= d >> > entity certificate in TLS is not found, the TLS client MUST abort the >> > handshake with an "access_denied" error." >> > >> > I suggest: >> > >> > "If the application receives zero usable certificate associations, it >> > MAY process TLS in the normal fashion." >> > "If a match between the certificate association(s) and the server's en= d >> > entity certificate in TLS is not found, the TLS client MAY abort the >> > handshake with an "access_denied" error." >> >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2593A6949 for ; Sat, 30 Oct 2010 09:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yav0Hb4VpF+8 for ; Sat, 30 Oct 2010 09:18:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DD1843A63D3 for ; Sat, 30 Oct 2010 09:18:02 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id o9UGJxBE010227 for ; Sat, 30 Oct 2010 09:19:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288455599; bh=LPO3zXFe1OpCAS4XfL0iCvgqKOY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=xq4gn/h5UbIpnUM3BgIZD3pXCqLH7jtmda8PK2DXIAdpoQWg/MLC8e2HMAiff0+PY SxdDhMzBFL3c1kx++lrIg== Received: from pva4 (pva4.prod.google.com [10.241.209.4]) by kpbe17.cbf.corp.google.com with ESMTP id o9UGJwUo014902 for ; Sat, 30 Oct 2010 09:19:58 -0700 Received: by pva4 with SMTP id 4so280487pva.20 for ; Sat, 30 Oct 2010 09:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UokOFSipXOPLwUoxvnyQYvvovormwFVuyltDP8qplL8=; b=YTomrN+0ujFW6hYkYK0a9bpuhPoe4Y2RF7bhT5vUseQ05yejFzS7soI0x1hr+QsZTc zCn+Z3J19ndkZwYLSfgQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hagBJkFmFTPoFsvbW8GSo1TkeEg1Yd2KUEntgBDEGVe4AsLv2JI7pHiRxzbffOQ1OF Rz7UPESviqn5dG5sMzZw== MIME-Version: 1.0 Received: by 10.142.134.15 with SMTP id h15mr2177384wfd.397.1288455597724; Sat, 30 Oct 2010 09:19:57 -0700 (PDT) Received: by 10.142.13.17 with HTTP; Sat, 30 Oct 2010 09:19:57 -0700 (PDT) In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> Date: Sat, 30 Oct 2010 17:19:57 +0100 Message-ID: From: Ben Laurie To: Steve Schultze Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 16:18:05 -0000 On 30 October 2010 16:05, Steve Schultze wrote: > Ben, I'm porting your comment below into this thread for the sake of subj= ect-line clarity (none of this is WG-formation specific, I believe). > > On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: >> Paul wants client policy to decide whether to trust PKIX, DNSSEC or >> some mixture of the two. This seems not only reasonable, but >> unavoidable: clients will implement what suits them, and we are in no >> position to change that. >> >> Phillip wants the domain in question to be able to state its >> intentions w.r.t. the policy clients should use. This seems not >> unreasonable, also. Clients can choose to follow this or not. > > What effect does this have on the MUST vs. MAY suggestions I made to the = draft-hoffman-keys-linkage-from-dns-03 text? I have temporarily given up on trying to stay up-to-date with the various I-Ds until the dust on chartering settles so I can't currently answer that. > =A0I believe that what you are saying is that the spec should leave it op= en to the client how to react to different validation outcome permutations = from PKIX and DNSSEC-secured KIDNS. =A0In that case, the two excerpts I quo= ted should be MAY, as I suggested. =A0This also means that I disagree with = Paul, who thinks that MUST should be used. > > I would note that, presuming KIDNS only affects client behavior when the = client can directly verify that the records were validly DNSSEC-signed (is = this everybody's assumption?), using a MUST creates a downgrade attack in w= hich a MITM can force PKIX-only validation by simply blocking DNSSEC-valida= ted DNS results. Surely not - in this case the client sees DNS failures, rather than a lack of results and so should squawk about that problem. > > "If the application receives zero usable certificate associations, it [MU= ST] process TLS in the normal fashion." > > We want the client to be able to choose to require DNSSEC-validated KIDNS= for all requests, if it wishes. =A0Otherwise what we're doing offers no gr= eater security than the status quo. > > On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: >> Thank you for being explicit! >> >> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >>> Having now caught up with the many recent messages, I'd also >>> be a bit concerned about the impact of: >>> >>>> "If a match between the certificate association(s) and the >>>> server's end entity certificate in TLS is not found, the >>>> TLS client MUST abort the handshake with an "access_denied" error." >>> >>> The concerns I have about it would include: >>> >>> - I'm not really sure if that same rule would be appropriate >>> for all applications that use TLS, nor for all deployments >>> of each protocol using TLS - basically the policy slippery >>> slope PHB is raising (from time to time:-) >> >> OK, maybe try being more explicit. For example, if this document was in = fact an update to TLS, would you have the same concern? Or, if you want a S= HOULD rather than a MUST, what would the specific exceptions be (or are you= asking for a typical IETF mushy SHOULD)? > > I don't know what Stephen Farrell is arguing for, but I'm arguing for an = even more mushy MAY ;) > > However, this is a feature because it gives the clients more options... i= ncluding the option to improve upon the status quo of PKIX security even in= the presence of a MITM (our assumed threat model). =A0It does so without f= orcing all clients to do this on day one, an impractical requirement. > > On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: >> "If the application receives zero usable certificate associations, it pr= ocess TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's end = entity certificate in TLS is not found, the TLS client MUST abort the hands= hake with an "access_denied" error." >> >> I suggest: >> >> "If the application receives zero usable certificate associations, it MA= Y process TLS in the normal fashion." >> "If a match between the certificate association(s) and the server's end = entity certificate in TLS is not found, the TLS client MAY abort the handsh= ake with an "access_denied" error." > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2714A3A6A05 for ; Sat, 30 Oct 2010 08:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kW+qh+WE4ro for ; Sat, 30 Oct 2010 08:40:35 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 208A13A684D for ; Sat, 30 Oct 2010 08:40:35 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o9UFgVj0018441 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Oct 2010 11:42:31 -0400 Received: from new-host-3.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9UFgUS8024743 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Oct 2010 11:42:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Schultze In-Reply-To: Date: Sat, 30 Oct 2010 11:42:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <64F66FE4-CBAA-47DA-8A8E-D791BA730BE0@Princeton.EDU> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6151 signatures=648712 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010300075 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 15:40:36 -0000 On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote: > What it sounds like to me is that people are suggesting that it is up = to the client to decide what semantics that the domain name holder = intended when they published the record. What is being suggested is that the domain name holder has the semantics = to say, "this is the fingerprint of the certificate I will use."=20 > The publisher of the record has to have sole control of what the = semantics of the record are. And they do, presuming they are articulating what I stated above. > The only role that the client can play is to choose to respect those = semantics or not. And in my version this is the case. The client decides whether a = validated KIDNS record is sufficient or necessary. (There may be other things that the domain holder can state in DNS, = along the lines of what you have suggested elsewhere, which I think are = equally subject to client discretion in the same fashion.) This is parallel to what we have today with the PKIX/CA model. Servers = present certs which the client decides to trust or not, based on its = root cert store, customized trust bits, and user override. This is a = feature because it allows clients with different trust preferences to = operate in a way that respects those.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89593A69FB for ; Sat, 30 Oct 2010 08:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLRPVjz7VvSx for ; Sat, 30 Oct 2010 08:27:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 036FD3A684D for ; Sat, 30 Oct 2010 08:27:00 -0700 (PDT) Received: by iwn40 with SMTP id 40so5269067iwn.31 for ; Sat, 30 Oct 2010 08:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kr1cw3hV8oDB+p24VJaIuNdQX9TXcrdzeXPPMCv1nPw=; b=b/4AtJwbmjKdRJSnvjzRmZ0GcQKX4IAAzTlVuiy/iCKm9cvyAcDVU15aZHRCWokEIK z2s4hTGT8Nrgo6DMQQ9fx0tRC2/iPLp9enpxztr2Gu2vf4rn1dQi+zh4nMCabZ8uPvAY LuMd3HqLnnY5bNyw/05C5NKzMJMM6rlRkMW8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kj4jhHZu1aH3qhxL0Gp6/tc1FjUbDCuODLxMtif6O/p6ZWNC12VjTFqfxEyVHkZY7R YYuL4k1MO5IEXE1Hzhanb5ht6YQjqLoHC+kNG5rdrezx8+HOksF6/s00wIa8lEOYNz0T BOtvw2p2Nv5RlFtW1m0RuGJNMJOdDmze6ae1M= MIME-Version: 1.0 Received: by 10.42.175.135 with SMTP id ba7mr10221904icb.420.1288452537725; Sat, 30 Oct 2010 08:28:57 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Sat, 30 Oct 2010 08:28:57 -0700 (PDT) In-Reply-To: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> Date: Sat, 30 Oct 2010 11:28:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Steve Schultze Content-Type: multipart/alternative; boundary=90e6ba6e8128d233a20493d73b13 Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 15:27:04 -0000 --90e6ba6e8128d233a20493d73b13 Content-Type: text/plain; charset=ISO-8859-1 Lets think about 'client makes a choice' What it sounds like to me is that people are suggesting that it is up to the client to decide what semantics that the domain name holder intended when they published the record. That cannot possibly work. The publisher of the record has to have sole control of what the semantics of the record are. The only role that the client can play is to choose to respect those semantics or not. We cannot address this 'Phill wants one thing', 'others want another' by deciding that client can interpret the same set of bits in different ways. We have to have different bits for the two purposes. I want to have a clean separation because the only way I can see support for draft-hoffman being feasible is if either the site operates its own PKI and DNS or the CA operates both the DNS and the certs for the site. I know what everyone here (myself included) would prefer the first. I would much rather be teaching people how to run their DNS CA infrastructure at $800 per person per day through my private consulting business or selling them training videos. But most people just want this to be something they just sign a cheque for and forget. On Sat, Oct 30, 2010 at 11:05 AM, Steve Schultze wrote: > Ben, I'm porting your comment below into this thread for the sake of > subject-line clarity (none of this is WG-formation specific, I believe). > > On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: > > Paul wants client policy to decide whether to trust PKIX, DNSSEC or > > some mixture of the two. This seems not only reasonable, but > > unavoidable: clients will implement what suits them, and we are in no > > position to change that. > > > > Phillip wants the domain in question to be able to state its > > intentions w.r.t. the policy clients should use. This seems not > > unreasonable, also. Clients can choose to follow this or not. > > What effect does this have on the MUST vs. MAY suggestions I made to the > draft-hoffman-keys-linkage-from-dns-03 text? I believe that what you are > saying is that the spec should leave it open to the client how to react to > different validation outcome permutations from PKIX and DNSSEC-secured > KIDNS. In that case, the two excerpts I quoted should be MAY, as I > suggested. This also means that I disagree with Paul, who thinks that MUST > should be used. > > I would note that, presuming KIDNS only affects client behavior when the > client can directly verify that the records were validly DNSSEC-signed (is > this everybody's assumption?), using a MUST creates a downgrade attack in > which a MITM can force PKIX-only validation by simply blocking > DNSSEC-validated DNS results. > > "If the application receives zero usable certificate associations, it > [MUST] process TLS in the normal fashion." > > We want the client to be able to choose to require DNSSEC-validated KIDNS > for all requests, if it wishes. Otherwise what we're doing offers no > greater security than the status quo. > > On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: > > Thank you for being explicit! > > > > At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: > >> Having now caught up with the many recent messages, I'd also > >> be a bit concerned about the impact of: > >> > >>> "If a match between the certificate association(s) and the > >>> server's end entity certificate in TLS is not found, the > >>> TLS client MUST abort the handshake with an "access_denied" error." > >> > >> The concerns I have about it would include: > >> > >> - I'm not really sure if that same rule would be appropriate > >> for all applications that use TLS, nor for all deployments > >> of each protocol using TLS - basically the policy slippery > >> slope PHB is raising (from time to time:-) > > > > OK, maybe try being more explicit. For example, if this document was in > fact an update to TLS, would you have the same concern? Or, if you want a > SHOULD rather than a MUST, what would the specific exceptions be (or are you > asking for a typical IETF mushy SHOULD)? > > I don't know what Stephen Farrell is arguing for, but I'm arguing for an > even more mushy MAY ;) > > However, this is a feature because it gives the clients more options... > including the option to improve upon the status quo of PKIX security even in > the presence of a MITM (our assumed threat model). It does so without > forcing all clients to do this on day one, an impractical requirement. > > On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: > > "If the application receives zero usable certificate associations, it > process TLS in the normal fashion." > > "If a match between the certificate association(s) and the server's end > entity certificate in TLS is not found, the TLS client MUST abort the > handshake with an "access_denied" error." > > > > I suggest: > > > > "If the application receives zero usable certificate associations, it MAY > process TLS in the normal fashion." > > "If a match between the certificate association(s) and the server's end > entity certificate in TLS is not found, the TLS client MAY abort the > handshake with an "access_denied" error." > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --90e6ba6e8128d233a20493d73b13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lets think about 'client makes a choice'=A0


=
What it sounds like to me is that people are suggesting that it = is up to the client to decide what semantics that the domain name holder in= tended when they published the record.

That cannot possibly work.

The= publisher of the record has to have sole control of what the semantics of = the record are.

The only role that the client can = play is to choose to respect those semantics or not.


We cannot address this 'Phill wants = one thing', 'others want another' by deciding that client can i= nterpret the same set of bits in different ways.

We have to have different bits for the two purposes.


I want to have a clean separation because the only way I = can see support for draft-hoffman being feasible is if either the site oper= ates its own PKI and DNS or the CA operates both the DNS and the certs for = the site.

I know what everyone here (myself included) would prefe= r the first. I would much rather be teaching people how to run their DNS CA= infrastructure at $800 per person per day through my private consulting bu= siness or selling them training videos. But most people just want this to b= e something they just sign a cheque for and forget.


On Sat, Oct 30, 2010 at 11:05 AM, S= teve Schultze <sj= s@princeton.edu> wrote:
Ben, I'm porting your comment below into this thread for the sake of su= bject-line clarity (none of this is WG-formation specific, I believe).

On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
> Paul wants client policy to decide whether to trust PKIX, DNSSEC or > some mixture of the two. This seems not only reasonable, but
> unavoidable: clients will implement what suits them, and we are in no<= br> > position to change that.
>
> Phillip wants the domain in question to be able to state its
> intentions w.r.t. the policy clients should use. This seems not
> unreasonable, also. Clients can choose to follow this or not.

What effect does this have on the MUST vs. MAY suggestions I made to the dr= aft-hoffman-keys-linkage-from-dns-03 text? =A0I believe that what you are s= aying is that the spec should leave it open to the client how to react to d= ifferent validation outcome permutations from PKIX and DNSSEC-secured KIDNS= . =A0In that case, the two excerpts I quoted should be MAY, as I suggested.= =A0This also means that I disagree with Paul, who thinks that MUST should = be used.

I would note that, presuming KIDNS only affects client behavior when the cl= ient can directly verify that the records were validly DNSSEC-signed (is th= is everybody's assumption?), using a MUST creates a downgrade attack in= which a MITM can force PKIX-only validation by simply blocking DNSSEC-vali= dated DNS results.

"If the application receives zero usable certificate associations, it = [MUST] process TLS in the normal fashion."

We want the client to be able to choose to require DNSSEC-validated KIDNS f= or all requests, if it wishes. =A0Otherwise what we're doing offers no = greater security than the status quo.

On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
> Thank you for being explicit!
>
> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>> Having now caught up with the many recent messages, I'd also >> be a bit concerned about the impact of:
>>
>>> "If a match between the certificate association(s) and th= e
>>> server's end entity certificate in TLS is not found, the >>> TLS client MUST abort the handshake with an "access_denie= d" error."
>>
>> The concerns I have about it would include:
>>
>> - I'm not really sure if that same rule would be appropriate >> for all applications that use TLS, nor for all deployments
>> of each protocol using TLS - basically the policy slippery
>> slope PHB is raising (from time to time:-)
>
> OK, maybe try being more explicit. For example, if this document was i= n fact an update to TLS, would you have the same concern? Or, if you want a= SHOULD rather than a MUST, what would the specific exceptions be (or are y= ou asking for a typical IETF mushy SHOULD)?

I don't know what Stephen Farrell is arguing for, but I'm arg= uing for an even more mushy MAY ;)

However, this is a feature because it gives the clients more options... inc= luding the option to improve upon the status quo of PKIX security even in t= he presence of a MITM (our assumed threat model). =A0It does so without for= cing all clients to do this on day one, an impractical requirement.

On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
> "If the application receives zero usable certificate associations= , it process TLS in the normal fashion."
> "If a match between the certificate assoc= iation(s) and the server's end entity certificate in TLS is not found, = the TLS client MUST abort the handshake with an "access_denied" e= rror."
>
> I suggest:
>
> "If the application receives zero usable certificate associations= , it MAY process TLS in the normal fashion."
> "If a match between the certificate association(s) and the = server's end entity certificate in TLS is not found, the TLS client MAY= abort the handshake with an "access_denied" error."


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



--
Website: http://hallambaker.com/

--90e6ba6e8128d233a20493d73b13-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECCA3A69EB for ; Sat, 30 Oct 2010 08:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imp4bbLrrFl4 for ; Sat, 30 Oct 2010 08:03:55 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id B960A3A69D6 for ; Sat, 30 Oct 2010 08:03:55 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o9UF5qBG032635 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 30 Oct 2010 11:05:52 -0400 Received: from new-host-3.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9UF5pKO008542 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Oct 2010 11:05:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Schultze In-Reply-To: Date: Sat, 30 Oct 2010 11:05:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6151 signatures=648712 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010300066 Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 15:03:57 -0000 Ben, I'm porting your comment below into this thread for the sake of = subject-line clarity (none of this is WG-formation specific, I believe). On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote: > Paul wants client policy to decide whether to trust PKIX, DNSSEC or > some mixture of the two. This seems not only reasonable, but > unavoidable: clients will implement what suits them, and we are in no > position to change that. >=20 > Phillip wants the domain in question to be able to state its > intentions w.r.t. the policy clients should use. This seems not > unreasonable, also. Clients can choose to follow this or not. What effect does this have on the MUST vs. MAY suggestions I made to the = draft-hoffman-keys-linkage-from-dns-03 text? I believe that what you = are saying is that the spec should leave it open to the client how to = react to different validation outcome permutations from PKIX and = DNSSEC-secured KIDNS. In that case, the two excerpts I quoted should be = MAY, as I suggested. This also means that I disagree with Paul, who = thinks that MUST should be used. I would note that, presuming KIDNS only affects client behavior when the = client can directly verify that the records were validly DNSSEC-signed = (is this everybody's assumption?), using a MUST creates a downgrade = attack in which a MITM can force PKIX-only validation by simply blocking = DNSSEC-validated DNS results. "If the application receives zero usable certificate associations, it = [MUST] process TLS in the normal fashion." We want the client to be able to choose to require DNSSEC-validated = KIDNS for all requests, if it wishes. Otherwise what we're doing offers = no greater security than the status quo. On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote: > Thank you for being explicit! >=20 > At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >> Having now caught up with the many recent messages, I'd also >> be a bit concerned about the impact of: >>=20 >>> "If a match between the certificate association(s) and the >>> server's end entity certificate in TLS is not found, the >>> TLS client MUST abort the handshake with an "access_denied" error." >>=20 >> The concerns I have about it would include: >>=20 >> - I'm not really sure if that same rule would be appropriate >> for all applications that use TLS, nor for all deployments >> of each protocol using TLS - basically the policy slippery >> slope PHB is raising (from time to time:-) >=20 > OK, maybe try being more explicit. For example, if this document was = in fact an update to TLS, would you have the same concern? Or, if you = want a SHOULD rather than a MUST, what would the specific exceptions be = (or are you asking for a typical IETF mushy SHOULD)? I don't know what Stephen Farrell is arguing for, but I'm arguing for an = even more mushy MAY ;) However, this is a feature because it gives the clients more options... = including the option to improve upon the status quo of PKIX security = even in the presence of a MITM (our assumed threat model). It does so = without forcing all clients to do this on day one, an impractical = requirement. On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote: > "If the application receives zero usable certificate associations, it = process TLS in the normal fashion." > "If a match between the certificate association(s) and the server's = end entity certificate in TLS is not found, the TLS client MUST abort = the handshake with an "access_denied" error." >=20 > I suggest: >=20 > "If the application receives zero usable certificate associations, it = MAY process TLS in the normal fashion." > "If a match between the certificate association(s) and the server's = end entity certificate in TLS is not found, the TLS client MAY abort the = handshake with an "access_denied" error." Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769E33A67EC for ; Fri, 29 Oct 2010 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z5-XNTp1h81 for ; Fri, 29 Oct 2010 09:22:13 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 069023A67DB for ; Fri, 29 Oct 2010 09:22:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ZbltFkSXe2vBqy90bS3iOUEFOPLfD7z/bOYt6Vrn6y1zTzCA0CPHZuocjoISrabs; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.31] (helo=elwamui-chisos.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PBrkM-000133-H6; Fri, 29 Oct 2010 12:24:06 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 29 Oct 2010 11:59:23 -0400 Message-ID: <16640038.1288367963750.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Date: Fri, 29 Oct 2010 10:59:23 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Phillip Hallam-Baker , Andrew Sullivan Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688d1ad76546901eeecdd9fc9918297fb6a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.31 Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:22:14 -0000 Phillip and all,


-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 29, 2010 9:12 AM
To: Andrew Sullivan
Cc: keyassure@ietf.org
Subject: Re: [keyassure] WG Re= view: Keys In DNS (kidns)

+1

These are certainly issues, but they are fixable issues. 

One way we can fix them is to build up the same set of capabilities in= DNSSEC as has existed in X.509 from the start. X.509 is expressly intended= to provide non repudiable, archival keys. A DS record is not.
 
agreed here.

A better way is to lightly graft on parts of the X.509 structure that = provide useful enhancements onto DNSSEC.\
 
  not only useful, but perhaps advisable or even necessary. = X.509 IMO has long needed more indepth
review.
PKI is the interface between the real world and the online world. As a= result a lot of the reasons something is necessary get into the type of is= sue that most engineers simply do not want to think about.
 
Amen!  However seems that we are going to have to at some limited= level or to some limited degree get
more involved in the issues regarding this.

I can address Andrew's issue fairly cleanly by publishing an X.509v3 c= ertificate for the KSK at the apex of each zone. But giving the full explan= ation of the reasons why you would want to do it that way is going to invol= ve a lot of business related issues that a lot of people don't have patienc= e for.
 
Agreed.


That is not how I would address those issues if I was building complet= ely from scratch. Given an unrestricted choice I would probably use somethi= ng with angle brackets like SAML assertions. That is one of the use cases I= was originally commissioned to design the assertion infrast= ructure SAML is based on for.


On Fri, Oct 29, 2010 at 9:34 AM, Andrew Sullivan <= SPAN dir=3Dltr><ajs@= shinkuro.com> wrote:
On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrote:=
> None of these seem to me to be incompatible with each other. So, w= hat
> is being discussed?

You've said this much more cle= arly than I've managed to do so far.  I
completely agree.

As= an aside, I will note that there has been a similar tension in the
DNSS= EC community around trust anchors.  Some operators feel that the
on= ly things that others may use for trust operations on their zones
are th= e ones that they are publishing _right now_, and anything else
is danger= ous.  Others want to be able to build a history of trust
anchors so= that it is possible to reconstruct this history and
"replay" RFC5011 ev= ents after some of the affected keys have been
withdrawn.

In both= the dispute about what to do here and in the DNSSEC
trust-history case,= we have what amounts to a disagreement about who
gets to decide the tru= st properties: whether the domain operator (or
site operator or whatever= ) gets to determine what things are valid, or
whether a client can make = choices for itself using the trade-offs it
likes.

My own view is = that the latter is always possible on the Internet, and
therefore I woul= d like to have well-documented ways in which such
trade-offs can be made= intelligently, so that users have a predictable
mechanism.  I full= y understand the argument from the other point of
view, however, but I t= hink it is unrealistic to imagine that, if we
don't provide some mechani= sm for clients to make up their own minds,
that they won't start doing a= ll kinds of strange and wonderful things
on their own.

Best,

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
__= _____________________________________________



--
Website: http://hallambaker.com/

Regards,
Jeffre= y A. Williams
"Obedience of the law is the greatest freedom" -
 =   Abraham Lincoln

"Credit should go with the performance of dut= y and not with what is very
often the accident of glory" - Theodore Roos= evelt

"If the probability be called P; the injury, L; and the burden= , B; liability
depends upon whether B is less than L multiplied by
P:= i.e., whether B is less than PL."
United States v. Carroll Towing = (159 F.2d 169 [2d Cir. 1947]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DUpdated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827



Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832463A69F0 for ; Fri, 29 Oct 2010 07:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4muQ+2uLPfg3 for ; Fri, 29 Oct 2010 07:10:33 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 5AEA43A6946 for ; Fri, 29 Oct 2010 07:10:32 -0700 (PDT) Received: by gxk7 with SMTP id 7so2139256gxk.31 for ; Fri, 29 Oct 2010 07:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nVYOcxIXZEfY3U53pMpWemDsjOgkVHQfJcn6l39f59g=; b=E9gwPF7eUqs7D12qSHv077MOesmxpn/k063CWc2885/TLoTvGM4RKyTnGE10+UsWEk 0hurhD8vWJYEfb5DaN27ebAKZNzl9RXV66QQE+BmCElD/WPrNkk2xlzxoNQTLcMH5Rkw w35ebwhVlmGiVWxkPawnxFQ5C6oRytMYZSr54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SD228hy7c7fFaPympZ0NPCnU+cdbT3koSZCvHH2E+ZKhX3YWevrdwQHVVa+A9H7SGP XvPsplnupz90vs16123q3P77vwyKac8/EpEYr4QxDbKEXRWX8a/AOZeo7pBOozZkRCrs ekKyFii5mGnypshz8vWKaRVYv7c7+yAp1uY50= MIME-Version: 1.0 Received: by 10.42.76.145 with SMTP id e17mr3073778ick.62.1288361546521; Fri, 29 Oct 2010 07:12:26 -0700 (PDT) Received: by 10.42.77.4 with HTTP; Fri, 29 Oct 2010 07:12:26 -0700 (PDT) In-Reply-To: <20101029133422.GS79716@shinkuro.com> References: <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <20101029133422.GS79716@shinkuro.com> Date: Fri, 29 Oct 2010 10:12:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=90e6ba2124fd529b2f0493c20ce1 Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:10:40 -0000 --90e6ba2124fd529b2f0493c20ce1 Content-Type: text/plain; charset=ISO-8859-1 +1 These are certainly issues, but they are fixable issues. One way we can fix them is to build up the same set of capabilities in DNSSEC as has existed in X.509 from the start. X.509 is expressly intended to provide non repudiable, archival keys. A DS record is not. A better way is to lightly graft on parts of the X.509 structure that provide useful enhancements onto DNSSEC. PKI is the interface between the real world and the online world. As a result a lot of the reasons something is necessary get into the type of issue that most engineers simply do not want to think about. I can address Andrew's issue fairly cleanly by publishing an X.509v3 certificate for the KSK at the apex of each zone. But giving the full explanation of the reasons why you would want to do it that way is going to involve a lot of business related issues that a lot of people don't have patience for. That is not how I would address those issues if I was building completely from scratch. Given an unrestricted choice I would probably use something with angle brackets like SAML assertions. That is one of the use cases I was originally commissioned to design the assertion infrastructure SAML is based on for. On Fri, Oct 29, 2010 at 9:34 AM, Andrew Sullivan wrote: > On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrote: > > None of these seem to me to be incompatible with each other. So, what > > is being discussed? > > You've said this much more clearly than I've managed to do so far. I > completely agree. > > As an aside, I will note that there has been a similar tension in the > DNSSEC community around trust anchors. Some operators feel that the > only things that others may use for trust operations on their zones > are the ones that they are publishing _right now_, and anything else > is dangerous. Others want to be able to build a history of trust > anchors so that it is possible to reconstruct this history and > "replay" RFC5011 events after some of the affected keys have been > withdrawn. > > In both the dispute about what to do here and in the DNSSEC > trust-history case, we have what amounts to a disagreement about who > gets to decide the trust properties: whether the domain operator (or > site operator or whatever) gets to determine what things are valid, or > whether a client can make choices for itself using the trade-offs it > likes. > > My own view is that the latter is always possible on the Internet, and > therefore I would like to have well-documented ways in which such > trade-offs can be made intelligently, so that users have a predictable > mechanism. I fully understand the argument from the other point of > view, however, but I think it is unrealistic to imagine that, if we > don't provide some mechanism for clients to make up their own minds, > that they won't start doing all kinds of strange and wonderful things > on their own. > > Best, > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --90e6ba2124fd529b2f0493c20ce1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

These are certainly issues, but they are fixable issu= es.=A0

One way we can fix them is to build up the = same set of capabilities in DNSSEC as has existed in X.509 from the start. = X.509 is expressly intended to provide non repudiable, archival keys. A DS = record is not.

A better way is to lightly graft on parts of the X.509 = structure that provide useful enhancements onto DNSSEC.


PKI is the interface between the real world and the on= line world. As a result a lot of the reasons something is necessary get int= o the type of issue that most engineers simply do not want to think about.<= /div>

I can address Andrew's issue fairly cleanly by publ= ishing an X.509v3 certificate for the KSK at the apex of each zone. But giv= ing the full explanation of the reasons why you would want to do it that wa= y is going to involve a lot of business related issues that a lot of people= don't have patience for.


That is not how I would address those is= sues if I was building completely from scratch. Given an unrestricted choic= e I would probably use something with angle brackets like SAML assertions. = That is one of the use cases I was originally=A0commissioned=A0to design th= e assertion=A0infrastructure=A0SAML is based on for.


On Fri, Oct 29, 2010 at = 9:34 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:
On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrot= e:
> None of these seem to me to be incompatible with each other. So, what<= br> > is being discussed?

You've said this much more clearly than I've managed to do so= far. =A0I
completely agree.

As an aside, I will note that there has been a similar tension in the
DNSSEC community around trust anchors. =A0Some operators feel that the
only things that others may use for trust operations on their zones
are the ones that they are publishing _right now_, and anything else
is dangerous. =A0Others want to be able to build a history of trust
anchors so that it is possible to reconstruct this history and
"replay" RFC5011 events after some of the affected keys have been=
withdrawn.

In both the dispute about what to do here and in the DNSSEC
trust-history case, we have what amounts to a disagreement about who
gets to decide the trust properties: whether the domain operator (or
site operator or whatever) gets to determine what things are valid, or
whether a client can make choices for itself using the trade-offs it
likes.

My own view is that the latter is always possible on the Internet, and
therefore I would like to have well-documented ways in which such
trade-offs can be made intelligently, so that users have a predictable
mechanism. =A0I fully understand the argument from the other point of
view, however, but I think it is unrealistic to imagine that, if we
don't provide some mechanism for clients to make up their own minds, that they won't start doing all kinds of strange and wonderful things on their own.

Best,

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________



--
Website: http://hallambaker.com/

--90e6ba2124fd529b2f0493c20ce1-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AB33A6A67; Fri, 29 Oct 2010 06:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7C45AURTwvG; Fri, 29 Oct 2010 06:41:05 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6DEB13A68E3; Fri, 29 Oct 2010 06:41:04 -0700 (PDT) Received: by gya6 with SMTP id 6so2109345gya.31 for ; Fri, 29 Oct 2010 06:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hW2UcZG/nQ/C+ixz7VxHCt5hHRM4PZ0E5242eUwnVUg=; b=hxOIhamdgdja1i9mgt1Sla3VD9Rr+N7O+3mzZv5zxJW+VXknqRg5X45ao5KtyzWZBk dcf8IqvtHUOEypCHgSvxqz0GVLDjcY2kZ029RUOn/OlQlIOy29wGTjGo0eReiWj5NA7L ZClYTROSPmfl+DnBEiqB7mlXqHXlpnIr/Q3z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kHz0avhCqapbEdqeInw1vkGiyM6Am37g1PxM0MPuXQj87uGu2LOImnLtHmoGrpHfhP JXsdctXXgh8pW9x0X6ed7LsdXeNfaAdXHKIz3UX4GU1KwuOt+ENr0BLHtB9a8i87H0YJ ek4A7WRM1cH2am3Wv8i1aRBscTI0x6otnuTA4= MIME-Version: 1.0 Received: by 10.100.242.6 with SMTP id p6mr1690370anh.168.1288359777971; Fri, 29 Oct 2010 06:42:57 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Fri, 29 Oct 2010 06:42:57 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Fri, 29 Oct 2010 09:42:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=0016368e24c4e8afb10493c1a2f0 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:41:08 -0000 --0016368e24c4e8afb10493c1a2f0 Content-Type: text/plain; charset=ISO-8859-1 +1 In addition to wanting to separate policy from key authentication for architectural reasons, I want to at least have the option of expressing the trust policy in terms of X.509 infrastructure. One reason for this approach is that we have a lot of infrastructure for managing X.509 certs already, both commercial and open source. For the enterprise that is looking to manage large numbers of keys it is going to be much easier for them to add rules to the DNS that state that all their certs are issued under an X.509 root than to deploy a new system that interacts with the DNS on every cert issue. A second reason is that the X.509 approach has 20 years of history and there is a lot of prior art we can point to. On Fri, Oct 29, 2010 at 8:33 AM, Ben Laurie wrote: > On 28 October 2010 01:12, Paul Wouters wrote: > > On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote: > > > >> I think that this represents a superficial analysis of the problem. > > > > No Philip, you keep trying to drag in the cat's meow. I've already > ignored > > some claims you made about what I said. We understand you value PKIX. So > > we do. We value DNSSEC. So should you. > > > >> This is a rather strange definition of 'separating' DNSSEC key assurance > >> from PKIX. What is being proposed here is that the DNSSEC which > >> is not yet deployed is to be promoted above PKIX which we have been > >> working on and with for twenty plus years. > > > > It's your fear this is "above PKIX". If your PKIX system works well > > enough, and is better then DNSSEC, why do you have this fear? You are > > the one who keeps trying to mix DNSSEC and PKIX. I've made statements > > I favour to keep these two separate, so they do not HAVE to interfere > > with one another. I never said "above". I said "separate" and "according > > to client policy". I'm bending over backwards to not interfere with > > any current PKIX deployment, and requested the same in return (eg I'm > > opposed to a CAA record). > > > > I would be interestd in what others who have not expressed themselves > > have to say on these matters, but I believe my views (and yours) on this > > topic have been stated clearly. Unless the IESG asks me for more input, > > I'll refrain from further adding to this discussion. > > I am with David Conrad on the DoS attack: I don't understand what > useful this seemingly endless discussion is actually _about_. > > Paul wants client policy to decide whether to trust PKIX, DNSSEC or > some mixture of the two. This seems not only reasonable, but > unavoidable: clients will implement what suits them, and we are in no > position to change that. > > Phillip wants the domain in question to be able to state its > intentions w.r.t. the policy clients should use. This seems not > unreasonable, also. Clients can choose to follow this or not. > > He also wants to separate protocols so policy can apply to > domain+protocol, not merely domain. This seems like an obvious > requirement to me. > > None of these seem to me to be incompatible with each other. So, what > is being discussed? > > > > > Paul > > _______________________________________________ > > keyassure mailing list > > keyassure@ietf.org > > https://www.ietf.org/mailman/listinfo/keyassure > > > -- Website: http://hallambaker.com/ --0016368e24c4e8afb10493c1a2f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1=A0

In addition to wanting to separate policy from key= authentication for architectural reasons, I want to at least have the opti= on of expressing the trust policy in terms of X.509 infrastructure.

One reason for this approach is that we have a lot of infras= tructure for managing X.509 certs already, both commercial and open source.= For the enterprise that is looking to manage large numbers of keys it is g= oing to be much easier for them to add rules to the DNS that state that all= their certs are issued under an X.509 root than to deploy a new system tha= t interacts with the DNS on every cert issue.

A second reason is that the X.509 approach has 20 years= of history and there is a lot of prior art we can point to.

=
On Fri, Oct 29, 2010 at 8:33 AM, Ben Laurie = <benl@google.com> wrote:
On 28 Oct= ober 2010 01:12, Paul Wouters <pau= l@xelerance.com> wrote:
> On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:
>
>> I think that this represents a superficial analysis of the problem= .
>
> No Philip, you keep trying to drag in the cat's meow. I've alr= eady ignored
> some claims you made about what I said. We understand you value PKIX. = So
> we do. We value DNSSEC. So should you.
>
>> This is a rather strange definition of 'separating' DNSSEC= key assurance
>> from PKIX. What is being proposed here is that the DNSSEC which >> is not yet deployed is to be promoted above PKIX which we have bee= n
>> working on and with for twenty plus years.
>
> It's your fear this is "above PKIX". If your PKIX system= works well
> enough, and is better then DNSSEC, why do you have this fear? You are<= br> > the one who keeps trying to mix DNSSEC and PKIX. I've made stateme= nts
> I favour to keep these two separate, so they do not HAVE to interfere<= br> > with one another. I never said "above". I said "separat= e" and "according
> to client policy". I'm bending over backwards to not interfer= e with
> any current PKIX deployment, and requested the same in return (eg I= 9;m
> opposed to a CAA record).
>
> I would be interestd in what others who have not expressed themselves<= br> > have to say on these matters, but I believe my views (and yours) on th= is
> topic have been stated clearly. Unless the IESG asks me for more input= ,
> I'll refrain from further adding to this discussion.

I am with David Conrad on the DoS attack: I don't understan= d what
useful this seemingly endless discussion is actually _about_.

Paul wants client policy to decide whether to trust PKIX, DNSSEC or
some mixture of the two. This seems not only reasonable, but
unavoidable: clients will implement what suits them, and we are in no
position to change that.

Phillip wants the domain in question to be able to state its
intentions w.r.t. the policy clients should use. This seems not
unreasonable, also. Clients can choose to follow this or not.

He also wants to separate protocols so policy can apply to
domain+protocol, not merely domain. This seems like an obvious
requirement to me.

None of these seem to me to be incompatible with each other. So, what
is being discussed?

>
> Paul
> ____________________________________= ___________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>



--
Website: http://hallambaker.com/

--0016368e24c4e8afb10493c1a2f0-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA253A6A51 for ; Fri, 29 Oct 2010 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjTOIP2fJT7u for ; Fri, 29 Oct 2010 06:32:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B04183A6A44 for ; Fri, 29 Oct 2010 06:32:37 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 4F0061ECB408 for ; Fri, 29 Oct 2010 13:34:25 +0000 (UTC) Date: Fri, 29 Oct 2010 09:34:22 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20101029133422.GS79716@shinkuro.com> References: <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 13:32:50 -0000 On Fri, Oct 29, 2010 at 01:33:47PM +0100, Ben Laurie wrote: > None of these seem to me to be incompatible with each other. So, what > is being discussed? You've said this much more clearly than I've managed to do so far. I completely agree. As an aside, I will note that there has been a similar tension in the DNSSEC community around trust anchors. Some operators feel that the only things that others may use for trust operations on their zones are the ones that they are publishing _right now_, and anything else is dangerous. Others want to be able to build a history of trust anchors so that it is possible to reconstruct this history and "replay" RFC5011 events after some of the affected keys have been withdrawn. In both the dispute about what to do here and in the DNSSEC trust-history case, we have what amounts to a disagreement about who gets to decide the trust properties: whether the domain operator (or site operator or whatever) gets to determine what things are valid, or whether a client can make choices for itself using the trade-offs it likes. My own view is that the latter is always possible on the Internet, and therefore I would like to have well-documented ways in which such trade-offs can be made intelligently, so that users have a predictable mechanism. I fully understand the argument from the other point of view, however, but I think it is unrealistic to imagine that, if we don't provide some mechanism for clients to make up their own minds, that they won't start doing all kinds of strange and wonderful things on their own. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418673A69A4 for ; Fri, 29 Oct 2010 05:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.783 X-Spam-Level: X-Spam-Status: No, score=-107.783 tagged_above=-999 required=5 tests=[AWL=2.194, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu7cOLIA9XN8 for ; Fri, 29 Oct 2010 05:32:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1CE343A68E3 for ; Fri, 29 Oct 2010 05:32:03 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o9TCXtPa013073 for ; Fri, 29 Oct 2010 05:33:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288355638; bh=7Wt7pSl2OwbmNZMkG9pJOMUt3CM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rRIP+dBqhqxpjJbtbFxbL8WVsH98tjRA+yloXjy69FN1PfoUgYOFxNAJqWtUCgFtK ZSU4RV8Nj1tQ3aPvzHfuQ== Received: from iwn35 (iwn35.prod.google.com [10.241.68.99]) by wpaz24.hot.corp.google.com with ESMTP id o9TCXWGF026296 for ; Fri, 29 Oct 2010 05:33:54 -0700 Received: by iwn35 with SMTP id 35so41726iwn.30 for ; Fri, 29 Oct 2010 05:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=denl0UXaIoCy6aXPjpNZmnNIs02T/hiw/UJPVajmN9Q=; b=eirE0QHb5x89zmreMag02m9Vqt4Jlktj594dwlKUF3/HPNpAaEhh5bqfUZh0Kqq8W0 wSk7A7XC6ddD7/T+Pf7Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wwsYVOzeE+R+pGbl1GMVWjAV9sjGtIZjjcmg+Qe2KzxcGgaorFCbJTqYRoqjYczE1Z mTrIyaChrIZ9b8QxPP8w== MIME-Version: 1.0 Received: by 10.231.38.1 with SMTP id z1mr10933943ibd.139.1288355628929; Fri, 29 Oct 2010 05:33:48 -0700 (PDT) Received: by 10.220.62.143 with HTTP; Fri, 29 Oct 2010 05:33:47 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Fri, 29 Oct 2010 13:33:47 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: keyassure@ietf.org, Phillip Hallam-Baker , iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 12:32:06 -0000 On 28 October 2010 01:12, Paul Wouters wrote: > On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote: > >> I think that this represents a superficial analysis of the problem. > > No Philip, you keep trying to drag in the cat's meow. I've already ignored > some claims you made about what I said. We understand you value PKIX. So > we do. We value DNSSEC. So should you. > >> This is a rather strange definition of 'separating' DNSSEC key assurance >> from PKIX. What is being proposed here is that the DNSSEC which >> is not yet deployed is to be promoted above PKIX which we have been >> working on and with for twenty plus years. > > It's your fear this is "above PKIX". If your PKIX system works well > enough, and is better then DNSSEC, why do you have this fear? You are > the one who keeps trying to mix DNSSEC and PKIX. I've made statements > I favour to keep these two separate, so they do not HAVE to interfere > with one another. I never said "above". I said "separate" and "according > to client policy". I'm bending over backwards to not interfere with > any current PKIX deployment, and requested the same in return (eg I'm > opposed to a CAA record). > > I would be interestd in what others who have not expressed themselves > have to say on these matters, but I believe my views (and yours) on this > topic have been stated clearly. Unless the IESG asks me for more input, > I'll refrain from further adding to this discussion. I am with David Conrad on the DoS attack: I don't understand what useful this seemingly endless discussion is actually _about_. Paul wants client policy to decide whether to trust PKIX, DNSSEC or some mixture of the two. This seems not only reasonable, but unavoidable: clients will implement what suits them, and we are in no position to change that. Phillip wants the domain in question to be able to state its intentions w.r.t. the policy clients should use. This seems not unreasonable, also. Clients can choose to follow this or not. He also wants to separate protocols so policy can apply to domain+protocol, not merely domain. This seems like an obvious requirement to me. None of these seem to me to be incompatible with each other. So, what is being discussed? > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABE33A67A3; Thu, 28 Oct 2010 17:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.467 X-Spam-Level: X-Spam-Status: No, score=0.467 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUdxvgtO0geY; Thu, 28 Oct 2010 17:03:03 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id E83AC3A6452; Thu, 28 Oct 2010 17:03:02 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id o9T04iVB017598; Thu, 28 Oct 2010 17:04:44 -0700 Message-Id: <201010290004.o9T04iVB017598@new.toad.com> To: Warren Kumari In-reply-to: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <201010280805.o9S85FWR052190@bartok.nlnetlabs.nl> <8FCC7646-EEF0-441D-A6D5-00FBBB684502@insensate.co.uk> Comments: In-reply-to Warren Kumari message dated "Thu, 28 Oct 2010 12:01:27 -0400." Date: Thu, 28 Oct 2010 17:04:44 -0700 From: John Gilmore Cc: keyassure@ietf.org, Jaap Akkerhuis , IESG IESG , Phillip Hallam-Baker Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 00:03:04 -0000 > > On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's: > >> To be blunt, I feel keyassure/kidns is being subject to a DoS > >> attack and gave up reading all messages (and most of my hope > >> about timely forward progress on this topic within the IETF) > >> some time ago. I have nothing nice to say on the topic, so I will say nothing. John Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3156E3A659C for ; Thu, 28 Oct 2010 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giaKllV8eWp7 for ; Thu, 28 Oct 2010 15:15:57 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 451E33A657C for ; Thu, 28 Oct 2010 15:15:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=hWdZJo7Cmlf5paODNnZObmCIVWvnjeoDZoBGX6KjSBIFckqtovPI6Onxm5trL3Jr; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PBan6-0008Jx-Hf; Thu, 28 Oct 2010 18:17:48 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Thu, 28 Oct 2010 18:17:48 -0400 Message-ID: <12474042.1288304268559.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Thu, 28 Oct 2010 17:17:48 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Stephen Farrell , Paul Hoffman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606889849bd08c75e252f853c39f25e38e6ba350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 22:15:59 -0000 Stephen and all, -----Original Message----- >From: Stephen Farrell >Sent: Oct 28, 2010 4:14 PM >To: Paul Hoffman >Cc: keyassure@ietf.org >Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns > > >Having now caught up with the many recent messages, I'd also >be a bit concerned about the impact of: > >> "If a match between the certificate association(s) and the >> server's end entity certificate in TLS is not found, the >> TLS client MUST abort the handshake with an "access_denied" error." > >The concerns I have about it would include: > >- I'm not really sure if that same rule would be appropriate > for all applications that use TLS, nor for all deployments > of each protocol using TLS - basically the policy slippery > slope PHB is raising (from time to time:-) yeah this is a valid concern, but we do need to be explicit here. >- I think the security implications (e.g. potential for it > being a DoS vector e.g. if some DNS management nodes > were compromised) would need to be considered Absolutely. >- We'd need to think about whether any corner cases might be > problematic e.g. where an LDAP query for a CRL was running > over TLS or something Agreed here as well for what i would consider obvious and perhaps significant reasons. As such the relevant discussions regarding this should be cooridinated with the LDAP WG accordingly. How that is to be effected may be problamatic. >- I'm not sure what RFCs would be being UPDATED by an > RFC saying that, nor whether something like that should > really be left to the TLS WG Good point. I'm not sure either. But just leaving it to the TLS WG without close coordination would seem to be a bit unwieldy to me. > >It could be that folks have already thought through some >or all of that, and that that MUST is the right thing to >do, but that's not clear to me at this stage, so I do think >that a kidns WG (which I think is worth forming) would really >have to figure out answers to the above. FWIW and going out on a limb here, the kidns WG would seem to be the most logical place to centeralize the discussion on your above reasonable concerns/considerations. > >S. >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6193A659B for ; Thu, 28 Oct 2010 14:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.446 X-Spam-Level: X-Spam-Status: No, score=-101.446 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6tDYkV45-s3 for ; Thu, 28 Oct 2010 14:56:19 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2DB883A659A for ; Thu, 28 Oct 2010 14:56:19 -0700 (PDT) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9SLqskG057854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 14:52:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CC9E7AB.1030501@cs.tcd.ie> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> <4CC9E7AB.1030501@cs.tcd.ie> Date: Thu, 28 Oct 2010 14:52:53 -0700 To: Stephen Farrell From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 21:56:20 -0000 Thank you for being explicit! At 10:14 PM +0100 10/28/10, Stephen Farrell wrote: >Having now caught up with the many recent messages, I'd also >be a bit concerned about the impact of: > >> "If a match between the certificate association(s) and the >> server's end entity certificate in TLS is not found, the >> TLS client MUST abort the handshake with an "access_denied" error." > >The concerns I have about it would include: > >- I'm not really sure if that same rule would be appropriate > for all applications that use TLS, nor for all deployments > of each protocol using TLS - basically the policy slippery > slope PHB is raising (from time to time:-) OK, maybe try being more explicit. For example, if this document was in fact an update to TLS, would you have the same concern? Or, if you want a SHOULD rather than a MUST, what would the specific exceptions be (or are you asking for a typical IETF mushy SHOULD)? >- I think the security implications (e.g. potential for it > being a DoS vector e.g. if some DNS management nodes > were compromised) would need to be considered If a DNS management node were compromised, all bets are off anyway. I guess we thought that was obvious, but we should say that in the Security Considerations. >- We'd need to think about whether any corner cases might be > problematic e.g. where an LDAP query for a CRL was running > over TLS or something Those are no different in this document than in normal TLS, are they? That is, what does this document change in TLS that would add such a corner case? That would be important to analyze. >- I'm not sure what RFCs would be being UPDATED by an > RFC saying that, nor whether something like that should > really be left to the TLS WG It should be done in coordination with the TLS WG, if this WG is formed and this is the way that the WG wants to go. >It could be that folks have already thought through some >or all of that, and that that MUST is the right thing to >do, but that's not clear to me at this stage, so I do think >that a kidns WG (which I think is worth forming) would really >have to figure out answers to the above. Fully agree. Please fill in any of the above after the WG is formed and if this is the direction that the WG goes. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DE73A6991 for ; Thu, 28 Oct 2010 14:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97uiO0D2Qnsk for ; Thu, 28 Oct 2010 14:23:36 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4B5373A689B for ; Thu, 28 Oct 2010 14:23:36 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id E01EAC2EC; Thu, 28 Oct 2010 17:25:21 -0400 (EDT) Date: Thu, 28 Oct 2010 17:25:21 -0400 (EDT) From: Paul Wouters To: =JeffH In-Reply-To: <4CC9DEA2.4040707@KingsMountain.com> Message-ID: References: <4CC9DEA2.4040707@KingsMountain.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] fyi: draft-turner-dnssec-centric-pki-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 21:23:37 -0000 On Thu, 28 Oct 2010, =JeffH wrote: > > Title : DNSSEC-centric PKI > Author(s) : R. Housley, T. Polk, S. Turner > Filename : draft-turner-dnssec-centric-pki-00.txt > Pages : 6 > Date : 2010-10-18 Certification Authorities (CAs) take great care to ensure that the private key holder is associated with the domain name contained in the certificate. DNSSEC [RFC4033][RFC4034][RFC4035] offers an opportunity to eliminate complicated off-line processes. I would not add value judgements like with "take great care". Research papers from Kaminsky, Appelbaum and others have claimed otherwise. Nor is it "offline" as it most often is just an email/MX verification. Perhaps something like: Certification Authorities (CAs) ensure that the private key holder is associated with the domain name contained in the certificate, usually requiring some form of human interaction by the private key holder. DNSSEC [RFC4033][RFC4034][RFC4035] offers an alternative method where the association of private key holder and domain name is automated via the DNSSEC signing operations of the DNS zone. Regarding Section 2 / 3 I prefer this solution of returning a CA/EE over the addition of a new CAA record, if one wants to add to the existing PKIX infrastructure with DNSSEC. For TLS [RFC5246], when the TLS looks up the IP address in the DNS it can also request the CERT RR. If the certificate that is provided in the TLS handshake matches the one retrieved from DNSSEC, then the client can accept it as a trusted certificate for that site, provided local policy allows this. If the CA certificate is returned in the TLS handshake, the TLS client can verify that the TLS server certificate was issued under that CA. It is not entirely clear what to do with conflicting results. If the CERT (or CA) has expired, or contains an invalid SIG, should the CERT be rejected? If the DNSSEC sig was bad, the record would never be received for processing, and a servfail would be returned. Should a client continue with only PKIX after a ServFail or not? These should probably be local policy decisions, but the draft does not state these. I'm also not entirely sure how to do this for a large site with many domains. Does the CN= and/or subjectAltname matter? Does it need to match the DNS queried hostname? Or is it ignored? (If it is ignored, one could argue that the TLSFP approach might make more sense - we would have smaller DNS packets to deal with as a fingerprint is much smaller then a full cert with many subjectAltnames) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F5C3A6800 for ; Thu, 28 Oct 2010 14:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smK7n81X9c0j for ; Thu, 28 Oct 2010 14:12:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 1AF983A6870 for ; Thu, 28 Oct 2010 14:12:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7FCEA3E40A4; Thu, 28 Oct 2010 22:14:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288300462; bh=iC8P+Qs6GlaWC2 Ojvrs8UHtx5tyj+zATRPZlCnmyajc=; b=TkXPR1PdVjClDDuMVgnlifPYTBTY4M 4MYU9c2MdhWNdyDkuj0fYg7yq13JLkFqkCEY/BKJKeIKFBiFHpJsnm3OYUv28PqT 0tqXgr0Ej6FdK1WYL+H7BQ/GRO0wSJorDqOoUaVWC8Mwv+CC8yLIpMaM/6a7cvvO dGZIgVaaHIIe48XLA/mserWrLTUROopn9Bh49iOLqQb+BzDHKiVkQaZOCI11Qsdi JxIfagriAqCTVfxyYRLolMKWv6WyjpVqNj/93FjvQt8SUXqv15CV2yLMowZLEl7q XApGN+BAojblUWjmdMCxUcb3rvwi+1A+TJ78aYbVsUBmhbpR9/g4tQmA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Fv1El-oMUgMy; Thu, 28 Oct 2010 22:14:22 +0100 (IST) Received: from [192.168.225.32] (hnc91.internetdsl.tpnet.pl [79.188.80.91]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0C0753E4095; Thu, 28 Oct 2010 22:14:20 +0100 (IST) Message-ID: <4CC9E7AB.1030501@cs.tcd.ie> Date: Thu, 28 Oct 2010 22:14:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Paul Hoffman References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 21:12:33 -0000 Having now caught up with the many recent messages, I'd also be a bit concerned about the impact of: > "If a match between the certificate association(s) and the > server's end entity certificate in TLS is not found, the > TLS client MUST abort the handshake with an "access_denied" error." The concerns I have about it would include: - I'm not really sure if that same rule would be appropriate for all applications that use TLS, nor for all deployments of each protocol using TLS - basically the policy slippery slope PHB is raising (from time to time:-) - I think the security implications (e.g. potential for it being a DoS vector e.g. if some DNS management nodes were compromised) would need to be considered - We'd need to think about whether any corner cases might be problematic e.g. where an LDAP query for a CRL was running over TLS or something - I'm not sure what RFCs would be being UPDATED by an RFC saying that, nor whether something like that should really be left to the TLS WG It could be that folks have already thought through some or all of that, and that that MUST is the right thing to do, but that's not clear to me at this stage, so I do think that a kidns WG (which I think is worth forming) would really have to figure out answers to the above. S. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A5133A685B for ; Thu, 28 Oct 2010 13:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9tmlGcxz0+G for ; Thu, 28 Oct 2010 13:33:54 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 1DFD33A6803 for ; Thu, 28 Oct 2010 13:33:54 -0700 (PDT) Received: (qmail 7372 invoked by uid 0); 28 Oct 2010 20:35:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 28 Oct 2010 20:35:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=UZ7ZqXr+L5idnZKErgxdQtethYCvZRMPwG1WISBtTNyszBI3YMbWcehSWoO6/GHFoD+0D7GxJxIsFQrW7B2TwbDVfAbw/7KWh8gtgB75F+vWR8aqFtrGwSeiyBsrEIiw; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.163]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBZCM-00008c-Cv for keyassure@ietf.org; Thu, 28 Oct 2010 14:35:46 -0600 Message-ID: <4CC9DEA2.4040707@KingsMountain.com> Date: Thu, 28 Oct 2010 13:35:46 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [keyassure] fyi: draft-turner-dnssec-centric-pki-00.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 20:33:55 -0000 Subject: I-D ACTION:draft-turner-dnssec-centric-pki-00.txt From: Internet-Drafts@ietf.org Date: Mon, 18 Oct 2010 16:45:02 -0700 (PDT) To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNSSEC-centric PKI Author(s) : R. Housley, T. Polk, S. Turner Filename : draft-turner-dnssec-centric-pki-00.txt Pages : 6 Date : 2010-10-18 This draft is input to the KIDNS discussion. The procedures defined herein provide a general Public Key Infrastructure (PKI) mechanism that leverages DNSSEC. This is compatible with RFC 5280. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-dnssec-centric-pki-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA31F3A68EB for ; Thu, 28 Oct 2010 10:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.444 X-Spam-Level: X-Spam-Status: No, score=-101.444 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LI+0e04XO77 for ; Thu, 28 Oct 2010 10:29:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7075E3A6971 for ; Thu, 28 Oct 2010 10:29:32 -0700 (PDT) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9SHVNOf043875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 10:31:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> References: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> Date: Thu, 28 Oct 2010 10:31:21 -0700 To: Stephen Schultze , keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:29:46 -0000 At 1:11 PM -0400 10/28/10, Stephen Schultze wrote: >draft-hoffman-keys-linkage-from-dns-03: > >"If the application receives zero usable certificate associations, it process TLS in the normal fashion." >"If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error." > >I suggest: > >"If the application receives zero usable certificate associations, it MAY process TLS in the normal fashion." >"If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MAY abort the handshake with an "access_denied" error." > >This leaves it up to the client how to deal with the relationship between KIDNS and PKIX validation results. RFC 2119 language is used for two reasons: interoperability and security. The first of your two changes makes no sense: if there are no usable certificate associations, then there is no new information for TLS. If an implementer has chosen not to follow the TLS semantics, there is nothing that this protocol has to offer. Can you say how you think your second change improves either interoperability or security? --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164F73A67F2 for ; Thu, 28 Oct 2010 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.023 X-Spam-Level: X-Spam-Status: No, score=-4.023 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHWc3kYtW5TS for ; Thu, 28 Oct 2010 10:10:28 -0700 (PDT) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id B67D23A6834 for ; Thu, 28 Oct 2010 10:10:27 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id o9SHBuAA004113 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 28 Oct 2010 13:12:19 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9SHBtIl022778 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 28 Oct 2010 13:11:56 -0400 (EDT) Message-Id: <286A23F7-0E2F-4F5E-906C-315DD9B325DA@princeton.edu> From: Stephen Schultze To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Oct 2010 13:11:56 -0400 X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6149 signatures=641672 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010280064 Subject: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 17:10:32 -0000 draft-hoffman-keys-linkage-from-dns-03: "If the application receives zero usable certificate associations, it process TLS in the normal fashion." "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error." I suggest: "If the application receives zero usable certificate associations, it MAY process TLS in the normal fashion." "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MAY abort the handshake with an "access_denied" error." This leaves it up to the client how to deal with the relationship between KIDNS and PKIX validation results. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8A23A6904; Thu, 28 Oct 2010 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzNGAsVMD6nw; Thu, 28 Oct 2010 08:59:37 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id E5B013A68DB; Thu, 28 Oct 2010 08:59:36 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 67557DEE002; Thu, 28 Oct 2010 11:59:58 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 58A73DEE001; Thu, 28 Oct 2010 11:59:57 -0400 (EDT) Message-Id: From: Warren Kumari To: Lawrence Conroy In-Reply-To: <8FCC7646-EEF0-441D-A6D5-00FBBB684502@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Oct 2010 12:01:27 -0400 References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <201010280805.o9S85FWR052190@bartok.nlnetlabs.nl> <8FCC7646-EEF0-441D-A6D5-00FBBB684502@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: Jaap Akkerhuis , keyassure@ietf.org, IESG IESG , Phillip Hallam-Baker Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:59:38 -0000 On Oct 28, 2010, at 5:06 AM, Lawrence Conroy wrote: > On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's: >> To be blunt, I feel keyassure/kidns is being subject to a DoS >> attack and gave up reading all messages (and most of my hope >> about timely forward progress on this topic within the IETF) >> some time ago. >> >> You are not the only one. I did the same. Please come back, we need you all.... >> >> jaap > > To which I quip: > I note you don't say a DDoS attack. Ok, this is not the first time that I have heard rumblings like this -- I have also heard this in person from folk, and it seems to be leading to fragmentation of the group, and valuable contributors throwing in the towel and not participating. I urge these folk to come back, and, if necessary, simply kill-file the source of the DoS or, if you feel that that is not enough to allow you to happily participate, explicitly ask (on list) for moderation of the source the attack. I am also asking the list participants to please try and stay on topic and not attempt to drag the conversation into areas that are outside the interest of the rest of the (proposed) WG. If you are the lone voice in the wilderness (or if there is only one other person interested), please strongly consider doing your document as an individual submission that is mentioned *but not discussed* in the WG. The IETF is a consensus driven organization -- one person does not consensus make.... The purpose of this list is to make forward progress, come to consensus on what the group wants and then get something done. > It is a pity, as the draft(s) do need IETF review -- they are > still rough in places. Yes, yes they do... The *group* (and the IETF) will contribute to the final documents, and they will incorporate group consensus - I realize that there is noise at the moment (for which I apologize), but ask for people to *please* try and ignore the noise (and attempts to draw us down ratholes) and continue to participate / please come back if they have gotten fed up... > That won't be easy in the current noise. > ... we're civil to those who cavil. Yup, and we do our best to tolerate those who are not, even if it it trying... W > > atb, Lawrence > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, with great presence of mind, they brought Thousand Island Dressing and a bottle of chili sauce. -- Terry Pratchett Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F05F3A6855; Thu, 28 Oct 2010 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5w80lheKNJp; Thu, 28 Oct 2010 08:59:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 67D493A683C; Thu, 28 Oct 2010 08:59:29 -0700 (PDT) Received: by yxp4 with SMTP id 4so1446965yxp.31 for ; Thu, 28 Oct 2010 09:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uryJo0XxGkiughVd7DL/k3qvFnUanZtBtdZN4AcB5rg=; b=Kq9CsGqkp+7oRcrWMNCo6Gt8rs9Fw++hiP6JiYqoirDfnJq+tfdrI/iCwQb4mA4xyM xPWirWBEqImKLv53HJMm8UshEPo5YYnAXK4CN1wy/Cefoscr2z8Z1JbftzXtOJX2tImj VdfFs/Kff4cMEmx9RzGg0v7Z0/Q6/3g/S0wkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U+qx0YqUdpcyGmwhuncQnSpSuMWBhTEJ8u78LEzGvsrqAhJya9D7RXK1oZHPBldwno WwiOKnM5Qr3+z/FaJEIR5tgC+LjIrzQIYx/4ojK0Mc7JY8Ths7mvn+oUYiRQYIHTK1GD vTj1z/yFlcnBPhlRMGgDpFDaMlianH+8Ig5mg= MIME-Version: 1.0 Received: by 10.101.148.37 with SMTP id a37mr9298293ano.132.1288281681383; Thu, 28 Oct 2010 09:01:21 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Thu, 28 Oct 2010 09:01:21 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Thu, 28 Oct 2010 12:01:21 -0400 Message-ID: From: Phillip Hallam-Baker To: David Conrad Content-Type: multipart/alternative; boundary=0016e68ee136fd50750493af7328 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 15:59:31 -0000 --0016e68ee136fd50750493af7328 Content-Type: text/plain; charset=ISO-8859-1 I keep asking questions because I never get answers. I keep asking why you want to conflate a mechanism that enables new means of establishing a key as valid with a new means of declaring PKIX certificates to be invalid. Those are two entirely separate issues in my view and it is not appropriate to reuse the DNS CERT record to do both. Each time I ask the question why this has to be a requirement I get non-response responses and so I keep asking the question and I am going to keep on asking until I get a substantive response. The first priority in any IETF working group has to be to do no harm. There is no reason that using DNSSEC to authenticate keys for my SMTP service should require me to change the way I manage my Web service. If my objective was to sabotage the effort as you keep accusing me of, I would do everything I could to make sure this feature stayed in the draft because it is a poison pill that is going to totally kill adoption. I keep asking for a justification and I never get one. Instead I get non-response responses, to wit: * Various restatements of the requirements that do not address the question of why it is necessary to effectively force sites who deploy DNSSEC authenticated keys to stop all use of CA issued certs. * This is the wrong time to ask the question. * It is now too late to ask the question because the group has decided. * Personal attacks. * Denials that this is part of the proposal. * Denials that specifying criteria for evaluating trust chains is part of security policy * Claims to the effect that the difficult problems of PKI magically disappear when the bits are expressed in DNSSEC syntax * Suggestions to the effect that nobody should discuss this with the IESG because it has been discussed on the mailing list. * Suggestions to the effect that this should not be discussed on the mailing list as it should be decided by the IESG. It is very simple, if you want to shorten the discussion then stick to the topic and answer the question. On Wed, Oct 27, 2010 at 8:39 PM, David Conrad wrote: > On Oct 27, 2010, at 2:12 PM, Paul Wouters wrote: > > I would be interestd in what others who have not expressed themselves > > have to say on these matters, but I believe my views (and yours) on this > > topic have been stated clearly. > > To be blunt, I feel keyassure/kidns is being subject to a DoS attack and > gave up reading all messages (and most of my hope about timely forward > progress on this topic within the IETF) some time ago. > > Regards, > -drc > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e68ee136fd50750493af7328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I keep asking questions because I never get answers.

I k= eep asking why you want to conflate a mechanism that enables new means of e= stablishing a key as valid with a new means of declaring PKIX certificates = to be invalid.

Those are two entirely separate issues in my view and i= t is not appropriate to reuse the DNS CERT record to do both.=A0
=

Each time I ask the question why this has to = be a requirement I get non-response responses and so I keep asking the ques= tion and I am going to keep on asking until I get a substantive response.

The first priority in any IETF working group has to be = to do no harm. There is no reason that using DNSSEC to authenticate keys fo= r my SMTP service should require me to change the way I manage my Web servi= ce. If my objective was to sabotage the effort as you keep accusing me of, = I would do everything I could to make sure this feature stayed in the draft= because it is a poison pill that is going to totally kill adoption.=A0


I keep asking for a justification and I = never get one. Instead I get non-response responses, to wit:

=
* Various restatements of the requirements that do not address t= he question of why it is necessary to effectively force sites who deploy DN= SSEC authenticated keys to stop all use of CA issued certs.

* This is the wrong time to ask the question.

* It is now too late to ask the question because the group = has decided.

* Personal attacks.=A0

* Denials that this is part of the proposal.

* Denials that specifying criteria for evaluating trust chains is par= t of security policy=A0

* Claims to the effect tha= t the difficult problems of PKI magically disappear when the bits are expre= ssed in DNSSEC syntax

* Suggestions to the effect that nobody should discuss = this with the IESG because it has been discussed on the mailing list.
=

* Suggestions to the effect that this should not be dis= cussed on the mailing list as it should be decided by the IESG.

It is very simple, if you want to shorten the discussio= n then stick to the topic and answer the question.=A0


On Wed, Oct 27, 2010 at 8:39 PM, David Conrad <drc@virtualized.org= > wrote:
On Oct 27, 2010, at 2:12 = PM, Paul Wouters wrote:
> I would be interestd in what others who have not expressed themselves<= br> > have to say on these matters, but I believe my views (and yours) on th= is
> topic have been stated clearly.

To be blunt, I feel keyassure/kidns is being subject to a DoS attack = and gave up reading all messages (and most of my hope about timely forward = progress on this topic within the IETF) some time ago.

Regards,
-drc

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



--
Website: http://hallambaker.com/

--0016e68ee136fd50750493af7328-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A163A6895; Thu, 28 Oct 2010 02:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbm4BN6bG-KS; Thu, 28 Oct 2010 02:04:11 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id B36E53A677E; Thu, 28 Oct 2010 02:04:10 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 1D478746767; Thu, 28 Oct 2010 10:06:01 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <201010280805.o9S85FWR052190@bartok.nlnetlabs.nl> Date: Thu, 28 Oct 2010 10:06:00 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8FCC7646-EEF0-441D-A6D5-00FBBB684502@insensate.co.uk> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <201010280805.o9S85FWR052190@bartok.nlnetlabs.nl> To: Jaap Akkerhuis X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 09:04:13 -0000 On 28 Oct 2010, at 09:05, Jaap Akkerhuis wrote in response to DRC's: > To be blunt, I feel keyassure/kidns is being subject to a DoS > attack and gave up reading all messages (and most of my hope > about timely forward progress on this topic within the IETF) > some time ago. > > You are not the only one. I did the same. > > jaap To which I quip: I note you don't say a DDoS attack. It is a pity, as the draft(s) do need IETF review -- they are still rough in places. That won't be easy in the current noise. ... we're civil to those who cavil. atb, Lawrence Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5243A67EB; Thu, 28 Oct 2010 01:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY9YMtEG8z1z; Thu, 28 Oct 2010 01:03:27 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id E61963A67AB; Thu, 28 Oct 2010 01:03:26 -0700 (PDT) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id o9S85FWR052190; Thu, 28 Oct 2010 10:05:15 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201010280805.o9S85FWR052190@bartok.nlnetlabs.nl> To: David Conrad In-reply-to: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Comments: In-reply-to David Conrad message dated "Wed, 27 Oct 2010 14:39:54 -1000." Date: Thu, 28 Oct 2010 10:05:15 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.6 (bartok.nlnetlabs.nl [127.0.0.1]); Thu, 28 Oct 2010 10:05:15 +0200 (CEST) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 08:03:28 -0000 To be blunt, I feel keyassure/kidns is being subject to a DoS attack and gave up reading all messages (and most of my hope about timely forward progress on this topic within the IETF) some time ago. You are not the ony one. I did he same. jaap Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AAE3A67E6; Wed, 27 Oct 2010 18:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqhxKpcSsE1T; Wed, 27 Oct 2010 18:01:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 9ABF63A67EB; Wed, 27 Oct 2010 18:01:33 -0700 (PDT) Received: by gwb15 with SMTP id 15so975674gwb.31 for ; Wed, 27 Oct 2010 18:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=isdqmHjQcZPjelumxuY2ZBEyGjef4UfW6ZNLlB+JU80=; b=VsfKWgFz6Lj9t25Niry43OIwQ1DEBKbm0iDAN16Ap3M+taY9RlFvMpDnv2I5zzYvPX 25vTvi6a4g/vg9Muhwb3ZKlYi6sniIyP5YvHjvXywt9mKt/X6fqmP5/xvy+ZX9nJHaCR C0oapb95vDFzGVdav+2yMRVMIpO5sYsCqf2po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RQ6mU5FNGXAu1VmaQcohRVVulAg2cLJtMlVxHbQ4/C2paBI8sN4IjI+tNSV/BY/vPr 94iu2zFfqg1hi1M2x+lGFdBoOvGb4i1lj7Li6V1c3K/z6Iy/ARGZ07mwg60mVMRBvt/k U+ekwT7m0f/oivJc4lqJf5FToR/ztzvRr2E0A= MIME-Version: 1.0 Received: by 10.91.16.27 with SMTP id t27mr1847652agi.126.1288227803530; Wed, 27 Oct 2010 18:03:23 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 18:03:23 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Wed, 27 Oct 2010 21:03:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016363b82769e87820493a2e8a8 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 01:01:35 -0000 --0016363b82769e87820493a2e8a8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 27, 2010 at 8:12 PM, Paul Wouters wrote: > On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote: > > I think that this represents a superficial analysis of the problem. >> > > No Philip, you keep trying to drag in the cat's meow. I've already ignored > some claims you made about what I said. We understand you value PKIX. So > we do. We value DNSSEC. So should you. Which is precisely why I have spent the last year developing a security policy scheme that is based on DNSSEC. > This is a rather strange definition of 'separating' DNSSEC key assurance >> from PKIX. What is being proposed here is that the DNSSEC which >> is not yet deployed is to be promoted above PKIX which we have been >> working on and with for twenty plus years. >> > > It's your fear this is "above PKIX". If your PKIX system works well > enough, and is better then DNSSEC, why do you have this fear? You are > the one who keeps trying to mix DNSSEC and PKIX. I've made statements > I favour to keep these two separate, so they do not HAVE to interfere > with one another. I never said "above". I said "separate" and "according > to client policy". I'm bending over backwards to not interfere with > any current PKIX deployment, and requested the same in return (eg I'm > opposed to a CAA record). > You are putting words into my mouth here. The effect of this proposal is that if it is accepted there will be PKIX certificates that a client would currently consider valid that will now be considered invalid. That is not keeping the systems separate as you claim, it is the opposite. If I define a PGP key it does not invalidate my S/MIME cert. If I acquire an S/MIME cert it does not invalidate my PGP key. All I am saying here is that a given mechanism must either validate keys or it should invalidate keys. Here we have a mechanism where the act of validating one key automatically invalidates all others bound to the same name for those clients that observe the MUST requirements of the spec. I don't think that is necessary, I don't think that is useful. And I definitely think that we need to have a justification for joining the two together. I am pretty sure that there is history here with respect to security policy and that some section of the community has been burned really badly with an attempt to do security policy. But nobody seems able to tell me what it is. I would be interestd in what others who have not expressed themselves > have to say on these matters, but I believe my views (and yours) on this > topic have been stated clearly. Unless the IESG asks me for more input, > I'll refrain from further adding to this discussion. > So you ask a bunch of slanted questions and then retire from the field with the implication that I should not answer them? -- Website: http://hallambaker.com/ --0016363b82769e87820493a2e8a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 27, 2010 at 8:12 PM, Paul Wo= uters <paul@xele= rance.com> wrote:
On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:

I think that this represents a superficial analysis of the problem.

No Philip, you keep trying to drag in the cat's meow. I've already = ignored
some claims you made about what I said. We understand you value PKIX. So we do. We value DNSSEC. So should you.

Whic= h is precisely why I have spent the last year developing a security policy = scheme that is based on DNSSEC.


=A0
This is a rather strange definition of 'separating' DNSSEC key assu= rance from PKIX. What is being proposed here is that the DNSSEC which
is not yet deployed is to be promoted above PKIX which we have been working= on and with for twenty plus years.

It's your fear this is "above PKIX". If your PKIX system work= s well
enough, and is better then DNSSEC, why do you have this fear? You are
the one who keeps trying to mix DNSSEC and PKIX. I've made statements I favour to keep these two separate, so they do not HAVE to interfere
with one another. I never said "above". I said "separate&quo= t; and "according
to client policy". I'm bending over backwards to not interfere wit= h
any current PKIX deployment, and requested the same in return (eg I'm opposed to a CAA record).

You are putting words into my mouth here.=A0

The effect of this proposal is tha= t if it is accepted there will be PKIX certificates that a client would cur= rently consider valid that will now be considered invalid. That is not keep= ing the systems separate as you claim, it is the opposite. If I define a PG= P key it does not invalidate my S/MIME cert. If I acquire an S/MIME cert it= does not invalidate my PGP key.

All I am sa= ying here is that a given mechanism must either validate keys or it should = invalidate keys. Here we have a mechanism where the act of validating one k= ey automatically invalidates all others bound to the same name for those cl= ients that observe the MUST requirements of the spec.

I don't= think that is necessary, I don't think that is useful. And I definitel= y think that we need to have a justification for joining the two together.= =A0


<= div class=3D"gmail_quote">I am pretty sure that there is history here with = respect to security policy and that some section of the community has been = burned really badly with an attempt to do security policy. But nobody seems= able to tell me what it is.=A0


I would be interestd in what others who have not expressed themselves
have to say on these matters, but I believe my views (and yours) on this topic have been stated clearly. Unless the IESG asks me for more input,
I'll refrain from further adding to this discussion.

So you ask a bunch of slanted questions and then retire from the field wit= h the implication that I should not answer them?=A0

--
Website: http://hallam= baker.com/

--0016363b82769e87820493a2e8a8-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 968E93A67ED; Wed, 27 Oct 2010 17:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssm0C-twNReD; Wed, 27 Oct 2010 17:38:09 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id B8EED3A67D0; Wed, 27 Oct 2010 17:38:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 218F4EEBC08; Wed, 27 Oct 2010 17:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5ILEW-DHjNm; Wed, 27 Oct 2010 17:39:58 -0700 (PDT) Received: from [10.0.1.7] (cpe-70-95-123-210.hawaii.res.rr.com [70.95.123.210]) by virtualized.org (Postfix) with ESMTP id 183B3EEBBFD; Wed, 27 Oct 2010 17:39:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Wed, 27 Oct 2010 14:39:54 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> To: Paul Wouters X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 00:38:10 -0000 On Oct 27, 2010, at 2:12 PM, Paul Wouters wrote: > I would be interestd in what others who have not expressed themselves > have to say on these matters, but I believe my views (and yours) on = this > topic have been stated clearly. To be blunt, I feel keyassure/kidns is being subject to a DoS attack and = gave up reading all messages (and most of my hope about timely forward = progress on this topic within the IETF) some time ago. Regards, -drc Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFD73A67AD for ; Wed, 27 Oct 2010 17:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.442 X-Spam-Level: X-Spam-Status: No, score=-101.442 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09lfwoAa+ROB for ; Wed, 27 Oct 2010 17:26:16 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 548403A67B1 for ; Wed, 27 Oct 2010 17:26:16 -0700 (PDT) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9S0DkEx084165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 17:13:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 27 Oct 2010 17:13:45 -0700 To: Warren Kumari , keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] DRAFT Agenda for KIDNS BOF. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 00:26:17 -0000 At 7:29 PM -0400 10/27/10, Warren Kumari wrote: >o draft-hoffman-keys-linkage-from-dns 45 minutes > Using Secure DNS to Associate Certificates with Domain Names For TLS. > Paul Hoffman Errr, no. There are approximately five drafts that have been discussed on the list so far, and I intend to bring up proposals from all of them. FWIW, Jakob Schlyter and I are working together on this, and he and I have already found things that the other one overlooked. The talk is currently titled "Some of the Early KIDNS Proposals", and I think that is what should be in the agenda. You can list Jakob and I, although only I will be giving the talk. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BA53A67B1; Wed, 27 Oct 2010 17:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr1oRmk1s96u; Wed, 27 Oct 2010 17:11:07 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 91C213A67AD; Wed, 27 Oct 2010 17:11:07 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4153BC3F8; Wed, 27 Oct 2010 20:12:57 -0400 (EDT) Date: Wed, 27 Oct 2010 20:12:56 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 00:11:11 -0000 On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote: > I think that this represents a superficial analysis of the problem. No Philip, you keep trying to drag in the cat's meow. I've already ignored some claims you made about what I said. We understand you value PKIX. So we do. We value DNSSEC. So should you. > This is a rather strange definition of 'separating' DNSSEC key assurance from PKIX. What is being proposed here is that the DNSSEC which > is not yet deployed is to be promoted above PKIX which we have been working on and with for twenty plus years. It's your fear this is "above PKIX". If your PKIX system works well enough, and is better then DNSSEC, why do you have this fear? You are the one who keeps trying to mix DNSSEC and PKIX. I've made statements I favour to keep these two separate, so they do not HAVE to interfere with one another. I never said "above". I said "separate" and "according to client policy". I'm bending over backwards to not interfere with any current PKIX deployment, and requested the same in return (eg I'm opposed to a CAA record). I would be interestd in what others who have not expressed themselves have to say on these matters, but I believe my views (and yours) on this topic have been stated clearly. Unless the IESG asks me for more input, I'll refrain from further adding to this discussion. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8AD3A679F for ; Wed, 27 Oct 2010 16:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OCpWEIXz+nw for ; Wed, 27 Oct 2010 16:25:49 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id D9A623A63D2 for ; Wed, 27 Oct 2010 16:25:48 -0700 (PDT) Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 03109228479E; Wed, 27 Oct 2010 19:26:09 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Oct 2010 19:29:01 -0400 Message-Id: To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [keyassure] DRAFT Agenda for KIDNS BOF. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 23:25:50 -0000 Hello all, Here is the draft agenda for the KIDNS BOF on Thursday. As always, = subject to change, may cause baldness, etc. W THURSDAY, November 11, 2010 1520-1720 Afternoon Session II Garden Ballroom 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 CHAIR(s): Warren Kumari Ondrej Sury =20 o Administrivia 15 minutes Chairs =20 - Note Well - Scribe - Blue Sheets - Document Status o Working group goals and agenda, charter, etc. Ondrej Sury 30 minutes =20 o draft-hoffman-keys-linkage-from-dns 45 minutes Using Secure DNS to Associate Certificates with Domain Names For TLS. Paul Hoffman o draft-turner-dnssec-centric-pki-00 30 minutes DNSSEC-centric PKI. Sean Turner o Discussions on what we are trying to accomplish in this group,=20 charter poking, etc.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C133A67B6 for ; Wed, 27 Oct 2010 15:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OKRqKy-VuUZ for ; Wed, 27 Oct 2010 15:41:46 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id B7A6A3A67B8 for ; Wed, 27 Oct 2010 15:41:46 -0700 (PDT) Received: (qmail 16891 invoked by uid 0); 27 Oct 2010 22:43:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 27 Oct 2010 22:43:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=1nWx5kFKMS2wiGMT3Qddpg7EmG+9Sk4XB9ct0mJWtt+ooZS9BU/4wiqahgUzQcZ3JHP1boAB2kkdo+fpwnIdVdReEf5iqtE4PnxZE/uoW8l2XLopzz6a7+oYvCUwmbsS; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.163]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBEiW-0000p7-TT; Wed, 27 Oct 2010 16:43:36 -0600 Message-ID: <4CC8AB17.1090608@KingsMountain.com> Date: Wed, 27 Oct 2010 15:43:35 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: keyassure@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 22:41:49 -0000 I support a working group being formed. some specific comments on the proposed chater (best in a fixed-pitch font)... > Objective: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS and authenticated using DNSSEC to obtain > public keys which are associated with a service located at a > domain name. The above paragraph doesn't parse well for me. How about something like.. Specify mechanisms and techniques that facilitate Internet applications to establish cryptographically secured communications by leveraging DNSSEC-authenticated DNS information; for example public keys associated with a service at a domain name. > Problem Statement: > > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. this isn't a "problem statement" -- it just states the status-quo scenario. building on what Stephane proposed, add a new para here, such as.. Currently, binding of domain names to public keys is typically accomplished using public-key certificates issued and signed by Certificate Authorities (CAs) [PKIX]. Authentication of a certificate-presenting party by a relying party involves checking the certificate's signature and iterating up the "certificate chain" until a "trust anchor" is reached, for which the relying party has a public-key certificate copy, typically obtained in an out-of-band fashion. Relying parties often have a trust anchor certificate store containing certificates for many various trust anchors. Typically, the authentication process succeeds if examination of a trust anchor's certificate chain successfully terminates with a locally-cached trust anchor's certificate. This introduces a new ("third") party in a given authentication process. Additionally, the relying party is trusting any and all of the various "third-party" trust anchors to not accidentally or maliciously issue "unauthorized" certificates purporting to be associated with any particular target domain. Objectives and Scope > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust ^^^^^^^^ verify > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. ^^^ ^^^^^^^^^^^^ del it and/or its delegates control. > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and ^ then > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). probably need to re-word above to be explict that TLS is only presently in-scope "client" protocol. perhaps need an explicit "out of scope" section. > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. > > Milestones: > Dec 2010 First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > Jan 2011 First WG draft of standards-track protocols for using DNS to > associate hosts with IPsec > Jun 2011 Protocol for using DNS to associate domain names with keys > for TLS and DTLS to IESG > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG > Aug 2011 Recharter HTH, =JeffH Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325503A679F; Wed, 27 Oct 2010 14:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUIp0DKFFAe8; Wed, 27 Oct 2010 14:05:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 43BF03A677D; Wed, 27 Oct 2010 14:05:29 -0700 (PDT) Received: by ywp6 with SMTP id 6so857611ywp.31 for ; Wed, 27 Oct 2010 14:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Nnbq2iFH9goqIcRUTVOxZnejB10kk6RJlCswfkA1un8=; b=AKsfcZvlSFhIWUSfYV0w2AIq9dSjzpKBY6Sf6P/78KpSZB5+7a8fyFjsA0hNvD03mi KVPgXd/EkJchljv331TGtwp7/aCQ8r0ygZj3RVpPb6vlcbVzVdon9D+64GkEAwy/h8wi FC6XSg6r4XMSziyv1hLStGotfdsy4vkekE0wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=S03wvxqXtpWsRuvS6s3vdWcK6b+Q27mqlFyTaG0p8xSbIStH43u09EF2zA+zCTSJww R+8xikjA2wVz7tkhqxiLt1ZLCp1RMJOeekZlArnVG3pH4FeKafafurfBpyZy9mB7XKLe up9xSsYxFlr4CtTdbrSaLM/EuxVZYIYu4YuB8= MIME-Version: 1.0 Received: by 10.100.167.18 with SMTP id p18mr3852377ane.180.1288213639222; Wed, 27 Oct 2010 14:07:19 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 14:07:19 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Wed, 27 Oct 2010 17:07:19 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001485f6d1ae5c58e004939f9cb9 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 21:05:31 -0000 --001485f6d1ae5c58e004939f9cb9 Content-Type: text/plain; charset=ISO-8859-1 I think that this represents a superficial analysis of the problem. If we were going to act on this set of concerns we have to start from a far more precise definition of the problem and a considerably more thorough analysis of the security considerations. It is reasonably easy to identify issues with the CA SSL system because it has been deployed 15 years and we have a lot of experience. At the moment, DNSSEC is an unknown. And what is worse it is really difficult to have a public debate about the precise level of security DNSSEC achieves because there are lots of people involved in deployment of DNSSEC who fear that any open discussion of the limitations might be used to provide a pretext for further delay. This is a rather strange definition of 'separating' DNSSEC key assurance from PKIX. What is being proposed here is that the DNSSEC which is not yet deployed is to be promoted above PKIX which we have been working on and with for twenty plus years. I am not suggesting that we do not support this type of semantics, merely that these be kept separated from any new mechanism for signing keys. The ESRV proposal I have a draft out on is a proposal for an extensible security policy framework. I think that if there is to be any work on security policy we have to address the pieces that are easiest to define and provide the greatest benefit first. Some parts of the security policy swamp are considered to be inevitable rat holes. Specification of which trust anchor is allowed to be used for which purpose is considered the swampiest. So I am not proposing to charge into that part of the swamp first. If we have a mechanism that allows a domain to state 'SSL is always offered' and a mechanism that allows sites to generate domain validated keys at no additional out of pocket cost beyond that of deploying DNSSEC we are then in a position to be able to make cryptography the default and retire the padlock icon and DV certificates completely. The swamp is drained. On Wed, Oct 27, 2010 at 2:47 PM, Paul Wouters wrote: > On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote: > > We can end this discussion now if the proposers are willing to accept: >> >> "If a match between the certificate >> association(s) and the server's end entity certificate in TLS is not >> found, TLS path processing MUST be performed as if no TLSFP record was >> published" >> > > I'd rather not see this. If a host is compromised, an attacker can change > the cert, get it signed by a rogue/sloppy CA, and get it to ignore the > entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed > for another trust hierarchy (The CA one). > > I think it makes more sense to say if a DNSSEC protected record is wrong, > then treat it as a problem, don't ignore it, provided your client policy > is to use TLSFP/DNSSEC. > > Similarly, I don't expect a client with a CA policy to accept an > invalid/expired CERT based on the fact that the TLSFP record happens > to match. > > It is very important we do not start mixing CA and DNSSEC based trust > models, or we end up with the worst of both worlds. > > Paul > -- Website: http://hallambaker.com/ --001485f6d1ae5c58e004939f9cb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that this represents a superficial analysis of the problem. If we w= ere going to act on this set of concerns we have to start from a far more p= recise definition of the problem and a considerably more thorough analysis = of the security considerations.

It is reasonably easy to identify issues with the CA SSL sys= tem because it has been deployed 15 years and we have a lot of experience. = At the moment, DNSSEC is an unknown. And what is worse it is really difficu= lt to have a public debate about the precise level of security DNSSEC achie= ves because there are lots of people involved in deployment of DNSSEC who f= ear that any open discussion of the limitations might be used to provide a = pretext for further delay.


This is a rather strange definition of &= #39;separating' DNSSEC key assurance from PKIX. What is being proposed = here is that the DNSSEC which is not yet deployed is to be promoted above P= KIX which we have been working on and with for twenty plus years.


I am not suggesting that we do not suppo= rt this type of semantics, merely that these be kept separated from any new= mechanism for signing keys.

The ESRV proposal I h= ave a draft out on is a proposal for an extensible security policy framewor= k. I think that if there is to be any work on security policy we have to ad= dress the pieces that are easiest to define and provide the greatest benefi= t first.

Some parts of the security policy swamp are considered = to be inevitable rat holes. Specification of which trust anchor is allowed = to be used for which purpose is considered the swampiest. So I am not propo= sing to charge into that part of the swamp first.

If we have a mechanism that allows a domain to state &#= 39;SSL is always offered' and a mechanism that allows sites to generate= domain validated keys at no additional out of pocket cost beyond that of d= eploying DNSSEC we are then in a position to be able to make cryptography t= he default and retire the padlock icon and DV certificates completely. The = swamp is drained.



On Wed, Oct 27, 2010= at 2:47 PM, Paul Wouters <paul@xelerance.com> wrote:
On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote:

We can end this discussion now if the proposers are willing to accept:

"If a match between the certificate
=A0=A0 association(s) and the server's end entity certificate in TLS is= not
=A0=A0 found,=A0TLS path processing MUST be performed as if no TLSFP record= was published"

I'd rather not see this. If a host is compromised, an attacker can chan= ge
the cert, get it signed by a rogue/sloppy CA, and get it to ignore the
entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed
for another trust hierarchy (The CA one).

I think it makes more sense to say if a DNSSEC protected record is wrong, then treat it as a problem, don't ignore it, provided your client polic= y
is to use TLSFP/DNSSEC.

Similarly, I don't expect a client with a CA policy to accept an
invalid/expired CERT based on the fact that the TLSFP record happens
to match.

It is very important we do not start mixing CA and DNSSEC based trust
models, or we end up with the worst of both worlds.

Paul



--
Website: http://hallambaker.com/

--001485f6d1ae5c58e004939f9cb9-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1CA3A680A; Wed, 27 Oct 2010 12:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqy0U-lXmGkE; Wed, 27 Oct 2010 12:49:26 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 610983A69A1; Wed, 27 Oct 2010 12:49:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=pahPsiTYbZ5CW5RdXR2aJv/HcF/BUBMSj2CsQALKN5RPeeDLp2KDbbTUds+uLtmI; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.28] (helo=mswamui-blood.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PBC1j-0006gE-07; Wed, 27 Oct 2010 15:51:15 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 27 Oct 2010 15:51:14 -0400 Message-ID: <20754507.1288209074785.JavaMail.root@mswamui-blood.atl.sa.earthlink.net> Date: Wed, 27 Oct 2010 14:51:14 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Phillip Hallam-Baker , Andrew Sullivan Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688a0cb91af4a8737f8048d2aa31a4ef71d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.28 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 19:49:28 -0000

Phillip and all,

 

 

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 27, 2010 12:39 PM
To: Andrew Sullivan
Cc: keyassure@ietf.org, iesg@ietf.org
Subject: Re: [= keyassure] WG Review: Keys In DNS (kidns)

This is a charter discuss= ion.=20

The question of Security Policy is a scope issue for the charter.
 
Agreed.

Thus the fact that we have proposals that attempt to address that scop= e is entirely relevant to this discussion.
 
Logically correct, so agreed.

I do not understand why you would think otherwise.
 
I do I think.  There seems to be a reluctance to recognize or acc= ept that for some WG security issues are
intertwined with policy decisions and vise versa. 


The objective of this exercise is for both sides to clearly understand= what is being to agreed to. The worst case outcome would be for the IESG t= o approve the WG charter and then reject the WG document proposals as out o= f scope because they thought that they were agreeing to something else.
 
Maybe not the worst outcome, but certainly not a good one IMO.


I am finding the rules of engagement here to be rather peculiar. It se= ems that it is unacceptable for me to suggest that what is being proposed i= s what the documents and the authors say that they are proposing while it i= s fine for Richard to make insulting accusations.
 
  FWIW, seems that there is some Fear, uncertainty, and doubt , &= lt; FUD > as there is with almost any security
related protocol consideration.  That FUD, which is not one of an= insulting nature, but one borne of the very
nature of what any WG on such considerations may have in respect to po= licy and politics < yuk > that are
unfortunately intertwined accordingly.  Of course the rodent-hole= s and fire pits that all too often unfortunately
come along with same, sometimes get deep/wide/politically-vemin infest= ed/hot accordingly and leaving
uncertainty in the wake.   So I wonder if this sort of FUD w= as not the FUD Richard was referring to? I'll
assume it was for now or until Richard confers otherwise.


On Wed, Oct 27, 2010 at 12:57 PM, Andrew Sullivan = <ajs= @shinkuro.com> wrote:
On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-Ba= ker wrote:
> I was responding to an unfair and untrue attack that ass= erted that I was
> spreading FUD.

I don't care about tha= t issue.  It's irrelevant to this discussion, I
think, which is sup= posed to be about whether it's right to form a WG
now.  Since you s= eem to be responding to substantive issues in
possible WG work, that is = evidence that there's work to be done and
even a community to do it. &nb= sp;Right?

> I was not spreading FUD, as you admit

No, I didn't.  I merely observed that I thought I understood why you<= BR>seemed to want to explore the details of of a particular proposal, andI was trying to say that I didn't think it mattered _why_, because
tha= t you were doing it was useful information.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
keyassur= e mailing list
key= assure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure=



--
Website: = http://hallambaker.com/=

Regards,
Jeffrey A. Williams
"Obedience of the law is the= greatest freedom" -
   Abraham Lincoln

"Credit should = go with the performance of duty and not with what is very
often the acci= dent of glory" - Theodore Roosevelt

"If the probability be called P;= the injury, L; and the burden, B; liability
depends upon whether B is l= ess than L multiplied by
P: i.e., whether B is less than PL."
United = States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Updated 1/26/04
CSO/DIR. Internet Network= Eng. SR. Eng. Network data security IDNS. div. of
Information Network E= ng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Ma= il jwkckid1@ix.netcom.com
Phone: 214-244-4827

= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4AB3A6803; Wed, 27 Oct 2010 11:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7JaoYvVvspZ; Wed, 27 Oct 2010 11:45:34 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 9433A3A6981; Wed, 27 Oct 2010 11:45:33 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 6FA06C2EC; Wed, 27 Oct 2010 14:47:22 -0400 (EDT) Date: Wed, 27 Oct 2010 14:47:22 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 18:45:37 -0000 On Wed, 27 Oct 2010, Phillip Hallam-Baker wrote: > We can end this discussion now if the proposers are willing to accept: > > "If a match between the certificate >    association(s) and the server's end entity certificate in TLS is not >    found, TLS path processing MUST be performed as if no TLSFP record was published" I'd rather not see this. If a host is compromised, an attacker can change the cert, get it signed by a rogue/sloppy CA, and get it to ignore the entire DNSSEC trust chain. In other words, DNSSEC trust is sacrificed for another trust hierarchy (The CA one). I think it makes more sense to say if a DNSSEC protected record is wrong, then treat it as a problem, don't ignore it, provided your client policy is to use TLSFP/DNSSEC. Similarly, I don't expect a client with a CA policy to accept an invalid/expired CERT based on the fact that the TLSFP record happens to match. It is very important we do not start mixing CA and DNSSEC based trust models, or we end up with the worst of both worlds. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19D23A69C9; Wed, 27 Oct 2010 10:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOj0Lq1fgda6; Wed, 27 Oct 2010 10:50:03 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 4F5543A68B1; Wed, 27 Oct 2010 10:50:01 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=KUwRjapF6Vy/n9hN2utpIzYx7gSgzBsEw8newnD65bmG9KpaP1czVYuS ReaLdMKzEBy9+HLvW8PTPuXGHzv+XeZaLe9OZrwMsSGl6r756mRHxrcGC kHQtUh9y+e8xVAx; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1288201913; x=1319737913; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Phillip=20Hallam-Baker=20, =20Andrew=20Sullivan=0D=0A=09|CC:=20"ke yassure@ietf.org"=20,=20"iesg@ietf.or g"=20|Date:=20Wed,=2027=20Oct=202010=2011: 51:50=20-0600|Subject:=20RE:=20[keyassure]=20WG=20Review: =20Keys=20In=20DNS=20(kidns)|Message-ID:=20<5EE049BA3C653 8409BBE6F1760F328ABEB01DE1321@DEN-MEXMS-001.corp.ebay.com >|References:=20<20101026170002.14A8C3A6992@core3.amsl.co m>=0D=0A=09=0D=0A=09=0D=0A=09<4CC7E1F7.2090303@ni c.cz>=0D=0A=09=0D=0A=09<25BC19E8-FE42-4DA4-915A-4A 7ABCE4C40D@bbn.com>=0D=0A=09=0D=0A=09=0D=0A =09<20101027161633.GP45134@shinkuro.com>=0D=0A=09=0D=0A=09<20101027165746.GQ45134@shinkuro.com>=0D=0A =20|In-Reply-To:=20|Content-Transfer-Encoding: =20quoted-printable|MIME-Version:=201.0; bh=hVjYB+BwToSHrIYEZ9dLNFW0IZ8hXUsPzKZEzSZ5rdY=; b=XASLB8wfDCtrpwybA38r9ctNCD0s4+Co1YiUKRwf83VSRW6l3zZ/oTJ/ z10sjV9ZvF5HTEW/4Au3E5kZEuQMCc3xHsj4p4rynJTIndh/ZtoQfUI04 hHzlVvhuO9IifV9; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.58,247,1286175600"; d="scan'208";a="72789989" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 27 Oct 2010 10:51:52 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Wed, 27 Oct 2010 11:51:51 -0600 From: "Steingruebl, Andy" To: Phillip Hallam-Baker , Andrew Sullivan Date: Wed, 27 Oct 2010 11:51:50 -0600 Thread-Topic: [keyassure] WG Review: Keys In DNS (kidns) Thread-Index: Act1/fKpNH4802wTRpCoWMXAanqU7wAANxDw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB01DE1321@DEN-MEXMS-001.corp.ebay.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <20101027161633.GP45134@shinkuro.com> <20101027165746.GQ45134@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: B/C8uvou60tNvKiR948anw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" , "iesg@ietf.org" Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:50:20 -0000 > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On B= ehalf Of Phillip Hallam-Baker > The question of Security Policy is a scope issue for the charter. > Thus the fact that we have proposals that attempt to address that scope i= s entirely relevant to this discussion. > The objective of this exercise is for both sides to clearly understand wh= at is being to agreed to. The worst case outcome=20 > would be for the IESG to approve the WG charter and then reject the WG do= cument proposals as out of scope because=20 > they thought that they were agreeing to something else. OK. If we store keys in DNS, we aren't doing it as just an FYI. We're sto= ring them there with the expectation that some bit of "client" software pay= attention to them, and consequently make a "policy" decision on what the p= resence of those keys mean. I'm fine with calling that a "security policy"= . And I'm fine with including it here. Are we all settled on whether PKIX validation should happen and keys in DNS= get us exclusion, or whether keys in dns automatically preclude PKIX valid= ation? No. In any case proposing a new way to pass around key information= is going to involve some policy choices unless all we define is a way to p= ass that data, and say absolutely nothing about how a client can tell wheth= er that data is valid. And frankly, since we are saying that the DNS respo= nses should be using DNSSEC, we *already* are making security policy decisi= ons here.=20 Oh, and I'm with Phillip on being civil. :) - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50D053A69C2; Wed, 27 Oct 2010 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5un9xCPLkM4; Wed, 27 Oct 2010 10:37:41 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 981AD3A6888; Wed, 27 Oct 2010 10:37:41 -0700 (PDT) Received: by gwb15 with SMTP id 15so660270gwb.31 for ; Wed, 27 Oct 2010 10:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uMgcBUar6QsxBdYNu8CbUYdV9Z2CenPdsXLMpLkNrEs=; b=T0mo7xwanUsTsD7cVNItkwjkOK+YgNgz3vDFt6uNw+apTHfA2uyrmQv24naTu2xRYC gaP4+DK6bZs530MQ9eTe6Z4wSj+xSKQvJPHa7gCVbNdULrbRdJjQU2jdRhq7MZaf9GrR eivamzHryT6rbfwRcwHsOjAIKh0JxaHSd5sog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fhOJTJlXwyXWALfLVWSM0k3ij9KzrB860G1V/K4qBLPR57J50c9BnPnty6rlczYY+9 wq6djF9fPtlWsxA4nN7PZAV7PTvvwTSGtZ43IIVuMjkeK2GRGY2gmh3+ePIhcqKEEXEi 9k9Jbjrvf00nndKjMb0GTv3ufmlIlU8qbpB3I= MIME-Version: 1.0 Received: by 10.101.7.26 with SMTP id k26mr8156070ani.220.1288201171360; Wed, 27 Oct 2010 10:39:31 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 10:39:31 -0700 (PDT) In-Reply-To: <20101027165746.GQ45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <20101027161633.GP45134@shinkuro.com> <20101027165746.GQ45134@shinkuro.com> Date: Wed, 27 Oct 2010 13:39:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636e1f34d37da7904939cb50b Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:37:43 -0000 --001636e1f34d37da7904939cb50b Content-Type: text/plain; charset=ISO-8859-1 This is a charter discussion. The question of Security Policy is a scope issue for the charter. Thus the fact that we have proposals that attempt to address that scope is entirely relevant to this discussion. I do not understand why you would think otherwise. The objective of this exercise is for both sides to clearly understand what is being to agreed to. The worst case outcome would be for the IESG to approve the WG charter and then reject the WG document proposals as out of scope because they thought that they were agreeing to something else. I am finding the rules of engagement here to be rather peculiar. It seems that it is unacceptable for me to suggest that what is being proposed is what the documents and the authors say that they are proposing while it is fine for Richard to make insulting accusations. On Wed, Oct 27, 2010 at 12:57 PM, Andrew Sullivan wrote: > On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-Baker wrote: > > I was responding to an unfair and untrue attack that asserted that I was > > spreading FUD. > > I don't care about that issue. It's irrelevant to this discussion, I > think, which is supposed to be about whether it's right to form a WG > now. Since you seem to be responding to substantive issues in > possible WG work, that is evidence that there's work to be done and > even a community to do it. Right? > > > I was not spreading FUD, as you admit > > No, I didn't. I merely observed that I thought I understood why you > seemed to want to explore the details of of a particular proposal, and > I was trying to say that I didn't think it mattered _why_, because > that you were doing it was useful information. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636e1f34d37da7904939cb50b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a charter discussion.

The question of Security P= olicy is a scope issue for the charter.

Thus the f= act that we have proposals that attempt to address that scope is entirely r= elevant to this discussion.

I do not understand why you would think otherwise.


The objective of this exercise is for b= oth sides to clearly understand what is being to agreed to. The worst case = outcome would be for the IESG to approve the WG charter and then reject the= WG document proposals as out of scope because they thought that they were = agreeing to something else.


I am finding the rules of engagement her= e to be rather peculiar. It seems that it is unacceptable for me to suggest= that what is being proposed is what the documents and the authors say that= they are proposing while it is fine for Richard to make insulting accusati= ons.


On Wed, Oct 27, 2010 at 12:57 PM, A= ndrew Sullivan <aj= s@shinkuro.com> wrote:
On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-= Baker wrote:
> I was responding to an unfair and untrue attack that asserted that I w= as
> spreading FUD.

I don't care about that issue. =A0It's irrelevant to this dis= cussion, I
think, which is supposed to be about whether it's right to form a WG now. =A0Since you seem to be responding to substantive issues in
possible WG work, that is evidence that there's work to be done and
even a community to do it. =A0Right?

> I was not spreading FUD, as you admit

No, I didn't. =A0I merely observed that I thought I understood wh= y you
seemed to want to explore the details of of a particular proposal, and
I was trying to say that I didn't think it mattered _why_, because
that you were doing it was useful information.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
___________________________________= ____________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



--
Website: http://hallambaker.com/

--001636e1f34d37da7904939cb50b-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DEC3A680A; Wed, 27 Oct 2010 10:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gz4fRBT-m4F; Wed, 27 Oct 2010 10:00:15 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 3DBF63A6803; Wed, 27 Oct 2010 10:00:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=t0jFUdzxQqx+oEtqEbrZuq5J+CHgIQFxBbtNQ+RijYsr4UMPXi70FTi1ax4yC2NP; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PB9O0-0003Fy-Up; Wed, 27 Oct 2010 13:02:04 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 27 Oct 2010 13:02:04 -0400 Message-ID: <32119566.1288198924918.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Wed, 27 Oct 2010 12:02:04 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Paul Hoffman , keyassure@ietf.org, iesg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b6a37afee9978841100b1cef725753c4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 17:00:16 -0000 Paul and all, -----Original Message----- >From: Paul Hoffman >Sent: Oct 27, 2010 11:46 AM >To: keyassure@ietf.org, iesg@ietf.org >Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) > >At 8:36 AM -0400 10/27/10, Phillip Hallam-Baker wrote: >>Security policy is generally understood to mean anything that was addressed in Matt Blaze's PolicyMaker scheme. > >FWIW, this is the first time I have heard such a definition, and thus suspect that it is not "generally understood". For example, it was never mentioned once on the mailing list for the IETF's (long-concluded) ipsec-policy WG. > >>Thus PKI trust chaining is excluded because it existed prior to PolicyMaker. >> >>Statements of the form 'always use SSL' or 'only trust these roots' are considered to be security policy statements. > >The concepts of "always use SSL" and "only trust these roots" also existed prior to the publication of their (not his) paper in 1996. > >If the IESG wants the KIDNS WG to deal with defining "policy", it should let us know sooner rather than later. Like it or not, admit it openly or not, the IESG and the IETF have to one degree or another, been about defining policy in one form or another. You know this. We have found or finnaly disclosed that for instance, 'only trust these roots' was not always a good thing to do. But also many of us from even before 1996 knew that but were not ever going to say so. But now we are at another point that is similar. "Only trust these CA's and Trust Anchors", when some of us know that some of the 'Trusted CA's' and 'Trust Anchors' are both one in the same, AND have had some security problems of their own due to complacency or other reasons. Are we not perhaps making the same mistake? Just my 2 cents... Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033713A680A; Wed, 27 Oct 2010 09:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyQA4Z2WjI9m; Wed, 27 Oct 2010 09:59:49 -0700 (PDT) Received: from mail166.messagelabs.com (mail166.messagelabs.com [216.82.253.163]) by core3.amsl.com (Postfix) with SMTP id D15723A6803; Wed, 27 Oct 2010 09:59:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-11.tower-166.messagelabs.com!1288198894!40183523!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 8500 invoked from network); 27 Oct 2010 17:01:35 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-11.tower-166.messagelabs.com with SMTP; 27 Oct 2010 17:01:35 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 27 Oct 2010 13:01:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] WG Review: Keys In DNS (kidns) Thread-Index: AQJm09DDUvit9hWiw0Honwf+Q22SUgG8kUcIAeHOXOMC1Lfl5gLf9kVPAlncIlEB17AysQJC1tcWkaAMYtA= References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> From: "Carl Wallace" To: "Phillip Hallam-Baker" Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:59:50 -0000 From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On = Behalf Of Phillip Hallam-Baker Sent: Wednesday, October 27, 2010 12:11 PM To: Richard L. Barnes Cc: keyassure@ietf.org; iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) The point at issue here is the following text in Hoffman-03: =A0=A0 If a match between one of the certificate association(s) and the =A0=A0 server's end entity certificate in TLS is found, the TLS client =A0=A0 continues the TLS handshake. =A0If a match between the = certificate =A0=A0 association(s) and the server's end entity certificate in TLS is = not =A0=A0 found, the TLS client MUST abort the handshake with an =A0=A0 "access_denied" error. Now I have discussed this with the authors on several occasions and at = least some of them intend this as a mechanism to guard against what they = see as the risk of unauthorized certificate issue by a CA. This text is buried in section 3. It comes after a pre-amble that gives = no justification for this behavior and no hint that this is a primary = purpose of the specification. We can end this discussion now if the proposers are willing to accept: "If a match between the certificate =A0=A0 association(s) and the server's end entity certificate in TLS is = not =A0=A0 found,=A0TLS path processing MUST be performed as if no TLSFP = record was published" [CW] Assuming your aim is not to render mismatches meaningless, there = are words similar enough to yours in the paragraph before the one you = referenced to handle the case where no match is found. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771783A6803; Wed, 27 Oct 2010 09:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.173 X-Spam-Level: X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5iYRapvQUyV; Wed, 27 Oct 2010 09:55:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B6AA33A693B; Wed, 27 Oct 2010 09:55:59 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 74D2B1ECB408; Wed, 27 Oct 2010 16:57:48 +0000 (UTC) Date: Wed, 27 Oct 2010 12:57:46 -0400 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20101027165746.GQ45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <20101027161633.GP45134@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:56:00 -0000 On Wed, Oct 27, 2010 at 12:41:28PM -0400, Phillip Hallam-Baker wrote: > I was responding to an unfair and untrue attack that asserted that I was > spreading FUD. I don't care about that issue. It's irrelevant to this discussion, I think, which is supposed to be about whether it's right to form a WG now. Since you seem to be responding to substantive issues in possible WG work, that is evidence that there's work to be done and even a community to do it. Right? > I was not spreading FUD, as you admit No, I didn't. I merely observed that I thought I understood why you seemed to want to explore the details of of a particular proposal, and I was trying to say that I didn't think it mattered _why_, because that you were doing it was useful information. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9F83A693B; Wed, 27 Oct 2010 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wv8zbh0FKDJ; Wed, 27 Oct 2010 09:55:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id DA1273A69F7; Wed, 27 Oct 2010 09:55:12 -0700 (PDT) Received: by ywp6 with SMTP id 6so611436ywp.31 for ; Wed, 27 Oct 2010 09:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jyWEWOymS09eg5R/8TzLvKL0hx7/fwPOU171mML2xqw=; b=B7Mp+nBgZOW2sH9lNTy9PXIWpIdECYTbZzgBVUu1hV7e4+cwoVVGT+h+2+YOt4BXY7 91liCJvKGCZGt1YTALLscs1HevuS5lUSFOHMkVA97DC7WC6miM4XEtjoasaDQa0CDowM rJMKyDeTaS1q42oBE9cJhf0Jbv5zm4Oe/NMks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NW2nOfQIE9cZ8hDcy3zudOyRI4GfAnRA2xDuHIRWCRFDkPyPjyVcFpTdPe0bMac9Ec 8J9FCfvzD/mJ+eUbe+7rR9WgsptMrMZosv4EIwZeesbHdfUf46s5H0TxdpuQSwUiW6vG 1vu6XRUUwXdJCPerdtRgYLnoLSbgGwx/3mzB8= MIME-Version: 1.0 Received: by 10.150.92.18 with SMTP id p18mr289753ybb.284.1288198622527; Wed, 27 Oct 2010 09:57:02 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 09:57:02 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027114125.GW45134@shinkuro.com> <4CC81B30.5020801@gmail.com> <20101027125343.GJ45134@shinkuro.com> Date: Wed, 27 Oct 2010 12:57:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=000e0cd4d7824bc28604939c1d70 Cc: Yaron Sheffer , keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:55:15 -0000 --000e0cd4d7824bc28604939c1d70 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 27, 2010 at 12:34 PM, Paul Hoffman wrote: > At 8:53 AM -0400 10/27/10, Andrew Sullivan wrote: > > >> If this is really a happy group of like-minded people, it should be easy > >> to cut-and-paste the charter, as well as your and Stephane's > >> clarifications into a Problem Statement I-D, and get it published soon > >> after the working group is formed. It need not block the work on the > >> technical solution. > > > >That sounds like a fine approach to me. The charter could be amended > >to require a problem statement I-D at the beginning. > > Another option is to include this in the first deliverable protocol > document. That saves both the WG and the IESG process time for something > that started as a copy-and-paste. That risks a very long and drawn out conversation between those of us who are convinced that security policy can be solved very easily and those of us who think it is difficult but tractable. And that conversation does nothing to get us any further with the IESG where the problem has been considered a very hard one for over a decade. I suggest that we instead follow the precedent of DKIM which was required to deliver the key publication and message signature draft before working on policy proposals. I seem to recall that DKIM was however allowed to work on the problem statement for the policy record at the same time as the key publication and message format work. Under this scheme the WG would have two phases, the initial phase being to produce a key publication mechanism and a problem statement for policy, the second phase being to work on the policy mechanism itself. This approach would not in any way delay deployment of DNSSEC published keys or prevent the group deciding to use a CERT certificate type as the only means of publishing certificate policy. The only long term consequence would be that we would end up with four new certificate types instead of just two and that people who do not want security policy with their key assurance would be assured of getting it. The second stage need not be gated on publication as an RFC. It could be sufficient to have the Security AD's permission to forward the proposal to the IESG. The key signing/publication problem is something that I think we can honestly say is understood really, really well. The number of degrees of freedom in the problem is really very small and so the only thing left to do is to write out the path processing semantics and a clear set of security requirements. The only real room for argument in the specification is on tagging and bagging issues. And none of that should affect the semantics. -- Website: http://hallambaker.com/ --000e0cd4d7824bc28604939c1d70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 27, 2010 at 12:34 PM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
At 8:53 AM -0400 10/27/10, Andrew Sullivan wrote:

>> If this is really a happy group of like-minded people, it should b= e easy
>> to cut-and-paste the charter, as well as your and Stephane's >> clarifications into a Problem Statement I-D, and get it published = soon
>> after the working group is formed. It need not block the work on t= he
>> technical solution.
>
>That sounds like a fine approach to me. =A0The charter could be amended=
>to require a problem statement I-D at the beginning.

Another option is to include this in the first deliverable protocol d= ocument. That saves both the WG and the IESG process time for something tha= t started as a copy-and-paste.

That risks a= very long and drawn out conversation between those of us who are convinced= that security policy can be solved very easily and those of us who think i= t is difficult but tractable. And that conversation does nothing to get us = any further with the IESG where the problem has been considered a very hard= one for over a decade.

I suggest that we instead follow the precedent of DKIM = which was required to deliver the key publication and message signature dra= ft before working on policy proposals. I seem to recall that DKIM was howev= er allowed to work on the problem statement for the policy record at the sa= me time as the key publication and message format work.


Under this scheme the WG would have two = phases, the initial phase being to produce a key publication mechanism and = a problem statement for policy, the second phase being to work on the polic= y mechanism itself.

This approach would not in any way delay deployment of = DNSSEC published keys or prevent the group deciding to use a CERT certifica= te type as the only means of publishing certificate policy. The only long t= erm consequence would be that we would end up with four new certificate typ= es instead of just two and that people who do not want security policy with= their key assurance would be assured of getting it.

The second stage need not be gated on publication as an= RFC. It could be sufficient to have the Security AD's permission to fo= rward the proposal to the IESG.


The key signing/publication problem is something that I think we can honest= ly say is understood really, really well. The number of degrees of freedom = in the problem is really very small and so the only thing left to do is to = write out the path processing semantics and a clear set of security require= ments.

The only real room for argument in the specification is= on tagging and bagging issues. And none of that should affect the semantic= s.


--
Website: http://hallambaker.com/

--000e0cd4d7824bc28604939c1d70-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA893A6952; Wed, 27 Oct 2010 09:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgUkTgFZLr4v; Wed, 27 Oct 2010 09:49:31 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 538EB3A6934; Wed, 27 Oct 2010 09:49:31 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BEECF40BB9; Wed, 27 Oct 2010 10:59:24 -0600 (MDT) Message-ID: <4CC85887.2030005@stpeter.im> Date: Wed, 27 Oct 2010 10:51:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Paul Hoffman References: <20101026170002.14A8C3A6992@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040904090603060204060407" Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:49:32 -0000 This is a cryptographically signed message in MIME format. --------------ms040904090603060204060407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/27/10 10:46 AM, Paul Hoffman wrote: > If the IESG wants the KIDNS WG to deal with defining "policy", it > should let us know sooner rather than later. If anything, this IESG member at least will request that the KIDNS WG rule out any work on defining "policy", which IMHO will lead to a rodent-hole of unusual size and perhaps even a fire swamp or two. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040904090603060204060407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NzE2NTExOVowIwYJKoZIhvcNAQkEMRYEFA24RUJfwoqoDajgfMb91CSBzDZgMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAdKjM/fGc1ot0wm/X/3hzS0M9Stc+GZsaz8gCgaRqNwXzuoDiNwtvoihgU Jxb4TuGcfuecKPRS8Fo1SOeRcX6S4mw+h5Vn7qu/lPauBT/C3jW9oHoRukqirnsosUrB/qVs P80cHGdkD74rlG4ioKap7btEBJZobJk8z2DsIYCWFmruFieL8+sfjtXDVrj0Unt54gU+lzpz kW3gOBVacnr1DypDaxPlBOegtQwIXJ8MZs1Cw9F/owUfgJ8YFUm2MiOnfcavqkUE2x1KZqE+ 4r/Mk7PEvl+dl5+iI8nkN3lMXL75selv+0QLk0zfX9uA+xTWfe+93HuC4IpOeYAPAOG9AAAA AAAA --------------ms040904090603060204060407-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311D63A698E; Wed, 27 Oct 2010 09:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.438 X-Spam-Level: X-Spam-Status: No, score=-101.438 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiJP-qhZK95X; Wed, 27 Oct 2010 09:44:17 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 13AB53A685C; Wed, 27 Oct 2010 09:44:16 -0700 (PDT) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9RGk5HF061383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 09:46:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Wed, 27 Oct 2010 09:46:04 -0700 To: keyassure@ietf.org, iesg@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:44:18 -0000 At 8:36 AM -0400 10/27/10, Phillip Hallam-Baker wrote: >Security policy is generally understood to mean anything that was addressed in Matt Blaze's PolicyMaker scheme. FWIW, this is the first time I have heard such a definition, and thus suspect that it is not "generally understood". For example, it was never mentioned once on the mailing list for the IETF's (long-concluded) ipsec-policy WG. >Thus PKI trust chaining is excluded because it existed prior to PolicyMaker. > >Statements of the form 'always use SSL' or 'only trust these roots' are considered to be security policy statements. The concepts of "always use SSL" and "only trust these roots" also existed prior to the publication of their (not his) paper in 1996. If the IESG wants the KIDNS WG to deal with defining "policy", it should let us know sooner rather than later. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4383A6948; Wed, 27 Oct 2010 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PfTV88jt0dZ; Wed, 27 Oct 2010 09:39:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 97F743A6803; Wed, 27 Oct 2010 09:39:39 -0700 (PDT) Received: by ywp6 with SMTP id 6so593384ywp.31 for ; Wed, 27 Oct 2010 09:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2abSLmL86yS2mCz5YKw7yng984GNO854OXEwWhCSXHA=; b=DMT7VO15af6rooHwW6/xHt82EB3IrdCb+mKXrVhDPxihH3XGIbd6F3NDq95clMlT9t jOI6fm7bUvZmDmEb/kNE0arlWjW+D147kbWPJE+1ZbUdo/X5TxIupH4c1dEBA8vjXh6E mpEP2/rPbDnbwGS9rRRSf+u0TZ0xKrHjR9iBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZK1DB22prkBFOwOLjYGmcvLlvwM6n4R201HQ/jtIIqBI48Hx0l3cmwquSP6JQgPyeY 5yDx8trss0+D2KRF2ITY7hooMJSz2IoNYmubFaup67GvQXyYadRktz4jU2N5Mr+P+nP5 w8XKTzu9uvOcF5CiWvukZQNL1QHboSHVbIIg4= MIME-Version: 1.0 Received: by 10.91.163.20 with SMTP id q20mr1183696ago.30.1288197689019; Wed, 27 Oct 2010 09:41:29 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 09:41:28 -0700 (PDT) In-Reply-To: <20101027161633.GP45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> <20101027161633.GP45134@shinkuro.com> Date: Wed, 27 Oct 2010 12:41:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001485f89bd4a78f0704939be521 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:40:00 -0000 --001485f89bd4a78f0704939be521 Content-Type: text/plain; charset=ISO-8859-1 I was responding to an unfair and untrue attack that asserted that I was spreading FUD. I was not spreading FUD, as you admit, my statement was fully justified by the proposal in question. I therefore believe that Richard should apologize for the implication that I was misrepresenting anyone's position. On Wed, Oct 27, 2010 at 12:16 PM, Andrew Sullivan wrote: > On Wed, Oct 27, 2010 at 12:10:32PM -0400, Phillip Hallam-Baker wrote: > > The point at issue here is the following text in Hoffman-03: > > You seem to be taking issue with particular proposals that the > proposed WG might work on _rather than_ the setting up of the WG in > order to work on these proposals. Doesn't that seem to you to be > _prima facie_ evidence that the WG in fact has work to do, and can > therefore be chartered to work on it? (Yes, I know what you were > responding to. I'm trying to bring the conversation back on the track > of what we were supposed to be talking about.) > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > -- Website: http://hallambaker.com/ --001485f89bd4a78f0704939be521 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was responding to an unfair and untrue attack that asserted that I was sp= reading FUD.

I was not spreading FUD, as you admit, my s= tatement was fully justified by the proposal in question. I therefore belie= ve that Richard should=A0apologize for the implication that I was misrepres= enting anyone's position.


On Wed, Oct 27, 2010 at = 12:16 PM, Andrew Sullivan <ajs@shinkuro.com> wrote:
On Wed, Oct 27, 2010 at 12:10:32PM -0400, Phillip Hallam-= Baker wrote:
> The point at issue here is the following text in Hoffman-03:

You seem to be taking issue with particular proposals that the
proposed WG might work on _rather than_ the setting up of the WG in
order to work on these proposals. =A0Doesn't that seem to you to be
_prima facie_ evidence that the WG in fact has work to do, and can
therefore be chartered to work on it? =A0(Yes, I know what you were
responding to. =A0I'm trying to bring the conversation back on the trac= k
of what we were supposed to be talking about.)

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.



--
Website: http://hallambaker.com/

--001485f89bd4a78f0704939be521-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B6E3A685C for ; Wed, 27 Oct 2010 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bml7+CFvzZd2 for ; Wed, 27 Oct 2010 09:39:49 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 8D0F03A69EF for ; Wed, 27 Oct 2010 09:38:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=JVhFyPA4uDvY5DSxSlbDWPy5MhBZ0TBxY24+tS0Kb4ZeQUH4/lbovqXqRbohQ+Dj; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PB93N-00028G-6Z; Wed, 27 Oct 2010 12:40:45 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 27 Oct 2010 12:40:45 -0400 Message-ID: <19030855.1288197645087.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Wed, 27 Oct 2010 11:40:45 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Stephane Bortzmeyer , Yaron Sheffer Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688e9add5ee014fffe5a6908e6c5e68b827350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:39:53 -0000 Stephane and all, -----Original Message----- >From: Stephane Bortzmeyer >Sent: Oct 27, 2010 3:03 AM >To: Yaron Sheffer >Cc: keyassure@ietf.org >Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) > >On Tue, Oct 26, 2010 at 10:44:23PM +0200, > Yaron Sheffer wrote > a message of 124 lines which said: > >> Lastly, the group includes contributors from the CA industry, which >> is very good. But given that we're putting all our trust in the DNS >> infrastructure and procedures, I would hope to see some domain >> operators in the loop. > >There are several already, like me or one of the proposed chairs. > >> The group has not produced a problem statement, > >It is in the charter. We could add something like: > >Currently, the authentication of the domain name is typically done by >the fact that the CA which signed the certificate checked in a way or >the other that the requester was the holder of example.com and that he >was allowed to delegate www.example.com (X.509 method). This >introduces a new party in the authentication process, the CA, while >some people may prefer to keep the process simpler, with only the >server manager and the DNS manager in the loop (they are the people >you need to trust anyway). I think you articulate here rather indirectly but adequately that the trust model being expanded to include at least the CA, but curiously leave out the Trust Anchors, of which some are the very same as the CA in this model which extends the hierarchal trust model proposed last week in D.C. which although i did not attend have now heard from several that did, that trust model is under some pressure as to be a workable one. Yes the server manager and DNS manager/provider are people that need to be able to be trusted, but not need to be trusted, which is how we got where we are here. >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B0D3A6A03; Wed, 27 Oct 2010 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYIEN85q0Qu2; Wed, 27 Oct 2010 09:33:14 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1F30B3A6A07; Wed, 27 Oct 2010 09:32:59 -0700 (PDT) Received: from [10.20.30.151] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9RGYffB060714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Oct 2010 09:34:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20101027125343.GJ45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027114125.GW45134@shinkuro.com> <4CC81B30.5020801@gmail.com> <20101027125343.GJ45134@shinkuro.com> Date: Wed, 27 Oct 2010 09:34:39 -0700 To: Andrew Sullivan , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:33:22 -0000 At 8:53 AM -0400 10/27/10, Andrew Sullivan wrote: >On Wed, Oct 27, 2010 at 02:29:36PM +0200, Yaron Sheffer wrote: >> >> My intention is not to add bureaucratic hurdles. It is to ensure that >> the group has reasonable consensus about its goals. I get worried when I >> see indecision about requirements/goals trickle into the technical spec, > >Yes, on this we fully agree. > >> If this is really a happy group of like-minded people, it should be easy >> to cut-and-paste the charter, as well as your and Stephane's >> clarifications into a Problem Statement I-D, and get it published soon >> after the working group is formed. It need not block the work on the >> technical solution. > >That sounds like a fine approach to me. The charter could be amended >to require a problem statement I-D at the beginning. Another option is to include this in the first deliverable protocol document. That saves both the WG and the IESG process time for something that started as a copy-and-paste. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8673A6998; Wed, 27 Oct 2010 09:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBLboi5WHgUU; Wed, 27 Oct 2010 09:14:47 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EE15A3A697C; Wed, 27 Oct 2010 09:14:46 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 15A1D1ECB408; Wed, 27 Oct 2010 16:16:36 +0000 (UTC) Date: Wed, 27 Oct 2010 12:16:34 -0400 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20101027161633.GP45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:14:50 -0000 On Wed, Oct 27, 2010 at 12:10:32PM -0400, Phillip Hallam-Baker wrote: > The point at issue here is the following text in Hoffman-03: You seem to be taking issue with particular proposals that the proposed WG might work on _rather than_ the setting up of the WG in order to work on these proposals. Doesn't that seem to you to be _prima facie_ evidence that the WG in fact has work to do, and can therefore be chartered to work on it? (Yes, I know what you were responding to. I'm trying to bring the conversation back on the track of what we were supposed to be talking about.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DFF3A6979; Wed, 27 Oct 2010 09:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9LUJTqKdhio; Wed, 27 Oct 2010 09:08:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D91FB3A6853; Wed, 27 Oct 2010 09:08:43 -0700 (PDT) Received: by gxk7 with SMTP id 7so561245gxk.31 for ; Wed, 27 Oct 2010 09:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QumNLdjEbgP3dJ6nsKpx1EwklpOAmB+gSWBSLlFBn3I=; b=fYLr2Znq+00GEl5UnOuMKGiQR0iOT7jV7Nj59XEKY6O/En9mHn/09JqiXHHhq7Lio8 7x+n0F7JtjQnzc6T/rk2mF/z7CZU3fqaW3M+Ik4jxZ4wKOvAo8Rr4izxzPGIFDBsZhNd G8AKl1pEVDu/PMDY+aeUyBdyikV9veOjPIBo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bP/uIAjc3/he7X2xeueI4vkFB3gYVlMadXdgCN7dJD0yREK3wLQkDL5/uk3fIBQIEC B5Ngnx3z9vsGcqYBBkdyT64mTBmFBMqxN15MyBYcuwyKq0IKZsddu0ZZg3TBZaQFoeWV o6PmnAr6Ts6CNcsUkSMe+OwXLTLdEGD8XrMhU= MIME-Version: 1.0 Received: by 10.100.134.8 with SMTP id h8mr8061064and.63.1288195833008; Wed, 27 Oct 2010 09:10:33 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 09:10:32 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Wed, 27 Oct 2010 12:10:32 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=0016e644d6d007118404939b7792 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 16:08:46 -0000 --0016e644d6d007118404939b7792 Content-Type: text/plain; charset=ISO-8859-1 The point at issue here is the following text in Hoffman-03: If a match between one of the certificate association(s) and the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake. If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error. Now I have discussed this with the authors on several occasions and at least some of them intend this as a mechanism to guard against what they see as the risk of unauthorized certificate issue by a CA. This text is buried in section 3. It comes after a pre-amble that gives no justification for this behavior and no hint that this is a primary purpose of the specification. We can end this discussion now if the proposers are willing to accept: "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, TLS path processing MUST be performed as if no TLSFP record was published" At the very minimum, this type of behavior has to be optional. I am quite happy for the IETF to specify a mechanism to address this particular use case but it is an aspect of security policy, it is the most difficult aspect of security policy and I do not want to have it conflated with a new mechanism for key validation. At the very least, any mechanism that has this intent should be clearly and unambiguously specified in the problem statement of the RFC. And there has to be a very compelling reason given for addressing the two issues together. Saving a DNS round trip is not a compelling reason in my view. There is a great tendency for IETF working groups to think about the difficulty of implementation and efficiency as the most important issues. My view is that the most important issue is functionality and the next most important is usability for the system administrator. We have a whole lot of security infrastructure that remains as shelfware because the typical administrator is not confident that they understand how to configure it correctly. Network admins are busy people. Their networks break for all sorts of reasons that are outside their control. Not deploying bad ideas is something that is within their control. And if they cannot get comfortable with an idea quickly their reaction is much more likely to be that the designer should get a clue rather than that they should get a clue. If you want them to deploy your stuff you have to be prepared to work with them and provide a mechanism that they can easily understand and be comfortable with. They are the gatekeepers. On Wed, Oct 27, 2010 at 9:40 AM, Phillip Hallam-Baker wrote: > Richard, > > Please keep the conversation civil. > > I am not spreading FUD, I am basing my statements on extensive discussions > with the proposers. > > If they wish to state that they don't want to address security policy then > there is no need for this discussion at all. The charter will simply say > that all the WG does in the first phase is to describe a certificate type > that provides one additional means of validating keys and has no side > effects. > > The only reason for a discussion is that some people want to override the > PKIX semantics and use this to edit the set of trusted CA roots for a zone. > > > > On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes wrote: > >> What Paul is saying is that the proposal does not override PKIX semantics >>> based on CA issuing in a world in which there are no CAs. In the world in >>> which we currently live TLSFP overrides PKIX semantics. If a TLSFP record >>> exists then a client that supports TLSFP is required to ignore the PKIX >>> certificate chain entirely. >>> >> >> The only instance in which TLSFP "overrides" anything about a PKIX cert is >> the following sentence: >> " >> If a TLS client fully trusts the association between a domain name and the >> certificate that was provided by the DNS, then that client MUST ignore the >> domain name that is given in the certificate. >> " >> >> In fact, the draft goes into some detail about the interaction between >> PKIX validation and the assertions that TLSFP provides. >> >> Unless you can point to text in a document that supports what you're >> saying about that document, quit spreading FUD. >> >> --Richard >> > > > > -- > Website: http://hallambaker.com/ > > -- Website: http://hallambaker.com/ --0016e644d6d007118404939b7792 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The point at issue here is the following text in Hoffman-03:

=
=A0=A0 If a match between one of the certificate association(s) a= nd the
=A0=A0 server's end entity certificate in TLS is found= , the TLS client
=A0=A0 continues the TLS handshake. =A0If a match between the certific= ate
=A0=A0 association(s) and the server's end entity certifi= cate in TLS is not
=A0=A0 found, the TLS client MUST abort the ha= ndshake with an
=A0=A0 "access_denied" error.

Now I= have discussed this with the authors on several occasions and at least som= e of them intend this as a mechanism to guard against what they see as the = risk of unauthorized certificate issue by a CA.

This text is buried in section 3. It comes after a pre-= amble that gives no justification for this behavior and no hint that this i= s a primary purpose of the specification.

We can e= nd this discussion now if the proposers are willing to accept:

"If a match between the certificate
=A0=A0 association(s) and the server's end entity c= ertificate in TLS is not
=A0=A0 found,=A0TLS path processing MUST= be performed as if no TLSFP record was published"

At the very minimum, this type of behavior has to be op= tional.=A0


I am quite happy for the= IETF to specify a mechanism to address this particular use case but it is = an aspect of security policy, it is the most difficult aspect of security p= olicy and I do not want to have it conflated with a new mechanism for key v= alidation.=A0

At the very least, any mechanism that has this intent s= hould be clearly and=A0unambiguously=A0specified in the problem statement o= f the RFC. And there has to be a very compelling reason given for addressin= g the two issues together. Saving a DNS round trip is not a compelling reas= on in my view.


There is a great tendency for IETF worki= ng groups to think about the difficulty of implementation and efficiency as= the most important issues. My view is that the most important issue is fun= ctionality and the next most important is usability for the system administ= rator.

We have a whole lot of security infrastructure that rem= ains as shelfware because the typical administrator is not confident that t= hey understand how to configure it correctly. Network admins are busy peopl= e. Their networks break for all sorts of reasons that are outside their con= trol. Not deploying bad ideas is something that is within their control. An= d if they cannot get comfortable with an idea quickly their reaction is muc= h more likely to be that the designer should get a clue rather than that th= ey should get a clue.

If you want them to deploy your stuff you have to be pr= epared to work with them and provide a mechanism that they can easily under= stand and be comfortable with. They are the gatekeepers.


On Wed, Oct 27, 2010 at 9:40 AM, Phill= ip Hallam-Baker <h= allam@gmail.com> wrote:
Richard,

Please keep the conversation civil.
<= br>
I am not spreading FUD, I am basing my statements on extensiv= e discussions with the proposers.=A0

If they wish = to state that they don't want to address security policy then there is = no need for this discussion at all. The charter will simply say that all th= e WG does in the first phase is to describe a certificate type that provide= s one additional means of validating keys and has no side effects.

The only reason for a discussion is that some people wa= nt to override the PKIX semantics and use this to edit the set of trusted C= A roots for a zone.



On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <rbarnes@bbn.com><= /span> wrote:
What Paul is saying is that the proposal does not override PKIX semantics b= ased on CA issuing in a world in which there are no CAs. In the world in wh= ich we currently live TLSFP overrides PKIX semantics. If a TLSFP record exi= sts then a client that supports TLSFP is required to ignore the PKIX certif= icate chain entirely.

The only instance in which TLSFP "overrides" anything about a PKI= X cert is the following sentence:
"
If a TLS client fully trusts the association between a domain name and the = certificate that was provided by the DNS, then that client MUST ignore the = domain name that is given in the certificate.
"

In fact, the draft goes into some detail about the interaction between PKIX= validation and the assertions that TLSFP provides.

Unless you can point to text in a document that supports what you're sa= ying about that document, quit spreading FUD.

--Richard



--
Webs= ite: http://hallambak= er.com/




--
Website: http://hallambaker.com/

--0016e644d6d007118404939b7792-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5CA23A67B2; Wed, 27 Oct 2010 06:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWO3iyNHIgXv; Wed, 27 Oct 2010 06:38:38 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 3A12F3A6A25; Wed, 27 Oct 2010 06:38:38 -0700 (PDT) Received: by gxk7 with SMTP id 7so398815gxk.31 for ; Wed, 27 Oct 2010 06:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/ouforXe39k8AMRZuzLdsYNBClY1pl9Q76l3s4Hk6YY=; b=QxA9UwJYF2DiaiXvB6yBH5jlLlnJTEOv/AWoX8xnsmJYpTfjTg0op1rEYzyDKvy4AT QxgNf/WK41V6unp/WeZupIRAFqK4LNa/lmhWKJvgKI+NHVN98swejIhgWxPw/ZgWJzzV OvE4E+S1ONo6y4p57dvfOqLxDOEcducslth0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KxTkAOjcVoLvfh6eGNiiqIzU9VNZmkHHLmaz6m3oo3Tn3/xdb936Xeg7g1HS9e9NFX BTkKEaF18ro0BM48+t+lpzfOa9murPk573hojhfRkqRiBn7VBx3XiTlnI92tcDDYfOvj qALX1CadmQgPO3cYgMW+CvJDiQ8TsSQQtHmFA= MIME-Version: 1.0 Received: by 10.101.105.20 with SMTP id h20mr7958556anm.196.1288186827391; Wed, 27 Oct 2010 06:40:27 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 06:40:27 -0700 (PDT) In-Reply-To: <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> Date: Wed, 27 Oct 2010 09:40:27 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=001636c92c424041b10493995ed7 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:38:43 -0000 --001636c92c424041b10493995ed7 Content-Type: text/plain; charset=ISO-8859-1 Richard, Please keep the conversation civil. I am not spreading FUD, I am basing my statements on extensive discussions with the proposers. If they wish to state that they don't want to address security policy then there is no need for this discussion at all. The charter will simply say that all the WG does in the first phase is to describe a certificate type that provides one additional means of validating keys and has no side effects. The only reason for a discussion is that some people want to override the PKIX semantics and use this to edit the set of trusted CA roots for a zone. On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes wrote: > What Paul is saying is that the proposal does not override PKIX semantics >> based on CA issuing in a world in which there are no CAs. In the world in >> which we currently live TLSFP overrides PKIX semantics. If a TLSFP record >> exists then a client that supports TLSFP is required to ignore the PKIX >> certificate chain entirely. >> > > The only instance in which TLSFP "overrides" anything about a PKIX cert is > the following sentence: > " > If a TLS client fully trusts the association between a domain name and the > certificate that was provided by the DNS, then that client MUST ignore the > domain name that is given in the certificate. > " > > In fact, the draft goes into some detail about the interaction between PKIX > validation and the assertions that TLSFP provides. > > Unless you can point to text in a document that supports what you're saying > about that document, quit spreading FUD. > > --Richard > -- Website: http://hallambaker.com/ --001636c92c424041b10493995ed7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Richard,

Please keep the conversation civil.
<= br>
I am not spreading FUD, I am basing my statements on extensiv= e discussions with the proposers.=A0

If they wish = to state that they don't want to address security policy then there is = no need for this discussion at all. The charter will simply say that all th= e WG does in the first phase is to describe a certificate type that provide= s one additional means of validating keys and has no side effects.

The only reason for a discussion is that some people wa= nt to override the PKIX semantics and use this to edit the set of trusted C= A roots for a zone.



On Wed, Oct 27, 2010 at 9:33 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
What Paul is saying is that the proposal does not override PKIX semantics b= ased on CA issuing in a world in which there are no CAs. In the world in wh= ich we currently live TLSFP overrides PKIX semantics. If a TLSFP record exi= sts then a client that supports TLSFP is required to ignore the PKIX certif= icate chain entirely.

The only instance in which TLSFP "overrides" anything about a PKI= X cert is the following sentence:
"
If a TLS client fully trusts the association between a domain name and the = certificate that was provided by the DNS, then that client MUST ignore the = domain name that is given in the certificate.
"

In fact, the draft goes into some detail about the interaction between PKIX= validation and the assertions that TLSFP provides.

Unless you can point to text in a document that supports what you're sa= ying about that document, quit spreading FUD.

--Richard



--
Website: http://hallambaker.com/

--001636c92c424041b10493995ed7-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8523C3A67FB; Wed, 27 Oct 2010 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faftkeBiXhGf; Wed, 27 Oct 2010 06:31:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3817A3A67B2; Wed, 27 Oct 2010 06:31:46 -0700 (PDT) Received: from [128.89.253.83] (port=52742 helo=[10.45.1.190]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PB68F-000Owe-QM; Wed, 27 Oct 2010 09:33:35 -0400 Message-Id: <25BC19E8-FE42-4DA4-915A-4A7ABCE4C40D@bbn.com> From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Oct 2010 09:33:35 -0400 References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:31:47 -0000 > What Paul is saying is that the proposal does not override PKIX > semantics based on CA issuing in a world in which there are no CAs. > In the world in which we currently live TLSFP overrides PKIX > semantics. If a TLSFP record exists then a client that supports > TLSFP is required to ignore the PKIX certificate chain entirely. The only instance in which TLSFP "overrides" anything about a PKIX cert is the following sentence: " If a TLS client fully trusts the association between a domain name and the certificate that was provided by the DNS, then that client MUST ignore the domain name that is given in the certificate. " In fact, the draft goes into some detail about the interaction between PKIX validation and the assertions that TLSFP provides. Unless you can point to text in a document that supports what you're saying about that document, quit spreading FUD. --Richard Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DDCF3A6953; Wed, 27 Oct 2010 06:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCfj8cfeZ-Eq; Wed, 27 Oct 2010 06:22:30 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A21643A67FB; Wed, 27 Oct 2010 06:22:29 -0700 (PDT) Received: by ywp6 with SMTP id 6so383768ywp.31 for ; Wed, 27 Oct 2010 06:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=608R6W1pe93NFYu1EnyoB1mMqHaSpj5w8AzrFPppTes=; b=wArbR3TNq4GftU4vsqx0wINz0fsPHdM4Fr7HThdEowNrlynRs8rASNUVTtbh6TEeh/ RvktVTEnZDURcZYZ21QzFK/cN1knwWraN0CLdG0q17DbYmLIPoHGXtqKGviRh6TwG7LJ I/lORXBwxLLPXathMT/ZxUf+bfx4QUUJWpprw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=coa8VOVbsaDbWB0A+xJ6dpVTHzlyPr0eedmPJzboVYIAe6piovGmbqaUcDTotsQ82G XcqyCSaWyqgv/08mujea5Yj4B9k+fYxGDZF302PfimG+aXO8SCNsrlbbCNlY3c9I01RJ c1KtgQqpRKkcMmen3wzBFyzZTD8np9fwJj1Ug= MIME-Version: 1.0 Received: by 10.100.10.20 with SMTP id 20mr6225786anj.264.1288185856968; Wed, 27 Oct 2010 06:24:16 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 06:24:16 -0700 (PDT) In-Reply-To: <4CC7E1F7.2090303@nic.cz> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC7E1F7.2090303@nic.cz> Date: Wed, 27 Oct 2010 09:24:16 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016e647132a68c76604939924a2 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:22:32 -0000 --0016e647132a68c76604939924a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 4:25 AM, Ond=C5=99ej Sur=C3=BD = wrote: > [Replying to Phillip and Paul simultaneously] > > > On 27.10.2010 02:06, Paul Wouters wrote: > >> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote: >> >>> In particular the TLSFP scheme defines a path validation algorithm >>> that overrides the standard PKIX processing mechanism in two >>> ways. >>> >> >> Not override, alternative. Depending on client policy. Image systems >> with no CA's. >> > > True. Not true at all. What Paul is saying is that the proposal does not override PKIX semantics based on CA issuing in a world in which there are no CAs. In the world in which we currently live TLSFP overrides PKIX semantics. If a TLSFP record exists then a client that supports TLSFP is required to ignore the PKIX certificate chain entirely. > Secondly, there is an assumption in TLSFP that any domain that >>> publishes CERT records of TLSFP certificate type will publish TLSFP >>> records for ALL valid SSL certs in use for the domain. >>> >> > Just a note: There is no such assumption in the charter. This is just > one particular I-D. Which is precisely the sort of issue that is relevant to a charter discussion with the IESG. This is security policy by side effect. I think that is the worst possible way to go about the security policy problem. I think we can develop a practical security policy scheme based on direct security policy assertions 'SMTP at example.com always uses TLS'. But doing this through side effects is looking for trouble. > So the publication of a TLSFP record to enable secure >>> communication on the mail server will cause the SSL certificate on >>> the Web server to be considered invalid. >>> >> >> I don't see that. The browser and its CA policy installation can >> still ignore TLSFP. In fact, I strongly suspect they will in at least >> the near future. >> > The publishers of a TLSFP record cannot assume that the security policy sid= e effects are going to be ignored. Presenting this as a client side choice is nonsense. I want to be able to publish TLSFP records for my mail server on example.comwithout affecting the operation of my web server on example.com in any way whatsoever. I want to have a means of publishing keys using the DNSSEC that is side effect free. > And I don't see that as a problem anyway. The scope of this proposed WG > is to link domain names to certificates. As stated by Stephane in other > thread in keyassure list, newer protocols generally use (or can use) SRV > record to distinguish between different services. It will take some > effort on the sysadmin side to make the TLSFP work as intended, but > setting up security was never painless. This is not a responsible approach to security configuration. The reason I want to have side effect free specifications is that I want to be able to automate these processes. A specification that makes automated systems management should be rejected out of hand at this point. This is what architecture is all about. There is no necessity for conjoining these two features other than that the proposers think that they would like to avoid some DNS round trips and are not prepared to use a completely new DNS RR. > I find this proposal troubling for several reasons. First it lacks >>> >>> orthogonality. It should be able to use the DNSSEC to establish >>> additional keys without affecting existing trust systems in any way >>> whatsoever. >>> >> > I don't understand why it should? You can decide if you want to use DNSS= EC > or not. You can decide if you want to use TLSFP or not. It's up to each > domain holder if he will use this mechanism or not. Because scripts are stupider than rocks. Separation of concerns is essential if these processes are going to be automated. The number of competent systems managers who can deploy DNSSEC is not very large. Training is hugely expensive. It is going to take a significant amount of time to do the job right. I can't see how it is going to be possible for the typical enterprise to deploy DNSSEC in house and those tha= t do should probably expect to spend $100K+. The only way any of this makes sense to me from a cost point of view is if the process is outsourced and those costs are amortized over a huge number of instances. >> The existence of a TLSFP record could mean "always use TLS". The WG >> is going to discuss whether or not to use bits for these things in >> the coming months. I would also like to see more policy options >> there, such as "only connect anonymous", or a policy where it is >> clear if the server does any kind of authentication, or whether it >> will allow a BTNS type security policy without client >> authentication. >> > > Yes, I think our proposed charter allows that. That is precisely the question the IESG needs to decide. I want to do security policy. I think that DNSSEC only makes sense if it ca= n be used for security policy. But any security policy mechanism that is done has to be a first order feature and not implemented by diddling with a few bits buried in a subfield encoding of a BASE64 encoded blob. My understanding is that this was discussed in the keyassure before and the > charter was built upon rough consensus. I don't think it's necessary to > reiterate through all this again on IESG list. As you said in your previous message, shouldn't you let the IESG speak for itself here? This type of issue is precisely what the IESG needs to be considering. Because if they do not discuss it now they are going to DISCUSS the drafts later and there is a serious risk that we waste several years work. The current IESG is not necessarily going to be the one that reviews the specifications. Absent a clear and unambiguous statement from the IESG that security policy work is in scope of the charter there is a risk that a future IESG is going to kick back. --=20 Website: http://hallambaker.com/ --0016e647132a68c76604939924a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 27, 2010 at 4:25 AM, Ond=C5= =99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:


On 27.10.2010 02:06, Paul Wouters wrote:
On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:
In particular the TLSFP scheme defines a path validation algorithm
=C2=A0that overrides the standard PKIX processing mechanism in two
ways.

Not override, alternative. Depending on client policy. Image systems
=C2=A0with no CA's.

True.

Not true at all.=C2=A0

What Paul is saying is that the proposal does not o= verride PKIX semantics based on CA issuing in a world in which there are no= CAs. In the world in which we currently live TLSFP overrides PKIX semantic= s. If a TLSFP record exists then a client that supports TLSFP is required t= o ignore the PKIX certificate chain entirely.



Secondly, there is an assumption in TLSFP that any domain that
publishes CERT records of TLSFP certificate type will publish TLSFP
records for ALL valid SSL certs in use for the domain.

Just a note: =C2=A0There is no such assumption in the charter. =C2=A0This i= s just
one particular I-D.

Which is precisely the sort of issue that is relevant = to a charter discussion with the IESG.=C2=A0

This is security policy by side effect. I = think that is the worst possible way to go about the security policy proble= m. I think we can develop a practical security policy scheme based on direc= t security policy assertions 'SMTP at ex= ample.com always uses TLS'. But doing this through side effects is = looking for trouble.



So the publication of a TLSFP record to enable secure
communication on the mail server will cause the SSL certificate on
the Web server to be considered invalid.

I don't see that. The browser and its CA policy installation can
still ignore TLSFP. In fact, I strongly suspect they will in at least
the near future.

The= publishers of a TLSFP record cannot assume that the security policy side e= ffects are going to be ignored.=C2=A0

Presenting t= his as a client side choice is nonsense.

I want to be able to publish TLSFP records for my mail = server on example.com without affecting = the operation of my web server on example.co= m in any way whatsoever.

I want to have a means of publishing keys using the DNS= SEC that is side effect free.
=C2=A0
And I don't see that as a problem anyway. =C2=A0The scope of this propo= sed WG
is to link domain names to certificates. =C2=A0As stated by Stephane in oth= er
thread in keyassure list, newer protocols generally use (or can use) SRV record to distinguish between different services. =C2=A0It will take some effort on the sysadmin side to make the TLSFP work as intended, but
setting up security was never painless. =C2=A0

<= div>This is not a responsible approach to security configuration.
The reason I want to have side effect free specifications i= s that I want to be able to automate these processes. A specification that = makes automated systems management should be rejected out of hand at this p= oint.

This is what architecture is all about.=C2=A0

There is no necessity for conjoining these two features oth= er than that the proposers think that they would like to avoid some DNS rou= nd trips and are not prepared to use a completely new DNS RR.


I find this proposal troubling for several reasons. First it lacks

orthogonality. It should be able to use the DNSSEC to establish
additional keys without affecting existing trust systems in any way
whatsoever.

I don't understand why it should? =C2=A0You can decide if you want to u= se DNSSEC or not. =C2=A0You can decide if you want to use TLSFP or not. =C2= =A0It's up to each domain holder if he will use this mechanism or not.<= /blockquote>

Because scr= ipts are stupider than rocks.

Separation of concerns is essential if these proces= ses are going to be automated.

The number = of competent systems managers who can deploy DNSSEC is not very large. Trai= ning is hugely expensive. It is going to take a significant amount of time = to do the job right. I can't see how it is going to be possible for the= typical enterprise to deploy DNSSEC in house and those that do should prob= ably expect to spend $100K+.

The only wa= y any of this makes sense to me from a cost point of view is if the process= is outsourced and those costs are amortized over a huge number of instance= s.=C2=A0


The existence of a TLSFP record could mean "always use TLS". The = WG
is going to discuss whether or not to use bits for these things in
the coming months. I would also like to see more policy options
there, such as "only connect anonymous", or a policy where it is<= br> clear if the server does any kind of authentication, or whether it
will allow a BTNS type security policy without client
authentication.

Yes, I think our proposed charter allows that.

That is precisely the quest= ion the IESG needs to decide.

I want to do security policy. I think that DNSSEC only makes sense if it ca= n be used for security policy. But any security policy mechanism that is do= ne has to be a first order feature and not implemented by diddling with a f= ew bits buried in a subfield encoding of a BASE64 encoded blob.

My understanding is that this was discussed in the keyassure before and the= charter was built upon rough consensus. =C2=A0I don't think it's n= ecessary to reiterate through all this again on IESG list.

As you said in your previous message, shouldn't you= let the IESG speak for itself here?

This type of issue is precise= ly what the IESG needs to be considering. Because if they do not discuss it= now they are going to DISCUSS the drafts later and there is a serious risk= that we waste several years work.

The current IESG is not necessarily going to be the one that= reviews the specifications. Absent a clear and unambiguous statement from = the IESG that security policy work is in scope of the charter there is a ri= sk that a future IESG is going to kick back.=C2=A0

--
Website: http://hallambaker.= com/

--0016e647132a68c76604939924a2-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36313A6A20; Wed, 27 Oct 2010 06:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8DLoetWDo9a; Wed, 27 Oct 2010 06:20:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id BF41E3A67FB; Wed, 27 Oct 2010 06:20:26 -0700 (PDT) Received: from [128.89.253.83] (port=52719 helo=[10.45.1.190]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PB5xI-000OnI-7O; Wed, 27 Oct 2010 09:22:16 -0400 Message-Id: <907C86A3-C332-4B11-8230-2003E08B0DAE@bbn.com> From: "Richard L. Barnes" To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4CC82275.8010809@nic.cz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Oct 2010 09:22:14 -0400 References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027114125.GW45134@shinkuro.com> <4CC81B30.5020801@gmail.com> <20101027125343.GJ45134@shinkuro.com> <4CC82275.8010809@nic.cz> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:20:28 -0000 >>> If this is really a happy group of like-minded people, it should >>> be easy >>> to cut-and-paste the charter, as well as your and Stephane's >>> clarifications into a Problem Statement I-D, and get it published >>> soon >>> after the working group is formed. It need not block the work on the >>> technical solution. >> >> That sounds like a fine approach to me. The charter could be amended >> to require a problem statement I-D at the beginning. > > Sounds fine to me. Any other comments from other interested people? I won't object very strongly to a problem statement I-D, but I don't think one is really necessary. --Richard Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5063A694A; Wed, 27 Oct 2010 05:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vX3XxDnJybc; Wed, 27 Oct 2010 05:58:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 851F03A686D; Wed, 27 Oct 2010 05:58:50 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id D2306734385; Wed, 27 Oct 2010 15:00:37 +0200 (CEST) Message-ID: <4CC82275.8010809@nic.cz> Date: Wed, 27 Oct 2010 15:00:37 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: keyassure@ietf.org, iesg@ietf.org, Warren Kumari References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027114125.GW45134@shinkuro.com> <4CC81B30.5020801@gmail.com> <20101027125343.GJ45134@shinkuro.com> In-Reply-To: <20101027125343.GJ45134@shinkuro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:58:52 -0000 On 27.10.2010 14:53, Andrew Sullivan wrote: > On Wed, Oct 27, 2010 at 02:29:36PM +0200, Yaron Sheffer wrote: >> >> My intention is not to add bureaucratic hurdles. It is to ensure that >> the group has reasonable consensus about its goals. I get worried when I >> see indecision about requirements/goals trickle into the technical spec, > > Yes, on this we fully agree. > >> If this is really a happy group of like-minded people, it should be easy >> to cut-and-paste the charter, as well as your and Stephane's >> clarifications into a Problem Statement I-D, and get it published soon >> after the working group is formed. It need not block the work on the >> technical solution. > > That sounds like a fine approach to me. The charter could be amended > to require a problem statement I-D at the beginning. Sounds fine to me. Any other comments from other interested people? Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CD133A69F9; Wed, 27 Oct 2010 05:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E3k+MY4E5he; Wed, 27 Oct 2010 05:51:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 24F193A69F4; Wed, 27 Oct 2010 05:51:57 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EA4191ECB408; Wed, 27 Oct 2010 12:53:45 +0000 (UTC) Date: Wed, 27 Oct 2010 08:53:44 -0400 From: Andrew Sullivan To: Yaron Sheffer Message-ID: <20101027125343.GJ45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027114125.GW45134@shinkuro.com> <4CC81B30.5020801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC81B30.5020801@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:51:58 -0000 On Wed, Oct 27, 2010 at 02:29:36PM +0200, Yaron Sheffer wrote: > > My intention is not to add bureaucratic hurdles. It is to ensure that > the group has reasonable consensus about its goals. I get worried when I > see indecision about requirements/goals trickle into the technical spec, Yes, on this we fully agree. > If this is really a happy group of like-minded people, it should be easy > to cut-and-paste the charter, as well as your and Stephane's > clarifications into a Problem Statement I-D, and get it published soon > after the working group is formed. It need not block the work on the > technical solution. That sounds like a fine approach to me. The charter could be amended to require a problem statement I-D at the beginning. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19983A6907; Wed, 27 Oct 2010 05:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+rrSqataH-P; Wed, 27 Oct 2010 05:34:22 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1DDDE3A68A0; Wed, 27 Oct 2010 05:34:22 -0700 (PDT) Received: by gwb15 with SMTP id 15so346608gwb.31 for ; Wed, 27 Oct 2010 05:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=t1Vx3VB410oP/y/uBWpsjv2nnyz6WXEck/oHxb26NC8=; b=J7IJplB37GQ2fXQo7yZh4sHpjxyP/NbbPVxkcQOEZtQMPesrakh0XWrsbo/C7m22kK QP3t26HNEiqOkxzX+nIrzseVUrplTPj1uF1P4JqbqHIQffyDDbFdpU1sAODEldZw5Ldj o0ZeviFcmT1zivEfoxEw0LKibDiyCrE2EE5SA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZT/S63hkylWc/KcfO4YSjhnGszTiupUqWuoPY5tKriTpLcjwkvZG/EeKynpNIu5npz qi7ueQvB8UH+GrTzjeFs9qjoMwH1yPLyF7iiE6om1Zj47bOvKR9HRbXPWYaPEe9A8i+p mahRtzFk0yVlmvAojFPdzgSMALuInO7n8YmYU= MIME-Version: 1.0 Received: by 10.100.121.14 with SMTP id t14mr3685912anc.109.1288182971037; Wed, 27 Oct 2010 05:36:11 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Wed, 27 Oct 2010 05:36:10 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Wed, 27 Oct 2010 08:36:10 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=0016e644cf6c6506a504939878e7 Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:34:24 -0000 --0016e644cf6c6506a504939878e7 Content-Type: text/plain; charset=ISO-8859-1 Security policy is generally understood to mean anything that was addressed in Matt Blaze's PolicyMaker scheme. Thus PKI trust chaining is excluded because it existed prior to PolicyMaker. Statements of the form 'always use SSL' or 'only trust these roots' are considered to be security policy statements. But whatever they are called, the problem is considered to be very difficult. In particular the problem of telling relying parties that they should only trust specific roots or certs for a domain is considered very difficult. What is being proposed here is not simply a matter of 'client choice'. If there are any clients out there that make security policy decisions based on the existence of TLSFP records then these must be explicit to the domains publishing the records. Otherwise we end up with a massive interoperability failure. I want to be able to publish a TLSFP certificate for my mail server (SMTP and IMAP) without affecting my Web server. That is not going to be possible if there is even one client out there that sees a TLSFP record and decides to reject a perfectly good certificate path as a result or worse decides that it is not going to connect to my Web server that does not have TLS and was never intended to. As for the idea that 'nobody is proposing this'. Paul Wooters just suggested doing exactly that and the TLSFP code does exactly that. On Wed, Oct 27, 2010 at 7:45 AM, Richard L. Barnes wrote: > Phillip, > > Nothing in this proposal creates security policy. It creates inputs for > things that go into security policy. All that the proposed records do is > provide another input into the client's *internal* process for deciding > whether a credential is tied to a particular domain. Clients are free to > validate or not validate certificates as they choose. Please stop trying to > reinforce the misconception that the proposed mechanism overrides PKIX > validation in any way. > > --Richard > > > > On Oct 26, 2010, at 9:03 PM, Phillip Hallam-Baker wrote: > > Since this is a charter discussion, it goes to the IESG. > > My point is not that the IETF should not address Security Policy, it is > that any security mechanism should be completely independent of defining a > new and additional mechanism to sign public keys. > > It should be able for a domain to publish public keys in the DNS without > impact on existing deployed SSL certificates and it should be possible for a > domain to publish security policy constraining trusted keys without having > to do so by publishing their keys in the DNS. > > If the policy of a site is that every certificate is issued off a local CA > root that is cross certified to a public root, it should suffice to state > that every valid cert is issued of the local CA root. > > > My reason for wanting this distinction is twofold. First I believe it is a > matter of sound architectural practice to separate the two issued, Secondly > I believe that the IAB and IESG are going to insist on this distinction. > > The worst outcome here would be for the WG to be chartered with an > ambiguous remit, spend a year or two working on the issue and then produce a > proposal that is thrown out by the IESG because they insist that the two > issues be kept separate. > > The second worse outcome is to be kicked back with a request to define the > problem we are trying to solve. I think that process is going to take longer > than solving the key signing problem. We really do understand the key > signing problem very well. > > > We have done mechanisms for signing keys before. It is a well constrained > problem. I think that having a mechanism for signing keys on the basis of > DNSSEC is a worthwhile achievement on its own. We should be able to knock > that one off in about six months. Then we can approach the IESG and invoke > the pinball rule under RFC 2418 sec 4: If you win you get to play again. > > By that time, I hope that we have some results to show with CAA which > addresses a very limited aspect of security policy that does not affect the > client. Based on the feedback I have had so far from targeted domains and > from CAs, that looks like a win-win. > > So at that time I think we can expect to be able to go back to the IESG and > tell them that we want to do security policy and that we are pretty sure > that we understand the issues involved and can produce a nicely abstracted > platform that has strong separation of concerns and reduces the entropy in > the Internet architecture rather than further increasing it.. > > > > On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters wrote: > >> On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote: >> >> [not sure if such a broad CC: is warranted] >> >> >> I think that this mechanism is entirely logical and useful. DNSSEC is >>> entirely adequate for the purpose of establishing >>> a key as being sufficient to enable use of encryption. >>> >>> The second set of proposals relates to security policy. >>> >> >> the first is a security policy as well. >> >> >> In particular the TLSFP scheme defines a path validation >>> algorithm that overrides the standard PKIX processing mechanism in two >>> ways. >>> >> >> Not override, alternative. Depending on client policy. Image systems with >> no CA's. >> >> >> Secondly, there is an assumption in TLSFP that any domain that publishes >>> CERT records of TLSFP certificate type will >>> publish TLSFP records for ALL valid SSL certs in use for the domain. So >>> the publication of a TLSFP record to enable >>> secure communication on the mail server will cause the SSL certificate on >>> the Web server to be considered invalid. >>> >> >> I don't see that. The browser and its CA policy installation can still >> ignore TLSFP. In fact, I strongly >> suspect they will in at least the near future. >> >> >> I find this proposal troubling for severalreasons. First it lacks >>> orthogonality. It should be able to use the DNSSEC to >>> establish additional keys without affecting existing trust systems in any >>> way whatsoever. >>> >> >> It does. Its an addon a client can decide to use or not use. >> >> >> I dislike >>> any mechanism that requires the administrator to perform configuration in >>> the DNS for each and every SSL certificate as >>> it is issued. >>> >> >> I dislike needing to delete so many untrusted omnipotent CA's from my >> browser. But our personal dislikes are irrelevant to protocol design. >> >> >> Thirdly, the percentage of Internet traffic that is encrypted today is >>> negligible. I think that we should make >>> encouraging the use of encryption a higher priority than correcting what >>> some people see as flaws in the trust provision >>> for existing sites. The security policy that has the highest leverage is >>> statements of the form 'always use TLS'. >>> >> >> The existence of a TLSFP record could mean "always use TLS". The WG is >> going to discuss whether or not to use >> bits for these things in the coming months. I would also like to see more >> policy options there, such as "only >> connect anonymous", or a policy where it is clear if the server does any >> kind of authentication, or whether it >> will allow a BTNS type security policy without client authentication. >> >> >> What worries me here is the that the WG should decide to address a single >>> aspect of security policy, address that aspect >>> from a single point of view and then optimize for that single scope. >>> >> >> Let's cut the chase here. It's independant of CA's. Yes. It's an >> alternative. Yes. Your worry has been noted. Again. >> You can ensure browser vendors are aware of these limitations in respect >> to deploying CA's, and recommend >> what they implement and support. But there is no reason to try and stop a >> protocol development that does not >> rely on the currently deployed CA infrastructure - an infrastructure some >> people have lost faith in, with good >> reason. >> >> Paul >> > > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > -- Website: http://hallambaker.com/ --0016e644cf6c6506a504939878e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Security policy is generally understood to mean anything that was addr= essed in Matt Blaze's PolicyMaker scheme. Thus PKI trust chaining is ex= cluded because it existed prior to PolicyMaker.

Statements of the form 'always use SSL' or 'only trust these ro= ots' are considered to be security policy statements.

But whatever they are called, the problem is considered to be very = difficult. In particular the problem of telling relying parties that they s= hould only trust specific roots or certs for a domain is considered very di= fficult.


What is being proposed here is not simpl= y a matter of 'client choice'.

If there ar= e any clients out there that make security policy decisions based on the ex= istence of TLSFP records then these must be explicit to the domains publish= ing the records. Otherwise we end up with a massive interoperability failur= e.

I want to be able to publish a TLSFP certificate for my= mail server (SMTP and IMAP) without affecting my Web server.
That is not going to be possible if there is even one client ou= t there that sees a TLSFP record and decides to reject a perfectly good cer= tificate path as a result or worse decides that it is not going to connect = to my Web server that does not have TLS and was never intended to.


As for the idea that 'nobody is prop= osing this'. Paul Wooters just suggested doing exactly that and the TLS= FP code does exactly that.


On = Wed, Oct 27, 2010 at 7:45 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
Phillip= ,

Nothing in this proposal creates security policy. =A0I= t creates inputs for things that go into security policy. =A0All that the p= roposed records do is provide another input into the client's *internal= * process for deciding whether a credential is tied to a particular domain.= =A0Clients are free to validate or not validate certificates as they choos= e. =A0Please stop trying to reinforce the misconception that the proposed m= echanism overrides PKIX validation in any way. =A0

--Richard



<= div>
On Oct 26, 2010, at 9:03 PM, Phi= llip Hallam-Baker wrote:

Since this is a charter discussion, it goes to= the IESG.

My point is not that the IETF should not addr= ess Security Policy, it is that any security mechanism should be completely= independent of defining a new and additional mechanism to sign public keys= .

It should be able for a domain to publish public keys = in the DNS without impact on existing deployed SSL certificates and it shou= ld be possible for a domain to publish security policy constraining trusted= keys without having to do so by publishing their keys in the DNS.

If the policy of a site is that every certificate is i= ssued off a local CA root that is cross certified to a public root, it shou= ld suffice to state that every valid cert is issued of the local CA root.


My reason for wanting this distinction = is twofold. First I believe it is a matter of sound architectural practice = to separate the two issued, Secondly I believe that the IAB and IESG are go= ing to insist on this distinction.

The worst outcome here would be for the WG to be chart= ered with an ambiguous remit, spend a year or two working on the issue and = then produce a proposal that is thrown out by the IESG because they insist = that the two issues be kept separate.

The second worse outcome is to be kicked back with a r= equest to define the problem we are trying to solve. I think that process i= s going to take longer than solving the key signing problem. We really do u= nderstand the key signing problem very well.


We have done mechanisms for signing key= s before. It is a well constrained problem. I think that having a mechanism= for signing keys on the basis of DNSSEC is a worthwhile achievement on its= own. We should be able to knock that one off in about six months. Then we = can approach the IESG and invoke the pinball rule under RFC 2418 sec 4: If = you win you get to play again.

By that time, I hope that we have some results to show with= CAA which addresses a very limited aspect of security policy that does not= affect the client. Based on the feedback I have had so far from targeted d= omains and from CAs, that looks like a win-win.

So at that time I think we can expect to be able to go= back to the IESG and tell them that we want to do security policy and that= we are pretty sure that we understand the issues involved and can produce = a nicely abstracted platform that has strong separation of concerns and red= uces the entropy in the Internet architecture rather than further increasin= g it..



On Tue, = Oct 26, 2010 at 8:06 PM, Paul Wouters <paul@xelerance.com> = wrote:
On Tue, 26 Oct 2010, Phillip Hallam-Baker w= rote:

[not sure if such a broad CC: is warranted]


I think that this mechanism is entirely logical and useful. DNSSEC is enti= rely adequate for the purpose of establishing
a key as being sufficient= to enable use of encryption.=A0

The second set of proposals relat= es to security policy.

the first is a security policy as well.

=
In particular the TLSFP scheme defines= a path validation
algorithm that overrides the standard PKIX processing mechanism in two way= s.

Not override, alternative. Depending on cli= ent policy. Image systems with no CA's.


Secondly, there is an assumption in TLSFP that any domain that publishes C= ERT records of TLSFP certificate type will
publish TLSFP records for AL= L valid SSL certs in use for the domain. So the publication of a TLSFP reco= rd to enable
secure communication on the mail server will cause the SSL certificate on = the Web server to be considered invalid.

I don= 't see that. The browser and its CA policy installation can still ignor= e TLSFP. In fact, I strongly
suspect they will in at least the near future.


I find this proposal troubling for severalreasons. First= it lacks orthogonality. It should be able to use the DNSSEC to
establish additional keys without affecting existing trust systems in any = way whatsoever.

It does. Its an addon a client= can decide to use or not use.


I dislike
any mechanism that requires the administrator to perform con= figuration in the DNS for each and every SSL certificate as
it is issue= d.

I dislike needing to delete so many untrust= ed omnipotent CA's from my
browser. But our personal dislikes are irrelevant to protocol design.
=

Thirdly, the percentage of Intern= et traffic that is encrypted today is negligible. I think that we should ma= ke
encouraging the use of encryption a higher priority than correcting what s= ome people see as flaws in the trust provision
for existing sites. The = security policy that has the highest leverage is statements of the form = 9;always use TLS'.

The existence of a TLSFP record could mean "= always use TLS". The WG is going to discuss whether or not to use
= bits for these things in the coming months. I would also like to see more p= olicy options there, such as "only
connect anonymous", or a policy where it is clear if the server does = any kind of authentication, or whether it
will allow a BTNS type securi= ty policy without client authentication.


What worries me here is the that the WG should decide to address a single = aspect of security policy, address that aspect
from a single point of v= iew and then optimize for that single scope.

Let's cut the chase here. It's independant of CA's. Yes. It= 9;s an alternative. Yes. Your worry has been noted. Again.
You can ensu= re browser vendors are aware of these limitations in respect to deploying C= A's, and recommend
what they implement and support. But there is no reason to try and stop a = protocol development that does not
rely on the currently deployed CA in= frastructure - an infrastructure some people have lost faith in, with good<= br> reason.

Paul



--
Website: http://hallambaker.com/

_______________________________________________
keyassure mailing list<= br>keyassure@ietf.o= rg
https://www.ietf.org/mailman/listinfo/keyassure




--
Website: http://hal= lambaker.com/

--0016e644cf6c6506a504939878e7-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4363A68A0; Wed, 27 Oct 2010 05:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.782 X-Spam-Level: X-Spam-Status: No, score=-101.782 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj8q0I2fKDxg; Wed, 27 Oct 2010 05:27:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D3C673A67CF; Wed, 27 Oct 2010 05:27:52 -0700 (PDT) Received: by wyb28 with SMTP id 28so624445wyb.31 for ; Wed, 27 Oct 2010 05:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=15EmXk7F3gScWrZmTWmeY+eeEY9uy55MswSiIPAvAvg=; b=ve4/wqiUlMl7/zwHc9EP+tgrB/F2V8blBI/vO4J+6MLNHdJZjJISxb95qnwMGbTgpI kMsBnc0acSKEpk0xvIKUOiN7/jQSeED8apxYYtFivXF0FFZ8b5+OR5hV5zteUeHljBRy dY7eFJyIfzvoNJIrhUStV+bx0qV2RUmFZbfLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=K+bnAZ9rwnDbyt5AY5HNvuxO+NkJBNVvbhW7go2AabbZ+ybXVm1/F3pJP1ijTK2B3K RDasoZWWmkH+o/hRIECigdW8LH6eJUjboS7+Mbni3XPuNRQx4vNmaQ/rk20qzdXJAT/c 5g1v/DVq6rSXy+9jK8e7IBAq5Ek4Z+Q3vmLuc= Received: by 10.227.155.66 with SMTP id r2mr8989946wbw.116.1288182581961; Wed, 27 Oct 2010 05:29:41 -0700 (PDT) Received: from [10.0.0.8] ([109.65.249.170]) by mx.google.com with ESMTPS id ga16sm7881115wbb.7.2010.10.27.05.29.38 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 05:29:40 -0700 (PDT) Message-ID: <4CC81B30.5020801@gmail.com> Date: Wed, 27 Oct 2010 14:29:36 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Andrew Sullivan References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027114125.GW45134@shinkuro.com> In-Reply-To: <20101027114125.GW45134@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 12:27:54 -0000 Hi Andrew, I must be doing something right, if I'm coming out on the side of the bad guys :-) My intention is not to add bureaucratic hurdles. It is to ensure that the group has reasonable consensus about its goals. I get worried when I see indecision about requirements/goals trickle into the technical spec, as I demonstrated in my earlier mail. If this is really a happy group of like-minded people, it should be easy to cut-and-paste the charter, as well as your and Stephane's clarifications into a Problem Statement I-D, and get it published soon after the working group is formed. It need not block the work on the technical solution. Thanks, Yaron On 10/27/2010 01:41 PM, Andrew Sullivan wrote: > On Tue, Oct 26, 2010 at 10:44:23PM +0200, Yaron Sheffer wrote: >> I believe it is too early to form a working group for kidns. >> >> The group has not produced a problem statement, nor is one proposed in >> the draft charter. While in most cases you can hide a problem statement >> in the first section or two of an RFC, in this case it is essential that >> the usage scenarios be hashed out before the technical solutions are >> discussed. > > With respect, it seems to me that such a reaction is exactly why > people give up on doing work at the IETF: the bureaucratic hurdles to > completing the job that get thrown up make people go away in > frustration. > > We have a community of interested people. We have a reasonably clear > idea of the initial goal of the work. We have different and competing > proposals for how to get that work done. We also have some sceptics > who want to take a completely different approach. We have people > committed to doing review. We have a proposed charter with measurable > deliverables. This sounds to me like a community that has coalesced > around a problem and is ready to do the work. To me, that means we > already _have_ a working group (i.e. a group of people doing work), > and the question is merely whether the IETF machinery acknowledges it. > > I'm not opposed to altering the charter to say, "This work allows > sites to publish keys in the DNS and for clients to use those key > securely without any validation infrastructure apart from DNSSEC," or > something like that. But I don't believe we need to discuss more > whether there is work to do, whether it can be done in a reasonable > time, or whether there is a community to do that work (all the things > a BOF would determine). We have ample demonstration, I think. > > A > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8393A6905; Wed, 27 Oct 2010 04:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKqSeMLolFsq; Wed, 27 Oct 2010 04:43:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5FE1A3A693B; Wed, 27 Oct 2010 04:43:16 -0700 (PDT) Received: from [128.89.253.125] (port=52577 helo=[192.168.1.15]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PB4RE-0004tC-D6; Wed, 27 Oct 2010 07:45:05 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2-635056657 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Oct 2010 07:45:01 -0400 References: <20101026170002.14A8C3A6992@core3.amsl.com> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:43:20 -0000 --Apple-Mail-2-635056657 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Phillip, Nothing in this proposal creates security policy. It creates inputs for things that go into security policy. All that the proposed records do is provide another input into the client's *internal* process for deciding whether a credential is tied to a particular domain. Clients are free to validate or not validate certificates as they choose. Please stop trying to reinforce the misconception that the proposed mechanism overrides PKIX validation in any way. --Richard On Oct 26, 2010, at 9:03 PM, Phillip Hallam-Baker wrote: > Since this is a charter discussion, it goes to the IESG. > > My point is not that the IETF should not address Security Policy, it > is that any security mechanism should be completely independent of > defining a new and additional mechanism to sign public keys. > > It should be able for a domain to publish public keys in the DNS > without impact on existing deployed SSL certificates and it should > be possible for a domain to publish security policy constraining > trusted keys without having to do so by publishing their keys in the > DNS. > > If the policy of a site is that every certificate is issued off a > local CA root that is cross certified to a public root, it should > suffice to state that every valid cert is issued of the local CA root. > > > My reason for wanting this distinction is twofold. First I believe > it is a matter of sound architectural practice to separate the two > issued, Secondly I believe that the IAB and IESG are going to insist > on this distinction. > > The worst outcome here would be for the WG to be chartered with an > ambiguous remit, spend a year or two working on the issue and then > produce a proposal that is thrown out by the IESG because they > insist that the two issues be kept separate. > > The second worse outcome is to be kicked back with a request to > define the problem we are trying to solve. I think that process is > going to take longer than solving the key signing problem. We really > do understand the key signing problem very well. > > > We have done mechanisms for signing keys before. It is a well > constrained problem. I think that having a mechanism for signing > keys on the basis of DNSSEC is a worthwhile achievement on its own. > We should be able to knock that one off in about six months. Then we > can approach the IESG and invoke the pinball rule under RFC 2418 sec > 4: If you win you get to play again. > > By that time, I hope that we have some results to show with CAA > which addresses a very limited aspect of security policy that does > not affect the client. Based on the feedback I have had so far from > targeted domains and from CAs, that looks like a win-win. > > So at that time I think we can expect to be able to go back to the > IESG and tell them that we want to do security policy and that we > are pretty sure that we understand the issues involved and can > produce a nicely abstracted platform that has strong separation of > concerns and reduces the entropy in the Internet architecture rather > than further increasing it.. > > > > On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters > wrote: > On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote: > > [not sure if such a broad CC: is warranted] > > > I think that this mechanism is entirely logical and useful. DNSSEC > is entirely adequate for the purpose of establishing > a key as being sufficient to enable use of encryption. > > The second set of proposals relates to security policy. > > the first is a security policy as well. > > > In particular the TLSFP scheme defines a path validation > algorithm that overrides the standard PKIX processing mechanism in > two ways. > > Not override, alternative. Depending on client policy. Image systems > with no CA's. > > > Secondly, there is an assumption in TLSFP that any domain that > publishes CERT records of TLSFP certificate type will > publish TLSFP records for ALL valid SSL certs in use for the domain. > So the publication of a TLSFP record to enable > secure communication on the mail server will cause the SSL > certificate on the Web server to be considered invalid. > > I don't see that. The browser and its CA policy installation can > still ignore TLSFP. In fact, I strongly > suspect they will in at least the near future. > > > I find this proposal troubling for severalreasons. First it lacks > orthogonality. It should be able to use the DNSSEC to > establish additional keys without affecting existing trust systems > in any way whatsoever. > > It does. Its an addon a client can decide to use or not use. > > > I dislike > any mechanism that requires the administrator to perform > configuration in the DNS for each and every SSL certificate as > it is issued. > > I dislike needing to delete so many untrusted omnipotent CA's from my > browser. But our personal dislikes are irrelevant to protocol design. > > > Thirdly, the percentage of Internet traffic that is encrypted today > is negligible. I think that we should make > encouraging the use of encryption a higher priority than correcting > what some people see as flaws in the trust provision > for existing sites. The security policy that has the highest > leverage is statements of the form 'always use TLS'. > > The existence of a TLSFP record could mean "always use TLS". The WG > is going to discuss whether or not to use > bits for these things in the coming months. I would also like to see > more policy options there, such as "only > connect anonymous", or a policy where it is clear if the server does > any kind of authentication, or whether it > will allow a BTNS type security policy without client authentication. > > > What worries me here is the that the WG should decide to address a > single aspect of security policy, address that aspect > from a single point of view and then optimize for that single scope. > > Let's cut the chase here. It's independant of CA's. Yes. It's an > alternative. Yes. Your worry has been noted. Again. > You can ensure browser vendors are aware of these limitations in > respect to deploying CA's, and recommend > what they implement and support. But there is no reason to try and > stop a protocol development that does not > rely on the currently deployed CA infrastructure - an infrastructure > some people have lost faith in, with good > reason. > > Paul > > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --Apple-Mail-2-635056657 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Since this is a charter discussion, it goes to the = IESG.

My point is not that the IETF should not = address Security Policy, it is that any security mechanism should be = completely independent of defining a new and additional mechanism to = sign public keys.

It should be able for a = domain to publish public keys in the DNS without impact on existing = deployed SSL certificates and it should be possible for a domain to = publish security policy constraining trusted keys without having to do = so by publishing their keys in the DNS.

If the = policy of a site is that every certificate is issued off a local CA root = that is cross certified to a public root, it should suffice to state = that every valid cert is issued of the local CA root.
=


My reason for wanting this = distinction is twofold. First I believe it is a matter of sound = architectural practice to separate the two issued, Secondly I believe = that the IAB and IESG are going to insist on this distinction.
=

The worst outcome here would be for the WG to be = chartered with an ambiguous remit, spend a year or two working on the = issue and then produce a proposal that is thrown out by the IESG because = they insist that the two issues be kept separate.
=

The second worse outcome is to be kicked back with a = request to define the problem we are trying to solve. I think that = process is going to take longer than solving the key signing problem. We = really do understand the key signing problem very well.
=


We have done mechanisms for signing = keys before. It is a well constrained problem. I think that having a = mechanism for signing keys on the basis of DNSSEC is a worthwhile = achievement on its own. We should be able to knock that one off in about = six months. Then we can approach the IESG and invoke the pinball rule = under RFC 2418 sec 4: If you win you get to play again.
=
By that time, I hope that we have some results to show = with CAA which addresses a very limited aspect of security policy that = does not affect the client. Based on the feedback I have had so far from = targeted domains and from CAs, that looks like a win-win.
=

So at that time I think we can expect to be able to = go back to the IESG and tell them that we want to do security policy and = that we are pretty sure that we understand the issues involved and can = produce a nicely abstracted platform that has strong separation of = concerns and reduces the entropy in the Internet architecture rather = than further increasing it..
=



On = Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters <paul@xelerance.com> = wrote:
On Tue, 26 Oct 2010, = Phillip Hallam-Baker wrote:

[not sure if such a broad CC: is = warranted]


= I think that this mechanism is entirely logical and useful. DNSSEC is = entirely adequate for the purpose of establishing
a key as being = sufficient to enable use of encryption. 

The second set of = proposals relates to security policy.

the = first is a security policy as well.


=
In particular the = TLSFP scheme defines a path validation
algorithm that overrides the = standard PKIX processing mechanism in two ways.
=
Not override, alternative. Depending on client policy. Image = systems with no CA's.


Secondly, there is an assumption in TLSFP that = any domain that publishes CERT records of TLSFP certificate type = will
publish TLSFP records for ALL valid SSL certs in use for the = domain. So the publication of a TLSFP record to enable
secure = communication on the mail server will cause the SSL certificate on the = Web server to be considered invalid.

I = don't see that. The browser and its CA policy installation can still = ignore TLSFP. In fact, I strongly
suspect they will in at least the = near future.


= I find this proposal troubling for severalreasons. First it lacks = orthogonality. It should be able to use the DNSSEC to
establish = additional keys without affecting existing trust systems in any way = whatsoever.

It does. Its an addon a client = can decide to use or not use.


I dislike
any mechanism that requires the = administrator to perform configuration in the DNS for each and every SSL = certificate as
it is issued.

I dislike = needing to delete so many untrusted omnipotent CA's from my
browser. = But our personal dislikes are irrelevant to protocol design.


Thirdly, the = percentage of Internet traffic that is encrypted today is negligible. I = think that we should make
encouraging the use of encryption a higher = priority than correcting what some people see as flaws in the trust = provision
for existing sites. The security policy that has the = highest leverage is statements of the form 'always use TLS'.
=

The existence of a TLSFP record could mean = "always use TLS". The WG is going to discuss whether or not to use
= bits for these things in the coming months. I would also like to see = more policy options there, such as "only
connect anonymous", or a = policy where it is clear if the server does any kind of authentication, = or whether it
will allow a BTNS type security policy without client = authentication.


What worries me here is the that the WG should = decide to address a single aspect of security policy, address that = aspect
from a single point of view and then optimize for that single = scope.

Let's cut the chase here. It's = independant of CA's. Yes. It's an alternative. Yes. Your worry has been = noted. Again.
You can ensure browser vendors are aware of these = limitations in respect to deploying CA's, and recommend
what they = implement and support. But there is no reason to try and stop a protocol = development that does not
rely on the currently deployed CA = infrastructure - an infrastructure some people have lost faith in, with = good
reason.

Paul
=



--
Website: http://hallambaker.com/

=
_______________________________________________
keyassure = mailing list
keyassure@ietf.org
https://www.ietf.= org/mailman/listinfo/keyassure

= = --Apple-Mail-2-635056657-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6F83A69CA; Wed, 27 Oct 2010 04:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SH-Qt+pSqHA; Wed, 27 Oct 2010 04:39:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D774E3A68A0; Wed, 27 Oct 2010 04:39:38 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 969301ECB408; Wed, 27 Oct 2010 11:41:27 +0000 (UTC) Date: Wed, 27 Oct 2010 07:41:25 -0400 From: Andrew Sullivan To: Yaron Sheffer Message-ID: <20101027114125.GW45134@shinkuro.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC73DA7.8010302@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: IESG Secretary , keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:39:54 -0000 On Tue, Oct 26, 2010 at 10:44:23PM +0200, Yaron Sheffer wrote: > I believe it is too early to form a working group for kidns. > > The group has not produced a problem statement, nor is one proposed in > the draft charter. While in most cases you can hide a problem statement > in the first section or two of an RFC, in this case it is essential that > the usage scenarios be hashed out before the technical solutions are > discussed. With respect, it seems to me that such a reaction is exactly why people give up on doing work at the IETF: the bureaucratic hurdles to completing the job that get thrown up make people go away in frustration. We have a community of interested people. We have a reasonably clear idea of the initial goal of the work. We have different and competing proposals for how to get that work done. We also have some sceptics who want to take a completely different approach. We have people committed to doing review. We have a proposed charter with measurable deliverables. This sounds to me like a community that has coalesced around a problem and is ready to do the work. To me, that means we already _have_ a working group (i.e. a group of people doing work), and the question is merely whether the IETF machinery acknowledges it. I'm not opposed to altering the charter to say, "This work allows sites to publish keys in the DNS and for clients to use those key securely without any validation infrastructure apart from DNSSEC," or something like that. But I don't believe we need to discuss more whether there is work to do, whether it can be done in a reasonable time, or whether there is a community to do that work (all the things a BOF would determine). We have ample demonstration, I think. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E372C3A691C for ; Wed, 27 Oct 2010 04:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOvpRgKsRjYs for ; Wed, 27 Oct 2010 04:05:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5D31F3A67FC for ; Wed, 27 Oct 2010 04:05:24 -0700 (PDT) Received: by wwe15 with SMTP id 15so582790wwe.13 for ; Wed, 27 Oct 2010 04:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XaQ8QGjqFj+9qDEj3GOV1vGkMkh1gGwU6rwcu7cgXyE=; b=Ye+x0l9rhtqSRalrQSpKl2iN87daLabNdd4BR/1LbECV3XSeXWIbXTZxTysNBVuQoU P11kU407pkAyLHx7GvsW84n2dnucYuLiSPhmxiaAkWN0sn7VjbsX0cpSL2uLm0r7PQWi JNokAHLXrFKIUgB6JNk9ZuCVFvvXyIwL5k/OU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ce/iz5HKYX4tQEDUgf/jN/dnq6y0Q1W6WFgKanHgzcERhc1TvPbylOb1vGj1iwdiGP UDbpAO+LERyPDa34P6T6iiZV7AjOWdDvSNl/CwbcHVuMfKB/8nhqs3trItE+RB1ArqO4 NnQeWqlWd+k74dMIzxyJUwle6R19B8257J7B8= Received: by 10.227.141.209 with SMTP id n17mr5800539wbu.126.1288177631649; Wed, 27 Oct 2010 04:07:11 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id a17sm7813731wbe.0.2010.10.27.04.07.09 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 04:07:10 -0700 (PDT) Message-ID: <4CC807DB.3060400@gmail.com> Date: Wed, 27 Oct 2010 13:07:07 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027080334.GB5872@nic.fr> In-Reply-To: <20101027080334.GB5872@nic.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 11:05:26 -0000 Hi Stephane, please see my comments below. Thanks, Yaron On 10/27/2010 10:03 AM, Stephane Bortzmeyer wrote: > On Tue, Oct 26, 2010 at 10:44:23PM +0200, > Yaron Sheffer wrote > a message of 124 lines which said: > >> Lastly, the group includes contributors from the CA industry, which >> is very good. But given that we're putting all our trust in the DNS >> infrastructure and procedures, I would hope to see some domain >> operators in the loop. > > There are several already, like me or one of the proposed chairs. > I'm glad to hear that. Thanks. >> The group has not produced a problem statement, > > It is in the charter. A charter is not an RFC. An RFC undergoes a different process, and is a permanent record of IETF consensus (but I don't have to tell you that). I think this group is badly in need of a PS document. If the group decides to publish one, I would be happy to participate. We could add something like: > > Currently, the authentication of the domain name is typically done by > the fact that the CA which signed the certificate checked in a way or > the other that the requester was the holder of example.com and that he > was allowed to delegate www.example.com (X.509 method). This > introduces a new party in the authentication process, the CA, while > some people may prefer to keep the process simpler, with only the > server manager and the DNS manager in the loop (they are the people > you need to trust anyway). The parenthetical remark at the end is incorrect: in a perfect world, I only have to trust the DNS manager (I assume you mean the operator) for *unprotected* communication, which is not our subject here. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E12B3A6919 for ; Wed, 27 Oct 2010 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.705 X-Spam-Level: X-Spam-Status: No, score=-105.705 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPtKUY3+K7vu for ; Wed, 27 Oct 2010 02:03:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 405833A69A7 for ; Wed, 27 Oct 2010 02:03:15 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o9R9546p008609 for ; Wed, 27 Oct 2010 02:05:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288170304; bh=b0kHoge1aVxBuw9VaJ3V1VNH7Ko=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=LOSjvnQ2C3w2X41zWNOx/iJVhzyP5y5pOwVB/nktNkLcDSd6zf9gaMQ3gTjsIotOS 0/ywjyt6Y/8547swXarpQ== Received: from gwj17 (gwj17.prod.google.com [10.200.10.17]) by wpaz17.hot.corp.google.com with ESMTP id o9R94etk028636 for ; Wed, 27 Oct 2010 02:05:03 -0700 Received: by gwj17 with SMTP id 17so198202gwj.8 for ; Wed, 27 Oct 2010 02:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7m7wbXVm4ZnFuRJQfZY/0iVSfNUQtGhgdLcTTqvuD1Y=; b=edOXb522OKAuPbUA2X8y11qJCjXSSWTkvpFSOnk5PG4guRc/xaiLZUfHMK8QwETPM1 tMOgWG8eHLxqmCd6V3ZQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NAP55W2eLDR10crX6kxoRgf72fet+mK4yg5KFjtREueZ681koU4KRcYB8GVnTMMagk VhMMpgYJxHMz+J5Mx65A== MIME-Version: 1.0 Received: by 10.100.167.18 with SMTP id p18mr3176277ane.180.1288170301319; Wed, 27 Oct 2010 02:05:01 -0700 (PDT) Received: by 10.220.62.143 with HTTP; Wed, 27 Oct 2010 02:05:01 -0700 (PDT) In-Reply-To: References: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> Date: Wed, 27 Oct 2010 10:05:01 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 09:03:18 -0000 On 25 October 2010 18:36, Phillip Hallam-Baker wrote: > On Mon, Oct 25, 2010 at 12:47 PM, Ben Laurie wrote: >> >> Sorry for the delay.. >> >> Looking at the -01 version... >> >> "The authorizations specified in the dauth and pauth properties are >> =A0 additive." >> >> I'm not sure "additive" is the right word - certainly it leaves me >> wondering "does that mean 'and' or 'or'?". Later text confirms "or", >> which was not my guess. > > I had difficulty drafting that. I think that the problem is that I should= be > using the term 'permission' or 'authorization entry'. > >> >> Why restrict tag length in the CAA RR? > > The tags are from an assigned space. The only protocol constraint I would > really insist on is that the tag length needs to be expressible in a sing= le > byte. > Do we really think we will need more than 2^16 different tags in a data > record that has to fit into a 65535 byte space? No, I just wondered what the point of the restriction was. Perhaps you want to reserve the other 4 bits for flags (e.g. it occurred to me that marking permissions as critical might serve some purpose)? > >> >> "An ASN.1 DER encoded data field containing the digest value of the >> =A0 =A0 =A0referenced object processed using the specified digest algori= thm." >> >> I don't think this is an unambiguous specification - you have to >> specify the ASN.1... > > I am not sure what point you were going to make here. I mean you should say how it is encoded (that is, as an OCTET STRING). > I am sure that there can be some byte sex issues that enter into things > here. I hope not! > Some digest algorithms have more than one OID assigned. But the ones we > currently recommend in IETF specs have exactly one OID assignment across = all > specifications, the one assigned by NIST. And this should be the same for > the SHA-3 algorithms as well. I'm talking about the digest itself, not the OID. > One other point that was raised was that some people would like to have t= he > ODI data wrapped in an ASN.1 tag, length container as well. Seems not unreasonable - in which case the tag would be OBJECT IDENTIFIER. > >> >> " =A0 Use of DNSSEC to authenticate CAA RRs is strongly recommended but = not >> =A0 required. =A0A CA MUST observe a CAA RR that is returned whether it = is >> =A0 signed using DNSSEC or not." >> >> Fine - but I think it should say that applications MUST NOT observe a >> CAA RR that is not signed. > > OK, that is fair enough. > I am thinking that we may want to differentiate between authority to issu= e > and authority for relying parties. > The issue authority statements refer to what an issuer is authorized to d= o > during the validity interval for the record. > But the fact that an issuer is no longer authorized to issue new > certificates does not invalidate the certificates they have already issue= d. > So the statement for relying parties may well contain more entries. Excellent point. > >> >> 4.2 should note that DNSSEC effectively prevents either suppression or >> spoofing. >> >> Other than that, looks good to me > > That must have got lost in the editing. > >> >> On 19 October 2010 03:17, Phillip Hallam-Baker wrote: >> > Adam L. pointed out some typos and so on. I had to get it in today and= I >> > am >> > fighting off a cold. >> > >> > As we discussed in the call, we are very interested in having Google >> > co-author if you are interested. >> > >> > CA buy-in is not so much of a worry for me. Comodo will deploy for >> > certain >> > and Symantec/VeriSignCA is pretty likely to follow. >> > Assume for a moment that other CAs don't follow our lead and end up >> > mis-issuing against a domain that has a CAA record. What do you think >> > their >> > liability is in that case? They certainly have a major PR issue at tha= t >> > point and their only realistic chance of surviving it without too much >> > damage is going to be to deploy CAA. >> > >> > So all in all, I think that the chances are pretty good that we can >> > present >> > this as a win for all concerned. >> > >> > You may also be interested in my DPLS draft: >> > http://www.ietf.org/id/draft-hallambaker-dpls-00.txt >> > A lot of the DNS performance issues go away if the DNS client can ask >> > its >> > resolver 'hey give me all the info I need to do this with that'. >> > >> > On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari >> > wrote: >> >> >> >> I have not yet read the whole draft, but so far I really like it. >> >> >> >> While (as you already pointed out) it doesn't solve all of the issues= , >> >> it >> >> does go a long way towards improving matters, assuming of course the >> >> CAs buy >> >> in... >> >> >> >> W >> >> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote: >> >> >> >> > This is a draft that I submitted this morning. The main proposal >> >> > being >> >> > made here is to enable Certification Authorities to avoid mis-issue= . >> >> > >> >> > As such I believe that it is complimentary to mechanisms that enabl= e >> >> > client side enforcement but has the considerable advantage of >> >> > offering >> >> > immediate protection to every Internet user regardless of whether >> >> > they have >> >> > an updated browser. It is also much less strongly dependent on >> >> > deployment of >> >> > DNSSEC. >> >> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt >> >> > >> >> > >> >> > Given the nature of the proposal, it is probably better suited to >> >> > having >> >> > the bulk of the legal-technical work considered in CABForum rather >> >> > than >> >> > IETF. Accordingly the proposal is designed to allow the technical >> >> > infrastructure to be agreed in IETF and then the practices and lega= l >> >> > work >> >> > done in CABForum. >> >> > >> >> > Clearly a record of this type could be used to effect client policy >> >> > enforcement mechanisms. But this is a rather more complex issue and >> >> > there >> >> > are going to be a lot of people with views on the best way forward. >> >> > >> >> > The mechanism as specified is sufficient for allowing client side >> >> > enforcement as it stands if the site is using a public CA, running = a >> >> > local >> >> > CA cross certified into a public hierarchy or using a standalone >> >> > private CA. >> >> > But only if those infrastructures are supporting all their >> >> > applications >> >> > without exception. >> >> > >> >> > >> >> > -- >> >> > Website: http://hallambaker.com/ >> >> > >> >> > _______________________________________________ >> >> > keyassure mailing list >> >> > keyassure@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/keyassure >> >> >> > >> > >> > >> > -- >> > Website: http://hallambaker.com/ >> > >> > >> > _______________________________________________ >> > keyassure mailing list >> > keyassure@ietf.org >> > https://www.ietf.org/mailman/listinfo/keyassure >> > >> > > > > > -- > Website: http://hallambaker.com/ > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642803A69A4; Wed, 27 Oct 2010 01:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9wBXY3QiNHn; Wed, 27 Oct 2010 01:45:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id D862D3A697A; Wed, 27 Oct 2010 01:45:56 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 1ABC473438D; Wed, 27 Oct 2010 10:47:45 +0200 (CEST) Message-ID: <4CC7E730.3040701@nic.cz> Date: Wed, 27 Oct 2010 10:47:44 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: keyassure@ietf.org, iesg@ietf.org References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> <20101027080334.GB5872@nic.fr> In-Reply-To: <20101027080334.GB5872@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:45:58 -0000 On 27.10.2010 10:03, Stephane Bortzmeyer wrote: > On Tue, Oct 26, 2010 at 10:44:23PM +0200, > Yaron Sheffer wrote > a message of 124 lines which said: > >> Lastly, the group includes contributors from the CA industry, which >> is very good. But given that we're putting all our trust in the DNS >> infrastructure and procedures, I would hope to see some domain >> operators in the loop. > > There are several already, like me or one of the proposed chairs. I could also add that this work was presented on at least two Centr[1] meetings and I just asked dns-wg@ripe chairs to present the work on RIPE 61 in Rome. But I think it was very well communicated to the TLD community through the various interest mailing lists. 1. CENTR is an association of Internet Country Code Top Level Domain Registries (www.centr.org) Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CEE3A69DB for ; Wed, 27 Oct 2010 01:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIWtlmmOO0Gv for ; Wed, 27 Oct 2010 01:32:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id D1DF03A69E8 for ; Wed, 27 Oct 2010 01:32:53 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id ED09B73433D for ; Wed, 27 Oct 2010 10:34:41 +0200 (CEST) Message-ID: <4CC7E420.4080802@nic.cz> Date: Wed, 27 Oct 2010 10:34:40 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: keyassure@ietf.org References: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> In-Reply-To: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:32:58 -0000 On 25.10.2010 11:36, Jakob Schlyter wrote: > On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote: > >> There is no magic in the choice of bits on the wire. DNSSEC suffers >> from exactly the same set of issuing chain difficulties as PKI >> does. The number of DNS registrars is actually considerably larger >> than the number of SSL validation authorities. > > Except that it is apparent for the victim when a DNS registrar goes > rogue (as the result is published in the DNS), whereas a trusted CA > can issue bad certificates without detection. And many registries implement lock-down function, where you can tie your domain name to current registrar and prevent all transfers. Some registries do it on the registry level[*] and I know I could lock at least some gTLDs via my registrar. If there is need on higher protection from rogue registrars then more registries could implement lock-down function. So your current sponsoring registrar would have to go wild. But you are not protected in that case even nowadays. (Issuing DV certs on whois/DNS data...) (And some registrars have even direct channel with some CAs.) Ondrej * - http://www.nic.cz/whois/publicrequest/ -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A216A3A6821; Wed, 27 Oct 2010 01:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBY+mHQZcIqz; Wed, 27 Oct 2010 01:23:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 52F403A67C3; Wed, 27 Oct 2010 01:23:39 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id C8B9673438D; Wed, 27 Oct 2010 10:25:27 +0200 (CEST) Message-ID: <4CC7E1F7.2090303@nic.cz> Date: Wed, 27 Oct 2010 10:25:27 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: keyassure@ietf.org, iesg@ietf.org References: <20101026170002.14A8C3A6992@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:23:41 -0000 [Replying to Phillip and Paul simultaneously] On 27.10.2010 02:06, Paul Wouters wrote: > On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote: >> In particular the TLSFP scheme defines a path validation algorithm >> that overrides the standard PKIX processing mechanism in two >> ways. > > Not override, alternative. Depending on client policy. Image systems > with no CA's. True. >> Secondly, there is an assumption in TLSFP that any domain that >> publishes CERT records of TLSFP certificate type will publish TLSFP >> records for ALL valid SSL certs in use for the domain. Just a note: There is no such assumption in the charter. This is just one particular I-D. >> So the publication of a TLSFP record to enable secure >> communication on the mail server will cause the SSL certificate on >> the Web server to be considered invalid. > > I don't see that. The browser and its CA policy installation can > still ignore TLSFP. In fact, I strongly suspect they will in at least > the near future. And I don't see that as a problem anyway. The scope of this proposed WG is to link domain names to certificates. As stated by Stephane in other thread in keyassure list, newer protocols generally use (or can use) SRV record to distinguish between different services. It will take some effort on the sysadmin side to make the TLSFP work as intended, but setting up security was never painless. And people who will find this too difficult can still use old CA scheme. But it will give a people with a skill the tool to make things more secure than now. >> I find this proposal troubling for several reasons. First it lacks >> orthogonality. It should be able to use the DNSSEC to establish >> additional keys without affecting existing trust systems in any way >> whatsoever. I don't understand why it should? You can decide if you want to use DNSSEC or not. You can decide if you want to use TLSFP or not. It's up to each domain holder if he will use this mechanism or not. >> Thirdly, the percentage of Internet traffic that is encrypted today >> is negligible. I think that we should make encouraging the use of >> encryption a higher priority than correcting what some people see >> as flaws in the trust provision for existing sites. The security >> policy that has the highest leverage is statements of the form >> 'always use TLS'. > > The existence of a TLSFP record could mean "always use TLS". The WG > is going to discuss whether or not to use bits for these things in > the coming months. I would also like to see more policy options > there, such as "only connect anonymous", or a policy where it is > clear if the server does any kind of authentication, or whether it > will allow a BTNS type security policy without client > authentication. Yes, I think our proposed charter allows that. >> What worries me here is the that the WG should decide to address a >> single aspect of security policy, address that aspect from a >> single point of view and then optimize for that single scope. > > Let's cut the chase here. It's independant of CA's. Yes. It's an > alternative. Yes. Your worry has been noted. Again. You can ensure > browser vendors are aware of these limitations in respect to > deploying CA's, and recommend what they implement and support. But > there is no reason to try and stop a protocol development that does > not rely on the currently deployed CA infrastructure - an > infrastructure some people have lost faith in, with good reason. My understanding is that this was discussed in the keyassure before and the charter was built upon rough consensus. I don't think it's necessary to reiterate through all this again on IESG list. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5575B3A6887; Wed, 27 Oct 2010 01:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AJji35tDA6D; Wed, 27 Oct 2010 01:05:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 95EDE3A6879; Wed, 27 Oct 2010 01:05:00 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id C98AA734451; Wed, 27 Oct 2010 10:06:48 +0200 (CEST) Message-ID: <4CC7DD98.6090009@nic.cz> Date: Wed, 27 Oct 2010 10:06:48 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: keyassure@ietf.org, iesg@ietf.org References: <20101026170002.14A8C3A6992@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:05:03 -0000 On 27.10.2010 03:03, Phillip Hallam-Baker wrote: > The worst outcome here would be for the WG to be chartered with an > ambiguous remit, spend a year or two working on the issue and then > produce a proposal that is thrown out by the IESG because they insist > that the two issues be kept separate. > > The second worse outcome is to be kicked back with a request to define > the problem we are trying to solve. I think that process is going to > take longer than solving the key signing problem. We really do > understand the key signing problem very well. I would say that IESG could speak for themselves... Aftera all, we are discussing this on the IESG list. I think it's futile to discuss what other parties may or may not do and not to ask them. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067303A69A7 for ; Wed, 27 Oct 2010 01:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYJPbOex69f0 for ; Wed, 27 Oct 2010 01:01:47 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id AFD1C3A68D2 for ; Wed, 27 Oct 2010 01:01:46 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 45FDC1C00F9; Wed, 27 Oct 2010 10:03:35 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 417491C0018; Wed, 27 Oct 2010 10:03:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 3FA58568057; Wed, 27 Oct 2010 10:03:35 +0200 (CEST) Date: Wed, 27 Oct 2010 10:03:35 +0200 From: Stephane Bortzmeyer To: Yaron Sheffer Message-ID: <20101027080334.GB5872@nic.fr> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC73DA7.8010302@gmail.com> X-Operating-System: Debian GNU/Linux squeeze/sid X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:01:48 -0000 On Tue, Oct 26, 2010 at 10:44:23PM +0200, Yaron Sheffer wrote a message of 124 lines which said: > Lastly, the group includes contributors from the CA industry, which > is very good. But given that we're putting all our trust in the DNS > infrastructure and procedures, I would hope to see some domain > operators in the loop. There are several already, like me or one of the proposed chairs. > The group has not produced a problem statement, It is in the charter. We could add something like: Currently, the authentication of the domain name is typically done by the fact that the CA which signed the certificate checked in a way or the other that the requester was the holder of example.com and that he was allowed to delegate www.example.com (X.509 method). This introduces a new party in the authentication process, the CA, while some people may prefer to keep the process simpler, with only the server manager and the DNS manager in the loop (they are the people you need to trust anyway). Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A8F3A696C for ; Wed, 27 Oct 2010 00:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.156 X-Spam-Level: X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvfs9LwAeI3J for ; Wed, 27 Oct 2010 00:43:43 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id AFCB03A677E for ; Wed, 27 Oct 2010 00:43:42 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 3A6AF1C00FF; Wed, 27 Oct 2010 09:45:31 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 35CA41C00FE; Wed, 27 Oct 2010 09:45:31 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 33CD0568057; Wed, 27 Oct 2010 09:45:31 +0200 (CEST) Date: Wed, 27 Oct 2010 09:45:31 +0200 From: Stephane Bortzmeyer To: Paul Wouters Message-ID: <20101027074531.GA5872@nic.fr> References: <8762wqquzs.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux squeeze/sid X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 07:43:44 -0000 On Mon, Oct 25, 2010 at 12:26:27PM -0400, Paul Wouters wrote a message of 18 lines which said: > I would say the world is moving in the other direction. You use > "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com. I > am PaulWouters@jabber.org, not PaulWouters@jabber.jabber.org. HTTP is very specific in that respect. It is the only major protocol (I do not consider RFC 1288 as "major") which do not use SRV (or a similar solution, such as MX). Hence the trick of an address record on the delegated domain. For your second example, the name to lookup in the DNS is hermes.jabber.org, target of the SRV, not jabber.org. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F14A3A68DE; Tue, 26 Oct 2010 18:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vIQ9g-Xeo2Y; Tue, 26 Oct 2010 18:01:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 264953A68D2; Tue, 26 Oct 2010 18:01:35 -0700 (PDT) Received: by gya6 with SMTP id 6so54552gya.31 for ; Tue, 26 Oct 2010 18:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=b50iDf/7vQpuXN+HlsExjcG+B3NLOjs9HDp5+8mCDos=; b=E1bLQ/DAnk9k8E+lni+KV+y/gE4PtLXpEGZtNpWF7/5SvkDTiNp5Xangfbozmg2YkP G1lSpfEDBIPQZMvp2wjsdNKV8KJieQHJBZHE0Vq1tP9XkjbYB3t7HYsHTqYgMa6rHm8y 3M7ZxK4iBRNB5/gcACuTIouf+yHg80W/4H2eo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nvZcDp236eUAeaWSov0Q92WJr83Yhn0jceCJI+CuMkOGqAeNXJXRG+LOSgRUJ+1IsJ uE8gtqZNiUdgrYKEhP9XtL2nBaebaxALVagtp12AC/QijXVuPUYTu4IwTUCD3+AuAXrl r2SkYdGwVADjy/7CAUOlgEB4laW9aRNKqa6AM= MIME-Version: 1.0 Received: by 10.100.209.15 with SMTP id h15mr2357816ang.97.1288141403421; Tue, 26 Oct 2010 18:03:23 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Tue, 26 Oct 2010 18:03:23 -0700 (PDT) In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Tue, 26 Oct 2010 21:03:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=00163698968fc57a6c04938ecaea Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 01:01:38 -0000 --00163698968fc57a6c04938ecaea Content-Type: text/plain; charset=ISO-8859-1 Since this is a charter discussion, it goes to the IESG. My point is not that the IETF should not address Security Policy, it is that any security mechanism should be completely independent of defining a new and additional mechanism to sign public keys. It should be able for a domain to publish public keys in the DNS without impact on existing deployed SSL certificates and it should be possible for a domain to publish security policy constraining trusted keys without having to do so by publishing their keys in the DNS. If the policy of a site is that every certificate is issued off a local CA root that is cross certified to a public root, it should suffice to state that every valid cert is issued of the local CA root. My reason for wanting this distinction is twofold. First I believe it is a matter of sound architectural practice to separate the two issued, Secondly I believe that the IAB and IESG are going to insist on this distinction. The worst outcome here would be for the WG to be chartered with an ambiguous remit, spend a year or two working on the issue and then produce a proposal that is thrown out by the IESG because they insist that the two issues be kept separate. The second worse outcome is to be kicked back with a request to define the problem we are trying to solve. I think that process is going to take longer than solving the key signing problem. We really do understand the key signing problem very well. We have done mechanisms for signing keys before. It is a well constrained problem. I think that having a mechanism for signing keys on the basis of DNSSEC is a worthwhile achievement on its own. We should be able to knock that one off in about six months. Then we can approach the IESG and invoke the pinball rule under RFC 2418 sec 4: If you win you get to play again. By that time, I hope that we have some results to show with CAA which addresses a very limited aspect of security policy that does not affect the client. Based on the feedback I have had so far from targeted domains and from CAs, that looks like a win-win. So at that time I think we can expect to be able to go back to the IESG and tell them that we want to do security policy and that we are pretty sure that we understand the issues involved and can produce a nicely abstracted platform that has strong separation of concerns and reduces the entropy in the Internet architecture rather than further increasing it.. On Tue, Oct 26, 2010 at 8:06 PM, Paul Wouters wrote: > On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote: > > [not sure if such a broad CC: is warranted] > > > I think that this mechanism is entirely logical and useful. DNSSEC is >> entirely adequate for the purpose of establishing >> a key as being sufficient to enable use of encryption. >> >> The second set of proposals relates to security policy. >> > > the first is a security policy as well. > > > In particular the TLSFP scheme defines a path validation >> algorithm that overrides the standard PKIX processing mechanism in two >> ways. >> > > Not override, alternative. Depending on client policy. Image systems with > no CA's. > > > Secondly, there is an assumption in TLSFP that any domain that publishes >> CERT records of TLSFP certificate type will >> publish TLSFP records for ALL valid SSL certs in use for the domain. So >> the publication of a TLSFP record to enable >> secure communication on the mail server will cause the SSL certificate on >> the Web server to be considered invalid. >> > > I don't see that. The browser and its CA policy installation can still > ignore TLSFP. In fact, I strongly > suspect they will in at least the near future. > > > I find this proposal troubling for severalreasons. First it lacks >> orthogonality. It should be able to use the DNSSEC to >> establish additional keys without affecting existing trust systems in any >> way whatsoever. >> > > It does. Its an addon a client can decide to use or not use. > > > I dislike >> any mechanism that requires the administrator to perform configuration in >> the DNS for each and every SSL certificate as >> it is issued. >> > > I dislike needing to delete so many untrusted omnipotent CA's from my > browser. But our personal dislikes are irrelevant to protocol design. > > > Thirdly, the percentage of Internet traffic that is encrypted today is >> negligible. I think that we should make >> encouraging the use of encryption a higher priority than correcting what >> some people see as flaws in the trust provision >> for existing sites. The security policy that has the highest leverage is >> statements of the form 'always use TLS'. >> > > The existence of a TLSFP record could mean "always use TLS". The WG is > going to discuss whether or not to use > bits for these things in the coming months. I would also like to see more > policy options there, such as "only > connect anonymous", or a policy where it is clear if the server does any > kind of authentication, or whether it > will allow a BTNS type security policy without client authentication. > > > What worries me here is the that the WG should decide to address a single >> aspect of security policy, address that aspect >> from a single point of view and then optimize for that single scope. >> > > Let's cut the chase here. It's independant of CA's. Yes. It's an > alternative. Yes. Your worry has been noted. Again. > You can ensure browser vendors are aware of these limitations in respect to > deploying CA's, and recommend > what they implement and support. But there is no reason to try and stop a > protocol development that does not > rely on the currently deployed CA infrastructure - an infrastructure some > people have lost faith in, with good > reason. > > Paul > -- Website: http://hallambaker.com/ --00163698968fc57a6c04938ecaea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since this is a charter discussion, it goes to the IESG.

My point is not that the IETF should not address Security Policy, it is th= at any security mechanism should be completely independent of defining a ne= w and additional mechanism to sign public keys.

It should be able for a domain to publish public keys i= n the DNS without impact on existing deployed SSL certificates and it shoul= d be possible for a domain to publish security policy constraining trusted = keys without having to do so by publishing their keys in the DNS.

If the policy of a site is that every certificate is is= sued off a local CA root that is cross certified to a public root, it shoul= d suffice to state that every valid cert is issued of the local CA root.


My reason for wanting this distinction i= s twofold. First I believe it is a matter of sound architectural practice t= o separate the two issued, Secondly I believe that the IAB and IESG are goi= ng to insist on this distinction.

The worst outcome here would be for the WG to be charte= red with an ambiguous remit, spend a year or two working on the issue and t= hen produce a proposal that is thrown out by the IESG because they insist t= hat the two issues be kept separate.

The second worse outcome is to be kicked back with a re= quest to define the problem we are trying to solve. I think that process is= going to take longer than solving the key signing problem. We really do un= derstand the key signing problem very well.


We have done mechanisms for signing keys= before. It is a well constrained problem. I think that having a mechanism = for signing keys on the basis of DNSSEC is a worthwhile achievement on its = own. We should be able to knock that one off in about six months. Then we c= an approach the IESG and invoke the pinball rule under RFC 2418 sec 4: If y= ou win you get to play again.

By that time, I hope that we have some results to show with = CAA which addresses a very limited aspect of security policy that does not = affect the client. Based on the feedback I have had so far from targeted do= mains and from CAs, that looks like a win-win.

So at that time I think we can expect to be able to go = back to the IESG and tell them that we want to do security policy and that = we are pretty sure that we understand the issues involved and can produce a= nicely abstracted platform that has strong separation of concerns and redu= ces the entropy in the Internet architecture rather than further increasing= it..



On Tue, O= ct 26, 2010 at 8:06 PM, Paul Wouters <paul@xelerance.com> wrote:
On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote:

[not sure if such a broad CC: is warranted]


I think that this mechanism is entirely logical and useful. DNSSEC is entir= ely adequate for the purpose of establishing
a key as being sufficient to enable use of encryption.=A0

The second set of proposals relates to security policy.

the first is a security policy as well.


In particular the TLSFP scheme defines a path validation
algorithm that overrides the standard PKIX processing mechanism in two ways= .

Not override, alternative. Depending on client policy. Image systems with n= o CA's.


Secondly, there is an assumption in TLSFP that any domain that publishes CE= RT records of TLSFP certificate type will
publish TLSFP records for ALL valid SSL certs in use for the domain. So the= publication of a TLSFP record to enable
secure communication on the mail server will cause the SSL certificate on t= he Web server to be considered invalid.

I don't see that. The browser and its CA policy installation can still = ignore TLSFP. In fact, I strongly
suspect they will in at least the near future.


I find this proposal troubling for severalreasons. First it lacks orthogona= lity. It should be able to use the DNSSEC to
establish additional keys without affecting existing trust systems in any w= ay whatsoever.

It does. Its an addon a client can decide to use or not use.


I dislike
any mechanism that requires the administrator to perform configuration in t= he DNS for each and every SSL certificate as
it is issued.

I dislike needing to delete so many untrusted omnipotent CA's from my browser. But our personal dislikes are irrelevant to protocol design.


Thirdly, the percentage of Internet traffic that is encrypted today is negl= igible. I think that we should make
encouraging the use of encryption a higher priority than correcting what so= me people see as flaws in the trust provision
for existing sites. The security policy that has the highest leverage is st= atements of the form 'always use TLS'.

The existence of a TLSFP record could mean "always use TLS". The = WG is going to discuss whether or not to use
bits for these things in the coming months. I would also like to see more p= olicy options there, such as "only
connect anonymous", or a policy where it is clear if the server does a= ny kind of authentication, or whether it
will allow a BTNS type security policy without client authentication.


What worries me here is the that the WG should decide to address a single a= spect of security policy, address that aspect
from a single point of view and then optimize for that single scope.

Let's cut the chase here. It's independant of CA's. Yes. It'= ;s an alternative. Yes. Your worry has been noted. Again.
You can ensure browser vendors are aware of these limitations in respect to= deploying CA's, and recommend
what they implement and support. But there is no reason to try and stop a p= rotocol development that does not
rely on the currently deployed CA infrastructure - an infrastructure some p= eople have lost faith in, with good
reason.

Paul



--
Website: http://hallambaker.com/

--00163698968fc57a6c04938ecaea-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4947B3A68D2; Tue, 26 Oct 2010 17:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQE2XmDYlqgT; Tue, 26 Oct 2010 17:05:05 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 88BED3A6836; Tue, 26 Oct 2010 17:05:05 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0B4B7C3F5; Tue, 26 Oct 2010 20:06:52 -0400 (EDT) Date: Tue, 26 Oct 2010 20:06:51 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20101026170002.14A8C3A6992@core3.amsl.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org, iesg@ietf.org, ietf-announce@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 00:05:07 -0000 On Tue, 26 Oct 2010, Phillip Hallam-Baker wrote: [not sure if such a broad CC: is warranted] > I think that this mechanism is entirely logical and useful. DNSSEC is entirely adequate for the purpose of establishing > a key as being sufficient to enable use of encryption.  > > The second set of proposals relates to security policy. the first is a security policy as well. > In particular the TLSFP scheme defines a path validation > algorithm that overrides the standard PKIX processing mechanism in two ways. Not override, alternative. Depending on client policy. Image systems with no CA's. > Secondly, there is an assumption in TLSFP that any domain that publishes CERT records of TLSFP certificate type will > publish TLSFP records for ALL valid SSL certs in use for the domain. So the publication of a TLSFP record to enable > secure communication on the mail server will cause the SSL certificate on the Web server to be considered invalid. I don't see that. The browser and its CA policy installation can still ignore TLSFP. In fact, I strongly suspect they will in at least the near future. > I find this proposal troubling for severalreasons. First it lacks orthogonality. It should be able to use the DNSSEC to > establish additional keys without affecting existing trust systems in any way whatsoever. It does. Its an addon a client can decide to use or not use. > I dislike > any mechanism that requires the administrator to perform configuration in the DNS for each and every SSL certificate as > it is issued. I dislike needing to delete so many untrusted omnipotent CA's from my browser. But our personal dislikes are irrelevant to protocol design. > Thirdly, the percentage of Internet traffic that is encrypted today is negligible. I think that we should make > encouraging the use of encryption a higher priority than correcting what some people see as flaws in the trust provision > for existing sites. The security policy that has the highest leverage is statements of the form 'always use TLS'. The existence of a TLSFP record could mean "always use TLS". The WG is going to discuss whether or not to use bits for these things in the coming months. I would also like to see more policy options there, such as "only connect anonymous", or a policy where it is clear if the server does any kind of authentication, or whether it will allow a BTNS type security policy without client authentication. > What worries me here is the that the WG should decide to address a single aspect of security policy, address that aspect > from a single point of view and then optimize for that single scope. Let's cut the chase here. It's independant of CA's. Yes. It's an alternative. Yes. Your worry has been noted. Again. You can ensure browser vendors are aware of these limitations in respect to deploying CA's, and recommend what they implement and support. But there is no reason to try and stop a protocol development that does not rely on the currently deployed CA infrastructure - an infrastructure some people have lost faith in, with good reason. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47ED3A68CC; Tue, 26 Oct 2010 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.806, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl53GXKPN8uT; Tue, 26 Oct 2010 14:54:36 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id A70033A6897; Tue, 26 Oct 2010 14:54:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mX/QN0pqQzH6g1zS7t67X9cmt7D8H6oZO5JQd4e8VL2dDGmCQv5DwIDxSH9yQIM5; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PArVH-0002xL-Dm; Tue, 26 Oct 2010 17:56:23 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 26 Oct 2010 17:56:22 -0400 Message-ID: <10196408.1288130183431.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Tue, 26 Oct 2010 16:56:23 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Ted Hardie , iesg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606880a03e300dcc59e3022a9efaeec55a0ad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Cc: keyassure@ietf.org, ietf@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:54:38 -0000 Ted and all, -----Original Message----- >From: Ted Hardie >Sent: Oct 26, 2010 1:36 PM >To: iesg@ietf.org >Cc: keyassure@ietf.org, ietf@ietf.org >Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) > >Howdy, > >The charter below has the following text: > >"The group may also create documents that describe how protocol entities >can discover and validate these bindings in the execution of specific >applications. This work would be done in coordination with the IETF >Working Groups responsible for the protocols." > >The "may" in that statement and the ordering involved throw up a tiny >red flag in my head that says "Are we building a technology and then >looking for customers, rather than asking customers what technology >to build"? (With the parallel that "customers" here are the "protocol ent= ities" >which would discover and use these bindings.) > >The answer appears to be "The customers are TLS and IPSEC". That >seems to me a big enough job for a first go-round. I would personally >suggest re-chartering to include other potential using protocols when >they have been identified, with specific coordination targets at that time >Some protocols developed outside the IETF might also want to use >this method of binding key materials, for example, and the WG coordination >for those might extend beyond IETF WGs. I think you need to add DNSSEC to the customers list as well as=20 browser vendors/developers, IxP's and DNS providers. Just my .2 cents... > >Just my two cents, > >regards, > >Ted > > > >On Tue, Oct 26, 2010 at 10:00 AM, IESG Secretary > wrote: >> A new IETF working group has been proposed in the Security Area. =C2=A0T= he IESG >> has not made any determination as yet. The following draft charter was >> submitted, and is provided for informational purposes only. Please send >> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, >> November 7, 2010 >> >> Keys In DNS (kidns) >> ----------------------- >> Last modified: 2010-10-25 >> Current status: Proposed Working Group >> >> Chairs: >> =C2=A0 =C2=A0Warren Kumari >> =C2=A0 =C2=A0Ondrej Sury >> >> Security Area Directors: >> =C2=A0 =C2=A0Sean Turner >> =C2=A0 =C2=A0Tim Polk >> >> Security Area Advisor: >> =C2=A0 =C2=A0Tim Polk >> >> Mailing Lists: >> =C2=A0 =C2=A0General Discussion: keyassure@ietf.org >> =C2=A0 =C2=A0To Subscribe: =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mai= lman/listinfo/keyassure >> =C2=A0 =C2=A0Archive: >> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html >> >> Objective: >> Specify mechanisms and techniques that allow Internet applications to >> establish cryptographically secured communications by using information >> distributed through the DNS and authenticated using DNSSEC to obtain >> public keys which are associated with a service located at a >> domain name. >> >> Problem Statement: >> >> Entities on the Internet are usually identified using domain names and >> forming a cryptographically secured connection to the entity requires >> the entity to authenticate its name. For instance, in HTTPS, a server >> responding to a query for is expected to >> authenticate as "www.example.com". Security protocols such as TLS and >> IPsec accomplish this authentication by allowing an endpoint to prove >> ownership of a private key whose corresponding public key is somehow >> bound to the name being authenticated. As a pre-requisite for >> authentication, then, these protocols require a mechanism for bindings >> to be asserted between public keys and domain names. >> >> DNSSEC provides a mechanism for a domain operator to sign DNS >> information directly, using keys that are bound to the domain by the >> parent domain; relying parties can continue this chain up to any trust >> anchor that they accept. In this way, bindings of keys to domains are >> asserted not by external entities, but by the entities that operate the >> DNS. In addition, this technique inherently limits the scope of any >> given entity to the names in zones he controls. >> >> This working group will develop mechanisms for domain operators to >> present bindings between names within their control and public keys, in >> such a way that these bindings can be integrity-protected (and thus >> shown to be authentically from the domain operator) using DNSSEC and >> used as a basis for authentication in protocols that use domain names as >> identifiers. Possible starting points for these deliverables include >> draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and >> draft-josefsson-keyassure-tls. >> >> The mechanisms developed by this group will address bindings between >> domain names and keys, allowing flexibility for all key-transport >> mechanisms supported by the application protocols addressed (e.g., both >> self-signed and CA-issued certificates for use in TLS). >> >> The group may also create documents that describe how protocol entities >> can discover and validate these bindings in the execution of specific >> applications. This work would be done in coordination with the IETF >> Working Groups responsible for the protocols. >> >> Milestones: >> Dec 2010 =C2=A0First WG draft of standards-track protocol for using DNS = to >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associate hosts with keys for TLS and = DTLS >> Jan 2011 =C2=A0First WG draft of standards-track protocols for using DNS= to >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associate hosts with IPsec >> Jun 2011 =C2=A0Protocol for using DNS to associate domain names with key= s >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for TLS and DTLS to IESG >> Aug 2011 =C2=A0Protocols for using DNS to associate domain names with ke= ys >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for IPsec to IESG >> Aug 2011 =C2=A0Recharter Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD3E3A68D2; Tue, 26 Oct 2010 14:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1eYQUj5R3WL; Tue, 26 Oct 2010 14:48:08 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 4F1483A68E4; Tue, 26 Oct 2010 14:48:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=XbSLdS9yj8iUrTjl82VmVuaWwA0ukFldhhAlix+2V4Q+vvQM4ezo3ZlU0jmV/JPo; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PArP2-0007Te-35; Tue, 26 Oct 2010 17:49:56 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 26 Oct 2010 17:49:55 -0400 Message-ID: <11902672.1288129796110.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Tue, 26 Oct 2010 16:49:55 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: keyassure@ietf.org, iesg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606885601d61cb2c9fb2f3af86f1b931b19c6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:48:10 -0000 laurence and all, I share lawrences frustration here and believe that the sooner we get started the better. Time waits of no man/woman. -----Original Message----- >From: Lawrence Conroy >Sent: Oct 26, 2010 4:38 PM >To: Yaron Sheffer >Cc: keyassure@ietf.org, iesg@ietf.org >Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) > >Hi folks, > I entirely disagree with this suggestion to delay protocol work until aft= er >a "full" problem statement/requirements analysis has been done. > >It's the IETF, for goodness sakes, and many a proposed group hasn't even >been able to START until it's almost too late for any market due to being >buried under requirements capture and analysis and even building consensus >on terminology [Ahem - Speermint, Drinks, ...]. Also, can we avoid taking >a small and simple idea and burying it under a load of different potential >options before it even gets to be a WG -- [HIP -- sigh]. >Let's not do that yet again, please. > >The work so far has pretty obvious target uses (TLS, IPSEC), and expanding >this list forever is hardly in keeping with the "small bite" approach that >the IETF is supposed to prefer. > >The fact that the work described in the charter is not ALL the work that i= s >needed to roll out this scheme should be entirely unsurprising. It's surel= y >not a reason to stop ANY work (apart from deep thought on the problem spac= e). >I trust we don't require a PS-level fully worked system before a WG can be= gin. > >In Maastricht there was quite a bit of support for this work; I do not see >a drop in the effort being applied. It seems to have momentum and people t= o >work on its charter tasks. >I believe that the WG should begin now, and I would trust that there can b= e >implementations to test out the initial proposals soon. Running code is go= od. >This assumes the protocol work is not slugged by being forced to wait for >everything else to be complete first -- it would be a shame if 3GPP (or th= e >ITU =C2=A7-) were quicker at delivery that the IETF. > >We're wildly agreeing that the potential of DNSSEC as an alternative trust= and >validation approach for TLS/IPSEC is interesting, and I for one would like= to >be able to add this as part of the toolbox I can apply soon. >Before I retire would be good. > >There are bound to be some areas that are local policy -- clients might ch= oose >one policy or another, but at the moment they don't have the choice. >This WG claims to give that choice. One can write documents until one's ha= nd >drops off, but in the end it's up to the market. >IMHO -- give this WG a chance to DEMONSTRATE this scheme, and let's see wh= at >falls. > >all the best, > Lawrence > > > >On 26 Oct 2010, at 21:44, Yaron Sheffer wrote: > >> I believe it is too early to form a working group for kidns. >>=20 >> The group has not produced a problem statement, nor is one proposed in t= he draft charter. While in most cases you can hide a problem statement in t= he first section or two of an RFC, in this case it is essential that the us= age scenarios be hashed out before the technical solutions are discussed. >>=20 >> With respect, the technical solution from what I've seen doesn't look te= rribly difficult, though we can argue forever about the details. But the ev= entual goal of this work for some of the participants (and one which I pers= onally support) is to provide an alternative to PKI. And the goal of this w= ork is something that we need to socialize and have consensus on. Right now= , even at the technical level the draft is ambiguous on whether DNS-based v= alidation replaces or not the regular PKIX validation, with wording such as= "a client MAY choose to trust a DNSSEC-secured certificate association". >>=20 >> Lastly, the group includes contributors from the CA industry, which is v= ery good. But given that we're putting all our trust in the DNS infrastruct= ure and procedures, I would hope to see some domain operators in the loop. >>=20 >> To summarize: this is important work; I support a BOF (but not a WG) in = Beijing and recommend the addition of a problem statement document into the= charter. >>=20 >> Thanks, >> =09Yaron >>=20 >> On 10/26/2010 07:00 PM, IESG Secretary wrote: >>> A new IETF working group has been proposed in the Security Area. The I= ESG >>> has not made any determination as yet. The following draft charter was >>> submitted, and is provided for informational purposes only. Please send >>> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, >>> November 7, 2010 >>>=20 >>> Keys In DNS (kidns) >>> ----------------------- >>> Last modified: 2010-10-25 >>> Current status: Proposed Working Group >>>=20 >>> Chairs: >>> Warren Kumari >>> Ondrej Sury >>>=20 >>> Security Area Directors: >>> Sean Turner >>> Tim Polk >>>=20 >>> Security Area Advisor: >>> Tim Polk >>>=20 >>> Mailing Lists: >>> General Discussion: keyassure@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure >>> Archive: >>> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html >>>=20 >>> Objective: >>> Specify mechanisms and techniques that allow Internet applications to >>> establish cryptographically secured communications by using information >>> distributed through the DNS and authenticated using DNSSEC to obtain >>> public keys which are associated with a service located at a >>> domain name. >>>=20 >>> Problem Statement: >>>=20 >>> Entities on the Internet are usually identified using domain names and >>> forming a cryptographically secured connection to the entity requires >>> the entity to authenticate its name. For instance, in HTTPS, a server >>> responding to a query for is expected to >>> authenticate as "www.example.com". Security protocols such as TLS and >>> IPsec accomplish this authentication by allowing an endpoint to prove >>> ownership of a private key whose corresponding public key is somehow >>> bound to the name being authenticated. As a pre-requisite for >>> authentication, then, these protocols require a mechanism for bindings >>> to be asserted between public keys and domain names. >>>=20 >>> DNSSEC provides a mechanism for a domain operator to sign DNS >>> information directly, using keys that are bound to the domain by the >>> parent domain; relying parties can continue this chain up to any trust >>> anchor that they accept. In this way, bindings of keys to domains are >>> asserted not by external entities, but by the entities that operate the >>> DNS. In addition, this technique inherently limits the scope of any >>> given entity to the names in zones he controls. >>>=20 >>> This working group will develop mechanisms for domain operators to >>> present bindings between names within their control and public keys, in >>> such a way that these bindings can be integrity-protected (and thus >>> shown to be authentically from the domain operator) using DNSSEC and >>> used as a basis for authentication in protocols that use domain names a= s >>> identifiers. Possible starting points for these deliverables include >>> draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and >>> draft-josefsson-keyassure-tls. >>>=20 >>> The mechanisms developed by this group will address bindings between >>> domain names and keys, allowing flexibility for all key-transport >>> mechanisms supported by the application protocols addressed (e.g., both >>> self-signed and CA-issued certificates for use in TLS). >>>=20 >>> The group may also create documents that describe how protocol entities >>> can discover and validate these bindings in the execution of specific >>> applications. This work would be done in coordination with the IETF >>> Working Groups responsible for the protocols. >>>=20 >>> Milestones: >>> Dec 2010 First WG draft of standards-track protocol for using DNS to >>> associate hosts with keys for TLS and DTLS >>> Jan 2011 First WG draft of standards-track protocols for using DNS to >>> associate hosts with IPsec >>> Jun 2011 Protocol for using DNS to associate domain names with keys >>> for TLS and DTLS to IESG >>> Aug 2011 Protocols for using DNS to associate domain names with keys >>> for IPsec to IESG >>> Aug 2011 Recharter >>> _______________________________________________ Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53A43A68D8; Tue, 26 Oct 2010 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLQu3T6NFjAS; Tue, 26 Oct 2010 14:36:28 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id DEF5C3A68DE; Tue, 26 Oct 2010 14:36:27 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 2D610745996; Tue, 26 Oct 2010 22:38:15 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: <4CC73DA7.8010302@gmail.com> Date: Tue, 26 Oct 2010 22:38:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55771117-8F7D-47B4-BEB4-1190708AFA2E@insensate.co.uk> References: <20101026170002.14A8C3A6992@core3.amsl.com> <4CC73DA7.8010302@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org, iesg@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:36:35 -0000 Hi folks, I entirely disagree with this suggestion to delay protocol work until = after a "full" problem statement/requirements analysis has been done. It's the IETF, for goodness sakes, and many a proposed group hasn't even been able to START until it's almost too late for any market due to = being buried under requirements capture and analysis and even building = consensus on terminology [Ahem - Speermint, Drinks, ...]. Also, can we avoid = taking a small and simple idea and burying it under a load of different = potential options before it even gets to be a WG -- [HIP -- sigh]. Let's not do that yet again, please. The work so far has pretty obvious target uses (TLS, IPSEC), and = expanding this list forever is hardly in keeping with the "small bite" approach = that the IETF is supposed to prefer. The fact that the work described in the charter is not ALL the work that = is needed to roll out this scheme should be entirely unsurprising. It's = surely not a reason to stop ANY work (apart from deep thought on the problem = space). I trust we don't require a PS-level fully worked system before a WG can = begin. In Maastricht there was quite a bit of support for this work; I do not = see a drop in the effort being applied. It seems to have momentum and people = to work on its charter tasks. I believe that the WG should begin now, and I would trust that there can = be implementations to test out the initial proposals soon. Running code is = good. This assumes the protocol work is not slugged by being forced to wait = for everything else to be complete first -- it would be a shame if 3GPP (or = the ITU =A7-) were quicker at delivery that the IETF. We're wildly agreeing that the potential of DNSSEC as an alternative = trust and validation approach for TLS/IPSEC is interesting, and I for one would = like to be able to add this as part of the toolbox I can apply soon. Before I retire would be good. There are bound to be some areas that are local policy -- clients might = choose one policy or another, but at the moment they don't have the choice. This WG claims to give that choice. One can write documents until one's = hand drops off, but in the end it's up to the market. IMHO -- give this WG a chance to DEMONSTRATE this scheme, and let's see = what falls. all the best, Lawrence On 26 Oct 2010, at 21:44, Yaron Sheffer wrote: > I believe it is too early to form a working group for kidns. >=20 > The group has not produced a problem statement, nor is one proposed in = the draft charter. While in most cases you can hide a problem statement = in the first section or two of an RFC, in this case it is essential that = the usage scenarios be hashed out before the technical solutions are = discussed. >=20 > With respect, the technical solution from what I've seen doesn't look = terribly difficult, though we can argue forever about the details. But = the eventual goal of this work for some of the participants (and one = which I personally support) is to provide an alternative to PKI. And the = goal of this work is something that we need to socialize and have = consensus on. Right now, even at the technical level the draft is = ambiguous on whether DNS-based validation replaces or not the regular = PKIX validation, with wording such as "a client MAY choose to trust a = DNSSEC-secured certificate association". >=20 > Lastly, the group includes contributors from the CA industry, which is = very good. But given that we're putting all our trust in the DNS = infrastructure and procedures, I would hope to see some domain operators = in the loop. >=20 > To summarize: this is important work; I support a BOF (but not a WG) = in Beijing and recommend the addition of a problem statement document = into the charter. >=20 > Thanks, > Yaron >=20 > On 10/26/2010 07:00 PM, IESG Secretary wrote: >> A new IETF working group has been proposed in the Security Area. The = IESG >> has not made any determination as yet. The following draft charter = was >> submitted, and is provided for informational purposes only. Please = send >> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, >> November 7, 2010 >>=20 >> Keys In DNS (kidns) >> ----------------------- >> Last modified: 2010-10-25 >> Current status: Proposed Working Group >>=20 >> Chairs: >> Warren Kumari >> Ondrej Sury >>=20 >> Security Area Directors: >> Sean Turner >> Tim Polk >>=20 >> Security Area Advisor: >> Tim Polk >>=20 >> Mailing Lists: >> General Discussion: keyassure@ietf.org >> To Subscribe: = https://www.ietf.org/mailman/listinfo/keyassure >> Archive: >> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html >>=20 >> Objective: >> Specify mechanisms and techniques that allow Internet applications to >> establish cryptographically secured communications by using = information >> distributed through the DNS and authenticated using DNSSEC to obtain >> public keys which are associated with a service located at a >> domain name. >>=20 >> Problem Statement: >>=20 >> Entities on the Internet are usually identified using domain names = and >> forming a cryptographically secured connection to the entity requires >> the entity to authenticate its name. For instance, in HTTPS, a server >> responding to a query for is expected to >> authenticate as "www.example.com". Security protocols such as TLS and >> IPsec accomplish this authentication by allowing an endpoint to prove >> ownership of a private key whose corresponding public key is somehow >> bound to the name being authenticated. As a pre-requisite for >> authentication, then, these protocols require a mechanism for = bindings >> to be asserted between public keys and domain names. >>=20 >> DNSSEC provides a mechanism for a domain operator to sign DNS >> information directly, using keys that are bound to the domain by the >> parent domain; relying parties can continue this chain up to any = trust >> anchor that they accept. In this way, bindings of keys to domains are >> asserted not by external entities, but by the entities that operate = the >> DNS. In addition, this technique inherently limits the scope of any >> given entity to the names in zones he controls. >>=20 >> This working group will develop mechanisms for domain operators to >> present bindings between names within their control and public keys, = in >> such a way that these bindings can be integrity-protected (and thus >> shown to be authentically from the domain operator) using DNSSEC and >> used as a basis for authentication in protocols that use domain names = as >> identifiers. Possible starting points for these deliverables include >> draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and >> draft-josefsson-keyassure-tls. >>=20 >> The mechanisms developed by this group will address bindings between >> domain names and keys, allowing flexibility for all key-transport >> mechanisms supported by the application protocols addressed (e.g., = both >> self-signed and CA-issued certificates for use in TLS). >>=20 >> The group may also create documents that describe how protocol = entities >> can discover and validate these bindings in the execution of specific >> applications. This work would be done in coordination with the IETF >> Working Groups responsible for the protocols. >>=20 >> Milestones: >> Dec 2010 First WG draft of standards-track protocol for using DNS to >> associate hosts with keys for TLS and DTLS >> Jan 2011 First WG draft of standards-track protocols for using DNS = to >> associate hosts with IPsec >> Jun 2011 Protocol for using DNS to associate domain names with keys >> for TLS and DTLS to IESG >> Aug 2011 Protocols for using DNS to associate domain names with keys >> for IPsec to IESG >> Aug 2011 Recharter >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1B93A6946; Tue, 26 Oct 2010 13:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-HnGKa+g5oI; Tue, 26 Oct 2010 13:42:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 988FC3A6932; Tue, 26 Oct 2010 13:42:43 -0700 (PDT) Received: by wyb28 with SMTP id 28so4945130wyb.31 for ; Tue, 26 Oct 2010 13:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3LAo8Bk5UcvDdZ55FgwedblqaiupTqCztDhtcc05NsA=; b=V6+CjMZSZexdf8vR73WxO/gUKmCbaOfBqcEgc+qhBwZxjqkq/YXg7OpcVljYyUYqWz kGFSLRBN78d603qUTIK+BLiCy7CiZT5jsRNWn1Mt3b6JLPexY/kEK2DCMMdwWALHzz4t lkuryOweE/gEETL6iPol41p4oICG5CCEobHB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O4jZQOkjT9oDTluhX3QCTCnyj37z8tK9rYdhMazTCjagF9ITZzdRIgB4VeEpt/582m CwvZeSWxK2bHIHeDL3GpZgD5twHjUi7XCXBcaeO8d2qKZ1S+nDRjMLuOoRo7Nz2fLHyT M0uBB1Bs3kH3YMNg/F5Y9OA6mPcX1cuqmA090= Received: by 10.227.20.14 with SMTP id d14mr8302970wbb.90.1288125870953; Tue, 26 Oct 2010 13:44:30 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id ga16sm7190692wbb.19.2010.10.26.13.44.26 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Oct 2010 13:44:29 -0700 (PDT) Message-ID: <4CC73DA7.8010302@gmail.com> Date: Tue, 26 Oct 2010 22:44:23 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: iesg@ietf.org References: <20101026170002.14A8C3A6992@core3.amsl.com> In-Reply-To: <20101026170002.14A8C3A6992@core3.amsl.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, IESG Secretary Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:42:48 -0000 I believe it is too early to form a working group for kidns. The group has not produced a problem statement, nor is one proposed in the draft charter. While in most cases you can hide a problem statement in the first section or two of an RFC, in this case it is essential that the usage scenarios be hashed out before the technical solutions are discussed. With respect, the technical solution from what I've seen doesn't look terribly difficult, though we can argue forever about the details. But the eventual goal of this work for some of the participants (and one which I personally support) is to provide an alternative to PKI. And the goal of this work is something that we need to socialize and have consensus on. Right now, even at the technical level the draft is ambiguous on whether DNS-based validation replaces or not the regular PKIX validation, with wording such as "a client MAY choose to trust a DNSSEC-secured certificate association". Lastly, the group includes contributors from the CA industry, which is very good. But given that we're putting all our trust in the DNS infrastructure and procedures, I would hope to see some domain operators in the loop. To summarize: this is important work; I support a BOF (but not a WG) in Beijing and recommend the addition of a problem statement document into the charter. Thanks, Yaron On 10/26/2010 07:00 PM, IESG Secretary wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination as yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, > November 7, 2010 > > Keys In DNS (kidns) > ----------------------- > Last modified: 2010-10-25 > Current status: Proposed Working Group > > Chairs: > Warren Kumari > Ondrej Sury > > Security Area Directors: > Sean Turner > Tim Polk > > Security Area Advisor: > Tim Polk > > Mailing Lists: > General Discussion: keyassure@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure > Archive: > http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html > > Objective: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS and authenticated using DNSSEC to obtain > public keys which are associated with a service located at a > domain name. > > Problem Statement: > > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. > > Milestones: > Dec 2010 First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > Jan 2011 First WG draft of standards-track protocols for using DNS to > associate hosts with IPsec > Jun 2011 Protocol for using DNS to associate domain names with keys > for TLS and DTLS to IESG > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG > Aug 2011 Recharter > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0284F3A6895; Tue, 26 Oct 2010 13:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfStM57pPsDu; Tue, 26 Oct 2010 13:29:08 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 8CE6B3A679C; Tue, 26 Oct 2010 13:29:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=MKmWDW15qyv2HapRUsDEHtAxqAeWqSGdOUBFmJzKAtYhqUSyVut9IdPEi2N6d+by; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PAqAa-0007ao-41; Tue, 26 Oct 2010 16:30:56 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 26 Oct 2010 16:30:55 -0400 Message-ID: <21982329.1288125055784.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Tue, 26 Oct 2010 15:30:55 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: iesg-secretary@ietf.org, iesg@ietf.org, tim.polk@nist.gov Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688a9fb48b135973428180db7277ed08ca7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:29:14 -0000

Phillip and all,

 

  I fully agree with this approach. 


-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 26, 2010 3:10 PM
To: iesg@ietf.org
Cc= : keyassure@ietf.org, ietf-announce@ietf.org
Subject: Re: [keyassure] W= G Review: Keys In DNS (kidns)

There are two sets of work items bein= g proposed for this group.

The first set of work describes mechanisms that allow a domain name ow= ner to use the DNS to establish the validity of a key.

I think that this mechanism is entirely logical and useful. DNSSEC is = entirely adequate for the purpose of establishing a key as being sufficient= to enable use of encryption. 


The second set of proposals relates to security policy. In particular = the TLSFP scheme defines a path validation algorithm that overrides the sta= ndard PKIX processing mechanism in two ways.

First a certificate that has a valid TLSFP validation path is to be co= nsidered valid even if it is a PKIX end entity cert and is invalid under PK= IX path math. This may be acceptable but needs to be carefully considered.<= /DIV>

Secondly, there is an assumption in TLSFP that any domain that publish= es CERT records of TLSFP certificate type will publish TLSFP records for AL= L valid SSL certs in use for the domain. So the publication of a TLSFP reco= rd to enable secure communication on the mail server will cause the SSL cer= tificate on the Web server to be considered invalid.


I find this proposal troubling for severalreasons. First it lacks orth= ogonality. It should be able to use the DNSSEC to establish additional keys= without affecting existing trust systems in any way whatsoever. At the ver= y least this behavior should be optional. 

Secondly, I am not at all convinced that enumeration of valid certific= ates is a practical method of declaring security policy with respect to TLS= trust anchors. PKIX provides a rich set of semantics for validating certif= icates. I dislike any mechanism that requires the administrator to perform = configuration in the DNS for each and every SSL certificate as it is issued= . The only way I can see that approach being practical for a public CA woul= d be if the CA took over maintenance of the DNS for the zone as well as the= PKI. 

Thirdly, the percentage of Internet traffic that is encrypted today is= negligible. I think that we should make encouraging the use of encryption = a higher priority than correcting what some people see as flaws in the trus= t provision for existing sites. The security policy that has the highest le= verage is statements of the form 'always use TLS'.

What worries me here is the that the WG should decide to address a sin= gle aspect of security policy, address that aspect from a single point of v= iew and then optimize for that single scope.

Specification of trust anchors and trust criteria is by far the most c= omplex and difficult part of security policy in my view. I do not see the l= ogic of punting on the high leverage aspects of security policy that are fa= irly well constrained (always use TLS) and then deciding to address the har= dest aspect of security policy in a fashion that is likely to raise severe = scaling issues.


I think we need to look at security policy separately from the problem= of providing new ways to establish keys.

I think we need to look at the whole problem of security policy togeth= er and not just one aspect of security policy. If we are going to address s= ecurity policy in stages we should start from the well defined problem of p= rotocol security policy and punt on the difficult issue of trust configurat= ion.


On Tue, Oct 26, 2010 at 1:00 PM, IESG Secretary <iesg-secretary@ietf.org> wrote:
A new IETF working group has been = proposed in the Security Area.  The IESG
has not made any determina= tion as yet. The following draft charter was
submitted, and is provided = for informational purposes only. Please send
your comments to the IESG m= ailing list (iesg@ietf.org= ) by Tuesday,
November 7, 2010

Keys In DNS (kidns)
-------= ----------------
Last modified: 2010-10-25
Current status: Proposed W= orking Group

Chairs:
   Warren Kumari <warren@kumari.net>
 =  Ondrej Sury <ondrej.sury@nic.cz>

Security Area Directors:
  &nbs= p;Sean Turner <turne= rs@ieca.com>
   Tim Polk <tim.polk@nist.gov>

Security Area A= dvisor:
   Tim Polk <tim.polk@nist.gov>

Mailing Lists:
  &n= bsp;General Discussion: keyassure@ietf.org
   To Subscribe:      = ; https://www.ietf.org/mailman/listinfo/keyassure
   Arch= ive:
http://www.ietf.org/mail-archive/web/keyassur= e/current/maillist.html

Objective:
Specify mechanisms and tec= hniques that allow Internet applications to
establish cryptographically = secured communications by using information
distributed through the DNS = and authenticated using DNSSEC to obtain
public keys which are associate= d with a service located at a
domain name.

Problem Statement:
=
Entities on the Internet are usually identified using domain names and<= BR>forming a cryptographically secured connection to the entity requiresthe entity to authenticate its name. For instance, in HTTPS, a server
r= esponding to a query for <https://www.example.com> is expected to
authenticate as "www.example.com". Secu= rity protocols such as TLS and
IPsec accomplish this authentication by a= llowing an endpoint to prove
ownership of a private key whose correspond= ing public key is somehow
bound to the name being authenticated. As a pr= e-requisite for
authentication, then, these protocols require a mechanis= m for bindings
to be asserted between public keys and domain names.
<= BR>DNSSEC provides a mechanism for a domain operator to sign DNS
informa= tion directly, using keys that are bound to the domain by the
parent dom= ain; relying parties can continue this chain up to any trust
anchor that= they accept. In this way, bindings of keys to domains are
asserted not = by external entities, but by the entities that operate the
DNS. In addit= ion, this technique inherently limits the scope of any
given entity to t= he names in zones he controls.

This working group will develop mecha= nisms for domain operators to
present bindings between names within thei= r control and public keys, in
such a way that these bindings can be inte= grity-protected (and thus
shown to be authentically from the domain oper= ator) using DNSSEC and
used as a basis for authentication in protocols t= hat use domain names as
identifiers. Possible starting points for these = deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-link= age-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms d= eveloped by this group will address bindings between
domain names and ke= ys, allowing flexibility for all key-transport
mechanisms supported by t= he application protocols addressed (e.g., both
self-signed and CA-issued= certificates for use in TLS).

The group may also create documents t= hat describe how protocol entities
can discover and validate these bindi= ngs in the execution of specific
applications. This work would be done i= n coordination with the IETF
Working Groups responsible for the protocol= s.

Milestones:
Dec 2010  First WG draft of standards-track p= rotocol for using DNS to
         associate hos= ts with keys for TLS and DTLS
Jan 2011  First WG draft of standards= -track protocols for using DNS to
         asso= ciate hosts with IPsec
Jun 2011  Protocol for using DNS to associat= e domain names with keys
         for TLS and D= TLS to IESG
Aug 2011  Protocols for using DNS to associate domain n= ames with keys
         for IPsec to IESG
Au= g 2011  Recharter
_______________________________________________keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/key= assure



--
Website: http://hallambaker.com/

Regards,
Jeffrey A. Williams
"Obedience of the law is the g= reatest freedom" -
   Abraham Lincoln

"Credit should go= with the performance of duty and not with what is very
often the accide= nt of glory" - Theodore Roosevelt

"If the probability be called P; t= he injury, L; and the burden, B; liability
depends upon whether B is les= s than L multiplied by
P: i.e., whether B is less than PL."
United St= ates v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Updated 1/26/04
CSO/DIR. Internet Network= Eng. SR. Eng. Network data security IDNS. div. of
Information Network E= ng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Ma= il jwkckid1@ix.netcom.com
Phone: 214-244-4827

= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD193A688A; Tue, 26 Oct 2010 13:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToKuX78SnfAr; Tue, 26 Oct 2010 13:08:46 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 6CCB93A6917; Tue, 26 Oct 2010 13:08:46 -0700 (PDT) Received: by yxp4 with SMTP id 4so3525573yxp.31 for ; Tue, 26 Oct 2010 13:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ChAEzRlTVPSC/Pu4zyLpoTgOtazUonbR1whY8WP9lZQ=; b=V0lC4iae/wLZaYcDZEnxasDFqYiYgMGM8X1aRMIO6o40I5dL302GRbwJMm3w7mADF0 U7ND6DM95WEnuMsLvJcg+8u22lMGKGHWjWUX/fL938oQuxIgKEG9xOuFtMxElfakNBzt 2oj4WmheVrNxjMctjaj8Jt4UDWdbO0XQbIFJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PiEwoJq44cmOnklu/88fFUml/nWscvVeXco2vIl++7YXpPwQ9tLiylCnLJGvCrP10t InkcAa65m1T/8gLp8WBGKGD7o8Mu8afvQFjAI7wnITf/d/5O29ckOe0C1NHdGYy+0GnH Cz++No+enil+xf1Q95y9SxfooQruSnkG+o8dI= MIME-Version: 1.0 Received: by 10.151.43.11 with SMTP id v11mr6025788ybj.105.1288123834121; Tue, 26 Oct 2010 13:10:34 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Tue, 26 Oct 2010 13:10:34 -0700 (PDT) In-Reply-To: <20101026170002.14A8C3A6992@core3.amsl.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Tue, 26 Oct 2010 16:10:34 -0400 Message-ID: From: Phillip Hallam-Baker To: iesg@ietf.org Content-Type: multipart/alternative; boundary=00151750eb3e8f401204938ab31a Cc: keyassure@ietf.org, ietf-announce@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:08:50 -0000 --00151750eb3e8f401204938ab31a Content-Type: text/plain; charset=ISO-8859-1 There are two sets of work items being proposed for this group. The first set of work describes mechanisms that allow a domain name owner to use the DNS to establish the validity of a key. I think that this mechanism is entirely logical and useful. DNSSEC is entirely adequate for the purpose of establishing a key as being sufficient to enable use of encryption. The second set of proposals relates to security policy. In particular the TLSFP scheme defines a path validation algorithm that overrides the standard PKIX processing mechanism in two ways. First a certificate that has a valid TLSFP validation path is to be considered valid even if it is a PKIX end entity cert and is invalid under PKIX path math. This may be acceptable but needs to be carefully considered. Secondly, there is an assumption in TLSFP that any domain that publishes CERT records of TLSFP certificate type will publish TLSFP records for ALL valid SSL certs in use for the domain. So the publication of a TLSFP record to enable secure communication on the mail server will cause the SSL certificate on the Web server to be considered invalid. I find this proposal troubling for severalreasons. First it lacks orthogonality. It should be able to use the DNSSEC to establish additional keys without affecting existing trust systems in any way whatsoever. At the very least this behavior should be optional. Secondly, I am not at all convinced that enumeration of valid certificates is a practical method of declaring security policy with respect to TLS trust anchors. PKIX provides a rich set of semantics for validating certificates. I dislike any mechanism that requires the administrator to perform configuration in the DNS for each and every SSL certificate as it is issued. The only way I can see that approach being practical for a public CA would be if the CA took over maintenance of the DNS for the zone as well as the PKI. Thirdly, the percentage of Internet traffic that is encrypted today is negligible. I think that we should make encouraging the use of encryption a higher priority than correcting what some people see as flaws in the trust provision for existing sites. The security policy that has the highest leverage is statements of the form 'always use TLS'. What worries me here is the that the WG should decide to address a single aspect of security policy, address that aspect from a single point of view and then optimize for that single scope. Specification of trust anchors and trust criteria is by far the most complex and difficult part of security policy in my view. I do not see the logic of punting on the high leverage aspects of security policy that are fairly well constrained (always use TLS) and then deciding to address the hardest aspect of security policy in a fashion that is likely to raise severe scaling issues. I think we need to look at security policy separately from the problem of providing new ways to establish keys. I think we need to look at the whole problem of security policy together and not just one aspect of security policy. If we are going to address security policy in stages we should start from the well defined problem of protocol security policy and punt on the difficult issue of trust configuration. On Tue, Oct 26, 2010 at 1:00 PM, IESG Secretary wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination as yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, > November 7, 2010 > > Keys In DNS (kidns) > ----------------------- > Last modified: 2010-10-25 > Current status: Proposed Working Group > > Chairs: > Warren Kumari > Ondrej Sury > > Security Area Directors: > Sean Turner > Tim Polk > > Security Area Advisor: > Tim Polk > > Mailing Lists: > General Discussion: keyassure@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure > Archive: > http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html > > Objective: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS and authenticated using DNSSEC to obtain > public keys which are associated with a service located at a > domain name. > > Problem Statement: > > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. > > Milestones: > Dec 2010 First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > Jan 2011 First WG draft of standards-track protocols for using DNS to > associate hosts with IPsec > Jun 2011 Protocol for using DNS to associate domain names with keys > for TLS and DTLS to IESG > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG > Aug 2011 Recharter > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --00151750eb3e8f401204938ab31a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are two sets of work items being proposed for this group.

The first set of work describes mechanisms that allow a domain name= owner to use the DNS to establish the validity of a key.

I think that this mechanism is entirely logical and useful. DNSS= EC is entirely adequate for the purpose of establishing a key as being suff= icient to enable use of encryption.=A0


The second set of proposals relates to security policy. In particular = the TLSFP scheme defines a path validation algorithm that overrides the sta= ndard PKIX processing mechanism in two ways.

First= a certificate that has a valid TLSFP validation path is to be considered v= alid even if it is a PKIX end entity cert and is invalid under PKIX path ma= th. This may be acceptable but needs to be carefully considered.

Secondly, there is an assumption in TLSFP that any doma= in that publishes CERT records of TLSFP certificate type will publish TLSFP= records for ALL valid SSL certs in use for the domain. So the publication = of a TLSFP record to enable secure communication on the mail server will ca= use the SSL certificate on the Web server to be considered invalid.


I find this proposal troubling for sever= alreasons. First it lacks orthogonality. It should be able to use the DNSSE= C to establish additional keys without affecting existing trust systems in = any way whatsoever. At the very least this behavior should be optional.=A0<= /div>

Secondly, I am not at all convinced that enumeration of= valid certificates is a practical method of declaring security policy with= respect to TLS trust anchors. PKIX provides a rich set of semantics for va= lidating certificates. I dislike any mechanism that requires the administra= tor to perform configuration in the DNS for each and every SSL certificate = as it is issued. The only way I can see that approach being practical for a= public CA would be if the CA took over maintenance of the DNS for the zone= as well as the PKI.=A0

Thirdly, the percentage of Internet traffic that is enc= rypted today is negligible. I think that we should make encouraging the use= of encryption a higher priority than correcting what some people see as fl= aws in the trust provision for existing sites. The security policy that has= the highest leverage is statements of the form 'always use TLS'.

What worries me here is the that the WG should decide t= o address a single aspect of security policy, address that aspect from a si= ngle point of view and then optimize for that single scope.

Specification of trust anchors and trust criteria is by far the = most complex and difficult part of security policy in my view. I do not see= the logic of punting on the high leverage aspects of security policy that = are fairly well constrained (always use TLS) and then deciding to address t= he hardest aspect of security policy in a fashion that is likely to raise s= evere scaling issues.


I think we need to look at security poli= cy separately from the problem of providing new ways to establish keys.

I think we need to look at the whole problem of secur= ity policy together and not just one aspect of security policy. If we are g= oing to address security policy in stages we should start from the well def= ined problem of protocol security policy and punt on the difficult issue of= trust configuration.


On Tue, Oct 26, 2010 at = 1:00 PM, IESG Secretary <iesg-secretary@ietf.org> wrote:
A new IETF working group has been proposed in the Security Area. =A0The IES= G
has not made any determination as yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (ie= sg@ietf.org) by Tuesday,
November 7, 2010

Keys In DNS (kidns)
-----------------------
Last modified: 2010-10-25
Current status: Proposed Working Group

Chairs:
=A0 =A0Warren Kumari <warren@kumar= i.net>
=A0 =A0Ondrej Sury <ondrej.sury@n= ic.cz>

Security Area Directors:
=A0 =A0Sean Turner <turners@ieca.co= m>
=A0 =A0Tim Polk <tim.polk@nist.gov= >

Security Area Advisor:
=A0 =A0Tim Polk <tim.polk@nist.gov= >

Mailing Lists:
=A0 =A0General Discussion: keyassure= @ietf.org
=A0 =A0To Subscribe: =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/= keyassure
=A0 =A0Archive:
http://www.ietf.org/mail-archive/web/keyassure/curr= ent/maillist.html

Objective:
Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through the DNS and authenticated using DNSSEC to obtain
public keys which are associated with a service located at a
domain name.

Problem Statement:

Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for <https://www.example.com> is expected to
authenticate as "= www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS
information directly, using keys that are bound to the domain by the
parent domain; relying parties can continue this chain up to any trust
anchor that they accept. In this way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate the
DNS. In addition, this technique inherently limits the scope of any
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the domain operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms developed by this group will address bindings between
domain names and keys, allowing flexibility for all key-transport
mechanisms supported by the application protocols addressed (e.g., both
self-signed and CA-issued certificates for use in TLS).

The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols.

Milestones:
Dec 2010 =A0First WG draft of standards-track protocol for using DNS to
=A0 =A0 =A0 =A0 =A0associate hosts with keys for TLS and DTLS
Jan 2011 =A0First WG draft of standards-track protocols for using DNS to =A0 =A0 =A0 =A0 =A0associate hosts with IPsec
Jun 2011 =A0Protocol for using DNS to associate domain names with keys
=A0 =A0 =A0 =A0 =A0for TLS and DTLS to IESG
Aug 2011 =A0Protocols for using DNS to associate domain names with keys
=A0 =A0 =A0 =A0 =A0for IPsec to IESG
Aug 2011 =A0Recharter
_______________________________________________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



--
Website: http://hallambaker.com/

--00151750eb3e8f401204938ab31a-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54993A688A; Tue, 26 Oct 2010 13:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt5lzUTgqSjt; Tue, 26 Oct 2010 13:03:21 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A20363A68F0; Tue, 26 Oct 2010 13:03:20 -0700 (PDT) Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9QK52bb032211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Oct 2010 22:05:04 +0200 From: Simon Josefsson To: "Jeffrey A. Williams" References: <33185963.1288122809337.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101026:jwkckid1@ix.netcom.com::Ur3kFmb/Nqpc583u:0vMr X-Hashcash: 1:22:101026:ietf@ietf.org::lzlJc3qhM+wIWmYJ:HRCA X-Hashcash: 1:22:101026:iesg@ietf.org::1Br1abbo54SUH1cL:ZZHS X-Hashcash: 1:22:101026:keyassure@ietf.org::YV0HRieew98XVXbc:k7Cw Date: Tue, 26 Oct 2010 22:05:03 +0200 In-Reply-To: <33185963.1288122809337.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> (Jeffrey A. Williams's message of "Tue, 26 Oct 2010 14:53:29 -0500 (GMT-05:00)") Message-ID: <87sjzs67ps.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 20:03:21 -0000 "Jeffrey A. Williams" writes: >>I object to that limitation. I believe it is important that any >>solution in this space supports different certificates for different >>ports/protocols on the same host. > > Whynot have both. One being a shared cert as acceptable and the > option of one for each? >> >>My experience with how protocols are deployed is that it is common for >>both web (HTTPS) and e-mail (SMTP with STARTTLS) to be hosted on the >>same domain name but with different certificates. >> >>For example, the host "lists.debian.org" is reachable with HTTPS (with a >>matching certificate) and also through SMTP with STARTTLS (also with a >>matching certificate). The services are using different certificates! > > i see nothing wrong with this and conversly nothing wrong with both > using a shared cert for each. Good point -- let me clarify that I believe it should be up to each administrator to decide whether to use one certificate for multiple services or use one certificate per service. A standard in this area should not rule out one alternative. Both alternatives are too common for that. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960563A6849; Tue, 26 Oct 2010 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEUq+cFjEh9C; Tue, 26 Oct 2010 12:51:44 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id F0DF93A686D; Tue, 26 Oct 2010 12:51:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=m/msG4RCrJ/75c8oFjlCvqiWpv1RmfzVhh52tWFeOaaY0rjsYx4Cbvi2M90OoSrb; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PApaL-0002nU-Bb; Tue, 26 Oct 2010 15:53:29 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 26 Oct 2010 15:53:29 -0400 Message-ID: <33185963.1288122809337.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Tue, 26 Oct 2010 14:53:29 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Simon Josefsson , iesg@ietf.org, ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c5477918db86806b8ba3de45fb8f9b64350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 19:51:45 -0000 Simon and all, -----Original Message----- >From: Simon Josefsson >Sent: Oct 26, 2010 2:46 PM >To: iesg@ietf.org, ietf@ietf.org >Cc: keyassure@ietf.org >Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) > >I believe the KIDNS charter is generally good and I support forming this >WG to work on this topic, however I have one important concern: > >> Specify mechanisms and techniques that allow Internet applications to >> establish cryptographically secured communications by using information >> distributed through the DNS and authenticated using DNSSEC to obtain >> public keys which are associated with a service located at a >> domain name. > >I fear this wording will lead to a standards that _requires_ people to >adopt the sloppy security practice to use the same credential for two >(or more) unrelated services. I share this concern. The above refrenced wording needs revision. > >By only locating services by domain name, the separation between ports >(e.g., 443 or 587) and transport protocols (UDP vs TCP) are lost. not lost really but confused, perhaps... > >I object to that limitation. I believe it is important that any >solution in this space supports different certificates for different >ports/protocols on the same host. Whynot have both. One being a shared cert as acceptable and the option of one for each? > >My experience with how protocols are deployed is that it is common for >both web (HTTPS) and e-mail (SMTP with STARTTLS) to be hosted on the >same domain name but with different certificates. > >For example, the host "lists.debian.org" is reachable with HTTPS (with a >matching certificate) and also through SMTP with STARTTLS (also with a >matching certificate). The services are using different certificates! i see nothing wrong with this and conversly nothing wrong with both using a shared cert for each. > >There are other examples, lists.ubuntu.com and even mail.ietf.org, even >if not all appear to support SMTP+STARTTLS. > >Thus, I'd like to see the charter clarify that services are located at a >distinct port/protocol/domain-name rather than only at a domain-name. > >/Simon >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3F43A68CE; Tue, 26 Oct 2010 12:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktFrNFFMzQOP; Tue, 26 Oct 2010 12:44:37 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 0FC393A6804; Tue, 26 Oct 2010 12:44:36 -0700 (PDT) Received: from latte.josefsson.org (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9QJkIfl031364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Oct 2010 21:46:20 +0200 X-Hashcash: 1:22:101026:ietf@ietf.org::TgDAQqZapIqVMGkh:HefP From: Simon Josefsson To: iesg@ietf.org, ietf@ietf.org References: <20101026170002.14A8C3A6992@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101026:keyassure@ietf.org::HkLjyYiOacfrpF5E:2lgL X-Hashcash: 1:22:101026:iesg@ietf.org::yBLwdF2OQBzgbz+3:Dtt3 X-Hashcash: 1:22:101026:ietf-announce@ietf.org::jV+0Jtsi9cXSYYlx:B+j0 Date: Tue, 26 Oct 2010 21:46:19 +0200 In-Reply-To: <20101026170002.14A8C3A6992@core3.amsl.com> (IESG Secretary's message of "Tue, 26 Oct 2010 10:00:01 -0700 (PDT)") Message-ID: <87pquw7n5g.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 19:44:38 -0000 I believe the KIDNS charter is generally good and I support forming this WG to work on this topic, however I have one important concern: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS and authenticated using DNSSEC to obtain > public keys which are associated with a service located at a > domain name. I fear this wording will lead to a standards that _requires_ people to adopt the sloppy security practice to use the same credential for two (or more) unrelated services. By only locating services by domain name, the separation between ports (e.g., 443 or 587) and transport protocols (UDP vs TCP) are lost. I object to that limitation. I believe it is important that any solution in this space supports different certificates for different ports/protocols on the same host. My experience with how protocols are deployed is that it is common for both web (HTTPS) and e-mail (SMTP with STARTTLS) to be hosted on the same domain name but with different certificates. For example, the host "lists.debian.org" is reachable with HTTPS (with a matching certificate) and also through SMTP with STARTTLS (also with a matching certificate). The services are using different certificates! There are other examples, lists.ubuntu.com and even mail.ietf.org, even if not all appear to support SMTP+STARTTLS. Thus, I'd like to see the charter clarify that services are located at a distinct port/protocol/domain-name rather than only at a domain-name. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F8E3A6958 for ; Tue, 26 Oct 2010 11:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0oPIdxOuXkn for ; Tue, 26 Oct 2010 11:53:23 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4AF563A6967 for ; Tue, 26 Oct 2010 11:53:18 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A182CC2EC; Tue, 26 Oct 2010 14:55:04 -0400 (EDT) Date: Tue, 26 Oct 2010 14:55:04 -0400 (EDT) From: Paul Wouters To: Paul Hoffman , =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: Message-ID: References: <20101026170002.14A8C3A6992@core3.amsl.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: keyassure@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 18:53:24 -0000 On Tue, 26 Oct 2010, Paul Hoffman wrote: >> >>> Aug 2011 Protocols for using DNS to associate domain names with keys >>> for IPsec to IESG >> >> How is this different from http://tools.ietf.org/html/rfc4322 ? > > - It might not. Okay. > - It probably will, because RFC 4322 (I think) assumes that the relying party never wants to see if a key can be validated against the relying party's trust anchor store. isn't that local client policy, similar to things like ISAKMP and IPSEC SA lifetime values that are also not negotiated? > - RFC 4322 underwent very light review because it was describing an already-defined protocol that was in the process of being deployed, and it was not intended for standards track. Actually, it was deployed years before. But its deployment never gained traction. One, because we had no DNSSEC, and two because part of the functionality worked on the reverse zones, which basically no clients have access to. > - Implementation experience with RFC 4322 (if there is any outside of the community of its original designers) might bring to light different design choices that can be made by the WG. Sure. Please keep me in the loop especially about this case, as I have a vested interest in it. If any update to RFC 4322 will be proposed, I'm more then happy to sheppard it. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5D63A6827; Tue, 26 Oct 2010 11:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iwRCq9ZG0eu; Tue, 26 Oct 2010 11:34:40 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 45A483A6774; Tue, 26 Oct 2010 11:34:40 -0700 (PDT) Received: by qyk5 with SMTP id 5so3017690qyk.10 for ; Tue, 26 Oct 2010 11:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7Gh/bTBJp7lbHWDiIfU0dUW7FLgwRUkjDcqWXX/JRzU=; b=jQJqQz5djZwKX5/1pIxMk8/z+ALPp+LNGZwz7+xr6S1kzExPD3jw5Fb7AdWkL8hcde l9ywbaQru6owCF00f43dazvYRlwp1uiESsWT+WnHglGOF8GhpMSkwF4AJeLsdkg8llaq HgznjSzxAyr7gUVKbLt25TzEWWK2LNKgpfj6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PRbb48JmaMsbT0prrAZYCjSOkjEKFkDXxTW2sIhC6/ABcFdxPm+PNtCWWj/E0B3NIn mrGiaFCPlRoS5+7gwjgLM+yMBwjkx+fDjc/BGjTDhKFxIZYUhycu1vjjpmofmqkRSN13 bcz9rpWAmkoHa8AVDb/Tw2TeY2+lSwfdsNyIo= MIME-Version: 1.0 Received: by 10.224.214.70 with SMTP id gz6mr1782522qab.104.1288118186609; Tue, 26 Oct 2010 11:36:26 -0700 (PDT) Received: by 10.229.213.69 with HTTP; Tue, 26 Oct 2010 11:36:26 -0700 (PDT) In-Reply-To: <20101026170002.14A8C3A6992@core3.amsl.com> References: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Tue, 26 Oct 2010 11:36:26 -0700 Message-ID: From: Ted Hardie To: iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 26 Oct 2010 14:16:13 -0700 Cc: keyassure@ietf.org, ietf@ietf.org Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 18:34:45 -0000 Howdy, The charter below has the following text: "The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols." The "may" in that statement and the ordering involved throw up a tiny red flag in my head that says "Are we building a technology and then looking for customers, rather than asking customers what technology to build"? (With the parallel that "customers" here are the "protocol enti= ties" which would discover and use these bindings.) The answer appears to be "The customers are TLS and IPSEC". That seems to me a big enough job for a first go-round. I would personally suggest re-chartering to include other potential using protocols when they have been identified, with specific coordination targets at that time Some protocols developed outside the IETF might also want to use this method of binding key materials, for example, and the WG coordination for those might extend beyond IETF WGs. Just my two cents, regards, Ted On Tue, Oct 26, 2010 at 10:00 AM, IESG Secretary wrote: > A new IETF working group has been proposed in the Security Area. =A0The I= ESG > has not made any determination as yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, > November 7, 2010 > > Keys In DNS (kidns) > ----------------------- > Last modified: 2010-10-25 > Current status: Proposed Working Group > > Chairs: > =A0 =A0Warren Kumari > =A0 =A0Ondrej Sury > > Security Area Directors: > =A0 =A0Sean Turner > =A0 =A0Tim Polk > > Security Area Advisor: > =A0 =A0Tim Polk > > Mailing Lists: > =A0 =A0General Discussion: keyassure@ietf.org > =A0 =A0To Subscribe: =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/ke= yassure > =A0 =A0Archive: > http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html > > Objective: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS and authenticated using DNSSEC to obtain > public keys which are associated with a service located at a > domain name. > > Problem Statement: > > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. > > Milestones: > Dec 2010 =A0First WG draft of standards-track protocol for using DNS to > =A0 =A0 =A0 =A0 =A0associate hosts with keys for TLS and DTLS > Jan 2011 =A0First WG draft of standards-track protocols for using DNS to > =A0 =A0 =A0 =A0 =A0associate hosts with IPsec > Jun 2011 =A0Protocol for using DNS to associate domain names with keys > =A0 =A0 =A0 =A0 =A0for TLS and DTLS to IESG > Aug 2011 =A0Protocols for using DNS to associate domain names with keys > =A0 =A0 =A0 =A0 =A0for IPsec to IESG > Aug 2011 =A0Recharter > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48DA3A69D4 for ; Tue, 26 Oct 2010 10:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.424 X-Spam-Level: X-Spam-Status: No, score=-101.424 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUnKJGcEYTjF for ; Tue, 26 Oct 2010 10:32:13 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 12EB43A69A9 for ; Tue, 26 Oct 2010 10:32:13 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9QHXwIw090331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Oct 2010 10:34:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Tue, 26 Oct 2010 10:33:57 -0700 To: Paul Wouters , keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 17:32:15 -0000 At 1:16 PM -0400 10/26/10, Paul Wouters wrote: >On Tue, 26 Oct 2010, IESG Secretary wrote: > >>Aug 2011 Protocols for using DNS to associate domain names with keys >> for IPsec to IESG > >How is this different from http://tools.ietf.org/html/rfc4322 ? - It might not. - It probably will, because RFC 4322 (I think) assumes that the relying party never wants to see if a key can be validated against the relying party's trust anchor store. - RFC 4322 underwent very light review because it was describing an already-defined protocol that was in the process of being deployed, and it was not intended for standards track. - Implementation experience with RFC 4322 (if there is any outside of the community of its original designers) might bring to light different design choices that can be made by the WG. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438CD3A69A6 for ; Tue, 26 Oct 2010 10:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZDd5AFcZyFv for ; Tue, 26 Oct 2010 10:15:09 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0ED953A69C4 for ; Tue, 26 Oct 2010 10:15:08 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 03071C2EC for ; Tue, 26 Oct 2010 13:16:55 -0400 (EDT) Date: Tue, 26 Oct 2010 13:16:55 -0400 (EDT) From: Paul Wouters To: keyassure@ietf.org In-Reply-To: <20101026170002.14A8C3A6992@core3.amsl.com> Message-ID: References: <20101026170002.14A8C3A6992@core3.amsl.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 17:15:12 -0000 On Tue, 26 Oct 2010, IESG Secretary wrote: > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG How is this different from http://tools.ietf.org/html/rfc4322 ? Paul Return-Path: X-Original-To: keyassure@ietf.org Delivered-To: keyassure@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 14A8C3A6992; Tue, 26 Oct 2010 10:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101026170002.14A8C3A6992@core3.amsl.com> Date: Tue, 26 Oct 2010 10:00:01 -0700 (PDT) Cc: keyassure@ietf.org Subject: [keyassure] WG Review: Keys In DNS (kidns) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 17:00:03 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 7, 2010 Keys In DNS (kidns) ----------------------- Last modified: 2010-10-25 Current status: Proposed Working Group Chairs: Warren Kumari Ondrej Sury Security Area Directors: Sean Turner Tim Polk Security Area Advisor: Tim Polk Mailing Lists: General Discussion: keyassure@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS and authenticated using DNSSEC to obtain public keys which are associated with a service located at a domain name. Problem Statement: Entities on the Internet are usually identified using domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and draft-josefsson-keyassure-tls. The mechanisms developed by this group will address bindings between domain names and keys, allowing flexibility for all key-transport mechanisms supported by the application protocols addressed (e.g., both self-signed and CA-issued certificates for use in TLS). The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. Milestones: Dec 2010 First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS Jan 2011 First WG draft of standards-track protocols for using DNS to associate hosts with IPsec Jun 2011 Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG Aug 2011 Protocols for using DNS to associate domain names with keys for IPsec to IESG Aug 2011 Recharter Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF1E3A686D for ; Mon, 25 Oct 2010 10:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpxwqprxzvnH for ; Mon, 25 Oct 2010 10:42:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1DE993A68D2 for ; Mon, 25 Oct 2010 10:42:24 -0700 (PDT) Received: by gxk7 with SMTP id 7so253736gxk.31 for ; Mon, 25 Oct 2010 10:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R6K4Sm2UgyzUmx0T2lOzPBcYqGvarvlHjwn222GUKZA=; b=H/Upnx7GezxkAZm90jtRV4XqXwYJm1hwfd3bHEEk4sNhM5q3ozzLisDfpMccrVS0Di CnLTLS4yt3vMTJyMO5TQc+gxVl1O38LT1oP5zwXlPDMdb3F3Vtkgx4+D0RqhVA0Hg1/0 O7crUWacD9tcv1Kq1X4dbVRmvv19b42sACCf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V0FdJ6BW41LFTMseEIzJ0lChVdWaI5P/ZETbVbAVqBkgTfNWgqw9NyusT47aUANPD/ /2PW6WwZQUfaVvsPW1hYQAjhw/C0b3neDSUrVVm2AATbwLFmfFwXoWrkaDGloKFdCSZB PkaQINxzi1l4+ooi0W7DBHIbyb/8uWB48XLtw= MIME-Version: 1.0 Received: by 10.100.10.13 with SMTP id 13mr2426690anj.192.1288028648402; Mon, 25 Oct 2010 10:44:08 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Mon, 25 Oct 2010 10:44:08 -0700 (PDT) In-Reply-To: References: <8762wqquzs.fsf@mocca.josefsson.org> Date: Mon, 25 Oct 2010 13:44:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6464da60c6d8f0493748a56 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:42:25 -0000 --0016e6464da60c6d8f0493748a56 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 25, 2010 at 12:26 PM, Paul Wouters wrote: > On Mon, 25 Oct 2010, Paul Hoffman wrote: > > The common practice is to give each server application its own domain >> name. This is not the only practice, but it is common. You want to not >> require that practice, at a cost of the DNS administrator needing to add >> some extra information in the DNS, and the client app needed to request that >> information. The question is whether the cost to everyone of those additions >> to the protocol are worth the benefit for the few who do not have unique >> domain names for each server application. I claim the cost to everyone is >> not worth the benefit to the few, but others may disagree. >> > > I would say the world is moving in the other direction. You use "cnn.com" > and "twitter.com", not www.cnn.com or www.twitter.com. > I am PaulWouters@jabber.org, not PaulWouters@jabber.jabber.org. > > If anything, we are trying to reduce the combinations of http/https/www/ > methods of reaching a website into one. > > Using a port specifier would in my opinion be very useful. It will also > reduce the number of records returned that have > to be checked by the client that is only interested in one particular > service/port. But we have to be careful not to > increase the amount of queries by missing the right port. At one point I had the following scheme: _80._http._tcp.example.com That runs into corner cases with CNAME. In particular: _80._http._tcp.www.example.com XXX "blah...." www.example.com CNAME example.com Trying to write discovery rules that are consistent and efficient and work with both CNAME and wildcards tend to fail round prefixes unless you can write the rules in such a way that the first lookup you do is always for an unprefixed record. Once past your first lookup you can use prefixes without issue. -- Website: http://hallambaker.com/ --0016e6464da60c6d8f0493748a56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 25, 2010 at 12:26 PM, Paul W= outers <paul@xel= erance.com> wrote:
On Mon, 25 Oct 2010, Paul Hoffman wrote:

The common practice is to give each server application its own domain name.= This is not the only practice, but it is common. You want to not require t= hat practice, at a cost of the DNS administrator needing to add some extra = information in the DNS, and the client app needed to request that informati= on. The question is whether the cost to everyone of those additions to the = protocol are worth the benefit for the few who do not have unique domain na= mes for each server application. I claim the cost to everyone is not worth = the benefit to the few, but others may disagree.

I would say the world is moving in the other direction. You use "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com.
I am PaulWouter= s@jabber.org, not PaulWouters@jabber.jabber.org.

If anything, we are trying to reduce the combinations of http/https/www/ me= thods of reaching a website into one.

Using a port specifier would in my opinion be very useful. It will also red= uce the number of records returned that have
to be checked by the client that is only interested in one particular servi= ce/port. But we have to be careful not to
increase the amount of queries by missing the right port.
=

At one point I had the following scheme:


That runs into corner cases with CNAME. In particular:<= /div>

_80._http._tcp.www.example.com XXX "blah...."


=
Trying to write discovery rules that are consistent and efficient and = work with both CNAME and wildcards tend to fail round prefixes unless you c= an write the rules in such a way that the first lookup you do is always for= an unprefixed record. Once past your first lookup you can use prefixes wit= hout issue.


--
Website: http://hallambaker.com/

--0016e6464da60c6d8f0493748a56-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453043A6ADC for ; Mon, 25 Oct 2010 10:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axCL7t9RLScs for ; Mon, 25 Oct 2010 10:35:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 6F2763A6B1F for ; Mon, 25 Oct 2010 10:35:08 -0700 (PDT) Received: by ywp6 with SMTP id 6so1790844ywp.31 for ; Mon, 25 Oct 2010 10:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0XILgo4Otyuh0aiuvlRecaSqlsaY+VRIyYUvbM4P+tE=; b=vezWRHG2+z0Z6LtG8/oG/m5tSJfUI4Il2ZiBdBQOesflbr9gO8se5sprGvb1ZM+V3V 2plWjQ8CQzrCP6F/xvmy4mEoyKQOS5cbi1WsKpHnaG/Vf3cugCad0Pq2MtbRS6QTkwKA FJIkki3/lfwor1+M/MqlQNQANDdZFM6j+boGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=STEO6QlDLMc4kkkdCeh1tln+lyDZ5JuCEGGN2KzkOwwBHdSWfzBOG8MW+yM3VXL+M5 YXT32+XsVPvvxPb653tEWOztV+j0Gbc53tfSn7fCi4zUGNgvFgGG6LzFZ/Fv5iWuzCVG FehGUpQZQf0C13r6lCpoBneVUwJk4U4zyikJo= MIME-Version: 1.0 Received: by 10.100.131.18 with SMTP id e18mr5741125and.148.1288028209573; Mon, 25 Oct 2010 10:36:49 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Mon, 25 Oct 2010 10:36:49 -0700 (PDT) In-Reply-To: References: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> Date: Mon, 25 Oct 2010 13:36:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=0016e6434aeee472440493746f60 Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:35:17 -0000 --0016e6434aeee472440493746f60 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 25, 2010 at 12:47 PM, Ben Laurie wrote: > Sorry for the delay.. > > Looking at the -01 version... > > "The authorizations specified in the dauth and pauth properties are > additive." > > I'm not sure "additive" is the right word - certainly it leaves me > wondering "does that mean 'and' or 'or'?". Later text confirms "or", > which was not my guess. > I had difficulty drafting that. I think that the problem is that I should be using the term 'permission' or 'authorization entry'. > Why restrict tag length in the CAA RR? > The tags are from an assigned space. The only protocol constraint I would really insist on is that the tag length needs to be expressible in a single byte. Do we really think we will need more than 2^16 different tags in a data record that has to fit into a 65535 byte space? > "An ASN.1 DER encoded data field containing the digest value of the > referenced object processed using the specified digest algorithm." > > I don't think this is an unambiguous specification - you have to > specify the ASN.1... > I am not sure what point you were going to make here. I am sure that there can be some byte sex issues that enter into things here. Some digest algorithms have more than one OID assigned. But the ones we currently recommend in IETF specs have exactly one OID assignment across all specifications, the one assigned by NIST. And this should be the same for the SHA-3 algorithms as well. One other point that was raised was that some people would like to have the ODI data wrapped in an ASN.1 tag, length container as well. > " Use of DNSSEC to authenticate CAA RRs is strongly recommended but not > required. A CA MUST observe a CAA RR that is returned whether it is > signed using DNSSEC or not." > > Fine - but I think it should say that applications MUST NOT observe a > CAA RR that is not signed. > OK, that is fair enough. I am thinking that we may want to differentiate between authority to issue and authority for relying parties. The issue authority statements refer to what an issuer is authorized to do during the validity interval for the record. But the fact that an issuer is no longer authorized to issue new certificates does not invalidate the certificates they have already issued. So the statement for relying parties may well contain more entries. > 4.2 should note that DNSSEC effectively prevents either suppression or > spoofing. > > Other than that, looks good to me That must have got lost in the editing. > On 19 October 2010 03:17, Phillip Hallam-Baker wrote: > > Adam L. pointed out some typos and so on. I had to get it in today and I > am > > fighting off a cold. > > > > As we discussed in the call, we are very interested in having Google > > co-author if you are interested. > > > > CA buy-in is not so much of a worry for me. Comodo will deploy for > certain > > and Symantec/VeriSignCA is pretty likely to follow. > > Assume for a moment that other CAs don't follow our lead and end up > > mis-issuing against a domain that has a CAA record. What do you think > their > > liability is in that case? They certainly have a major PR issue at that > > point and their only realistic chance of surviving it without too much > > damage is going to be to deploy CAA. > > > > So all in all, I think that the chances are pretty good that we can > present > > this as a win for all concerned. > > > > You may also be interested in my DPLS draft: > > http://www.ietf.org/id/draft-hallambaker-dpls-00.txt > > A lot of the DNS performance issues go away if the DNS client can ask its > > resolver 'hey give me all the info I need to do this with that'. > > > > On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari > wrote: > >> > >> I have not yet read the whole draft, but so far I really like it. > >> > >> While (as you already pointed out) it doesn't solve all of the issues, > it > >> does go a long way towards improving matters, assuming of course the CAs > buy > >> in... > >> > >> W > >> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote: > >> > >> > This is a draft that I submitted this morning. The main proposal being > >> > made here is to enable Certification Authorities to avoid mis-issue. > >> > > >> > As such I believe that it is complimentary to mechanisms that enable > >> > client side enforcement but has the considerable advantage of offering > >> > immediate protection to every Internet user regardless of whether they > have > >> > an updated browser. It is also much less strongly dependent on > deployment of > >> > DNSSEC. > >> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt > >> > > >> > > >> > Given the nature of the proposal, it is probably better suited to > having > >> > the bulk of the legal-technical work considered in CABForum rather > than > >> > IETF. Accordingly the proposal is designed to allow the technical > >> > infrastructure to be agreed in IETF and then the practices and legal > work > >> > done in CABForum. > >> > > >> > Clearly a record of this type could be used to effect client policy > >> > enforcement mechanisms. But this is a rather more complex issue and > there > >> > are going to be a lot of people with views on the best way forward. > >> > > >> > The mechanism as specified is sufficient for allowing client side > >> > enforcement as it stands if the site is using a public CA, running a > local > >> > CA cross certified into a public hierarchy or using a standalone > private CA. > >> > But only if those infrastructures are supporting all their > applications > >> > without exception. > >> > > >> > > >> > -- > >> > Website: http://hallambaker.com/ > >> > > >> > _______________________________________________ > >> > keyassure mailing list > >> > keyassure@ietf.org > >> > https://www.ietf.org/mailman/listinfo/keyassure > >> > > > > > > > > -- > > Website: http://hallambaker.com/ > > > > > > _______________________________________________ > > keyassure mailing list > > keyassure@ietf.org > > https://www.ietf.org/mailman/listinfo/keyassure > > > > > -- Website: http://hallambaker.com/ --0016e6434aeee472440493746f60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2010 at 12:47 PM, Ben Laurie <benl@google.com> wrote:
Sorry for the delay..

Looking at the -01 version...

"The authorizations specified in the dauth and pauth properties are =A0 additive."

I'm not sure "additive" is the right word - certainly it leav= es me
wondering "does that mean 'and' or 'or'?". Later = text confirms "or",
which was not my guess.

I had difficult= y drafting that. I think that the problem is that I should be using the ter= m 'permission' or 'authorization entry'.

=A0
Why restrict tag length in the CAA RR?

= The tags are from an assigned space. The only protocol constraint I would r= eally insist on is that the tag length needs to be expressible in a single = byte.

Do we really think we will need more than 2^16 differen= t tags in a data record that has to fit into a 65535 byte space?
=
=A0
"An ASN.1 DER encoded data field containing the digest value of the =A0 =A0 =A0referenced object processed using the specified digest algorith= m."

I don't think this is an unambiguous specification - you have to
specify the ASN.1...

I am not sure what= point you were going to make here.

I am sure that= there can be some byte sex issues that enter into things here.

Some digest algorithms have more than one OID assigned. But = the ones we currently recommend in IETF specs have exactly one OID assignme= nt across all specifications, the one assigned by NIST. And this should be = the same for the SHA-3 algorithms as well.

One other point that was raised was that some people wo= uld like to have the ODI data wrapped in an ASN.1 tag, length container as = well.

=A0
" =A0 Use of DNSSEC to authenticate CAA RRs is strongly recommended bu= t not
=A0 required. =A0A CA MUST observe a CAA RR that is returned whether it is=
=A0 signed using DNSSEC or not."

Fine - but I think it should say that applications MUST NOT observe a
CAA RR that is not signed.

OK, that is = fair enough.

I am thinking that we may want to dif= ferentiate between authority to issue and authority for relying parties.

The issue authority statements refer to what an issuer = is authorized to do during the validity interval for the record.=A0

But the fact that an issuer is no longer authorized to is= sue new certificates does not invalidate the certificates they have already= issued. So the statement for relying parties may well contain more entries= .

=A0
4.2 should note that DNSSEC effectively prevents either suppression or spoo= fing.

Other than that, looks good to me

That must= have got lost in the editing.=A0

=A0
On 19 October 2010 03:17, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Adam L. pointed out some typos and so on. I had to get it in today and= I am
> fighting off a cold.
>
> As we discussed in the call, we are very interested in having Google > co-author if you are interested.
>
> CA buy-in is not so much of a worry for me. Comodo will deploy for cer= tain
> and Symantec/VeriSignCA is pretty likely to follow.
> Assume for a moment that other CAs don't follow our lead and end u= p
> mis-issuing against a domain that has a CAA record. What do you think = their
> liability is in that case? They certainly have a major PR issue at tha= t
> point and their only realistic chance of surviving it without too much=
> damage is going to be to deploy CAA.
>
> So all in all, I think that the chances are pretty good that we can pr= esent
> this as a win for all concerned.
>
> You may also be interested in my DPLS draft:
> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt
> A lot of the DNS performance issues go away if the DNS client can ask = its
> resolver 'hey give me all the info I need to do this with that'= ;.
>
> On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <warren@kumari.net> wrote:
>>
>> I have not yet read the whole draft, but so far I really like it.<= br> >>
>> While (as you already pointed out) it doesn't solve all of the= issues, it
>> does go a long way towards improving matters, assuming of course t= he CAs buy
>> in...
>>
>> W
>> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote:
>>
>> > This is a draft that I submitted this morning. The main propo= sal being
>> > made here is to enable Certification Authorities to avoid mis= -issue.
>> >
>> > As such I believe that it is complimentary to mechanisms that= enable
>> > client side enforcement but has the considerable advantage of= offering
>> > immediate protection to every Internet user regardless of whe= ther they have
>> > an updated browser. It is also much less strongly dependent o= n deployment of
>> > DNSSEC.
>> > http://www.ietf.org/id/draft-hallambaker-donoti= ssue-00.txt
>> >
>> >
>> > Given the nature of the proposal, it is probably better suite= d to having
>> > the bulk of the legal-technical work considered in CABForum r= ather than
>> > IETF. Accordingly the proposal is designed to allow the techn= ical
>> > infrastructure to be agreed in IETF and then the practices an= d legal work
>> > done in CABForum.
>> >
>> > Clearly a record of this type could be used to effect client = policy
>> > enforcement mechanisms. But this is a rather more complex iss= ue and there
>> > are going to be a lot of people with views on the best way fo= rward.
>> >
>> > The mechanism as specified is sufficient for allowing client = side
>> > enforcement as it stands if the site is using a public CA, ru= nning a local
>> > CA cross certified into a public hierarchy or using a standal= one private CA.
>> > But only if those infrastructures are supporting all their ap= plications
>> > without exception.
>> >
>> >
>> > --
>> > Website: http://hallambaker.com/
>> >
>> > _______________________________________________
>> > keyassure mailing list
>> > keyassure@ietf.org<= br> >> > https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> --
> Website: http://= hallambaker.com/
>
>
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>
>



--
Website: http://hallambaker.com/

--0016e6434aeee472440493746f60-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1853A6B7C for ; Mon, 25 Oct 2010 10:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4fjmRaCwZlw for ; Mon, 25 Oct 2010 10:10:18 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 492103A6A62 for ; Mon, 25 Oct 2010 10:10:18 -0700 (PDT) Received: by gya6 with SMTP id 6so2463305gya.31 for ; Mon, 25 Oct 2010 10:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ex8a62z4YVVQT0nX0A/C0ZdiC1ERO36DUuiFbEEhq70=; b=OxjKC1W6IBCrffuGhXCmLwKlsO/ECYnVwXb50N1fTGpdKLpG0tH4xe1kmgh/sBzQhB amEOoZa+wcBoeTj41YJj/dRu0pybsMFCZtNB+Xbl18mx23DQX7BsaL8Pfb/U3/RASaCA omokqHGklYuOPMmGCazExbMTswbFUeJjCcy60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OFSLIsoYK5+BIKTFjfaFX2Dl17d94s1FvxGxdr7o9tM69q6zbXLak9lYD8ZR1hRo3q GDJ1VAfhusrWlKMFN88AatiiYRzFoXeJPjplcOwyVeWcL97cKvvWKtUQ5zSmRU+L7LVI F690G+zKg59jsLVa0E3vhEM4e7TJj8A8h3K5c= MIME-Version: 1.0 Received: by 10.100.10.15 with SMTP id 15mr5762766anj.9.1288026723334; Mon, 25 Oct 2010 10:12:03 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Mon, 25 Oct 2010 10:12:03 -0700 (PDT) In-Reply-To: References: <8762wqquzs.fsf@mocca.josefsson.org> Date: Mon, 25 Oct 2010 13:12:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e64652fa4e3d9104937417e0 Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:10:20 -0000 --0016e64652fa4e3d9104937417e0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 25, 2010 at 10:51 AM, Paul Hoffman wrote: > > The common practice is to give each server application its own domain name. > This is not the only practice, but it is common. You want to not require > that practice, at a cost of the DNS administrator needing to add some extra > information in the DNS, and the client app needed to request that > information. The question is whether the cost to everyone of those additions > to the protocol are worth the benefit for the few who do not have unique > domain names for each server application. I claim the cost to everyone is > not worth the benefit to the few, but others may disagree. I don't think that this group is going to be allowed to make that decision. The reason that we have an IESG and an IAB is to prevent WGs introducing additional assumptions into the architecture that hobble other groups in the future. That said, I think it is the wrong approach because it will stop applications being written to automatically produce the appropriate DNS records. [see later] > At 10:02 AM -0400 10/25/10, Phillip Hallam-Baker wrote: > >Whether this is an issue or not depends on whether the semantics are "here > is a key you can use" or "here are the only keys you can use" > > Correct. And the very strong impression I was left with after my discussion with Tim was that we would have to solve #1 before being allowed to go to #2. > >It has to be possible to use dnssec to establish a key for a mail server > that lives on the same dns node as a Web server without affecting operation > of the Web server in any way. > > Can you say more about why you have this requirement? When the DNS protocol > prevents you from doing something at one level but completely allows you do > do something by creating another name within a subordinate namespace, what > makes it so required that you only do things at the top-level name? There > are lots of other examples of such requirements in the DNS protocol; why is > this one so important? For example, Alice installs sendmail on example.com. There is no way for a script to determine that there is a HTTP server on example.com. It might be a completely fresh install of the OS and the admin installed sendmail before apache. It would be really nice if sendmail could just spin up a self signed keypair and propose a DNS CERT record. But it isn't going to be able to do that if there is any risk of affecting the Web service. Using CERT records that establish keys and restrict at the same time means that the sendmail script would likely disable more than a few Web servers. Now we could address SMTP by insisting on a different name for the hosts declared in the MX record. But we can't do that for IMAP or any other protocol which does not have SRV discovery as a requirement. [We do in any case have to consider and describe what is done to handle CNAMEs, DNAMEs, SRV records and any other record that causes name substitution to take place.] I think that we can square this circle, but we will need another RR to do so. or rather, we could try to cram the information into the CERT record but I think that would get a lot of pushback. Since one of the base assumptions here is that we are going to be using DNSSEC, we should expect that the infrastructure that will allow that data through will have support for using unknown RRs. So lets imagine we introduce one new RR 'Server Security Policy'. The SSP record may be used in either a prefixed form or an unprefixed form. The rules for using SSP is that a client attempting to connect to a service at x.example.com will always query for the SSP record for x.example.com. If the SSP record exists, it MAY apply to every service at example.com or it MAY have a flag that says 'lookup protocol prefixed SSP' or it may have a flag that says 'lookup SRV and then lookup SSP' (etc.) In either case the SSP record MAY specify security policies such as 'always use SSL' or 'valid certs MUST conform to specification Y'. This approach allows for root restriction to be by requiring there to be a companion CERT record or by inclusion of a specific policy OID or existence of a trust chain to a specific certificate signing certificate. That is what I would anticipate as a requirement since using the DNS to distribute certificate assurance data is going to be considered 'research' and there is a longstanding resistance to building research on research. Looking through the decision tree, the overhead is one additional DNS lookup that is made in parallel with the A and AAAA lookup for the case that no SSP record exists. In the case that there is an SSP record, the overhead depends on how the DNS resolver is tuned. If the resolver is tuned to optimize SSP lookup (e.g. using DPLS) the entire lookup can be performed in one round trip in every single case. -- Website: http://hallambaker.com/ --0016e64652fa4e3d9104937417e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 25, 2010 at 10:51 AM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
The common practice is to give each server application its own domain name.= This is not the only practice, but it is common. You want to not require t= hat practice, at a cost of the DNS administrator needing to add some extra = information in the DNS, and the client app needed to request that informati= on. The question is whether the cost to everyone of those additions to the = protocol are worth the benefit for the few who do not have unique domain na= mes for each server application. I claim the cost to everyone is not worth = the benefit to the few, but others may disagree.

I don't think that this group is going to be allowe= d to make that decision. The reason that we have an IESG and an IAB is to p= revent WGs introducing additional assumptions into the architecture that ho= bble other groups in the future.

That said, I think it is the wrong approach because it = will stop applications being written to automatically produce the appropria= te DNS records. [see later]

=A0
At 10:02 AM -0400 10/25/10, Phillip Hallam-Baker wrote:
>Whether this is an issue or not depends on whether the semantics are &q= uot;here is a key you can use" or "here are the only keys you can= use"

Correct.

And the very strong impressi= on I was left with after my discussion with Tim was that we would have to s= olve #1 before being allowed to go to #2.

=A0
>It has to be possible to use dnssec to establish a key for a mail serve= r that lives on the same dns node as a Web server without affecting operati= on of the Web server in any way.

Can you say more about why you have this requirement? When the DNS pr= otocol prevents you from doing something at one level but completely allows= you do do something by creating another name within a subordinate namespac= e, what makes it so required that you only do things at the top-level name?= There are lots of other examples of such requirements in the DNS protocol;= why is this one so important?

For example, Alice installs sen= dmail on example.com. There is no way fo= r a script to determine that there is a HTTP server on example.com. It might be a completely fresh install of the O= S and the admin installed sendmail before apache.=A0

It would be really nice if sendmail could just spin up = a self signed keypair and propose a DNS CERT record. But it isn't going= to be able to do that if there is any risk of affecting the Web service. U= sing CERT records that establish keys and restrict at the same time means t= hat the sendmail script would likely disable more than a few Web servers.

Now we could address SMTP by insisting on a different n= ame for the hosts declared in the MX record. But we can't do that for I= MAP or any other protocol which does not have SRV discovery as a requiremen= t.

[We do in any case have to consider and describe what i= s done to handle CNAMEs, DNAMEs, SRV records and any other record that caus= es name substitution to take place.]


I think that we can square this circle, but we will need another RR to= do so. or rather, we could try to cram the information into the CERT recor= d but I think that would get a lot of pushback.

Since one of the base assumptions here is that we are going to be using DNS= SEC, we should expect that the infrastructure that will allow that data thr= ough will have support for using unknown RRs.


So lets imagine we introduce one new RR 'Server Security= Policy'.

The SSP record may be used in either= a prefixed form or an unprefixed form. The rules for using SSP is that a c= lient attempting to connect to a service at x.example.com will always query for the SSP record for x.example.com.=A0

If the SSP record exists, it MAY apply to every service= at example.com or it MAY have a flag th= at says 'lookup protocol prefixed SSP' or it may have a flag that s= ays 'lookup SRV and then lookup SSP' (etc.)

In either case the SSP record MAY specify security poli= cies such as 'always use SSL' or 'valid certs MUST conform to s= pecification Y'.


This approach = allows for root restriction to be by requiring there to be a companion CERT= record or by inclusion of a specific policy OID or existence of a trust ch= ain to a specific certificate signing certificate.

That is what I would anticipate as a requirement since = using the DNS to distribute certificate assurance data is going to be consi= dered 'research' and there is a longstanding resistance to building= research on research.


Looking through the decision tree, the o= verhead is one additional DNS lookup that is made in parallel with the A an= d AAAA lookup for the case that no SSP record exists.

In the case that there is an SSP record, the overhead depends on how t= he DNS resolver is tuned. If the resolver is tuned to optimize SSP lookup (= e.g. using DPLS) the entire lookup can be performed in one round trip in ev= ery single case.


--
Website: http://hallambaker.com/

--0016e64652fa4e3d9104937417e0-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4088B3A6A9E for ; Mon, 25 Oct 2010 09:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.69 X-Spam-Level: X-Spam-Status: No, score=-105.69 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+f8ThNGCH4u for ; Mon, 25 Oct 2010 09:46:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 0EA783A6B05 for ; Mon, 25 Oct 2010 09:46:08 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o9PGlrsJ003626 for ; Mon, 25 Oct 2010 09:47:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1288025273; bh=oZW4x3G9o3ryyLzARFH8YVnzPPs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qcaou47UdJnOj7Trnz2EFh78Y3TywtvoTW7VHxY8s/rYryoexf4CmnFSeocJWDKTQ tNB3VQljyYbMfeVS/uwjQ== Received: from pva18 (pva18.prod.google.com [10.241.209.18]) by hpaq5.eem.corp.google.com with ESMTP id o9PGlpKa027378 for ; Mon, 25 Oct 2010 09:47:52 -0700 Received: by pva18 with SMTP id 18so881954pva.17 for ; Mon, 25 Oct 2010 09:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Sgfy0+jQVjYTMmGi77V70peXCSKxCRgSgGmtq0xZGqk=; b=gneqExSv0O6xQ9wQSAJ1mwXnOyPboBPDPRvRbLLdfFw8UO8b8+BqCgQS4mxJkomVVx B9x7eKwKewLaOXQjPC2w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xFTT2+cQczhny190VNQncIqewoZ1wR8zuco7dr3ugzPVCecKz3hLMgpJQ+GtKyiapd qR43VwwmlmUNmNRSOCHw== MIME-Version: 1.0 Received: by 10.142.192.5 with SMTP id p5mr5346875wff.300.1288025271119; Mon, 25 Oct 2010 09:47:51 -0700 (PDT) Received: by 10.142.13.17 with HTTP; Mon, 25 Oct 2010 09:47:51 -0700 (PDT) In-Reply-To: References: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> Date: Mon, 25 Oct 2010 17:47:51 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:46:11 -0000 Sorry for the delay.. Looking at the -01 version... "The authorizations specified in the dauth and pauth properties are additive." I'm not sure "additive" is the right word - certainly it leaves me wondering "does that mean 'and' or 'or'?". Later text confirms "or", which was not my guess. Why restrict tag length in the CAA RR? "An ASN.1 DER encoded data field containing the digest value of the referenced object processed using the specified digest algorithm." I don't think this is an unambiguous specification - you have to specify the ASN.1... " Use of DNSSEC to authenticate CAA RRs is strongly recommended but not required. A CA MUST observe a CAA RR that is returned whether it is signed using DNSSEC or not." Fine - but I think it should say that applications MUST NOT observe a CAA RR that is not signed. 4.2 should note that DNSSEC effectively prevents either suppression or spoofing. Other than that, looks good to me. On 19 October 2010 03:17, Phillip Hallam-Baker wrote: > Adam L. pointed out some typos and so on. I had to get it in today and I am > fighting off a cold. > > As we discussed in the call, we are very interested in having Google > co-author if you are interested. > > CA buy-in is not so much of a worry for me. Comodo will deploy for certain > and Symantec/VeriSignCA is pretty likely to follow. > Assume for a moment that other CAs don't follow our lead and end up > mis-issuing against a domain that has a CAA record. What do you think their > liability is in that case? They certainly have a major PR issue at that > point and their only realistic chance of surviving it without too much > damage is going to be to deploy CAA. > > So all in all, I think that the chances are pretty good that we can present > this as a win for all concerned. > > You may also be interested in my DPLS draft: > http://www.ietf.org/id/draft-hallambaker-dpls-00.txt > A lot of the DNS performance issues go away if the DNS client can ask its > resolver 'hey give me all the info I need to do this with that'. > > On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari wrote: >> >> I have not yet read the whole draft, but so far I really like it. >> >> While (as you already pointed out) it doesn't solve all of the issues, it >> does go a long way towards improving matters, assuming of course the CAs buy >> in... >> >> W >> On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote: >> >> > This is a draft that I submitted this morning. The main proposal being >> > made here is to enable Certification Authorities to avoid mis-issue. >> > >> > As such I believe that it is complimentary to mechanisms that enable >> > client side enforcement but has the considerable advantage of offering >> > immediate protection to every Internet user regardless of whether they have >> > an updated browser. It is also much less strongly dependent on deployment of >> > DNSSEC. >> > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt >> > >> > >> > Given the nature of the proposal, it is probably better suited to having >> > the bulk of the legal-technical work considered in CABForum rather than >> > IETF. Accordingly the proposal is designed to allow the technical >> > infrastructure to be agreed in IETF and then the practices and legal work >> > done in CABForum. >> > >> > Clearly a record of this type could be used to effect client policy >> > enforcement mechanisms. But this is a rather more complex issue and there >> > are going to be a lot of people with views on the best way forward. >> > >> > The mechanism as specified is sufficient for allowing client side >> > enforcement as it stands if the site is using a public CA, running a local >> > CA cross certified into a public hierarchy or using a standalone private CA. >> > But only if those infrastructures are supporting all their applications >> > without exception. >> > >> > >> > -- >> > Website: http://hallambaker.com/ >> > >> > _______________________________________________ >> > keyassure mailing list >> > keyassure@ietf.org >> > https://www.ietf.org/mailman/listinfo/keyassure >> > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64C53A6AC2 for ; Mon, 25 Oct 2010 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49WZre7jv81p for ; Mon, 25 Oct 2010 09:34:48 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E34DF3A6ACA for ; Mon, 25 Oct 2010 09:34:46 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D756FC2F9; Mon, 25 Oct 2010 12:36:31 -0400 (EDT) Date: Mon, 25 Oct 2010 12:36:31 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: <3F123170-C2C7-4586-A92B-D58E79AA4FBC@gmail.com> Message-ID: References: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> <489A09CF-F710-4806-B8D9-49B52C27F42A@kirei.se> <3F123170-C2C7-4586-A92B-D58E79AA4FBC@gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:34:55 -0000 On Mon, 25 Oct 2010, Phillip Hallam-Baker wrote: > In theory that should be the case. In practice the transfer of dns names is rather more complex. I have been trying to find documentation on the controls. They may not be public or they may not exist. > > If you want to demonstrate that one system is more secure than the other you have to apply the same standard of scruitiny to both systems. The same applies for chaining security systems (DNSSEC and CA's). I remember when crpytophone people did not trust one cipher, and Rudi Weiss had to prove that (AES->3DES->blowfish) was at least as secure as the weakest component in that list. Which he did in a paper that went beyond my math skills. Entangling CA's and DNSSEC would need some proof that it is more secure then its individual components. With some strong weaknesses in the CA deployments and omnipotent trust wielders, I am extremely skeptical this can be done. And the price to pay is to deal with many corner cases because unlike chained chiphers, this entangled system would not have a clear serial flow through it. Contradictions would be possible, and then we run into many interpretations and implementations as to how to address these. The reason (IMHO) that we are doing anything in the ASN.1 space at all for DNSSEC is that we have to deal with X.509 in SSL/TLS. But I think this discussion has already been seen on this list various times, so I'll refrain from further firing up this discussion *again* Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0BB3A6A10 for ; Mon, 25 Oct 2010 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4FQAF6hHXXa for ; Mon, 25 Oct 2010 09:24:43 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id BC4F83A6A04 for ; Mon, 25 Oct 2010 09:24:43 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id C7886C2F9; Mon, 25 Oct 2010 12:26:27 -0400 (EDT) Date: Mon, 25 Oct 2010 12:26:27 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <8762wqquzs.fsf@mocca.josefsson.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:24:44 -0000 On Mon, 25 Oct 2010, Paul Hoffman wrote: > The common practice is to give each server application its own domain name. This is not the only practice, but it is common. You want to not require that practice, at a cost of the DNS administrator needing to add some extra information in the DNS, and the client app needed to request that information. The question is whether the cost to everyone of those additions to the protocol are worth the benefit for the few who do not have unique domain names for each server application. I claim the cost to everyone is not worth the benefit to the few, but others may disagree. I would say the world is moving in the other direction. You use "cnn.com" and "twitter.com", not www.cnn.com or www.twitter.com. I am PaulWouters@jabber.org, not PaulWouters@jabber.jabber.org. If anything, we are trying to reduce the combinations of http/https/www/ methods of reaching a website into one. Using a port specifier would in my opinion be very useful. It will also reduce the number of records returned that have to be checked by the client that is only interested in one particular service/port. But we have to be careful not to increase the amount of queries by missing the right port. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103273A68B8 for ; Mon, 25 Oct 2010 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Tj7wa+AfN6d for ; Mon, 25 Oct 2010 07:50:53 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 226373A6A4A for ; Mon, 25 Oct 2010 07:50:46 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9PEqUTs001398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Oct 2010 07:52:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8762wqquzs.fsf@mocca.josefsson.org> References: <8762wqquzs.fsf@mocca.josefsson.org> Date: Mon, 25 Oct 2010 07:51:45 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 14:50:54 -0000 At 3:09 PM +0200 10/25/10, Simon Josefsson wrote: >Paul Hoffman writes: > >>>For instance, example.com might have a TLS cert for SMTP, but not for >>>HTTPS. Querying the DNS for a cert record will not tell me I can connect >>>on HTTPS to that server. >> >> That is correct. It is not correct, however, if you query for >> www.example.com and mail.example.com: then you do know that the >> services at each of those two hosts (which might reside on the same >> box) use TLS. > >One part that I disliked was that you don't separate on port. So it is >not possible to query for a TLS fingerprint for certificate used on port >X and do the same for port Y without having to match them all. I >believe this primarily makes it difficult to deploy, because it is >difficult to separate DNS privileges between the people responsible for >the different services. The common practice is to give each server application its own domain name. This is not the only practice, but it is common. You want to not require that practice, at a cost of the DNS administrator needing to add some extra information in the DNS, and the client app needed to request that information. The question is whether the cost to everyone of those additions to the protocol are worth the benefit for the few who do not have unique domain names for each server application. I claim the cost to everyone is not worth the benefit to the few, but others may disagree. At 10:02 AM -0400 10/25/10, Phillip Hallam-Baker wrote: >Whether this is an issue or not depends on whether the semantics are "here is a key you can use" or "here are the only keys you can use" Correct. >It has to be possible to use dnssec to establish a key for a mail server that lives on the same dns node as a Web server without affecting operation of the Web server in any way. Can you say more about why you have this requirement? When the DNS protocol prevents you from doing something at one level but completely allows you do do something by creating another name within a subordinate namespace, what makes it so required that you only do things at the top-level name? There are lots of other examples of such requirements in the DNS protocol; why is this one so important? --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BB03A6A37 for ; Mon, 25 Oct 2010 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4wPzX5diueF for ; Mon, 25 Oct 2010 07:00:43 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 11C0E3A6A13 for ; Mon, 25 Oct 2010 07:00:41 -0700 (PDT) Received: by qyk1 with SMTP id 1so1399744qyk.10 for ; Mon, 25 Oct 2010 07:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=VAzZdYBv9wir2RldcvCPELyhUWxhWwKRAGcPKYKXqTM=; b=MCkzBHj8GR+FDfC2YQgA7mKN1ypS0RA0Tpl71cCYmp8HxsrkzYj07s7Buq40wDfoRs NthjcT5F//+TUK+wUoDpaMXeL3cOWbVc3FTbNFSlioZ5n/e5j/9vEgPM+sbn5jdrk9Pv +kkPb9tYDnlkiLL3yqcUJwRRwXKoQ+Ne/hn9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=RgfWXCjSixCPQafm+fbJMZMPR7KqrIxguBK7xmx5tIZew8g67L2fQg7GYO34U10tE0 VncdqCsvJogTcvfoEL4hLU2s+8gOEsVmyxhNxU4pbI3vtREnBn08jT6JS/nJpka+lVXz hCtIQh4POYWRigOhBYSboSQ+aTK673MHI84m4= Received: by 10.229.219.132 with SMTP id hu4mr175274qcb.46.1288015345201; Mon, 25 Oct 2010 07:02:25 -0700 (PDT) Received: from [10.0.0.130] ([64.241.37.140]) by mx.google.com with ESMTPS id nb14sm6071667qcb.36.2010.10.25.07.02.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 07:02:24 -0700 (PDT) References: <8762wqquzs.fsf@mocca.josefsson.org> Message-Id: <8F3ADBBD-C2B9-4A89-816B-AE953216DD55@gmail.com> From: Phillip Hallam-Baker To: Simon Josefsson In-Reply-To: <8762wqquzs.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B500) Mime-Version: 1.0 (iPad Mail 7B500) Date: Mon, 25 Oct 2010 10:02:25 -0400 Cc: "keyassure@ietf.org" , Paul Hoffman Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 14:00:46 -0000 Whether this is an issue or not depends on whether the semantics are = "here is a key you can use" or "here are the only keys you can use" I have also had discussions with the AD. My expectation was that the = group will be required to produce a means of establishing keys as being = valid before it would be allowed to address any aspect of security = policy. I also anticipated being required to produce experimental drafts = for any security policy mechanism. This is what I believe will be = required of the group. It has to be possible to use dnssec to establish a key for a mail server = that lives on the same dns node as a Web server without affecting = operation of the Web server in any way. Those requirements cannot and should not be ignored for the sake of = saving a few DNS round trips. Reuse of the CERT record to establish a key as being valid goes beyond = the original semantics of the record but is something i think we can = justify. But using it to communicate security policy goes too far in my = view. Sent from my iPad On Oct 25, 2010, at 9:09 AM, Simon Josefsson = wrote: > Paul Hoffman writes: >=20 >>> For instance, example.com might have a TLS cert for SMTP, but not = for >>> HTTPS. Querying the DNS for a cert record will not tell me I can = connect >>> on HTTPS to that server. >>=20 >> That is correct. It is not correct, however, if you query for >> www.example.com and mail.example.com: then you do know that the >> services at each of those two hosts (which might reside on the same >> box) use TLS. >=20 > One part that I disliked was that you don't separate on port. So it = is > not possible to query for a TLS fingerprint for certificate used on = port > X and do the same for port Y without having to match them all. I > believe this primarily makes it difficult to deploy, because it is > difficult to separate DNS privileges between the people responsible = for > the different services. >=20 > /Simon > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4D73A6A10 for ; Mon, 25 Oct 2010 06:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgOkHjPO3JA4 for ; Mon, 25 Oct 2010 06:30:12 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 8A6A83A6A05 for ; Mon, 25 Oct 2010 06:30:11 -0700 (PDT) Received: by qyk5 with SMTP id 5so1484520qyk.10 for ; Mon, 25 Oct 2010 06:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=lQkED2khSBcnTh9HaO64lL91jG3OKg8TxJeyT5RFw3E=; b=ZDN9VZGploUaaUmgggM4WERc3WHoKft8jf/0532aaRzAXHdJg2z1RNUT7TsH7+9sjM gSlgu0UFOCJd9RYX+TKoXpqbvesdma1CVmGFg3PUT0tpeOzwfNKwpOqD0LGo+FAr36kR KFGKzjKnb309OWFnqEnvxAr+Cqp1vHPgmQTRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=A4+FeZ4O22Hk0nhw7AuGZcejly9qaQQqhL9HQ95mSXZm1HBv2xeJdGM6tyUflAsUcF oMCDWUbIqCBR68IoIOhNkwCCAkWNxWj5UTz1w8xpXfS7j8tDMm1+89DOSmEMTFKVyAVq Bj+24DAz+1QT1hVeKTs5MHUi/sn3QoaAcrSHc= Received: by 10.229.181.210 with SMTP id bz18mr1329018qcb.43.1288013516326; Mon, 25 Oct 2010 06:31:56 -0700 (PDT) Received: from [10.0.0.130] ([64.241.37.140]) by mx.google.com with ESMTPS id s28sm6036126qcp.9.2010.10.25.06.31.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 06:31:55 -0700 (PDT) References: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> <489A09CF-F710-4806-B8D9-49B52C27F42A@kirei.se> Message-Id: <3F123170-C2C7-4586-A92B-D58E79AA4FBC@gmail.com> From: Phillip Hallam-Baker To: Jakob Schlyter In-Reply-To: <489A09CF-F710-4806-B8D9-49B52C27F42A@kirei.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B500) Mime-Version: 1.0 (iPad Mail 7B500) Date: Mon, 25 Oct 2010 09:31:55 -0400 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 13:30:14 -0000 That has yet to be established. In theory that should be the case. In practice the transfer of dns names = is rather more complex. I have been trying to find documentation on the = controls. They may not be public or they may not exist.=20 If you want to demonstrate that one system is more secure than the other = you have to apply the same standard of scruitiny to both systems.=20 Sent from my iPad On Oct 25, 2010, at 8:33 AM, Jakob Schlyter wrote: > On 25 okt 2010, at 14.01, Phillip Hallam-Baker wrote: >=20 >> If the registrar is defecting they can change the DNS, look for the = update, ping the resolver whose cache they want to poison and then = reverse out the changes once the cache is poisoned. >=20 > Only the registrar you have chosen can go rogue. If you don't trust = your registrar, chose another one. Compared to legacy PKI, where you can = cannot choose as all CA:s are trusted without constraints, this is a = huge win. >=20 > I do agree that combining DNSSEC and EV is even better. However, = combining DNSSEC and DV to order to increase security is IMHO close to = useless. >=20 > jakob >=20 > --=20 > Jakob Schlyter > Kirei AB - www.kirei.se >=20 >=20 >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF123A6A18 for ; Mon, 25 Oct 2010 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSKOB6UGb-R1 for ; Mon, 25 Oct 2010 06:08:06 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 842913A6A15 for ; Mon, 25 Oct 2010 06:08:06 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9PD9ikp024390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 Oct 2010 15:09:46 +0200 From: Simon Josefsson To: Paul Hoffman References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:101025:paul@xelerance.com::XBFBM7ev6SRbwXFu:4Sol X-Hashcash: 1:22:101025:paul.hoffman@vpnc.org::PYEJuD1QKqUMJGz5:6n1G X-Hashcash: 1:22:101025:keyassure@ietf.org::RJTslsZVMpiETx6k:LX5y Date: Mon, 25 Oct 2010 15:09:43 +0200 In-Reply-To: (Paul Hoffman's message of "Sun\, 24 Oct 2010 14\:45\:03 -0700") Message-ID: <8762wqquzs.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 13:08:08 -0000 Paul Hoffman writes: >>For instance, example.com might have a TLS cert for SMTP, but not for >>HTTPS. Querying the DNS for a cert record will not tell me I can connect >>on HTTPS to that server. > > That is correct. It is not correct, however, if you query for > www.example.com and mail.example.com: then you do know that the > services at each of those two hosts (which might reside on the same > box) use TLS. One part that I disliked was that you don't separate on port. So it is not possible to query for a TLS fingerprint for certificate used on port X and do the same for port Y without having to match them all. I believe this primarily makes it difficult to deploy, because it is difficult to separate DNS privileges between the people responsible for the different services. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B8A3A69E1 for ; Mon, 25 Oct 2010 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsl0JSyCk9KI for ; Mon, 25 Oct 2010 05:31:33 -0700 (PDT) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 30C7A3A69E2 for ; Mon, 25 Oct 2010 05:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=+50vfsM8mvRLAOQxuE9r1U9hXJcgJG+CxF5OuwM/UKY=; b=KJx2hgfXXOCqDAmnDFnqIJ72gcpq1q3dk3R6lbjp3lZogihQmI30Nrnh1Bi0ROERawbCwUtz9mJY5 Swdp1QSQVhGopEXZHgfj/xhPoHUS4sFm/0mfcMsqedGKh4M2pD0KpSW9Wm2/KHz7XrbX6qc1NsJKS1 T8H1Ejpr3YUKEbe8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 25 Oct 2010 14:33:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Mon, 25 Oct 2010 14:33:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <489A09CF-F710-4806-B8D9-49B52C27F42A@kirei.se> References: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 12:31:34 -0000 On 25 okt 2010, at 14.01, Phillip Hallam-Baker wrote: > If the registrar is defecting they can change the DNS, look for the = update, ping the resolver whose cache they want to poison and then = reverse out the changes once the cache is poisoned. Only the registrar you have chosen can go rogue. If you don't trust your = registrar, chose another one. Compared to legacy PKI, where you can = cannot choose as all CA:s are trusted without constraints, this is a = huge win. I do agree that combining DNSSEC and EV is even better. However, = combining DNSSEC and DV to order to increase security is IMHO close to = useless. jakob --=20 Jakob Schlyter Kirei AB - www.kirei.se Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FE63A69D7 for ; Mon, 25 Oct 2010 04:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd91FcXdCohv for ; Mon, 25 Oct 2010 04:59:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 25C283A6992 for ; Mon, 25 Oct 2010 04:59:47 -0700 (PDT) Received: by yxp4 with SMTP id 4so2204589yxp.31 for ; Mon, 25 Oct 2010 05:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tHycXK7yhHCOZsZfsXKxdrTjx4QYZdXoAXpgf1wCBnA=; b=pHD0dl5MgiRfcsE21r6F1o1344Nck4JEKLplgWP2CfHUTYMb5m6WsBPPNtwFmzq/n+ KyjoFUdFUWhWxc3p6H/JoUCavlZ3OLnbgJgP31Fd0ytR7pMoO1x6d9pxoXA2keTz/IDp 3jjLhTDuGAAEaU8mJWXbUyh51uTKHdoPKM3/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xws6bjihxL71rS6x52wMz8YoLHfhg6E9QOoAOdYVvCo85wv79YWTP5J9YMV08HzHx6 c9PlqikIRwkmLdPdi82FFQdgOYptuF9/HBPlhmhbeQS1GzkpEPjuHTyPLaykVWAHHeYY akNHg+u2q42GHX0JRqGoDqze4jdtS8FjNrkkM= MIME-Version: 1.0 Received: by 10.151.41.9 with SMTP id t9mr12694290ybj.59.1288008089847; Mon, 25 Oct 2010 05:01:29 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Mon, 25 Oct 2010 05:01:29 -0700 (PDT) In-Reply-To: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> References: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> Date: Mon, 25 Oct 2010 08:01:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=0015174ff446a9c7cd04936fc04c Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 11:59:48 -0000 --0015174ff446a9c7cd04936fc04c Content-Type: text/plain; charset=ISO-8859-1 Not necessarily. If the registrar is defecting they can change the DNS, look for the update, ping the resolver whose cache they want to poison and then reverse out the changes once the cache is poisoned. If you make equivalent assumptions, both systems are vulnerable to compromise. The only way you can do better is if you use both systems and check both paths so that you get some degree of separation of duties. On Mon, Oct 25, 2010 at 5:36 AM, Jakob Schlyter wrote: > On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote: > > > There is no magic in the choice of bits on the wire. DNSSEC suffers from > exactly the same set of issuing chain difficulties as PKI does. The number > of DNS registrars is actually considerably larger than the number of SSL > validation authorities. > > Except that it is apparent for the victim when a DNS registrar goes rogue > (as the result is published in the DNS), whereas a trusted CA can issue bad > certificates without detection. > > jakob > > -- > Jakob Schlyter > Kirei AB - www.kirei.se > > -- Website: http://hallambaker.com/ --0015174ff446a9c7cd04936fc04c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not necessarily.

If the registrar is defecting they can = change the DNS, look for the update, ping the resolver whose cache they wan= t to poison and then reverse out the changes once the cache is poisoned.


If you make equivalent assumptions, both= systems are vulnerable to compromise. The only way you can do better is if= you use both systems and check both paths so that you get some degree of s= eparation of duties.=A0


On Mon, Oct 25, 2010 at 5:36 AM, Ja= kob Schlyter <jakob@= kirei.se> wrote:
On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote:

> There is no magic in the choice of bits on the wire. DNSSEC suffers fr= om exactly the same set of issuing chain difficulties as PKI does. The numb= er of DNS registrars is actually considerably larger than the number of SSL= validation authorities.

Except that it is apparent for the victim when a DNS registrar goes r= ogue (as the result is published in the DNS), whereas a trusted CA can issu= e bad certificates without detection.

=A0 =A0 =A0 =A0jakob

--
Jakob Schlyter
Kirei AB - www.kirei.se




--
Website: http://hallambaker.com/

--0015174ff446a9c7cd04936fc04c-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2696F3A6991 for ; Mon, 25 Oct 2010 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEX24fniyjLD for ; Mon, 25 Oct 2010 02:35:28 -0700 (PDT) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 9C2BB3A699A for ; Mon, 25 Oct 2010 02:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=3rXmdzHAC9thaYf7/iCi/XeR6DFM9AEddEz7wKh/z8k=; b=YtnOKaS9EKdfJXi2A7T/GRk+L1ZkPwtPsFtZOI06yMKWdCAaH6rMzjiGYLY4l7Rq3muws83EAjW0t cp+QCb6qxvHhF/p69ES8fAAMDhO9S5pimanjaGsFMsjLpfHnc+330rRGpcjsybXuG6WKaQth+wssbE Oudy9BMPDUzexBr4= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 25 Oct 2010 11:37:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Mon, 25 Oct 2010 11:36:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54C22805-5AC8-4CF9-9FFA-AC0D513AB67E@kirei.se> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 09:35:30 -0000 On 24 okt 2010, at 23.48, Phillip Hallam-Baker wrote: > There is no magic in the choice of bits on the wire. DNSSEC suffers = from exactly the same set of issuing chain difficulties as PKI does. The = number of DNS registrars is actually considerably larger than the number = of SSL validation authorities.=20 Except that it is apparent for the victim when a DNS registrar goes = rogue (as the result is published in the DNS), whereas a trusted CA can = issue bad certificates without detection. jakob --=20 Jakob Schlyter Kirei AB - www.kirei.se Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F933A6903 for ; Sun, 24 Oct 2010 15:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfmGtmraCcRp for ; Sun, 24 Oct 2010 15:02:10 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 355E93A6452 for ; Sun, 24 Oct 2010 15:02:10 -0700 (PDT) Received: by gya6 with SMTP id 6so1877985gya.31 for ; Sun, 24 Oct 2010 15:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IWKVx9wsdSqG0Bqzten5RjRKnUz0elPKfni9I3ewRvo=; b=p4GAozlN3C5Yz0lxE0t77PM6frTB3se3gh/LIXqeQameiujeCgn8hCFpv+ALTBD17W lkkgdN+io2Z5opXLHRyB8iiulnAA+0PikEG4rUfWxwwyBaSw0FqX27VcKezWDlsojSOJ 3tPGdhF9YqIwgGsATTwECWCtQ8oFXajvSrMbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UxAkQiBjoP/+nHzweox7Jt1YC/OSZOy55Zg0ApPJ+VWRjA4Lj+3B3iKGGwJ2Uusa4L UfB/NtOAu/otGmGiO5R0mUyqgVo52l1lNLLXyvUMb9T9oRxAdlDD9s8PEYrMvuX+lhc+ SiJEwVEOwdmQ+QRqa6oDK7RpvQGMEpWmxb0TE= MIME-Version: 1.0 Received: by 10.100.125.13 with SMTP id x13mr4794686anc.135.1287957827932; Sun, 24 Oct 2010 15:03:47 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Sun, 24 Oct 2010 15:03:28 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Oct 2010 18:03:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e644cf8ad25a8e0493640c13 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 22:02:12 -0000 --0016e644cf8ad25a8e0493640c13 Content-Type: text/plain; charset=ISO-8859-1 That is an example of security policy. That is exactly what I propose in ESRV and what CAA is a form of. I discussed this issue with Tim Polk last Friday and as I expected, he thinks that there is a significant risk that a group that tries to do security policy will never terminate. So he would like to see experimental proposals being made before the WG looks at them. Specification of trust anchors is the hardest aspect of security policy to get right. If we have a statement in the DNS/DNSSEC that says 'always use SSL' for a given protocol, we can then ensure that every communication uses the highest degree of security supported by both the client and server. In that world we do not require the padlock icon at all. The only communication to the user that is worth communicating to the user is 'we think you are safe'. A DV cert only allows encryption to be established and that is a fairly low level of risk control. The probability that an end point is malicious is far greater than the probability that the infrastructure has been compromised for most Internet use cases. So securing the network connection alone is only giving a very weak form of protection. I would like to see the padlock icon retired and to only use user notification when an EV certificate is in use and we have a demonstration of accountability for the end point. On Sun, Oct 24, 2010 at 5:01 PM, Paul Wouters wrote: > On Mon, 4 Oct 2010, Paul Hoffman wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Using Secure DNS to Associate Certificates with >>> Domain Names For TLS >>> Author(s) : P. Hoffman, et al. >>> Filename : draft-hoffman-keys-linkage-from-dns-03.txt >>> Pages : 13 >>> Date : 2010-10-04 >>> >> > I like this draft. I have only one concern. This method does not allow > one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP > records received back, decide on a different course of action. > > For instance, example.com might have a TLS cert for SMTP, but not for > HTTPS. Querying the DNS for a cert record will not tell me I can connect > on HTTPS to that server. > > It would be nice if we could do this, so we have some method of migrating > the masses of the web servers to use HTTPS without having to go through > an HTTP redirect (which way too often, will leak cookies, Etags or other > information that could be used to later take over the HTTPS connection. > > A next logical step would be to try and phase out HTTP for HTTPS. If > possible, > this standard should take that signalling into consideration. The less > redirects and DNS queries we need to do, the better. > > Paul > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e644cf8ad25a8e0493640c13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is an example of security policy. That is exactly what I propose in ES= RV and what CAA is a form of.

I discussed this issue wit= h Tim Polk last Friday and as I expected, he thinks that there is a signifi= cant risk that a group that tries to do security policy will never terminat= e. So he would like to see experimental proposals being made before the WG = looks at them.

Specification of trust anchors is the hardest aspect of= security policy to get right.=A0


I= f we have a statement in the DNS/DNSSEC that says 'always use SSL' = for a given protocol, we can then ensure that every communication uses the = highest degree of security supported by both the client and server.

In that world we do not require the padlock icon at all= . The only communication to the user that is worth communicating to the use= r is 'we think you are safe'. A DV cert only allows encryption to b= e established and that is a fairly low level of risk control. The probabili= ty that an end point is malicious is far greater than the probability that = the infrastructure has been compromised for most Internet use cases. So sec= uring the network connection alone is only giving a very weak form of prote= ction.

I would like to see the padlock icon retired and to onl= y use user notification when an EV certificate is in use and we have a demo= nstration of accountability for the end point.


On Sun, Oct 24, 2010 at 5:01 PM, Paul Wouter= s <paul@xeleranc= e.com> wrote:
On Mon, 4 Oct 2010, Paul Hoffman wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Using Secure DNS to Associate C= ertificates with Domain Names For TLS
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Hoffman, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-hoffman-keys-linkage-from-d= ns-03.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-10-04

I like this draft. I have only one concern. This method does not allow
one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP<= br> records received back, decide on a different course of action.

For instance, example.com<= /a> might have a TLS cert for SMTP, but not for
HTTPS. Querying the DNS for a cert record will not tell me I can connect on HTTPS to that server.

It would be nice if we could do this, so we have some method of migrating the masses of the web servers to use HTTPS without having to go through
an HTTP redirect (which way too often, will leak cookies, Etags or other information that could be used to later take over the HTTPS connection.

A next logical step would be to try and phase out HTTP for HTTPS. If possib= le,
this standard should take that signalling into consideration. The less
redirects and DNS queries we need to do, the better.

Paul



--
Website: http://hallambaker.com/

--0016e644cf8ad25a8e0493640c13-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46ED03A6910 for ; Sun, 24 Oct 2010 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk2D5V6tvOxX for ; Sun, 24 Oct 2010 14:46:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9F6903A690A for ; Sun, 24 Oct 2010 14:46:49 -0700 (PDT) Received: by gya6 with SMTP id 6so1873944gya.31 for ; Sun, 24 Oct 2010 14:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=m1zWXMcMDL2InKVrUnc9IfYcnkHcO422WpmHJH5lvCQ=; b=c1+pP4CJOmv1VVEaec2ERc6lCNxTwtlZVTZn2Ui+XMZ8iBaQvU1dAwnluiqVMoi30Z nRjU01M4gME9X4oPcNU6mu+zJbnSl5ILeYFSUr20j5bbnMBEOKSunELKwpM8M87bDETQ hHFP8sTzkEO+A9qYX//1VJPmEnghnDmLwx0Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XaOds1y1Pf0OrbXRgxbq28D05cDOzifj21xItF7mltoGptWTCQ2HbZ17wd0e5b7gM3 2QG405xrLFjvwoGNpaInwEAkcapKkf3PAacNa8ywv5LsO/GNb+ArS4btZgVM0xZN2jMs 49JWYd8/RB0A7G0uaMeQyToT1Lv11JIdLC1wo= MIME-Version: 1.0 Received: by 10.150.131.8 with SMTP id e8mr6735395ybd.91.1287956912809; Sun, 24 Oct 2010 14:48:32 -0700 (PDT) Received: by 10.100.41.14 with HTTP; Sun, 24 Oct 2010 14:48:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Oct 2010 17:48:32 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=000e0cd4cdb6462a4f049363d607 Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 21:46:51 -0000 --000e0cd4cdb6462a4f049363d607 Content-Type: text/plain; charset=ISO-8859-1 CAA only requires deployment by two parties to be useful and provide coverage, both of which are highly motivated to act. TLSFP requires the client application to be upgraded before a relying party has any protection. That means that deployment will take a minimum of ten years. It also means that it is a good deal harder to get right. There is a good case to be made for client side enforcement of certificate issuing policy, but it is not a substitute for better issue controls. As for reducing the number of CAs, that is rather more difficult than you might imagine. CAA is designed to set an objective test that gives a browser provider grounds for withdrawing accreditation. There is no magic in the choice of bits on the wire. DNSSEC suffers from exactly the same set of issuing chain difficulties as PKI does. The number of DNS registrars is actually considerably larger than the number of SSL validation authorities. On Sun, Oct 24, 2010 at 4:28 PM, Paul Wouters wrote: > On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote: > > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt >> > > The Certification Authority Authorization (CAA) DNS Resource Record > allows a DNS domain name holder to specify the certificate signing > certificate(s) authorized to issue certificates for that domain. > > If you can trust the CAA DNS record, why could you not trust a record > with SSL/TLS FP from the same administrative source? From a technical > point of view, this record makes no sense. > > This record seems to address practical limitations of the CA trust model, > whereby one installed omnipotent CA could make a claim contradicting > another omnipontent CA. > > > Clearly a record of this type could be used to effect client policy >> enforcement mechanisms. >> > > A better fix would be to replace/fix the broken bag of omnipotent CA's > endusers now have to blindly trust. If that solution is sought outside > the scope of CA's and X.509, CRLs, OCSP's etc, then it makes no sense to > keep lingering in that space, and instead just move on to DNSSEC based > trust relationships. > > Before issue of a certificate a compliant CA MUST check for > publication of a relevant CAA Resource Record and if a record is > published that the certificate requested is consistent with it. If > the certificate requested is not consistent with the CAA RR > authorization, the CA MUST NOT issue the certificate. > > This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what's > left of the role of the CA? > > If the CAA DNS record would present a migration path from CA's to DNSSEC > based authentication, I might see a use for it. > > Paul > -- Website: http://hallambaker.com/ --000e0cd4cdb6462a4f049363d607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable CAA only requires deployment by two parties to be useful and provide covera= ge, both of which are highly motivated to act.

TLSFP req= uires the client application to be upgraded before a relying party has any = protection. That means that deployment will take a minimum of ten years. It= also means that it is a good deal harder to get right.


There is a good case to be made for clie= nt side enforcement of certificate issuing policy, but it is not a substitu= te for better issue controls.=A0

As for reducing the numb= er of CAs, that is rather more difficult than you might imagine. CAA is des= igned to set an objective test that gives a browser provider grounds for wi= thdrawing accreditation.=A0


There is no magic in the choice of bits = on the wire. DNSSEC suffers from exactly the same set of issuing chain diff= iculties as PKI does. The number of DNS registrars is actually considerably= larger than the number of SSL validation authorities.=A0


On Sun, Oct 24, 2010 at = 4:28 PM, Paul Wouters <paul@xelerance.com> wrote:
On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote:

http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt

=A0 The Certification Authority Authorization (CAA) DNS Resource Record =A0 allows a DNS domain name holder to specify the certificate signing
=A0 certificate(s) authorized to issue certificates for that domain.

If you can trust the CAA DNS record, why could you not trust a record
with SSL/TLS FP from the same administrative source? From a technical
point of view, this record makes no sense.

This record seems to address practical limitations of the CA trust model, whereby one installed omnipotent CA could make a claim contradicting
another omnipontent CA.


Clearly a record of this type could be used to effect client policy enforce= ment mechanisms.

A better fix would be to replace/fix the broken bag of omnipotent CA's<= br> endusers now have to blindly trust. If that solution is sought outside
the scope of CA's and X.509, CRLs, OCSP's etc, then it makes no sen= se to
keep lingering in that space, and instead just move on to DNSSEC based
trust relationships.

=A0 Before issue of a certificate a compliant CA MUST check for
=A0 publication of a relevant CAA Resource Record and if a record is
=A0 published that the certificate requested is consistent with it. =A0If<= br> =A0 the certificate requested is not consistent with the CAA RR
=A0 authorization, the CA MUST NOT issue the certificate.

This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what'= s
left of the role of the CA?

If the CAA DNS record would present a migration path from CA's to DNSSE= C
based authentication, I might see a use for it.

Paul



--
Website: http://hallambaker.com/

--000e0cd4cdb6462a4f049363d607-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3D63A68FB for ; Sun, 24 Oct 2010 14:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.407 X-Spam-Level: X-Spam-Status: No, score=-101.407 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 250nzw-v7gNS for ; Sun, 24 Oct 2010 14:43:23 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E5E173A63D2 for ; Sun, 24 Oct 2010 14:43:22 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9OLj4VA054592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Oct 2010 14:45:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 24 Oct 2010 14:45:03 -0700 To: Paul Wouters From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 21:43:24 -0000 At 5:01 PM -0400 10/24/10, Paul Wouters wrote: >I like this draft. I have only one concern. This method does not allow >one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP >records received back, decide on a different course of action. Actually, it does, if you ask for the specific host. However... >For instance, example.com might have a TLS cert for SMTP, but not for >HTTPS. Querying the DNS for a cert record will not tell me I can connect >on HTTPS to that server. That is correct. It is not correct, however, if you query for www.example.com and mail.example.com: then you do know that the services at each of those two hosts (which might reside on the same box) use TLS. The "tell me all the TLS-enhanced services at example.com" issue is still interesting, but it devolves very quickly. You are assuming that "example.com" is the right cutoff without knowing how that zone names the hosts that provide services. You do *not* want .com giving a single answer for all of its subdomains, do you? If not, why do you want example.com? Our design explicitly chose "give the exact host name, and we'll tell you about it". If folks want something that is along the line of "give a zone name and we'll tell you about the layers one or more levels down", I hope they can also say how to prevent the "VeriSign gets to give this data for all of .com" and "PIR gets to give this data for all of .org" problem. >It would be nice if we could do this, so we have some method of migrating >the masses of the web servers to use HTTPS without having to go through >an HTTP redirect (which way too often, will leak cookies, Etags or other >information that could be used to later take over the HTTPS connection. Fully agree. The folks in the websec WG are working on this problem. >A next logical step would be to try and phase out HTTP for HTTPS. If possible, >this standard should take that signalling into consideration. The less >redirects and DNS queries we need to do, the better. Yep. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 376EE3A6875 for ; Sun, 24 Oct 2010 14:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljbv6EC6kWBY for ; Sun, 24 Oct 2010 14:00:12 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id D5D073A67B1 for ; Sun, 24 Oct 2010 14:00:11 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id C998BC2F9; Sun, 24 Oct 2010 17:01:54 -0400 (EDT) Date: Sun, 24 Oct 2010 17:01:54 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 21:00:13 -0000 On Mon, 4 Oct 2010, Paul Hoffman wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Using Secure DNS to Associate Certificates with Domain Names For TLS >> Author(s) : P. Hoffman, et al. >> Filename : draft-hoffman-keys-linkage-from-dns-03.txt >> Pages : 13 >> Date : 2010-10-04 I like this draft. I have only one concern. This method does not allow one to query the DNS in an opportunistic matter, and based upon CERT/TLSFP records received back, decide on a different course of action. For instance, example.com might have a TLS cert for SMTP, but not for HTTPS. Querying the DNS for a cert record will not tell me I can connect on HTTPS to that server. It would be nice if we could do this, so we have some method of migrating the masses of the web servers to use HTTPS without having to go through an HTTP redirect (which way too often, will leak cookies, Etags or other information that could be used to later take over the HTTPS connection. A next logical step would be to try and phase out HTTP for HTTPS. If possible, this standard should take that signalling into consideration. The less redirects and DNS queries we need to do, the better. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6FD53A6835 for ; Sun, 24 Oct 2010 13:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwWhpSS9-dbX for ; Sun, 24 Oct 2010 13:57:53 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 665413A67B1 for ; Sun, 24 Oct 2010 13:57:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=odfBz/xfFUEhV07NtG9opW48xFh7j9PtvxQSkEmUrDP1qsrghvXwWoo4B3rTCX+S; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PA7fE-0006zj-FO for keyassure@ietf.org; Sun, 24 Oct 2010 16:59:36 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sun, 24 Oct 2010 16:59:36 -0400 Message-ID: <6010001.1287953976438.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Sun, 24 Oct 2010 15:59:36 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c9bd704dec7be3a6a66681921b64937f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 20:57:54 -0000 Paul and all, -----Original Message----- >From: Paul Wouters >Sent: Oct 24, 2010 3:44 PM >To: Phillip Hallam-Baker >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Certification Authority Authorization Draft. > >On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote: > >> Assume for a moment that other CAs don't follow our lead and end up mis-= issuing against a domain that has a CAA record. What do you >> think their liability is in that case? They certainly have a major PR is= sue at that point and their only realistic chance of >> surviving it without too much damage is going to be to deploy CAA. > >Seeing that rapidssl is still very much alive, I think we can safely say P= R is not a valid detergend >against running an uhm, less then optimally secure CA. > >> You may also be interested in my DPLS draft:=C2=A0 >>=20 >> http://www.ietf.org/id/draft-hallambaker-dpls-00.txt > >A quick peek: > > DPLS allows for more efficient secure DNS resolution by enabling a > trusted resolver to efficiently authenticate communiction with a > client. > >I doubt the impact of running DNSSEC on the enduser is that much >of an impact these days. Especially because of DNS caching. Plus, >if efficiency is an issue, configuring the enduser to use a trusted >validating usptream resolver addresses that problem too (except it would >not have confidentiality, but see below) Confidentiality is a significant issue though... > > A secondary advantage of using DPLS is that it enables traffic > between the DNS client and resolver to be encrypted, thus reducing > exposure to confidentiality attacks. > >It might protect last-mile wifi confidentiality attacks, but nothing >else. Because it is easy to give unique DNS labels to clients for tracking >purposes, unless hundreds+ clients are all congregating their traffic >at a common DNS server (something that TOR tries to do) If your correct, and I am not sure you are, still confidentiality attacks are reduced. That's an improvement. =20 > > >> A lot of the DNS performance issues go away if the DNS client can ask it= s resolver 'hey give me all the info I need to do this with >> that'. > >Those can be done using EDNS options as well. > >the draft discusses a lot of split DNS setups and required confidentiality= , but >that all boils down to "enterprises need VPN + company DNS server". I am u= nclear >how this draft would change that, except adding some new kind of transport= layer >security. If one would design something like that, the very least I would = expect >is a way to return more data to the client in bulk that it will encounter = when >doing more queries anyway. Latency is the performance issue here, not band= width >or CPU usage. > >Paul >Paul >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liabilit= y depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.co= m Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED293A6895 for ; Sun, 24 Oct 2010 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omkpNp2IHKWB for ; Sun, 24 Oct 2010 13:43:12 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 904D33A6875 for ; Sun, 24 Oct 2010 13:43:12 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 663AAC2F9; Sun, 24 Oct 2010 16:44:55 -0400 (EDT) Date: Sun, 24 Oct 2010 16:44:55 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 20:43:14 -0000 On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote: > Assume for a moment that other CAs don't follow our lead and end up mis-issuing against a domain that has a CAA record. What do you > think their liability is in that case? They certainly have a major PR issue at that point and their only realistic chance of > surviving it without too much damage is going to be to deploy CAA. Seeing that rapidssl is still very much alive, I think we can safely say PR is not a valid detergend against running an uhm, less then optimally secure CA. > You may also be interested in my DPLS draft:  > > http://www.ietf.org/id/draft-hallambaker-dpls-00.txt A quick peek: DPLS allows for more efficient secure DNS resolution by enabling a trusted resolver to efficiently authenticate communiction with a client. I doubt the impact of running DNSSEC on the enduser is that much of an impact these days. Especially because of DNS caching. Plus, if efficiency is an issue, configuring the enduser to use a trusted validating usptream resolver addresses that problem too (except it would not have confidentiality, but see below) A secondary advantage of using DPLS is that it enables traffic between the DNS client and resolver to be encrypted, thus reducing exposure to confidentiality attacks. It might protect last-mile wifi confidentiality attacks, but nothing else. Because it is easy to give unique DNS labels to clients for tracking purposes, unless hundreds+ clients are all congregating their traffic at a common DNS server (something that TOR tries to do) > A lot of the DNS performance issues go away if the DNS client can ask its resolver 'hey give me all the info I need to do this with > that'. Those can be done using EDNS options as well. the draft discusses a lot of split DNS setups and required confidentiality, but that all boils down to "enterprises need VPN + company DNS server". I am unclear how this draft would change that, except adding some new kind of transport layer security. If one would design something like that, the very least I would expect is a way to return more data to the client in bulk that it will encounter when doing more queries anyway. Latency is the performance issue here, not bandwidth or CPU usage. Paul Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955AD3A680F for ; Sun, 24 Oct 2010 13:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lg3y78Dq6s-w for ; Sun, 24 Oct 2010 13:26:28 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 83A943A680B for ; Sun, 24 Oct 2010 13:26:27 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1A8C4C2F9; Sun, 24 Oct 2010 16:28:10 -0400 (EDT) Date: Sun, 24 Oct 2010 16:28:09 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 20:26:29 -0000 On Mon, 18 Oct 2010, Phillip Hallam-Baker wrote: > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. If you can trust the CAA DNS record, why could you not trust a record with SSL/TLS FP from the same administrative source? From a technical point of view, this record makes no sense. This record seems to address practical limitations of the CA trust model, whereby one installed omnipotent CA could make a claim contradicting another omnipontent CA. > Clearly a record of this type could be used to effect client policy enforcement mechanisms. A better fix would be to replace/fix the broken bag of omnipotent CA's endusers now have to blindly trust. If that solution is sought outside the scope of CA's and X.509, CRLs, OCSP's etc, then it makes no sense to keep lingering in that space, and instead just move on to DNSSEC based trust relationships. Before issue of a certificate a compliant CA MUST check for publication of a relevant CAA Resource Record and if a record is published that the certificate requested is consistent with it. If the certificate requested is not consistent with the CAA RR authorization, the CA MUST NOT issue the certificate. This basicly mandates DNSSEC to avoid fraud. If mandating DNSSEC, what's left of the role of the CA? If the CAA DNS record would present a migration path from CA's to DNSSEC based authentication, I might see a use for it. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257BC3A6A66 for ; Mon, 18 Oct 2010 19:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohMXh7cE6LhW for ; Mon, 18 Oct 2010 19:15:36 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D1DD63A6A01 for ; Mon, 18 Oct 2010 19:15:35 -0700 (PDT) Received: by fxm17 with SMTP id 17so1384297fxm.31 for ; Mon, 18 Oct 2010 19:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FTVArQxpWarIJkZGcKPykJFjEZLTBlQtFICY7yrFw0U=; b=pCfOExQ2QqARhYT8DYs8Zsdkz2vzJ3GapM50AXQWvzOpONFojlORSW/6kR6CCZzKAT bvyQw/wkfijj7PxaoTmnhbYLcsRFGvJcM88r0JTTMoGyO2gCQhS0S4o/e8+S36rXkdsW 6PfmUGr66fYmoXpLwzNCzfnCXpnWs2ojUts1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AsX8JxeJ/qFiDyAGVoWCfAMPRXQnaijMhbpOfQLWz1qB2KtybLdS8ibbjXPBmfJXaE RWRsEO8Q07zQ0ApTb42pHlxZKTaHmWHRHJLP7vuLuGw374qQg+4yl7yMWsKT+ADbZV5L o36AcVO8+X8xzCduXYg8gPTYaKR9zxfjUhxsE= MIME-Version: 1.0 Received: by 10.239.185.9 with SMTP id a9mr295124hbh.199.1287454624400; Mon, 18 Oct 2010 19:17:04 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Mon, 18 Oct 2010 19:17:04 -0700 (PDT) In-Reply-To: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> References: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> Date: Mon, 18 Oct 2010 22:17:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=001485f796328d455e0492eee344 Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 02:15:38 -0000 --001485f796328d455e0492eee344 Content-Type: text/plain; charset=ISO-8859-1 Adam L. pointed out some typos and so on. I had to get it in today and I am fighting off a cold. As we discussed in the call, we are very interested in having Google co-author if you are interested. CA buy-in is not so much of a worry for me. Comodo will deploy for certain and Symantec/VeriSignCA is pretty likely to follow. Assume for a moment that other CAs don't follow our lead and end up mis-issuing against a domain that has a CAA record. What do you think their liability is in that case? They certainly have a major PR issue at that point and their only realistic chance of surviving it without too much damage is going to be to deploy CAA. So all in all, I think that the chances are pretty good that we can present this as a win for all concerned. You may also be interested in my DPLS draft: http://www.ietf.org/id/draft-hallambaker-dpls-00.txt A lot of the DNS performance issues go away if the DNS client can ask its resolver 'hey give me all the info I need to do this with that'. On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari wrote: > I have not yet read the whole draft, but so far I really like it. > > While (as you already pointed out) it doesn't solve all of the issues, it > does go a long way towards improving matters, assuming of course the CAs buy > in... > > W > On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote: > > > This is a draft that I submitted this morning. The main proposal being > made here is to enable Certification Authorities to avoid mis-issue. > > > > As such I believe that it is complimentary to mechanisms that enable > client side enforcement but has the considerable advantage of offering > immediate protection to every Internet user regardless of whether they have > an updated browser. It is also much less strongly dependent on deployment of > DNSSEC. > > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt > > > > > > Given the nature of the proposal, it is probably better suited to having > the bulk of the legal-technical work considered in CABForum rather than > IETF. Accordingly the proposal is designed to allow the technical > infrastructure to be agreed in IETF and then the practices and legal work > done in CABForum. > > > > Clearly a record of this type could be used to effect client policy > enforcement mechanisms. But this is a rather more complex issue and there > are going to be a lot of people with views on the best way forward. > > > > The mechanism as specified is sufficient for allowing client side > enforcement as it stands if the site is using a public CA, running a local > CA cross certified into a public hierarchy or using a standalone private CA. > But only if those infrastructures are supporting all their applications > without exception. > > > > > > -- > > Website: http://hallambaker.com/ > > > > _______________________________________________ > > keyassure mailing list > > keyassure@ietf.org > > https://www.ietf.org/mailman/listinfo/keyassure > > -- Website: http://hallambaker.com/ --001485f796328d455e0492eee344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Adam L. pointed out some typos and so on. I had to get it in today and I am= fighting off a cold.


As we discussed in = the call, we are very interested in having Google co-author if you are inte= rested.


CA buy-in is not so much of a worry for me. Co= modo will deploy for certain and Symantec/VeriSignCA is pretty likely to fo= llow.

Assume for a moment that other CAs don't= follow our lead and end up mis-issuing against a domain that has a CAA rec= ord. What do you think their liability is in that case? They certainly have= a major PR issue at that point and their only realistic chance of survivin= g it without too much damage is going to be to deploy CAA.


So all in all, I think that the chances = are pretty good that we can present this as a win for all concerned.=A0


You may also be interested in my DPLS = draft:=A0


A lot of the DNS performance issues go away if the DNS = client can ask its resolver 'hey give me all the info I need to do this= with that'.


On Mon, Oct 18, 2010 at 9:51 PM, Warren Kumari <warren@kumari.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> I have not yet read the whole draft, but so far I really like it.

While (as you already pointed out) it doesn't solve all of the issues, = it does go a long way towards improving matters, assuming of course the CAs= buy in...

W
On Oct 18, 2010, at 5:32 PM, Phillip Hall= am-Baker wrote:

> This is a draft that I submitted this morning. The main proposal being= made here is to enable Certification Authorities to avoid mis-issue.
>
> As such I believe that it is complimentary to mechanisms that enable c= lient side enforcement but has the considerable advantage of offering immed= iate protection to every Internet user regardless of whether they have an u= pdated browser. It is also much less strongly dependent on deployment of DN= SSEC.
> http://www.ietf.org/id/draft-hallambaker-donotissue-00.t= xt
>
>
> Given the nature of the proposal, it is probably better suited to havi= ng the bulk of the legal-technical work considered in CABForum rather than = IETF. Accordingly the proposal is designed to allow the technical infrastru= cture to be agreed in IETF and then the practices and legal work done in CA= BForum.
>
> Clearly a record of this type could be used to effect client policy en= forcement mechanisms. But this is a rather more complex issue and there are= going to be a lot of people with views on the best way forward.
>
> The mechanism as specified is sufficient for allowing client side enfo= rcement as it stands if the site is using a public CA, running a local CA c= ross certified into a public hierarchy or using a standalone private CA. Bu= t only if those infrastructures are supporting all their applications witho= ut exception.
>
>
> --
> Website: http://= hallambaker.com/
>
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure




--
Website: http://hallambaker.com/

--001485f796328d455e0492eee344-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309BA3A6AB6 for ; Mon, 18 Oct 2010 18:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o-xGSdDFXUq for ; Mon, 18 Oct 2010 18:49:10 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 04FD53A6A70 for ; Mon, 18 Oct 2010 18:49:09 -0700 (PDT) Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 4C18D22849C8; Mon, 18 Oct 2010 21:49:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 18 Oct 2010 21:51:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DFD910F-C3A7-4E60-A98B-1B8AAF1E9F6D@kumari.net> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 01:49:14 -0000 I have not yet read the whole draft, but so far I really like it.=20 While (as you already pointed out) it doesn't solve all of the issues, = it does go a long way towards improving matters, assuming of course the = CAs buy in... W On Oct 18, 2010, at 5:32 PM, Phillip Hallam-Baker wrote: > This is a draft that I submitted this morning. The main proposal being = made here is to enable Certification Authorities to avoid mis-issue.=20 >=20 > As such I believe that it is complimentary to mechanisms that enable = client side enforcement but has the considerable advantage of offering = immediate protection to every Internet user regardless of whether they = have an updated browser. It is also much less strongly dependent on = deployment of DNSSEC.=20 > http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt >=20 >=20 > Given the nature of the proposal, it is probably better suited to = having the bulk of the legal-technical work considered in CABForum = rather than IETF. Accordingly the proposal is designed to allow the = technical infrastructure to be agreed in IETF and then the practices and = legal work done in CABForum. >=20 > Clearly a record of this type could be used to effect client policy = enforcement mechanisms. But this is a rather more complex issue and = there are going to be a lot of people with views on the best way = forward. >=20 > The mechanism as specified is sufficient for allowing client side = enforcement as it stands if the site is using a public CA, running a = local CA cross certified into a public hierarchy or using a standalone = private CA. But only if those infrastructures are supporting all their = applications without exception. >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D88F13A69AD for ; Mon, 18 Oct 2010 15:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.803 X-Spam-Level: X-Spam-Status: No, score=-101.803 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qK3YSl8gjfk for ; Mon, 18 Oct 2010 15:07:04 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 7A6A83A6B8F for ; Mon, 18 Oct 2010 15:07:04 -0700 (PDT) Received: from [192.168.0.215] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 53FF822849C8; Mon, 18 Oct 2010 18:07:22 -0400 (EDT) References: <20013730.1287417982521.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <9529321E-B9F4-4B86-8A26-0942B755424A@Princeton.EDU> In-Reply-To: <9529321E-B9F4-4B86-8A26-0942B755424A@Princeton.EDU> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Type: text/plain; charset=us-ascii Message-Id: <5B0893D9-5F50-4E23-BA00-F1CCF425B689@kumari.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8A293) From: Warren Kumari Date: Mon, 18 Oct 2010 18:08:57 -0400 To: Steve Schultze Cc: "keyassure@ietf.org" Subject: Re: [keyassure] CA-related event in DC on Friday X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 22:07:06 -0000 On Oct 18, 2010, at 5:30 PM, Steve Schultze wrote: > My apologies for the short notice. Frankly, I wasn't even sure if it was a= ppropriate to send event info to the list. I'm glad folks are interested. >=20 Very interested -- unfortunately I won't be able to make it, but it looks ve= ry interesting... Please send a followup letting us know how it went off... W > At the event, I will be doing an extended introduction/tutorial along with= Ed Felten, and I'd be happy to make sure any input from the list is represe= nted. Feel free to email me directly or tweet to #ethreats. I believe that= there will also be a live stream (linked from the New America events page),= and the moderator will keep his eye on twitter during the event. >=20 > I'll also be in Beijing, and I'm looking forward to a more interactive con= versation there. >=20 > Steve >=20 > On Oct 18, 2010, at 12:06 PM, Jeffrey A. Williams wrote: >> stephen and all, >>=20 >> Thanks for this information, but the thing is that we are >> just 4 days before this event getting the information. That's >> a bit short of a time lead. Will this event be taken on the road >> perhaps in the near future? The video is fine, but doesn't allow >> for much interaction... >>=20 >>=20 >> -----Original Message----- >>> From: Stephen Schultze >>> Sent: Oct 18, 2010 9:39 AM >>> To: keyassure@ietf.org >>> Subject: [keyassure] CA-related event in DC on Friday >>>=20 >>> Hey all, those of you in the DC area you may be interested in an event =20= >>> my research center is hosting along with New America Foundation. The =20= >>> full description is below. Video will be available after the event. >>>=20 >>> =3D=3D >>>=20 >>> Emerging Threats to Online Trust: The Role of Public Policy and =20 >>> Browser Certificates >>> http://citp.princeton.edu/events/emerging-threats-to-online-trust/ >>>=20 >>> Date: Friday, October 22, 2010 >>> Time: 9:00 AM - 11:00 AM >>> Location: New America Foundation, 1899 L Street, NW, 4th Floor, =20 >>> Washington DC 20036 >>> Hashtag: #ethreats >>>=20 >>> Hosted by Princeton's Center for Information Technology Policy and the =20= >>> New America Foundation >>>=20 >>> Every day, we rely on our web browsers to keep our communications =20 >>> secure. Whether we are submitting our credit card for purchases, doing =20= >>> online banking, or sending email, the same fundamental security =20 >>> structure is being used. The lock icon displayed by web browsers might =20= >>> give users reason to believe that the prevailing "certificate"-based =20= >>> model is trustworthy, but the reality is that many vulnerabilities =20 >>> exist and the risks are multiplying. Hundreds of different entities =20 >>> located around the world have the ability to issue fraudulent =20 >>> certificates that will nevertheless be trusted by our browsers. =20 >>> Overcoming the shortcomings in the current model and working toward a =20= >>> better model requires cooperation of corporations, the government, =20 >>> developers, and users. Many of the most difficult challenges are not =20= >>> technical in nature but rather social or political. >>>=20 >>> Keynote: >>> Andrew McLaughlin, White House Deputy CTO, Internet Policy >>>=20 >>> Panelists: >>> Peter Eckersley, Senior Staff Technologist, Electronic Frontier =20 >>> Foundation >>> Adam Langley, Senior Software Engineer, Google >>> Scott Rea, Senior PKI Architect, DigiCert >>> Paul Vixie, President, Internet Software Consortium >>>=20 >>> Respondents: >>> Ari Schwartz, Senior Internet Policy Advisor, National Institute of =20 >>> Standards and Technology >>> Andy Steingruebl, Manager, Internet Standards and Governance, PayPal >>>=20 >>> This event is free and open to the public. Please rsvp at: >>> http://www.newamerica.net/events/2010/online_trust >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >> Regards, >> Jeffrey A. Williams >> "Obedience of the law is the greatest freedom" - >> Abraham Lincoln >>=20 >> "Credit should go with the performance of duty and not with what is very >> often the accident of glory" - Theodore Roosevelt >>=20 >> "If the probability be called P; the injury, L; and the burden, B; liabil= ity >> depends upon whether B is less than L multiplied by >> P: i.e., whether B is less than PL." >> United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Updated 1/26/04 >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. o= f >> Information Network Eng. INEG. INC. >> ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.= com >> Phone: 214-244-4827 >>=20 >>=20 >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85883A6BE8 for ; Mon, 18 Oct 2010 14:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55d7skDExQk6 for ; Mon, 18 Oct 2010 14:30:55 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 465903A6E8B for ; Mon, 18 Oct 2010 14:30:49 -0700 (PDT) Received: by fxm17 with SMTP id 17so1156768fxm.31 for ; Mon, 18 Oct 2010 14:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=WNcgr/WYKFpKRRjpjFkgfzJKcFhl9wJe7iwCjb2wmQU=; b=mjuEZmueDyb4Ba6HbTHUzMOhasYmLbJ5kgKniih0zURLVK0NQ70j60YrS81SlHrDJ1 ux3DOx7m9wKb2iUvQTDzbAl/JQaghcA0sOj67MiMTW6XXCr/NV0L/djFURpN87ImliW4 BkfHc7f7CnZ/+NOSr8mEb53XF3FQc3W45gZ90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ek/h4RbyfrglMrM6+je2Vs4NGCwMfOOI7vxjFJnMxRk4IuCYGHw6ipb+ECrc3kE2/l QiBiX0FJGSSE/GHu/DBrfaIBNfsg6cx+SmbzJvTj37CdnmiDoTN7Cp4JOFPgYDJ11OQT Yd1xAiZmXXMAmj3LXlOsSuZtutWGhbLPcjUDg= MIME-Version: 1.0 Received: by 10.239.180.80 with SMTP id h16mr107339hbg.128.1287437532855; Mon, 18 Oct 2010 14:32:12 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Mon, 18 Oct 2010 14:32:12 -0700 (PDT) Date: Mon, 18 Oct 2010 17:32:12 -0400 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org Content-Type: multipart/alternative; boundary=001485f7c3ecd0ff030492eae8ba Subject: [keyassure] Certification Authority Authorization Draft. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 21:30:56 -0000 --001485f7c3ecd0ff030492eae8ba Content-Type: text/plain; charset=ISO-8859-1 This is a draft that I submitted this morning. The main proposal being made here is to enable Certification Authorities to avoid mis-issue. As such I believe that it is complimentary to mechanisms that enable client side enforcement but has the considerable advantage of offering immediate protection to every Internet user regardless of whether they have an updated browser. It is also much less strongly dependent on deployment of DNSSEC. http://www.ietf.org/id/draft-hallambaker-donotissue-00.txt Given the nature of the proposal, it is probably better suited to having the bulk of the legal-technical work considered in CABForum rather than IETF. Accordingly the proposal is designed to allow the technical infrastructure to be agreed in IETF and then the practices and legal work done in CABForum. Clearly a record of this type could be used to effect client policy enforcement mechanisms. But this is a rather more complex issue and there are going to be a lot of people with views on the best way forward. The mechanism as specified is sufficient for allowing client side enforcement as it stands if the site is using a public CA, running a local CA cross certified into a public hierarchy or using a standalone private CA. But only if those infrastructures are supporting all their applications without exception. -- Website: http://hallambaker.com/ --001485f7c3ecd0ff030492eae8ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a draft that I submitted this morning. The main proposal being made= here is to enable Certification Authorities to avoid mis-issue.=A0
As such I believe that it is complimentary to mechanisms that e= nable client side enforcement but has the considerable advantage of offerin= g immediate protection to every Internet user regardless of whether they ha= ve an updated browser. It is also much less strongly dependent on deploymen= t of DNSSEC.=A0

Given the nature of = the proposal, it is probably better suited to having the bulk of the legal-= technical work considered in CABForum rather than IETF. Accordingly the pro= posal is designed to allow the technical infrastructure to be agreed in IET= F and then the practices and legal work done in CABForum.

Clearly a record of this type could be used to effect client= policy enforcement mechanisms. But this is a rather more complex issue and= there are going to be a lot of people with views on the best way forward.<= /div>

The mechanism as specified is sufficient for allowing c= lient side enforcement as it stands if the site is using a public CA, runni= ng a local CA cross certified into a public hierarchy or using a standalone= private CA. But only if those infrastructures are supporting all their app= lications without exception.

--001485f7c3ecd0ff030492eae8ba-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B993A6BF9 for ; Mon, 18 Oct 2010 14:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60hM4AaDl6qZ for ; Mon, 18 Oct 2010 14:29:32 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id EDF183A6AB6 for ; Mon, 18 Oct 2010 14:29:31 -0700 (PDT) Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o9ILV01u011777 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 18 Oct 2010 17:31:00 -0400 Received: from new-host-2.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9ILUxKO023545 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Oct 2010 17:31:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Schultze In-Reply-To: <20013730.1287417982521.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Mon, 18 Oct 2010 17:30:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9529321E-B9F4-4B86-8A26-0942B755424A@Princeton.EDU> References: <20013730.1287417982521.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6140 signatures=640565 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010180169 Subject: Re: [keyassure] CA-related event in DC on Friday X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 21:29:35 -0000 My apologies for the short notice. Frankly, I wasn't even sure if it was = appropriate to send event info to the list. I'm glad folks are = interested. At the event, I will be doing an extended introduction/tutorial along = with Ed Felten, and I'd be happy to make sure any input from the list is = represented. Feel free to email me directly or tweet to #ethreats. I = believe that there will also be a live stream (linked from the New = America events page), and the moderator will keep his eye on twitter = during the event. I'll also be in Beijing, and I'm looking forward to a more interactive = conversation there. Steve On Oct 18, 2010, at 12:06 PM, Jeffrey A. Williams wrote: > stephen and all, >=20 > Thanks for this information, but the thing is that we are > just 4 days before this event getting the information. That's > a bit short of a time lead. Will this event be taken on the road > perhaps in the near future? The video is fine, but doesn't allow > for much interaction... >=20 >=20 > -----Original Message----- >> From: Stephen Schultze >> Sent: Oct 18, 2010 9:39 AM >> To: keyassure@ietf.org >> Subject: [keyassure] CA-related event in DC on Friday >>=20 >> Hey all, those of you in the DC area you may be interested in an = event =20 >> my research center is hosting along with New America Foundation. The = =20 >> full description is below. Video will be available after the event. >>=20 >> =3D=3D >>=20 >> Emerging Threats to Online Trust: The Role of Public Policy and =20 >> Browser Certificates >> http://citp.princeton.edu/events/emerging-threats-to-online-trust/ >>=20 >> Date: Friday, October 22, 2010 >> Time: 9:00 AM - 11:00 AM >> Location: New America Foundation, 1899 L Street, NW, 4th Floor, =20 >> Washington DC 20036 >> Hashtag: #ethreats >>=20 >> Hosted by Princeton's Center for Information Technology Policy and = the =20 >> New America Foundation >>=20 >> Every day, we rely on our web browsers to keep our communications =20 >> secure. Whether we are submitting our credit card for purchases, = doing =20 >> online banking, or sending email, the same fundamental security =20 >> structure is being used. The lock icon displayed by web browsers = might =20 >> give users reason to believe that the prevailing "certificate"-based =20= >> model is trustworthy, but the reality is that many vulnerabilities =20= >> exist and the risks are multiplying. Hundreds of different entities =20= >> located around the world have the ability to issue fraudulent =20 >> certificates that will nevertheless be trusted by our browsers. =20 >> Overcoming the shortcomings in the current model and working toward a = =20 >> better model requires cooperation of corporations, the government, =20= >> developers, and users. Many of the most difficult challenges are not =20= >> technical in nature but rather social or political. >>=20 >> Keynote: >> Andrew McLaughlin, White House Deputy CTO, Internet Policy >>=20 >> Panelists: >> Peter Eckersley, Senior Staff Technologist, Electronic Frontier =20 >> Foundation >> Adam Langley, Senior Software Engineer, Google >> Scott Rea, Senior PKI Architect, DigiCert >> Paul Vixie, President, Internet Software Consortium >>=20 >> Respondents: >> Ari Schwartz, Senior Internet Policy Advisor, National Institute of =20= >> Standards and Technology >> Andy Steingruebl, Manager, Internet Standards and Governance, PayPal >>=20 >> This event is free and open to the public. Please rsvp at: >> http://www.newamerica.net/events/2010/online_trust >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=20 > Regards, > Jeffrey A. Williams > "Obedience of the law is the greatest freedom" - > Abraham Lincoln >=20 > "Credit should go with the performance of duty and not with what is = very > often the accident of glory" - Theodore Roosevelt >=20 > "If the probability be called P; the injury, L; and the burden, B; = liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. = div. of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail = jwkckid1@ix.netcom.com > Phone: 214-244-4827 >=20 >=20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01923A6D8F for ; Mon, 18 Oct 2010 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in77Rl-yy5qJ for ; Mon, 18 Oct 2010 09:04:54 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 26BD63A6A09 for ; Mon, 18 Oct 2010 09:04:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=LWcEHHRYt9sNpG/l8esH3C2nj8GWaLy7SWMCJwDbw21XZg1+vU9AxWxSAb0EmyX+; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P7sEA-0003zu-IB; Mon, 18 Oct 2010 12:06:22 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Mon, 18 Oct 2010 12:06:22 -0400 Message-ID: <20013730.1287417982521.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Mon, 18 Oct 2010 11:06:22 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Stephen Schultze , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688bea7f8248c0a68665c59eb59bbcefc40350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Subject: Re: [keyassure] CA-related event in DC on Friday X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 16:04:56 -0000 stephen and all, Thanks for this information, but the thing is that we are just 4 days before this event getting the information. That's a bit short of a time lead. Will this event be taken on the road perhaps in the near future? The video is fine, but doesn't allow for much interaction... -----Original Message----- >From: Stephen Schultze >Sent: Oct 18, 2010 9:39 AM >To: keyassure@ietf.org >Subject: [keyassure] CA-related event in DC on Friday > >Hey all, those of you in the DC area you may be interested in an event >my research center is hosting along with New America Foundation. The >full description is below. Video will be available after the event. > >== > >Emerging Threats to Online Trust: The Role of Public Policy and >Browser Certificates >http://citp.princeton.edu/events/emerging-threats-to-online-trust/ > >Date: Friday, October 22, 2010 >Time: 9:00 AM - 11:00 AM >Location: New America Foundation, 1899 L Street, NW, 4th Floor, >Washington DC 20036 >Hashtag: #ethreats > >Hosted by Princeton's Center for Information Technology Policy and the >New America Foundation > >Every day, we rely on our web browsers to keep our communications >secure. Whether we are submitting our credit card for purchases, doing >online banking, or sending email, the same fundamental security >structure is being used. The lock icon displayed by web browsers might >give users reason to believe that the prevailing "certificate"-based >model is trustworthy, but the reality is that many vulnerabilities >exist and the risks are multiplying. Hundreds of different entities >located around the world have the ability to issue fraudulent >certificates that will nevertheless be trusted by our browsers. >Overcoming the shortcomings in the current model and working toward a >better model requires cooperation of corporations, the government, >developers, and users. Many of the most difficult challenges are not >technical in nature but rather social or political. > >Keynote: >Andrew McLaughlin, White House Deputy CTO, Internet Policy > >Panelists: >Peter Eckersley, Senior Staff Technologist, Electronic Frontier >Foundation >Adam Langley, Senior Software Engineer, Google >Scott Rea, Senior PKI Architect, DigiCert >Paul Vixie, President, Internet Software Consortium > >Respondents: >Ari Schwartz, Senior Internet Policy Advisor, National Institute of >Standards and Technology >Andy Steingruebl, Manager, Internet Standards and Governance, PayPal > >This event is free and open to the public. Please rsvp at: >http://www.newamerica.net/events/2010/online_trust >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711DD3A69A4 for ; Mon, 18 Oct 2010 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6EJyOxZw8Cp for ; Mon, 18 Oct 2010 07:38:17 -0700 (PDT) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 761E53A6B31 for ; Mon, 18 Oct 2010 07:38:17 -0700 (PDT) Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id o9IEdbAp010096 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 18 Oct 2010 10:39:44 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by smtpserver1.Princeton.EDU (8.12.9/8.12.9) with ESMTP id o9IEdaB3021746 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Oct 2010 10:39:37 -0400 (EDT) Message-Id: From: Stephen Schultze To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 18 Oct 2010 10:39:36 -0400 X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6139 signatures=640564 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=100 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1010180089 Subject: [keyassure] CA-related event in DC on Friday X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 14:38:19 -0000 Hey all, those of you in the DC area you may be interested in an event my research center is hosting along with New America Foundation. The full description is below. Video will be available after the event. == Emerging Threats to Online Trust: The Role of Public Policy and Browser Certificates http://citp.princeton.edu/events/emerging-threats-to-online-trust/ Date: Friday, October 22, 2010 Time: 9:00 AM - 11:00 AM Location: New America Foundation, 1899 L Street, NW, 4th Floor, Washington DC 20036 Hashtag: #ethreats Hosted by Princeton's Center for Information Technology Policy and the New America Foundation Every day, we rely on our web browsers to keep our communications secure. Whether we are submitting our credit card for purchases, doing online banking, or sending email, the same fundamental security structure is being used. The lock icon displayed by web browsers might give users reason to believe that the prevailing "certificate"-based model is trustworthy, but the reality is that many vulnerabilities exist and the risks are multiplying. Hundreds of different entities located around the world have the ability to issue fraudulent certificates that will nevertheless be trusted by our browsers. Overcoming the shortcomings in the current model and working toward a better model requires cooperation of corporations, the government, developers, and users. Many of the most difficult challenges are not technical in nature but rather social or political. Keynote: Andrew McLaughlin, White House Deputy CTO, Internet Policy Panelists: Peter Eckersley, Senior Staff Technologist, Electronic Frontier Foundation Adam Langley, Senior Software Engineer, Google Scott Rea, Senior PKI Architect, DigiCert Paul Vixie, President, Internet Software Consortium Respondents: Ari Schwartz, Senior Internet Policy Advisor, National Institute of Standards and Technology Andy Steingruebl, Manager, Internet Standards and Governance, PayPal This event is free and open to the public. Please rsvp at: http://www.newamerica.net/events/2010/online_trust Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547593A69B4 for ; Tue, 12 Oct 2010 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RMML_Stock1=0.21] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7QtW+BFWffR for ; Tue, 12 Oct 2010 08:22:06 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by core3.amsl.com (Postfix) with ESMTP id E4B193A699E for ; Tue, 12 Oct 2010 08:22:05 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E7F354780E9; Tue, 12 Oct 2010 15:23:19 +0000 (GMT) Received: from prod-mail-relay01.akamai.com (unknown [172.17.50.20]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id D09A24780D6; Tue, 12 Oct 2010 15:23:19 +0000 (UTC) Received: from duryanta.kendall.corp.akamai.com (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay01.akamai.com (Postfix) with ESMTP id C4BEA22604D; Tue, 12 Oct 2010 15:23:19 +0000 (GMT) Received: by duryanta.kendall.corp.akamai.com (Postfix, from userid 501) id 5C07EB473CB; Tue, 12 Oct 2010 11:23:19 -0400 (EDT) From: Brian Sniffen To: Tony Finch References: <50A38D0D-8F66-4A8B-836A-9C8A5C0F9280@bbn.com> <19F4493A-6E3E-418F-9643-1F8D578C3C20@gmail.com> Date: Tue, 12 Oct 2010 11:23:18 -0400 In-Reply-To: (Tony Finch's message of "Thu, 19 Aug 2010 19:41:05 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] key per host X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 15:22:08 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Finch writes: >> Say that I am managing 100,000 sites on 100 actual machines. Do I want >> to have to manage 100,000 keys that are bound to the sites or 100 keys >> that are bound to machines? Note that the sites float fairly freely >> from machine to machine and moving crypto on machines that use crypto >> accelerators is non-trivial. > > If the server farm acts as a single service then a single key would seem > right to me. The crypto accelerator is more likely to live on the load > balancer than the servers. We certainly find need to use multiple keys to identify each of several principals authorized to provide a service. For example, Example, Inc. might hold one key & certificate for www.example.com and authorize a CDN or service provider to also provide service for www.example.com. Each such service provider commonly generates his own key and requests his own certificate---it saves arguing about who compromised a key, for example. =2D -Brian =2D --=20 Brian T. Sniffen Information Security Akamai Technologies, Inc. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAky0fWYACgkQjNCI4p/QmrpD/wCeNIqzxO71CcpHf50WxegKn9Hx LuUAoJEN9FLUbXiIIaspEylz0tCjUH8j =3DBasR =2D----END PGP SIGNATURE----- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD8C3A6B19 for ; Mon, 11 Oct 2010 09:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXQTsPQN1ep1 for ; Mon, 11 Oct 2010 09:04:34 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 216843A6A00 for ; Mon, 11 Oct 2010 09:04:33 -0700 (PDT) Received: by fxm17 with SMTP id 17so579187fxm.31 for ; Mon, 11 Oct 2010 09:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XSOaRTfFQ1p53OqkiPTRP3ToQhr9jxzvmy4uTm0G5Fs=; b=r2DQyEqfdfPqz0qMXa8JR155rmaLiPpFICVxaEaPut2JrZ/qiW8ehq6UG/B+t8g2RD Cwl9NCMaVEoa7RrsxMJSmxAZHZNJ2msgGVAVSd45S5cM0EltuX7IdnsNQzABu9RtTcFu CQnfQWDvA4zeB6Ofj9z4Vyw++Hgg8wsIFKkQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FV3W4mdy0QUiiqsCw7hP/45emt9W3VvEsXiyXKofvf1L6wFuUK8DCV0hkAg/Zna9eD oKRr/55NYii5e1xysgq4A/HQz/2F2V2IrGhuyM07iAQfOeDfJ9JSmgAO3ftrgnQWrIsX zy6c/2VUYHhqi+cX1y/YZSWh5Y/8iew8d53UI= MIME-Version: 1.0 Received: by 10.239.172.69 with SMTP id z5mr353107hbe.170.1286813145465; Mon, 11 Oct 2010 09:05:45 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Mon, 11 Oct 2010 09:05:45 -0700 (PDT) In-Reply-To: References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> <457BA40A-C5AE-4585-ADC9-84A0DC2ED478@dotat.at> <20101011051456.GA22178@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 11 Oct 2010 12:05:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001485f03cac6d851404925988a2 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 16:04:36 -0000 --001485f03cac6d851404925988a2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 11, 2010 at 9:42 AM, Tony Finch wrote: > On 11 Oct 2010, at 06:14, Ilari Liusvaara > wrote: > > > > Also, "do not issue" advisories are not enough against rogue (or just > plain > > careless[*]!) CAs. Against those you need genuine chaining restrictions > > Phill's proposal includes that. > > > or exhaustive end-server cert enumeration. > > I think this should not be necessary. If you don't trust your CA to issue > certs to the right people, why are you buying certs from them? > > Also I am worried that this requires too much complexity to deal with the > many-certs case, and will be bad for performance if the DNS lookup has to > be delayed until the TLS handshake. > > > I'm inclined to say the client's logic should be to accept the cert if any > of the certs in the chain (including the server cert itself) match any > TLSFP record [0] in the DNS. Then you can either enumerate all the server > certs or rely on CA "do not issue" rules. Sadly you can't have both > because listing a CA cert implicitly authorizes any subordinate cert, > which negates the point of server cert enumeration. > I agree that there are cases where there is a risk of either a CA default or a CA being co-erced. But they are rather complex corner cases and require assumptions that would invalidate any technology. In the case where an end entity requires local control, the solution in my view would be for them to either deploy their own cert issuing CA or deploy a CA that cross certifies the end entity certs. I cannot really see a commercial need for this approach, but there could be a need in a government deployment. So for example, say that you deploy Windows Server CA internally and get a cross cert that chains your CA root to a public one. In that case you would put out a policy statement with the FP of the intermediate root that you control. That is going to be a lot easier to manage than the enumeration approach because all the necessary software to run that type of system already exists and is mature. The enumeration approach would require tight integration between the PKI and the DNS which is an entirely new approach. -- Website: http://hallambaker.com/ --001485f03cac6d851404925988a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2010 at 9:42 AM, Tony Finch <dot@dotat.at> wrote:
On 11 Oct 2010, at 06:14, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wro= te:
>
> Also, "do not issue" advisories are not enough against rogue= (or just plain
> careless[*]!) CAs. Against those you need genuine chaining restriction= s

Phill's proposal includes that.

> or exhaustive end-server cert enumeration.

I think this should not be necessary. If you don't trust your CA = to issue
certs to the right people, why are you buying certs from them?

Also I am worried that this requires too much complexity to deal with the many-certs case, and will be bad for performance if the DNS lookup has to be delayed until the TLS handshake.


I'm inclined to say the client's logic should be to accept the cert= if any
of the certs in the chain (including the server cert itself) match any
TLSFP record [0] in the DNS. Then you can either enumerate all the server certs or rely on CA "do not issue" rules. Sadly you can't hav= e both
because listing a CA cert implicitly authorizes any subordinate cert,
which negates the point of server cert enumeration.
I agree that there are cases where there is a risk of either a= CA default or a CA being co-erced. But they are rather complex corner case= s and require assumptions that would invalidate any technology.


In the case where an end entity requires= local control, the solution in my view would be for them to either deploy = their own cert issuing CA or deploy a CA that cross certifies the end entit= y certs.=A0

I cannot really see a commercial need for this approach= , but there could be a need in a government deployment.


So for example, say that you deploy Windows Server CA = internally and get a cross cert that chains your CA root to a public one. I= n that case you would put out a policy statement with the FP of the interme= diate root that you control.

That is going to be a lot easier to manage than the enu= meration approach because all the necessary software to run that type of sy= stem already exists and is mature. The enumeration approach would require t= ight integration between the PKI and the DNS which is an entirely new appro= ach.

=A0
--
Website: http://hallambaker.com/

--001485f03cac6d851404925988a2-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B8D3A68D6 for ; Mon, 11 Oct 2010 08:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD1g3GWZz5OC for ; Mon, 11 Oct 2010 08:40:18 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 305253A68D5 for ; Mon, 11 Oct 2010 08:40:11 -0700 (PDT) Received: by fxm17 with SMTP id 17so559200fxm.31 for ; Mon, 11 Oct 2010 08:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=d7Yo6Z2JPK5KWBRnJt6uUsBBmp3m4A5DZKp56NU/7nA=; b=FyFEfZsDMUNEG0oiaohccv45Z+MMf21ocCvPlx/HysMJ09vZ1dyRrGyMGSDM/s/HFo P0WNmqWrk9X2QGCfHK6GShv+xW5KuOz5CxPoKlzfzhekjNgBMSJ6DAppi8LGP53++NTe 4H/9LIYaVTJ6goVZC7nEgKe0eSp0Nbsl08L0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fdrL/xZBOBLp5akuoF0iANv9rhWbfxVGYmPKka16Ufa89JtEh2yFIxl3dKep0GWgvy Ji15DXpp/Y0eOWI7VfjQI8QwwOUXWO7p9j/49aZzMZIw7ucwt0plLwCemXD6cUclHUS2 Mr5Q/u1Vap8i30o2qrPV8HE3Jm5045LsafvSU= MIME-Version: 1.0 Received: by 10.239.164.20 with SMTP id r20mr434533hbd.60.1286811680383; Mon, 11 Oct 2010 08:41:20 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Mon, 11 Oct 2010 08:41:20 -0700 (PDT) In-Reply-To: <4CB2BC6E.3010604@nic.cz> References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <4CB2BC6E.3010604@nic.cz> Date: Mon, 11 Oct 2010 11:41:20 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001485f199f01a24dc0492593176 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 15:40:22 -0000 --001485f199f01a24dc0492593176 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Ondrej, I am not trying to 'obstruct' the WG as you claim. I have been through IETF process many times over the past 18 years. I have also had a hand in creating many of the alternative standardization routes so I can tell you those pitfalls as well. I would have absolutely no problem with a WG that is only going to specify additional methods of telling a client that it can trust a key. Which is what you appear to think that the group is limited to. My problem is with a proposal that has an implicit condition that if there is one FP specified in the DNS, then a client MUST regard the absence of a matching FP to invalidate any other certificate regardless of whether there is a valid PKIX chain or not. Now you may not be aware that this is what some people are proposing but th= e fact is that (1) they are and (2) they believe that it is a rather importan= t requirement. This is precisely the type of thing that it is important to get clear befor= e you submit the charter. The fact that the prototype code that has been deployed already implements these semantics is rather relevant. As for the milestones, you want to manage expectations and specify the longest time period the ADs will allow you to get away with. I cannot possibly imagine them insisting on the milestones being shorter than a year= . There are many aspects of IETF process that are completely out of control o= f the WG chairs and authors. On Mon, Oct 11, 2010 at 3:27 AM, Ond=F8ej Sur=FD wrote= : > Just to clarify. This group has nothing to do with Dan Kaminsky and it's > not based on his work. Neither his name nor his presentation was pointed > out neither when we did bar-BoF nor when we started mailing list. > > This group was started on basis of work of earlier IETF contributors as w= as > Simon Josefsson, Jakob Schlyter and others.[1] It was merely meant as a > revival of that work after we started having DNSSEC signed root. > > I spoke to different parties and everybody seemed to be working on > "something like this", and because I didn't want to have divergence on th= e > market, I tried to concentrate work done into this place. (Even though I > was warned that IETF way is painful and we better keep this outside.) > > And Phillip, I would really like to see if you can stop obstructing the > work here by sending tons of emails where you reiterate your ideas again = and > again just because you have entirely different idea what this group shoul= d > be doing. Your ideas about the work for this to-be-WG is that much > different that you should create your own WG. I wouldn't mind. But don't > try to change this group into something it isn't and was never meant to b= e. > > O. > Links: > 1. http://www.ietf.org/mail-archive/web/keyassure/current/msg00002.html > > > On 8.10.2010 18:53, Phillip Hallam-Baker wrote: > >> At BH, Dan Kaminsky presented a paper where he identified the lack of >> standards for issuing DV certificates as a problem and suggested an >> alternative scheme based on DNSSEC which would have two purposes: >> >> 1) Enable a domain name owner to validate keys at the DV level >> 2) Enable a domain name owner to prevent clients that support the >> proposed mechanism from trusting certificates that they did not authoriz= e. >> >> >> I did not attend BH this year and so when I saw the group formed I >> assumed that the only requirement it was intended to address was the >> first one. >> >> This week I have spoken to or otherwise communicated to several of the >> draft authors offlist. I have confirmed with them that the purpose of >> enabling a domain name owner to prevent use of the certificates is >> indeed one of their principal objectives. >> >> >> Now if you want to rule the second purpose out of the charter, that is >> fine with me. But the fact remains that the technical complexity of >> putting any form of restriction in the client is vastly greater than the >> complexity of a mandate that is imposed on the issuing CAs. >> >> Whether or not this group wishes to be a part of the 'do not issue' >> approach, it is a simpler approach and one that offers benefits to both >> CAs and to the users of legacy browsers and browsers that choose not to >> deploy an enumeration based restriction scheme. And while it can make >> use of DNSSEC, it is not dependent on DNSSEC deployment. >> >> I would see the forum for addressing do-not-issue to be CABForum more >> than IETF. >> >> The reason it is relevant here is because it bears on the same original >> requirement and may well pre-empt it to an extent. It is not possible to >> use the enumeration approach as the basis of do-not-issue for obvious >> reasons (can't take the hash of a cert before it is issued). >> >> So there is going to be do-not-issue information in the DNS that can >> potentially be applied to solve this problem equally well and with a far >> lower maintenance requirement than this particular scheme. >> >> -- >> Website: http://hallambaker.com/ >> >> > > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > --=20 Website: http://hallambaker.com/ --001485f199f01a24dc0492593176 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Ondrej,

I am not trying to 'obstruct' the WG as = you claim.

I have been through IETF process many t= imes over the past 18 years. I have also had a hand in creating many of the= alternative standardization routes so I can tell you those pitfalls as wel= l.


I would have absolutely no problem with = a WG that is only going to specify additional methods of telling a client t= hat it can trust a key. Which is what you appear to think that the group is= limited to.

My problem is with a proposal that has an implicit cond= ition that if there is one FP specified in the DNS, then a client MUST rega= rd the absence of a matching FP to invalidate any other certificate regardl= ess of whether there is a valid PKIX chain or not.


Now you may not be aware that this is wh= at some people are proposing but the fact is that (1) they are and (2) they= believe that it is a rather important requirement.

This is precisely the type of thing that it is important to get clear = before you submit the charter. The fact that the prototype code that has be= en deployed already implements these semantics is rather relevant.


As for the milestones, you want to manag= e expectations and specify the longest time period the ADs will allow you t= o get away with. I cannot possibly imagine them insisting on the milestones= being shorter than a year.

There are many aspects of IETF process that are complet= ely out of control of the WG chairs and authors.

<= br>
On Mon, Oct 11, 2010 at 3:27 AM, Ond=F8ej Sur= =FD <ondrej.sury= @nic.cz> wrote:
Just to clarify. =A0This group has nothing = to do with Dan Kaminsky and it's not based on his work. =A0Neither his = name nor his presentation was pointed out neither when we did bar-BoF nor w= hen we started mailing list.

This group was started on basis of work of earlier IETF contributors as was= Simon Josefsson, Jakob Schlyter and others.[1] =A0It was merely meant as a= revival of that work after we started having DNSSEC signed root.

I spoke to different parties and everybody seemed to be working on "so= mething like this", and because I didn't want to have divergence o= n the market, I tried to concentrate work done into this place. =A0(Even th= ough I was warned that IETF way is painful and we better keep this outside.= )

And Phillip, I would really like to see if you can stop obstructing the wor= k here by sending tons of emails where you reiterate your ideas again and a= gain just because you have entirely different idea what this group should b= e doing. =A0Your ideas about the work for this to-be-WG is that much differ= ent that you should create your own WG. =A0I wouldn't mind. But don'= ;t try to change this group into something it isn't and was never meant= to be.

O.
Links:
1. http://www.ietf.org/mail-archive/web/keyassure/c= urrent/msg00002.html


On 8.10.2010 18:53, Phillip Hallam-Baker wrote:
At BH, Dan Kaminsky presented a paper where he identified the lack of
standards for issuing DV certificates as a problem and suggested an
alternative scheme based on DNSSEC which would have two purposes:

1) Enable a domain name owner to validate keys at the DV level
2) Enable a domain name owner to prevent clients that support the
proposed mechanism from trusting certificates that they did not authorize.<= br>

I did not attend BH this year and so when I saw the group formed I
assumed that the only requirement it was intended to address was the
first one.

This week I have spoken to or otherwise communicated to several of the
draft authors offlist. I have confirmed with them that the purpose of
enabling a domain name owner to prevent use of the certificates is
indeed one of their principal objectives.


Now if you want to rule the second purpose out of the charter, that is
fine with me. But the fact remains that the technical complexity of
putting any form of restriction in the client is vastly greater than the complexity of a mandate that is imposed on the issuing CAs.

Whether or not this group wishes to be a part of the 'do not issue'=
approach, it is a simpler approach and one that offers benefits to both
CAs and to the users of legacy browsers and browsers that choose not to
deploy an enumeration based restriction scheme. And while it can make
use of DNSSEC, it is not dependent on DNSSEC deployment.

I would see the forum for addressing do-not-issue to be CABForum more
than IETF.

The reason it is relevant here is because it bears on the same original
requirement and may well pre-empt it to an extent. It is not possible to use the enumeration approach as the basis of do-not-issue for obvious
reasons (can't take the hash of a cert before it is issued).

So there is going to be do-not-issue information in the DNS that can
potentially be applied to solve this problem equally well and with a far lower maintenance requirement than this particular scheme.

--
Website: http://halla= mbaker.com/



--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------



--
Website: http://hallambaker.com/

--001485f199f01a24dc0492593176-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB373A6A5A for ; Mon, 11 Oct 2010 06:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o85OnPTmYh9h for ; Mon, 11 Oct 2010 06:41:17 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id 9A51B3A6A3C for ; Mon, 11 Oct 2010 06:41:16 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51999) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1P5Ie3-0003He-E8 (Exim 4.72) (return-path ); Mon, 11 Oct 2010 14:42:27 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1P5Ie3-0003Ii-By (Exim 4.67) (return-path ); Mon, 11 Oct 2010 14:42:27 +0100 Date: Mon, 11 Oct 2010 14:42:27 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ilari Liusvaara In-Reply-To: <20101011051456.GA22178@LK-Perkele-V2.elisa-laajakaista.fi> Message-ID: References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> <457BA40A-C5AE-4585-ADC9-84A0DC2ED478@dotat.at> <20101011051456.GA22178@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 13:41:18 -0000 On 11 Oct 2010, at 06:14, Ilari Liusvaara wrote: > > Also, "do not issue" advisories are not enough against rogue (or just plain > careless[*]!) CAs. Against those you need genuine chaining restrictions Phill's proposal includes that. > or exhaustive end-server cert enumeration. I think this should not be necessary. If you don't trust your CA to issue certs to the right people, why are you buying certs from them? Also I am worried that this requires too much complexity to deal with the many-certs case, and will be bad for performance if the DNS lookup has to be delayed until the TLS handshake. I'm inclined to say the client's logic should be to accept the cert if any of the certs in the chain (including the server cert itself) match any TLSFP record [0] in the DNS. Then you can either enumerate all the server certs or rely on CA "do not issue" rules. Sadly you can't have both because listing a CA cert implicitly authorizes any subordinate cert, which negates the point of server cert enumeration. [0] or whatever we settle on Tony. -- f.anthony.n.finch http://dotat.at/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18703A68E4 for ; Mon, 11 Oct 2010 00:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAAoiHbVZHur for ; Mon, 11 Oct 2010 00:26:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 287663A6909 for ; Mon, 11 Oct 2010 00:26:32 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id A6DA67343AB; Mon, 11 Oct 2010 09:27:42 +0200 (CEST) Message-ID: <4CB2BC6E.3010604@nic.cz> Date: Mon, 11 Oct 2010 09:27:42 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 07:26:36 -0000 Just to clarify. This group has nothing to do with Dan Kaminsky and it's not based on his work. Neither his name nor his presentation was pointed out neither when we did bar-BoF nor when we started mailing list. This group was started on basis of work of earlier IETF contributors as was Simon Josefsson, Jakob Schlyter and others.[1] It was merely meant as a revival of that work after we started having DNSSEC signed root. I spoke to different parties and everybody seemed to be working on "something like this", and because I didn't want to have divergence on the market, I tried to concentrate work done into this place. (Even though I was warned that IETF way is painful and we better keep this outside.) And Phillip, I would really like to see if you can stop obstructing the work here by sending tons of emails where you reiterate your ideas again and again just because you have entirely different idea what this group should be doing. Your ideas about the work for this to-be-WG is that much different that you should create your own WG. I wouldn't mind. But don't try to change this group into something it isn't and was never meant to be. O. Links: 1. http://www.ietf.org/mail-archive/web/keyassure/current/msg00002.html On 8.10.2010 18:53, Phillip Hallam-Baker wrote: > At BH, Dan Kaminsky presented a paper where he identified the lack of > standards for issuing DV certificates as a problem and suggested an > alternative scheme based on DNSSEC which would have two purposes: > > 1) Enable a domain name owner to validate keys at the DV level > 2) Enable a domain name owner to prevent clients that support the > proposed mechanism from trusting certificates that they did not authorize. > > > I did not attend BH this year and so when I saw the group formed I > assumed that the only requirement it was intended to address was the > first one. > > This week I have spoken to or otherwise communicated to several of the > draft authors offlist. I have confirmed with them that the purpose of > enabling a domain name owner to prevent use of the certificates is > indeed one of their principal objectives. > > > Now if you want to rule the second purpose out of the charter, that is > fine with me. But the fact remains that the technical complexity of > putting any form of restriction in the client is vastly greater than the > complexity of a mandate that is imposed on the issuing CAs. > > Whether or not this group wishes to be a part of the 'do not issue' > approach, it is a simpler approach and one that offers benefits to both > CAs and to the users of legacy browsers and browsers that choose not to > deploy an enumeration based restriction scheme. And while it can make > use of DNSSEC, it is not dependent on DNSSEC deployment. > > I would see the forum for addressing do-not-issue to be CABForum more > than IETF. > > The reason it is relevant here is because it bears on the same original > requirement and may well pre-empt it to an extent. It is not possible to > use the enumeration approach as the basis of do-not-issue for obvious > reasons (can't take the hash of a cert before it is issued). > > So there is going to be do-not-issue information in the DNS that can > potentially be applied to solve this problem equally well and with a far > lower maintenance requirement than this particular scheme. > > -- > Website: http://hallambaker.com/ > -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14D03A690D for ; Mon, 11 Oct 2010 00:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x56gQiIqN8OB for ; Mon, 11 Oct 2010 00:17:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 169693A68EA for ; Mon, 11 Oct 2010 00:17:09 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 9201673444D for ; Mon, 11 Oct 2010 09:18:18 +0200 (CEST) Message-ID: <4CB2BA3A.2090806@nic.cz> Date: Mon, 11 Oct 2010 09:18:18 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: keyassure@ietf.org References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 07:17:12 -0000 Phillip, We spoke to ADs before we sent the charter, and we sent the charter to them upon their request (after we ironed out few flaws we had in the charter). And I am quite sure that if such a danger existed, the ADs would point that out. Also we have a recent precedent - the websec WG (former HASMAT) was recently approved[1] and it has requested BoF before it was approved for Beijing[2]. O. Links: 1. http://www.ietf.org/mail-archive/web/hasmat/current/msg00123.html 2. http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Applications On 8.10.2010 16:26, Phillip Hallam-Baker wrote: > As I pointed out to Ondrej offlist, > > A WG meeting has a minimum notice period that is constrained by legal > considerations, visa issue requirements and a whole host of travel > planning issues. > > If the group is chartered before Beijing it cannot have a BOF and it > cannot have a WG meeting either. > > So sending the charter to the ADs in advance of the meeting is probably > a mistake. > > The BOF is an opportunity to advertise the work to the wider IETF > community. It is your single best advertising and marketing opportunity. > > > The charter milestones are completely unrealistic. > > Time and again I see WG charters propose unrealistic milestones that are > then used to constrain the discussion on the basis that there is no time > to consider other options. > > The result is inevitably that the WG takes far longer than it would have > done had the milestones been realistic. > > > We can come to agreement almost immediately on a proposal to use the DNS > to validate keys. The tricky part is how to use DNS to constrain key > validity. > > So far the group has only discussed one mechanism that is designed to > constrain key validity after issue. But that is not the only option, a > much more powerful and lower impact approach is to provide mechanisms > that enable domain name owners to avoid mis-issue. > > There is really no need or point to scheduling milestones for submission > of initial drafts. The charter states that there are input drafts, that > is enough. > > As far as work schedules go, I think it is realistic to have a draft > ready for IESG review that describes a mechanism for key validation and > for publishing 'do not issue' advice to CAs by March. Describing a > mechanism for client side enforcement is a lot more involved and > necessitates consideration of lots of application details. So November > 2011 is optimistic. > > The Shepherding process for turning drafts into standards always takes > much longer than everyone expects, even people who have done something > before. > > Rushing a proposal through a WG only makes the process take a lot longer > with much less control. Issues that could have been disposed of quickly > end up taking much longer as the IESG raises them and takes much longer > to dispose of them because they are overloaded. > > > On Fri, Oct 8, 2010 at 4:15 AM, Ondřej Surý > wrote: > > On 6.10.2010 17:09, Ondřej Surý wrote: > > Hi all, > > since the proposed charter is quite stable for a last week or so > with small exceptions of small nits, we (me and Warren) believed > that > the charter is good to go and that we have a rough consensus on the > charter, and so we asked our fellow ADs to process it accordingly to > IETF processes, ie. take it to the IESG. > > With some luck that could mean that we can make it to be WG in the > time of Beijing meeting. > > I would like to thank all the contributors to the charter, so thank > you all. > > Regards, Ondrej > > > Bill has asked me to post a charter as sent to ADs: > > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure > > Here's verbatim copy of that page for an evidence: > > Objective: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS for discovering and authenticating public > keys which are associated with a service located at a domain name. > > Problem Statement: > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com ". Security > protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. > > Milestones: > Nov 2010 First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > Jan 2011 First WG draft of standards-track protocols for using DNS to > associate hosts with IPsec > Jun 2011 Protocol for using DNS to associate domain names with keys > for TLS and DTLS to IESG > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG > Aug 2011 Recharter > > O. > > -- > Ondřej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > > > -- > Website: http://hallambaker.com/ > -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD503A68E7 for ; Sun, 10 Oct 2010 22:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5iU+5TVnup4 for ; Sun, 10 Oct 2010 22:07:20 -0700 (PDT) Received: from emh05.mail.saunalahti.fi (emh05.mail.saunalahti.fi [62.142.5.111]) by core3.amsl.com (Postfix) with ESMTP id 3F0EB3A68E4 for ; Sun, 10 Oct 2010 22:07:18 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh05-2.mail.saunalahti.fi (Postfix) with SMTP id D949C8BE11; Mon, 11 Oct 2010 08:08:27 +0300 (EEST) Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A022B6D4FA8; Mon, 11 Oct 2010 08:08:27 +0300 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id B3C262BD49; Mon, 11 Oct 2010 08:08:24 +0300 (EEST) Date: Mon, 11 Oct 2010 08:14:56 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20101011051456.GA22178@LK-Perkele-V2.elisa-laajakaista.fi> References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> <457BA40A-C5AE-4585-ADC9-84A0DC2ED478@dotat.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Tony Finch , "keyassure@ietf.org" Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 05:07:24 -0000 On Sun, Oct 10, 2010 at 11:18:51PM -0400, Phillip Hallam-Baker wrote: > One scheme can certainly do both. > > But changing CA practices when there is a dramatic and immediate advantage > to the CA is much easier than working out 'fire and forget' rules for client > side processing and getting them agreed amongst the various IETF groups > affected. The only three (present or near term future) ones that spring to mind are: - HASMAT - PKIX - Keyassure (this group) (I didn't put TLS on that list because authentication issues are AFAIK outside its scope). Also, "do not issue" advisories are not enough against rogue (or just plain careless[*]!) CAs. Against those you need genuine chaining restrictions or exhaustive end-server cert enumeration. [*] Remember, X.509 is only as strong as weakest acceptable CA. -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69ED3A63C9 for ; Sun, 10 Oct 2010 20:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWJV7mlVDrqm for ; Sun, 10 Oct 2010 20:17:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5A98B3A68B8 for ; Sun, 10 Oct 2010 20:17:43 -0700 (PDT) Received: by fxm17 with SMTP id 17so271537fxm.31 for ; Sun, 10 Oct 2010 20:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mYdpD/T9SRt70Vciy+uqak0pqKk5jf520sQlM7pn8co=; b=pL8MvMXoWY0gCfzMT8luxxiesZD51GRDFmbLZ5UaffAaC2/BCkoTmqdjH5t2xWfw7K K+3HpU5Q4HN2Qikrf4iGnxxID0dlP4gCMnjz2qVcOQ8ooMJIKekEDaxs45iy40PpkZmO LihRBwFjLWCI2mS0okZCjNx6HyWoYqvh9UYAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uVJxSeH5UTqnN4iG1K/f63RthzFFDc9S9GfPjV4Dl/Y+R6hLJX0e+wECqvh1i66o0B gN1Dg+9F/OlsRWyNiVDLksVq8liD/N5itOgpdy6j9UqeiUJrM6ezqy0JWpPD9zsPKnHi o74UY30GS0xufrQ6ufqSJQeD6kZGOzQhc1ya0= MIME-Version: 1.0 Received: by 10.239.164.20 with SMTP id r20mr388177hbd.60.1286767131899; Sun, 10 Oct 2010 20:18:51 -0700 (PDT) Received: by 10.239.156.141 with HTTP; Sun, 10 Oct 2010 20:18:51 -0700 (PDT) In-Reply-To: <457BA40A-C5AE-4585-ADC9-84A0DC2ED478@dotat.at> References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> <457BA40A-C5AE-4585-ADC9-84A0DC2ED478@dotat.at> Date: Sun, 10 Oct 2010 23:18:51 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001485f199f0ce35d704924ed140 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 03:17:47 -0000 --001485f199f0ce35d704924ed140 Content-Type: text/plain; charset=ISO-8859-1 One scheme can certainly do both. But changing CA practices when there is a dramatic and immediate advantage to the CA is much easier than working out 'fire and forget' rules for client side processing and getting them agreed amongst the various IETF groups affected. I tend to think that the proper procedure on this concept would be to have the IETF assign the RR code but hand as much work as possible on the practices side to the CABForum where there are lawyers who like writing rules for that sort of thing. I certainly want to do client side rules. But realistically we only get one chance to do those right. On Sun, Oct 10, 2010 at 6:55 PM, Tony Finch wrote: > On 8 Oct 2010, at 20:32, "Richard L. Barnes" wrote: > > > > Certainly agree that putting CA certs in the DNS could be a useful > approach. It's not the same as a "do not issue" warning. > > Phill's proposal said that clients could check the server's cert chain > against the list of allowed CAs in the DNS. The CA issuing rules help for > old clients, and provide defence in depth. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > -- Website: http://hallambaker.com/ --001485f199f0ce35d704924ed140 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One scheme can certainly do both.

But changing CA practi= ces when there is a dramatic and immediate advantage to the CA is much easi= er than working out 'fire and forget' rules for client side process= ing and getting them agreed amongst the various IETF groups affected.


I tend to think that the proper procedur= e on this concept would be to have the IETF assign the RR code but hand as = much work as possible on the practices side to the CABForum where there are= lawyers who like writing rules for that sort of thing.

I certainly want to do client side rules. But realistically we onl= y get one chance to do those right.



On Sun, Oct 10, 2010 at 6:55 PM, Tony Finch= <dot@dotat.at>= wrote:
On 8 Oct 2010, at 20:32, = "Richard L. Barnes" <rbarne= s@bbn.com> wrote:
>
> Certainly agree that putting CA certs in the DNS could be a useful app= roach. =A0It's not the same as a "do not issue" warning.

Phill's proposal said that clients could check the server's c= ert chain against the list of allowed CAs in the DNS. The CA issuing rules = help for old clients, and provide defence in depth.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/



--
Website: http://hallambaker.com/

--001485f199f0ce35d704924ed140-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEBF3A6876 for ; Sun, 10 Oct 2010 15:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8E9zaVbIu5o for ; Sun, 10 Oct 2010 15:54:34 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by core3.amsl.com (Postfix) with ESMTP id A98273A686E for ; Sun, 10 Oct 2010 15:54:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [87.115.122.141] (port=51805 helo=[192.168.1.5]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1P54nr-0004sy-FO (Exim 4.72) (return-path ); Sun, 10 Oct 2010 23:55:39 +0100 References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <457BA40A-C5AE-4585-ADC9-84A0DC2ED478@dotat.at> X-Mailer: iPhone Mail (8B117) From: Tony Finch Date: Sun, 10 Oct 2010 23:55:13 +0100 To: "Richard L. Barnes" Sender: Tony Finch Cc: "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 22:54:35 -0000 On 8 Oct 2010, at 20:32, "Richard L. Barnes" wrote: >=20 > Certainly agree that putting CA certs in the DNS could be a useful approac= h. It's not the same as a "do not issue" warning. Phill's proposal said that clients could check the server's cert chain again= st the list of allowed CAs in the DNS. The CA issuing rules help for old cli= ents, and provide defence in depth. Tony. -- f.anthony.n.finch http://dotat.at/= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAEF3A698F for ; Fri, 8 Oct 2010 18:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf8L2h3F9Jtz for ; Fri, 8 Oct 2010 18:27:47 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 918C93A63C9 for ; Fri, 8 Oct 2010 18:27:47 -0700 (PDT) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id C51D4C3AA for ; Fri, 8 Oct 2010 21:28:50 -0400 (EDT) Date: Fri, 8 Oct 2010 21:28:50 -0400 (EDT) From: Paul Wouters To: "keyassure@ietf.org" In-Reply-To: <32175560.1286574817952.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Message-ID: References: <32175560.1286574817952.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2010 01:27:48 -0000 On Fri, 8 Oct 2010, Jeffrey A. Williams wrote: [Way behind on the list, possible more in-depth message following...] The goals of the charter seem good in their goals to allow DNSSEC and CA based authentication systems to coexist. This is very important. Try to limit the interaction required for either system so that they work as independantly as possible, without demanding or forbidding each other's use. Where interaction occurs, try to limit data overlap or data duplication as much as possible - this points specifically to SSL/TLS. I should be able to configure my browser with a preference of auth scheme. One over the other, or both as a minimum. Bonus points if two machines can do this when connecting offline (eg bluetooth) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321F73A6974 for ; Fri, 8 Oct 2010 14:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.924, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWHQ0qPm1mnL for ; Fri, 8 Oct 2010 14:52:37 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 9A27F3A6972 for ; Fri, 8 Oct 2010 14:52:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=deKj6PDdbJcD6wzQXZEqaEe7kcfSwE2umx9WtZyJBihXPGIarRrjDnImPHhap8zd; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.25] (helo=mswamui-backed.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P4Ksj-0000dV-Ud; Fri, 08 Oct 2010 17:53:37 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 8 Oct 2010 17:53:37 -0400 Message-ID: <32175560.1286574817952.JavaMail.root@mswamui-backed.atl.sa.earthlink.net> Date: Fri, 8 Oct 2010 16:53:37 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Ilari Liusvaara , "Richard L. Barnes" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688865a444bfafba5667a8490af87a3823e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.25 Cc: Tony Finch , "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 21:52:39 -0000 Ilari and all, -----Original Message----- >From: Ilari Liusvaara >Sent: Oct 8, 2010 4:20 PM >To: "Richard L. Barnes" >Cc: Tony Finch , Phillip Hallam-Baker , "keyassure@ietf.org" >Subject: Re: [keyassure] Charter sent to ADs > >On Fri, Oct 08, 2010 at 03:32:06PM -0400, Richard L. Barnes wrote: >> > >> >The two are not mutually incompatible. The authorized CA >> >identified in the DNS can be a private CA (which also deals with >> >the many-certs problem that Phill identified) and in the simplest >> >case it should also be possible to identify the server's cert >> >directly. >> >> Certainly agree that putting CA certs in the DNS could be a useful >> approach. It's not the same as a "do not issue" warning. > >Furthermore, bad enough CAs could just ignore the "do not issue" >warnings (for instance if coerced). > >Here's (another) way to do that: > >TLSCFP (Transport Layer Security Chaining FingerPrint) record. > >These come to play if no matching TLSFP record (eithe direct or >indirect via TLSRQ) is found but usable TLSCFP records are present. > >The client will then collect all available (local store and server- >sent) certificates that match fingerprints in TLSCFP records and >runs normal PKI validation with collected certificates notionally >declared to be trust anchors. This assumes that the Trust anchor(s) are trustworthy at the time of this check. > >If this check passes, the key is OK from DNS key checking POV. The >client may or may not trust it at this point (depending on client >local policy). Right. But if the policy is bad at the time given the trustworthyness of the Trust Anchor(s) relied upon. Such may not be the case. > >If this check fails, the whole DNS key checking fails and client >SHOULD NOT trust the certificate. Right again. However seems to me anyway that this possibility is minimized by the questionable assumption that at least one Trust Anchor used for validation is not compermized. A reasonably good assumption depending on the before mentioned policy, but not necessarly an accurate assumption. > > >The reason for excluding certs that match TLSFPs is that one can't >attack those using bad-CA attacks anyway (since that certificate >can't be used without server key, legimate server sends good >certificate chains and compromising the key would compromise >everything anyway). Yes but only if the server key is ligitimate or valid which is not necessarly an assumption that can be made. > >-Ilari >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1133A6960 for ; Fri, 8 Oct 2010 14:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjFj2VJ+iLx0 for ; Fri, 8 Oct 2010 14:13:18 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id 38E6E3A695D for ; Fri, 8 Oct 2010 14:13:18 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id 88AB813CA8F; Sat, 9 Oct 2010 00:14:22 +0300 (EEST) Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A042807C799; Sat, 09 Oct 2010 00:14:22 +0300 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id A6FEB1C6385; Sat, 9 Oct 2010 00:14:17 +0300 (EEST) Date: Sat, 9 Oct 2010 00:20:32 +0300 From: Ilari Liusvaara To: "Richard L. Barnes" Message-ID: <20101008212032.GA7809@LK-Perkele-V2.elisa-laajakaista.fi> References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Tony Finch , Phillip Hallam-Baker , "keyassure@ietf.org" Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 21:13:20 -0000 On Fri, Oct 08, 2010 at 03:32:06PM -0400, Richard L. Barnes wrote: > > > >The two are not mutually incompatible. The authorized CA > >identified in the DNS can be a private CA (which also deals with > >the many-certs problem that Phill identified) and in the simplest > >case it should also be possible to identify the server's cert > >directly. > > Certainly agree that putting CA certs in the DNS could be a useful > approach. It's not the same as a "do not issue" warning. Furthermore, bad enough CAs could just ignore the "do not issue" warnings (for instance if coerced). Here's (another) way to do that: TLSCFP (Transport Layer Security Chaining FingerPrint) record. These come to play if no matching TLSFP record (eithe direct or indirect via TLSRQ) is found but usable TLSCFP records are present. The client will then collect all available (local store and server- sent) certificates that match fingerprints in TLSCFP records and runs normal PKI validation with collected certificates notionally declared to be trust anchors. If this check passes, the key is OK from DNS key checking POV. The client may or may not trust it at this point (depending on client local policy). If this check fails, the whole DNS key checking fails and client SHOULD NOT trust the certificate. The reason for excluding certs that match TLSFPs is that one can't attack those using bad-CA attacks anyway (since that certificate can't be used without server key, legimate server sends good certificate chains and compromising the key would compromise everything anyway). -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F85C3A693E for ; Fri, 8 Oct 2010 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AthcFRQ35A3Y for ; Fri, 8 Oct 2010 12:31:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A6DAA3A6828 for ; Fri, 8 Oct 2010 12:31:01 -0700 (PDT) Received: from ros-dhcp192-1-51-62.bbn.com ([192.1.51.62]:62966) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P4Ifm-00096Y-U1; Fri, 08 Oct 2010 15:32:07 -0400 Message-Id: From: "Richard L. Barnes" To: Tony Finch In-Reply-To: <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> Content-Type: multipart/alternative; boundary=Apple-Mail-18--978518882 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 8 Oct 2010 15:32:06 -0400 References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> X-Mailer: Apple Mail (2.936) Cc: "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:31:05 -0000 --Apple-Mail-18--978518882 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit >>> Whether or not this group wishes to be a part of the 'do not >>> issue' approach, it is a simpler approach and one that offers >>> benefits to both CAs and to the users of legacy browsers and >>> browsers that choose not to deploy an enumeration based >>> restriction scheme. And while it can make use of DNSSEC, it is not >>> dependent on DNSSEC deployment. >> >> The "do not issue" approach is entirely orthogonal to the point of >> this group. It assumes that commercial CAs are still the entities >> asserting the name-key binding. >> >> The point of this group is to enable the assertion of name-key >> bindings using DNSSEC, so that the domain owner, rather than an >> external CA, is the entity asserting the binding. > > The two are not mutually incompatible. The authorized CA identified > in the DNS can be a private CA (which also deals with the many-certs > problem that Phill identified) and in the simplest case it should > also be possible to identify the server's cert directly. Certainly agree that putting CA certs in the DNS could be a useful approach. It's not the same as a "do not issue" warning. --Richard --Apple-Mail-18--978518882 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Whether or not this = group wishes to be a part of the 'do not issue' approach, it is a = simpler approach and one that offers benefits to both CAs and to the = users of legacy browsers and browsers that choose not to deploy an = enumeration based restriction scheme. And while it can make use of = DNSSEC, it is not dependent on DNSSEC = deployment.

The "do not = issue" approach is entirely orthogonal to the point of this group. =  It assumes that commercial CAs are still the entities asserting = the name-key binding.

The point of this = group is to enable the assertion of name-key bindings using DNSSEC, so = that the domain owner, rather than an external CA, is the entity = asserting the binding.

The two are not mutually incompatible. The authorized = CA identified in the DNS can be a private CA (which also deals with the = many-certs problem that Phill identified) and in the simplest case it = should also be possible to identify the server's cert = directly.

Certainly agree = that putting CA certs in the DNS could be a useful approach.  It's = not the same as a "do not issue" = warning.

--Richard


= --Apple-Mail-18--978518882-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D923A6928 for ; Fri, 8 Oct 2010 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi+N3voqsmRZ for ; Fri, 8 Oct 2010 11:41:24 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by core3.amsl.com (Postfix) with ESMTP id 60DDB3A68F1 for ; Fri, 8 Oct 2010 11:41:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [82.132.248.219] (port=16944 helo=[10.135.252.202]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1P4Htf-0003L9-R5 (Exim 4.72) (return-path ); Fri, 08 Oct 2010 19:42:27 +0100 References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> In-Reply-To: <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--981524117 Message-Id: <74112D26-5B93-425C-B4D2-8B5DD357246B@dotat.at> X-Mailer: iPhone Mail (8B117) From: Tony Finch Date: Fri, 8 Oct 2010 19:41:47 +0100 To: "Richard L. Barnes" Sender: Tony Finch Cc: "keyassure@ietf.org" , Phillip Hallam-Baker Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 18:41:26 -0000 --Apple-Mail-1--981524117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Oct 2010, at 18:07, "Richard L. Barnes" wrote: >> Whether or not this group wishes to be a part of the 'do not issue' appro= ach, it is a simpler approach and one that offers benefits to both CAs and t= o the users of legacy browsers and browsers that choose not to deploy an enu= meration based restriction scheme. And while it can make use of DNSSEC, it i= s not dependent on DNSSEC deployment. >=20 > The "do not issue" approach is entirely orthogonal to the point of this gr= oup. It assumes that commercial CAs are still the entities asserting the na= me-key binding. >=20 > The point of this group is to enable the assertion of name-key bindings us= ing DNSSEC, so that the domain owner, rather than an external CA, is the ent= ity asserting the binding. The two are not mutually incompatible. The authorized CA identified in the D= NS can be a private CA (which also deals with the many-certs problem that Ph= ill identified) and in the simplest case it should also be possible to ident= ify the server's cert directly. Tony. -- f.anthony.n.finch http://dotat.at/= --Apple-Mail-1--981524117 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Oct 2010, at 18:07, "Richard L. Barne= s" <rbarnes@bbn.com> wrote:

Whether or not this group wishes to be a part of t= he 'do not issue' approach, it is a simpler approach and one that offers ben= efits to both CAs and to the users of legacy browsers and browsers that choo= se not to deploy an enumeration based restriction scheme. And while it can m= ake use of DNSSEC, it is not dependent on DNSSEC deployment.

The "do not issue" approach is entirely ortho= gonal to the point of this group.  It assumes that commercial CAs are s= till the entities asserting the name-key binding.
The point of this group is to enable the assertion of name-key bindin= gs using DNSSEC, so that the domain owner, rather than an external CA, is th= e entity asserting the binding.
<= /font>

The two are not mutually incompatible. The autho= rized CA identified in the DNS can be a private CA (which also deals with th= e many-certs problem that Phill identified) and in the simplest case it shou= ld also be possible to identify the server's cert directly.
<= span class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-color: rgba(2= 6, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.= 230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">
Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
= --Apple-Mail-1--981524117-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE8A3A6923 for ; Fri, 8 Oct 2010 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMZdwjrU271r for ; Fri, 8 Oct 2010 10:06:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 90B4D3A68C1 for ; Fri, 8 Oct 2010 10:06:27 -0700 (PDT) Received: from ros-dhcp192-1-51-62.bbn.com ([192.1.51.62]:61171) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P4GPs-0006xE-C0; Fri, 08 Oct 2010 13:07:32 -0400 Message-Id: <95FE581B-EE99-4DC9-AFC0-9A707FF64E76@bbn.com> From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 8 Oct 2010 13:07:31 -0400 References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 17:06:28 -0000 > Whether or not this group wishes to be a part of the 'do not issue' > approach, it is a simpler approach and one that offers benefits to > both CAs and to the users of legacy browsers and browsers that > choose not to deploy an enumeration based restriction scheme. And > while it can make use of DNSSEC, it is not dependent on DNSSEC > deployment. The "do not issue" approach is entirely orthogonal to the point of this group. It assumes that commercial CAs are still the entities asserting the name-key binding. The point of this group is to enable the assertion of name-key bindings using DNSSEC, so that the domain owner, rather than an external CA, is the entity asserting the binding. As a side note, objective (2) as you've phrased it is non-sensical. Domain owners cannot prevent clients from accepting any certificate. The only thing a domain owner can do is make assertions about what their servers will do, which the client can use to make validation decisions. Discussion to date has focused on positive assertions like "My servers will use this key:...", but one could imagine negative assertions as well, of the character "My servers will not use any other keys." As I read it, the current charter allows both of these. (And whoever you talked to off-list, I'm imagining that's more like what they had in mind than a "do-not-issue" approach.) --Richard Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9379B3A68B0 for ; Fri, 8 Oct 2010 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyxpIsGvfiyv for ; Fri, 8 Oct 2010 09:52:22 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8ED323A6887 for ; Fri, 8 Oct 2010 09:52:21 -0700 (PDT) Received: by wyi11 with SMTP id 11so1501720wyi.31 for ; Fri, 08 Oct 2010 09:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1VBRwZF+B7tUpJ2l63TBhdQLfxfPkhx+LfXDY7SHQoc=; b=wJxvFovUMXg24TgHXNEBVfacTm/2QL8cjG3F96ihFvILlNTpEFq3YNeDKed7PxDXX8 bOmxZly0lvp1mUWnUcbCGkPjeNcDq99OzAx0YGRPopu5miWz1sRX24qI3FehYK/9j6/7 jLbzBNdzP1/k+b2d5+gQlmni+CII9TdaEFUHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HOIFxfOodqUn/4S4IWIKMP++UHQHeZJGve/K86t9F43Ajx5QR5xV2+jF2h/n+TiQHQ X9WWL+8gdKDV8iiV3IdYXOMmzsyq5pjM8fQ8J3R45r0qgI5AoNGyfy9U0TriM8WODH5j fHxt5n8MN9NRT3ukuw0Wvkir26Dh/wm1OTZDE= MIME-Version: 1.0 Received: by 10.216.157.81 with SMTP id n59mr2498254wek.84.1286556804750; Fri, 08 Oct 2010 09:53:24 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 8 Oct 2010 09:53:24 -0700 (PDT) In-Reply-To: References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> Date: Fri, 8 Oct 2010 12:53:24 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=0016e65a022254af3804921dd975 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:52:23 -0000 --0016e65a022254af3804921dd975 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 8, 2010 at 11:58 AM, Richard L. Barnes wrote: > So far the group has only discussed one mechanism that is designed to >> constrain key validity after issue. But that is not the only option, a much >> more powerful and lower impact approach is to provide mechanisms that enable >> domain name owners to avoid mis-issue. >> > > ... > > > As far as work schedules go, I think it is realistic to have a draft ready >> for IESG review that describes a mechanism for key validation and for >> publishing 'do not issue' advice to CAs by March. >> > > I do not understand what you mean by "avoid mis-issue" or "publishing 'do > not issue' advice to CAs". Those phrases doesn't sound like any problem > that had been discussed previously on this list. Which is a real problem because that is exactly what the code we are discussing is designed to prevent. And I am not at all surprised that you were unaware that this was an objective as it is not something that I would have expected to be an objective either and have only discovered gradually. Let us rewind back to the Black Hat 2010 conference. At BH, Dan Kaminsky presented a paper where he identified the lack of standards for issuing DV certificates as a problem and suggested an alternative scheme based on DNSSEC which would have two purposes: 1) Enable a domain name owner to validate keys at the DV level 2) Enable a domain name owner to prevent clients that support the proposed mechanism from trusting certificates that they did not authorize. I did not attend BH this year and so when I saw the group formed I assumed that the only requirement it was intended to address was the first one. This week I have spoken to or otherwise communicated to several of the draft authors offlist. I have confirmed with them that the purpose of enabling a domain name owner to prevent use of the certificates is indeed one of their principal objectives. Now if you want to rule the second purpose out of the charter, that is fine with me. But the fact remains that the technical complexity of putting any form of restriction in the client is vastly greater than the complexity of a mandate that is imposed on the issuing CAs. Whether or not this group wishes to be a part of the 'do not issue' approach, it is a simpler approach and one that offers benefits to both CAs and to the users of legacy browsers and browsers that choose not to deploy an enumeration based restriction scheme. And while it can make use of DNSSEC, it is not dependent on DNSSEC deployment. I would see the forum for addressing do-not-issue to be CABForum more than IETF. The reason it is relevant here is because it bears on the same original requirement and may well pre-empt it to an extent. It is not possible to use the enumeration approach as the basis of do-not-issue for obvious reasons (can't take the hash of a cert before it is issued). So there is going to be do-not-issue information in the DNS that can potentially be applied to solve this problem equally well and with a far lower maintenance requirement than this particular scheme. -- Website: http://hallambaker.com/ --0016e65a022254af3804921dd975 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 8, 2010 at 11:58 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
<= div class=3D"gmail_quote">
So far the group has only discussed one mechanism that is designed to const= rain key validity after issue. But that is not the only option, a much more= powerful and lower impact approach is to provide mechanisms that enable do= main name owners to avoid mis-issue.

=A0...


As far as work schedules go, I think it is realistic to have a draft ready = for IESG review that describes a mechanism for key validation and for publi= shing 'do not issue' advice to CAs by March.

I do not understand what you mean by "avoid mis-issue" or "p= ublishing 'do not issue' advice to CAs". =A0Those phrases does= n't sound like any problem that had been discussed previously on this l= ist.

Which is a real problem because that is exactly what th= e code we are discussing is designed to prevent.

A= nd I am not at all surprised that you were unaware that this was an objecti= ve as it is not something that I would have expected to be an objective eit= her and have only discovered gradually.=A0

Let us rewind back to the Black Hat 2010 conference.


At BH, Dan Kaminsky presented a paper= where he identified the lack of standards for issuing DV certificates as a= problem and suggested an alternative scheme based on DNSSEC which would ha= ve two purposes:

1) Enable a domain name owner to validate keys at the D= V level
2) Enable a domain name owner to prevent clients that sup= port the proposed mechanism from trusting certificates that they did not au= thorize.


I did not attend BH this year and so whe= n I saw the group formed I assumed that the only requirement it was intende= d to address was the first one.=A0

This week I hav= e spoken to or otherwise communicated to several of the draft authors offli= st. I have confirmed with them that the purpose of enabling a domain name o= wner to prevent use of the certificates is indeed one of their principal ob= jectives.


Now if you want to rule the second purpo= se out of the charter, that is fine with me. But the fact remains that the = technical complexity of putting any form of restriction in the client is va= stly greater than the complexity of a mandate that is imposed on the issuin= g CAs.

Whether or not this group wishes to be a part of the &#= 39;do not issue' approach, it is a simpler approach and one that offers= benefits to both CAs and to the users of legacy browsers and browsers that= choose not to deploy an enumeration based restriction scheme. And while it= can make use of DNSSEC, it is not dependent on DNSSEC deployment.

I would see the forum for addressing do-not-issue to be= CABForum more than IETF.

The reason it is relevan= t here is because it bears on the same original requirement and may well pr= e-empt it to an extent. It is not possible to use the enumeration approach = as the basis of do-not-issue for obvious reasons (can't take the hash o= f a cert before it is issued).

So there is going to be do-not-issue information in the= DNS that can potentially be applied to solve this problem equally well and= with a far lower maintenance requirement than this particular scheme.=A0

--
Website: http://hallam= baker.com/

--0016e65a022254af3804921dd975-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900BE3A6921 for ; Fri, 8 Oct 2010 09:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.869 X-Spam-Level: X-Spam-Status: No, score=-105.869 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+V74eiV+MhM for ; Fri, 8 Oct 2010 09:32:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2C6843A6890 for ; Fri, 8 Oct 2010 09:32:43 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id o98GXlqb015594 for ; Fri, 8 Oct 2010 09:33:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286555627; bh=GWL028BzA4XIRF/e2wYRwv/41f8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=inshmr8adgvkR1gaXsVXlfHvmDf2JWf3G79WzGEphgR/DSV6aDKnlQcDSfXjTTnpG 3SwTYC1j4fPAqUOgWOTuA== Received: from fxm7 (fxm7.prod.google.com [10.184.13.7]) by wpaz21.hot.corp.google.com with ESMTP id o98GXkKj027921 for ; Fri, 8 Oct 2010 09:33:46 -0700 Received: by fxm7 with SMTP id 7so735179fxm.30 for ; Fri, 08 Oct 2010 09:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VxQybowLcl5sr+mPi6hIpzCceYvIHYVkoFmRh0e9ZKU=; b=G6J0TnRX+32Zkd8e2VwaFdXq/qvoXdAzjl94QMS96iTK6m7blkxIZJFV7UMFrYm5GQ 7Vz10LewIlRmTPyl51eA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=laF4ZCxlvqT1l/8j1LHLfS2bjMrmD1UbQF59RgZyYNhL/seNgtK4vkJn9Nccxhhwwa A62Y5P2EcNme7gi6XqFA== MIME-Version: 1.0 Received: by 10.239.155.74 with SMTP id h10mr192452hbc.30.1286555625046; Fri, 08 Oct 2010 09:33:45 -0700 (PDT) Received: by 10.220.60.134 with HTTP; Fri, 8 Oct 2010 09:33:44 -0700 (PDT) In-Reply-To: References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> Date: Fri, 8 Oct 2010 17:33:44 +0100 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:32:51 -0000 On 8 October 2010 17:19, Paul Hoffman wrote: > At 11:58 AM -0400 10/8/10, Richard L. Barnes wrote: >>>So far the group has only discussed one mechanism that is designed to co= nstrain key validity after issue. But that is not the only option, a much m= ore powerful and lower impact approach is to provide mechanisms that enable= domain name owners to avoid mis-issue. >> >> ... >> >>>As far as work schedules go, I think it is realistic to have a draft rea= dy for IESG review that describes a mechanism for key validation and for pu= blishing 'do not issue' advice to CAs by March. >> >>I do not understand what you mean by "avoid mis-issue" or "publishing 'do= not issue' advice to CAs". =A0Those phrases doesn't sound like any problem= that had been discussed previously on this list. > > +1. These sound like topics for a different proposed Working Group, not o= ne focused on associating a key with a host name. Agreed. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D813A6892 for ; Fri, 8 Oct 2010 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.44 X-Spam-Level: X-Spam-Status: No, score=-100.44 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwZCsI78gSiC for ; Fri, 8 Oct 2010 09:18:31 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9A1583A686B for ; Fri, 8 Oct 2010 09:18:31 -0700 (PDT) Received: from [192.168.0.4] ([68.170.72.67]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o98GJZiR009158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Oct 2010 09:19:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> Date: Fri, 8 Oct 2010 09:19:29 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 16:18:32 -0000 At 11:58 AM -0400 10/8/10, Richard L. Barnes wrote: >>So far the group has only discussed one mechanism that is designed to constrain key validity after issue. But that is not the only option, a much more powerful and lower impact approach is to provide mechanisms that enable domain name owners to avoid mis-issue. > > ... > >>As far as work schedules go, I think it is realistic to have a draft ready for IESG review that describes a mechanism for key validation and for publishing 'do not issue' advice to CAs by March. > >I do not understand what you mean by "avoid mis-issue" or "publishing 'do not issue' advice to CAs". Those phrases doesn't sound like any problem that had been discussed previously on this list. +1. These sound like topics for a different proposed Working Group, not one focused on associating a key with a host name. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BB23A68AB for ; Fri, 8 Oct 2010 08:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSEK+WmySVeR for ; Fri, 8 Oct 2010 08:56:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A06B13A68CB for ; Fri, 8 Oct 2010 08:56:56 -0700 (PDT) Received: from ros-dhcp192-1-51-62.bbn.com ([192.1.51.62]:60483) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P4FKb-0008DG-JS; Fri, 08 Oct 2010 11:58:01 -0400 Message-Id: From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 8 Oct 2010 11:58:00 -0400 References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:56:57 -0000 > So far the group has only discussed one mechanism that is designed > to constrain key validity after issue. But that is not the only > option, a much more powerful and lower impact approach is to provide > mechanisms that enable domain name owners to avoid mis-issue. ... > As far as work schedules go, I think it is realistic to have a draft > ready for IESG review that describes a mechanism for key validation > and for publishing 'do not issue' advice to CAs by March. I do not understand what you mean by "avoid mis-issue" or "publishing 'do not issue' advice to CAs". Those phrases doesn't sound like any problem that had been discussed previously on this list. --Richard Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218203A68D7 for ; Fri, 8 Oct 2010 07:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSXvmXj+najP for ; Fri, 8 Oct 2010 07:25:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 204DC3A68CC for ; Fri, 8 Oct 2010 07:25:27 -0700 (PDT) Received: by wwj40 with SMTP id 40so861112wwj.13 for ; Fri, 08 Oct 2010 07:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qOyx4Fx1BXBPagXKH03uBbo6ORgdQ5c9bQrCVR+cRCM=; b=ayaPsSLF0GZYkJR4VSubFiLQoQKEqKFJxQFZAfB9Bd/rnf3rMAJJ5eyTUvUZOWhf2O 7jEC5Ki5QkUayij8DxDeQgCGWCJewj39m4EuZuxnreareH65+qggGkt3R69c+r8vjGUg BoEayWLk0rc6m3bIknIY8n93LOu7fPi80xTGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GatMJxMUTuyExCmjM0c1grOhKLOF30KNRUTncuY/qVIzBL71kLSKUATP9WkaU2n8RZ fF5YK61R9D7RXT56Bxhe89MunwwPL8fhwISxd1JXkllBHT0D7bjYs7harKvfM1NcVLac fiGe+ggLdStBXum+ak6a2+24JnqoWLWGwZMAU= MIME-Version: 1.0 Received: by 10.216.1.208 with SMTP id 58mr2336328wed.22.1286547977981; Fri, 08 Oct 2010 07:26:17 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 8 Oct 2010 07:26:17 -0700 (PDT) In-Reply-To: <4CAED310.9060006@nic.cz> References: <4CAC9146.80609@nic.cz> <4CAED310.9060006@nic.cz> Date: Fri, 8 Oct 2010 10:26:17 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=00163683302a36d07204921bcbc8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 14:25:31 -0000 --00163683302a36d07204921bcbc8 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable As I pointed out to Ondrej offlist, A WG meeting has a minimum notice period that is constrained by legal considerations, visa issue requirements and a whole host of travel planning issues. If the group is chartered before Beijing it cannot have a BOF and it cannot have a WG meeting either. So sending the charter to the ADs in advance of the meeting is probably a mistake. The BOF is an opportunity to advertise the work to the wider IETF community= . It is your single best advertising and marketing opportunity. The charter milestones are completely unrealistic. Time and again I see WG charters propose unrealistic milestones that are then used to constrain the discussion on the basis that there is no time to consider other options. The result is inevitably that the WG takes far longer than it would have done had the milestones been realistic. We can come to agreement almost immediately on a proposal to use the DNS to validate keys. The tricky part is how to use DNS to constrain key validity. So far the group has only discussed one mechanism that is designed to constrain key validity after issue. But that is not the only option, a much more powerful and lower impact approach is to provide mechanisms that enabl= e domain name owners to avoid mis-issue. There is really no need or point to scheduling milestones for submission of initial drafts. The charter states that there are input drafts, that is enough. As far as work schedules go, I think it is realistic to have a draft ready for IESG review that describes a mechanism for key validation and for publishing 'do not issue' advice to CAs by March. Describing a mechanism fo= r client side enforcement is a lot more involved and necessitates consideration of lots of application details. So November 2011 is optimistic. The Shepherding process for turning drafts into standards always takes much longer than everyone expects, even people who have done something before. Rushing a proposal through a WG only makes the process take a lot longer with much less control. Issues that could have been disposed of quickly en= d up taking much longer as the IESG raises them and takes much longer to dispose of them because they are overloaded. On Fri, Oct 8, 2010 at 4:15 AM, Ond=F8ej Sur=FD wrote: > On 6.10.2010 17:09, Ond=F8ej Sur=FD wrote: > >> Hi all, >> >> since the proposed charter is quite stable for a last week or so >> with small exceptions of small nits, we (me and Warren) believed that >> the charter is good to go and that we have a rough consensus on the >> charter, and so we asked our fellow ADs to process it accordingly to >> IETF processes, ie. take it to the IESG. >> >> With some luck that could mean that we can make it to be WG in the >> time of Beijing meeting. >> >> I would like to thank all the contributors to the charter, so thank >> you all. >> >> Regards, Ondrej >> > > Bill has asked me to post a charter as sent to ADs: > > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure > > Here's verbatim copy of that page for an evidence: > > Objective: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed through the DNS for discovering and authenticating public > keys which are associated with a service located at a domain name. > > Problem Statement: > Entities on the Internet are usually identified using domain names and > forming a cryptographically secured connection to the entity requires > the entity to authenticate its name. For instance, in HTTPS, a server > responding to a query for is expected to > authenticate as "www.example.com". Security protocols such as TLS and > IPsec accomplish this authentication by allowing an endpoint to prove > ownership of a private key whose corresponding public key is somehow > bound to the name being authenticated. As a pre-requisite for > authentication, then, these protocols require a mechanism for bindings > to be asserted between public keys and domain names. > > DNSSEC provides a mechanism for a domain operator to sign DNS > information directly, using keys that are bound to the domain by the > parent domain; relying parties can continue this chain up to any trust > anchor that they accept. In this way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate the > DNS. In addition, this technique inherently limits the scope of any > given entity to the names in zones he controls. > > This working group will develop mechanisms for domain operators to > present bindings between names within their control and public keys, in > such a way that these bindings can be integrity-protected (and thus > shown to be authentically from the domain operator) using DNSSEC and > used as a basis for authentication in protocols that use domain names as > identifiers. Possible starting points for these deliverables include > draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and > draft-josefsson-keyassure-tls. > > The mechanisms developed by this group will address bindings between > domain names and keys, allowing flexibility for all key-transport > mechanisms supported by the application protocols addressed (e.g., both > self-signed and CA-issued certificates for use in TLS). > > The group may also create documents that describe how protocol entities > can discover and validate these bindings in the execution of specific > applications. This work would be done in coordination with the IETF > Working Groups responsible for the protocols. > > Milestones: > Nov 2010 First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > Jan 2011 First WG draft of standards-track protocols for using DNS to > associate hosts with IPsec > Jun 2011 Protocol for using DNS to associate domain names with keys > for TLS and DTLS to IESG > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG > Aug 2011 Recharter > > O. > > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ --00163683302a36d07204921bcbc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As I pointed out to Ondrej offlist,

A WG meeting has a m= inimum notice period that is constrained by legal considerations, visa issu= e requirements and a whole host of travel planning issues.

If the group is chartered before Beijing it cannot have a BOF an= d it cannot have a WG meeting either.

So sending t= he charter to the ADs in advance of the meeting is probably a mistake.

The BOF is an opportunity to advertise the work to the = wider IETF community. It is your single best advertising and marketing oppo= rtunity.


The charter milestones are= completely unrealistic.=C2=A0

Time and again I see WG charters propose unrealistic mi= lestones that are then used to constrain the discussion on the basis that t= here is no time to consider other options.

The res= ult is inevitably that the WG takes far longer than it would have done had = the milestones been realistic.


We can come to agreement almost immediat= ely on a proposal to use the DNS to validate keys. The tricky part is how t= o use DNS to constrain key validity.

So far the gr= oup has only discussed one mechanism that is designed to constrain key vali= dity after issue. But that is not the only option, a much more powerful and= lower impact approach is to provide mechanisms that enable domain name own= ers to avoid mis-issue.

There is really no need or point to scheduling mileston= es for submission of initial drafts. The charter states that there are inpu= t drafts, that is enough.

As far as work schedules= go, I think it is realistic to have a draft ready for IESG review that des= cribes a mechanism for key validation and for publishing 'do not issue&= #39; advice to CAs by March. Describing a mechanism for client side enforce= ment is a lot more involved and necessitates consideration of lots of appli= cation details. So November 2011 is optimistic.

The Shepherding process for turning drafts into standar= ds always takes much longer than everyone expects, even people who have don= e something before.

Rushing a proposal through a W= G only makes the process take a lot longer with much less control. =C2=A0Is= sues that could have been disposed of quickly end up taking much longer as = the IESG raises them and takes much longer to dispose of them because they = are overloaded.


On Fri, Oct 8, 2010 at 4:15 AM, Ond= =C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
On 6.10.2010 17:09, Ond=C5=99ej Sur=C3=BD wrote:
Hi all,

since the proposed charter is quite stable for a last week or so
with small exceptions of small nits, we (me and Warren) believed that
the charter is good to go and that we have a rough consensus on the
charter, and so we asked our fellow ADs to process it accordingly to
IETF processes, ie. take it to the IESG.

With some luck that could mean that we can make it to be WG in the
time of Beijing meeting.

I would like to thank all the contributors to the charter, so thank
you all.

Regards, Ondrej

Bill has asked me to post a charter as sent to ADs:

http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure

Here's verbatim copy of that page for an evidence:

Objective:
Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through the DNS for discovering and authenticating public
keys which are associated with a service located at a domain name.

Problem Statement:
Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for <https://www.example.com> is expected to
authenticate as "= www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.

DNSSEC provides a mechanism for a domain operator to sign DNS
information directly, using keys that are bound to the domain by the
parent domain; relying parties can continue this chain up to any trust
anchor that they accept. In this way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate the
DNS. In addition, this technique inherently limits the scope of any
given entity to the names in zones he controls.

This working group will develop mechanisms for domain operators to
present bindings between names within their control and public keys, in
such a way that these bindings can be integrity-protected (and thus
shown to be authentically from the domain operator) using DNSSEC and
used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

The mechanisms developed by this group will address bindings between
domain names and keys, allowing flexibility for all key-transport
mechanisms supported by the application protocols addressed (e.g., both
self-signed and CA-issued certificates for use in TLS).

The group may also create documents that describe how protocol entities
can discover and validate these bindings in the execution of specific
applications. This work would be done in coordination with the IETF
Working Groups responsible for the protocols.

Milestones:
Nov 2010 =C2=A0 First WG draft of standards-track protocol for using DNS to=
associate hosts with keys for TLS and DTLS
Jan 2011 =C2=A0 First WG draft of standards-track protocols for using DNS t= o
associate hosts with IPsec
Jun 2011 =C2=A0 Protocol for using DNS to associate domain names with keys<= br> for TLS and DTLS to IESG
Aug 2011 =C2=A0 Protocols for using DNS to associate domain names with keys=
for IPsec to IESG
Aug 2011 =C2=A0 Recharter

O.

--
=C2=A0Ond=C5=99ej Sur=C3=BD
=C2=A0vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
=C2=A0-------------------------------------------
=C2=A0CZ.NIC, z.s.p.o. =C2=A0 =C2=A0-- =C2=A0 =C2=A0Laborato=C5=99e CZ.NIC<= br> =C2=A0Americka 23, 120 00 Praha 2, Czech Republic
=C2=A0mailto:ondrej= .sury@nic.cz =C2=A0 =C2=A0= http://nic.cz/
=C2=A0tel:+420.222745110 =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112
=C2=A0-------------------------------------------
_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



--
Website: http://hallambaker.com/

--00163683302a36d07204921bcbc8-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4328E3A683C for ; Fri, 8 Oct 2010 01:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC845pALQd8U for ; Fri, 8 Oct 2010 01:14:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id E50063A6828 for ; Fri, 8 Oct 2010 01:14:08 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 6925F7343ED for ; Fri, 8 Oct 2010 10:15:12 +0200 (CEST) Message-ID: <4CAED310.9060006@nic.cz> Date: Fri, 08 Oct 2010 10:15:12 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: keyassure@ietf.org References: <4CAC9146.80609@nic.cz> In-Reply-To: <4CAC9146.80609@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 08:14:18 -0000 On 6.10.2010 17:09, Ondřej Surý wrote: > Hi all, > > since the proposed charter is quite stable for a last week or so > with small exceptions of small nits, we (me and Warren) believed that > the charter is good to go and that we have a rough consensus on the > charter, and so we asked our fellow ADs to process it accordingly to > IETF processes, ie. take it to the IESG. > > With some luck that could mean that we can make it to be WG in the > time of Beijing meeting. > > I would like to thank all the contributors to the charter, so thank > you all. > > Regards, Ondrej Bill has asked me to post a charter as sent to ADs: http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure Here's verbatim copy of that page for an evidence: Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through the DNS for discovering and authenticating public keys which are associated with a service located at a domain name. Problem Statement: Entities on the Internet are usually identified using domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a domain operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for domain operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the domain operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and draft-josefsson-keyassure-tls. The mechanisms developed by this group will address bindings between domain names and keys, allowing flexibility for all key-transport mechanisms supported by the application protocols addressed (e.g., both self-signed and CA-issued certificates for use in TLS). The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. Milestones: Nov 2010 First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS Jan 2011 First WG draft of standards-track protocols for using DNS to associate hosts with IPsec Jun 2011 Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG Aug 2011 Protocols for using DNS to associate domain names with keys for IPsec to IESG Aug 2011 Recharter O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502DE3A7115 for ; Wed, 6 Oct 2010 08:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.9 X-Spam-Level: X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD9o6HnMissI for ; Wed, 6 Oct 2010 08:08:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id C253B3A6C4C for ; Wed, 6 Oct 2010 08:08:58 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 3780B73439E for ; Wed, 6 Oct 2010 17:09:58 +0200 (CEST) Message-ID: <4CAC9146.80609@nic.cz> Date: Wed, 06 Oct 2010 17:09:58 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: keyassure@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] Charter sent to ADs X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:09:00 -0000 Hi all, since the proposed charter is quite stable for a last week or so with small exceptions of small nits, we (me and Warren) believed that the charter is good to go and that we have a rough consensus on the charter, and so we asked our fellow ADs to process it accordingly to IETF processes, ie. take it to the IESG. With some luck that could mean that we can make it to be WG in the time of Beijing meeting. I would like to thank all the contributors to the charter, so thank you all. Regards, Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BFF3A6FC2; Tue, 5 Oct 2010 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnxI5AMZl1Si; Tue, 5 Oct 2010 11:36:00 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id ED26A3A7097; Tue, 5 Oct 2010 11:35:59 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1P3CNl-0005Km-Nc; Tue, 05 Oct 2010 18:36:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7086D6018; Tue, 5 Oct 2010 18:36:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+8ypa8RMu5rlKDWfvP1mXa36zdcsNGry8= Message-ID: <4CAB7048.6090603@extendedsubset.com> Date: Tue, 05 Oct 2010 13:36:56 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <1285970705.1984.136.camel@mattlaptop2.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 06 Oct 2010 10:28:06 -0700 Cc: "Kemp, David P." , dnsop@ietf.org, keyassure@ietf.org, tls@ietf.org, pkix@ietf.org, saag@ietf.org Subject: Re: [keyassure] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 18:36:01 -0000 On 10/05/2010 11:56 AM, Phillip Hallam-Baker wrote: > > Clearly if you have two controls, A and B and BOTH must be compromised, > the system is less likely to be compromised than either A or B. > > But the design approach taken in the Hoffman et. al. proposal is that > publication of a DNSSEC assurance for a cert disables verification on > the PKIX chain unless the 'preferences' flag is set. This flag will be > buried in a base64 encoded sub-field encoding. > > In practice only a proportion of clients will deploy this mechanism. So > if A is PKIX and B is DNSSEC, it will be possible for an attacker to > succeed if either A or B is compromised in one configuration and if > either A or A and B is compromised in the other. +1 In practice, only a proportion of servers will deploy this mechanism until such time as Firefox and Chrome are willing to shut them off. I've read that because DNSSEC records are large, some resolvers cannot pass them on. Testing a few months ago indicated that it worked on something like 4 out of 5 internet connections I tried it on. But it's quite possible that there are little wifi-router-firewall boxes in millions of homes that don't expect such large packets on port 53. So clients will have to continue to operate in the absence of DNSSEC information for the forseeable future. It's also reasonable to suspect that an attacker (who in our analysis is already presumed to have a fraudulent server cert and the ability to make use of it, i.e., MitM) would also be able to downgrade DNS to strip out this "preferences" flag (if some intermediate box isn't doing it already). Therefore the attacker may be able to choose to attack the via a DNSSEC problem (e.g., a website vuln at the site's DNS registrar) or via PKI (e.g., a rouge sub-CA). So the attack surface is, in fact, increased. Unless I'm missing something about how DNSSEC prevents downgrade attacks, which is quite possible. > People seem to be confusing the security of the cryptographic protocols > with the security of the infrastructures that support them. The weakest > link in any competently designed security scheme is people and > processes. Perhaps only because security designers have successfully washed their hands of the harder part of the problem? > The PKIX infrastructure has been operating as a security > infrastructure for 15 years, its flaws are reasonably well understood at > this point. That's a very nice way of saying it. I would have said it this way: IT SUCKS!!!! The fact that the national telephone company of Qwertystan can delegate a sub-CA that can delegate a sub-CA that can issue a certificate which enables the MitM of the connection between my notebook and my company's VPN server is a scandal. If anyone had ever proposed such a scheme to people who weren't already steeped in the status quo, they'd be laughed out of their industry. > DNS on the other hand is a non-security infrastructure that > people appear to want to immediately co-opt to duplicate functions of PKIX. Rather than wanting to co-opt or duplicate the current PKI scheme, it may be that people are simply eager to rid themselves of it. Not saying it's perfect, I honestly haven't looked into it very deeply, but DNSSEC holds a lot of promise: 1. It builds on top of DNS, which is reasonably mature. 2. It was designed for actual security with knowledge of modern attacks and the benefit of hindsight. 3. It was designed at all, rather than simply evolving to enable various sets of business deals. 4. It roots to one entity is ostensibly neutral and non-profit. They have a track record which can be evaluated. They largely own DNS anyway. 5. Domain holders already understand the need to handle their domain name registrations as super-critical assets. 6. It appears to delegate more control to the domain holder to define and authenticate his own data. He doesn't have to deal with weird "per server licensing" (whatever that means) agreements. 7. It appears to reduce or eliminate some recurring fees associated with server authentication. Of course, this list leaves out anything bad about it. Possibly, it's worse on balance. > "What could possibly go wrong" Lots, particularly during the transition period when parallel systems must be trusted. Which is why such a proposal needs a lot of thinking and real-world testing. Which is why it would have been better for it to have been proposed earlier. > Given that the problem that instigated this proposal is mis-issue of a > certificate. It would appear to me that we should look at deploying > controls that reduce the probability of mis-issue of a certificate It's not a question of probability, it's the option of the attacker. If you have something worth protecting, you need to be defending against a targeted attack. The attacker may or may not have the capability to obtain a usable private key, but if he can, he can be expected to use it. So it's not a question of "probability if" but of "who", i.e., who are the attackers I wish to defend against. There are may of users of the technology who do not desire to trust (or actively mistrust) many of the entities controlling CAs. > before we rush to deploy a completely new validation scheme for > certificates in the six month timescale being proposed in this charter. > > In particular, it would be rather useful to have controls of the form: > > * Certificates only valid if issued into a certificate chain with > specified properties > * Obtain additional authentication according to protocol X and key Y. Anything limiting the number and scope of CAs would be an improvement. But such improvements could have been implemented at any time previously, yet they were not. Maybe the prospect of DNSSEC replacing it will provide motivation for PKI to improve. But by then the train may already be rolling. - Marsh Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DEF43A7012 for ; Tue, 5 Oct 2010 10:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.477 X-Spam-Level: X-Spam-Status: No, score=-100.477 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gVdW4hiQYkK for ; Tue, 5 Oct 2010 10:56:26 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 490E53A6FB7 for ; Tue, 5 Oct 2010 10:56:26 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o95HvKfa088179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 10:57:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 5 Oct 2010 10:57:18 -0700 To: "Carl Wallace" , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] usable certificate association? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:56:27 -0000 At 1:34 PM -0400 10/5/10, Carl Wallace wrote: > > >If the client >> >receives two associations but does not understand the hash algorithm >> in >> >either, does it have 0 usable associations and continue, or does it >> fail >> >with access denied because it has no match? >> >> It has 0 usable associations and continues: >> If a certificate association contains a hash type that is not >> understood by the TLS client, that certificate association MUST be >> completely ignored. >> > >This is what I suspected was meant. It would be more clear if the >"completely ignored" phrase was replaced with something like "marked as >unusable" to tie the two steps together. Good suggestion; done. >Geoff's suggestion regarding >the hash algorithm to use could make this OBE. They work together well. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611A23A6FCA for ; Tue, 5 Oct 2010 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.404 X-Spam-Level: X-Spam-Status: No, score=-101.404 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NSsdXywrvBB for ; Tue, 5 Oct 2010 10:41:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1E0AB3A6F97 for ; Tue, 5 Oct 2010 10:41:38 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o95HgWH5087106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 10:42:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 5 Oct 2010 10:42:30 -0700 To: Geoff Beier From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:41:39 -0000 At 1:18 PM -0400 10/5/10, Geoff Beier wrote: >On Mon, Oct 4, 2010 at 19:42, Paul Hoffman wrote: >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-03.txt >> > > >> If a certificate association contains a hash type that is not >> understood by the TLS client, that certificate association MUST be >> completely ignored. > >This situation could be avoided entirely by requiring that the hash >type be the same as the hash used to produce the signature over the >CERT RR in question. Since the signature must be verified before the >association is processed, no client could get this far without >supporting the hash type. Good point. We will suggest this in the next draft. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489703A6C9D for ; Tue, 5 Oct 2010 10:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyvkquBKwpZB for ; Tue, 5 Oct 2010 10:33:19 -0700 (PDT) Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id AB9FC3A6E25 for ; Tue, 5 Oct 2010 10:33:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-9.tower-75.messagelabs.com!1286300052!31099749!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 27658 invoked from network); 5 Oct 2010 17:34:12 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-9.tower-75.messagelabs.com with SMTP; 5 Oct 2010 17:34:12 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Oct 2010 13:34:11 -0400 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] usable certificate association? Thread-Index: ActksxA7kuf0pJCuS7q95Jkxfye6zQAABpPA References: From: "Carl Wallace" To: "Paul Hoffman" , Subject: Re: [keyassure] usable certificate association? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:33:20 -0000 > >If the client > >receives two associations but does not understand the hash algorithm > in > >either, does it have 0 usable associations and continue, or does it > fail > >with access denied because it has no match? >=20 > It has 0 usable associations and continues: > If a certificate association contains a hash type that is not > understood by the TLS client, that certificate association MUST be > completely ignored. >=20 This is what I suspected was meant. It would be more clear if the "completely ignored" phrase was replaced with something like "marked as unusable" to tie the two steps together. Geoff's suggestion regarding the hash algorithm to use could make this OBE. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA303A6FC1 for ; Tue, 5 Oct 2010 10:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp2JbAJFKNwk for ; Tue, 5 Oct 2010 10:30:00 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BAF213A6FBD for ; Tue, 5 Oct 2010 10:29:59 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o95HUlL1086484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 10:30:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20101005014313.GA17376@LK-Perkele-V2.elisa-laajakaista.fi> References: <20101005014313.GA17376@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 5 Oct 2010 08:53:11 -0700 To: Ilari Liusvaara From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:30:01 -0000 At 4:43 AM +0300 10/5/10, Ilari Liusvaara wrote: >On Mon, Oct 04, 2010 at 04:42:04PM -0700, Paul Hoffman wrote: >> >A New Internet-Draft is available from the on-line Internet-Drafts directories. >> > Filename : draft-hoffman-keys-linkage-from-dns-03.txt > >> "The TLSRQ certificate type has a certificate body with a single octet >> of 0. The TLSFP certificate type is TBD2." > >Do you mean "The TLSRQ certificate type is TBD2."? Yes, thanks! --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4843A6E25 for ; Tue, 5 Oct 2010 10:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.473 X-Spam-Level: X-Spam-Status: No, score=-100.473 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RXOste2PH6O for ; Tue, 5 Oct 2010 10:29:55 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3A6763A6CE1 for ; Tue, 5 Oct 2010 10:29:55 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o95HUlL3086484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Oct 2010 10:30:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 5 Oct 2010 10:30:45 -0700 To: "Carl Wallace" , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] usable certificate association? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:29:56 -0000 At 7:22 AM -0400 10/5/10, Carl Wallace wrote: >In section 3, what is a "usable certificate association"? On that the TLS client is able to understand. >If the client >receives two associations but does not understand the hash algorithm in >either, does it have 0 usable associations and continue, or does it fail >with access denied because it has no match? It has 0 usable associations and continues: If a certificate association contains a hash type that is not understood by the TLS client, that certificate association MUST be completely ignored. > I assume that a different >client that receives the same two associations but does not understand >one and the other does not match should fail with access denied. Correct. > >A few nits... > >In the first paragraph of the Introduction, change "the trust anchor" to >"a trust anchor" and change "perform correct validation on" to >"successfully validate". Yep. >In section 2, it'd be nice to have an example that enumerates multiple >certificates to support the new text on exclusion vs. enumeration. Added. >Also in section 3, change "it process TLS" to "it processes TLS". Done. Thanks! --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585D93A6E25 for ; Tue, 5 Oct 2010 10:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3hrnE187J4F for ; Tue, 5 Oct 2010 10:17:56 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 651443A6FD1 for ; Tue, 5 Oct 2010 10:17:56 -0700 (PDT) Received: by iwn3 with SMTP id 3so10204987iwn.31 for ; Tue, 05 Oct 2010 10:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=CCu5cxAGA/lLoav+zCocddYPvW9ptGPfN42zBfkgSPM=; b=obb7GqHXl9amyP37PxfsqDZGQjSZSlVxqRzCymwbr7QEIXKfCvFIhRTSjVOrqogiKM +FII/mPUl0ZOHkkZ9DfCdU7iTSvPROetO4XqI8JOfrj44DdWwqn/bhMfQ4XzyHCsldlq BBtwGADNyyvJBxy29udDbLILXixWLdZavwaJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uGX8BhCb9UwXwPMxyBCGyqrgPvhMpcxAyLPbctRiN731A/+WkJtuuhRNRw5HJq1BYL FuNhrOy9A67FsRLOLV5x9pgHgUNPHe06zRCSiHBOZn7ljnX+gCtzUxHirEkJhG9VB+D7 Q1GfZ1A0Dy6+TxfAICpRiufUHJBZ1SCsW7kIc= Received: by 10.231.11.69 with SMTP id s5mr12476053ibs.38.1286299133570; Tue, 05 Oct 2010 10:18:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.199.11 with HTTP; Tue, 5 Oct 2010 10:18:33 -0700 (PDT) In-Reply-To: References: From: Geoff Beier Date: Tue, 5 Oct 2010 13:18:33 -0400 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:17:57 -0000 On Mon, Oct 4, 2010 at 19:42, Paul Hoffman wrote: >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-03.txt > > > If a certificate association contains a hash type that is not > understood by the TLS client, that certificate association MUST be > completely ignored. This situation could be avoided entirely by requiring that the hash type be the same as the hash used to produce the signature over the CERT RR in question. Since the signature must be verified before the association is processed, no client could get this far without supporting the hash type. Regards, Geoff Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892AD3A6F2A for ; Tue, 5 Oct 2010 07:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFDwWBwiyyVR for ; Tue, 5 Oct 2010 07:22:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 21E3C3A6F73 for ; Tue, 5 Oct 2010 07:22:49 -0700 (PDT) Received: by wwj40 with SMTP id 40so4078297wwj.13 for ; Tue, 05 Oct 2010 07:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=eN6TbdnH7nA/f47lp5qXspTyecECUhjCpr4WGhzqhu4=; b=jlx9+4fcw2ixytN6V9HzYdYJtlddtiI7jiCWBwr+gtdvpw11Opio+Kq81S4uagepGQ e3xjfb3GV/UbdBt9y8wTiRKi9loNs5YO47vFwv7e9bqkW27kraa8LqyUAYdWFlOrxUCx YwaTJrUS1n/I+Cr9IGcRDvI3bs31y7wK4oPbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=KfcARvyAbTLiFybvD2/d8dEIbH5J4zmYJ6fF00t3RbWI5L4WDO8Fd/LX0wranEwfgw 7gGvBD/icrD4AS7htf7QkHdOgoEpZm/cdyeEChsHBUbZ3xwmeS9FrHnfydyC/FO1xaWH ProXM08SSJNaofX6HlBjgbgEZZf/mZzLh1Ruc= MIME-Version: 1.0 Received: by 10.216.11.201 with SMTP id 51mr1107360wex.72.1286288626118; Tue, 05 Oct 2010 07:23:46 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.216.6.204 with HTTP; Tue, 5 Oct 2010 07:23:45 -0700 (PDT) In-Reply-To: References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> Date: Tue, 5 Oct 2010 10:23:45 -0400 X-Google-Sender-Auth: W7DmXtwS8M6sqHsQq0yXkE886Ew Message-ID: From: Adam Langley To: Tony Finch Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:22:51 -0000 On Tue, Oct 5, 2010 at 7:15 AM, Tony Finch wrote: >> Once the necessary record is allocated, a proposal is made to CABForum to >> require all member CAs to verify every cert against these DNS records before >> issue. I believe that there should be a very high degree of voluntary >> compliance since it is a check that can be automated. Yes, this would be a useful incentive to adoption. However, we're a ways off having a proposal solid enough for this yet. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A826E3A6F39 for ; Tue, 5 Oct 2010 04:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPk2xiGH4pDo for ; Tue, 5 Oct 2010 04:21:21 -0700 (PDT) Received: from mail151.messagelabs.com (mail151.messagelabs.com [216.82.253.3]) by core3.amsl.com (Postfix) with SMTP id 57E783A6F2F for ; Tue, 5 Oct 2010 04:21:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-5.tower-151.messagelabs.com!1286277737!4749010!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 31889 invoked from network); 5 Oct 2010 11:22:17 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-5.tower-151.messagelabs.com with SMTP; 5 Oct 2010 11:22:17 -0000 x-cr-hashedpuzzle: AFzG ApID BVSB CGok COrq Cqoh DKP/ D0F/ D7Ua EGif Eu1e FKyN G+9w HTMC H247 H6JU; 1; awBlAHkAYQBzAHMAdQByAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7BF4DDD1-D6E8-4DEE-BC3F-BFBDE8E5A6E7}; YwB3AGEAbABsAGEAYwBlAEAAYwB5AGcAbgBhAGMAbwBtAC4AYwBvAG0A; Tue, 05 Oct 2010 11:22:15 GMT; dQBzAGEAYgBsAGUAIABjAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABhAHMAcwBvAGMAaQBhAHQAaQBvAG4APwA= MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-class: urn:content-classes:message Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Oct 2010 07:22:15 -0400 Message-ID: X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: usable certificate association? Thread-Index: Actkf5BVTGTgnPDvS5qP29lJlsDARQ== From: "Carl Wallace" x-cr-puzzleid: {7BF4DDD1-D6E8-4DEE-BC3F-BFBDE8E5A6E7} To: Subject: [keyassure] usable certificate association? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 11:21:23 -0000 In section 3, what is a "usable certificate association"? If the client receives two associations but does not understand the hash algorithm in either, does it have 0 usable associations and continue, or does it fail with access denied because it has no match? I assume that a different client that receives the same two associations but does not understand one and the other does not match should fail with access denied. A few nits... In the first paragraph of the Introduction, change "the trust anchor" to "a trust anchor" and change "perform correct validation on" to "successfully validate". In section 2, it'd be nice to have an example that enumerates multiple certificates to support the new text on exclusion vs. enumeration. Also in section 3, change "it process TLS" to "it processes TLS". Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09F53A6D18 for ; Tue, 5 Oct 2010 04:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qARgml07EqXu for ; Tue, 5 Oct 2010 04:15:04 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 9D7BD3A6E60 for ; Tue, 5 Oct 2010 04:15:03 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51191) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1P35V1-0003Ae-sY (Exim 4.72) (return-path ); Tue, 05 Oct 2010 12:15:59 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1P35V1-00044j-Sn (Exim 4.67) (return-path ); Tue, 05 Oct 2010 12:15:59 +0100 Date: Tue, 5 Oct 2010 12:15:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: keyassure@ietf.org Subject: Re: [keyassure] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 11:15:05 -0000 Moving this to the keyassure mailing list. It's probably also on topic for pkix but i'm not subscribed there. On Mon, 4 Oct 2010, Phillip Hallam-Baker wrote: > > The way I see this working is that each CA would publish a record that > customers could publish in their DNS zone to state that other CAs should not > issue certs. This would have the Digest of either the root key or an > intermediate cert. This could presumably also cover a private CA cert or a self-signed certificate that is being used without any chain. > Once the necessary record is allocated, a proposal is made to CABForum to > require all member CAs to verify every cert against these DNS records before > issue. I believe that there should be a very high degree of voluntary > compliance since it is a check that can be automated. > > After a short interval the mechanism is made mandatory. The browser and > platform providers have the necessary tools to achieve this. They can > require the checks to be specified in the annual WebTrust audit which means > that every cert would have to be in compliance within a year. > > Non compliant certificates would be detected as a matter of course by the > various companies who have reason to crawl the Web and look at SSL certs. > > Note that my approach does not require client implementation to be > effective, but allows for client implementation if this is considered > desirable and is equally effective as a means of client side enforcement. I like this dual approach a lot. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62DE3A6D42 for ; Mon, 4 Oct 2010 18:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsIBf+DRPKA7 for ; Mon, 4 Oct 2010 18:36:38 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by core3.amsl.com (Postfix) with ESMTP id D97CB3A6E7E for ; Mon, 4 Oct 2010 18:36:35 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh01-2.mail.saunalahti.fi (Postfix) with SMTP id AC0598C2C1; Tue, 5 Oct 2010 04:37:29 +0300 (EEST) Received: from emh01.mail.saunalahti.fi ([62.142.5.107]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A05F44A6D37; Tue, 05 Oct 2010 04:37:29 +0300 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 359244035; Tue, 5 Oct 2010 04:37:27 +0300 (EEST) Date: Tue, 5 Oct 2010 04:43:13 +0300 From: Ilari Liusvaara To: Paul Hoffman Message-ID: <20101005014313.GA17376@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 01:36:48 -0000 On Mon, Oct 04, 2010 at 04:42:04PM -0700, Paul Hoffman wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Filename : draft-hoffman-keys-linkage-from-dns-03.txt > "The TLSRQ certificate type has a certificate body with a single octet > of 0. The TLSFP certificate type is TBD2." Do you mean "The TLSRQ certificate type is TBD2."? -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47A53A6DCE for ; Mon, 4 Oct 2010 16:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J9yUvi9BdXZ for ; Mon, 4 Oct 2010 16:41:10 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A2E0D3A6D4F for ; Mon, 4 Oct 2010 16:41:10 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o94Ng5M3027995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Oct 2010 16:42:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 4 Oct 2010 16:42:04 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [keyassure] Fwd: I-D Action:draft-hoffman-keys-linkage-from-dns-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 23:41:12 -0000 >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Using Secure DNS to Associate Certificates with Domain Names For TLS > Author(s) : P. Hoffman, et al. > Filename : draft-hoffman-keys-linkage-from-dns-03.txt > Pages : 13 > Date : 2010-10-04 > >TLS and DTLS use certificates for authenticating the server. Users >want their applications to verify that the certificate provided by >the TLS server is in fact associated with the domain name they >expect. Instead of trusting a certificate authority to have made >this association correctly, the user might instead trust the >authoritative DNS server for the domain name to make that >association. This document describes how to use secure DNS to >associate the TLS server's certificate with the the intended domain >name. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-03.txt The new draft has a slew of changes (listed near the end) that were suggested by many people on this list. Comments are appreciated, but we would prefer that discussion of this group becoming an IETF WG be considered much higher priority, given that we don't know what the first draft of the WG document will be. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2753A6E69; Mon, 4 Oct 2010 12:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ0YR8f-TsXU; Mon, 4 Oct 2010 12:17:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 91FE63A6E62; Mon, 4 Oct 2010 12:17:23 -0700 (PDT) Received: from crankycanuck.ca (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 20C181ECB41D; Mon, 4 Oct 2010 19:18:18 +0000 (UTC) Date: Mon, 4 Oct 2010 15:18:16 -0400 From: Andrew Sullivan To: Phillip Hallam-Baker Message-ID: <20101004191816.GB379@shinkuro.com> References: <1285970705.1984.136.camel@mattlaptop2.local> <4CA7E120.6080701@extendedsubset.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Tony Finch , "dnsop@ietf.org" , keyassure@ietf.org, Marsh Ray , "saag@ietf.org" , "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [keyassure] [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: keyassure@ietf.org List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:17:24 -0000 On Sun, Oct 03, 2010 at 11:14:23AM -0400, Phillip Hallam-Baker wrote: > What is actually being proposed is to replace the fifteen year established > system of CAs with a new scheme starting in November. [. . .] > I really don't think that we want to replace the existing infrastructure a > new PKI designed by people who claim not to understand the issues involved. > As the proposers of this scheme have done repeatedly. Suppose all of that is true (and I think it's a gross misrepresentation of the situation, but never mind that), so what? Presumably, if this new PKI sucks as much as you say it does, nobody will use it, and no harm will come. If it's a kind of snake oil that appeals to the clueless (i.e. it sucks as much as you say it does, but it's jumped up and marketed in a way that lures people who don't know any better), then it will have some spectacular failure and everyone will thenceforth avoid it. So what's the problem, even if things are as bad as you say? Also, why isn't this on the list devoted to this discussion (followup set)? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792FB3A6E84 for ; Sat, 2 Oct 2010 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.386 X-Spam-Level: X-Spam-Status: No, score=-101.386 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9OBKzVOVald for ; Sat, 2 Oct 2010 08:46:41 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 79DAA3A6E35 for ; Sat, 2 Oct 2010 08:46:41 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o92FlSsj095977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Oct 2010 08:47:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20101002032645.GA19564@odin.mars.sol> References: <20101002032645.GA19564@odin.mars.sol> Date: Sat, 2 Oct 2010 08:47:20 -0700 To: Scott Schmit , keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 15:46:42 -0000 At 11:26 PM -0400 10/1/10, Scott Schmit wrote: >On Thu, Sep 30, 2010 at 08:06:00PM -0400, Warren Kumari wrote keyassure: >> So, please have another look at the charter and hopefully you will > > find it acceptable to you: > > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure > >Looking at the deliverables, I see an asymmetry: >> Nov 2010 First WG draft of standards-track protocol for using DNS to >> associate hosts with keys for TLS and DTLS >> Jan 2011 First WG draft of standards-track protocols for using DNS >> to associate hosts with non-TLS security protocols > ^^^^^^^ >> Jun 2011 Protocol for using DNS to associate domain names with keys >> for TLS and DTLS to IESG >> Aug 2011 Protocols for using DNS to associate domain names with keys >> for IPsec to IESG > ^^^^^ > >Is this deliberate? Er, no, it was a mistake. Now fixed. >If I understand the latter two correctly, the intent >is that the Jun/Aug deliverables are final RFCs of the drafts put out in >Nov/Jan. Correct. >The other thing is that I'm not a big believer in special cases unless >they're really necessary, and I don't quite understand why TLS/DTLS >warrants a special case. I would have thought that we'd explain the >basic mechanism, and then appropriate protocol WGs (or this WG) would >explain how to leverage the mechanism in follow-on RFCs. Otherwise >you're setting yourself up for a maintenance nightmare of >almost-the-same mechanisms. Can you explain more? The drafts done so far show that most of the protocol work is in specifying the DNS part. For example, the "change" to TLS is simply "trust this cert without validating, unless you want to validate anyway". It would be similar for IPsec, although IPsec is quite different because of the many different types of authentication mechanisms that need to be shown in and out of scope. >If the thought is that the TLS/DTLS use cases are somehow more complex >than average, then maybe we should be laying out the requirements and >constraints first... At least for me, I didn't choose it because of its complexity, but in fact the opposite: the new protocol makes almost no changes to TLS processing. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F083A6BF1 for ; Fri, 1 Oct 2010 21:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEIsUCrj-yyR for ; Fri, 1 Oct 2010 21:06:52 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8D3663A6BB8 for ; Fri, 1 Oct 2010 21:06:51 -0700 (PDT) Received: by wwj40 with SMTP id 40so1563319wwj.13 for ; Fri, 01 Oct 2010 21:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=T4tYwrWl4oXdIr0MoPsivE2IU51FCAHjCV5uHWiPvEo=; b=V+ufOmdNjtxpm6HSKeVEqZsOopYLJFmZ1RzNR7MaB/fbkQbJqHzLwIW5iKV5G/KhZE neCxgA4j43SyXfxLYjjdLF9scWcxrPiPQs21qpnmvm3v8tz4TPEzx5L+ulOyJ/OMdll+ zNqDOcmfU0l7ZaWUZhMmEkYVXml7mgp4hYJVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TIpNumJtGSCjPPNT03Ltr25+jxwk0cSUyNJRXF3JBqriuCjWH7gUK7OlXd3xHO5zFe KbGG+eqjUzOCCfzyBYgYLol/0Ky1TPN9/4E+rn17Ei+DrraL+Vmoei+8/4UsjstxtubI OgQSIZ1228sENY3cfA6gILeXFvQnEERoaOkbY= MIME-Version: 1.0 Received: by 10.216.47.80 with SMTP id s58mr5264250web.15.1285992460723; Fri, 01 Oct 2010 21:07:40 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 21:07:40 -0700 (PDT) In-Reply-To: <15A9EC4B-D5A0-4E02-96F9-E91559BFD228@kumari.net> References: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> <15A9EC4B-D5A0-4E02-96F9-E91559BFD228@kumari.net> Date: Sat, 2 Oct 2010 00:07:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=001485f28010ce279704919a7369 Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 04:06:54 -0000 --001485f28010ce279704919a7369 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 1, 2010 at 1:54 PM, Warren Kumari wrote: > > >> That is why I do not want the charter to be tied to any specific approach, >> mine included. >> >> >> The point I was trying to make was that forced to chose between a >> certificate type that works for TLS+IPSEC+S/MIME+SSH and one that works for >> X.509+PGP+SPKI, I would choose the first, i.e. we would have: >> >> CERT APKIX .... >> CERT APGP .... >> CERT ASPKI .... >> >> But that is if I am forced to choose. I would prefer >> >> CERT ASSERT 0 0 >> >> Which is completely general. >> > > Can you please try draft text that explains that in a short and concise and > *specific* manner? > > We keep coming back to the "security policy" bit, and it seems as though A: > most of the participant have a different view than yours, B: your definition > is vague and / or changing and / or C: poorly defined / overly broad.... Please read your own draft that your name is on before accusing others of being vague or confusing. You will find that the certificate enumeration semantics that you claim to be the main point are never actually explained directly. Are you honestly confused by my comments on your spec or are you as confused by the document you put your name on as I was until I spent several weeks working out what it says? Where do I mention security policy in the foregoing paragraph you are commenting on? The answer is that I don't because I am only addressing the fact that you have a peculiar and unexplained fixation with having a spec that covers all known certificate types yet arbitrarily separates TLS protocol handling from all others. None of the authors of the draft have bothered to explain this rationale. The fixation with support for multiple cert types is despite the fact that SPKI concluded in 1999 and has never progressed beyond EXPERIMENTAL and the only other cert format of relevance is OpenPGP. While support for multiple certificate types might be arguably 'nice to have' it is hardly as significant as support for multiple protocols in a consistent fashion. No other key assurance format I know of has this peculiar distinction that you are attempting to foist on us and never bother to explain. Instead you use the tactics of agenda denial against me. Please explain to us just why you think TLS should be handled as a special case in the protocol. Note that it is perfectly OK to have a mechanism that is general and only give a detailed explanation for TLS. But that is not what is being proposed here. What you are proposing is to do a one off for using TLS with any certificate type and then do other protocols. The CERT slot is for certificate type not protocol type. You do owe us an explanation for that approach. So far none of you have ever deigned to justify a single one of your design decisions. Instead you have attempted to avoid engagement by claiming not to understand any of the points being made. Then you declare that consensus in the group is not to make any change and carry on as before. What I do not want is for these decisions to be made in the charter. >> > > Oh, but what we REALLY don't want is to have a charter that is so broad > that: > A: It never gets agreed to (which is what is happening here -- we have been > trying to limit the scope, but have slowly increased it to try accommodate > your suggestions and views). > B: the working group gets bogged down (like the mailing list has been) and > forward process is thwarted. > The question that the IESG is asking is not 'is the charter too broad' it is 'is the WG likely to finish anything worthwhile'. So responding to every design query by claiming not to understand the question is not exactly a good tactic if you want to give the ADs confidence in the WG ability to deliver. The approach that you appear to have been advised to follow here is to avoid engagement on the technical issues at all costs and just stick to the party line. I think that before you continue much further that you should consult an alternative expert on IETF WG strategy. I think that the advice you get back will be surprisingly different to the advice you have been receiving to date. -- Website: http://hallambaker.com/ --001485f28010ce279704919a7369 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 1, 2010 at 1:54 PM, Warren K= umari <warren@kum= ari.net> wrote:


That is why I do not want the charter to be tied to any specific approach, = mine included.


The point I was trying to make was that forced to chose between a certifica= te type that works for TLS+IPSEC+S/MIME+SSH and one that works for X.509+PG= P+SPKI, I would choose the first, i.e. we would have:

CERT APKIX ....
CERT APGP ....
CERT ASPKI ....

But that is if I am forced to choose. I would prefer

CERT ASSERT 0 0 <AlgID> <CertID> <Digest>

Which is completely general.

Can you please try draft text that explains that in a short and concise and= *specific* manner?

We keep coming back to the "security policy" bit, and it seems as= though A: most of the participant have a different view than yours, B: you= r definition is vague and / or changing and / or =A0C: poorly defined / ove= rly broad....

Please read your own draft that your name is on before = accusing others of being vague or confusing. You will find that the certifi= cate enumeration semantics that you claim to be the main point are never ac= tually explained directly.=A0

Are you honestly confused by my comments on your spec o= r are you as confused by the document you put your name on as I was until I= spent several weeks working out what it says?


Where do I mention security policy in the foregoing paragrap= h you are commenting on? The answer is that I don't because I am only a= ddressing the fact that you have a peculiar and unexplained fixation with h= aving a spec that covers all known certificate types yet arbitrarily separa= tes TLS protocol handling from all others.

None of the authors of the draft have bothered to expla= in this rationale.=A0


The fixation = with support for multiple cert types is=A0despite the fact that SPKI conclu= ded in 1999 and has never progressed beyond EXPERIMENTAL and the only other= cert format of relevance is OpenPGP. While support for multiple certificat= e types might be arguably 'nice to have' it is hardly as significan= t as support for multiple protocols in a consistent fashion.

No other key assurance format I know of has this peculi= ar distinction that you are attempting to foist on us and never bother to e= xplain. Instead you use the tactics of agenda denial against me.


Please explain to us just why you think TLS s= hould be handled as a special case in the protocol.

Note that it is perfectly OK to have a mechanism that is general and only= give a detailed explanation for TLS. But that is not what is being propose= d here. What you are proposing is to do a one off for using TLS with any ce= rtificate type and then do other protocols.

The CERT slot is for certificate type not protocol type= . You do owe us an explanation for that approach.

=
So far none of you have ever deigned to justify a single one= of your design decisions. Instead you have attempted to avoid engagement b= y claiming not to understand any of the points being made. Then you declare= that consensus in the group is not to make any change and carry on as befo= re.


What I do not want is for these decisions to= be made in the charter.

Oh, but what we REALLY don't want is to have a charter that is so broad= that:
A: It never gets agreed to (which is what is happening here -- we have been= trying to limit the scope, but have slowly increased it to try accommodate= your suggestions and views).
B: the working group gets bogged down (like the mailing list has been) and = forward process is thwarted.

The questi= on that the IESG is asking is not 'is the charter too broad' it is = 'is the WG likely to finish anything worthwhile'.=A0

So responding to every design query by claiming not to = understand the question is not exactly a good tactic if you want to give th= e ADs confidence in the WG ability to deliver.=A0

The approach that you appear to have been advised to follow here is to avoi= d engagement on the technical issues at all costs and just stick to the par= ty line.=A0

I think that before you continue much = further that you should consult an alternative expert on IETF WG strategy. = I think that the advice you get back will be surprisingly different to the = advice you have been receiving to date.


--
Website: http://hallambaker.com/

--001485f28010ce279704919a7369-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82243A6BBA for ; Fri, 1 Oct 2010 20:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[AWL=1.359, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAX66rcG4TmZ for ; Fri, 1 Oct 2010 20:25:57 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 9892D3A6BB8 for ; Fri, 1 Oct 2010 20:25:57 -0700 (PDT) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta05.emeryville.ca.mail.comcast.net with comcast id DfAe1f0010QkzPwA5fSnYs; Sat, 02 Oct 2010 03:26:47 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta02.emeryville.ca.mail.comcast.net with comcast id DfSl1f00J00PQ6U8NfSm8E; Sat, 02 Oct 2010 03:26:47 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id o923Qj3h022162 for ; Fri, 1 Oct 2010 23:26:45 -0400 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id o923QjOc022160 for keyassure@ietf.org; Fri, 1 Oct 2010 23:26:45 -0400 Date: Fri, 1 Oct 2010 23:26:45 -0400 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20101002032645.GA19564@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 03:25:58 -0000 On Thu, Sep 30, 2010 at 08:06:00PM -0400, Warren Kumari wrote keyassure: > So, please have another look at the charter and hopefully you will > find it acceptable to you: > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure Looking at the deliverables, I see an asymmetry: > Nov 2010 First WG draft of standards-track protocol for using DNS to > associate hosts with keys for TLS and DTLS > Jan 2011 First WG draft of standards-track protocols for using DNS > to associate hosts with non-TLS security protocols ^^^^^^^ > Jun 2011 Protocol for using DNS to associate domain names with keys > for TLS and DTLS to IESG > Aug 2011 Protocols for using DNS to associate domain names with keys > for IPsec to IESG ^^^^^ Is this deliberate? If I understand the latter two correctly, the intent is that the Jun/Aug deliverables are final RFCs of the drafts put out in Nov/Jan. The other thing is that I'm not a big believer in special cases unless they're really necessary, and I don't quite understand why TLS/DTLS warrants a special case. I would have thought that we'd explain the basic mechanism, and then appropriate protocol WGs (or this WG) would explain how to leverage the mechanism in follow-on RFCs. Otherwise you're setting yourself up for a maintenance nightmare of almost-the-same mechanisms. If the thought is that the TLS/DTLS use cases are somehow more complex than average, then maybe we should be laying out the requirements and constraints first... Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC1D3A6DCA for ; Fri, 1 Oct 2010 18:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80SkEfakXmnm for ; Fri, 1 Oct 2010 18:38:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 19C623A6E11 for ; Fri, 1 Oct 2010 18:38:01 -0700 (PDT) Received: by wyi11 with SMTP id 11so4113366wyi.31 for ; Fri, 01 Oct 2010 18:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=v58RrexC4r3b7xGrdn64akSGJ54Lh75qUa3mlMXmrS8=; b=A5U8c8ne0XrM3NBCqq2fokA0Y2e2Jjth2ryilqfzcB0xir/wGczjBmpqgpzK5YKvuG VWuvmfEHY/2PB+F1gyHqgIRf7JmSQWyDKMgzdadXa8aXjXQ46Qo0/KukQr8At6rCwaBV ASe1WPQD2MT0mxMpUAOpMsxsRwkSZ5YjGnhug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ESKmzC8y8t2tMUMHEsKO7wLuZWAGQ/d5ZsBT88EWIz1OGIxmP0TwgzJHx3Swy7jAxk rmYF1VU0tcKMxGKkI0JO0xEq1Plw6v48TC24JmynqXVIJ3OaFFtDIuIVnUFlXPVkcEk/ Y7Rjb+CSwZJKEhhVYpJhSHvz6CPIyZ/JBd7ko= MIME-Version: 1.0 Received: by 10.216.157.72 with SMTP id n50mr2780314wek.4.1285983530624; Fri, 01 Oct 2010 18:38:50 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 18:38:50 -0700 (PDT) In-Reply-To: References: <1285967068.1984.45.camel@mattlaptop2.local> <1285975827.1984.304.camel@mattlaptop2.local> Date: Fri, 1 Oct 2010 21:38:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Zack Weinberg Content-Type: multipart/alternative; boundary=0016e6546d9e87a82e0491985f4d Cc: keyassure@ietf.org Subject: Re: [keyassure] Potential benefits of keyassure X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 01:38:07 -0000 --0016e6546d9e87a82e0491985f4d Content-Type: text/plain; charset=ISO-8859-1 I think it good that people are starting to think in terms of the deployment incentive. While it is true that yet-another-mechanism for binding keys to domain names has limited utility by itself, that does not mean that the only use for binding keys to domain names is the one hidden in in hoffman-keys-linkage-from-dns or that this is the best way to achieve the stated goals. If Google wishes to eliminate weak CAs from their browser then they can do that tomorrow. They decide who goes on the list, if they are not confident in the CPS of any of them they should remove the roots. My preferred approach would be for them to eliminate all user interface elements for all certs validated at DV or bellow. The browser would accept self signed, DV and DNSSEC validated keys regardless of source and turn on TLS without any user notification at all in the primary chrome. Somehow, I don't think they are going to do that quite yet. But I think they might if we could get to the position where 90% of Web traffic was encrypted and insecurity was now the default. To get to that point, it is necessary to make it possible for any site to offer an automatic, transparent upgrade to use TLS without additional out-of-pocket cost. Just because you can't think of a use for DNSSEC validated keys without the cert enumeration semantics does not mean that no such uses exist. --0016e6546d9e87a82e0491985f4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it good that people are starting to think in terms of the deploymen= t incentive.

While it is true that yet-another-mechanism for binding= keys to domain names has limited utility by itself, that does not mean tha= t the only use for binding keys to domain names is the one hidden in in hof= fman-keys-linkage-from-dns or that this is the best way to achieve the stat= ed goals.=A0


If Google wishes to eliminate weak CAs f= rom their browser then they can do that tomorrow. They decide who goes on t= he list, if they are not confident in the CPS of any of them they should re= move the roots.

My preferred approach would be for them to eliminate al= l user interface elements for all certs validated at DV or bellow. The brow= ser would accept self signed, DV and DNSSEC validated keys regardless of so= urce and turn on TLS without any user notification at all in the primary ch= rome.=A0


Somehow, I don't think they are goin= g to do that quite yet. But I think they might if we could get to the posit= ion where 90% of Web traffic was encrypted and insecurity was now the defau= lt.

To get to that point, it is necessary to make it possib= le for any site to offer an automatic, transparent upgrade to use TLS witho= ut additional out-of-pocket cost.


Just because you can't think of a use for DNSSEC validated keys without= the cert enumeration semantics does not mean that no such uses exist. --0016e6546d9e87a82e0491985f4d-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B603A6D39 for ; Fri, 1 Oct 2010 18:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHbH7yDdemrN for ; Fri, 1 Oct 2010 18:32:32 -0700 (PDT) Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id 9F5933A6A39 for ; Fri, 1 Oct 2010 18:32:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-5.tower-75.messagelabs.com!1285983199!114353322!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.17] Received: (qmail 7623 invoked from network); 2 Oct 2010 01:33:20 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.17) by server-5.tower-75.messagelabs.com with SMTP; 2 Oct 2010 01:33:20 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 1 Oct 2010 21:32:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] Potential benefits of keyassure Thread-Index: ActhyenTSyUsFzNxQGiR7RtjF1d1kQABgSUQ References: <1285967068.1984.45.camel@mattlaptop2.local><1285975827.1984.304.camel@mattlaptop2.local> From: "Carl Wallace" To: "Zack Weinberg" , "Matt McCutchen" Cc: keyassure@ietf.org Subject: Re: [keyassure] Potential benefits of keyassure X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 01:32:33 -0000 PHNuaXA+DQo+ID4+IEV4Y2x1c2l2aXR5IGFzc2VydGlvbnMsIHRob3VnaCwgKmRvKiBidXkgeW91 IGEgcmVhbCBzZWN1cml0eQ0KPiA+PiBpbmNyZW1lbnQ6IHNhZmV0eSBhZ2FpbnN0IGNvcnJ1cHQg b3IgY29lcmNlZCBDQXMgaXNzdWluZyByb2d1ZQ0KPiA+PiBjZXJ0aWZpY2F0ZXMsDQo+ID4NCj4g PiBUaGlzIGlzIGFsbCB0cnVlLiDCoEJ1dCBub3RlIHRoYXQgRE5TU0VDIHRydXN0IGFuY2hvcnMg YXJlIG5vdCBpbW11bmUNCj4gdG8NCj4gPiBjb3JydXB0aW9uIG9yIGNvZXJjaW9uIGVpdGhlciwg c28gaXQgbWF5IGJlIHdvcnRoIGxvY2FsbHkgY29uZmlndXJpbmcNCj4gPiBleGNsdXNpdmUgdHJ1 c3QgYW5jaG9ycyBmb3IgaGlnaC12YWx1ZSB6b25lcyB3aXRoIHdoaWNoIG9uZSBoYXMgYQ0KPiA+ IHJlbGF0aW9uc2hpcC4NCj4gDQo+IEFzIGEgYnJvd3NlciB2ZW5kb3IgKGxldCBtZSBiZSBzcGVj aWZpYzogdW50aWwgdGhpcyBwYXN0IEF1Z3VzdCBJDQo+IHdvcmtlZCBmb3IgTW96aWxsYSBDby4s IGFuZCBJIGFtIHN0aWxsIGludm9sdmVkIGluIHRoZSBwcm9qZWN0KSBJIGFtDQo+IHJ1bm5pbmcg b24gdGhlIGFzc3VtcHRpb24gdGhhdCBsb2NhbCBjb25maWd1cmF0aW9uIG9mIHRydXN0IGFuY2hv cnMNCj4gb2NjdXJzIHdpdGggcHJvYmFiaWxpdHkgemVybw0KDQpUaG91Z2ggaXQgbWF5IGJlIGNs b3NlIGVub3VnaCB0byAwJSwgdGhpcyBpcyBjZXJ0YWlubHkgbm90IHRydWUgYSBzdGF0ZW1lbnQu ICBQbGVudHkgb2YgZm9sa3MgY2xlYW4gbXVjaCBvZiB0aGUgY3J1ZnQgZnJvbSB0aGVpciBUQSBz dG9yZS4gIEF0IHByZXNlbnQgSSBjYW4gb3BlcmF0ZSBteSBDaHJvbWUgb3IgSUUgYnJvd3NlcnMg c3VjaCB0aGF0IGNvbnN0cmFpbmVkIFRBcyBhcmUgdXNlZCBmb3IgcGF0aCB2YWxpZGF0aW9uIGFu ZCwgZm9yIGV4YW1wbGUsIEVWIGNlcnRpZmljYXRlIHBvbGljaWVzIGFyZSByZXF1aXJlZC4gIFRo aXMgcGFydGlhbGx5IGV4cGxhaW5zIHdoeSBJIGRvbuKAmXQgd2FudCBvciBzZWUgdmFsdWUgaW4g YSBmbGFnIHRlbGxpbmcgdGhlIGNsaWVudCB3aGF0IHRvIGRvIHZhbGlkYXRpb24td2lzZSB3aXRo IHRoZSBrZXkgb2J0YWluZWQgZnJvbSBETlMuICBVbmZvcnR1bmF0ZWx5LCB0aGUgY29kZSBpc24n dCBwcmVzZW50bHkgYXZhaWxhYmxlIChidXQgaXQgd2FzIGRlbW8nZWQgYXQgYSBOSVNUIFBLSSBj b25mZXJlbmNlIGFuZCBET0QgY29uZmVyZW5jZSBsYXN0IHNwcmluZykuICANCg0KRm9yIHdoYXQg aXQncyB3b3J0aCwgbW92aW5nIHBvbGljeSBlbHNld2hlcmUgc2VlbXMgbGlrZSBhIGdvb2QgdGhp bmcuICBJIGxpa2UgdGhlIGN1cnJlbnQgVExTIGRyYWZ0IChtaW51cyB0aGUgZmxhZyBJJ3ZlIGdy b3VzZWQgYWJvdXQgcHJldmlvdXNseSkuDQo= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502453A6CD3 for ; Fri, 1 Oct 2010 17:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.386 X-Spam-Level: X-Spam-Status: No, score=-101.386 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLcEK3RtMjPZ for ; Fri, 1 Oct 2010 17:45:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 96DD53A6C86 for ; Fri, 1 Oct 2010 17:45:34 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o920kKon053954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 17:46:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 1 Oct 2010 17:46:19 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 00:45:35 -0000 At 8:24 PM -0400 10/1/10, Phillip Hallam-Baker wrote: >I am agnostic on the question of number of WGs. Sounds good. I have removed the policy discussion from the proposed charter at <>. Please get a mailing list for the policy work set up. If the ADs don't mint you one @ietf.org (but they should), I'm happy to host it at VPNC (because there could be some effect on IPsec) or you can host one at Comodo or something. Be sure to tell this list when it is up and happening. This split should let both sets of work move forwards more expeditiously. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63D43A6CD3 for ; Fri, 1 Oct 2010 17:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldODjlNDnVRp for ; Fri, 1 Oct 2010 17:35:59 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 68CB73A6D91 for ; Fri, 1 Oct 2010 17:35:59 -0700 (PDT) Received: by qyk7 with SMTP id 7so1572912qyk.10 for ; Fri, 01 Oct 2010 17:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1IlfXv3Hdg4aiLtPBuIe1s4Vp47T472sZPChHGbcmwE=; b=MhIF+c9wAaGkdJ4fR1G8HUTU9T95DN6F8n6ywJtFdChGzac1r8Fi+cND9yIGmqMs3P GGgXwrPIZwUBYksEb7VO5x+qJBdo3xZK6vFHzRfk0b2xkNjPIu+Kb0ZSdZkGkq8N9D/+ I3hndB1cK1Q3gxACDOokjTmsjLthmtLCowde8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TkQGeLpSJ/NHD00Qr7RY058vtS76TmliBV3HaAdVxnf5SZ+ILhs3sQo6FzX/ddNuPY 7+AWGVq9ZPUV2WDIEaCLd5QNRnxuPVRJVN8ZwgTNukU3LcIiSTXee/Eb4ae7hwxVxOcb 6fjwtDxqxKOgxMNfaXXMmmZgjHOthTwSitz1I= MIME-Version: 1.0 Received: by 10.220.61.140 with SMTP id t12mr1526792vch.194.1285979808186; Fri, 01 Oct 2010 17:36:48 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.220.191.134 with HTTP; Fri, 1 Oct 2010 17:36:48 -0700 (PDT) In-Reply-To: <1285975827.1984.304.camel@mattlaptop2.local> References: <1285967068.1984.45.camel@mattlaptop2.local> <1285975827.1984.304.camel@mattlaptop2.local> Date: Fri, 1 Oct 2010 17:36:48 -0700 X-Google-Sender-Auth: wLSBPFy8zAebfmSmqaZ40ioO3oc Message-ID: From: Zack Weinberg To: Matt McCutchen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Potential benefits of keyassure X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 00:36:01 -0000 On Fri, Oct 1, 2010 at 4:30 PM, Matt McCutchen wro= te: > On Fri, 2010-10-01 at 14:33 -0700, Zack Weinberg wrote: >> This is my personal opinion, and only applies to keys used for HTTPS: >> I don't think being able to make that positive statement via the DNS >> is useful by itself. =C2=A0All it does (I think, anyway) is provide an >> alternative to DV certs. > > Right, and one that supports secure delegation. =C2=A0PKIX supports > delegation via name constraints, but they are unsupported in some > popular clients and insecure in others that accept the subject common > name as a DNS name without applying the constraints. =C2=A0One could fix = the > PKIX clients, but I suspect that most people who care about secure > delegation will just switch to DNSSEC where it is already working. But what good does secure delegation do you in the absence of exclusivity assertions? Someone can still come along with a cert they shouldn't have, courtesy Jim-Bob's Bait Shop and CA, and without an exclusivity assertion, the browser has no way of knowing it shouldn't accept it. (To be honest, though, I'm not sure I know what you mean by secure delegati= on?) >> Exclusivity assertions, though, *do* buy you a real security >> increment: safety against corrupt or coerced CAs issuing rogue >> certificates, > > This is all true. =C2=A0But note that DNSSEC trust anchors are not immune= to > corruption or coercion either, so it may be worth locally configuring > exclusive trust anchors for high-value zones with which one has a > relationship. As a browser vendor (let me be specific: until this past August I worked for Mozilla Co., and I am still involved in the project) I am running on the assumption that local configuration of trust anchors occurs with probability zero. >> and against blatantly fake certs that users click >> through anyway. =C2=A0Those (particularly the latter) are real-world >> problems that browser vendors would love to have immediate-term >> solutions to. > > You're supposing that browsers would not allow users to override an > exclusive certificate list in DNSSEC, on the grounds that the server is > broken and accepting another certificate would be by definition > incorrect behavior. Yes. STS (http://tools.ietf.org/html/draft-hodges-strict-transport-sec) is already going there, and this could follow. > Why should we believe that such a tough stance will > be any more viable with DNSSEC than with the current public CA system? > (This isn't a rhetorical question, I want an answer if there is one.) As I understand it, a lot of the problems with the current CA system are consequences of silent acceptance of conditions that *should* (from an abstract security point or view) shut down a site. We're stuck with that in the existing system lest we break sites that aren't really being maintained. But the new scheme is opt-in, so we can declare that by opting in, you take on certain extra administrative responsibilities, and in exchange you get these additional security benefits. Don't like it? Stick with DV certs, we're not taking that away. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58FB3A6E28 for ; Fri, 1 Oct 2010 17:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGvMKDtGo1v9 for ; Fri, 1 Oct 2010 17:23:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0BE9D3A6D91 for ; Fri, 1 Oct 2010 17:23:21 -0700 (PDT) Received: by wwj40 with SMTP id 40so1485134wwj.13 for ; Fri, 01 Oct 2010 17:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7PjtPdQIT43B0NzPgyin0D6BFRtMIZcv0y6EvEUxDjI=; b=EZQirlJdZKsaSX0zkkHt9uSmo/62/kzUoK/dpvg5XQlZlGK8iT3XE/l28qV7SIylLI AwIj+HSB5ZkVX+xcNcXZjTyRgi6BiAbUrlHnykl3afXGKgPE6ndxgZMkP5AAOxLVKHi1 GKbEbif8tOJ3BbEbhAuV12weNwYDDeoqW8ATM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TC3ca9wUEx+bZ0UQN/7UPm5w2wnM7Y0Q2SmcFv16jjctzx1dfzvDd6cWwCgPpovjeO hXZ2YBXtE9VCw8WFR5ZX78Z1zBQgM3omZPlQFzfTSwj8HvA5ujO6ZFVdPq2l3ANi8iMh 22oeUbJK6vE/zFb219QmEN4gzlfNXMsp3nuqA= MIME-Version: 1.0 Received: by 10.216.13.17 with SMTP id a17mr2733848wea.46.1285979050777; Fri, 01 Oct 2010 17:24:10 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 17:24:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Oct 2010 20:24:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e64c19ce829d33049197541a Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 00:23:23 -0000 --0016e64c19ce829d33049197541a Content-Type: text/plain; charset=ISO-8859-1 I am agnostic on the question of number of WGs. I think that getting a spec like ASSURE/DPKIX/DIGEST ready for submission to the IESG can be done by January next year. The XDIGEST/TLSFP approach with the enumeration business is going to take quite a lot longer. It can possibly be done in a year if it is feasible. As far as ESRV goes, what I want to do at this stage is to get some real world deployment experience on an experimental basis. I want a RR assignment as soon as possible but would not want to be starting on a standards track effort for a year. So we really don't need to decide whether this is one WG or two at this stage. I suggest the following milestones Jan 2011 Submit DIGEST mechanism draft to IESG July 2011 Submit DIGESTX mechanism draft to IESG July 2011 Submit Using CERT records with TLS draft to IESG Nov 2011 Submit Using CERT records with IPSEC draft to IESG Recharter These are actually pretty aggressive milestones. The WG would have to cover a lot of work in a short space of time. Getting the group chartered by Jan might well be ambitious. Even if the draft of DIGESTX with the enumeration/exclusion semantics is ready in Jan 2011, the charter has to give the TLS, PKIX and other working groups a sufficient time to review the impact on their specs. Note also that getting the draft to the IESG is not the end of the process. There can be a huge amount of work for the shepherd and the authors after that point. The WG is going to have to take a very different approach to work if they want the spec to exit from the IESG. On Fri, Oct 1, 2010 at 7:33 PM, Paul Hoffman wrote: > At 7:05 PM -0400 10/1/10, Phillip Hallam-Baker wrote: > >What I am insisting on here is a separation between security policy and > the key assurance mechanism. It should not be necessary for me to use a > mechanism that circumvents PKIX path validation for ALL certificates bound > to that domain name in order to use either DNSSEC key validation or security > policy. > > Well, you didn't say that you agreed with the proposition that the two > pieces of work be in separate WGs, but it sounds that way from this > paragraph. Is that true? > > --Paul Hoffman, Director > --VPN Consortium > -- Website: http://hallambaker.com/ --0016e64c19ce829d33049197541a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am agnostic on the question of number of WGs.

I think = that getting a spec like ASSURE/DPKIX/DIGEST ready for submission to the IE= SG can be done by January next year.=A0

The XDIGES= T/TLSFP approach with the enumeration business is going to take quite a lot= longer. It can possibly be done in a year if it is feasible.


As far as ESRV goes, what I want to do a= t this stage is to get some real world deployment experience on an experime= ntal basis. I want a RR assignment as soon as possible but would not want t= o be starting on a standards track effort for a year.

So we really don't need to decide whether this is o= ne WG or two at this stage.=A0


I su= ggest the following milestones

Jan 2011 =A0Submit = DIGEST mechanism draft to IESG
July 2011 Submit DIGESTX mechanism draft to IESG
July 2011 S= ubmit Using CERT records with TLS draft to IESG
Nov 2011 Submit= =A0Using CERT records with IPSEC draft to IESG
Recharter

These are actually pretty aggressive mil= estones. The WG would have to cover a lot of work in a short space of time.= Getting the group chartered by Jan might well be ambitious.=A0

Even if the draft of DIGESTX with the enumeration/exclusion = semantics is ready in Jan 2011, the charter has to give the TLS, PKIX and o= ther working groups a sufficient time to review the impact on their specs.<= /div>


Note also that getting the draft to the = IESG is not the end of the process. There can be a huge amount of work for = the shepherd and the authors after that point.

The WG is going to have to take a very different approach to work if they w= ant the spec to exit from the IESG.


On Fri, Oct 1, 2010 at 7:33 PM, Paul Hoffman <paul.hoffman@v= pnc.org> wrote:
At 7:05 PM -0400 10/1/10,= Phillip Hallam-Baker wrote:
>What I am insisting on here is a separation between security policy and= the key assurance mechanism. It should not be necessary for me to use a me= chanism that circumvents PKIX path validation for ALL certificates bound to= that domain name in order to use either DNSSEC key validation or security = policy.

Well, you didn't say that you agreed with the proposition that th= e two pieces of work be in separate WGs, but it sounds that way from this p= aragraph. Is that true?

--Paul Hoffman, Director
--VPN Consortium



--
Website: http://hallambaker.com/

--0016e64c19ce829d33049197541a-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF0D3A6D71 for ; Fri, 1 Oct 2010 16:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtYE7Klex+wN for ; Fri, 1 Oct 2010 16:45:02 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 5509E3A6CFC for ; Fri, 1 Oct 2010 16:45:02 -0700 (PDT) Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id D9FA4228481E; Fri, 1 Oct 2010 19:45:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20101001200627.GB14142@shinkuro.com> Date: Fri, 1 Oct 2010 19:45:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <65F83BE9-2769-4E4F-BBF9-BDE82D69056B@kumari.net> References: <20101001200627.GB14142@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:45:03 -0000 On Oct 1, 2010, at 4:06 PM, Andrew Sullivan wrote: > On Fri, Oct 01, 2010 at 01:03:05PM -0700, Paul Hoffman wrote: >> How do others feel about this removal of policy for *this* WG? >=20 > It seems to me that if we want to get any work done, it would be a = good idea. >=20 Just in case it wasn't obvious from my earlier mails, so do I....=20 W > A >=20 > --=20 > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1A63A6CFC for ; Fri, 1 Oct 2010 16:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVzedZlLyqpq for ; Fri, 1 Oct 2010 16:35:21 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 2641F3A6D53 for ; Fri, 1 Oct 2010 16:35:21 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 7F18A28006F; Fri, 1 Oct 2010 16:36:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=u3bDah2Ju0ov6UJSlzB/JKfvxr61LC0i4LUxZdRF9yT cVXk8uMP5jPktA2grL6bZK9H10JqI+mqzcV9uUrxNxpse3RGzI3BlH/xZsr22iMH kwqEr2y9nvMKUW6DgcsvZY+gOrT99KdIl2g01MnVWS5vMXuTz+e1pbjDCZFevGjM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=p3jKTyhU9Wd8RW5jN3YP4o9a44A=; b=Ph1w02rMyy EoB+gm7oV3XuhNucY5z04VJbmNQ0mlGp+4aaoXwgSdqldSiiU92va85D72h38HgV qKNLfT+6jT5DcIeeDPPuj8E7LicA8S89WimpcDAkqO6Kbkig0CUSFURuLncm/ES2 hqSNjoAtK/19P37HnNTKj10rhzeaTCg+k= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id 3B36728006C; Fri, 1 Oct 2010 16:36:09 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg In-Reply-To: References: <1285967068.1984.45.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Oct 2010 19:30:27 -0400 Message-ID: <1285975827.1984.304.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: [keyassure] Potential benefits of keyassure X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:35:24 -0000 On Fri, 2010-10-01 at 14:33 -0700, Zack Weinberg wrote: > On Fri, Oct 1, 2010 at 2:04 PM, Matt McCutchen wrote: > > On Fri, 2010-10-01 at 13:46 -0700, Zack Weinberg wrote: > >> Client software has to be able to > >> do something with that information, after all. If this WG cannot come > >> to any consensus on the meaning of a fingerprint record, _in the > >> absence_ of any explicit policy records, then we're not doing anything > >> useful. > > > > I believe we have consensus that the presence of a DPKIX (or analogous) > > record at a name is a positive statement that the key is acceptable for > > that name. The disagreement is about whether DPKIX records are > > implicitly exclusive when at least one is present (as in > > draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be > > optionally made exclusive (one approach being to add the functionality > > to draft-hallambaker-esrv). > > This is my personal opinion, and only applies to keys used for HTTPS: > I don't think being able to make that positive statement via the DNS > is useful by itself. All it does (I think, anyway) is provide an > alternative to DV certs. Right, and one that supports secure delegation. PKIX supports delegation via name constraints, but they are unsupported in some popular clients and insecure in others that accept the subject common name as a DNS name without applying the constraints. One could fix the PKIX clients, but I suspect that most people who care about secure delegation will just switch to DNSSEC where it is already working. > That may be good for the long-run health of > the net, but it doesn't make any direct improvement to the security of > the web and therefore it's going to be a hard sell to browser vendors. > > Exclusivity assertions, though, *do* buy you a real security > increment: safety against corrupt or coerced CAs issuing rogue > certificates, This is all true. But note that DNSSEC trust anchors are not immune to corruption or coercion either, so it may be worth locally configuring exclusive trust anchors for high-value zones with which one has a relationship. > and against blatantly fake certs that users click > through anyway. Those (particularly the latter) are real-world > problems that browser vendors would love to have immediate-term > solutions to. You're supposing that browsers would not allow users to override an exclusive certificate list in DNSSEC, on the grounds that the server is broken and accepting another certificate would be by definition incorrect behavior. Why should we believe that such a tough stance will be any more viable with DNSSEC than with the current public CA system? (This isn't a rhetorical question, I want an answer if there is one.) -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520983A6D71 for ; Fri, 1 Oct 2010 16:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.383 X-Spam-Level: X-Spam-Status: No, score=-101.383 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZYEU4g+WZah for ; Fri, 1 Oct 2010 16:32:48 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 95D463A6C7D for ; Fri, 1 Oct 2010 16:32:48 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o91NXYow051882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 16:33:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 1 Oct 2010 16:33:33 -0700 To: Phillip Hallam-Baker From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:32:49 -0000 At 7:05 PM -0400 10/1/10, Phillip Hallam-Baker wrote: >What I am insisting on here is a separation between security policy and the key assurance mechanism. It should not be necessary for me to use a mechanism that circumvents PKIX path validation for ALL certificates bound to that domain name in order to use either DNSSEC key validation or security policy. Well, you didn't say that you agreed with the proposition that the two pieces of work be in separate WGs, but it sounds that way from this paragraph. Is that true? --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C293A6E4B for ; Fri, 1 Oct 2010 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFTPp0CyElZt for ; Fri, 1 Oct 2010 16:04:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 591ED3A6E46 for ; Fri, 1 Oct 2010 16:04:24 -0700 (PDT) Received: by wyi11 with SMTP id 11so4036723wyi.31 for ; Fri, 01 Oct 2010 16:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OvUdwWDHoFwPbG9HhILl13D+mOhbSRdX+gaA7dF2QGo=; b=nsbin9uhD5Gkn91DuU8QdnAGwKe9XpRfhxpk1M5cD3RTjEYXrU4jjxW40SvaAmSFI1 mavOVSxS3G7SWW7Lxu9hpeW/ELIH4zBVhizpj333jWHVp9q5ERxUUkqLaq60l19McBRA /A+tTbs3nRpB7B3gCmjG2o8I4+jl+baVrykm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wrerXqsiGD2WIZcqQReYjrTA4Y7p0P1O3F5aW+JzGOnTdc8rGxbQtBylO/ToiIgu2V N1AB8NrHpWhupkl9URfdaP5SsQr9YBiS/7ltbuN5KoenMRMINhfwtq/zUduLEEjdLHqV /18bSGjBSeAJHkrIj96501aYOYixnoIyyLnP4= MIME-Version: 1.0 Received: by 10.216.22.203 with SMTP id t53mr5062201wet.37.1285974312763; Fri, 01 Oct 2010 16:05:12 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 16:05:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Oct 2010 19:05:12 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016364c7e371a405b0491963abd Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 23:04:25 -0000 --0016364c7e371a405b0491963abd Content-Type: text/plain; charset=ISO-8859-1 My only non-negotiable position are 1) that the exclusive cert enumeration semantics have to be a clearly distinguished option when using DNSSEC to assure keys 2) That this aspect of security policy does not foreclose a comprehensive solution to the problem. As far as the mechanism to use the DNS+DNSSEC goes, we are currently very close. The only outstanding issues are 1) Identifier to be used to identify the cert format to prevent a substitution attack and the hash algorithm. I am fine with anything that does not bias the scheme towards one security protocol. So using the DNS identifiers would be OK and using ASN.1 would be OK. I don't want to use TLS identifiers even if the cert type is limited to TLS as that would mean having to specify different identifiers according to the protocol to be used which would make coding a general API hellish. 2) Whether to tie the record to one protocol (TLS) or make the key assurance mechanism protocol neutral with the proviso that an RFC is likely to be necessary to explain exactly how to use the mechanism with each protocol covered. Now it may just be me, but I do not regard those as being irreconcilable. To deal with the cert enumeration exclusion semantics, I propose two separate certificate Types: DIGEST For assuring certs without exclusive semantics XDIGEST For assuring certs and asserting exclusive semantics We have plenty of certificate type codes and can even use OIDs if necessary. This makes the use of exclusive semantics a clearly defined option. It is thus practical to use this mechanism to assure mail server certs and the like without the risk that publishing a mail server cert will break the Web server. What I am insisting on here is a separation between security policy and the key assurance mechanism. It should not be necessary for me to use a mechanism that circumvents PKIX path validation for ALL certificates bound to that domain name in order to use either DNSSEC key validation or security policy. --0016364c7e371a405b0491963abd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My only non-negotiable position are=A0

1) that the exclu= sive cert enumeration semantics have to be a clearly distinguished option w= hen using DNSSEC to assure keys=A0

2) That this aspect of security policy does not f= oreclose a comprehensive solution to the problem.

=
As far as the mechanism to use the DNS+DNSSEC goes, we are c= urrently very close. The only outstanding issues are

1) Identifier to be used to identify the cert format to= prevent a substitution attack and the hash algorithm. I am fine with anyth= ing that does not bias the scheme towards one security protocol. So using t= he DNS identifiers would be OK and using ASN.1 would be OK.

I don't want to use TLS identifiers even if the cer= t type is limited to TLS as that would mean having to specify different ide= ntifiers according to the protocol to be used which would make coding a gen= eral API hellish.

2) Whether to tie the record to one protocol (TLS) or m= ake the key assurance mechanism protocol neutral with the proviso that an R= FC is likely to be necessary to explain exactly how to use the mechanism wi= th each protocol covered.


Now it may just be me, but I do not rega= rd those as being irreconcilable.=A0


To deal with the cert enumeration exclusion semantics, I propose two sepa= rate certificate Types:

DIGEST =A0 =A0For assuring certs without exclusive sema= ntics
XDIGEST =A0 For assuring certs and asserting exclusive sema= ntics

We have plenty of certificate type codes and= can even use OIDs if necessary.

This makes the use of exclusive semantics a clearly def= ined option. It is thus practical to use this mechanism to assure mail serv= er certs and the like without the risk that publishing a mail server cert w= ill break the Web server.


What I am insisting on here is a separat= ion between security policy and the key assurance mechanism. It should not = be necessary for me to use a mechanism that circumvents PKIX path validatio= n for ALL certificates bound to that domain name in order to use either DNS= SEC key validation or security policy.
--0016364c7e371a405b0491963abd-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CC53A6BCF for ; Fri, 1 Oct 2010 15:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skV6SHSODXcc for ; Fri, 1 Oct 2010 15:54:10 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 346E83A6BB8 for ; Fri, 1 Oct 2010 15:54:10 -0700 (PDT) Received: (qmail 20696 invoked by uid 0); 1 Oct 2010 22:54:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 1 Oct 2010 22:54:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=4NQ6+fw/aHY6P8XaGaU9qijRNWhrrn7kiclIWRmQ1zcgj+Pb7NIDZegvYz7BNOb3zNINLJxkstgIT1bZkwxq6W+U8FJPFG1T2ZArn/T87Qg2HDqcnh4G32DU68NkoUp4; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P1oVH-0005uG-3X for keyassure@ietf.org; Fri, 01 Oct 2010 16:54:59 -0600 Message-ID: <4CA666C1.5040100@KingsMountain.com> Date: Fri, 01 Oct 2010 15:54:57 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: keyassure@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 22:54:11 -0000 > asteingruebl@paypal-inc.com said: >> -----Original Message----- >> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On >> Behalf Of Zack Weinberg >> >> As a security researcher and Web browser implementor, I'm fine with >> splitting out policy assertions of the form "always use TLS for this site" >> (which >> are not conceptually tied to any given key). > Agreed. I fully support moving this to another WG. Depending on whether we > believe that there should be a all-purpose policy mechanism, or a > per-protocol/application one, some of this could take place in WebSec. >> But I don't see that it doe anyone any good to define DNS records for key >> fingerprints without also defining what it _means_ for a key's fingerprint >> to appear in the DNS. Client software has to be able to do something with >> that information, after all. If this WG cannot come to any consensus on the >> meaning of a fingerprint record, _in the absence_ of any explicit policy >> records, then we're not doing anything useful. > Agreed. This specific question belongs here. +1 =JeffH Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FAC3A6D01 for ; Fri, 1 Oct 2010 14:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEtwSycE9fhF for ; Fri, 1 Oct 2010 14:42:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3486A3A6B53 for ; Fri, 1 Oct 2010 14:42:34 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o91LhKwm047986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 14:43:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 1 Oct 2010 14:43:19 -0700 To: Zack Weinberg From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:42:35 -0000 At 1:46 PM -0700 10/1/10, Zack Weinberg wrote: >As a security researcher and Web browser implementor, I'm fine with >splitting out policy assertions of the form "always use TLS for this >site" (which are not conceptually tied to any given key). Good. >But I don't >see that it does anyone any good to define DNS records for key >fingerprints without also defining what it _means_ for a key's >fingerprint to appear in the DNS. Fully agree. We have already moved around on this just within our own draft, and having a WG with a consensus process and people contributing text to the WG's draft(s) would be really useful. >Client software has to be able to >do something with that information, after all. If this WG cannot come >to any consensus on the meaning of a fingerprint record, _in the >absence_ of any explicit policy records, then we're not doing anything >useful. Yep. Having a security protocol that doesn't explain its semantics is a waste of time. >I have an opinion about what a fingerprint record should mean, but >I'll save it for a non-meta thread. Keep thinking about contributing text to the eventual WG document! --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA1A3A6B53 for ; Fri, 1 Oct 2010 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK26Uu9Ri8NN for ; Fri, 1 Oct 2010 14:32:22 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id BB63B3A6E49 for ; Fri, 1 Oct 2010 14:32:20 -0700 (PDT) Received: by pvg7 with SMTP id 7so1134285pvg.31 for ; Fri, 01 Oct 2010 14:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=WnVTjxvIUEyQVwXt88ECiPlLtCxSop1CsEqe9OJg9aE=; b=jaDfJye0FNywFC4A6dfMe8Z8ZSykC7xMmtn5au4zdrP0y9jfOKYZGxvu7amosbwej4 2VmmJf3g4g6wLBi8jxfUEp4QVjDNzK9+MbGCFgJT79LsmQklGtok7q/vyCPEBq++Xfpc axVYY0KoATLfDt0++aOR23q+4uCMD5Vrasxl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LncN3jxWf7LKIii7Y7qakdyJd688xQdj4nEhMsc3An5xipXmSwRsxKm2nef/n3hUVk EAdUcXrcazC7gSJ2QJHmXV7KQK67C/bL9v88nKp5WCP4gLgf7ChnedSrEccgrX9XGem4 dkjMMsCgghFNsXuw+Ykkx6BtsZ8MnwZJq7LXo= MIME-Version: 1.0 Received: by 10.114.133.14 with SMTP id g14mr7012912wad.192.1285968789664; Fri, 01 Oct 2010 14:33:09 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.220.191.134 with HTTP; Fri, 1 Oct 2010 14:33:09 -0700 (PDT) In-Reply-To: <1285967068.1984.45.camel@mattlaptop2.local> References: <1285967068.1984.45.camel@mattlaptop2.local> Date: Fri, 1 Oct 2010 14:33:09 -0700 X-Google-Sender-Auth: jMDon6I8RwTqAzsIjTQywFtLsEQ Message-ID: From: Zack Weinberg To: Matt McCutchen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:32:23 -0000 On Fri, Oct 1, 2010 at 2:04 PM, Matt McCutchen wro= te: > On Fri, 2010-10-01 at 13:46 -0700, Zack Weinberg wrote: >> Client software has to be able to >> do something with that information, after all. =C2=A0If this WG cannot c= ome >> to any consensus on the meaning of a fingerprint record, _in the >> absence_ of any explicit policy records, then we're not doing anything >> useful. > > I believe we have consensus that the presence of a DPKIX (or analogous) > record at a name is a positive statement that the key is acceptable for > that name. =C2=A0The disagreement is about whether DPKIX records are > implicitly exclusive when at least one is present (as in > draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be > optionally made exclusive (one approach being to add the functionality > to draft-hallambaker-esrv). This is my personal opinion, and only applies to keys used for HTTPS: I don't think being able to make that positive statement via the DNS is useful by itself. All it does (I think, anyway) is provide an alternative to DV certs. That may be good for the long-run health of the net, but it doesn't make any direct improvement to the security of the web and therefore it's going to be a hard sell to browser vendors. Exclusivity assertions, though, *do* buy you a real security increment: safety against corrupt or coerced CAs issuing rogue certificates, and against blatantly fake certs that users click through anyway. Those (particularly the latter) are real-world problems that browser vendors would love to have immediate-term solutions to. (I wouldn't be surprised if this assessment was true for other application layer protocols as well, but HTTPS is the only one I know well enough to opine for.) zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8F13A6BB0 for ; Fri, 1 Oct 2010 14:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05uSQMjyOKf6 for ; Fri, 1 Oct 2010 14:26:49 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id DC3523A6E2A for ; Fri, 1 Oct 2010 14:26:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=pWmu2y7BrekoqjzUDj7AfAgQF93jR5Zb7dpXOG1kJ+dkwS9rQta8X3IUlsbJ0/tx; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P1n8j-0003OL-It; Fri, 01 Oct 2010 17:27:37 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 1 Oct 2010 17:27:37 -0400 Message-ID: <20190047.1285968457560.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Fri, 1 Oct 2010 16:27:37 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Paul Hoffman , keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688253ace12a523777f9ece3eebd4905388350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:26:50 -0000 Paul and all, I disagree that there is a need to remove policy from this WG discussion as to devise a standard inhearently at some point requires that a policy be determined or arrived at. -----Original Message----- >From: Paul Hoffman >Sent: Oct 1, 2010 3:03 PM >To: keyassure@ietf.org >Subject: [keyassure] Moving policy to a different WG > >Greetings again. The issue of "host security policy" has bedeviled different IETF WGs over the past decade. It means different things to different people, and it has tended to pull WGs into areas where only a few people have strong opinions, although those people also tend to disagree with each other. This is not to say that defining policies is impossible, but it is often time-consuming and the results are not always well-understood even when they work; DKIM is a good example of this. > >Phill's responses today to the current charter shows that there is still a fairly wide rift between different people's views of what policy is wanted and how it should be expressed. Much of the interest in forming this WG was for a single issue that is arguably not policy: which keys and certificates, when given in-band in a security protocol, are to be used by the client. > >Given this rift, I propose that we change the proposed charter again and remove "policy" altogether, and that those interested in being able to express policy in the DNS, secured by DNSSEC, set up their own WG to do this. I say this as someone who will participate in that other WG because there is a piece of policy that I absolutely care about, namely "This site always uses { TLS | IPsec }, don't fall back to unprotected". I agree with Phill that such a policy should not be tied to the key or cert that is being proffered in the current work. > >Splitting key assurance (which most people here seem to understand) from policy (on which there is a lot of disagreement) should allow the two pieces of work to move forwards in different timeframes, with different WG leadership, even though there will be some overlap between participants, just as there is in many Security Area WGs. I assume that it would not be hard to get a "security-policy@ietf.org" mailing list to start discussions of a charter. > >How do others feel about this removal of policy for *this* WG? > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8BE3A6D8B for ; Fri, 1 Oct 2010 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Bk5n4YdxXb for ; Fri, 1 Oct 2010 14:19:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 461AC3A6D32 for ; Fri, 1 Oct 2010 14:19:02 -0700 (PDT) Received: from [128.89.254.114] (port=53706 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P1n1C-000KEj-Tw; Fri, 01 Oct 2010 17:19:51 -0400 Message-Id: <7F7DC427-4C06-42FE-9AAF-64195676DE8F@bbn.com> From: "Richard L. Barnes" To: Jakob Schlyter In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 1 Oct 2010 17:19:49 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:19:10 -0000 I agree with this proposal. --Richard On Oct 1, 2010, at 4:06 PM, Jakob Schlyter wrote: > On 1 okt 2010, at 22.03, Paul Hoffman wrote: > >> How do others feel about this removal of policy for *this* WG? > > I think this would be a reasonable way forward. > > jakob > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E972E3A6E2F for ; Fri, 1 Oct 2010 14:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpfPz82WEla8 for ; Fri, 1 Oct 2010 14:03:41 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 4A7F03A6D5D for ; Fri, 1 Oct 2010 14:03:41 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 533B7578073; Fri, 1 Oct 2010 14:04:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=M2h4nj/1RJM0n868rftTQheys1lIxTZsZ03ux3N1jCp qo8QtwugglSjLh/2DOa+D8kmVEpB9j2VVO+eAGitzKnLxt/K2abxcmgikRNfHVYy mlobNAVnA6R4TeoqSeUHWxLZAUsK2E8nJv4N2mMUYBEWzAZzg9Q7wzwF/XqqMOyE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=SM3CjXTGX8wjR7kQEHHD7GSatN0=; b=Zu2k0HfIyz LLo4Hjunbjoqt7OaVdoVlsmU3Dfxfjr/HjP5QP3a9lnhqEgr45cO0pH4isQK2Z2T OblufJ5FwudKzlmuGPf+Dmb0Il7QZS3/PUX0EnfM3NkmkxfASUFVgTziumsDqrFf uzFsEu13ZVBGlpGmt+RkLFFiK6wYbsMVk= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id AA07757806C; Fri, 1 Oct 2010 14:04:29 -0700 (PDT) From: Matt McCutchen To: Zack Weinberg In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Oct 2010 17:04:28 -0400 Message-ID: <1285967068.1984.45.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:03:43 -0000 On Fri, 2010-10-01 at 13:46 -0700, Zack Weinberg wrote: > On Fri, Oct 1, 2010 at 1:03 PM, Paul Hoffman wrote: > [...] > > Phill's responses today to the current charter shows that there is still a fairly wide > > rift between different people's views of what policy is wanted and how it should > > be expressed. Much of the interest in forming this WG was for a single issue that > > is arguably not policy: which keys and certificates, when given in-band in a > > security protocol, are to be used by the client. > > As an interested observer, an awful lot of the argument on this list > seems to be over > whether or not that is a policy issue. Right. > But I don't > see that it does anyone any good to define DNS records for key > fingerprints without also defining what it _means_ for a key's > fingerprint to appear in the DNS. Indeed, the existing CERT subtypes do just that. > Client software has to be able to > do something with that information, after all. If this WG cannot come > to any consensus on the meaning of a fingerprint record, _in the > absence_ of any explicit policy records, then we're not doing anything > useful. I believe we have consensus that the presence of a DPKIX (or analogous) record at a name is a positive statement that the key is acceptable for that name. The disagreement is about whether DPKIX records are implicitly exclusive when at least one is present (as in draft-hoffman-keys-linkage-from-dns) or otherwise about how they can be optionally made exclusive (one approach being to add the functionality to draft-hallambaker-esrv). -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906B43A6E3E for ; Fri, 1 Oct 2010 14:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BupCiJ7+Vne for ; Fri, 1 Oct 2010 14:01:52 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id 0ED9C3A6B3F for ; Fri, 1 Oct 2010 14:01:51 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=riTDGTWZRFgPe9PMnOzlldHnhnWMVt8y8Pyx2Lel6OjLOlkFi2A6uQcx LalLrP08bHjpk+TAtrV9Uh1a/FxXDdL5NIlryaxzMHLFHZDq3LVBB4m9c q/m89nqrz+2JC34; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1285966961; x=1317502961; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Zack=20Weinberg=20, =20Paul=20Hoffman=0D=0A=09|CC:=20" keyassure@ietf.org"=20|Date:=20Fri, =201=20Oct=202010=2015:02:39=20-0600|Subject:=20RE:=20[ke yassure]=20Moving=20policy=20to=20a=20different=20WG |Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABEB013B941 2@DEN-MEXMS-001.corp.ebay.com>|References:=20=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=h66D9pzj4Sw1GCSha4zLObujLyKYTwJ7ITnX2CG/ZVE=; b=K3019Sbg5xUApJmTh6OLQfAM4e3n2nyWgDwXtIKuSu26Cnvs+NE4/1ea eKXRpimwBuPxTm5kaU0usNqtZ5ADOxHVhBQt89xApgnmykbEwG4lkGL7j fWU9gFsE3YU5mM+; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.57,268,1283756400"; d="scan'208";a="72354069" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 01 Oct 2010 14:02:40 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Fri, 1 Oct 2010 15:02:40 -0600 From: "Steingruebl, Andy" To: Zack Weinberg , Paul Hoffman Date: Fri, 1 Oct 2010 15:02:39 -0600 Thread-Topic: [keyassure] Moving policy to a different WG Thread-Index: ActhqjDB4nbnyKNKTWe/MN1ZqO2h6wAAZs6Q Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB013B9412@DEN-MEXMS-001.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 21:01:54 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Zack Weinberg >=20 > As a security researcher and Web browser implementor, I'm fine with > splitting out policy assertions of the form "always use TLS for this site= " (which > are not conceptually tied to any given key). =20 Agreed. I fully support moving this to another WG. Depending on whether w= e believe that there should be a all-purpose policy mechanism, or a per-pro= tocol/application one, some of this could take place in WebSec. >But I don't see that it does > anyone any good to define DNS records for key fingerprints without also > defining what it _means_ for a key's fingerprint to appear in the DNS. C= lient > software has to be able to do something with that information, after all.= If > this WG cannot come to any consensus on the meaning of a fingerprint > record, _in the absence_ of any explicit policy records, then we're not d= oing > anything useful. Agreed. This specific question belongs here. - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DEF3A6E66 for ; Fri, 1 Oct 2010 13:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPhgdFEfWz1i for ; Fri, 1 Oct 2010 13:46:09 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 411E63A6E8A for ; Fri, 1 Oct 2010 13:46:09 -0700 (PDT) Received: by pwi3 with SMTP id 3so1137571pwi.31 for ; Fri, 01 Oct 2010 13:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=m5BINuZ7x9t49Qu2TmuBeFxwuVebU6WhsMA4cSdqZ8w=; b=IeuD8Pr995h77KD7PQCS4eKlOWKJog0/L+HlS9R55/0c8/7RM7fEXdiPhkIEVnFcNp mDHivBahNT4hllF6GA2NAdlHrORrXpZ6k6WIQi9h7k+euQ3WMTeK/BffwyX+Dre0C5lg adb48LlvFoY3qyOH5W1l03shFHFhOniwXH2ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=C9gE3vbgxAykZvkYdekz2ks8uu590WbVoRHKR8rhu9nh0EDl9ZF7TKZ1s6Pw2LaX+T fIY4HyFghcopVKlSvmKMhJzsYsJ4LcAHpxxenwk1TfZsTc3JARme2H/6gGl8IypblTLT hsXcWJE1ElC5nCAkWsFmVlACOY0Qbl/0SZsiM= MIME-Version: 1.0 Received: by 10.114.88.17 with SMTP id l17mr6983682wab.145.1285966018123; Fri, 01 Oct 2010 13:46:58 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.220.191.134 with HTTP; Fri, 1 Oct 2010 13:46:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Oct 2010 13:46:57 -0700 X-Google-Sender-Auth: sho8sGo3u27CM0dE9bP8jqP_ItI Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:46:10 -0000 On Fri, Oct 1, 2010 at 1:03 PM, Paul Hoffman wrote: [...] > Phill's responses today to the current charter shows that there is still a fairly wide > rift between different people's views of what policy is wanted and how it should > be expressed. Much of the interest in forming this WG was for a single issue that > is arguably not policy: which keys and certificates, when given in-band in a > security protocol, are to be used by the client. As an interested observer, an awful lot of the argument on this list seems to be over whether or not that is a policy issue. As a security researcher and Web browser implementor, I'm fine with splitting out policy assertions of the form "always use TLS for this site" (which are not conceptually tied to any given key). But I don't see that it does anyone any good to define DNS records for key fingerprints without also defining what it _means_ for a key's fingerprint to appear in the DNS. Client software has to be able to do something with that information, after all. If this WG cannot come to any consensus on the meaning of a fingerprint record, _in the absence_ of any explicit policy records, then we're not doing anything useful. I have an opinion about what a fingerprint record should mean, but I'll save it for a non-meta thread. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A483A6D08 for ; Fri, 1 Oct 2010 13:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Upu-k2s+XPt1 for ; Fri, 1 Oct 2010 13:35:43 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id B2DE83A6E1E for ; Fri, 1 Oct 2010 13:35:43 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id E840C598070; Fri, 1 Oct 2010 13:36:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=vdFMJdRO5+9BN2MVavQ53bzJGutLFYUpehlhrzeD6v8 /2zuM+59v6GThxEnArgIKoxVLuwWk8dKZ6iHztvV8ydZVTxMvo1iCHwqvTCDToAR ahFL/7iiZ1hXshxWwxDwphaUbl5QYA/PEOfUS4rA8FZ5hGqoinnX/7uI9Id3nlkU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=T6PjrZ1DSRB01h9iHl4pFMAmxJM=; b=We61XcmaXk zTEaQhc3K/DMNRbXoHGHEvbh4I7PAOYYk5cg1QMzOJU6p5NjeE0YZqB88uDykHDc fllpYMNHN027GpAKX8iw8/PhUKVFJNdKImS8u0R6MaybTewlpe1g/AjYpK+19q2i SXh8OV+HKEGyIr4hPk6VrhghSIhWX6gQ8= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id 9C61459806B; Fri, 1 Oct 2010 13:36:31 -0700 (PDT) From: Matt McCutchen To: Paul Hoffman In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 01 Oct 2010 16:36:30 -0400 Message-ID: <1285965390.1984.34.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:35:44 -0000 On Fri, 2010-10-01 at 13:03 -0700, Paul Hoffman wrote: > Phill's responses today to the current charter shows that there is > still a fairly wide rift between different people's views of what > policy is wanted and how it should be expressed. Much of the interest > in forming this WG was for a single issue that is arguably not policy: > which keys and certificates, when given in-band in a security > protocol, are to be used by the client. > > Given this rift, I propose that we change the proposed charter again > and remove "policy" altogether, and that those interested in being > able to express policy in the DNS, secured by DNSSEC, set up their own > WG to do this. I say this as someone who will participate in that > other WG because there is a piece of policy that I absolutely care > about, namely "This site always uses { TLS | IPsec }, don't fall back > to unprotected". I agree with Phill that such a policy should not be > tied to the key or cert that is being proffered in the current work. It seems clear that mandatory use of TLS/IPSEC is outside the scope of DNSSEC key assurance per se. The disagreement is over the possible exclusivity of DNSSEC key assurance. IIUC, you are including it in the "single issue that is arguably not policy: which keys and certificates, when given in-band in a security protocol, are to be used by the client", while Phill argues that it constitutes policy and should be treated along with other policy: http://www.ietf.org/mail-archive/web/pkix/current/msg28410.html I am happy either way, as long as the exclusivity gets standardized without undue delay. While the improved security of exclusive DNSSEC key assurance is arguably the most important benefit of what we are doing, Phill has pointed out that some admins might want to take advantage of the convenience of DNSSEC key assurance without committing to using it exclusively, so I think the exclusivity should be optional (i.e., a flag). -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59523A6E1E for ; Fri, 1 Oct 2010 13:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ0qr+K0qm26 for ; Fri, 1 Oct 2010 13:05:41 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D89513A6E1B for ; Fri, 1 Oct 2010 13:05:40 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D61641ECB408 for ; Fri, 1 Oct 2010 20:06:28 +0000 (UTC) Date: Fri, 1 Oct 2010 16:06:27 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20101001200627.GB14142@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:05:41 -0000 On Fri, Oct 01, 2010 at 01:03:05PM -0700, Paul Hoffman wrote: > How do others feel about this removal of policy for *this* WG? It seems to me that if we want to get any work done, it would be a good idea. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BF93A6E04 for ; Fri, 1 Oct 2010 13:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm9hP11EN7Ad for ; Fri, 1 Oct 2010 13:05:35 -0700 (PDT) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id BD2853A6D5A for ; Fri, 1 Oct 2010 13:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=7Z2Bu6L+/vt2anSdTxK6oucH7bXq9Ha87Lw+rGn2z9U=; b=x4BRxnBMsoK8ppHt3BVFJ9lahp3NeMwMbgmZFuTJU1oNBXns6quC7YoyYP4tpybI2idZyvJKeL4xD z3GcpQnSI8UxXQtqdI8S2k74wbjDF57pAkaWAioYoIQpYJLtXR42oxD6BeBxOocECOPhjv3kueFDVB lKmgAptidofNJurk= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 1 Oct 2010 22:06:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Fri, 1 Oct 2010 22:06:19 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:05:36 -0000 On 1 okt 2010, at 22.03, Paul Hoffman wrote: > How do others feel about this removal of policy for *this* WG? I think this would be a reasonable way forward. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55D33A6DFF for ; Fri, 1 Oct 2010 13:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbZyo0XTmO7v for ; Fri, 1 Oct 2010 13:02:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 167233A6D5A for ; Fri, 1 Oct 2010 13:02:49 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o91K3cSm043725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Oct 2010 13:03:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 1 Oct 2010 13:03:05 -0700 To: keyassure@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [keyassure] Moving policy to a different WG X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 20:02:51 -0000 Greetings again. The issue of "host security policy" has bedeviled different IETF WGs over the past decade. It means different things to different people, and it has tended to pull WGs into areas where only a few people have strong opinions, although those people also tend to disagree with each other. This is not to say that defining policies is impossible, but it is often time-consuming and the results are not always well-understood even when they work; DKIM is a good example of this. Phill's responses today to the current charter shows that there is still a fairly wide rift between different people's views of what policy is wanted and how it should be expressed. Much of the interest in forming this WG was for a single issue that is arguably not policy: which keys and certificates, when given in-band in a security protocol, are to be used by the client. Given this rift, I propose that we change the proposed charter again and remove "policy" altogether, and that those interested in being able to express policy in the DNS, secured by DNSSEC, set up their own WG to do this. I say this as someone who will participate in that other WG because there is a piece of policy that I absolutely care about, namely "This site always uses { TLS | IPsec }, don't fall back to unprotected". I agree with Phill that such a policy should not be tied to the key or cert that is being proffered in the current work. Splitting key assurance (which most people here seem to understand) from policy (on which there is a lot of disagreement) should allow the two pieces of work to move forwards in different timeframes, with different WG leadership, even though there will be some overlap between participants, just as there is in many Security Area WGs. I assume that it would not be hard to get a "security-policy@ietf.org" mailing list to start discussions of a charter. How do others feel about this removal of policy for *this* WG? --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 626FC3A6918 for ; Fri, 1 Oct 2010 10:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAtxA+-nANvz for ; Fri, 1 Oct 2010 10:54:10 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id D67593A6DAC for ; Fri, 1 Oct 2010 10:54:09 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id DCAC722849E4; Fri, 1 Oct 2010 13:54:21 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id A8750228481E; Fri, 1 Oct 2010 13:54:20 -0400 (EDT) Message-Id: <15A9EC4B-D5A0-4E02-96F9-E91559BFD228@kumari.net> From: Warren Kumari To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 1 Oct 2010 13:54:56 -0400 References: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 17:54:11 -0000 On Oct 1, 2010, at 9:56 AM, Phillip Hallam-Baker wrote: > Ilari's position is completely reasonable here. We have not yet > demonstrated the practicality of any approach to security policy and > we are building on an infrastructure (DNSSEC) that is still in > deployment phase. Thats true -- as we have not "demonstrated the practicality of any approach to security policy" I am leaning more and more to making the charter as specific as possible, and not opening the "security policy" door at all... > > That is why I do not want the charter to be tied to any specific > approach, mine included. > > > The point I was trying to make was that forced to chose between a > certificate type that works for TLS+IPSEC+S/MIME+SSH and one that > works for X.509+PGP+SPKI, I would choose the first, i.e. we would > have: > > CERT APKIX .... > CERT APGP .... > CERT ASPKI .... > > But that is if I am forced to choose. I would prefer > > CERT ASSERT 0 0 > > Which is completely general. Can you please try draft text that explains that in a short and concise and *specific* manner? We keep coming back to the "security policy" bit, and it seems as though A: most of the participant have a different view than yours, B: your definition is vague and / or changing and / or C: poorly defined / overly broad.... > > > What I do not want is for these decisions to be made in the charter. Oh, but what we REALLY don't want is to have a charter that is so broad that: A: It never gets agreed to (which is what is happening here -- we have been trying to limit the scope, but have slowly increased it to try accommodate your suggestions and views). B: the working group gets bogged down (like the mailing list has been) and forward process is thwarted. A tightly bounded and specific charter that allows us to move forward, do a bit of work and then A: conclude or B: recharter seems preferable -- "launch and iterate" approach vs "extended kvetching". I really appreciate your experience, insight, passion and knowledge, but it seems more and more as though the list's view and your view's on what we are trying to accomplish differ and that these may be irreconcilable differences. One possible option is that the security policy parts could be included in a different RR and worked on as an individual submission and / or in a different group... W > > > On Fri, Oct 1, 2010 at 8:05 AM, Ilari Liusvaara > wrote: > On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote: > > > > The policy mechanism should be orthogonal to the keying mechanism. > > > > Existing experience of security policy ties the policy to > protocols and not > > keys. Security policies are of the form 'must use SSL when using > HTTP at > > example.com' and 'must use SSL with key conforming to trust > criteria X when > > using HTTP...' > > I'm not a fan of security policies in DNS. I would like more to see > facts, > like: > > * Client can upgrade the connection (to this or that) after connecting > for this service (downgrade-attack-free upgrades) > * Client can connect securely (using this or that) to this service > (it will sniff the connection type) > * Client can obtain equivalent secure service (using this or that) > from > that service (service redirect) > > * This service supports security, client MAY use it. > * This service is sensitive, client SHOULD use security. > * This service doesn't yield useful nonsecure service, client MUST use > security. > > * The certificate will chain to one of these TAs. > > Of course, the client is free to ignore this, but it will do so on > peril > of itself and its user. > > This is pretty much everything one needs to have secure connection. > One can > then send actual (protocol dependent) policy (securely) via that. > > > I don't see any particular reason to separate TLS and non TLS > protocols > > either. So far the only aspects of the protocol that are tied to > TLS are the > > 'cert enumeration' mechanism and the cert type identifier. > > I thought the idea was to form some "core" with some free > "parameters" and > then instantiate that for each protocol. > > Anyway, spec for TLS can be transformed into spec for IPSEC with > little > search-and-replace. > > > Given the choice, I would much prefer a key assurance mechanism that > > supports any security protocol but only works with X.509 certs > than one the > > only works with TLS but has the option of using additional cert > formats that > > are either essentially historic or make no real sense in the > context of a > > hierarchical naming structure (PGP). > > I think OpenPGP would make great sense here. Its way simpler if you > just > need key container for TLS (since TLS doesn't have "raw key cert" > format). > > -Ilari > > > > -- > Website: http://hallambaker.com/ > -- Outside of a dog, a book is your best friend, and inside of a dog, it's too dark to read Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB8E3A6C83 for ; Fri, 1 Oct 2010 07:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuTeqm+N1L62 for ; Fri, 1 Oct 2010 07:46:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4E4993A6C1C for ; Fri, 1 Oct 2010 07:46:46 -0700 (PDT) Received: by wyi11 with SMTP id 11so3520878wyi.31 for ; Fri, 01 Oct 2010 07:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pOyhWFipWyII2qq2THCQG2NUr0n5SrXVJHiSmPeE2yU=; b=J1OxFfxAhQYLhOOeQIzLGSy8k5p8fbKhqARg6Wuz/uZSF60jR50apbW13t081Tn/RB 8sFEiL+iDKcIevHTsOunFRKjbC75CLoTomjHHuAAOT6Xtg/cVivKlqXl3HuPWmP2ZAfI 5KxW/sPJJbmFVs+5WbrCVb2AGicl4va3GU6zM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SXVB8ReFI5dsgplpSnH2uLxx7zlS+hG6lAZofdW+ez/JcrTpaHPZYBXBcWKjM53AEC otY/6eQC7fBsGclAbfj4pDZEqJOlXBY6ozzIjPGn+Arej/ICtPjrdOOrZ43MDW9055ui K2lP0bcSV1Hkn5mGkBjcOoZhmCP5i27XVRT2w= MIME-Version: 1.0 Received: by 10.216.153.140 with SMTP id f12mr2188094wek.111.1285944453898; Fri, 01 Oct 2010 07:47:33 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 07:47:33 -0700 (PDT) In-Reply-To: <20101001142352.GT8669@shinkuro.com> References: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> <20101001142352.GT8669@shinkuro.com> Date: Fri, 1 Oct 2010 10:47:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e65b54dc60274104918f46a5 Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 14:46:47 -0000 --0016e65b54dc60274104918f46a5 Content-Type: text/plain; charset=ISO-8859-1 If you believe that then tie the charter to the proven approach as used in DKIM and policymaker and every other Security Policy scheme. If you believe that then tie the charter to the approach that gives the clean API. Having recently shepherded three drafts through the IESG to RFC-EDITOR state, the issues that they have been concerned with are consistency of architectural approach, separation of concerns and that the group understands the security considerations and has deployed all relevant controls. On that basis, I don't think the IESG is going to be impressed by a charter that is written to force adoption of the cert enumeration approach. On Fri, Oct 1, 2010 at 10:23 AM, Andrew Sullivan wrote: > On Fri, Oct 01, 2010 at 09:56:23AM -0400, Phillip Hallam-Baker wrote: > > That is why I do not want the charter to be tied to any specific > approach, > > mine included. > > Over on the homegate list, an open-ended, unfocussed charter of that > type was just rejected on the very grounds that it's too open-ended, > unfocussed, unclear, and unconstrained. > > My lesson from that discussion is that the current IESG wants specific > deliverables in charters. > > Therefore, if we don't tie to specific approaches, we'll get nowhere > except wandering in the wilderness. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e65b54dc60274104918f46a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you believe that then tie the charter to the proven approach as used in = DKIM and policymaker and every other Security Policy scheme.

=
If you believe that then tie=A0the charter to = the approach that gives the clean API.


Having recently shepherded three drafts = through the IESG to RFC-EDITOR state, the issues that they have been concer= ned with are consistency of architectural approach, separation of concerns = and that the group understands the security considerations and has deployed= all relevant controls.

On that basis, I don't think the IESG is going to b= e impressed by a charter that is written to force adoption of the cert enum= eration approach.



On Fri, Oct 1, 2010 at 10:23 AM, Andrew Sullivan <ajs@shinkuro.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
On Fri, Oct 01, 2010 at 09:56:23AM -0400, Phillip Hallam-= Baker wrote:
> That is why I do not want the charter to be tied to any specific appro= ach,
> mine included.

Over on the homegate list, an open-ended, unfocussed charter of that<= br> type was just rejected on the very grounds that it's too open-ended, unfocussed, unclear, and unconstrained.

My lesson from that discussion is that the current IESG wants specific
deliverables in charters.

Therefore, if we don't tie to specific approaches, we'll get nowher= e
except wandering in the wilderness.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
__________________________________= _____________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



--
Website: http://hallambaker.com/

--0016e65b54dc60274104918f46a5-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333F33A6C63 for ; Fri, 1 Oct 2010 07:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.009 X-Spam-Level: X-Spam-Status: No, score=-102.009 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m09-KBfTKBs for ; Fri, 1 Oct 2010 07:23:15 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C2F753A6F4D for ; Fri, 1 Oct 2010 07:23:06 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B636A1ECB408 for ; Fri, 1 Oct 2010 14:23:54 +0000 (UTC) Date: Fri, 1 Oct 2010 10:23:53 -0400 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20101001142352.GT8669@shinkuro.com> References: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 14:23:16 -0000 On Fri, Oct 01, 2010 at 09:56:23AM -0400, Phillip Hallam-Baker wrote: > That is why I do not want the charter to be tied to any specific approach, > mine included. Over on the homegate list, an open-ended, unfocussed charter of that type was just rejected on the very grounds that it's too open-ended, unfocussed, unclear, and unconstrained. My lesson from that discussion is that the current IESG wants specific deliverables in charters. Therefore, if we don't tie to specific approaches, we'll get nowhere except wandering in the wilderness. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AFBB3A6C9E for ; Fri, 1 Oct 2010 06:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD+YHJ0X88R2 for ; Fri, 1 Oct 2010 06:55:43 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B19473A6F16 for ; Fri, 1 Oct 2010 06:55:35 -0700 (PDT) Received: by wwj40 with SMTP id 40so976598wwj.13 for ; Fri, 01 Oct 2010 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wu7gQZ0KfSZH6uROOtQ1xDiUE7g4SIRImjNk0X6YzJo=; b=JPg3XoZMKvQ+CtpPTWbWTiy7XqBZHLc1HYw1B6kvp8+KaLUSZPhxomUmAdEvPmPo9R Ou+nzqxQgkWdtf+DTIa2sA/Txye3wFyz6diwoS9kNXSc8SiSO+Mf3OnUnAfKZvBG1G1R R71/N+CuwvAnwXuJz9KjFuokioT2r9GyD5PnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iWJWq586n5r/KarrVwLOP2+ATUiUwBFqa4Z93iV1RxrPNmZwNfkexwp1M7NN0IeG96 oMT5iKy6QxnyRiGzWAMoSK0VLkbsjtJRq5aXV8DdQhagBfjEMAqOHdApKjOHBPHbyOuk oRALzCC2eA1C8qjladQzmEe7jvsFUnI4geySc= MIME-Version: 1.0 Received: by 10.216.161.71 with SMTP id v49mr4473061wek.94.1285941383440; Fri, 01 Oct 2010 06:56:23 -0700 (PDT) Received: by 10.216.166.9 with HTTP; Fri, 1 Oct 2010 06:56:23 -0700 (PDT) In-Reply-To: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> References: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 1 Oct 2010 09:56:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001636416b975ca81804918e8f94 Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 13:55:48 -0000 --001636416b975ca81804918e8f94 Content-Type: text/plain; charset=ISO-8859-1 Ilari's position is completely reasonable here. We have not yet demonstrated the practicality of any approach to security policy and we are building on an infrastructure (DNSSEC) that is still in deployment phase. That is why I do not want the charter to be tied to any specific approach, mine included. The point I was trying to make was that forced to chose between a certificate type that works for TLS+IPSEC+S/MIME+SSH and one that works for X.509+PGP+SPKI, I would choose the first, i.e. we would have: CERT APKIX .... CERT APGP .... CERT ASPKI .... But that is if I am forced to choose. I would prefer CERT ASSERT 0 0 Which is completely general. What I do not want is for these decisions to be made in the charter. On Fri, Oct 1, 2010 at 8:05 AM, Ilari Liusvaara wrote: > On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote: > > > > The policy mechanism should be orthogonal to the keying mechanism. > > > > Existing experience of security policy ties the policy to protocols and > not > > keys. Security policies are of the form 'must use SSL when using HTTP at > > example.com' and 'must use SSL with key conforming to trust criteria X > when > > using HTTP...' > > I'm not a fan of security policies in DNS. I would like more to see facts, > like: > > * Client can upgrade the connection (to this or that) after connecting > for this service (downgrade-attack-free upgrades) > * Client can connect securely (using this or that) to this service > (it will sniff the connection type) > * Client can obtain equivalent secure service (using this or that) from > that service (service redirect) > > * This service supports security, client MAY use it. > * This service is sensitive, client SHOULD use security. > * This service doesn't yield useful nonsecure service, client MUST use > security. > > * The certificate will chain to one of these TAs. > > Of course, the client is free to ignore this, but it will do so on peril > of itself and its user. > > This is pretty much everything one needs to have secure connection. One can > then send actual (protocol dependent) policy (securely) via that. > > > I don't see any particular reason to separate TLS and non TLS protocols > > either. So far the only aspects of the protocol that are tied to TLS are > the > > 'cert enumeration' mechanism and the cert type identifier. > > I thought the idea was to form some "core" with some free "parameters" and > then instantiate that for each protocol. > > Anyway, spec for TLS can be transformed into spec for IPSEC with little > search-and-replace. > > > Given the choice, I would much prefer a key assurance mechanism that > > supports any security protocol but only works with X.509 certs than one > the > > only works with TLS but has the option of using additional cert formats > that > > are either essentially historic or make no real sense in the context of a > > hierarchical naming structure (PGP). > > I think OpenPGP would make great sense here. Its way simpler if you just > need key container for TLS (since TLS doesn't have "raw key cert" format). > > -Ilari > -- Website: http://hallambaker.com/ --001636416b975ca81804918e8f94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ilari's position is completely reasonable here. We have not yet demonst= rated the practicality of any approach to security policy and we are buildi= ng on an infrastructure (DNSSEC) that is still in deployment phase.

That is why I do not want the charter to be tied to any specific appro= ach, mine included.


The point I was= trying to make was that forced to chose between a certificate type that wo= rks for TLS+IPSEC+S/MIME+SSH and one that works for X.509+PGP+SPKI, I would= choose the first, i.e. we would have:

CERT APKIX ....
CERT APGP ....
CERT= ASPKI ....

But that is if I am forced to choose. = I would prefer

CERT ASSERT 0 0 <AlgID> <C= ertID> <Digest>

Which is completely general.

<= br>
What I do not want is for these decisions to be made in the c= harter.


On Fri, Oct= 1, 2010 at 8:05 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> w= rote:
On Fri, Oct 01, 2010 at 0= 1:16:24AM -0400, Phillip Hallam-Baker wrote:
>
> The policy mechanism should be orthogonal to the keying mechanism.
>
> Existing experience of security policy ties the policy to protocols an= d not
> keys. Security policies are of the form 'must use SSL when using H= TTP at
> example.com' = and 'must use SSL with key conforming to trust criteria X when
> using HTTP...'

I'm not a fan of security policies in DNS. I would like more to s= ee facts,
like:

* Client can upgrade the connection (to this or that) after connecting
for this service (downgrade-attack-free upgrades)
* Client can connect securely (using this or that) to this service
(it will sniff the connection type)
* Client can obtain equivalent secure service (using this or that) from
that service (service redirect)

* This service supports security, client MAY use it.
* This service is sensitive, client SHOULD use security.
* This service doesn't yield useful nonsecure service, client MUST use<= br> security.

* The certificate will chain to one of these TAs.

Of course, the client is free to ignore this, but it will do so on peril of itself and its user.

This is pretty much everything one needs to have secure connection. One can=
then send actual (protocol dependent) policy (securely) via that.

> I don't see any particular reason to separate TLS and non TLS prot= ocols
> either. So far the only aspects of the protocol that are tied to TLS a= re the
> 'cert enumeration' mechanism and the cert type identifier.

I thought the idea was to form some "core" with some free &= quot;parameters" and
then instantiate that for each protocol.

Anyway, spec for TLS can be transformed into spec for IPSEC with little
search-and-replace.

> Given the choice, I would much prefer a key assurance mechanism that > supports any security protocol but only works with X.509 certs than on= e the
> only works with TLS but has the option of using additional cert format= s that
> are either essentially historic or make no real sense in the context o= f a
> hierarchical naming structure (PGP).

I think OpenPGP would make great sense here. Its way simpler if you j= ust
need key container for TLS (since TLS doesn't have "raw key cert&q= uot; format).

-Ilari



--
Website: http://hallambaker.com/

--001636416b975ca81804918e8f94-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D723A6E35 for ; Fri, 1 Oct 2010 05:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRZexrGGBxnw for ; Fri, 1 Oct 2010 05:59:20 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 214C33A6C9D for ; Fri, 1 Oct 2010 05:59:20 -0700 (PDT) Received: from [192.168.0.221] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id EF4BB228481E; Fri, 1 Oct 2010 08:59:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Fri, 1 Oct 2010 09:00:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A5324FF-4409-4DFF-83E9-D326E6E9BE26@kumari.net> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:59:21 -0000 Will respond more fully later, but wanted to at least start responding = before heading in to office. On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker wrote: > I have asked on three separate occasions to have the ESRV draft added = to the list of possible starting points: >=20 > Possible starting points for these deliverables include = draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, = draft-josefsson-keyassure-tls and draft-hallambaker-esrv >=20 >=20 Apologies, done. >=20 >=20 > If we are doing security policy we should look at all the proposals. >=20 >=20 > The charter as written is of the form 'here is a technology, we want a = WG to turn it into a standard'. While that is the right approach when = there is significant experience of using actual code, we are not in that = position here.=20 >=20 > In particular I disagree with the following: >=20 > The group will also investigate publishing security policies that are = related to the use of keying material in the DNS, such as whether = communications must be cryptographically protected. >=20 > Please remove " that are related to the use of keying material" Can you please try and limit this a bit? I had initially written it = without that phrase, but then realized that that also opened the door to = talking about how high a fence should be around your datacenter and that = you shouldn't write your password on a sticky on your monitor... One of = the major sticking points on these discussions has been: A: if policy should be included at all (and, my reading is that the = majority of folk think that it shouldn't) B: if it is, what all should be allowed. Just saying "publishing security policies in the DNS" is entirely too = broad...=20 >=20 > The policy mechanism should be orthogonal to the keying mechanism. >=20 > Existing experience of security policy ties the policy to protocols = and not keys. Security policies are of the form 'must use SSL when using = HTTP at example.com' and 'must use SSL with key conforming to trust = criteria X when using HTTP...' >=20 > Absent extensive experience of tying policy to keys and a = demonstration of clear benefits resulting from that approach, the = charter should leave that choice open. >=20 > I don't see any particular reason to separate TLS and non TLS = protocols either. So far the only aspects of the protocol that are tied = to TLS are the 'cert enumeration' mechanism and the cert type = identifier. >=20 > Given the choice, I would much prefer a key assurance mechanism that = supports any security protocol but only works with X.509 certs than one = the only works with TLS but has the option of using additional cert = formats that are either essentially historic or make no real sense in = the context of a hierarchical naming structure (PGP). >=20 Yes, you've made that clear --- however, you are not the only person = participating. Keep in mind that I haven't had my morning coffee yet, = and so am extra grumpy -- We have been trying really hard to come to a = compromise on many of these points, but I'm beginning to think that we = are just not going to be able to make you happy. We have been trying to = move things forward, but it feels like you are intentionally being = obstructionistic. >=20 > I find the milestones to be entirely unrealistic.=20 >=20 > It will take considerably longer than June 2011 to have any draft with = the cert enumeration semantics contained in it ready for the IESG. It = would be somewhat optimistic to expect to have a draft with only the key = assurance semantics ready in that time, and that is work we have twenty = years experience doing at this point. >=20 >=20 > The natural place to break the problem is between key assurance and = security policy. That is, along the major functional lines. >=20 > I would anticipate the final document set looking something like >=20 > * Key Assurance Mechanism > * Use of Key Assurance Cert Type with HTTP/TLS > * DNS Security Policy Mechanism=20 > * Use of Security Policy with HTTP > * Use of Security Policy with SMTP, POP3, IMAP While the final document set may or may not look like that, having a few = items and then rechartering may allow us to actually get some things = done...=20 When rechartering we can look at increasing or decreasing the scope --- = forming while saying "And we'll poke at a whole bunch of other WGs = space" is yet another obstacle to getting formed... >=20 > For each of the 'Mechanism' documents I would anticipate an effective = 3 step process of Experimental, Proposed, Standard. >=20 > For the Use documents I would anticipate a 2 step process starting at = Proposed and going to Standard. >=20 > If Russ' 2 step proposal goes through then the final step would be = 'Full Standard' otherwise it will most likely be 'Draft'. >=20 >=20 > I would also leave open the possibility that there may be multiple = experimental mechanism documents in the case that there is no agreement = before test deployments start.=20 >=20 The possibility of multiple experimental mechanism documents is still = open -- work can happen that isn't listed in the milestones, but I do = not think that we *need* to do multiple for all docs... > The reason I propose using the experimental step is that I want to = start real world trials as soon as possible and want the results of = those trials to feed into the Proposed Standard. And to do trials, I = would like to have possible production code points assigned. >=20 > Based on previous IETF experience, three years for getting the = documents of this type to Proposed Standard is rather more realistic = than the schedules proposed. Yes, the milestones were intended to be aggressive, and I think that we = could meet them if folk are willing to ignore distraction / disruptions. W (who still hasn't had his coffee). Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567B93A6EEB for ; Fri, 1 Oct 2010 05:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmxiqrrH9JBo for ; Fri, 1 Oct 2010 05:12:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CD3773A72C7 for ; Fri, 1 Oct 2010 05:10:47 -0700 (PDT) Received: from [128.89.254.186] (port=51822 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P1eSb-0009Fd-HE; Fri, 01 Oct 2010 08:11:35 -0400 Message-Id: <02565C55-AA4F-44C3-8587-31056A97989D@bbn.com> From: "Richard L. Barnes" To: Phillip Hallam-Baker In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2-537730953 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 1 Oct 2010 08:11:32 -0400 References: X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 12:12:21 -0000 --Apple-Mail-2-537730953 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I would support striking this sentence, which is the only mention of the word "privacy": "The group will also investigate publishing security policies that are related to the use of keying material in the DNS, such as whether communications must be cryptographically protected." This is not a policy group, it's a domain-to-key binding group. Policy, as I've said before, is the domain of the applications. --Richard On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker wrote: > I have asked on three separate occasions to have the ESRV draft > added to the list of possible starting points: > > Possible starting points for these deliverables include draft- > hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, draft- > josefsson-keyassure-tls and draft-hallambaker-esrv > > > > > > > > If we are doing security policy we should look at all the proposals. > > > The charter as written is of the form 'here is a technology, we want > a WG to turn it into a standard'. While that is the right approach > when there is significant experience of using actual code, we are > not in that position here. > > In particular I disagree with the following: > > The group will also investigate publishing security policies that > are related to the use of keying material in the DNS, such as > whether communications must be cryptographically protected. > > Please remove " that are related to the use of keying material" > > > The policy mechanism should be orthogonal to the keying mechanism. > > Existing experience of security policy ties the policy to protocols > and not keys. Security policies are of the form 'must use SSL when > using HTTP at example.com' and 'must use SSL with key conforming to > trust criteria X when using HTTP...' > > Absent extensive experience of tying policy to keys and a > demonstration of clear benefits resulting from that approach, the > charter should leave that choice open. > > I don't see any particular reason to separate TLS and non TLS > protocols either. So far the only aspects of the protocol that are > tied to TLS are the 'cert enumeration' mechanism and the cert type > identifier. > > Given the choice, I would much prefer a key assurance mechanism that > supports any security protocol but only works with X.509 certs than > one the only works with TLS but has the option of using additional > cert formats that are either essentially historic or make no real > sense in the context of a hierarchical naming structure (PGP). > > > I find the milestones to be entirely unrealistic. > > It will take considerably longer than June 2011 to have any draft > with the cert enumeration semantics contained in it ready for the > IESG. It would be somewhat optimistic to expect to have a draft with > only the key assurance semantics ready in that time, and that is > work we have twenty years experience doing at this point. > > > The natural place to break the problem is between key assurance and > security policy. That is, along the major functional lines. > > I would anticipate the final document set looking something like > > * Key Assurance Mechanism > * Use of Key Assurance Cert Type with HTTP/TLS > * DNS Security Policy Mechanism > * Use of Security Policy with HTTP > * Use of Security Policy with SMTP, POP3, IMAP > > For each of the 'Mechanism' documents I would anticipate an > effective 3 step process of Experimental, Proposed, Standard. > > For the Use documents I would anticipate a 2 step process starting > at Proposed and going to Standard. > > If Russ' 2 step proposal goes through then the final step would be > 'Full Standard' otherwise it will most likely be 'Draft'. > > > I would also leave open the possibility that there may be multiple > experimental mechanism documents in the case that there is no > agreement before test deployments start. > > The reason I propose using the experimental step is that I want to > start real world trials as soon as possible and want the results of > those trials to feed into the Proposed Standard. And to do trials, I > would like to have possible production code points assigned. > > Based on previous IETF experience, three years for getting the > documents of this type to Proposed Standard is rather more realistic > than the schedules proposed. > > On Thu, Sep 30, 2010 at 8:06 PM, Warren Kumari > wrote: > Hi there all, > > I wanted to thank everyone for their hard work and active > involvement in the chartering discussions. > > I have reread most of the mail on this topic, and have tried to > integrate everyones suggestions, and I think that we finally have a > version that will be *acceptable* to everyone. > > I'd like to especially thank Stephen Farrell for his suggestions > (which I somehow filed into a different label and missed) as well as > Phillip, Paul, Richard and Jakob for their input and suggested text... > > I think that we have been fairly close to an acceptable charter for > a long time now, but were getting hung up on misunderstandings and > misinterpretations of what others were saying... > > So, please have another look at the charter and hopefully you will > find it acceptable to you: > http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure > > If parts are not acceptable, please do me 3 favors: > 1: Reread the unacceptable parts and try figure out if what you are > objecting to is what the sentence is trying to say, or it is just a > wording issue / differing uses of a term. > > 2: If you are OK with it being in the charter so that we (as a WG) > can at least discuss the issue and come to consensus. > > and, most importantly: > 3: send text --- saying "Bah, paragraph X is the devil! eat flaming > death, mongrel!" is *not* helpful... "How does the group feel about > 'Foo blargh wumblet boop' instead of 'mumble'?" is... > > W > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure --Apple-Mail-2-537730953 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I would support striking this = sentence, which is the only mention of the word "privacy":
"The = group will also investigate publishing security policies that are=20 related to the use of keying material in the DNS, such as whether=20 communications must be cryptographically = protected."

This is not a policy group, it's a = domain-to-key binding group.  Policy, as I've said before, is the = domain of the = applications.

--Richard

=
On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker = wrote:

I have asked on three separate occasions to have the ESRV = draft added to the list of possible starting = points:

Possible starting points for = these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, = draft-hallambaker-esrv
=

=


=

If we are doing security policy = we should look at all the = proposals.


The charter as = written is of the form 'here is a technology, we want a WG to turn it = into a standard'. While that is the right approach when there is = significant experience of using actual code, we are not in that position = here. 

In particular I disagree with the = following:

The group will also investigate publishing security policies that = are related to the use of keying material in the DNS, such as whether = communications must be cryptographically protected.
=

Please remove " that are related to the = use of keying material"


The policy = mechanism should be orthogonal to the keying = mechanism.

=

=
Absent extensive = experience of tying policy to keys and a demonstration of clear benefits = resulting from that approach, the charter should leave that choice = open.

=
I don't see any = particular reason to separate TLS and non TLS protocols either. So far = the only aspects of the protocol that are tied to TLS are the 'cert = enumeration' mechanism and the cert type = identifier.

=
Given the choice, I would much = prefer a key assurance mechanism that supports any security protocol but = only works with X.509 certs than one the only works with TLS but has the = option of using additional cert formats that are either essentially = historic or make no real sense in the context of a hierarchical naming = structure (PGP).

=

=
I find the = milestones to be entirely = unrealistic. 

=
It will take = considerably longer than June 2011 to have any draft with the cert = enumeration semantics contained in it ready for the IESG. It would be = somewhat optimistic to expect to have a draft with only the key = assurance semantics ready in that time, and that is work we have twenty = years experience doing at this point.
=


=
The natural place = to break the problem is between key assurance and security policy. That = is, along the major functional lines.
=

I would anticipate = the final document set looking something = like

=
* Key Assurance = Mechanism
* Use of Key = Assurance Cert Type with HTTP/TLS
=
* = DNS Security Policy Mechanism 
=
* = Use of Security Policy with HTTP
=
* = Use of Security Policy with SMTP, POP3, = IMAP

=
For each of the = 'Mechanism' documents I would anticipate an effective 3 step process of = Experimental, Proposed, Standard.
=

For the Use = documents I would anticipate a 2 step process starting at Proposed and = going to Standard.

=
If Russ' 2 step = proposal goes through then the final step would be 'Full Standard' = otherwise it will most likely be = 'Draft'.

=

=
I would also leave = open the possibility that there may be multiple experimental mechanism = documents in the case that there is no agreement before test deployments = start. 

=
The reason I = propose using the experimental step is that I want to start real world = trials as soon as possible and want the results of those trials to feed = into the Proposed Standard. And to do trials, I would like to have = possible production code points = assigned.

=
Based on previous = IETF experience, three years for getting the documents of this type to = Proposed Standard is rather more realistic than the schedules = proposed.

=
On Thu, Sep 30, 2010 at 8:06 PM, = Warren Kumari <warren@kumari.net> = wrote:
Hi there all,

I wanted to thank = everyone for their hard work and active involvement in the chartering = discussions.

I have reread most of the mail on this topic, and = have tried to integrate everyones suggestions, and I think that we = finally have a version that will be *acceptable* to everyone.

= I'd like to especially thank Stephen Farrell for his suggestions (which = I somehow filed into a different label and missed) as well as Phillip, = Paul, Richard and Jakob for their input and suggested text...

I = think that we have been fairly close to an acceptable charter for a long = time now, but were getting hung up on misunderstandings and = misinterpretations of what others were saying...

So, please = have another look at the charter and hopefully you will find it = acceptable to you:
http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure<= /a>

If parts are not acceptable, please do me 3 favors:
1: = Reread the unacceptable parts and try figure out if what you are = objecting to is what the sentence is trying to say, or it is just a = wording issue / differing uses of a term.

2: If  you are = OK with it being in the charter so that we (as a WG) can at least = discuss the issue and come to consensus.

and, most = importantly:
3: send text --- saying "Bah, paragraph X is the devil! = eat flaming death, mongrel!" is *not* helpful... "How does the group = feel about 'Foo blargh wumblet boop' instead of 'mumble'?" is...
=
W
_______________________________________________
keyassure = mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure
=



--
Website: http://hallambaker.com/

=
_______________________________________________
keyassure = mailing list
keyassure@ietf.org
https://www.ietf.= org/mailman/listinfo/keyassure

= = --Apple-Mail-2-537730953-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138343A6C91 for ; Fri, 1 Oct 2010 04:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4bOUFoOHyUl for ; Fri, 1 Oct 2010 04:59:22 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id 7AB193A6C2A for ; Fri, 1 Oct 2010 04:59:21 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id 9AE2813BD1B; Fri, 1 Oct 2010 15:00:07 +0300 (EEST) Received: from emh06.mail.saunalahti.fi ([62.142.5.116]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A017D696B1B; Fri, 01 Oct 2010 15:00:07 +0300 Received: from LK-Perkele-V2 (a88-112-50-174.elisa-laajakaista.fi [88.112.50.174]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 08DF8E51A4; Fri, 1 Oct 2010 15:00:01 +0300 (EEST) Date: Fri, 1 Oct 2010 15:05:22 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20101001120522.GA27088@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] Latest spin at the chater... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 11:59:24 -0000 On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote: > > The policy mechanism should be orthogonal to the keying mechanism. > > Existing experience of security policy ties the policy to protocols and not > keys. Security policies are of the form 'must use SSL when using HTTP at > example.com' and 'must use SSL with key conforming to trust criteria X when > using HTTP...' I'm not a fan of security policies in DNS. I would like more to see facts, like: * Client can upgrade the connection (to this or that) after connecting for this service (downgrade-attack-free upgrades) * Client can connect securely (using this or that) to this service (it will sniff the connection type) * Client can obtain equivalent secure service (using this or that) from that service (service redirect) * This service supports security, client MAY use it. * This service is sensitive, client SHOULD use security. * This service doesn't yield useful nonsecure service, client MUST use security. * The certificate will chain to one of these TAs. Of course, the client is free to ignore this, but it will do so on peril of itself and its user. This is pretty much everything one needs to have secure connection. One can then send actual (protocol dependent) policy (securely) via that. > I don't see any particular reason to separate TLS and non TLS protocols > either. So far the only aspects of the protocol that are tied to TLS are the > 'cert enumeration' mechanism and the cert type identifier. I thought the idea was to form some "core" with some free "parameters" and then instantiate that for each protocol. Anyway, spec for TLS can be transformed into spec for IPSEC with little search-and-replace. > Given the choice, I would much prefer a key assurance mechanism that > supports any security protocol but only works with X.509 certs than one the > only works with TLS but has the option of using additional cert formats that > are either essentially historic or make no real sense in the context of a > hierarchical naming structure (PGP). I think OpenPGP would make great sense here. Its way simpler if you just need key container for TLS (since TLS doesn't have "raw key cert" format). -Ilari