From sjs@princeton.edu Wed Jun 1 10:45:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F7BE0949 for ; Wed, 1 Jun 2011 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Upb4gTyhjX for ; Wed, 1 Jun 2011 10:45:50 -0700 (PDT) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EDE0678 for ; Wed, 1 Jun 2011 10:45:49 -0700 (PDT) Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa04.Princeton.EDU (8.14.4/8.14.4) with ESMTP id p51HjmSo022998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 1 Jun 2011 13:45:48 -0400 Received: from mayflower-ad.Princeton.EDU (mayflower-ad.Princeton.EDU [128.112.224.246]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p51HjmZO029610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Jun 2011 13:45:48 -0400 Message-Id: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> From: Stephen Schultze To: dane@ietf.org 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, 1 Jun 2011 13:45:47 -0400 References: X-Mailer: Apple Mail (2.936) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-06-01_09:2011-06-01, 2011-06-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=quarantine_outbound_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1106010093 Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:45:51 -0000 On May 30, 2011, at 8:48 AM, Peter Gutmann wrote: > When I first heard of CAA I thought it was great, a web site owner > could > indicate that only certificates from CA X should be trusted for > their site: > > 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. > [...] Right, and the following sentence is: "Publication of CAA resource records allow a public Certification Authority (CA) to implement additional controls to reduce the risk of unintended certificate mis-issue." So the obvious primary purpose is for communication between participating CAs, rather than to end users, which you observed... > Then I saw things like: > > Thus Relying Applications MUST NOT use failure to conform to > currently > published CAA records as a rejection criteria for certificates > unless [...] > > OK, so that's not a good start. What's the intended use for this > then? Let's > see... > > Examples of Use. > > The following example informs CAs that certificates must not be > issued > except under [...] So yes, it's backwards if what you're assuming it is intended to indicate anything to end users. The current draft confuses things, because it *does* include discussion of relying parties... although seemingly as an afterthought. I think the CAA authors should drop their section 2.3 and any other reference to relying party applications and instead focus their relying party energies on DANE -- in particular the current draft's section 2.3 cert type 2. That way we can all clearly address the issues together. Paul suggested the same thingsix months ago: http://www.ietf.org/mail-archive/web/dane/current/msg01316.html From matt@mattmccutchen.net Wed Jun 1 11:03:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83992E06FC for ; Wed, 1 Jun 2011 11:03:42 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sfl60GXsjmee for ; Wed, 1 Jun 2011 11:03:41 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA313E06D8 for ; Wed, 1 Jun 2011 11:03:41 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 43F5725C079 for ; Wed, 1 Jun 2011 11:03:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=LSSkEj4zYEQ+zvJyvfLFErRliH6QvG/BoWeF3JBtdFK PSzkd4TVeAlSL+IcXn2nWe6hHEs/yMXubqxgaShPVco1Z0Y2QvNcSZYBNBBuNP8b Y1ahQ1dRzF5HjfGsp9ZefNo49XYk0moiuM7EyNy+jiXZZ6I2TmTHg2iymy9UxINA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=JRqZBxueNpZQKotqCxAATPWruyM=; b=LK8uHIzrAf 6esFLgGPb/OCwHekzVV5zmQfI+tWyGsk979mBNI2TtvLR+Y4vQO2kyEY446k9yLc lbE3j1qr0YCyVM6Ln+3Q9Ya7iqTlJZl2ugujBy/IzpXy8P79fDJJeMgsoAQgbJEH 8nvprkwJKTWdpZFGiLGlFsOI/Bx1hhLQ8= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 9A28725C078 for ; Wed, 1 Jun 2011 11:03:40 -0700 (PDT) From: Matt McCutchen To: dane In-Reply-To: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> Content-Type: text/plain; charset="UTF-8" Date: Wed, 01 Jun 2011 14:03:34 -0400 Message-ID: <1306951414.2201.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:03:42 -0000 On Wed, 2011-06-01 at 13:45 -0400, Stephen Schultze wrote: > The current [CAA] draft confuses things, > because it *does* include discussion of relying parties... although > seemingly as an afterthought. I think the CAA authors should drop > their section 2.3 and any other reference to relying party > applications and instead focus their relying party energies on DANE -- > in particular the current draft's section 2.3 cert type 2. That way > we can all clearly address the issues together. I agree. Current DANE supports server and CA certificate constraints, while current CAA supports those and certification policy constraints and could add new constraint types in the future. Leaving aside the extensibility, my feeling is that the certification policy constraints may be useful for issuance, but I am not seeing a use case that would benefit materially from having relying parties enforce certification policy constraints rather than (say) CA certificate constraints. So I think Stephen's suggestion is appropriate. -- Matt From hallam@gmail.com Wed Jun 1 14:10:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B306E0867 for ; Wed, 1 Jun 2011 14:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnigOpiDsFQL for ; Wed, 1 Jun 2011 14:10:17 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1498BE083F for ; Wed, 1 Jun 2011 14:10:16 -0700 (PDT) Received: by yic13 with SMTP id 13so119356yic.31 for ; Wed, 01 Jun 2011 14:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MXR2sXauZWT59+p852czYUGP/ubtVuwiqNUPslhtuOQ=; b=O8M9KprEE+j7db2KyuZ9XOcGRIyJPjgZEFj5VjsZucqfLWwXVTJVYV52aHdlGTngZF Nb/4oWIyl+hndAebv2RwS9yMwNfA96yAJgVCe+Hn26RX1XCwJhyjHQczMMRxNdCPFsyy KDUPjlhi0dOWOlmUrCUcZNSAEMqdgnUbhLm/M= 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=LjJoqflTOxfWvdnkwkIvZFqABbLMkJmMgN9LZV0JRbWJb7v2123mWZTxzxVKB3TWA9 8oo3mLUsn3SJw4gNU9aDkzXToae7e7bDxeEDNAknZszeMmDbLFrDzUYU3W5mdKxPVAoq eXW8JDZ1dUjy2VdEnktMv36HMRK/iuQjHKSH0= MIME-Version: 1.0 Received: by 10.101.11.14 with SMTP id o14mr4798967ani.88.1306962616320; Wed, 01 Jun 2011 14:10:16 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 1 Jun 2011 14:10:16 -0700 (PDT) In-Reply-To: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> Date: Wed, 1 Jun 2011 17:10:16 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Schultze Content-Type: multipart/alternative; boundary=0016e68fcec47b04aa04a4acf2a2 Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 21:10:20 -0000 --0016e68fcec47b04aa04a4acf2a2 Content-Type: text/plain; charset=ISO-8859-1 The reason CAA has the elements referring to client side enforcement is to alert deployers and implementers to the fact that the criteria for issue and enforcement are different. An existing certificate must be valid for use even if the CA has lost its issue privileges. So it is a bad idea to propose a specification that does not support both use cases. Though in practice the need for ongoing relying party checks should be quite small. For example, imagine that we fix certificate revocation mechanisms such that a browser provider can push out a blacklist of 'bad certificates' (i.e. certs known to be actually dangerous). In that case it would be sufficient for a small number of clients to do relying party checks and notify the blacklisting mechanism if something untoward is seen. As Peter says, CAA is backwards to the approach that people have been attempting to use for years. But that might well be because we have been approaching the problem backwards from the start. I have also proposed merging the two approaches. However we have a serious obstacle to achieving that. My strong belief is that any IETF standard must be designed to interoperate with other IETF standards. So I regard the following to be essential: * 100% compatibility with all DNS features including wildcards, CNAME, DNAME and SRV * Use syntactic forms that are compatible with the protocols that it is designed to interoperate with, i.e. PKIX * Use algorithm identifiers that are compatible with the protocols that it is designed to interoperate with. Now people can claim that consensus in the WG is that this group has decided to ignore all this and go off to do everything its own way. But that approach tends not to go down too well in the rest of the IETF or the rest of the industry. So if the WG syntax turns out to be successful and people deploy I would expect that a rev of CAA would be developed to align CAA with whatever is deployed. But if the IETF at large complains that DANE needs to be compatible with existing IETF protocols then CAA and the other proposals I have made represent a proof of existence of an alternative approach that does not introduce unnecessary incompatibilities and inconsistencies as the Hoffman et al draft does. On Wed, Jun 1, 2011 at 1:45 PM, Stephen Schultze wrote: > On May 30, 2011, at 8:48 AM, Peter Gutmann wrote: > >> When I first heard of CAA I thought it was great, a web site owner could >> indicate that only certificates from CA X should be trusted for their >> site: >> >> 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. >> [...] >> > > Right, and the following sentence is: > "Publication of CAA resource records allow a public Certification Authority > (CA) to implement additional controls to reduce the risk of unintended > certificate mis-issue." > > So the obvious primary purpose is for communication between participating > CAs, rather than to end users, which you observed... > > > Then I saw things like: >> >> Thus Relying Applications MUST NOT use failure to conform to currently >> published CAA records as a rejection criteria for certificates unless >> [...] >> >> OK, so that's not a good start. What's the intended use for this then? >> Let's >> see... >> >> Examples of Use. >> >> The following example informs CAs that certificates must not be issued >> except under [...] >> > > So yes, it's backwards if what you're assuming it is intended to indicate > anything to end users. The current draft confuses things, because it *does* > include discussion of relying parties... although seemingly as an > afterthought. I think the CAA authors should drop their section 2.3 and any > other reference to relying party applications and instead focus their > relying party energies on DANE -- in particular the current draft's section > 2.3 cert type 2. That way we can all clearly address the issues together. > Paul suggested the same thingsix months ago: > > http://www.ietf.org/mail-archive/web/dane/current/msg01316.html > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68fcec47b04aa04a4acf2a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The reason CAA has the elements referring to c= lient side enforcement is to alert deployers and implementers to the fact t= hat the criteria for issue and enforcement are different. An existing certi= ficate must be valid for use even if the CA has lost its issue privileges.<= /div>

So it is a bad idea to propose a specification that doe= s not support both use cases. Though in practice the need for ongoing relyi= ng party checks should be quite small.

For example= , imagine that we fix certificate revocation mechanisms such that a browser= provider can push out a blacklist of 'bad certificates' (i.e. cert= s known to be actually dangerous). In that case it would be sufficient for = a small number of clients to do relying party checks and notify the blackli= sting mechanism if something untoward is seen.

As Peter says, CAA is backwards to the approach that pe= ople have been attempting to use for years. But that might well be because = we have been approaching the problem backwards from the start.


I have also proposed merging the two approach= es. However we have a serious obstacle to achieving that.

My strong belief is that any IETF standard must be designed to inte= roperate with other IETF standards. So I regard the following to be essenti= al:

* 100% compatibility with all DNS features including wi= ldcards, CNAME, DNAME and SRV=A0

* Use syntactic f= orms that are compatible with the protocols that it is designed to interope= rate with, i.e. PKIX

* Use algorithm identifiers that are compatible with th= e protocols that it is designed to interoperate with.

<= div>
Now people can claim that consensus in the WG is that th= is group has decided to ignore all this and go off to do everything its own= way. But that approach tends not to go down too well in the rest of the IE= TF or the rest of the industry.=A0

So if the WG syntax turns out to be successful and peop= le deploy I would expect that a rev of CAA would be developed to align CAA = with whatever is deployed.

But if the IETF at larg= e complains that DANE needs to be compatible with existing IETF protocols t= hen CAA and the other proposals I have made represent a proof of existence = of an alternative approach that does not introduce unnecessary incompatibil= ities and inconsistencies as the Hoffman et al draft does.





On Wed, Jun 1, 2011 at 1:45 PM, Stephen Schultze <sjs@princeton.edu>= wrote:
On May 30, 2011, at 8:48 = AM, Peter Gutmann wrote:
When I first heard of CAA I thought it was great, a web site owner could indicate that only certificates from CA X should be trusted for their site:=

=A0The Certification Authority Authorization (CAA) DNS Resource Record allo= ws a
=A0DNS domain name holder to specify the certificate signing certificate(s)=
=A0authorized to issue certificates for that domain.
[...]

Right, and the following sentence is:
"Publication of CAA resource records allow a public Certification Auth= ority (CA) to implement additional controls to reduce the risk of unintende= d certificate mis-issue."

So the obvious primary purpose is for communication between participating C= As, rather than to end users, which you observed...


Then I saw things like:

=A0Thus Relying Applications MUST NOT use failure to conform to currently =A0published CAA records as a rejection criteria for certificates unless [.= ..]

OK, so that's not a good start. =A0What's the intended use for this= then? =A0Let's
see...

=A0Examples of Use.

=A0The following example informs CAs that certificates must not be issued =A0except under [...]

So yes, it's backwards if what you're assuming it is intended to in= dicate anything to end users. =A0The current draft confuses things, because= it *does* include discussion of relying parties... although seemingly as a= n afterthought. =A0I think the CAA authors should drop their section 2.3 an= d any other reference to relying party applications and instead focus their= relying party energies on DANE -- in particular the current draft's se= ction 2.3 cert type 2. =A0That way we can all clearly address the issues to= gether. =A0Paul suggested the same thingsix months ago:

http://www.ietf.org/mail-archive/web/dane/current/msg013= 16.html

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016e68fcec47b04aa04a4acf2a2-- From matt@mattmccutchen.net Thu Jun 2 10:07:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4755E07FC for ; Thu, 2 Jun 2011 10:07:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSzIGkOrbCHb for ; Thu, 2 Jun 2011 10:07:43 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 857CAE06BB for ; Thu, 2 Jun 2011 10:07:22 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 4359D59807A; Thu, 2 Jun 2011 10:07:22 -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=q3vodHJOO3gulF74nrggznA0cgTV+a5N85ksDY2vydq lD/Om8mh1F5yRBfNe0cpM1QcIN9Fb3ZoAjtDhZKSwNhcBboeza7OX+DJ9JIU1zDV Tvlu+SVF+qlqc+6baC1fcitplS+HD81rykYMXT8KgXUZa5lxNXmOhLgqK9ql2uTg = 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=hEGLn3rSHzHr9tUPhO5Tg8szJKE=; b=GRfZcW5zKx d883DMk7kfYdVQU7FiWyMiKSMTh0xJ6q+RG8fmCWMl+PbiOBLGgsd1YB7oNhDed5 DVc5PVJ4EEm/JDBp58UK+sJdmu+jSXTGa1BtQ4b4++kCjl9uHtr7xSPNxbTPru7N 9PAB0zi4F+5lJaKlaWaLRneCyhu9Vy9aw= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id C812D598077; Thu, 2 Jun 2011 10:07:21 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 13:05:52 -0400 Message-ID: <1307034352.2193.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:07:44 -0000 On Wed, 2011-06-01 at 17:10 -0400, Phillip Hallam-Baker wrote: > The reason CAA has the elements referring to client side enforcement > is to alert deployers and implementers to the fact that the criteria > for issue and enforcement are different. An existing certificate must > be valid for use even if the CA has lost its issue privileges. > > So it is a bad idea to propose a specification that does not support > both use cases. You are rather glibly coupling (1) the desire to discourage implementers from misapplying the issuance constraints as relying party constraints and (2) the potential utility of relying party constraints. I think we can all agree that in IETF protocol work, discouraging the misapplication of a scheme for A to B is not grounds for introducing dummy functionality for B. Hence (1) is null and relying party enforcement in CAA must stand on its own merits, in light of potential overlap with DANE. > I have also proposed merging the two approaches. However we have a > serious obstacle to achieving that. > > My strong belief is that any IETF standard must be designed to > interoperate with other IETF standards. So I regard the following to > be essential: > > * 100% compatibility with all DNS features including wildcards, CNAME, > DNAME and SRV DANE (TLSA) and SRV are not compatible, but composable: DANE comes into play after SRV discovery is completed. I consider compatibility with wildcards and CNAME/DNAME to be essential for DANE too and just filed a ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/24). Are there other relevant "DNS features"? > * Use syntactic forms that are compatible with the protocols that it > is designed to interoperate with, i.e. PKIX > > * Use algorithm identifiers that are compatible with the protocols > that it is designed to interoperate with. CAA/DANE tools will be interoperable with one another no matter what syntactic forms or algorithm identifiers are used. What you are talking about is homogeneity of design, not interoperability. And AIUI, the DANE group chose homogeneity with DNS over homogeneity with PKIX. I think this is appropriate in view of the possible future use of DANE with non-PKIX TLS "certificate types". -- Matt From matt@mattmccutchen.net Thu Jun 2 10:13:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A59E06DC for ; Thu, 2 Jun 2011 10:13:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tllz3Y4a20Tm for ; Thu, 2 Jun 2011 10:13:08 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2272EE05D3 for ; Thu, 2 Jun 2011 10:13:08 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id E9947634073; Thu, 2 Jun 2011 10:13:07 -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=QD10PQ5xqfQLsABxsGVLAeDdowkTXOvLVR8TA0cr5Vn 7jvI/woc9QqS4+BAWOHglhkdyiEMZmxVzs3vUGyLEhuDGCOpGmZZv1Y/udY0KT35 yRPh5eol+jl1mrqRxzj86vJMDzyBc2hWgkuELkN55Bs6YCUvNJpNnNZLrLLZAm8A = 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=us9T7fnKN8hV72HoJA4/xIH4/hk=; b=ZL3q9PPy5t jzPMnKNsnraGWGgTiPk9/v6gWbKhIRNY9+Pgaggwln9puMvw5zeUaGSDBs/W0Akl FJt6xnMdfVPg+/0qWdsrtoCxB2ucrvBewGiaQWkUwwX+dLT9VCIHF3YUrmTXJq4n +ZTx0j5tDKr3/1nc7M1RC8tY9vpAwlOH8= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 68EC663406F; Thu, 2 Jun 2011 10:13:07 -0700 (PDT) From: Matt McCutchen To: Peter Gutmann In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 13:13:05 -0400 Message-ID: <1307034785.2193.54.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: [dane] OT - Weak links X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:13:08 -0000 On Tue, 2011-05-31 at 01:19 +1200, Peter Gutmann wrote: > All you have to do is make it at least as secure as > the current weakest link, which is forging a request to the registrar to > change the DNS entry (and that's a pretty low barrier for your $9.95 > registrar). Really? Do you know something I don't? I invite you to change the CAA records on mattmccutchen.net. -- Matt From stephen.farrell@cs.tcd.ie Thu Jun 2 10:16:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA5EE07A2 for ; Thu, 2 Jun 2011 10:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJwMNi2i+P9U for ; Thu, 2 Jun 2011 10:16:22 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 727C8E079A for ; Thu, 2 Jun 2011 10:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B28F0171C06; Thu, 2 Jun 2011 18:16:20 +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=1307034980; bh=ESSGOQ6eahIG0+ Y61P7Zdte6gsPUPba6mMP8vWnqBhM=; b=2gYQ5IQ+I3jnaZZiD2V3hibUN04Vo0 A/qh8/0ImCekqWRvxmj42BWVOiZnhWcdisLcKae25CoCRzhGXOynWHxOXj57fNIj PimGUXOvEJ2fx90s0BEVx65VpwDuXtFHZ8+qWxTmP2zjrucCSwMK6pi5C2E2Itgr aW35DaCNiwu4buQTZaWZXPkh8lQKNDLflh+NBd+IxQe7/qG2br5DsDPhbOX3KXSJ 9rdGHboVNsy2E99pPAnpHDmX0qVVLfADpBHo3OxILMdr/YqufPkLm9pO5FFmEyqd GFJVodePDN33U1KQmcjCUvR3sJBtbRQ+c7AKLvAg/rqlII0wgyH7NKfQ== 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 6MzhKvZ0LZks; Thu, 2 Jun 2011 18:16:20 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 685CA171C01; Thu, 2 Jun 2011 18:16:18 +0100 (IST) Message-ID: <4DE7C562.8060404@cs.tcd.ie> Date: Thu, 02 Jun 2011 18:16:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matt McCutchen References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <1307034352.2193.52.camel@localhost> In-Reply-To: <1307034352.2193.52.camel@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:16:23 -0000 So just a venue point - the PKIX WG have today agreed to adopt CAA as a work item. When this has gone a bit further as a work item there we'll be able to deal with any remaining overlap with DANE more easily so I'd suggest moving discussion on this to PKIX for the next while. (Well, once Phill has posted a -00 PKIX WG document I guess.) Cheers, Stephen. On 02/06/11 18:05, Matt McCutchen wrote: > On Wed, 2011-06-01 at 17:10 -0400, Phillip Hallam-Baker wrote: >> The reason CAA has the elements referring to client side enforcement >> is to alert deployers and implementers to the fact that the criteria >> for issue and enforcement are different. An existing certificate must >> be valid for use even if the CA has lost its issue privileges. >> >> So it is a bad idea to propose a specification that does not support >> both use cases. > > You are rather glibly coupling (1) the desire to discourage implementers > from misapplying the issuance constraints as relying party constraints > and (2) the potential utility of relying party constraints. I think we > can all agree that in IETF protocol work, discouraging the > misapplication of a scheme for A to B is not grounds for introducing > dummy functionality for B. Hence (1) is null and relying party > enforcement in CAA must stand on its own merits, in light of potential > overlap with DANE. > >> I have also proposed merging the two approaches. However we have a >> serious obstacle to achieving that. >> >> My strong belief is that any IETF standard must be designed to >> interoperate with other IETF standards. So I regard the following to >> be essential: >> >> * 100% compatibility with all DNS features including wildcards, CNAME, >> DNAME and SRV > > DANE (TLSA) and SRV are not compatible, but composable: DANE comes into > play after SRV discovery is completed. I consider compatibility with > wildcards and CNAME/DNAME to be essential for DANE too and just filed a > ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/24). Are there > other relevant "DNS features"? > >> * Use syntactic forms that are compatible with the protocols that it >> is designed to interoperate with, i.e. PKIX >> >> * Use algorithm identifiers that are compatible with the protocols >> that it is designed to interoperate with. > > CAA/DANE tools will be interoperable with one another no matter what > syntactic forms or algorithm identifiers are used. What you are talking > about is homogeneity of design, not interoperability. And AIUI, the > DANE group chose homogeneity with DNS over homogeneity with PKIX. I > think this is appropriate in view of the possible future use of DANE > with non-PKIX TLS "certificate types". > From hallam@gmail.com Thu Jun 2 10:53:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294DCE0802 for ; Thu, 2 Jun 2011 10:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvJxXQmmYzoC for ; Thu, 2 Jun 2011 10:53:17 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A33A7E0803 for ; Thu, 2 Jun 2011 10:53:14 -0700 (PDT) Received: by gxk19 with SMTP id 19so557613gxk.31 for ; Thu, 02 Jun 2011 10:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=w+v9UbvYkwz7YkHNSeect4loWxo/ueIwltKMVXIQ8O4=; b=p/yGPbLYuAP5oxrqfyayQlbdIuNdwg7Miyyel/kl2eOGHnZQ5Qz9YGOCTyvNCYYWFc IBbks6j83RppcRIeu6xKuBzvKGgeLBy191S3RVGclXXcYhhv3rbv76hRNsSK/VOWdFvA kKsa8z9YWJXmy5rjicpTHZTCpj5fyMhZ11T1c= 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=q/+SlvoPH740QqKQZs1IjS1XfiRsjRe10DQr3xpdwrshlHAjig3cI7XCG4EwBu4oN1 VyJUWupiROs9JdbAVcVQApvrafXYFGlzjpFe7GlaP1wPZo2trjaqsrF7NRpK3cKtHvf0 gcrV2sfAy2H2L/Nh0UGFIRGqx8Pd0VWbtelJs= MIME-Version: 1.0 Received: by 10.101.74.10 with SMTP id b10mr654937anl.107.1307037194033; Thu, 02 Jun 2011 10:53:14 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 10:53:14 -0700 (PDT) In-Reply-To: <1307034785.2193.54.camel@localhost> References: <1307034785.2193.54.camel@localhost> Date: Thu, 2 Jun 2011 13:53:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016368e1f85a89b5604a4be4f9a Cc: dane@ietf.org Subject: Re: [dane] OT - Weak links X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:53:18 -0000 --0016368e1f85a89b5604a4be4f9a Content-Type: text/plain; charset=ISO-8859-1 Ooooo please not. I have seen people make similar challenges and it never ends well. Even if you give permission to be hacked, your registrar has not and they are the party that will bear the cost. On Thu, Jun 2, 2011 at 1:13 PM, Matt McCutchen wrote: > On Tue, 2011-05-31 at 01:19 +1200, Peter Gutmann wrote: > > All you have to do is make it at least as secure as > > the current weakest link, which is forging a request to the registrar to > > change the DNS entry (and that's a pretty low barrier for your $9.95 > > registrar). > > Really? Do you know something I don't? I invite you to change the CAA > records on mattmccutchen.net. > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016368e1f85a89b5604a4be4f9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ooooo please not.

I have seen people make similar challe= nges and it never ends well. Even if you give permission to be hacked, your= registrar has not and they are the party that will bear the cost.

On Thu, Jun 2, 2011 at 1:13 PM, Matt McCutchen <= span dir=3D"ltr"><matt@mattmcc= utchen.net> wrote:
On Tue, 2011-05-31 at 01:19 +1200, Peter Gutmann wrote:
> All you have to do is make it at least as secure as
> the current weakest link, which is forging a request to the registrar = to
> change the DNS entry (and that's a pretty low barrier for your $9.= 95
> registrar).

Really? =A0Do you know something I don't? =A0I invite you to change the= CAA
records on mattmccut= chen.net.

--
Matt

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016368e1f85a89b5604a4be4f9a-- From matt@mattmccutchen.net Thu Jun 2 11:05:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCDCE083C for ; Thu, 2 Jun 2011 11:05:11 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkyptlZTqWqD for ; Thu, 2 Jun 2011 11:05:11 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B9E0801 for ; Thu, 2 Jun 2011 11:05:11 -0700 (PDT) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id C6B7E25C06A; Thu, 2 Jun 2011 11:05:10 -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=dIj8gqdVdz4UVaHzI2qeN8AThn/Km1QKVjz5Hg+Ku2t 3CFK6rWFXhK+o4+jyWAzoFkyg5Q00rMiusZOyzG2RP9EDG3XuILg1BSkblqoZRlk orJ2x1cgQA5OIKh1f3MTGoqWATnZsNg6gC3+BTKstzKhRLMo58e8EzbRfPrVTShI = 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=l2VTiCMk725bjTAbkgzyj5Mozkk=; b=VAXUHg4CV7 2Tamd73MiwxaxaJBUuagTrvVU/1TVYsEKx5jXR6OlBy/0vuXNWSONrti+MyJ3ySj UnkGVmRRr+8YUJPcl4WWvkjiDvpiWlsl7tlu3IKYNRjlBrYT3H7apASzOLR6nsyH LrOUFWt+dSWjLVYK0sYU+XXECo1njtAIc= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 0F1B725C063; Thu, 2 Jun 2011 11:05:09 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <1307034785.2193.54.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 14:05:08 -0400 Message-ID: <1307037908.2193.66.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] OT - Weak links X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:05:11 -0000 On Thu, 2011-06-02 at 13:53 -0400, Phillip Hallam-Baker wrote: > Ooooo please not. > > I have seen people make similar challenges and it never ends well. > Even if you give permission to be hacked, your registrar has not and > they are the party that will bear the cost. You are right, my remark was unwise and I take it back. I just don't like FUD. If on the other hand there are known problems in this area, I would like to fix them. It doesn't seem like maintaining a secure customer admin interface should cost more than $9.95 per domain at the scale of a large registrar like mine. -- Matt From gnu@toad.com Thu Jun 2 11:14:49 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E29DE0835 for ; Thu, 2 Jun 2011 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYoMLaQCW0IZ for ; Thu, 2 Jun 2011 11:14:49 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4392BE0849 for ; Thu, 2 Jun 2011 11:14:47 -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 p52IEkZE003911 for ; Thu, 2 Jun 2011 11:14:46 -0700 Message-Id: <201106021814.p52IEkZE003911@new.toad.com> To: dane@ietf.org In-reply-to: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> Comments: In-reply-to Stephen Schultze message dated "Wed, 01 Jun 2011 13:45:47 -0400." Date: Thu, 02 Jun 2011 11:14:46 -0700 From: John Gilmore Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:14:49 -0000 CAA seems like a complete abuse of the domain name system to communicate a domain owner's restriction to CA's that are too lazy to access the domain's web site (or look up the domain in WHOIS), pick up the phone, and call the domain owner to verify that they really ordered this alleged certificate. Since that seems to be the state of the art in "certifying"... no round-trip verification at all... why should we dignify that with an otherwise useless DNS record, that by its own definition doesn't communicate anything to anybody except a few hundred CA's worldwide? John From hallam@gmail.com Thu Jun 2 11:34:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B47E0801 for ; Thu, 2 Jun 2011 11:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUmSFfMmBPI1 for ; Thu, 2 Jun 2011 11:34:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76D03E07E6 for ; Thu, 2 Jun 2011 11:34:26 -0700 (PDT) Received: by gyf3 with SMTP id 3so581730gyf.31 for ; Thu, 02 Jun 2011 11:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NsGPTWobkmbPtrwUSeowOdE6+PrF/qnH2kxwS0axe/g=; b=cF0OlnRN5dAI+iLgWM9ANo7N676rUqLsReAWGksrelXuUU/V4I9t/5TeAwfAdQnN1E aWXorX0qe+NZ1tfF1bjFldi6XumwEoqBM2+uNFm7AQXEe38cQWQCVNmCnYF5tvFCOzBH +CBaqSdDR5XczjAiXPTaGd4AFpjD3JB+9Mbmg= 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=lh02ZUMgHbvczkfb7lru6uUttmGkatGNcyiHeJ3RanlLLW+Q6YalmKR6a+1TApxHd8 v6J34l0/efDzcgMpdT1z/pKOcZqINxSybA5vR0FuE6GxWjQARzNudKAWHJEa7BS69Rlw pLNBoCys+fAjFGYdtPs17oKuYArvpGaGqio3o= MIME-Version: 1.0 Received: by 10.101.11.14 with SMTP id o14mr690153ani.88.1307039665866; Thu, 02 Jun 2011 11:34:25 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 11:34:25 -0700 (PDT) In-Reply-To: <1307034352.2193.52.camel@localhost> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <1307034352.2193.52.camel@localhost> Date: Thu, 2 Jun 2011 14:34:25 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016e68fcec4fdc97404a4bee216 Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:34:27 -0000 --0016e68fcec4fdc97404a4bee216 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 1:05 PM, Matt McCutchen wrote: > On Wed, 2011-06-01 at 17:10 -0400, Phillip Hallam-Baker wrote: > > The reason CAA has the elements referring to client side enforcement > > is to alert deployers and implementers to the fact that the criteria > > for issue and enforcement are different. An existing certificate must > > be valid for use even if the CA has lost its issue privileges. > > > > So it is a bad idea to propose a specification that does not support > > both use cases. > > You are rather glibly coupling (1) the desire to discourage implementers > from misapplying the issuance constraints as relying party constraints > and (2) the potential utility of relying party constraints. I think we > can all agree that in IETF protocol work, discouraging the > misapplication of a scheme for A to B is not grounds for introducing > dummy functionality for B. Hence (1) is null and relying party > enforcement in CAA must stand on its own merits, in light of potential > overlap with DANE. I think that what we can all agree on is that it would be a good thing if the DANE WG and the PKIX WG eventually arrive at a common view of the problem as a whole. > > I have also proposed merging the two approaches. However we have a > > serious obstacle to achieving that. > > > > My strong belief is that any IETF standard must be designed to > > interoperate with other IETF standards. So I regard the following to > > be essential: > > > > * 100% compatibility with all DNS features including wildcards, CNAME, > > DNAME and SRV > > DANE (TLSA) and SRV are not compatible, but composable: DANE comes into > play after SRV discovery is completed. I consider compatibility with > wildcards and CNAME/DNAME to be essential for DANE too and just filed a > ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/24). Are there > other relevant "DNS features"? I agree that they need to be composable. But that does not necessarily mean that they take place entirely independently or that DANE always follows SRV. The reason is that I have been working on the problem of making wildcard records work correctly with prefix records for some time and I think the fix for the problem of SRV prefix records is the same as the one we should adopt for DANE. Basically the problem is that prefix records only work as expected when applied to a canonical name. The solution that looks most promising to me therefore is that a DNS record should always take a prefix record or it should never take a prefix record and that the discovery process should always begin with an unprefixed name. When a DNS client attempts to resolve an unprefixed name the result will be one of the following 1) The name does not resolve at all 2) The name is found to be canonical 3) The name was not canonical and is mapped to a canonical name So either the resolution process will halt after the first resolution attempt or there will be an unprefixed name to continue the resolution process. So what it comes down to is how you deal with the corner cases such as the need to support finer grained constraints. At the moment DANE only supports one level of granularity but the mechanism used to do so is broken because it does not work with wildcards and aliases. I think that when DANE is fixed to work with wildcards and aliases it is going to be necessary to have a two phase approach as outlined above which suggests a discovery strategy that has two levels of granularity so that constraints can be specified at the domain level or the host/port level and that the host/port level is only consulted in the cases where a site determines it is necessary to use finer granularity. > > * Use syntactic forms that are compatible with the protocols that it > > is designed to interoperate with, i.e. PKIX > > > > * Use algorithm identifiers that are compatible with the protocols > > that it is designed to interoperate with. > > CAA/DANE tools will be interoperable with one another no matter what > syntactic forms or algorithm identifiers are used. What you are talking > about is homogeneity of design, not interoperability. And AIUI, the > DANE group chose homogeneity with DNS over homogeneity with PKIX. I > think this is appropriate in view of the possible future use of DANE > with non-PKIX TLS "certificate types". > Well I have been involved in SDSI/SPKI, PGP, XKMS and SAML which have all attempted to play that game. Other than SAML I can't see that it was much of a success and SAML only succeeded because it offers a completely different value proposition. Most people don't even realize that the SAML assertion structure is a generalization of PKIX. In retrospect I now regret the fact that we effectively forked the algorithm registry in XML Signature. We ended up creating a completely parallel set of algorithm IDs to maintain when we could have simply reused the OID assignments with the OID: URI type. I believe that the correct way to view DANE is as part of the application layer framework and that it should therefore adopt application layer framework tropes. DANE has to work with the TLS and PKIX Working Groups. It is probably not a good thing if it ends up having to have extensive discussions with the DNS world. That would probably mean that there is something wrong. -- Website: http://hallambaker.com/ --0016e68fcec4fdc97404a4bee216 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 2, 2011 at 1:05 PM, Matt McC= utchen <matt= @mattmccutchen.net> wrote:
On Wed, 2011-06-01 at 17:10 -0400, Phillip Hallam-Baker w= rote:
> The reason CAA has the elements referring to client side enforcement > is to alert deployers and implementers to the fact that the criteria > for issue and enforcement are different. An existing certificate must<= br> > be valid for use even if the CA has lost its issue privileges.
>
> So it is a bad idea to propose a specification that does not support > both use cases.

You are rather glibly coupling (1) the desire to discourage implement= ers
from misapplying the issuance constraints as relying party constraints
and (2) the potential utility of relying party constraints. =A0I think we can all agree that in IETF protocol work, discouraging the
misapplication of a scheme for A to B is not grounds for introducing
dummy functionality for B. =A0Hence (1) is null and relying party
enforcement in CAA must stand on its own merits, in light of potential
overlap with DANE.

I think that what we can= all agree on is that it would be a good thing if the DANE WG and the PKIX = WG eventually arrive at a common view of the problem as a whole.

=A0
> I have also proposed merging the two approaches. However we have a
> serious obstacle to achieving that.
>
> My strong belief is that any IETF standard must be designed to
> interoperate with other IETF standards. So I regard the following to > be essential:
>
> * 100% compatibility with all DNS features including wildcards, CNAME,=
> DNAME and SRV

DANE (TLSA) and SRV are not compatible, but composable: DANE comes in= to
play after SRV discovery is completed. =A0I consider compatibility with
wildcards and CNAME/DNAME to be essential for DANE too and just filed a
ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/24). =A0A= re there
other relevant "DNS features"?

I = agree that they need to be composable. But that does not necessarily mean t= hat they take place entirely independently or that DANE always follows SRV.=

The reason is that I have been working on the problem o= f making wildcard records work correctly with prefix records for some time = and I think the fix for the problem of SRV prefix records is the same as th= e one we should adopt for DANE.


Basically the problem is that prefix rec= ords only work as expected when applied to a canonical name.=A0
<= br>
The solution that looks most promising to me therefore is tha= t a DNS record should always take a prefix record or it should never take a= prefix record and that the discovery process should always begin with an u= nprefixed name.

When a DNS client attempts to resolve an unprefixed nam= e the result will be one of the following

1) The n= ame does not resolve at all
2) The name is found to be canonical<= /div>
3) The name was not canonical and is mapped to a canonical name=A0

So either the resolution process will halt after the = first resolution attempt or there will be an unprefixed name to continue th= e resolution process.

So what it comes down to is how you deal with the corne= r cases such as the need to support finer grained constraints. At the momen= t DANE only supports one level of granularity but the mechanism used to do = so is broken because it does not work with wildcards and aliases.

I think that when DANE is fixed to work with wildcards = and aliases it is going to be=A0necessary=A0to have a two phase approach as= outlined above which suggests a discovery strategy that has two levels of = granularity so that constraints can be specified at the domain level or the= host/port level and that the host/port level is only consulted in the case= s where a site determines it is necessary to use finer granularity.


=A0
> * Use syntactic forms that are compatible with the protocols that it > is designed to interoperate with, i.e. PKIX
>
> * Use algorithm identifiers that are compatible with the protocols
> that it is designed to interoperate with.

CAA/DANE tools will be interoperable with one another no matter what<= br> syntactic forms or algorithm identifiers are used. =A0What you are talking<= br> about is homogeneity of design, not interoperability. =A0And AIUI, the
DANE group chose homogeneity with DNS over homogeneity with PKIX. =A0I
think this is appropriate in view of the possible future use of DANE
with non-PKIX TLS "certificate types".

<= /div>
Well I have been involved in SDSI/SPKI, PGP, XKMS and SAML which = have all attempted to play that game. Other than SAML I can't see that = it was much of a success and SAML only succeeded because it offers a comple= tely different value proposition. Most people don't even realize that t= he SAML assertion structure is a generalization of PKIX.

In retrospect I now regret the fact that we effectively= forked the algorithm registry in XML Signature. We ended up creating a com= pletely parallel set of algorithm IDs to maintain when we could have simply= reused the OID assignments with the OID: URI type.

I believe that the correct way to view DANE is as= part of the application layer framework and that it should therefore adopt= application layer framework tropes. DANE has to work with the TLS and PKIX= Working Groups. It is probably not a good thing if it ends up having to ha= ve extensive discussions with the DNS world. That would probably mean that = there is something wrong.

--0016e68fcec4fdc97404a4bee216-- From hallam@gmail.com Thu Jun 2 11:41:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43B6E086A for ; Thu, 2 Jun 2011 11:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5y2R-UJ4Cf9 for ; Thu, 2 Jun 2011 11:41:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9294E078F for ; Thu, 2 Jun 2011 11:41:34 -0700 (PDT) Received: by gyf3 with SMTP id 3so585150gyf.31 for ; Thu, 02 Jun 2011 11:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5Q3B3UdgJ4gfxY55gcMjJ1GAJ2CX2D3ogkkzFEHuCs4=; b=bXNiDgVyppN8r/aN2KkbXe9DbIrLBCxrtpDIXU1tgK6NzyObt3qemjZJJV3u4Gr12/ hLgiq6hlbm7TTz74175cqCVp/1ekIErUvIcS1Q8STAFRo6vohKr/uNjeC4SXrmH8F30C aIKFYOl6Sg4++dCtfU7Ft3Ph3YQA87W4aE72g= 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=i34WIzzKwwHlaUAlTf4h5iLnVrp0Qp4Tfhz6u+jZkvmaFxviM45qRxYZcgmK0RmzD8 SO3F31dqED95zmj4vqrT6+wq3QaYbMjchAIraT2+XCkag3CQb3jG1inHs6tI8PmWvrD5 ADXuCYFgdmdCKKrHFHRoBX/kRU0k7UHpRMLBc= MIME-Version: 1.0 Received: by 10.101.11.14 with SMTP id o14mr695654ani.88.1307040092653; Thu, 02 Jun 2011 11:41:32 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 2 Jun 2011 11:41:32 -0700 (PDT) In-Reply-To: <201106021814.p52IEkZE003911@new.toad.com> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> Date: Thu, 2 Jun 2011 14:41:32 -0400 Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: multipart/alternative; boundary=0016e68fcec46e0a1004a4befca5 Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:41:35 -0000 --0016e68fcec46e0a1004a4befca5 Content-Type: text/plain; charset=ISO-8859-1 The issue is not laziness, the issue is being able to define a process that is actionable in 150 different countries with a lot of different languages and a lot of different legal systems. I can call up the CSO of Sony to authenticate their cert request but there is no guarantee that he is going to speak English. And even if he speaks English there is no guarantee that he is going to have the slightest notion of the existence of the project requiring the cert. Working out whether an employee of a company incorporated in Japan with the name Sony in the corporate name and a part of the Sony group is authorized to request a certificate for sony.com is distinctly non trivial even for an expert in Japanese law. The objective here is not to solve all these issues. But we can help flag the cases where there may be an issue. On Thu, Jun 2, 2011 at 2:14 PM, John Gilmore wrote: > CAA seems like a complete abuse of the domain name system to > communicate a domain owner's restriction to CA's that are too lazy to > access the domain's web site (or look up the domain in WHOIS), pick up > the phone, and call the domain owner to verify that they really > ordered this alleged certificate. > > Since that seems to be the state of the art in "certifying"... no > round-trip verification at all... why should we dignify that with an > otherwise useless DNS record, that by its own definition doesn't > communicate anything to anybody except a few hundred CA's worldwide? > > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68fcec46e0a1004a4befca5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The issue is not laziness, the issue is being able to define a process that= is actionable in 150 different countries with a lot of different languages= and a lot of different legal systems.

I can call up the= CSO of Sony to authenticate their cert request but there is no guarantee t= hat he is going to speak English. And even if he speaks English there is no= guarantee that he is going to have the slightest notion of the existence o= f the project requiring the cert.

Working out whether an employee of a company incorporat= ed in Japan with the name Sony in the corporate name and a part of the Sony= group is authorized to request a certificate for sony.com is distinctly non trivial even for an expert in Japanese la= w.


The objective here is not to solve all t= hese issues. But we can help flag the cases where there may be an issue.


On Thu, Jun 2, 2011 a= t 2:14 PM, John Gilmore <gnu@toad.com> wrote:
CAA seems like a complete abuse of the doma= in name system to
communicate a domain owner's restriction to CA's that are too lazy = to
access the domain's web site (or look up the domain in WHOIS), pick up<= br> the phone, and call the domain owner to verify that they really
ordered this alleged certificate.

Since that seems to be the state of the art in "certifying"... no=
round-trip verification at all... why should we dignify that with an
otherwise useless DNS record, that by its own definition doesn't
communicate anything to anybody except a few hundred CA's worldwide?
=A0 =A0 =A0 =A0John
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016e68fcec46e0a1004a4befca5-- From matt@mattmccutchen.net Thu Jun 2 11:49:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA90E0880 for ; Thu, 2 Jun 2011 11:49:52 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmToX5xho9dg for ; Thu, 2 Jun 2011 11:49:52 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 12CCFE087E for ; Thu, 2 Jun 2011 11:49:52 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id B656B51C069; Thu, 2 Jun 2011 11:49:51 -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=lyrfx2T4hc7xSz/vfM9wPxy/XsaGQ7mVzzykOqEP1LU yeKr51GBzBxES2lh1E93GyEPcrb0YWrslcpeH66XXYvuEnDIp5UTx7BzZWT37xW+ cc6ozdyP+BKvssSmbFi1dd/XbjBTqfXxdOVhMePbKJ69ZDLzpiGs9t/psL9GG6jI = 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=iU0KikfO9SZ+uz3fgVpiKpIUojM=; b=GyCdzS14o/ TdVALvD6V9NbK1mNlXXqPvDhvwr5JT5fSVsOAiEgJLWJuGPCleOPa0RYpt5qM9m9 7o2lREZYxiCZQ2xym1E25r38Ioj/T4eFCNIS7oipDTHtxGBK6cig0naxzfPKA4FR gEA1H/5X24OWFEHQPbUNkH1beex5Xiuqw= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 3DD0F51C063; Thu, 2 Jun 2011 11:49:51 -0700 (PDT) From: Matt McCutchen To: John Gilmore In-Reply-To: <201106021814.p52IEkZE003911@new.toad.com> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 14:49:49 -0400 Message-ID: <1307040589.2193.73.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:49:52 -0000 On Thu, 2011-06-02 at 11:14 -0700, John Gilmore wrote: > CAA seems like a complete abuse of the domain name system to > communicate a domain owner's restriction to CA's that are too lazy to > access the domain's web site (or look up the domain in WHOIS), pick up > the phone, and call the domain owner to verify that they really > ordered this alleged certificate. That is a mischaracterization. CAA can serve as an additional automated check for CAs that use either automated (typically email-based) domain control verification or manual verification, to catch mistakes in either process and provide a level of accountability. > Since that seems to be the state of the art in "certifying"... no > round-trip verification at all... why should we dignify that with an > otherwise useless DNS record, that by its own definition doesn't > communicate anything to anybody except a few hundred CA's worldwide? Why shouldn't we? The cost is minimal: another entry in the zone (which clients will never be bothered about unless they ask) and another bit in the NSEC. -- Matt From matt@mattmccutchen.net Thu Jun 2 12:20:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAFDE0860 for ; Thu, 2 Jun 2011 12:20: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSwIyU85cL9Y for ; Thu, 2 Jun 2011 12:20:56 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id F34FDE0853 for ; Thu, 2 Jun 2011 12:20:55 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id A613851C073; Thu, 2 Jun 2011 12:20:55 -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=iELso2qMbWKAoTS/iCa5kOJKdMIufLm9DKA387eaf+V knQW2I+uiJNhxzluPmaKZ6r7wH8/2MkkWMvYoMNonlohsAiF06HJB4INZ+92k51W ev1zZKBRtQEiJ4aPUb+ocqRgbmtBfcLcwG+wANMWiMToUC2hdynEBvAVcIG0mwv0 = 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=Fj8Aa/nQkVOG/LbQQypBfmmVlRk=; b=SykwPlJrbO GF58LoXBFPYy1lUi1pNlabJoQ14L5ZsHYHzIufi0dbCdw22rRxOly8r7Q+BYvA87 HM3hRowCf0FmmQGIeMwo1hJCdTFvY2ppj3ALz4E9Lbzptzd9CWcZroIhnSKLi+gR U6mbyuANjb+RaPHLERGqt2G0n8+Fcf7Ho= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 86FEA51C063; Thu, 2 Jun 2011 12:20:54 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <1307034352.2193.52.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 15:20:52 -0400 Message-ID: <1307042452.2193.92.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: [dane] Possible shortcomings of DANE compared to CAA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 19:20:57 -0000 On Thu, 2011-06-02 at 14:34 -0400, Phillip Hallam-Baker wrote: > On Thu, Jun 2, 2011 at 1:05 PM, Matt McCutchen > wrote: > On Wed, 2011-06-01 at 17:10 -0400, Phillip Hallam-Baker wrote: > > The reason CAA has the elements referring to client side > enforcement > > is to alert deployers and implementers to the fact that the > criteria > > for issue and enforcement are different. An existing > certificate must > > be valid for use even if the CA has lost its issue > privileges. > > > > So it is a bad idea to propose a specification that does not > support > > both use cases. > > > You are rather glibly coupling (1) the desire to discourage > implementers > from misapplying the issuance constraints as relying party > constraints > and (2) the potential utility of relying party constraints. I > think we > can all agree that in IETF protocol work, discouraging the > misapplication of a scheme for A to B is not grounds for > introducing > dummy functionality for B. Hence (1) is null and relying > party > enforcement in CAA must stand on its own merits, in light of > potential > overlap with DANE. > I think that what we can all agree on is that it would be a good thing > if the DANE WG and the PKIX WG eventually arrive at a common view of > the problem as a whole. Yes, but I'm not holding my breath. Some of us just want TLS server authentication that is worth a ____. My point that you quoted stands. > > I have also proposed merging the two approaches. However we > have a > > serious obstacle to achieving that. > > > > My strong belief is that any IETF standard must be designed > to > > interoperate with other IETF standards. So I regard the > following to > > be essential: > > > > * 100% compatibility with all DNS features including > wildcards, CNAME, > > DNAME and SRV > > > DANE (TLSA) and SRV are not compatible, but composable: DANE > comes into > play after SRV discovery is completed. I consider > compatibility with > wildcards and CNAME/DNAME to be essential for DANE too and > just filed a > ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/24). > Are there > other relevant "DNS features"? > > > I agree that they need to be composable. But that does not necessarily > mean that they take place entirely independently or that DANE always > follows SRV. > > > The reason is that I have been working on the problem of making > wildcard records work correctly with prefix records for some time and > I think the fix for the problem of SRV prefix records is the same as > the one we should adopt for DANE. I agree that SRV and DANE should use the same approach. That does not entail using the same record, which would unnecessarily couple the processes. I prefer the current design with SRV before DANE for the reasons I previously gave (https://www.ietf.org/mail-archive/web/keyassure/current/msg01715.html). > The solution that looks most promising to me therefore is that a DNS > record should always take a prefix record or it should never take a > prefix record and that the discovery process should always begin with > an unprefixed name. [...] The right place to discuss the details would be at https://trac.tools.ietf.org/wg/dane/trac/ticket/24 . > > * Use syntactic forms that are compatible with the protocols > that it > > is designed to interoperate with, i.e. PKIX > > > > * Use algorithm identifiers that are compatible with the > protocols > > that it is designed to interoperate with. > > > CAA/DANE tools will be interoperable with one another no > matter what > syntactic forms or algorithm identifiers are used. What you > are talking > about is homogeneity of design, not interoperability. And > AIUI, the > DANE group chose homogeneity with DNS over homogeneity with > PKIX. I > think this is appropriate in view of the possible future use > of DANE > with non-PKIX TLS "certificate types". > > > Well I have been involved in SDSI/SPKI, PGP, XKMS and SAML which have > all attempted to play that game. Other than SAML I can't see that it > was much of a success and SAML only succeeded because it offers a > completely different value proposition. Most people don't even realize > that the SAML assertion structure is a generalization of PKIX. In my view, the reason PKIX/TLS succeeded is that the tools were widely available and braindead easy: urlopen("https://hallambaker.com/"). And DANE can be a drop-in replacement, as demonstrated by my prototype. > In retrospect I now regret the fact that we effectively forked the > algorithm registry in XML Signature. We ended up creating a completely > parallel set of algorithm IDs to maintain when we could have simply > reused the OID assignments with the OID: URI type. Valid point. But I don't see this becoming a major obstacle for DANE. > I believe that the correct way to view DANE is as part of the > application layer framework and that it should therefore adopt > application layer framework tropes. I don't follow this argument (not that I would strongly argue the opposite either). For a flippant example, MX records do not consist of an RFC 822-format headers giving the host name and priority. > DANE has to work with the TLS and PKIX Working Groups. It is probably > not a good thing if it ends up having to have extensive discussions > with the DNS world. That would probably mean that there is something > wrong. A scheme for TLS server authentication obviously has to work with TLS. >From the perspective of DANE, the only claim to fame of PKIX is that it was the first certificate type to be supported by TLS and is still overwhelmingly the most popular. Hence, I don't think design homogeneity with PKIX should be a goal for parts of DANE that are not PKIX-specific. -- Matt From hallam@gmail.com Thu Jun 2 13:56:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9ABE08CB for ; Thu, 2 Jun 2011 13:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJEJ7tcu02Tn for ; Thu, 2 Jun 2011 13:56:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B38A2E07F3 for ; Thu, 2 Jun 2011 13:56:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so1233582vxg.31 for ; Thu, 02 Jun 2011 13:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=fnapgzNE9HQi/LgjDdkMCwTf2vMM9G9+A8NShBbwkfA=; b=NmwSv/O3mnCFbVYSz8gxVEye5d0g7V/DNgtB58lwqG7v64zUky3PuwUy3enMX+GnpH 37CAJNPegqwzqtjlsWVXwg5OPiHmG+DbYbny8E69mDNYXn8kH81ANRjio56NQ+lLOumy Q+43jjoHb4V0sLmhk68Cj6gJBXtiremzja7pI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=D349GHW0ZZ9F6ogNHopjKphE+dHEQBgaZHl84vwP1D35Zf3tXI6RSvZmawDdG/ra3L BisLIWzAssKM1NE9bSZ9JVIZjyFbzl2gXOXoZfZN0ZLSWLdj00z9DJ2IcPwveTdLAdv3 PVIiKydsoIVZSJlmHyUgbmf2w1KqRt+TfpQao= MIME-Version: 1.0 Received: by 10.52.96.104 with SMTP id dr8mr1525807vdb.214.1307048204177; Thu, 02 Jun 2011 13:56:44 -0700 (PDT) Received: by 10.52.182.65 with HTTP; Thu, 2 Jun 2011 13:56:44 -0700 (PDT) Date: Thu, 2 Jun 2011 16:56:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=20cf307c9f50ea101004a4c0df3b Cc: dane@ietf.org Subject: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 20:56:45 -0000 --20cf307c9f50ea101004a4c0df3b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 3:20 PM, Matt McCutchen wrote: > > In my view, the reason PKIX/TLS succeeded is that the tools were widely > available and braindead easy: urlopen("https://hallambaker.com/"). And > DANE can be a drop-in replacement, as demonstrated by my prototype. > We are in agreement, more or less. The difference being that I am working at one level higher in abstraction. My objective is to eventually have a library that can resolve http://hallambaker.com/ and deliver the best connection offered by the service that my client library can consume with respect to both security and robustness. This then makes it much easier to interface this technology with a scripting language like perl or tcl or javascript. The way I would do it is as follows: 0) Starting conditions Domain to connect to: hallambaker.com SRV prefix of protocol: _http._tcp Default port assignment (if defined): 80 1) Resolve DANE1 RR for hallambaker.com * If not found then terminate * If the DANE1 record does not specify greater granularity information then discovery is complete * If hallambaker.com was an alias or a wildcard name then set the variable to the canonical name value returned * if the DANE1 record indicates that the additional data is port based then set the value of to the decimal port number, otherwise set the value of to the SRV prefix. 2) Resolve DANE2 RR for domain . * If not found then terminate This particular approach supports wildcards, aliases and different trust constraints for different services. More importantly for SRV fans the DANE1 record can have a flag to say 'use SRV discovery' or 'use URI discovery'. This allows the use of extended discovery to be added to legacy protocols that did not originally use SRV. It also allows the SRV discovery process to be made compliant with alias and wildcard records. For a more details description of this approach see: http://tools.ietf.org/html/draft-hallambaker-esrv-01 As a practical matter I can't see how we can make CAA and DANE work under a single RR format unless there is a way for DANE to address both generic statements that apply to the whole domain and service specific statements. It has to be possible to make a CAA statement that applies to the whole domain. -- Website: http://hallambaker.com/ --20cf307c9f50ea101004a4c0df3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 2, 2011 at 3:20 PM, Matt McC= utchen <matt= @mattmccutchen.net> wrote:
In my view, the reason PKIX/TLS succeeded is that the tools were widely
available and braindead easy: urlopen("https://hallambaker.com/"). =A0And
DANE can be a drop-in replacement, as demonstrated by my prototype.

We are in agreement, more or less. The differe= nce being that I am working at one level higher in abstraction.

My objective is to eventually have a library that can resolv= e http://hallambaker.com/ and deliv= er the best connection offered by the service that my client library can co= nsume with respect to both security and robustness.

This then makes it much easier to interface this techno= logy with a scripting language like perl or tcl or javascript.

The way I would do it is as follows:

0) Starting conditions

Domain to co= nnect to: hallambaker.com
= SRV prefix of protocol: _http._tcp
Default port assignment (if de= fined): 80

1) Resolve DANE1 RR for <domain> hallambaker.com

* If not fo= und then terminate
* If the DANE1 record does not specify greater= granularity information then discovery is complete=A0
* If hallambaker.com was an ali= as or a wildcard name then set the variable <canonical> to the canoni= cal name value returned

* if the DANE1 record indi= cates that the additional data is port based then set the value of <pref= ix> to the decimal port number, otherwise set the value of <prefix>= ; to the SRV prefix.

2) Resolve DANE2 RR for domain <prefix>.<canon= ical>
* If not found then terminate

<= br>
This particular approach supports wildcards, aliases and diff= erent trust constraints for different services.

More importantly for SRV fans the DANE1 record can have= a flag to say 'use SRV discovery' or 'use URI discovery'. = This allows the use of extended discovery to be added to legacy protocols t= hat did not originally use SRV. It also allows the SRV discovery process to= be made compliant with alias and wildcard records.

For a more details description of this approach see:


As a practical matter I can't see how we can ma= ke CAA and DANE work under a single RR format unless there is a way for DAN= E to address both generic statements that apply to the whole domain and ser= vice specific statements. It has to be possible to make a CAA statement tha= t applies to the whole domain.
--
Website: http://hallambaker.com/=

--20cf307c9f50ea101004a4c0df3b-- From matt@mattmccutchen.net Thu Jun 2 14:31:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659EAE08BD for ; Thu, 2 Jun 2011 14:31:41 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C20ImDYKp4n for ; Thu, 2 Jun 2011 14:31:39 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC5FE08BC for ; Thu, 2 Jun 2011 14:31:39 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id D81C570407A; Thu, 2 Jun 2011 14:31:38 -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=A2cnVA6VeDR7lztEIAjOeCUBplPzGk1ojUfi0KJHfpM Glk6wlua99Bx/w9Z2P299dah+2pLrKb2XClCAWuLZr957ktSmUIlB3lsbh5+/GAr VFxwDLm/U4darctDKRwC+B9X+3w23KgpRJYkwjo4o1N3St8REZ6b/XTqKKvVrXS4 = 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=s0mT2voYSl1ehXNfC+BU8aO3Ls4=; b=BBpX/EVPal ZxhOkrSr4Ejp6doMFPn+w4PY5wO1j7tR/7ZffUfiG8Tg8mUlDUhbrNsIuXYuJzOW BD99aqmE8V8f7eozoRNchmcgy5jBZpSx6nTH2u94qVhs5F6mCyzK4xOFR4KaHqIn 4tshXc/7WprW/kt0VMn7cWI0Fi8mzYbHI= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 55D7A704078; Thu, 2 Jun 2011 14:31:38 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 17:31:36 -0400 Message-ID: <1307050296.2193.108.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:31:41 -0000 On Thu, 2011-06-02 at 16:56 -0400, Phillip Hallam-Baker wrote: > My objective is to eventually have a library that can resolve > http://hallambaker.com/ and deliver the best connection offered by the > service that my client library can consume with respect to both > security and robustness. > > This then makes it much easier to interface this technology with a > scripting language like perl or tcl or javascript. [...] I would like better service discovery too. But I still do not understand what you hope to gain design-wise by coupling DANE with service discovery. I explained at https://www.ietf.org/mail-archive/web/keyassure/current/msg01715.html why I believe (DNS name, transport protocol, port) is the right set of inputs to DANE. It follows that DANE should run after that tuple is determined, i.e., after any applicable service discovery. My question stands: "Can you point to any concrete use cases that would benefit from your proposal?" Security-related assertions with purposes closer to the application level than simple TLS server authentication should be pursued separately from DANE and indeed may be appropriate to integrate with service discovery. > As a practical matter I can't see how we can make CAA and DANE work > under a single RR format unless there is a way for DANE to address > both generic statements that apply to the whole domain and service > specific statements. It has to be possible to make a CAA statement > that applies to the whole domain. Yes, DANE needs that too. One case is stated in https://trac.tools.ietf.org/wg/dane/trac/ticket/23 , but the considerations for the general case are not really different. -- Matt From hallam@gmail.com Thu Jun 2 14:37:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F084AE08B6 for ; Thu, 2 Jun 2011 14:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 242hpeauvmE6 for ; Thu, 2 Jun 2011 14:37:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37E98E087A for ; Thu, 2 Jun 2011 14:37:33 -0700 (PDT) Received: by vws12 with SMTP id 12so1259958vws.31 for ; Thu, 02 Jun 2011 14:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MhH7oGEZ+72GAYIYlWLA4t7+z8YVbkFsAsCbK/M2vwA=; b=nW38f4f/q86rnREANYm4Yk0bxk6ZgJ1GIEYxR1EspQU7BhW0ny14J08n3zBq7CJq6x kz5M4EDecUtDJSX+Gj5uDG9g44hxUMi1RSQwYm+OkWH/3N7K+99y1aQS6lRHdXFU2juH YyEPnpU7IdJXY0CiHzFmBnLx7fQk8EVU3+5Lk= 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=G6NHeYVnCTwhiI3EojJwD8iH0HDfTawp1q2xun6ubOdnWMeTgu8VPTM8jNX3aOLEpW cpsSKmoLAvb7APUkh2gJ4lg/8D83QY05uPhc5tOu6lj22UdlOSMZqj5h4sPO45Hc4rkP csJX8Kj2vw0vJyiY1+OZjrs9B1rXr7LAcitsw= MIME-Version: 1.0 Received: by 10.52.115.10 with SMTP id jk10mr1633100vdb.294.1307050652588; Thu, 02 Jun 2011 14:37:32 -0700 (PDT) Received: by 10.52.182.65 with HTTP; Thu, 2 Jun 2011 14:37:32 -0700 (PDT) In-Reply-To: <1307050296.2193.108.camel@localhost> References: <1307050296.2193.108.camel@localhost> Date: Thu, 2 Jun 2011 17:37:32 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=bcaec547cb81d9d94204a4c1714d Cc: dane@ietf.org Subject: Re: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:37:36 -0000 --bcaec547cb81d9d94204a4c1714d Content-Type: text/plain; charset=ISO-8859-1 1) Efficiency. My approach is much more efficient than yours when measured over the whole transaction. The difference is even greater when the DNS is being used to deliver more than just keys. Knowing that TLS is offered on a connection at all is much more important to me than the strength of the key. If the client can't work out that SSL is required at all the strength of the key is moot. 2) Ease of Administration My approach is much simpler to manage for the typical site since there is an option of specifying global properties. On Thu, Jun 2, 2011 at 5:31 PM, Matt McCutchen wrote: > On Thu, 2011-06-02 at 16:56 -0400, Phillip Hallam-Baker wrote: > > My objective is to eventually have a library that can resolve > > http://hallambaker.com/ and deliver the best connection offered by the > > service that my client library can consume with respect to both > > security and robustness. > > > > This then makes it much easier to interface this technology with a > > scripting language like perl or tcl or javascript. [...] > > I would like better service discovery too. But I still do not > understand what you hope to gain design-wise by coupling DANE with > service discovery. I explained at > https://www.ietf.org/mail-archive/web/keyassure/current/msg01715.html > why I believe (DNS name, transport protocol, port) is the right set of > inputs to DANE. It follows that DANE should run after that tuple is > determined, i.e., after any applicable service discovery. My question > stands: "Can you point to any concrete use cases that would benefit from > your proposal?" > > Security-related assertions with purposes closer to the application > level than simple TLS server authentication should be pursued separately > from DANE and indeed may be appropriate to integrate with service > discovery. > > > As a practical matter I can't see how we can make CAA and DANE work > > under a single RR format unless there is a way for DANE to address > > both generic statements that apply to the whole domain and service > > specific statements. It has to be possible to make a CAA statement > > that applies to the whole domain. > > Yes, DANE needs that too. One case is stated in > https://trac.tools.ietf.org/wg/dane/trac/ticket/23 , but the > considerations for the general case are not really different. > > -- > Matt > > -- Website: http://hallambaker.com/ --bcaec547cb81d9d94204a4c1714d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 1) Efficiency.

My approach is much more efficient than y= ours when measured over the whole transaction. The difference is even great= er when the DNS is being used to deliver more than just keys. Knowing that = TLS is offered on a connection at all is much more important to me than the= strength of the key. If the client can't work out that SSL is required= at all the strength of the key is moot.


2) Ease of Administration

=
My approach is much simpler to manage for the typical site since= there is an option of specifying global properties.


On Thu, Jun 2, 2011 at 5:31 PM, Matt McCutchen <= span dir=3D"ltr"><matt@mattmcc= utchen.net> wrote:
On Thu, 2011-06-02 at 16:56 -0400, Phillip Hallam-Baker w= rote:
> My objective is to eventually have a library that can resolve
> http://hallambak= er.com/ and deliver the best connection offered by the
> service that my client library can consume with respect to both
> security and robustness.
>
> This then makes it much easier to interface this technology with a
> scripting language like perl or tcl or javascript. [...]

I would like better service discovery too. =A0But I still do not
understand what you hope to gain design-wise by coupling DANE with
service discovery. =A0I explained at
https://www.ietf.org/mail-archive/web/keyassure/cu= rrent/msg01715.html
why I believe (DNS name, transport protocol, port) is the right set of
inputs to DANE. =A0It follows that DANE should run after that tuple is
determined, i.e., after any applicable service discovery. =A0My question stands: "Can you point to any concrete use cases that would benefit fr= om
your proposal?"

Security-related assertions with purposes closer to the application
level than simple TLS server authentication should be pursued separately from DANE and indeed may be appropriate to integrate with service
discovery.

> As a practical matter I can't see how we can make CAA and DANE wor= k
> under a single RR format unless there is a way for DANE to address
> both generic statements that apply to the whole domain and service
> specific statements. It has to be possible to make a CAA statement
> that applies to the whole domain.

Yes, DANE needs that too. =A0One case is stated in
https://trac.tools.ietf.org/wg/dane/trac/ticket/23 , but the
considerations for the general case are not really different.

--
Matt




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

--bcaec547cb81d9d94204a4c1714d-- From matt@mattmccutchen.net Thu Jun 2 14:49:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56100E0833 for ; Thu, 2 Jun 2011 14:49:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuTNu5xcT3dp for ; Thu, 2 Jun 2011 14:49:50 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BB09EE07AE for ; Thu, 2 Jun 2011 14:49:50 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 937E9634073; Thu, 2 Jun 2011 14:49:50 -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=r6oBIRM2EQzYHavqG/e9i9U4Eao60zGNM7EHnXt7dSF +Pyb2HzgB54dYWbDymEaBSmaEqomSFT5Mk9Pw6rJ6IBcOiDTvP1Dznmq0cJmmj7i 8ehwtz1HCUb9r6HT5+FHn3g2RK5uso8bjQ9oGd1cob/LNy8v/364PhlaojXBHP0g = 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=sNeRb0bPJ2yCbcDyARRlS4+j+2c=; b=YH1oK6OQxH fhJStjT4/Z17pI6X6E/dU/uK3I4BvLQUCKS3e9Yi9xigFmGEM4HafVi3yaVJS9+i Ld83Pf6xOjaJLijDBgI9YOGj7IpWW7tExDNhxuUSFmklf0Zy1Y4X/PmX+HZXpjBp AEg6FKnAM3b+xq+ebQTCpUt3c2aBqJM04= Received: from [192.168.1.40] (pool-74-96-41-104.washdc.east.verizon.net [74.96.41.104]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 118F963406E; Thu, 2 Jun 2011 14:49:49 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <1307050296.2193.108.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 17:49:43 -0400 Message-ID: <1307051383.2193.122.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 21:49:51 -0000 On Thu, 2011-06-02 at 17:37 -0400, Phillip Hallam-Baker wrote: > 1) Efficiency. > > My approach is much more efficient than yours when measured over the > whole transaction. The difference is even greater when the DNS is > being used to deliver more than just keys. Are you talking about performance, economy of design, or what? In my mind, the performance issues would have to be pretty stark to outweigh the design considerations I stated. > Knowing that TLS is offered on a connection at all is much more > important to me than the strength of the key. If the client can't work > out that SSL is required at all the strength of the key is moot. Indeed, you need both, but it does not follow that they should be coupled. HASTLS or such will be a win. For now, we are getting by with the https: URI scheme and other out-of-band indications. > 2) Ease of Administration > > My approach is much simpler to manage for the typical site since there > is an option of specifying global properties. As I said, I intend for DANE to have that too. -- Matt From hallam@gmail.com Thu Jun 2 15:22:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8AE072F for ; Thu, 2 Jun 2011 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyv67yHspmaP for ; Thu, 2 Jun 2011 15:22:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C51F9E06BC for ; Thu, 2 Jun 2011 15:22:12 -0700 (PDT) Received: by vxg33 with SMTP id 33so1293791vxg.31 for ; Thu, 02 Jun 2011 15:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BaIVzYsPV+HG70ektUDqA99RFhFJwUoAnF5mjV5WGYw=; b=Oce5SqT5XqeB8Ez6/Q2WL6hO542psqf++nXzgNwLLQq5qTJpTb7852lxkywQ4zCw1Q FJaKW1KBFw8zg7jhlTESaT0hLGLyfsGO8ekW8wDvQK+8djuAu0Smc7hfOVr9cuErLuUI IVIAEGOW4bLe5beqsl3LCSSod1g25bvREKAbk= 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=xxpNuaUy579BKcBgZLKL3UhEPJR8wrTbNZ/h82xqFophwsie/ygTOTw6Pp2nnaP4J+ XkpKLNl9Id2+cx9bkpmsPe04+zz8/oaCmoVl7+78V5B6ArymTVLz4r73wWn7Ioawcbto 7obxydnwSGOQMpSwcwLTpQkZf4ph6RhYGXxDE= MIME-Version: 1.0 Received: by 10.52.73.234 with SMTP id o10mr1673872vdv.174.1307053331893; Thu, 02 Jun 2011 15:22:11 -0700 (PDT) Received: by 10.52.182.65 with HTTP; Thu, 2 Jun 2011 15:22:11 -0700 (PDT) In-Reply-To: <1307051383.2193.122.camel@localhost> References: <1307050296.2193.108.camel@localhost> <1307051383.2193.122.camel@localhost> Date: Thu, 2 Jun 2011 18:22:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=20cf3071cc3e8ccf1904a4c2118a Cc: dane@ietf.org Subject: Re: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:22:13 -0000 --20cf3071cc3e8ccf1904a4c2118a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 5:49 PM, Matt McCutchen wrote: > On Thu, 2011-06-02 at 17:37 -0400, Phillip Hallam-Baker wrote: > > 1) Efficiency. > > > > My approach is much more efficient than yours when measured over the > > whole transaction. The difference is even greater when the DNS is > > being used to deliver more than just keys. > > Are you talking about performance, economy of design, or what? In my > mind, the performance issues would have to be pretty stark to outweigh > the design considerations I stated. I don't see that you have specified anything more than asserting you like your way better. I don't see that you have given any justification for your approach at all. In my view the criteria that are applicable here are functionality, performance and ease of administration. What objective criteria are you applying? Could you avoid a reference to an earlier reply as I have read those and don't see any objective criteria there. > > Knowing that TLS is offered on a connection at all is much more > > important to me than the strength of the key. If the client can't work > > out that SSL is required at all the strength of the key is moot. > > Indeed, you need both, but it does not follow that they should be > coupled. HASTLS or such will be a win. For now, we are getting by with > the https: URI scheme and other out-of-band indications. If you want performance then a single framework that can support both types of data will be more efficient. > > 2) Ease of Administration > > > > My approach is much simpler to manage for the typical site since there > > is an option of specifying global properties. > > As I said, I intend for DANE to have that too. > Well propose an alternative mechanism for doing so and we can have a bake off. But at the moment mine is the only concrete proposal that meets all the criteria you specify. -- Website: http://hallambaker.com/ --20cf3071cc3e8ccf1904a4c2118a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 2, 2011 at 5:49 PM, Matt McC= utchen <matt= @mattmccutchen.net> wrote:
On Thu, 2011-06-02 at 17:37 -0400, Phillip Hallam-Baker w= rote:
> 1) Efficiency.
>
> My approach is much more efficient than yours when measured over the > whole transaction. The difference is even greater when the DNS is
> being used to deliver more than just keys.

Are you talking about performance, economy of design, or what? =A0In = my
mind, the performance issues would have to be pretty stark to outweigh
the design considerations I stated.

I don&#= 39;t see that you have specified anything more than asserting you like your= way better. I don't see that you have given any justification for your= approach at all.

In my view the criteria that are applicable here are fu= nctionality, performance and ease of administration.=A0

What objective criteria are you applying? Could you avoid a reference= to an earlier reply as I have read those and don't see any objective c= riteria there.

=A0
> Knowing that TLS is offered on a connection at all is much more
> important to me than the strength of the key. If the client can't = work
> out that SSL is required at all the strength of the key is moot.

Indeed, you need both, but it does not follow that they should be
coupled. =A0HASTLS or such will be a win. =A0For now, we are getting by wit= h
the https: URI scheme and other out-of-band indications.
<= br>
If you want performance then a single framework that can supp= ort both types of data will be more efficient.


=A0
> 2) Ease of Administration
>
> My approach is much simpler to manage for the typical site since there=
> is an option of specifying global properties.

As I said, I intend for DANE to have that too.
=
Well propose an alternative mechanism for doing so and we can have a ba= ke off.

But at the moment mine is the only concrete prop= osal that meets all the criteria you specify.

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

--20cf3071cc3e8ccf1904a4c2118a-- From chris@eff.org Thu Jun 2 15:57:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939BFE0879 for ; Thu, 2 Jun 2011 15:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3T-wVZQJjFO for ; Thu, 2 Jun 2011 15:57:11 -0700 (PDT) Received: from mail1.eff.org (mail1.eff.org [64.147.188.4]) by ietfa.amsl.com (Postfix) with ESMTP id 14F69E08FC for ; Thu, 2 Jun 2011 15:57:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Chris Palmer In-Reply-To: <1307037908.2193.66.camel@localhost> Date: Thu, 2 Jun 2011 15:57:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <43A8F71A-474D-484D-82F3-46D9A40A296C@eff.org> References: <1307034785.2193.54.camel@localhost> <1307037908.2193.66.camel@localhost> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] OT - Weak links X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:57:11 -0000 On Jun 2, 2011, at 11:05 AM, Matt McCutchen wrote: > It doesn't seem like maintaining a secure > customer admin interface should cost more than $9.95 per domain at the > scale of a large registrar like mine. And yet... -- Chris Palmer Technology Director, Electronic Frontier Foundation https://www.eff.org/code From matt@mattmccutchen.net Thu Jun 2 17:31:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C34E0881 for ; Thu, 2 Jun 2011 17:31:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftwuinVSYf+3 for ; Thu, 2 Jun 2011 17:31:05 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E2C84E06AB for ; Thu, 2 Jun 2011 17:31:05 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 93A4734806F; Thu, 2 Jun 2011 17:31:05 -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=BwjrzggiNJSRrtow/k+bw3RLnh/xbj/pTEs7jXhhJFf JzvFjr3Ibh5RH11lCzPsKvqGsmHlkidhlUxojivOocQ7qpyG08KDrwwKdMmK2qS/ sgXzxvLujdqlmATkv3OrFLpa7ObXG6pMdfELfUK39qGYwnanOveQG7JBnO8uKKOo = 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=wF1iQ4yOahmaI8PPvPjH/qLAxhE=; b=WxBzpqNFfG yxKxbhVT+3r4k0UHEuYst2fSAHO6RT3HpOoLhL9iff0ofI4kjY7AmtzJO1H/Vzuf fVBglNQZf8w0rzeqvLvaW9zmffGTZB0Yt7y0xDNlxy9Xr93jrioA6nDVxXVOjmHU DZcFuoIHp5JRvjn6sw5CEfoaa4Nd0RwY8= Received: from [192.168.1.40] (pool-96-231-3-192.washdc.east.verizon.net [96.231.3.192]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 240AF34806A; Thu, 2 Jun 2011 17:31:05 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <1307050296.2193.108.camel@localhost> <1307051383.2193.122.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Thu, 02 Jun 2011 20:31:03 -0400 Message-ID: <1307061063.2193.165.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 00:31:06 -0000 On Thu, 2011-06-02 at 18:22 -0400, Phillip Hallam-Baker wrote: > In my view the criteria that are applicable here are functionality, > performance and ease of administration.=20 >=20 > What objective criteria are you applying? Could you avoid a reference > to an earlier reply as I have read those and don't see any objective > criteria there. I agree with your list of functionality, performance, and ease of administration, though I am de-emphasizing performance for now because I don't think we have a good idea of how significant the performance issues will be. I would add ease of integration with existing tools. > I don't see that you have specified anything more than asserting you > like your way better. I don't see that you have given any > justification for your approach at all. In the message I previously linked, I asserted that (DNS name, transport protocol, port) should be the input to DANE because: (1) The client is bound to know these variables (at least if it does SNI). (2) Under the current design of IP, TCP, and SNI and in the absence of active attacks, the set of certificates that a client might see when contacting a TLS server is a function of these variables and no others. Hence there can be no benefit in making the TLSA data a function of other variables. I don't see certificate designation in draft-hallambaker-esrv-01. But suppose you added it using the existing levels in section 2, namely: - Domain: (name) - Service: (name, transport[?], service type) - Instance: (name, port, transport, service type) Then there would be no way for existing TLS clients that take the (name, transport, port) tuple as input to do a DANE lookup. Such clients include NSS tstclnt, OpenSSL s_client, and gnutls-cli. Traditionally, the port has not been used in the server ID check, but tstclnt in my modified NSS uses it for the DANE lookup. > If you want performance then a single framework that can support both > types of data will be more efficient. Maybe so. At this point, it's hard to tell how much it will matter. We'll have caches in various places, and either scheme in "optimized" mode would work in a single round trip. > Well propose an alternative mechanism for doing so and we can have a > bake off. >=20 > But at the moment mine is the only concrete proposal that meets all > the criteria you specify. Right, you got there first. I don't have a complete proposal that I'm happy with, but as a starting point consider the following: If a service type is given, perform service discovery (SRV, ESRV, or whatever). Once you have a port, if you are going to use TLS, do a DANE lookup. For DANE, and separately for service discovery if it would start with a prefixed name, canonicalize the unprefixed name first. On the DNS admin side: - To make a statement about a whole DNS subtree, use my script (deployed on mattmccutchen.net but not yet publicly released) that covers the subtree with DNS wildcards, so that the data will be returned for any name in the subtree. As I wrote at https://trac.tools.ietf.org/wg/dane/trac/ticket/23#comment:2, this is an ugly solution and I'm hoping for a better one. I was thinking of having the client scan the ancestors in DNS, but Ond=C5=99ej Sur=C3=BD thought t= hat was a bad idea (https://www.ietf.org/mail-archive/web/keyassure/current/msg01663.html) - If you have many names served by the same pool of servers (my favorite example is *.googleusercontent.com), first collect them with a wildcard CNAME and put the data at prefix extensions of the target of the CNAME. --=20 Matt From paul@xelerance.com Fri Jun 3 08:46:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899E1E0708 for ; Fri, 3 Jun 2011 08:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ1lmf4XGObL for ; Fri, 3 Jun 2011 08:46:15 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC3BFE06E9 for ; Fri, 3 Jun 2011 08:46:15 -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 515DE570DE; Fri, 3 Jun 2011 11:46:13 -0400 (EDT) Date: Fri, 3 Jun 2011 11:46:13 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.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: dane@ietf.org Subject: Re: [dane] CAA: Isn't this completely backwards? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 15:46:16 -0000 On Thu, 2 Jun 2011, Phillip Hallam-Baker wrote: > The issue is not laziness, the issue is being able to define a process that is actionable in 150 different countries with a lot of different languages and a lot of different > legal systems. > I can call up the CSO of Sony to authenticate their cert request but there is no guarantee that he is going to speak English. And even if he speaks English there is no > guarantee that he is going to have the slightest notion of the existence of the project requiring the cert. > > Working out whether an employee of a company incorporated in Japan with the name Sony in the corporate name and a part of the Sony group is authorized to request a certificate > for sony.com is distinctly non trivial even for an expert in Japanese law. If only we could add a DNS record in our zone and sign it to signifiy what our pubkey is... If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS lookup of the pubkey. Paul From matt@mattmccutchen.net Fri Jun 3 14:30:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4004E07D4; Fri, 3 Jun 2011 14:30:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQqVkDN31r+a; Fri, 3 Jun 2011 14:30:51 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id CF738E07F1; Fri, 3 Jun 2011 14:30:50 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 54D59280074; Fri, 3 Jun 2011 14:30:50 -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=kBid7frbiVNjvV0Wz1t1gt0sOcvuNVVonIrjH1Rf/DK Cxur4giBdvAMRZ7hY9hnoCC5PaFiXU2ARzqFB6LX2w7C3P0hSBoIkcMQ/+0R54kj MAE48eNC3XC3AGyN7b/6mxI1cqkWaWxukf7eZpXWw2pE0dmd84SjhdqHPhBouXeI = 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=b6knztUKFBA6dI8a3egqGzuaYQk=; b=qwsUw8XjOv DY048YvTRZIBTBSUjn9el6QFKO+e6wd7BPZUPt9tYo6R8OyNslViAA+fUSHws5Pb IML1FnM3hSMGpQ5KfNnFX1tyntJSt1MK9bsPMCDajV4IDKtXfq4yJBA7Df9ML4xA mVk0yleBoqdy0rm51VzgB5UgcfooR6rbg= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id BCDAC280063; Fri, 3 Jun 2011 14:30:49 -0700 (PDT) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 17:30:47 -0400 Message-ID: <1307136647.1999.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, dane@ietf.org Subject: [dane] CSRs in CAA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 21:30:52 -0000 On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote: > If only we could add a DNS record in our zone and sign it to signifiy what our pubkey is... > > If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey > needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS > lookup of the pubkey. For those who want to support legacy clients while making the maximum possible use of DNS, this is absolutely the thing to do, except I would use the CSR or even (CSR, requested signer cert). This is just to authenticate the entire request; the CA may only honor a subset of the CSR fields according to its policies. Organizations that have a close relationship with a CA may not feel the need to duplicate their requests to the CA in the DNS, but they may find the ancestor cert and cert policy constraints to be useful controls. Hence, I would keep those options as well. Let's take further discussion of CAA to the PKIX list. -- Matt From internet-drafts@ietf.org Fri Jun 3 15:21:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE93E080A; Fri, 3 Jun 2011 15:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp1yTIjYlfL4; Fri, 3 Jun 2011 15:21:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904B4E07F5; Fri, 3 Jun 2011 15:21:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603222131.23013.3917.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2011 15:21:31 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-07.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 22:21:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For TLS Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-07.txt Pages : 14 Date : 2011-06-03 TLS and DTLS use PKIX 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. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-07.txt From paul.hoffman@vpnc.org Fri Jun 3 15:23:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD193E07F5 for ; Fri, 3 Jun 2011 15:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZUJnYSQCqMk for ; Fri, 3 Jun 2011 15:23:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C60F2E07F2 for ; Fri, 3 Jun 2011 15:23:04 -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 p53MN3QP021781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 3 Jun 2011 15:23:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jun 2011 15:23:03 -0700 Message-Id: <2D11F142-435E-4930-90E5-FB4D46A778DB@vpnc.org> To: DANE WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Protocol version -07 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 22:23:05 -0000 Greetings again. Jakob and I have just published draft -07 because we = wanted to keep the WG rolling. We fully admit (here and in the draft) = that the use cases and requirements document isn't completely done, and = we will make more changes if needed based on future changes to that = document. Please note that there is another large hole in -07, namely about = DNSSEC. As the use cases document showed, DNSSEC is not needed in all = cases for TLSA. We started to make changes to that effect, but the task = of separating out when DNSSEC is and is not needed in the protocol is = fairly large, and we want to be sure that the wording we end up with = does not make someone think that they don't need DNSSEC for their use = case if they really do. If there is someone out there who is itching for = an interesting, focused editing task, let us know. One last thing: the diffs for this version against the last will look = awful. We did a major reorg to make the specification clearer to people = who have not been following the progress from -00, and we figured doing = it now was better than waiting until the end. --Paul Hoffman From matt@mattmccutchen.net Fri Jun 3 20:05:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0684DE075E; Fri, 3 Jun 2011 20:05:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXAJptyr8C6N; Fri, 3 Jun 2011 20:05:07 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 67F04E06FC; Fri, 3 Jun 2011 20:05:07 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 3B4D863406F; Fri, 3 Jun 2011 20:05:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Fip4awCH73BhXgswecHuzUUKmzFpR5ywHIWhHWQnYgC EVQ7KoGIP46dbamRi3+6qGrMB0EXNYs/gSboV7/ipd/sUGteZGSH77/NOdtMdS5F tcVzF2+/VMBdHwxHHxbOp+jF2nbTN4BG/Y2DhhLUIh+f/CxYngTuX/Se8hsoDC1E = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=g6/Cg/zqBZ0is7fScLLeFoKNXq0=; b=hmasKAPUP8 nsQmsxn1GFZXFGJBCX2gRkfdeuha8mBJWgrmJPk63HOLeWauOT9px+bUSMzLXD1q F5KydEO3NiEzkIVEAKEIa6nREwqDXiCtEtxO59CeZetyXGdliax7GtKUg3LUxuxZ JJZWBNutbxtsUBC39NzAegdLTGshGSRRw= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id CA2BC63406E; Fri, 3 Jun 2011 20:05:06 -0700 (PDT) From: Matt McCutchen To: pkix@ietf.org, dane In-Reply-To: <1307136647.1999.7.camel@localhost> References: <49989971-BCC3-4AB5-872C-85CC8D6B4685@princeton.edu> <201106021814.p52IEkZE003911@new.toad.com> <1307136647.1999.7.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Fri, 03 Jun 2011 23:05:04 -0400 Message-ID: <1307156704.1999.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] CSRs in CAA + automation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 03:05:08 -0000 On Fri, 2011-06-03 at 17:30 -0400, Matt McCutchen wrote: > On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote: > > If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey > > needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS > > lookup of the pubkey. > > For those who want to support legacy clients while making the maximum > possible use of DNS, this is absolutely the thing to do, except I would > use the CSR or even (CSR, requested signer cert). This is just to > authenticate the entire request; the CA may only honor a subset of the > CSR fields according to its policies. Do you all realize what we'll be able to do with such a protocol? Just give your web server access to update its DNS data via TSIG, and it can generate a key pair, poke the DANE records into DNS, and get itself a domain-validated certificate from your favorite CA. This functionality could be in the TLS server library. (Yes, Martin, I mean "TLS and associated technologies".) At a higher level, when you register a domain from $favorite_web_host, you could check a box and have them set up the whole nine yards: DNSSEC with DS submitted to the registry, TLS, DANE, a domain-validated certificate, strict transport security, and whatever else we cook up. Phill, this may be the "easy TLS adoption" you were looking forward to. -- Matt From matt@mattmccutchen.net Sat Jun 4 16:34:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2748A21F846F for ; Sat, 4 Jun 2011 16:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoG0dTQcgkt0 for ; Sat, 4 Jun 2011 16:34:01 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF9221F846C for ; Sat, 4 Jun 2011 16:33:58 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 4A83B10AFAA for ; Sat, 4 Jun 2011 16:33:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=qCXGt48Nc8V6cXIfPNsRS/BdqUoM/fk178TKTH+vWXI P52Es2MaeB03Ge5UwRQTcHIvWnURikqPrVXh5zqUA7ivCNC7SFxPP41PwSonsp7S 2At5QxfkVc6uKHKn/a/POL5bTIdHYnr1ifRCEIpr9i6dW9G/sSobPbomTWEUYvJ0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=flIJC6Ix3DNm+DeoM3fDK1oavUA=; b=mjKqAbO4fv Y6qLjy3AZs+cz4dUzNaVeraRAaTSFY2aRQc7m9df/1uoepLl8fi/FXAKea+Rm/8D QeXRriyempekFzFnrPjaeX56amuUNP4lifHrZD78CIIlFlilUIM4r2mDACuCRDtp yjrfhhDrDOoAq+AJoKI/3neg5N2ULGlCo= Received: from [192.168.1.40] (pool-74-96-127-26.washdc.east.verizon.net [74.96.127.26]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id EBB3710AFA1 for ; Sat, 4 Jun 2011 16:33:57 -0700 (PDT) From: Matt McCutchen To: dane In-Reply-To: <004901cc140c$8d250b40$a76f21c0$@augustcellars.com> References: <4DCD5D6A.7080203@KingsMountain.com> <004901cc140c$8d250b40$a76f21c0$@augustcellars.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 04 Jun 2011 19:33:55 -0400 Message-ID: <1307230435.5994.41.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] simultaneous use cases (was: Starting WGLC on: draft-ietf-dane-use-cases-02) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 23:34:02 -0000 On Mon, 2011-05-16 at 14:02 -0700, Jim Schaad wrote: > I think that it might require some extra text. There are two cases and they > need to be distinguished. The first is the combinable case and the second > is the rollover case. If you want to roll over from specifying the EE cert > to specifying a CA cert this is different than saying that both are to be > enforced. At a minimum one needs to say that a combinable case exists. I would suggest the following design. A TLSA assertion for a service is a disjunction of zero or more profiles, each of which is a conjunction of one or more predicates on certificates; its meaning is that a legitimate certificate satisfies all the predicates of some profile. (Better terminology invited.) We can have various predicate types that are applicable to different subsets of the TLS certificate types, and are considered to be false for certificates of inappropriate types. The existing "certificate types" become predicate types applicable to X.509 certificates. There would be an additional predicate type for an unspecified "traditional" certificate acceptance test, typically understood to be PKIX validation against a mainstream public CA list plus a server ID check. An absent TLSA assertion is equivalent to one with a single profile containing the single predicate "traditional". You can then do: - An additive assertion: (traditional) || (server_cert_hash(...)) - A restrictive assertion: (traditional && server_cert_hash(...)) - An assertion that completely replaces the traditional test: (server_cert_hash(...)) And a client that elects to process a TLSA assertion from a verified-insecure zone can just add the "traditional" predicate to every profile where it does not already appear. -- Matt From warren@kumari.net Wed Jun 8 16:48:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2121F854A for ; Wed, 8 Jun 2011 16:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, URIBL_RED=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IQ+jnj9ADl5 for ; Wed, 8 Jun 2011 16:48:08 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id A9D4321F8548 for ; Wed, 8 Jun 2011 16:48:08 -0700 (PDT) Received: from [192.168.0.197] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id ED2541B40429 for ; Wed, 8 Jun 2011 19:48:07 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Jun 2011 19:48:05 -0400 Message-Id: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:48:14 -0000 Cross posted: ---------- http://i.imgur.com/oTSPF.png here's the site: https://www.certigna.fr/crl/ looks like private keys are exposed. -------- Probably not a big issue... W From warren@kumari.net Wed Jun 8 16:56:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B74611E8085 for ; Wed, 8 Jun 2011 16:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, URIBL_RED=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RahuuaDBePLC for ; Wed, 8 Jun 2011 16:56:14 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8965F11E8080 for ; Wed, 8 Jun 2011 16:56:14 -0700 (PDT) Received: from [192.168.0.235] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 97CFE1B40A71; Wed, 8 Jun 2011 19:56:13 -0400 (EDT) References: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> In-Reply-To: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8C148) From: Warren Kumari Date: Wed, 8 Jun 2011 19:56:08 -0400 To: Warren Kumari Cc: "dane@ietf.org" Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:56:15 -0000 On Jun 8, 2011, at 7:48 PM, Warren Kumari wrote: > Cross posted: > ---------- > http://i.imgur.com/oTSPF.png > > here's the site: https://www.certigna.fr/crl/ > > looks like private keys are exposed. > -------- > > Probably not a big issue... > But many lists and twitter seem entertained... W > W > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From paul@xelerance.com Wed Jun 8 18:36:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFC811E80C1 for ; Wed, 8 Jun 2011 18:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RED=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcR3TPIbtgJQ for ; Wed, 8 Jun 2011 18:36:14 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id E065C11E8084 for ; Wed, 8 Jun 2011 18:35:25 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id A2CAFBC39; Wed, 8 Jun 2011 21:35:22 -0400 (EDT) Date: Wed, 8 Jun 2011 21:35:22 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> Message-ID: References: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 01:36:15 -0000 On Wed, 8 Jun 2011, Warren Kumari wrote: > Cross posted: > ---------- > http://i.imgur.com/oTSPF.png > > here's the site: https://www.certigna.fr/crl/ > > looks like private keys are exposed. > -------- > > Probably not a big issue... Hey, at least we can write our own revocation for the entire CA :) Paul From paul@xelerance.com Wed Jun 8 18:45:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427B811E80CD for ; Wed, 8 Jun 2011 18:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RED=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzxhbTYRH8Fz for ; Wed, 8 Jun 2011 18:45:23 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92E11E8084 for ; Wed, 8 Jun 2011 18:45:23 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 99119BC39; Wed, 8 Jun 2011 21:45:22 -0400 (EDT) Date: Wed, 8 Jun 2011 21:45:22 -0400 (EDT) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 01:45:24 -0000 On Wed, 8 Jun 2011, Paul Wouters wrote: >> http://i.imgur.com/oTSPF.png >> >> here's the site: https://www.certigna.fr/crl/ >> >> looks like private keys are exposed. >> -------- >> >> Probably not a big issue... > > Hey, at least we can write our own revocation for the entire CA :) Also: https://bugzilla.mozilla.org/show_bug.cgi?id=393166 Paul From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 19:46:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A5B21F84EF for ; Wed, 8 Jun 2011 19:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ98p3a4+MeP for ; Wed, 8 Jun 2011 19:46:46 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3A21F854A for ; Wed, 8 Jun 2011 19:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307587606; x=1339123606; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20paul@xelerance.com,=20warren@kumari.net|Subject: =20Re:=20[dane]=20You're=20doing=20it=20wrong...|Cc:=20da ne@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Thu,=2009=20Jun =202011=2014:46:43=20+1200; bh=nT3DuEaPis3j3uUu7d5lcNb9Z34EM6kXmWCsaR/bKr4=; b=TJTMUYcQaYayJKz4uVrsDM7zWIYg7vRux5hbsJ6PFdSbgkiu9O08vbLz BMigXFZka6fLPtGvpIRQHnZjBDVcNOpio0YBIWCEn/miWeW/DdaKYRQSd g6lE9fplO5rSo4LK6CNYSDLQLZ6dpbxmJJdXAEop77L9AkuefBRgZBtgz 0=; X-IronPort-AV: E=Sophos;i="4.65,340,1304251200"; d="scan'208";a="66382274" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jun 2011 14:46:43 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QUVGd-00066a-GN; Thu, 09 Jun 2011 14:46:43 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUVGd-0005dd-19; Thu, 09 Jun 2011 14:46:43 +1200 From: Peter Gutmann To: paul@xelerance.com, warren@kumari.net In-Reply-To: Message-Id: Date: Thu, 09 Jun 2011 14:46:43 +1200 Cc: dane@ietf.org Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:46:48 -0000 Paul Wouters writes: >Also: https://bugzilla.mozilla.org/show_bug.cgi?id=393166 That was the first thing I checked, it is a trusted CA. Peter. From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 19:52:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A427E21F858C for ; Wed, 8 Jun 2011 19:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsHIq6mMo2TQ for ; Wed, 8 Jun 2011 19:52:05 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7E34F21F858F for ; Wed, 8 Jun 2011 19:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307587925; x=1339123925; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dane@ietf.org,=20warren@kumari.net|Subject:=20Re: =20[dane]=20You're=20doing=20it=20wrong...|In-Reply-To: =20<770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> |Message-Id:=20|Date:=20Thu,=2009=20Jun=202011=2014:52:04=20+1200; bh=ftQ5nqJfUTzrxjWbCrVEf94WlHI/BJC/FIo903ytUXc=; b=u+zQ2/249aHoNWq0nrdNHHXa7/NwiIr+WsEgnOkTTfukII8WLbn7Q0Sb IBpN1AvI6r0/qlt9pn7JB5Q+A2hxdGD0o5u8kim2UgZ/eGzYw43r/ENJ5 G3sDIBzaKudjLYlqoReOS5eVrc1Hg7+7AsNjB/e6bbMOBpL7C2u6DhIJN c=; X-IronPort-AV: E=Sophos;i="4.65,340,1304251200"; d="scan'208";a="66384555" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jun 2011 14:52:05 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QUVLo-0006Jc-IM; Thu, 09 Jun 2011 14:52:04 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUVLo-0005ly-LA; Thu, 09 Jun 2011 14:52:04 +1200 From: Peter Gutmann To: dane@ietf.org, warren@kumari.net In-Reply-To: <770E7D39-D2A8-4D24-9678-BED1C3E61942@kumari.net> Message-Id: Date: Thu, 09 Jun 2011 14:52:04 +1200 Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:52:07 -0000 Warren Kumari writes: >looks like private keys are exposed. > >Probably not a big issue... These are private keys belonging to a trusted CA, how is this not a big issue? Given the universal implicit cross-certification in browsers, this means any cert, including CA certs, can be forged by the first attacker to crack the encryption. If this is what it appears to be, it'd bring the whole browser-PKI house of cards down. Peter. From matt@mattmccutchen.net Wed Jun 8 19:54:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B621F85B1 for ; Wed, 8 Jun 2011 19:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjG+rT2GGfAw for ; Wed, 8 Jun 2011 19:54:53 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7F79C21F85B0 for ; Wed, 8 Jun 2011 19:54:53 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 3E8B363406F; Wed, 8 Jun 2011 19:54:53 -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=Gl/LXhBWXIh04PgQPnRF0SfL6xs9hcKjmMFrAPtFTq/ CSPh72lDGZ73ywo5NqWx5x3ABJAUOJCFwZOsC8HHbYbhVOqrvfvPlAvfg7z4M47P h/5X+N3iRpnKdu9ZdSVejhDRwHGxl1aPnfboQ1jhDI5ckBOLOW+xbFiABSPY9jik = 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=+O5ToM8YwmjYAvHZQOcysDPKYHw=; b=aHr5yeoY1C GcCeQytz+CEcHYHd0ztJrQyo6Yj/yl109RI5fP/qY1ZCYzwFmLB02UL8yjU/jj1t B37fdRZtlCjf0Y1Kwr6EWSGzywnPBsTWQiHBhZCmOSk4eNnypeB5f5aTwR9MWKEu AwsEkR/6titZb/AOq6GisFWECEp7FSFMc= Received: from [192.168.1.40] (pool-74-96-43-195.washdc.east.verizon.net [74.96.43.195]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id C9D2363406E; Wed, 8 Jun 2011 19:54:52 -0700 (PDT) From: Matt McCutchen To: Peter Gutmann In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Jun 2011 22:54:50 -0400 Message-ID: <1307588090.2013.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:54:55 -0000 On Thu, 2011-06-09 at 14:52 +1200, Peter Gutmann wrote: > Warren Kumari writes: > > >looks like private keys are exposed. > > > >Probably not a big issue... > > These are private keys belonging to a trusted CA, how is this not a big issue? > Given the universal implicit cross-certification in browsers, this means any > cert, including CA certs, can be forged by the first attacker to crack the > encryption. If this is what it appears to be, it'd bring the whole > browser-PKI house of cards down. It appears to be the private key for the www.certigna.fr server, encrypted with a passphrase. The most you could do is brute-force the passphrase and MITM connections to the subscriber portal. Hopefully they can replace the cert before you have time to do that. -- Matt From pgut001@login01.cs.auckland.ac.nz Wed Jun 8 20:06:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646AE11E80D9 for ; Wed, 8 Jun 2011 20:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixBhWdP3Lh9H for ; Wed, 8 Jun 2011 20:06:58 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEB711E8096 for ; Wed, 8 Jun 2011 20:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1307588818; x=1339124818; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20matt@mattmccutchen.net,=20pgut001@cs.auckland.ac.n z|Subject:=20Re:=20[dane]=20You're=20doing=20it=20wrong.. .|Cc:=20dane@ietf.org|In-Reply-To:=20<1307588090.2013.2.c amel@localhost>|Message-Id:=20|Date:=20Thu,=2009=20Jun=202011=2015:0 6:57=20+1200; bh=37rzJro6IJxaoPm5QEarlS2r3ela1hYToIGAYE+hJ9E=; b=L4eVe1P/V/B88m3g+iVDSwN92lNLfuejp5c6lSLQtzHMyhHfKGqkHXx7 HK3ibSlF4M411pJr01G3IFQW2aHzGS5RPy7kCE+qzFnnKnZOKgxXsaMF5 eenyfoQYKlNj6GtX+Jq38Meattolvnxw3GbWkyxSolOpyVUIuy3BmQYsh 4=; X-IronPort-AV: E=Sophos;i="4.65,340,1304251200"; d="scan'208";a="66395167" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jun 2011 15:06:57 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QUVaD-0006xF-Gn; Thu, 09 Jun 2011 15:06:57 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QUVaD-0006dk-5O; Thu, 09 Jun 2011 15:06:57 +1200 From: Peter Gutmann To: matt@mattmccutchen.net, pgut001@cs.auckland.ac.nz In-Reply-To: <1307588090.2013.2.camel@localhost> Message-Id: Date: Thu, 09 Jun 2011 15:06:57 +1200 Cc: dane@ietf.org Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 03:06:59 -0000 Matt McCutchen writes: >It appears to be the private key for the www.certigna.fr server, encrypted >with a passphrase. The most you could do is brute-force the passphrase and >MITM connections to the subscriber portal. Hopefully they can replace the >cert before you have time to do that. Ah, so they're just server keys and not cert-signing keys. Still, would you trust certs issued by a CA that publicly posts their server private keys? Peter. From christopher.morrow@gmail.com Wed Jun 8 20:39:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08069228003 for ; Wed, 8 Jun 2011 20:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T693wcKtAu49 for ; Wed, 8 Jun 2011 20:39:08 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68F3721F8504 for ; Wed, 8 Jun 2011 20:39:08 -0700 (PDT) Received: by pzk5 with SMTP id 5so595483pzk.31 for ; Wed, 08 Jun 2011 20:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IOSf0BWad/Vq+NbfiDYXlMeC7+4A8396n1QLhYibdR4=; b=jac/GR15Co20Q6jG3b8mQycgNJefgbJtOQOeav0ZWBvNACwi22HuiKS8dEJES3DY+z 04FT/0GW+t3HjED9dP+V0XBgocd+CjHiA0g7XT9LMhPeosBpHmxm4INtlF4esh/yCzA3 +5U+YU4XVVRYVIIcFlJzsyjzxYLhaSCno/D18= 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=R7xETA/TAVrrBs+zhvo9ustd/qwmNF3hH2sbjsWTpumCheJ5DLlnOZYjomU7PF9AYZ vIeM/E+uJJw6PHLV+p8VMKcaOLMW7XPhI6AKoupiBquM5mCo72st9yAq3NdavnCHhTr7 ZbdFhMN80cQ29ALIU2TNdcs1nM6Mx78l9hP7c= MIME-Version: 1.0 Received: by 10.68.38.133 with SMTP id g5mr92753pbk.83.1307590748113; Wed, 08 Jun 2011 20:39:08 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.68.44.106 with HTTP; Wed, 8 Jun 2011 20:39:08 -0700 (PDT) In-Reply-To: References: <1307588090.2013.2.camel@localhost> Date: Wed, 8 Jun 2011 23:39:08 -0400 X-Google-Sender-Auth: wDbbXoHsjjW_GJiEiCsKITk9fYo Message-ID: From: Christopher Morrow To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 03:39:10 -0000 On Wed, Jun 8, 2011 at 11:06 PM, Peter Gutmann wrote: > Matt McCutchen writes: > >>It appears to be the private key for the www.certigna.fr server, encrypte= d >>with a passphrase. =A0The most you could do is brute-force the passphrase= and >>MITM connections to the subscriber portal. =A0Hopefully they can replace = the >>cert before you have time to do that. > > Ah, so they're just server keys and not cert-signing keys. =A0Still, woul= d you > trust certs issued by a CA that publicly posts their server private keys? kind of like lifelock, eh? From hallam@gmail.com Thu Jun 9 05:04:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401AD11E80C1 for ; Thu, 9 Jun 2011 05:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8j5s8kZMWPt for ; Thu, 9 Jun 2011 05:04:28 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F90911E80B9 for ; Thu, 9 Jun 2011 05:04:28 -0700 (PDT) Received: by yib18 with SMTP id 18so1140850yib.31 for ; Thu, 09 Jun 2011 05:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gfGpaXCf9EG/70dC9fQawG6DZ5eAET085ANSXpQs4oM=; b=Wn6ypM/pqGgEICxuoukHfnF7O5itmWsh47tcNFp9pLccy3pOPSQ40OgZNBoJNfXahg L0aL5ED4Flu/8X/FEIJOpH1+uyUFkZC3SGETPkuETpC80SFjv7eQf1oVr6jb4hQpfxvL qKQmYZnMtw7XwmddozYrkoDnII7QvkOyNe/Bs= 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=rWkhmQQwi8ADSLW3zBTyLlOez5yYUCEPkJPNYOqLZ9htQHWM4dgKzmXfCuH05ZkBLD GsC1uv7UL4zQ8Y/aneakdgX2unfhKCwd4fJr4HmO6Gp4CkhJoQkzFeE7QIO0aHcAPpZD bzxbky3I8VKTwKqdw0ezrOH5VRFmT7REjuO0A= MIME-Version: 1.0 Received: by 10.101.52.7 with SMTP id e7mr608784ank.85.1307621064725; Thu, 09 Jun 2011 05:04:24 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 9 Jun 2011 05:04:24 -0700 (PDT) In-Reply-To: References: <1307588090.2013.2.camel@localhost> Date: Thu, 9 Jun 2011 08:04:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=001636ed731310531904a5464172 Cc: dane@ietf.org Subject: Re: [dane] You're doing it wrong... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 12:04:29 -0000 --001636ed731310531904a5464172 Content-Type: text/plain; charset=ISO-8859-1 Would I? Almost certainly, I probably don't get a choice in the matter. Even if I control my trust environment I am likely dependent on some party who is dependent and so there is an indirect dependency. The real issue is whether the site is trustworthy i.e. whether I should trust it. Heck, the local power station runs a control system with no security in the local loop connection whatsoever. As far as private key storage goes, I think a lot of people did the industry a disservice when they went round demonizing the TCG work. As a result we still have annoying copy protection schemes and private keys are still vulnerable. It would be nice if we could work towards getting code signing fixed in that respect as being low hanging fruit. On Wed, Jun 8, 2011 at 11:06 PM, Peter Gutmann wrote: > Matt McCutchen writes: > > >It appears to be the private key for the www.certigna.fr server, > encrypted > >with a passphrase. The most you could do is brute-force the passphrase > and > >MITM connections to the subscriber portal. Hopefully they can replace the > >cert before you have time to do that. > > Ah, so they're just server keys and not cert-signing keys. Still, would > you > trust certs issued by a CA that publicly posts their server private keys? > > Peter. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636ed731310531904a5464172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Would I? Almost certainly, I probably don't get a choice in the matter.= Even if I control my trust environment I am likely dependent on some party= who is dependent and so there is an indirect dependency.

The real issue is whether the site is trustworthy i.e. whether I shoul= d trust it.

Heck, the local power station runs a c= ontrol system with no security in the local loop connection whatsoever.=A0<= /div>


As far as private key storage goes, I th= ink a lot of people did the industry a disservice when they went round demo= nizing the TCG work. As a result we still have annoying copy protection sch= emes and private keys are still vulnerable.=A0

It would be nice if we could work towards getting code = signing fixed in that respect as being low hanging fruit.

On Wed, Jun 8, 2011 at 11:06 PM, Peter Gutmann = <pgut001@= cs.auckland.ac.nz> wrote:
Matt McCutchen <matt@mattmccutchen.net> writes:<= br>
>It appears to be the private key for the www.certigna.fr server, encrypted
>with a passphrase. =A0The most you could do is brute-force the passphra= se and
>MITM connections to the subscriber portal. =A0Hopefully they can replac= e the
>cert before you have time to do that.

Ah, so they're just server keys and not cert-signing keys. =A0Sti= ll, would you
trust certs issued by a CA that publicly posts their server private keys?
Peter.
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--001636ed731310531904a5464172-- From matt@mattmccutchen.net Fri Jun 10 17:19:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DFC11E807A; Fri, 10 Jun 2011 17:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpB3rM3DT5t3; Fri, 10 Jun 2011 17:19:22 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 00E299E8007; Fri, 10 Jun 2011 17:19:21 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 78B88704063; Fri, 10 Jun 2011 17:19:21 -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=Mdtgxh8WgcVW8s8RGhaEQpXKduoX5jQAV7ON9JVyNRe VsVNgDS3cQuQ/P0nF2hwbVO97g8yn1j4TFpvPpVl7dPOsoaGtwEYtW4gYYGTqHK/ Gt5OD1geo6SVKE6TxLUIu6cowrPPGMFMg9K/mMeFl8ieiSuuIE2C1B4cDoI2K31M = 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=/krSHyP6rvUCq9pQaKxGRJd3iNw=; b=X2r1aPXi40 4hHCwOpyGstoThGjHAaG3Lq3Am6UicdhwUru66sGUhNi1hrigeZL0Y3MUyywgB45 ivHd7VL7cLDDGN0SmrmiAhImEMsDmgYNrzLoun3Gvzdxo89k8vVAe5GxWofEHmw/ ihghpDkT0loAEBgTpIgu25PKeggIOroxU= Received: from [192.168.1.40] (pool-74-96-43-55.washdc.east.verizon.net [74.96.43.55]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id E9195704014; Fri, 10 Jun 2011 17:19:20 -0700 (PDT) From: Matt McCutchen To: "Ed Gerck, Ph.D." In-Reply-To: <4DF2A183.8040809@nma.com> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Jun 2011 20:19:19 -0400 Message-ID: <1307751559.2095.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, dane Subject: [dane] TLS server authentication schemes... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 00:19:22 -0000 On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote: > On 6/10/2011 2:37 PM, Matt McCutchen wrote: > > DANE > > does not redefine PKIX semantics in any way. > > Yes, > DANE redefines the PKIX semantics > > Why? > > DANE defines a different way (ie, different meaning, different semantics) > to authenticate the association of the server's certificate with the intended > domain name, and is done without trusting an external CA. [1] The first statement does not follow from the second. PKIX is still what it is; DANE is merely an alternative. The claim that DANE "redefines" PKIX seems to be a deduction from the faulty premise that PKIX is the only possible method of TLS server authentication, and thus the only way to do differently is to change PKIX. > > DANE has significant security advantages over PKIX under a set of > > assumptions that are controversial. > > Intuitively, as more witnesses are considered, it becomes less likely that all > witnesses > can be compromised at the same time. More Witnesses = Better Evidence. [2] > > DANE reduces the number of witnesses over what is needed with PKIX, hence it > can be more easily compromised. Hence, it is not desirable. > > In other words, exactly because the same DNS administrator for a domain name is > authorized under DANE to *both* give identifying information about the zone and > make an authoritative binding between the domain name and a certificate, it should > be less trustworthy. Trust cannot be earned by self-assertions [2]. This debate has gone around and around on the DANE list, and it is not productive because the two sides argue from different assumptions that they are unwilling or unable (for lack of data) to reconcile. Suffice it to say that a number of people wish to use DANE, so we are proceeding with the standardization. > > OTOH, I have not seen any > > substantive claim of an advantage of the CAA RP support over DANE. > > As above. I do not understand what you mean. Please spell it out. -- Matt From hallam@gmail.com Fri Jun 10 20:43:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7F11E8073 for ; Fri, 10 Jun 2011 20:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWXHQ-HH9FWJ for ; Fri, 10 Jun 2011 20:43:14 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9E0322800B for ; Fri, 10 Jun 2011 20:43:13 -0700 (PDT) Received: by yxs7 with SMTP id 7so547701yxs.31 for ; Fri, 10 Jun 2011 20:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DFbPVOuGNpZuD6vGqkngTeOpt7oxJG3uJ0BspzTVL3k=; b=AE/hz5i+LL/vX8X9M7WTBqc8AUSaSbjIqYj5NcZ62dHsHSJz5GiFJ6Wpzd9C/Z1r/P lKWn2CuBhnV+OR/rI/LIfQ+w8M9HX/zyUnbxLk5z3vV2t5sAgc7bV8OM57IZW/BgR1D5 ZKNwpSuRPxiHvUhlhZ2WCYOnXzs9p9p0NixEY= 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=aji2zU3CjMn5NDSuBxEIyyPT8QXxLzha04FFIEVKyUJuGUn3TIAkVr1y/cqQIdqOVf A28H9o55IykDVSPYeOETQE08YkSdeiNxQTz6Jo4yYV7Ra4WaxKma5ovUn0gQyleqoatU h+WfdaCmRpced5/X+m6lzDDaosEhdAYlKmOhM= MIME-Version: 1.0 Received: by 10.101.200.1 with SMTP id c1mr2646035anq.63.1307763793362; Fri, 10 Jun 2011 20:43:13 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Fri, 10 Jun 2011 20:43:13 -0700 (PDT) In-Reply-To: <1307751559.2095.21.camel@localhost> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> <1307751559.2095.21.camel@localhost> Date: Fri, 10 Jun 2011 23:43:13 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016e68deca85a80da04a5677c89 Cc: "Ed Gerck, Ph.D." , dane Subject: Re: [dane] TLS server authentication schemes... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 03:43:15 -0000 --0016e68deca85a80da04a5677c89 Content-Type: text/plain; charset=ISO-8859-1 Since people are proposing to define restriction semantics on existing PKIX certificates using DANE they are proposing to change the validity and thus the semantics of PKIX. I do not see any possibility of a collision between DANE semantics and anything that is agreed in PKIX because I cannot see any possibility of DANE getting a standards track RFC published that attempts to perform the restriction being proposed. If people want to get anywhere with DANE they are going to have to first develop a mechanism that is capable of key distribution without affecting any existing infrastructure whatsoever. Only after that has been achieved and deployed and is in use can I see a proposal such as the cert restriction semantics having credibility outside the DANE working group. It is really, really easy to propose security schemes in theory. You can sweep all the hard parts under the rug and hope nobody notices. Or you can attack the motives of people who have had prior experience and hope they eventually go away. Publishing keys is a really hard problem all by itself. But the only way people are going to believe how hard it is is when they start to deploy. I certainly find it rather odd that the people who are so terrified of scope creep that they only want to think about TLS want to combine key distribution with restricting keys issued in a completely different PKI. So they end up having to consider the ambiguities and complexities of legacy DNS deployment due to using DNSSEC and then on top of that they want to add in all the complexities of PKIX. I guess that it might roll out the way people here imagine but I think it rather more likely that the result of trying to start a turf war on this is going to be an applicability statement that prohibits DANE making any assertion relating to non-DANE PKIX certs. On Fri, Jun 10, 2011 at 8:19 PM, Matt McCutchen wrote: > On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote: > > On 6/10/2011 2:37 PM, Matt McCutchen wrote: > > > DANE > > > does not redefine PKIX semantics in any way. > > > > Yes, > > DANE redefines the PKIX semantics > > > > Why? > > > > DANE defines a different way (ie, different meaning, different semantics) > > to authenticate the association of the server's certificate with the > intended > > domain name, and is done without trusting an external CA. [1] > > The first statement does not follow from the second. PKIX is still what > it is; DANE is merely an alternative. The claim that DANE "redefines" > PKIX seems to be a deduction from the faulty premise that PKIX is the > only possible method of TLS server authentication, and thus the only way > to do differently is to change PKIX. > > > > DANE has significant security advantages over PKIX under a set of > > > assumptions that are controversial. > > > > Intuitively, as more witnesses are considered, it becomes less likely > that all > > witnesses > > can be compromised at the same time. More Witnesses = Better Evidence. > [2] > > > > DANE reduces the number of witnesses over what is needed with PKIX, hence > it > > can be more easily compromised. Hence, it is not desirable. > > > > In other words, exactly because the same DNS administrator for a domain > name is > > authorized under DANE to *both* give identifying information about the > zone and > > make an authoritative binding between the domain name and a certificate, > it should > > be less trustworthy. Trust cannot be earned by self-assertions [2]. > > This debate has gone around and around on the DANE list, and it is not > productive because the two sides argue from different assumptions that > they are unwilling or unable (for lack of data) to reconcile. Suffice > it to say that a number of people wish to use DANE, so we are proceeding > with the standardization. > > > > OTOH, I have not seen any > > > substantive claim of an advantage of the CAA RP support over DANE. > > > > As above. > > I do not understand what you mean. Please spell it out. > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68deca85a80da04a5677c89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since people are proposing to define restriction semantics on existing PKIX= certificates using DANE they are proposing to change the validity and thus= the semantics of PKIX.

I do not see any possibility of = a collision between DANE semantics and anything that is agreed in PKIX beca= use I cannot see any possibility of DANE getting a standards track RFC publ= ished that attempts to perform the restriction being proposed.=A0


If people want to get anywhere with DANE= they are going to have to first develop a mechanism that is capable of key= distribution without affecting any existing infrastructure whatsoever. Onl= y after that has been achieved and deployed and is in use can I see a propo= sal such as the cert restriction semantics having credibility outside the D= ANE working group.

It is really, really easy to propose security schemes i= n theory. You can sweep all the hard parts under the rug and hope nobody no= tices. Or you can attack the motives of people who have had prior experienc= e and hope they eventually go away.

Publishing keys is a really hard problem all by itself.=A0But the = only way people are going to believe how hard it is is when they start to d= eploy.=A0


I certainly find it rathe= r odd that the people who are so terrified of scope creep that they only wa= nt to think about TLS want to combine key distribution with restricting key= s issued in a completely different PKI. So they end up having to consider t= he ambiguities and complexities of legacy DNS deployment due to using DNSSE= C and then on top of that they want to add in all the complexities of PKIX.= =A0


I guess that it might roll out the way p= eople here imagine but I think it rather more likely that the result of try= ing to start a turf war on this is going to be an applicability statement t= hat prohibits DANE making any assertion relating to non-DANE PKIX certs.

On Fri, Jun 10, 2011 at 8:19 PM, Matt M= cCutchen <ma= tt@mattmccutchen.net> wrote:
On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote:
> On 6/10/2011 2:37 PM, Matt McCutchen wrote:
> > =A0 =A0DANE
> > does not redefine PKIX semantics in any way.
>
> Yes,
> DANE redefines the PKIX semantics
>
> Why?
>
> DANE defines a different way (ie, different meaning, different semanti= cs)
> to authenticate the association of =A0the server's certificate wit= h the intended
> domain name, and is done without trusting an external =A0CA. [1]

The first statement does not follow from the second. =A0PKIX is still what<= br> it is; DANE is merely an alternative. =A0The claim that DANE "redefine= s"
PKIX seems to be a deduction from the faulty premise that PKIX is the
only possible method of TLS server authentication, and thus the only way to do differently is to change PKIX.

> > DANE has significant security advantages over PKIX under a set of=
> > assumptions that are controversial.
>
> Intuitively, as more witnesses are considered, it becomes less likely = that all
> witnesses
> can be compromised at the same time. More Witnesses =3D Better Evidenc= e. [2]
>
> DANE reduces the number of witnesses over what is needed with PKIX, he= nce it
> can be more easily compromised. =A0Hence, it is not desirable.
>
> In other words, exactly because the same DNS administrator for a domai= n name is
> authorized under DANE to *both* give identifying information about the= zone and
> make an authoritative binding between the domain name and a certificat= e, it should
> be less trustworthy. Trust cannot be earned by self-assertions [2].
This debate has gone around and around on the DANE list, and it is not
productive because the two sides argue from different assumptions that
they are unwilling or unable (for lack of data) to reconcile. =A0Suffice it to say that a number of people wish to use DANE, so we are proceeding with the standardization.

> > =A0 OTOH, I have not seen any
> > substantive claim of an advantage of the CAA RP support over DANE= .
>
> As above.

I do not understand what you mean. =A0Please spell it out.

--
Matt

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016e68deca85a80da04a5677c89-- From mrex@sap.com Fri Jun 10 21:27:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118C79E8011 for ; Fri, 10 Jun 2011 21:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnnhM-ZW5vfo for ; Fri, 10 Jun 2011 21:27:25 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3FED39E800B for ; Fri, 10 Jun 2011 21:27:25 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p5B4RNI3022083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jun 2011 06:27:23 +0200 (MEST) From: Martin Rex Message-Id: <201106110427.p5B4RMs1019345@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Sat, 11 Jun 2011 06:27:22 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jun 10, 11 11:43:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: egerck@nma.com, dane@ietf.org Subject: Re: [dane] TLS server authentication schemes... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 04:27:26 -0000 Phillip Hallam-Baker wrote: > > If people want to get anywhere with DANE they are going to have to first > develop a mechanism that is capable of key distribution without affecting > any existing infrastructure whatsoever. Only after that has been achieved > and deployed and is in use can I see a proposal such as the cert restriction > semantics having credibility outside the DANE working group. I believe the IETF should let the consumer / the market decide how much of PKIX and how much of DANE they want. IMO, PKIX might has too much of a bias to make such a decision. DANE is _not_ about inventing a whole new technology infrastructure from ground up, but about making an emerging and useful infrastructure even more useful by offering additional benefits. DANE is primarily about trust anchor management and path constraints management for the internet, something we I, personally, do not believe we have any reliable working solution for -- today. If you think that the existing thing known as the "TLS X.509 PKI of commercial CAs" is as valuable and reliable as you want to make us believe, then there is really nothing that you have to worry about from the part of DANE. ;-) -Martin From paul.hoffman@vpnc.org Sat Jun 11 08:04:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EAB11E80A9 for ; Sat, 11 Jun 2011 08:04: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aLG8dFvESFQ for ; Sat, 11 Jun 2011 08:04:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 003CB11E807E for ; Sat, 11 Jun 2011 08:04:32 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p5BF4QNh017858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 08:04:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 11 Jun 2011 08:04:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <25A6AE2C-2BFC-47CF-99C8-5F92743FCC69@vpnc.org> References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> <1307751559.2095.21.camel@localhost> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: DANE WG Subject: Re: [dane] TLS server authentication schemes... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 15:04:33 -0000 On Jun 10, 2011, at 8:43 PM, Phillip Hallam-Baker wrote: > Since people are proposing to define restriction semantics on existing = PKIX certificates using DANE they are proposing to change the validity = and thus the semantics of PKIX. Lord knows this is probably foolish, but let me try again: You talk about "semantics of PKIX", but you don't say which you mean. = Can you possibly send some quotes from RFC 5280 to help us understand = what you mean? If not, can you tell us why you think that unwritten = ideas should be considered here? Thanks in advance. --Paul Hoffman From matt@mattmccutchen.net Sat Jun 11 16:01:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1151F21F84E8 for ; Sat, 11 Jun 2011 16:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZtyJbl-UAWG for ; Sat, 11 Jun 2011 16:01:02 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7842121F84E7 for ; Sat, 11 Jun 2011 16:01:02 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 84881704063; Sat, 11 Jun 2011 16:01: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=RcSPF8OjM2Fuxw0kxZazjkAMlLiC9J84DZVwDfwMqP8 yNO0QKuScujtGVnGXJ+tXZP9PKqyGRm9Tb7+JjRAm+Q23o26Lqr2kswKfS2UVpA0 Xqn2Ndn7hxKacQ2APluKQIwMoZA4hIg1ohmXmL80mt74C7WePcWqGVO0x/5IjD8g = 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=lqAYYxHuwrUmevObMkBu5biTZrk=; b=AYtwokYyw7 tSWkFMeDCpPEj0mMCq0K09bH3O1i6I31/fO8G+hTT76IiX8EWanDJ/6oKDSqV+2J GuIIIoi4Zh8zON0c86Pnums8FQfjOlEFmq1fn+I5MlU88Y01rGvRngOejaNwaPDI E4CdTcvpFen6zuyIIYYktoGmpVYWoDVWw= Received: from [192.168.1.40] (pool-74-96-43-55.washdc.east.verizon.net [74.96.43.55]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 1CD16704014; Sat, 11 Jun 2011 16:01:00 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <4DF2C54C.4060706@nma.com> <201106110429.p5B4TuoF019430@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Sat, 11 Jun 2011 19:00:58 -0400 Message-ID: <1307833258.2102.69.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] TLS server authentication schemes... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 23:01:03 -0000 For now, I'll respond to one point: On Sat, 2011-06-11 at 09:55 -0400, Phillip Hallam-Baker wrote: > Nowhere does the charter state that DANE is going to make statements > about certificates. Incorrect. The charter says, "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 purpose of using the term "keys" is to be general to protocols that rely on key-name bindings but do not use certificates. -- Matt From matt@mattmccutchen.net Sat Jun 11 16:16:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E73511E8097 for ; Sat, 11 Jun 2011 16:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj4tHwXk5VG7 for ; Sat, 11 Jun 2011 16:16:55 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id EF86311E807C for ; Sat, 11 Jun 2011 16:16:54 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id B7261704063 for ; Sat, 11 Jun 2011 16:16:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=YTutbs9 U7rUS7AxmkusAurBjO1FQq7rmI54kELhI2mceBcVXk1zu5WS7kI5SNgfh9R+d1b7 OriZC9j+G+j/tDmVurX3p4llCDdd/r8eDWus/sCbO1xIUumlOyKeh+9qYMBqC0ob Ewdhi0ol8P5xCpGqJeMXr7gp/lMjvBC9Cq9g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=gKmZfgAo9ErcN ffw/oyZ2xwmlrQ=; b=pLv+u+Pbl1uTIFhH+xdza7QKwsGecQyqSF7FXOM1dmhIb 8HHZl+g92oXWl2HnyxIuznVQ0I3Jhx8rTcpK1lgbgNSPpF3fEzoI3btIJIG/d0bI F0qJZrkQVjI/DO7vL6sefOF4ggCe1+hDOzFWtDptjQNSZSBTnH0j2lYdzkgAtQ= Received: from [192.168.1.40] (pool-74-96-43-55.washdc.east.verizon.net [74.96.43.55]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 68A64704014 for ; Sat, 11 Jun 2011 16:16:54 -0700 (PDT) From: Matt McCutchen To: dane Content-Type: text/plain; charset="UTF-8" Date: Sat, 11 Jun 2011 19:16:52 -0400 Message-ID: <1307834212.2102.81.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 23:16:55 -0000 Restrictive assertions about name-bound credentials [1] are in the use cases document and the protocol document (though the latter has a lot of reworking yet to come), but whether they are in scope of the current charter is less clear. The whole charter is written with additive assertions in mind and contains no mention of restrictive assertions that would serve to include them, and there is the statement "More general statements of policy for a domain are out of scope", which definitely excludes orthogonal stuff like HASTLS and might exclude restrictive assertions. So it's possible that the current charter excludes restrictive assertions, and it's possible that the exclusion is unintentional, or at least desirable to change now. Phill says restrictive assertions are out of scope (https://www.ietf.org/mail-archive/web/pkix/current/msg29356.html). How do others interpret the charter? If it is believed necessary, I would support a charter update to place restrictive assertions in scope, matching the current use cases document. Others? If consensus was that restrictive assertions should be out of scope, I'd appreciate if people could remind me of the pertinent arguments. [1] I.e., an assertion that a legitimate credential for a given name will satisfy a constraint, which a client may use as grounds to reject a credential it would have accepted in the absence of the assertion. -- Matt From hallam@gmail.com Sat Jun 11 17:53:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899F21F849D for ; Sat, 11 Jun 2011 17:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+x+rt2LFm+k for ; Sat, 11 Jun 2011 17:53:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8317521F849B for ; Sat, 11 Jun 2011 17:53:51 -0700 (PDT) Received: by yxs7 with SMTP id 7so956434yxs.31 for ; Sat, 11 Jun 2011 17:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=245dZTKUcLg/fS1AS5gk/DpxZAhyge+q9A78IqvCRKg=; b=D0MVZ18ZIlzHdCtXMr6tV/bf4Cpf6qrhdaFI1ypJOiJCJuxj3QM3gOXUOBmI79qrMS 8+l3VM1DnqMmhhDDv+NIwPQMlhsrSlmpicqvsHc18zcREd1AN0Ahho9bPIrl6Tav9iyp yshAw1yKEJVjpflFmt5yFDZPfB7nbP/vbxEk4= 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=lJXhNbeX9GK/mmUAk/f/kD9Ho7oD1RFySInn08AIkeZFP5F2+2G0cAi2dzS4rvKuiB Xu2nodtTPtzhOTtdq97kPPTS3mPTzCmE7tiLZT0muFpT8c1NF2tz3951SXEhsc69atgj Ilgxoeks2gdFlRFoCybsvSS+4uRdrOF7I8Xh0= MIME-Version: 1.0 Received: by 10.100.56.29 with SMTP id e29mr3428080ana.129.1307840029083; Sat, 11 Jun 2011 17:53:49 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 17:53:49 -0700 (PDT) In-Reply-To: <1307834212.2102.81.camel@localhost> References: <1307834212.2102.81.camel@localhost> Date: Sat, 11 Jun 2011 20:53:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=001485f860e65b494504a5793ce3 Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 00:53:53 -0000 --001485f860e65b494504a5793ce3 Content-Type: text/plain; charset=ISO-8859-1 What I said was that the charter does not make an explicit claim. I think that if people who wrote the charter for one WG want to go off and wave it at another with some sort of exclusivity claim then the charter claim has to at least be clear and unambiguous. On Sat, Jun 11, 2011 at 7:16 PM, Matt McCutchen wrote: > Restrictive assertions about name-bound credentials [1] are in the use > cases document and the protocol document (though the latter has a lot of > reworking yet to come), but whether they are in scope of the current > charter is less clear. The whole charter is written with additive > assertions in mind and contains no mention of restrictive assertions > that would serve to include them, and there is the statement "More > general statements of policy for a domain are out of scope", which > definitely excludes orthogonal stuff like HASTLS and might exclude > restrictive assertions. > > So it's possible that the current charter excludes restrictive > assertions, and it's possible that the exclusion is unintentional, or at > least desirable to change now. > > Phill says restrictive assertions are out of scope > (https://www.ietf.org/mail-archive/web/pkix/current/msg29356.html). How > do others interpret the charter? If it is believed necessary, I would > support a charter update to place restrictive assertions in scope, > matching the current use cases document. Others? If consensus was that > restrictive assertions should be out of scope, I'd appreciate if people > could remind me of the pertinent arguments. > > [1] I.e., an assertion that a legitimate credential for a given name > will satisfy a constraint, which a client may use as grounds to reject a > credential it would have accepted in the absence of the assertion. > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001485f860e65b494504a5793ce3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I said was that the charter does not make an explicit claim.

<= /div>
I think that if people who wrote the charter for one WG want to g= o off and wave it at another with some sort of exclusivity claim then the c= harter claim has to at least be clear and unambiguous.




On Sa= t, Jun 11, 2011 at 7:16 PM, Matt McCutchen <matt@mattmccutchen.net> wrote= :
Restrictive assertions about name-bound cre= dentials [1] are in the use
cases document and the protocol document (though the latter has a lot of reworking yet to come), but whether they are in scope of the current
charter is less clear. =A0The whole charter is written with additive
assertions in mind and contains no mention of restrictive assertions
that would serve to include them, and there is the statement "More
general statements of policy for a domain are out of scope", which
definitely excludes orthogonal stuff like HASTLS and might exclude
restrictive assertions.

So it's possible that the current charter excludes restrictive
assertions, and it's possible that the exclusion is unintentional, or a= t
least desirable to change now.

Phill says restrictive assertions are out of scope
(https://www.ietf.org/mail-archive/web/pkix/current/msg= 29356.html). =A0How
do others interpret the charter? =A0If it is believed necessary, I would support a charter update to place restrictive assertions in scope,
matching the current use cases document. =A0Others? =A0If consensus was tha= t
restrictive assertions should be out of scope, I'd appreciate if people=
could remind me of the pertinent arguments.

[1] I.e., an assertion that a legitimate credential for a given name
will satisfy a constraint, which a client may use as grounds to reject a credential it would have accepted in the absence of the assertion.

--
Matt

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--001485f860e65b494504a5793ce3-- From gnu@toad.com Sat Jun 11 18:09:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77421F84F9 for ; Sat, 11 Jun 2011 18:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8M388+E1-3B for ; Sat, 11 Jun 2011 18:09:07 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9DB21F84F6 for ; Sat, 11 Jun 2011 18:09:07 -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 p5C193sV020847; Sat, 11 Jun 2011 18:09:03 -0700 Message-Id: <201106120109.p5C193sV020847@new.toad.com> To: Phillip Hallam-Baker In-reply-to: References: <1307834212.2102.81.camel@localhost> Comments: In-reply-to Phillip Hallam-Baker message dated "Sat, 11 Jun 2011 20:53:49 -0400." Date: Sat, 11 Jun 2011 18:09:03 -0700 From: John Gilmore Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 01:09:08 -0000 Deconfuse me a minute here. DANE was created because there's a significant problem with being able to trust the hundreds of trust-roots in current TLS CA practices. (The problem is that some of them are not trustworthy - but we don't know which ones until we're burned, and even then, if we mark the whole CA as untrusted, we also mark many valid keys, certified by that CA, as untrusted.) Phillip seems to be claiming that DANE can't "restrict" current TLS practice, by which he seems to mean that if current TLS practice says "accept that this key belongs to this site", DANE can't provide clients any information saying "no it doesn't -- the CA must have been hacked". Nor even, "Use this key instead - it's signed by the domain holder." On this theory, DANE could certify a key that old TLS practice didn't provide any information about, or could provide additional assurance for an already CA-certified key, but couldn't decertify a key that old TLS practice validates. If Phillip is right, I don't see how DANE could improve the security of TLS, absent a mass migration away from the old insecure TLS practices (CA's). John From matt@mattmccutchen.net Sat Jun 11 20:00:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1CC21F84DA for ; Sat, 11 Jun 2011 20:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajPU7T8ZqEck for ; Sat, 11 Jun 2011 20:00:26 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id A505921F84D9 for ; Sat, 11 Jun 2011 20:00:26 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id C4ECD284071; Sat, 11 Jun 2011 20:00:25 -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=IQAvmBO0ySy5Vz32lObclzg6CflvPEizaqeYLtr534d kLR692xsz2J3MjuFUUing7b0nv9u4iGUJUH/MJ4CDUIdvykgGjNnKMuQy36n38Al hssXeQZ0kMEH+OkFnhbYBAICD/vxkyMcL5p7PNLzHzKLdOYmHqy+VvSXy+MyBECY = 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=moj4fhWow0UdZjb6yoboGSNyDYI=; b=Yheo0k8BfO 4UaGR3yO93HHtgFvkkt4x8mSse8kMi0AqeUxVAokZHKDH8artU+b62T0zFydeJD3 E/OaNWjTcxF76BASliVlzhsBxsr7kxs71GC7oaV9bsOdebSiNvoHBvNtZ/BVjTaG kaR4a1LEZL1CXcl28kQqxIk5MVehhdO4c= Received: from [192.168.1.40] (pool-74-96-43-55.washdc.east.verizon.net [74.96.43.55]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 4F0EC28406C; Sat, 11 Jun 2011 20:00:25 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <1307834212.2102.81.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sat, 11 Jun 2011 23:00:22 -0400 Message-ID: <1307847622.2109.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 03:00:27 -0000 On Sat, 2011-06-11 at 20:53 -0400, Phillip Hallam-Baker wrote: > What I said was that the charter does not make an explicit claim. Ah, thanks for the clarification. > I think that if people who wrote the charter for one WG want to go off > and wave it at another with some sort of exclusivity claim then the > charter claim has to at least be clear and unambiguous. I'm not sure whether you are referring to (1) DANE restrictive assertions or (2) the proposal to drop CAA RP in favor of DANE. Regarding (1), DANE does not claim any kind of exclusivity as a mechanism for TLS server authentication. It is just defining the semantics for RPs that choose to use DANE, and those semantics induce a set of acceptable certificates that need not be a superset of the PKIX set. (If you even read that much into it. The latest viewpoint seems to be to describe the DANE data as an assertion and leave client behavior unspecified to avoid objections about forcing policy on the client.) Re (2), I believe the proposal was based not on charters, but on the fact that DANE has the express purpose of supporting relying party enforcement in full generality, and thus can be presumed to give a better solution than a simple copy-and-paste of an issuance enforcement scheme. If you see technical shortcomings of DANE compared to CAA RP, I urge you to raise them. So far, you have raised only cultural and political objections (see previous discussion: https://www.ietf.org/mail-archive/web/dane/current/msg02624.html ). The upshot is that I have yet to be convinced of the value of pursuing CAA RP. But I do not intend to stand in the way of it. -- Matt From hallam@gmail.com Sat Jun 11 21:10:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2062D11E80C7 for ; Sat, 11 Jun 2011 21:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X+yV0sntmN1 for ; Sat, 11 Jun 2011 21:10:14 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 653FF11E808D for ; Sat, 11 Jun 2011 21:10:13 -0700 (PDT) Received: by yie30 with SMTP id 30so506079yie.31 for ; Sat, 11 Jun 2011 21:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9Rt4Sn9c06m1KTSxa88t3CucN9oLfNjT8oOy5ZBUB9I=; b=BMcZK9ocSWAxjedMCBnKz48O1DotfHnpbexjM3qXgynzdCPchGWCPMyFKd5/0T2Hca eKkiqYAdJ3qpORNWNNJEpNtXM2zlM02r/tiJz0LssZPaTQKJLuZSCHaAuBYntdwlhdw+ OWPQRKWHutNjCjXvRBvSmupldM9jrh+uy0VFg= 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=K4O11six61ySyLoXDAqOISAenxvGDPNEbQWVHlOXPzzqywdojJlK2f5USl3So2JZew Nm+4iu8EdmlScUPNfix1bXYrlqcVskPI7W1yrF0ntaTSgVGq6/os65uzEOm2jXI9NHap FGLr4dts3uL3YT/D498Iz/z6CNiitJ36Uzdag= MIME-Version: 1.0 Received: by 10.100.255.2 with SMTP id c2mr3579286ani.41.1307851809554; Sat, 11 Jun 2011 21:10:09 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 21:10:09 -0700 (PDT) In-Reply-To: <1307847622.2109.24.camel@localhost> References: <1307834212.2102.81.camel@localhost> <1307847622.2109.24.camel@localhost> Date: Sun, 12 Jun 2011 00:10:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=00163662e6618703a904a57bfaac Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 04:10:17 -0000 --00163662e6618703a904a57bfaac Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 11, 2011 at 11:00 PM, Matt McCutchen wrote: > > Re (2), I believe the proposal was based not on charters, but on the > fact that DANE has the express purpose of supporting relying party > enforcement in full generality, No it does not, its not even explicit in the charter. > and thus can be presumed to give a > better solution than a simple copy-and-paste of an issuance enforcement > That is an insult to my work. I do not do superficial proposals. We have considerable expertise in the field. We put in a great deal of time and effort. The use case document I submitted is considerably more comprehensive than the one DANE chose to work from. scheme. If you see technical shortcomings of DANE compared to CAA RP, > I urge you to raise them. Well the fact that it is expressed in non PKIX style would seem to me to be a pretty big obstacle to having it included in PKIX based applications. And the fact that you still haven't proposed a scheme that meets the DNS constraints you acknowledged in the earlier exchange. It is quite possible that you will come up with another way to meet those constraints, but until you have done so, I have a proposal and you don't. It is also possible that you will work out a better way to navigate those constraints than I have. But at the end of the day CAA RP has a much easier problem to solve because it is only doing restriction, not restriction plus distribution of end entity keys. So I don't need to use prefixing at all for CAA which is inescapable if you are going to do end entity keys. There are only two technical proposals currently on the table that allow you to meet all the DNS constraints. The first is that you decide not to distribute EE keys an to only distribute key signing keys in the DNS. This obviates the need for prefixing entirely and makes DANE logically equivalent to CAA. So since you are going to need a CA in there anyway (possibly run locally) why not just adopt CAA as the basis for DANE as well? The second is that you decide you want to put the EE keys in the DNS because you don't want to have to run a CA everywhere. That is fine but you will then have to adopt at least part of the GSRV/ESRV approach and have an unprefixed record for the first round of lookup which may involve a canonical name and then apply the prefix to the canonical if that is necessary to continue at finer grain discovery. Again, I have solved the technical problem, so why not just consider doing it my way? I mean seriously, when have you ever seriously considered the possibility of doing anything I suggest? I have a complete system and it has a compelling value proposition in the Web Services space, one of the hotest, fastest growing spaces in the field. How to make PKI work for Web Services is currently an unsolved problem. If you want to affect the way browsers work you will find it much easier to do so by establishing a critical mass of users and proving the value in the Web Services field. > So far, you have raised only cultural and > political objections (see previous discussion: > https://www.ietf.org/mail-archive/web/dane/current/msg02624.html ). > Which is what the standards process is entirely about. If you think that the core problem here is a fault in PKIX then the appropriate response is to propose a solution to PKIX or CABForum or both. If you think that the issue here is an opportunity to use DNSSEC to replace the need for DV certs in certain use cases then the appropriate response is to start a WG to put keys in the DNS. Trying to do both in the same WG is a terrible idea. It forces you to address the legacy constraints of both the DNS and PKIX at the same time. And both systems are now infrastructures and the legacy constraints are far more complex than any single individual can hope to understand. What I am saying here is that far from having a turf battle with PKIX demanding to keep the RP restriction issue to themselves, the DANE group should be begging them to take it off their hands. -- Website: http://hallambaker.com/ --00163662e6618703a904a57bfaac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 11, 2011 at 11:00 PM, Matt M= cCutchen <ma= tt@mattmccutchen.net> wrote:
Re (2), I believe the proposal was based not on charters, but on the
fact that DANE has the express purpose of supporting relying party
enforcement in full generality,

No it does = not, its not even explicit in the charter.

=A0
and thus can be presumed to give a
better solution than a simple copy-and-paste of an issuance enforcement
=

That is an insult to my work. I do not do = superficial proposals.

We have considerable expert= ise in the field. We put in a great deal of time and effort.=A0

The use case document I submitted is considerably more = comprehensive than the one DANE chose to work from.=A0

=

scheme. =A0If you see technical shortcomings of DANE compared to CAA RP, I= =A0urge you to raise them.

Well the fact th= at it is expressed in non PKIX style would seem to me to be a pretty big ob= stacle to having it included in PKIX based applications.=A0

And the fact that you still haven't proposed a sche= me that meets the DNS constraints you acknowledged in the earlier exchange.=


It is quite possible that you will= come up with another way to meet those constraints, but until you have don= e so, I have a proposal and you don't. It is also possible that you wil= l work out a better way to navigate those constraints than I have.=A0

But at the end of the day CAA RP has a much easier prob= lem to solve because it is only doing restriction, not restriction plus dis= tribution of end entity keys. So I don't need to use prefixing at all f= or CAA which is inescapable if you are going to do end entity keys.

There are only two technical proposals currently on the= table that allow you to meet all the DNS constraints.

=
The first is that you decide not to distribute EE keys an to only dist= ribute key signing keys in the DNS. This obviates the need for prefixing en= tirely and makes DANE logically equivalent to CAA. So since you are going t= o need a CA in there anyway (possibly run locally) why not just adopt CAA a= s the basis for DANE as well?

The second is that you decide you want to put the EE ke= ys in the DNS because you don't want to have to run a CA everywhere. Th= at is fine but you will then have to adopt at least part of the GSRV/ESRV a= pproach and have an unprefixed record for the first round of lookup which m= ay involve a canonical name and then apply the prefix to the canonical if t= hat is necessary to continue at finer grain discovery.

Again, I have solved the technical problem, so why not = just consider doing it my way?

I mean seriously, w= hen have you ever seriously considered the possibility of doing anything I = suggest?

I have a complete system and it has a compelling value = proposition in the Web Services space, one of the hotest, fastest growing s= paces in the field. How to make PKI work for Web Services is currently an u= nsolved problem.

If you want to affect the way browsers work you will fi= nd it much easier to do so by establishing a critical mass of users and pro= ving the value in the Web Services field.

=A0
=A0So far, you have raised only cultural a= nd
political objections (see previous discussion:
https://www.ietf.org/mail-archive/web/dane/current/msg0= 2624.html ).

Which is what the stan= dards process is entirely about.=A0

If you think that the core problem here is a f= ault in PKIX then the appropriate response is to propose a solution to PKIX= or CABForum or both.

If you think that the issue = here is an opportunity to use DNSSEC to replace the need for DV certs in ce= rtain use cases then the appropriate response is to start a WG to put keys = in the DNS.

Trying to do both in the same WG is a terrible idea. It= forces you to address the legacy constraints of both the DNS and PKIX at t= he same time. And both systems are now infrastructures and the legacy const= raints are far more complex than any single individual can hope to understa= nd.


What I am saying here is that far from h= aving a turf battle with PKIX demanding to keep the RP restriction issue to= themselves, the DANE group should be begging them to take it off their han= ds.

--00163662e6618703a904a57bfaac-- From jakob@kirei.se Sun Jun 12 03:54:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A804B21F84A3 for ; Sun, 12 Jun 2011 03:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBzfd7bY1cOY for ; Sun, 12 Jun 2011 03:54:54 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37221F84A4 for ; Sun, 12 Jun 2011 03:54:53 -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=8VYCTJJNwKndRnxaeKH2TE5SdDiWm2dpHHfOdEPj2wI=; b=QIwBilHbyiKp+OWtvh4PnlHyWATgZODwrHBpBeVW/4CTaD6l96Fjd16DjSKnxGBmnBpD0/fR8bcSi HPzV7A4+sbXfiwRXLuechR11VOOhFh2NlsrwHmTi6BUFJ9MgpwLtJOuV1wlOwlPO2GRWosXKlFW6ST 5xJ27RSBx/Tu0ESg= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 12 Jun 2011 12:54:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201106120109.p5C193sV020847@new.toad.com> Date: Sun, 12 Jun 2011 12:54:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1307834212.2102.81.camel@localhost> <201106120109.p5C193sV020847@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1084) Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 10:54:55 -0000 On 12 jun 2011, at 03.09, John Gilmore wrote: > On this theory, DANE could certify a key that old TLS practice didn't > provide any information about, or could provide additional assurance > for an already CA-certified key, but couldn't decertify a key that old > TLS practice validates. IMHO, this is the most important use case for DANE - we need DANE to = keep a leash on PKI, and restrictive assertions is the way we do this. = I want tell the my users what certs (or issuers) I intend to use, and = that other certs are not valid. DANE clients can always implement their own policy accepting the certs = anyway, just as many people today - based on my experience - just click = "continue" whenever the annoying certificate warning goo pops up their = browser.=20 jakob From hallam@gmail.com Sun Jun 12 05:54:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D0E11E8088 for ; Sun, 12 Jun 2011 05:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuVcz+0AiNVz for ; Sun, 12 Jun 2011 05:54:54 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6D211E807B for ; Sun, 12 Jun 2011 05:54:54 -0700 (PDT) Received: by yie30 with SMTP id 30so648985yie.31 for ; Sun, 12 Jun 2011 05:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dNxM0RybZgvpY1nGoWyDU+sFWUbacoZAPeBTOremM1s=; b=Qe7aRYZxlvfLhqjLZ252uoqZq8LoZS5l8ZlZ6ED2ba6lbWl1xxllHtzsehGRwqbb2m b1lP8YHn6RGPJjOLEtNEdjPuwLncovAXjhlvwbCJL9Z3adrqjel5c5dcpC8hDXtGkCjO P5Mw8Utb6RXjDqXzZy8OQ6wIljm3gadviIP9M= 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=IVdkJLwhBJ9tlP9jFYKxlrxNDVpewbdgokyM+eZHTt6wFBUwNyuQoipJLLpXLCyCC1 iJgDOYm0j69VkEBHp9i3m0jof3yl76er1XA5ePb7/MpjEoF+4Q6BkzCqQFAKoDD6P458 tDpdv2I5hgKUJXAokL3/WJzmEg5xYwRUBIpRU= MIME-Version: 1.0 Received: by 10.100.56.29 with SMTP id e29mr3815835ana.129.1307883293371; Sun, 12 Jun 2011 05:54:53 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sun, 12 Jun 2011 05:54:53 -0700 (PDT) In-Reply-To: References: <1307834212.2102.81.camel@localhost> <201106120109.p5C193sV020847@new.toad.com> Date: Sun, 12 Jun 2011 08:54:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001485f860e61bef4d04a5834f89 Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 12:54:55 -0000 --001485f860e61bef4d04a5834f89 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 12, 2011 at 6:54 AM, Jakob Schlyter wrote: > On 12 jun 2011, at 03.09, John Gilmore wrote: > > > On this theory, DANE could certify a key that old TLS practice didn't > > provide any information about, or could provide additional assurance > > for an already CA-certified key, but couldn't decertify a key that old > > TLS practice validates. > > IMHO, this is the most important use case for DANE - we need DANE to keep a > leash on PKI, and restrictive assertions is the way we do this. I want tell > the my users what certs (or issuers) I intend to use, and that other certs > are not valid. > > DANE clients can always implement their own policy accepting the certs > anyway, just as many people today - based on my experience - just click > "continue" whenever the annoying certificate warning goo pops up their > browser. Which is not at all what you advertised to the rest of the IETF at the start. If you want to 'keep a leash on PKI' as in PKIX then you are proposing to change the semantics of PKIX BY DEFINITION. There is no way that you can do that without affecting PKIX clients. So you have to do that in PKIX if that is what you want to do. Here is an idea, first propose a mechanism for publishing keys in the DNS that actually works with the DNS (CNAME, SRV, Wildcards) before you try proposing to 'keep a leash' on other people's existing work. -- Website: http://hallambaker.com/ --001485f860e61bef4d04a5834f89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jun 12, 2011 at 6:54 AM, Jakob S= chlyter <jakob@kirei= .se> wrote:
On 12 jun 2011, at 03.09, John Gilmore wrote:

> On this theory, DANE could certify a key that old TLS practice didn= 9;t
> provide any information about, or could provide additional assurance > for an already CA-certified key, but couldn't decertify a key that= old
> TLS practice validates.

IMHO, this is the most important use case for DANE - we need DANE to = keep a leash on PKI, and restrictive assertions is the way we do this. =A0I= want tell the my users what certs (or issuers) I intend to use, and that o= ther certs are not valid.

DANE clients can always implement their own policy accepting the certs anyw= ay, just as many people today - based on my experience - just click "c= ontinue" whenever the annoying certificate warning goo pops up their b= rowser.

Which is not at all what you ad= vertised to the rest of the IETF at the start.

If = you want to 'keep a leash on PKI' as in PKIX then you are proposing= to change the semantics of PKIX BY DEFINITION. There is no way that you ca= n do that without affecting PKIX clients.

So you have to do that in PKIX if that is what you want= to do.


Here is an idea, first prop= ose a mechanism for publishing keys in the DNS that actually works with the= DNS (CNAME, SRV, Wildcards) before you try proposing to 'keep a leash&= #39; on other people's existing work.


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

--001485f860e61bef4d04a5834f89-- From egerck@nma.com Fri Jun 10 18:30:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528DC11E80D3 for ; Fri, 10 Jun 2011 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3ReHNiNmeX5 for ; Fri, 10 Jun 2011 18:30:54 -0700 (PDT) Received: from nm26.access.bullet.mail.mud.yahoo.com (nm26.access.bullet.mail.mud.yahoo.com [66.94.237.91]) by ietfa.amsl.com (Postfix) with SMTP id 9821811E80B7 for ; Fri, 10 Jun 2011 18:30:54 -0700 (PDT) Received: from [66.94.237.126] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 01:30:54 -0000 Received: from [66.94.237.105] by tm1.access.bullet.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 01:30:54 -0000 Received: from [127.0.0.1] by omp1010.access.mail.mud.yahoo.com with NNFMP; 11 Jun 2011 01:30:54 -0000 X-Yahoo-Newman-Id: 279371.60776.bm@omp1010.access.mail.mud.yahoo.com Received: (qmail 54198 invoked from network); 11 Jun 2011 01:30:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307755854; bh=Vw7lCboD2NRaogwCwSObHleifCXuxTdNZma1QtYqrm0=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NGPlhA857zPP3sCcKO6W9cXK1w65JJx0GU12jAhvqRPZ1PhmQLKt4ap9W4GdCkLh+Rmb/SWXbjiO+5J56WkAqVdt+DdMknJdmZ+mh7aE9sO8YT+o4L9h3bG5HLYu0cpQXrmJ/TbPpnOaV6fimEebq4FpiLdR+HO2m4USoI3vggo= Received: from [172.16.1.88] (egerck@99.145.106.177 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 10 Jun 2011 18:30:53 -0700 PDT X-Yahoo-SMTP: MbPjQnGswBC7yA6NwEFbGJ4iXszffqyyVjqB X-YMail-OSG: bg4r_QUVM1nnV1S9b4SiHA.xglE2gnPFgal9FUHnGhW7LWd 8t48L8INtDdaS7bJqHRjSOvzzJ_vrKFmx4upwLxPENkQPIwr5DyfJpUBPA5d 0LC9YqGIHe_oqYhFYMPIMg9FvLd3exo_kqPWFGEa3My4c4XRFfZUK3gQTBk5 8K.2W4VogkJFUL.yly.cfmIxmsDuYX6W4ddWn6Ey9DQ70TyljlrJwW0Qm2zI UX_usWInhLYtLXjW_56DUlCggVOv7IRG7Uw8uwMRk7a3k6DGHBlAr5gDgvQY hrFvCCYWL95r_PVPgGzan_2GF9rkfbMWU2rpKdoVeAEWEEhl2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DF2C54C.4060706@nma.com> Date: Fri, 10 Jun 2011 18:30:52 -0700 From: "Ed Gerck, Ph.D." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matt McCutchen References: <201106090244.p592i7XA029918@fs4113.wdf.sap.corp> <01FA2D01-8083-4411-8D17-043A662609A6@vpnc.org> <1307741865.2123.14.camel@localhost> <4DF2A183.8040809@nma.com> <1307751559.2095.21.camel@localhost> In-Reply-To: <1307751559.2095.21.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Jun 2011 06:02:04 -0700 Cc: pkix@ietf.org, dane Subject: Re: [dane] TLS server authentication schemes... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 01:30:55 -0000 On 6/10/2011 5:19 PM, Matt McCutchen wrote: > On Fri, 2011-06-10 at 15:58 -0700, Ed Gerck, Ph.D. wrote: >> Yes, DANE redefines the PKIX semantics >> Why? >> >> DANE defines a different way (ie, different meaning, different semantics) >> to authenticate the association of the server's certificate with the intended >> domain name, and is done without trusting an external CA. [1] > The first statement does not follow from the second. PKIX is still what > it is; DANE is merely an alternative. The claim that DANE "redefines" > PKIX seems to be a deduction from the faulty premise that PKIX is the > only possible method of TLS server authentication, and thus the only way > to do differently is to change PKIX. The first statement makes no claim on an authoritative source. The fact that folks can *redefine* the semantics of English so that "cool" means "hot" does not mean that English is authoritatively changed. In this case, because DANE changes what it means to "authenticate the server certificate" (which has so far been defined by PKIX semantics), DANE is indeed *redefining* the meaning (semantics) that people assign to that sentence. We now have two angles to understand the sentence "authenticate the server certificate" . The DANE and the PKIX angles. Now, while this may add some degree of confusion (which angle is the browser using?), I do not say that this is bad or "impossible". What I say is not that this is by itself bad but that it is not desirable, and I explained why below. >>> DANE has significant security advantages over PKIX under a set of >>> assumptions that are controversial. >> Intuitively, as more witnesses are considered, it becomes less likely that all >> witnesses >> can be compromised at the same time. More Witnesses = Better Evidence. [2] >> >> DANE reduces the number of witnesses over what is needed with PKIX, hence it >> can be more easily compromised. Hence, it is not desirable. >> >> In other words, exactly because the same DNS administrator for a domain name is >> authorized under DANE to *both* give identifying information about the zone and >> make an authoritative binding between the domain name and a certificate, it should >> be less trustworthy. Trust cannot be earned by self-assertions [2]. > This debate has gone around and around on the DANE list, and it is not > productive because the two sides argue from different assumptions that > they are unwilling or unable (for lack of data) to reconcile. Suffice > it to say that a number of people wish to use DANE, so we are proceeding > with the standardization. My argument did not hinge on popularity. A number of people may wish to use what is more likely to fail for a number of reasons, including cost. My argument was that security-wise DANE is less trustworthy and I explained why using intuitive, historical, and formal arguments. It's not just a theory or an anecdote. >>> OTOH, I have not seen any >>> substantive claim of an advantage of the CAA RP support over DANE. >> As above. > I do not understand what you mean. Please spell it out. > Security-wise, DANE is less trustworthy. Thank you for your comments. Cheers, Ed Gerck From warren@kumari.net Sun Jun 12 06:37:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821D811E80E1 for ; Sun, 12 Jun 2011 06:37:26 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NLzBWh+jmfu for ; Sun, 12 Jun 2011 06:37:25 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id AC01511E8072 for ; Sun, 12 Jun 2011 06:37:25 -0700 (PDT) Received: from [10.111.112.105] (unknown [38.109.210.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 43F3F1B40175; Sun, 12 Jun 2011 09:37:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <201106120109.p5C193sV020847@new.toad.com> Date: Sun, 12 Jun 2011 07:37:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <58E3203E-647A-4F7E-9530-45BB2ADDAF8A@kumari.net> References: <1307834212.2102.81.camel@localhost> <201106120109.p5C193sV020847@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1084) Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 13:37:26 -0000 Apologies to all for the latency in responding -- I'm traveling (and = will be for a month or so) and haven't been checking email as frequently = as I should=85. On Jun 11, 2011, at 7:09 PM, John Gilmore wrote: > Deconfuse me a minute here. >=20 > DANE was created because there's a significant problem with being able > to trust the hundreds of trust-roots in current TLS CA practices. Yup, that was one of the driving forces behind the creation. If I'm example.com and I get my certs from GoodCerts, I'd like a way to = "protect" users who access example.com from accepting a certificate = issued for example.com by BadCerts. I know which CA (and, more = specifically, which cert I am using) and want to provide a means for = relying parties to know this too. Now that I have this ability, if I wish to generate and use my own = certificate (which I have signed with the key itself (see how I avoided = using "self-signed" there? ;-) )) I should be able to tell relying = parties this as well -- they can use this information as input to = decide if the certificate should be trusted. > (The problem is that some of them are not trustworthy - but we don't > know which ones until we're burned, and even then, if we mark the > whole CA as untrusted, we also mark many valid keys, certified by > that CA, as untrusted.) I would have worded that differently :-) Actually I think that I have a whole different spin on this -- the folk = who get certificates choose a particular CA to obtain the cert from -- = their reasons for choosing X over Y over Z are not important, what is it = that they have made this decision, and gotten a certificate (let's call = it A). *This* is the certificate that relying parties should use, not = one from Y, not one from Z, not a different one from X, but A (ok, or = multiple A's). Someone who operates example.com knows definitively (well, should!) = which certificate (or set thereof) are in use -- they should be able to = communicate this so that folk who connect to example.com can know that = there are shenanigans if they see a different cert=85. >=20 > Phillip seems to be claiming that DANE can't "restrict" current TLS > practice, by which he seems to mean that if current TLS practice says > "accept that this key belongs to this site", DANE can't provide = clients > any information saying "no it doesn't -- the CA must have been = hacked". > Nor even, "Use this key instead - it's signed by the domain holder." >=20 > On this theory, DANE could certify a key that old TLS practice didn't > provide any information about, or could provide additional assurance > for an already CA-certified key, but couldn't decertify a key that old > TLS practice validates. >=20 > If Phillip is right, I don't see how DANE could improve the security > of TLS, absent a mass migration away from the old insecure TLS > practices (CA's). Ok, so -- seeing as this question keeps coming up (for whatever reason) = it seems that the we need to clearly and concisely define the question, = record it in the issue tracker and get our AD's to weigh in here (I = think that questions that clarify if something is in scope should have = the AD's input, especially if the chairs think that it is in scope).=20 So, can folk please help me clearly define the question? I'm having a = hard time wording it clearly, concisely and unambiguously. Matt's "an assertion that a legitimate credential for a given name will = satisfy a constraint, which a client may use as grounds to reject a credential it would have accepted in the absence of the assertion." = comes close, but is (IMO) a little hard to read. Something along the lines of: ---------------------------------------- Is the "restrictive" case within the charter? The restrictive case is: If a relying party finds information in the DNS = (for example in a TLSA record) that states that certificates X and Y are = the certificates that should be accepted, it may use this information to = reject certificate Z (even if it would have accepted Z without this = information). ---------------------------------------------- or ---------------------------------------- Is the "restrictive" case within the charter? The restrictive case is: If a relying party finds information in the DNS = (for example in a TLSA record) that states that the credentials to be = use must satisfy the following criteria, it may use this information to = reject credentials that to not satisfy these criteria. An informal = example of the criteria could be: "Must match the following set of = certificates" ---------------------------------------------- I think that this needs some serious word-smithing :-P . I am trying to = keep it general and informal enough so that it is easily understood (I = tried this with various words instead of "certificate" and credentials, = but they all sounded klunky, which leads me to think that they were not = good choices). I am looking for something that clearly outlines the = intent, not something too formal (I don't want us to end up in the "Ha, = but that doesn't apply on Thursdays in March if it's also a full moon.") W P.S: Apologies for the grumpy (and rushed) tone, I'm a: grumpy and b: = rushed! > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Sun Jun 12 06:43:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303EF11E80A7 for ; Sun, 12 Jun 2011 06:43:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whThwNm9+ZNO for ; Sun, 12 Jun 2011 06:43:43 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 489D011E8072 for ; Sun, 12 Jun 2011 06:43:43 -0700 (PDT) Received: from [10.111.112.105] (unknown [38.109.210.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 33C6B1B40175; Sun, 12 Jun 2011 09:43:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sun, 12 Jun 2011 07:43:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1307834212.2102.81.camel@localhost> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 13:43:44 -0000 On Jun 11, 2011, at 6:53 PM, Phillip Hallam-Baker wrote: > What I said was that the charter does not make an explicit claim. >=20 Yes, you are correct, the charter is not explicit here. Let's get the question clear and unambiguous, get our ADs to confirm if = the "restrictive assertions" case is within the scope, clearly record = this and move on. If the ADs thing it is necessary we can discuss = getting the clarification inserted / appended to the charter.=20 W > I think that if people who wrote the charter for one WG want to go off = and wave it at another with some sort of exclusivity claim then the = charter claim has to at least be clear and unambiguous. >=20 >=20 >=20 >=20 > On Sat, Jun 11, 2011 at 7:16 PM, Matt McCutchen = wrote: > Restrictive assertions about name-bound credentials [1] are in the use > cases document and the protocol document (though the latter has a lot = of > reworking yet to come), but whether they are in scope of the current > charter is less clear. The whole charter is written with additive > assertions in mind and contains no mention of restrictive assertions > that would serve to include them, and there is the statement "More > general statements of policy for a domain are out of scope", which > definitely excludes orthogonal stuff like HASTLS and might exclude > restrictive assertions. >=20 > So it's possible that the current charter excludes restrictive > assertions, and it's possible that the exclusion is unintentional, or = at > least desirable to change now. >=20 > Phill says restrictive assertions are out of scope > (https://www.ietf.org/mail-archive/web/pkix/current/msg29356.html). = How > do others interpret the charter? If it is believed necessary, I would > support a charter update to place restrictive assertions in scope, > matching the current use cases document. Others? If consensus was = that > restrictive assertions should be out of scope, I'd appreciate if = people > could remind me of the pertinent arguments. >=20 > [1] I.e., an assertion that a legitimate credential for a given name > will satisfy a constraint, which a client may use as grounds to reject = a > credential it would have accepted in the absence of the assertion. >=20 > -- > Matt >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From matt@mattmccutchen.net Sun Jun 12 07:52:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C833511E80B2 for ; Sun, 12 Jun 2011 07:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b7WF+DrCPD9 for ; Sun, 12 Jun 2011 07:52:03 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 08CF911E80AB for ; Sun, 12 Jun 2011 07:52:03 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 8E0DF34806B for ; Sun, 12 Jun 2011 07:52:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=es59+o0jBVHr7hjxiAoKGJ6TkejI0ZTxYTIfNHWUZYQ estxUzbJYccOXPAij2jNxSKVhAQhpoRdk5ljqFNyLNLLpfAHGe3y8mPeLtCi8oEN pBDCisdRiS9YLLPgG5kx2xUCw6N+AFF6VskI9DuRV3yERwHzrtZSmSuW2COe2SiM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=7SrVxCqITR9jvvDCHGq1HNVqQ0Q=; b=ZnuTW4JQQr +aX1PjuHgCWA/fYTQ9stvRiMQ6RpTa6k26pgJgxjzQ7ajQW+M6yuxhWRG3jnEyec ZLZ9jFhYED8S2kjPUJlaYAX3iW3SxcQvtpeXrw1SVnRuJAtn/be5WQ6HtPDUwBF6 3PglIcQD40EZDl3tCyxMqNArjYIa77Pbo= Received: from [192.168.1.40] (pool-74-96-35-208.washdc.east.verizon.net [74.96.35.208]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 40645348062 for ; Sun, 12 Jun 2011 07:52:02 -0700 (PDT) From: Matt McCutchen To: dane In-Reply-To: <58E3203E-647A-4F7E-9530-45BB2ADDAF8A@kumari.net> References: <1307834212.2102.81.camel@localhost> <201106120109.p5C193sV020847@new.toad.com> <58E3203E-647A-4F7E-9530-45BB2ADDAF8A@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Sun, 12 Jun 2011 10:52:00 -0400 Message-ID: <1307890320.2009.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 14:52:03 -0000 On Sun, 2011-06-12 at 07:37 -0600, Warren Kumari wrote: > Ok, so -- seeing as this question keeps coming up (for whatever > reason) it seems that the we need to clearly and concisely define the > question, record it in the issue tracker and get our AD's to weigh in > here (I think that questions that clarify if something is in scope > should have the AD's input, especially if the chairs think that it is > in scope). > > So, can folk please help me clearly define the question? I'm having a > hard time wording it clearly, concisely and unambiguously. > Matt's "an assertion that a legitimate credential for a given name > will satisfy a constraint, which a client may use as grounds to reject > a > credential it would have accepted in the absence of the assertion." > comes close, but is (IMO) a little hard to read. > > Something along the lines of: > ---------------------------------------- > Is the "restrictive" case within the charter? > The restrictive case is: If a relying party finds information in the > DNS (for example in a TLSA record) that states that certificates X and > Y are the certificates that should be accepted, it may use this > information to reject certificate Z (even if it would have accepted Z > without this information). > ---------------------------------------------- > or > ---------------------------------------- > Is the "restrictive" case within the charter? > The restrictive case is: If a relying party finds information in the > DNS (for example in a TLSA record) that states that the credentials to > be use must satisfy the following criteria, it may use this > information to reject credentials that to not satisfy these criteria. > An informal example of the criteria could be: "Must match the > following set of certificates" > ---------------------------------------------- > > I think that this needs some serious word-smithing :-P . I am trying > to keep it general and informal enough so that it is easily understood > (I tried this with various words instead of "certificate" and > credentials, but they all sounded klunky, which leads me to think > that they were not good choices). I am looking for something that > clearly outlines the intent, not something too formal (I don't want us > to end up in the "Ha, but that doesn't apply on Thursdays in March if > it's also a full moon.") I was treading very carefully around the policy objection. The "must" and "should" in your formulations may be problematic. Also, your first formulation describes the restrictive use of an assertion that is both additive and restrictive. Since we do want to support purely restrictive assertions, it would be better to describe that case and let the reader realize that, with both additive and restrictive assertions in scope, a site owner could use both (or one assertion that works both ways; the difference is immaterial). The second formulation, with "must" replaced by "will", is pretty good. I would just mention that the assertion applies to the protocol endpoint identified by a tuple that contains a DNS name. For TLS, it is a service identified by (DNS name, transport protocol, port), but I want to be general to S/MIME, IPsec, etc. -- Matt From kent@bbn.com Sun Jun 12 09:52:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0A611E80C1 for ; Sun, 12 Jun 2011 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zey0XlPo6iTD for ; Sun, 12 Jun 2011 09:52:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E390811E80AE for ; Sun, 12 Jun 2011 09:52:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39116 helo=[10.111.112.9]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QVntg-0003gG-8V; Sun, 12 Jun 2011 12:52:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <58E3203E-647A-4F7E-9530-45BB2ADDAF8A@kumari.net> References: <1307834212.2102.81.camel@localhost> <201106120109.p5C193sV020847@new.toad.com> <58E3203E-647A-4F7E-9530-45BB2ADDAF8A@kumari.net> Date: Sun, 12 Jun 2011 12:40:46 -0400 To: Warren Kumari From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:52:25 -0000 At 7:37 AM -0600 6/12/11, Warren Kumari wrote: >Apologies to all for the latency in responding=20 >-- I'm traveling (and will be for a month or so)=20 >and haven't been checking email as frequently as=20 >I should=8A. > >On Jun 11, 2011, at 7:09 PM, John Gilmore wrote: > >> Deconfuse me a minute here. >> >> DANE was created because there's a significant problem with being able >> to trust the hundreds of trust-roots in current TLS CA practices. > >Yup, that was one of the driving forces behind the creation. > I concur. If the WG adopts a requirements statement that=20 includes this (IMHO important) case, then it=20 follows that DANE-enabled clients MUST be allowed=20 to reject a cert from a server, if that cert is=20 inconsistent with the DANE data retrieved and=20 validated by the client. Steve From internet-drafts@ietf.org Sun Jun 12 14:50:04 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5025A21F847E; Sun, 12 Jun 2011 14:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2jA32sdUHwb; Sun, 12 Jun 2011 14:50:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95B21F8479; Sun, 12 Jun 2011 14:50:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110612215003.14916.87041.idtracker@ietfa.amsl.com> Date: Sun, 12 Jun 2011 14:50:03 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 21:50:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Use Cases and Requirements for DNS-based Authentication = of Named Entities (DANE) Author(s) : Richard Barnes Filename : draft-ietf-dane-use-cases-03.txt Pages : 12 Date : 2011-06-12 Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-use-cases-03.txt From rbarnes@bbn.com Sun Jun 12 14:52:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3ED21F8491 for ; Sun, 12 Jun 2011 14:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.3 X-Spam-Level: X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMZKtSAaUO8p for ; Sun, 12 Jun 2011 14:52:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD621F8488 for ; Sun, 12 Jun 2011 14:52:24 -0700 (PDT) Received: from [128.89.253.22] (port=58759 helo=[192.168.1.11]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QVsZz-000AGb-Fl for dane@ietf.org; Sun, 12 Jun 2011 17:52:23 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "Richard L. Barnes" In-Reply-To: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> Date: Sun, 12 Jun 2011 17:52:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1082) Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 21:52:27 -0000 This version addresses a variety of comments raised during the earlier = last call. The diff can be found here: On Jun 12, 2011, at 5:50 PM, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-dane-use-cases-03.txt has been = successfully submitted by Richard Barnes and posted to the IETF = repository. >=20 > Filename: draft-ietf-dane-use-cases > Revision: 03 > Title: Use Cases and Requirements for DNS-based = Authentication of Named Entities (DANE) > Creation date: 2011-06-12 > WG ID: dane > Number of pages: 12 >=20 > Abstract: > Many current applications use the certificate-based authentication > features in TLS to allow clients to verify that a connected server > properly represents a desired domain name. Traditionally, this > authentication has been based on PKIX trust hierarchies, rooted in > well-known CAs, but additional information can be provided via the > DNS itself. This document describes a set of use cases in which the > DNS and DNSSEC could be used to make assertions that support the TLS > authentication process. >=20 >=20 >=20 >=20 > The IETF Secretariat From stephen.farrell@cs.tcd.ie Sun Jun 12 15:52:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEE911E8120 for ; Sun, 12 Jun 2011 15:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.366 X-Spam-Level: X-Spam-Status: No, score=-106.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZixN6X4ma+U for ; Sun, 12 Jun 2011 15:52:01 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B39D311E8076 for ; Sun, 12 Jun 2011 15:52:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1B968153856; Sun, 12 Jun 2011 23:51:57 +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=1307919116; bh=OM0xU+LK1WGrmt jjqjMETfrpVCX/StPci9rhAG6GmYs=; b=m648a3Z84cHNL8z4q5HIGupNdp/eZb lhbmdcorvmPTAO3P5UHBT1Jb55WhkYpML9VVaqiRIWrvUjE2ySw2Q0p56U/4glLI aG5bVMxPzxddQr2DVQ85yLcFqr/QH/+ukDF980h6TT+gTwRExsogTYpJH8iyRx13 pY80305cbTsVhw4JENHNr1Xfle1/eYLp1gIpV3BPnVQoOHg5uUF8DDe3UJ2tXotd neKg6XbeCV6Z/LZECUYeuQoQ94TYIcHAZFjVY/eomNoTLpOrL2Wabx830M6Ap5ds sQ0JO1l00QsrBsgrvg7gz5J6UE+fk4MImf+knJ/RAOve3LyPMGqUaX3w== 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 y+6SwBp3OZ3F; Sun, 12 Jun 2011 23:51:56 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.19.164]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 7E7011537F8; Sun, 12 Jun 2011 23:51:53 +0100 (IST) Message-ID: <4DF542FE.4040301@cs.tcd.ie> Date: Sun, 12 Jun 2011 23:51:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Kent References: <1307834212.2102.81.camel@localhost> <201106120109.p5C193sV020847@new.toad.com> <58E3203E-647A-4F7E-9530-45BB2ADDAF8A@kumari.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 22:52:02 -0000 On 12/06/11 17:40, Stephen Kent wrote: > At 7:37 AM -0600 6/12/11, Warren Kumari wrote: >> Apologies to all for the latency in responding -- I'm traveling (and >> will be for a month or so) and haven't been checking email as >> frequently as I shouldŠ. >> >> On Jun 11, 2011, at 7:09 PM, John Gilmore wrote: >> >>> Deconfuse me a minute here. >>> >>> DANE was created because there's a significant problem with being able >>> to trust the hundreds of trust-roots in current TLS CA practices. >> >> Yup, that was one of the driving forces behind the creation. >> > > I concur. > > If the WG adopts a requirements statement that includes this (IMHO > important) case, then it follows that DANE-enabled clients MUST be > allowed to reject a cert from a server, if that cert is inconsistent > with the DANE data retrieved and validated by the client. Same here. (As AD, since I was asked.) To be clear, I had a look at the charter again, and I think that the phrase "validate these bindings in the execution of specific applications" implicitly puts the restrictive semantic within the scope of the charter. The only alternative reading of that would be that DANE would have to either just define ways to make TLS/IPsec more liberal or else define entirely new ways to make TLS/IPsec work, neither of which would make sense. I see no need to recharter for this. If we do recharter maybe make a note that it should be clearer, if still needed at that point in time. Cheers, S. From warren@kumari.net Mon Jun 13 06:32:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D899E8012 for ; Mon, 13 Jun 2011 06:32:06 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ctx24+bW5Vu for ; Mon, 13 Jun 2011 06:32:06 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 52E339E8007 for ; Mon, 13 Jun 2011 06:32:03 -0700 (PDT) Received: from [10.111.112.250] (unknown [38.109.210.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 5F8F11B4017E; Mon, 13 Jun 2011 09:32:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Date: Mon, 13 Jun 2011 07:32:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <994BE570-2ECA-47CF-8315-5A7E276B798C@kumari.net> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:32:06 -0000 I would like to thank Richard again for authoring this -- I personally = think that he did a really good job of capturing / documenting the use = cases and integrating the provided comments=85 This document has already successfully passed WGLC (and we have = clarification that the "restrictive" case is within out charter), but as = a courtesy we'd like to give the folk that provided comments / feedback = a chance to confirm that your point was captured (and not mangled during = integration). Please provided confirmation or *clearly* explain what was = *misunderstood* by Thursday June 16th, 00:00UTC. Silence will count as = confirmation / acceptance. Once again, this is *NOT* the time to reopen discussions, WGLC already = happened (and there was strong consensus) W On Jun 12, 2011, at 3:52 PM, Richard L. Barnes wrote: > This version addresses a variety of comments raised during the earlier = last call. The diff can be found here: > >=20 >=20 >=20 > On Jun 12, 2011, at 5:50 PM, internet-drafts@ietf.org wrote: >=20 >> A new version of I-D, draft-ietf-dane-use-cases-03.txt has been = successfully submitted by Richard Barnes and posted to the IETF = repository. >>=20 >> Filename: draft-ietf-dane-use-cases >> Revision: 03 >> Title: Use Cases and Requirements for DNS-based = Authentication of Named Entities (DANE) >> Creation date: 2011-06-12 >> WG ID: dane >> Number of pages: 12 >>=20 >> Abstract: >> Many current applications use the certificate-based authentication >> features in TLS to allow clients to verify that a connected server >> properly represents a desired domain name. Traditionally, this >> authentication has been based on PKIX trust hierarchies, rooted in >> well-known CAs, but additional information can be provided via the >> DNS itself. This document describes a set of use cases in which the >> DNS and DNSSEC could be used to make assertions that support the TLS >> authentication process. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul@xelerance.com Mon Jun 13 07:22:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BC011E8090 for ; Mon, 13 Jun 2011 07:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe0IMBKzMYDB for ; Mon, 13 Jun 2011 07:22:12 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECFC11E808C for ; Mon, 13 Jun 2011 07:22:11 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0EAF5BF80; Mon, 13 Jun 2011 10:22:09 -0400 (EDT) Date: Mon, 13 Jun 2011 10:22:08 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <1307834212.2102.81.camel@localhost> <1307847622.2109.24.camel@localhost> 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: dane Subject: Re: [dane] Restrictive assertions in scope of charter? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:22:13 -0000 On Sun, 12 Jun 2011, Phillip Hallam-Baker wrote: > Again, I have solved the technical problem, so why not just consider doing it my way? Because CAA is based on the goodwill and competence of a group that seems to be doing worse over time instead of improving over time. Plus, with browers (and particularly open source browsers) we seem to have a much better control on the security implementations, especially when talking to DNSSEC data directly instead of via X.509 indirectly. > If you want to affect the way browsers work you will find it much easier to do so by establishing a critical mass of users and > proving the value in the Web Services field. I'd say that's what the DANE draft various DANE code snippets have done. >  So far, you have raised only cultural and > political objections (see previous discussion: I'd argue DANE is much less about politics and more about veriable code then CAA and CA's are, after all CA's and EVR et all is more lawyer enforced then technology enforced. DANE is about removing politics and lawyers. The security check ultimately has to be on the end client, not some middle man organisation. CAA is just a signaling method for CA's that uses DNSSEC as transport security. Whether the signal gets used or lost is totally up to the CA, the lawyers and the push of the free market. None of which are good security enforcers. While I don't mind the CAA, I have no use for it, I do object to CAA and other proposals slowing down DANE for non-technical reasons. > If you think that the issue here is an opportunity to use DNSSEC to replace the need for DV certs in certain use cases then the > appropriate response is to start a WG to put keys in the DNS. These reoccuring motions for delaying DANE are becoming repetitive and I am losing my patience with these. The IETF is about enabling new technologies, not about limiting new technologies. DNSSEC is not an accidental "opportunity". DANE grew out of the shortcomings and failures of PKIX on the open market. > What I am saying here is that far from having a turf battle with PKIX demanding to keep the RP restriction issue to themselves, > the DANE group should be begging them to take it off their hands. Good security usually does not involve begging nor shoving problems to eager recipients. In the last two months we have seen how dismal the state of security on the internet is. 17 year old high school dropouts are shaming one company after the other while some actual sophisticated hackers have taken the crown jewels. We're long overdue in replacing some of the old school technologies that failed to adequately protect us. Those who wish to remain using the old stuff, are free to do so. Just don't stand in our way of trying something else, because those 20 years of experience aren't doing us any good right now. Paul From ondrej.sury@nic.cz Mon Jun 13 08:39:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50611E80D9 for ; Mon, 13 Jun 2011 08:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCABbBqMh6-K for ; Mon, 13 Jun 2011 08:39:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C642211E80CE for ; Mon, 13 Jun 2011 08:39: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 5D2232A0DC0 for ; Mon, 13 Jun 2011 17:38:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1307979536; bh=dmbKnPbSkHeaOTO0ArAZ/uLTJ74mqrlfr0cdsSTjc8c=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C8MeM+oG7cEC/r66KN9BNKzA3YhBsZ0D5RtM7IYQOXRTdh9aY92Zp1Xay+u7RCdbd Ji2NXs4dPT14vVqJSmDf/miU2VDsSzHnLk1Bl40m9eH1pyPlWnNbjhw4YreE770T16 rxbsQ/hepAasel43m3Fk12zboHmP5rkE0VY9GkYs= Message-ID: <4DF62F10.804@nic.cz> Date: Mon, 13 Jun 2011 17:38:56 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <1307834212.2102.81.camel@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Restrictive assertions are in scope of charter. (Was: Restrictive assertions in scope of charter?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:39:01 -0000 On 12.6.2011 15:43, Warren Kumari wrote: > On Jun 11, 2011, at 6:53 PM, Phillip Hallam-Baker wrote: >> What I said was that the charter does not make an explicit claim. > > Yes, you are correct, the charter is not explicit here. > > Let's get the question clear and unambiguous, get our ADs to confirm > if the "restrictive assertions" case is within the scope, clearly > record this and move on. If the ADs thing it is necessary we can > discuss getting the clarification inserted / appended to the charter. Which has happened in <4DF542FE.4040301@cs.tcd.ie> and at least on of our AD think it is within the charter. I agree that if we ever recharter we could try to polish the charter to make it more clearer on the restrictive assertions, but now we can just move on with a fact that "Restrictive assertions are in the scope of the charter." Now when we have -03 of use cases document (after WGLC) Paul and Jacob can resume on the protocol draft (and they already did). 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 ------------------------------------------- From ondrej.sury@nic.cz Mon Jun 13 08:51:35 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1F11E80F3 for ; Mon, 13 Jun 2011 08:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC1vcs-8a-EP for ; Mon, 13 Jun 2011 08:51:35 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80D11E80CE for ; Mon, 13 Jun 2011 08:51:35 -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 712992A2BDF; Mon, 13 Jun 2011 17:51:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1307980294; bh=cCew44MOdyFvILq6JggFcOT7CZATi5uUJp0OTwKX4oI=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=pE3MsVnOBB6IJVfkL3xKzjYxupzkb2bQRwXFChfX3IcPTKdD3yjlzp9GiBZyg8ajP rb8DyfTB7wlGKY7ylwnXReOfmMU0Nel4NBXkuMKg496PMwimjawvpQpQFZv6sh8FSQ i6eNZnt7L/m0yyPq8ZtJW7BMvrO5AoXp6+nCCmxQ= Message-ID: <4DF63206.5000409@nic.cz> Date: Mon, 13 Jun 2011 17:51:34 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org, Richard Barnes , Paul Hoffman , Jakob Schlyter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] DANE WG Meeting at IETF-81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:51:36 -0000 Colleagues, we (the chairs) have requested a meeting slot at IETF-81 in Quebec. We thought that since there are lot of people who just come to meeting in person and not read the mailing list, we should do a summary on use cases and on the progress of the protocol we might have. Any thoughts on that or any requests for timeslots? 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 ------------------------------------------- From rbarnes@bbn.com Mon Jun 13 08:54:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE0011E80F3 for ; Mon, 13 Jun 2011 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHCFd4ZBY4wS for ; Mon, 13 Jun 2011 08:54:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD511E80EB for ; Mon, 13 Jun 2011 08:54:55 -0700 (PDT) Received: from [192.1.255.163] (port=64398 helo=col-dhcp-192-1-255-163.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QW9Ta-000KPt-Qf; Mon, 13 Jun 2011 11:54:54 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <4DF63206.5000409@nic.cz> Date: Mon, 13 Jun 2011 11:54:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DF63206.5000409@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] DANE WG Meeting at IETF-81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:54:56 -0000 I would be glad to provide an overview of the requirements document if = you think that would be helpful. --Richard On Jun 13, 2011, at 11:51 AM, Ond=C5=99ej Sur=C3=BD wrote: > Colleagues, >=20 > we (the chairs) have requested a meeting slot at IETF-81 in Quebec. >=20 > We thought that since there are lot of people who just come to meeting > in person and not read the mailing list, we should do a summary on use > cases and on the progress of the protocol we might have. >=20 > Any thoughts on that or any requests for timeslots? >=20 > O. > --=20 > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- From ondrej.sury@nic.cz Mon Jun 13 08:57:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBFE11E8137 for ; Mon, 13 Jun 2011 08:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWfvUQS2kmoS for ; Mon, 13 Jun 2011 08:57:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF4F11E80F3 for ; Mon, 13 Jun 2011 08:57:45 -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 6A1C62A03CE; Mon, 13 Jun 2011 17:57:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1307980664; bh=iqfClViQgKglI+x8VImfBSYp2uPjuHN9JxHVbfw5An0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PpWsWv/EXE0B7QzPP2g27h5hqWKaqgCXdeILt/jk4o8ZVPkTbfSL6pK8hAeKGKsKU gsrH0sxrZa3TizGdMrH8rI2hPlcyvUNbA7yv0BZ8oWDQIjy63htOUgpwWtdJE5Ft30 FpPhq632j8iiS7gYDWc8hiailT+SSiwpa/zcQ9P0= Message-ID: <4DF63378.3080503@nic.cz> Date: Mon, 13 Jun 2011 17:57:44 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4DF63206.5000409@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] DANE WG Meeting at IETF-81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:57:46 -0000 Richard, thank you very much. I think that would be very useful. I see two benefits in doing that. One is a way of saying: "Yes, we did what you have asked us."). And the second is providing overview to a people who don't follow mailing list, but attend WG meetings (and I think we saw there were such people in the room in Prague). O. On 13.6.2011 17:54, Richard L. Barnes wrote: > I would be glad to provide an overview of the requirements document if you think that would be helpful. > --Richard > > > On Jun 13, 2011, at 11:51 AM, OndÅ™ej Surý wrote: > >> Colleagues, >> >> we (the chairs) have requested a meeting slot at IETF-81 in Quebec. >> >> We thought that since there are lot of people who just come to meeting >> in person and not read the mailing list, we should do a summary on use >> cases and on the progress of the protocol we might have. >> >> Any thoughts on that or any requests for timeslots? >> >> 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 >> ------------------------------------------- > -- 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 ------------------------------------------- From dhc2@dcrocker.net Mon Jun 13 09:27:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8B21F852D for ; Mon, 13 Jun 2011 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM9MU6SzYaZq for ; Mon, 13 Jun 2011 09:27:35 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8102421F84FD for ; Mon, 13 Jun 2011 09:27:35 -0700 (PDT) Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p5DGRUNI031277 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 13 Jun 2011 09:27:35 -0700 Message-ID: <4DF63A6D.8040709@dcrocker.net> Date: Mon, 13 Jun 2011 09:27:25 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <4DF63206.5000409@nic.cz> <4DF63378.3080503@nic.cz> In-Reply-To: <4DF63378.3080503@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Jun 2011 09:27:35 -0700 (PDT) Subject: Re: [dane] DANE WG Meeting at IETF-81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:27:36 -0000 On 6/13/2011 8:57 AM, Ondřej Surý wrote: > Richard, > > thank you very much. I think that would be very useful. I see two > benefits in doing that. One is a way of saying: "Yes, we did what you > have asked us."). And the second is providing overview to a people who > don't follow mailing list, but attend WG meetings (and I think we saw > there were such people in the room in Prague). I thought that dane has had plenty of activity on its list, though I haven't tracked unresolved issues. Perhaps starting with a list of those issues will point to a good use of the meeting time? Working group meeting time is extremely scarce. Roughly 6 hours a year, at most. The time is rather explicitly not meant for tutorials. Spending time reviewing material that can be read outside the group mostly indicates that the group has not been making much progress on the mailing list. If it were making more progress on the mailing list, it would have developed a set of unresolved issues that would benefit from the considerable efficiencies of face-to-face discussion during that scarce time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@xelerance.com Mon Jun 13 10:32:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A57311E8157 for ; Mon, 13 Jun 2011 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3LEc8pP0WxR for ; Mon, 13 Jun 2011 10:32:21 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id D4A8E11E8153 for ; Mon, 13 Jun 2011 10:32:20 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id ED658BF80; Mon, 13 Jun 2011 13:32:18 -0400 (EDT) Date: Mon, 13 Jun 2011 13:32:18 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" , =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , Warren Kumari In-Reply-To: <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@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: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:32:22 -0000 On Sun, 12 Jun 2011, Richard L. Barnes wrote: > This version addresses a variety of comments raised during the earlier last call. The diff can be found here: > It seems my previous comments have not been integrated at all. Since Richard also did not provide feedback to them, I am not sure if he missed them or if he (or the WG) disagreed with them. Since various people quoted links to my previous comments during WGLC, I am somewhat confused what happened to these. Could Richard of the chairs clarify this for me? I have two real issues, and some typo fixes. 1) Use of DANE without DNSSEC "Nonetheless, using DANE in this way without also using DNSSEC represents provides a very small incremental security feature. Many common attacks against TLS connections already require the attacker to inject false A or AAAA records in order to steer the victim client to the attacker's server. An attacker that can already inject false DNS records can also fake DANE information (without DNSSEC) by simply spoofing the additional records required to carry the DANE information." The text was changed to even further reduce the non-dnsse case to "very small incremental security feature". I still believe more then just I are advocating for "no DANE without DNSSEC". I still believe this section should be removed, and no non-DNSSEC case of DANE should be supported or argued for. See also section 1. where it states: "With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain for DNS-based Authentication of Named Entities (DANE) is to use the DNS and DNSSEC to provide additional information about the cryptographic credentials associated with a domain, so that clients can use this information to increase the level of assurance they receive from the TLS handshake process. This document describes a set of use cases that capture specific goals for using the DNS in this way" It clearly states here this docment presents a way to use DNSSEC, not a way to insecurely publish cryptographic material in a better then nothing method. Telling people to use cryptographic material sent without modification protection is just wrong. It's worse then allowing sha1, which we don't allow any new draft to do. This part of the use case also violates section 4. Other Requirements "minimal dependancies" that states: "Minimal Dependencies: It should be possible for a site to deploy DANE without also deploying anything else, except DNSSEC." 2) DNS control means full domain control "Continuing to require PKIX validation also limits the degree to which DNS operators (as distinct from the owners of domains) can interfere with TLS authentication through this mechanism. As above, even if a DNS operator falsifies DANE records, it cannot masquerade as the target server unless it can also obtain a certificate for the target domain." This text is still very wrong. As I explained before, the DNS administrator can remove the draft-ietf-dane-protocol-7 Section 2.1. Certificate Type Field 2 and replace it with a type 1 (EEcert) or type 3 (pubkey) bypassing the CA limitation. There is nothing DANE can do to prevent the DNS operator from doing so. "Because these constraints do not increase the scope of PKIX-based assertions about domains, there is not a strict requirement for DNSSEC. Deletion of records removes the protection provided by this constraint, but the client is still protected by CA practices (as now). Injected or modified false records are not useful unless the attacker can also obtain a certificate for the target domain." The DNS operator could introduce a CNAME pointing to a domain under their control, and issuing a type 2 CA backed certificate for the CNAME target to get a "CA PKIX" assured DANE reference, so this statement is also wrong. I strongly suggest to updating/removing the sections that suggest DANE without DNSSEC adds any kind of security. It does not. Both attempts to describe these above are incorrect. 3) Some typos: The DANE mechanism must allow a clients -> The DANE mechanism must allow a client case a denial of service -> cause a denial of service Paul From zack.weinberg@gmail.com Mon Jun 13 14:08:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9F321F85A4 for ; Mon, 13 Jun 2011 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol-VLMumbNFu for ; Mon, 13 Jun 2011 14:08:01 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2C821F85A2 for ; Mon, 13 Jun 2011 14:08:01 -0700 (PDT) Received: by pvh18 with SMTP id 18so2515328pvh.31 for ; Mon, 13 Jun 2011 14:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eAOkwqbqcgEREaJUldDyqPgh5OIx2Gh9j2XzEOHXBHc=; b=GmcsJq9gWfIznLXRSL8zK+3WnHW6AG9bWRcHM1QKtZYnxCmrJM4bo4WxNpsFiDQsUB SRUPjbpAzW0OkVprUOmogLmLcZCk4OV8WYQ2gdA0KzawWUboRK8MM4Jo10j44f8/npJT xlJZihcxz6OrGBN8uNAC24ZoszBu/OLPP2GVg= 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:content-type :content-transfer-encoding; b=V8zWbahIQfxA7fIiSvwNiZ9wIQKWi0Z2sGbd9wSDEt3FnUOrzzM/1vTum85xc41Ai9 hvGQxTjXjVlKnpsbfCFzUgBx12c7uziDhMHrXOUKpjCWh3mM+6mnh0yfgHyggZGFJ3FG +XIzV1Bq8U4dW15l5/pzGPgqGnlsBuLlq+T9Y= MIME-Version: 1.0 Received: by 10.68.65.41 with SMTP id u9mr1025432pbs.527.1307999280701; Mon, 13 Jun 2011 14:08:00 -0700 (PDT) Sender: zack.weinberg@gmail.com Received: by 10.68.47.170 with HTTP; Mon, 13 Jun 2011 14:08:00 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Date: Mon, 13 Jun 2011 14:08:00 -0700 X-Google-Sender-Auth: SFVn4_eocxiRGlgNrJcA2dQ93Vk Message-ID: From: Zack Weinberg To: IETF DANE WG list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 21:08:01 -0000 On Mon, Jun 13, 2011 at 10:32 AM, Paul Wouters wrote: ... > It clearly states here this docment presents a way to use DNSSEC, > not a way to insecurely publish cryptographic material in a better then > nothing method. =C2=A0Telling people to use cryptographic material sent w= ithout > modification protection is just wrong. It's worse then allowing sha1, > which we don't allow any new draft to do. This part of the use case also > violates section 4. Other Requirements "minimal dependancies" that states= : > > =C2=A0 =C2=A0 =C2=A0 =C2=A0"Minimal Dependencies: It should be possible f= or a site to deploy > =C2=A0 =C2=A0 =C2=A0 =C2=A0 DANE without also deploying anything else, ex= cept DNSSEC." These were my words, and I didn't mean them to exclude the possibility of DANE without DNSSEC; I just wanted to avoid *further* dependencies. In particular, I think takeup of DANE by administrators of existing TLS-secured sites will be severely harmed if adding TLSA records to a zone breaks the service unless other things (outside the zone file) are reconfigured simultaneously. That said, I think you're right to advocate for DANE-with-DNSSEC as the only supported operational mode, just because it means neither specifiers nor implementers have to worry about whether DANE-without-DNSSEC information is usable in any given context. zw From paul@xelerance.com Mon Jun 13 14:22:06 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC1D21F85B9 for ; Mon, 13 Jun 2011 14:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF5t2XZk9bjo for ; Mon, 13 Jun 2011 14:22:06 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 22D1F21F85A8 for ; Mon, 13 Jun 2011 14:22:06 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4F94EBF8B; Mon, 13 Jun 2011 17:22:04 -0400 (EDT) Date: Mon, 13 Jun 2011 17:22:03 -0400 (EDT) From: Paul Wouters To: Zack Weinberg In-Reply-To: Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.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: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 21:22:06 -0000 On Mon, 13 Jun 2011, Zack Weinberg wrote: > That said, I think you're right to advocate for DANE-with-DNSSEC as > the only supported operational mode, just because it means neither > specifiers nor implementers have to worry about whether > DANE-without-DNSSEC information is usable in any given context. It's worse then worry about implementers though. I haven't found a single use case where non-DNSSEC DANE adds any security, as the use cases in the current draft are broken as I explained. Paul From hallam@gmail.com Mon Jun 13 15:59:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFD421F857A for ; Mon, 13 Jun 2011 15:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcCRcqXyleVv for ; Mon, 13 Jun 2011 15:59:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2243721F8579 for ; Mon, 13 Jun 2011 15:59:24 -0700 (PDT) Received: by ywp31 with SMTP id 31so3204347ywp.31 for ; Mon, 13 Jun 2011 15:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=knO8ZANKU26N6+zqHIM36G51SShnP47lMCxBM2F9p4k=; b=aZj7tD4UXH8JUFRNzhayiQwKhHJZj8W/AuIkH6F5XodIjyPM4Vt22xy9H+rhUMaW48 IbQq6hRtozRQnjQzPALT6n3Mwr+227ZqRWDaUFl5CI0l6KsT4TWQAV5Eqr4nPJgvz5Az l9UqKBEA/3fUnuK4wAT8exChfAUsz0c4IuvVc= 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=UNaFyeTgix5u2YpUWaSVDimtPBHWUZBFu6Tz0kp/RFaJ/KC2uybT82gl/hEzDiAfkJ e+3c25mF/lyzUioFQLcvGsHBBZ1FhaKoo0ndp1tQfLUkBuuFhGFF+bGZTse8gw2niOtD I1qISEBtQiwo5ls5E0FeHZ0aVv0MXMJmHEdI0= MIME-Version: 1.0 Received: by 10.100.78.18 with SMTP id a18mr5571620anb.19.1308005963514; Mon, 13 Jun 2011 15:59:23 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Mon, 13 Jun 2011 15:59:23 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Date: Mon, 13 Jun 2011 18:59:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=00504501755cd1c44404a59fdefa Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:59:25 -0000 --00504501755cd1c44404a59fdefa Content-Type: text/plain; charset=ISO-8859-1 If Alice is going to connect to the site en clair anyway, a DANE key without DNSSEC offers more security. On Mon, Jun 13, 2011 at 5:22 PM, Paul Wouters wrote: > On Mon, 13 Jun 2011, Zack Weinberg wrote: > > That said, I think you're right to advocate for DANE-with-DNSSEC as >> the only supported operational mode, just because it means neither >> specifiers nor implementers have to worry about whether >> DANE-without-DNSSEC information is usable in any given context. >> > > It's worse then worry about implementers though. I haven't found a > single use case where non-DNSSEC DANE adds any security, as the use > cases in the current draft are broken as I explained. > > Paul > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --00504501755cd1c44404a59fdefa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If Alice is going to connect to the site en clair anyway, a DANE key withou= t DNSSEC offers more security.


On Mon, Jun 13, 2011 at 5:22 PM, Paul Wouters <<= a href=3D"mailto:paul@xelerance.com">paul@xelerance.com> wrot= e:
On Mon, 13 Jun 2011, Zack= Weinberg wrote:

That said, I think you're right to advocate for DANE-with-DNSSEC as
the only supported operational mode, just because it means neither
specifiers nor implementers have to worry about whether
DANE-without-DNSSEC information is usable in any given context.

It's worse then worry about implementers though. I haven't found a<= br> single use case where non-DNSSEC DANE adds any security, as the use
cases in the current draft are broken as I explained.

Paul

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--00504501755cd1c44404a59fdefa-- From paul@xelerance.com Mon Jun 13 17:20:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500A521F852D for ; Mon, 13 Jun 2011 17:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdNvrTzHY2jK for ; Mon, 13 Jun 2011 17:20:46 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 12D3321F8512 for ; Mon, 13 Jun 2011 17:20:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BE99DBF80; Mon, 13 Jun 2011 20:20:30 -0400 (EDT) Date: Mon, 13 Jun 2011 20:20:30 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.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: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 00:20:47 -0000 On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: > If Alice is going to connect to the site en clair anyway, a DANE key without DNSSEC offers more security. It offers as much as the "may contain traces of peanuts" on the snickers wrapper.... If the attacker can spoof the DNS anser for the A record or DANE record, having the DANE record there adds no security. Really, the only marginal case you can argue for is that she is safe against all attackers that can spoof the A record, but not the DANE record. But once this is deployed, even LulzSec will know how to spoof a DANE record. People seem to think this is orthogonal to opportunistic encryption, but it is not. Alice can already do opportunistic https without DANE, so the protection against passive attacks is already there. Agains active attacks, DANE without DNSSEC adds nothing. Paul From ietf@augustcellars.com Mon Jun 13 18:36:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92DC11E80C4 for ; Mon, 13 Jun 2011 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vBXoYIpIle8 for ; Mon, 13 Jun 2011 18:36:28 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 323E611E80BF for ; Mon, 13 Jun 2011 18:36:28 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 9E07B6A411; Mon, 13 Jun 2011 18:36:27 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" , "'IETF DANE WG list'" References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> In-Reply-To: <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Date: Mon, 13 Jun 2011 19:07:11 -0700 Message-ID: <013f01cc2a37$c614c6c0$523e5440$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdoBJmwYo4JkWP0rzcHmAJ1XX5vwHu1dcPk4mH8CA= Content-Language: en-us Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 01:36:28 -0000 You may treat some of the comments below as IETF last call statements if you wish: 1. I cannot say that I like the title of section 3.3. To me a Domain-Issued Certificate is not the same as making a trust anchor assertion which is what I think the section is really about. To me a Domain-Issued Certificate would still be a true statement if Alice got a sub-CA to Charlie and issued here own certificates. I would prefer that this used more PKIX style terminology as what this section is addressing is publishing trust anchors. 2. Along the same lines I would like to change the title of section 3.2 - even a CA constraint is a constraint on a certificate. This might be better stated as Service Certificate Constraint 3. I find the statement referring to security consideration of section 3.1 from 3.2 difficult as they are not clearly defined as such. Given that I cannot easily find the security considerations - they are not in section 7 and are not labeled then it does not make sense. Implications might be a better word here. Also I think that if you really consider them to be considerations they should be referenced from section 7. 4. In section 3.2 the following text exists: " She would like to provide a way for visitors to her site to know that they should expect alice.example.com to present the specific certificate issued by Charlie." But there is nothing inherit here that says it was issued by Charlie. I would suggest s/the specific certificate issued by Charlie./a specific certificate./ 5. I am not happy with the Combination text. I am not sure that one would need to use combination for the stated case. That is a CA statement would be sufficient to state that a specific CA would be used. It would be more accurate to deal with the case of either specifying both a CA and a service certificate. Or specifying both a CA and a trust anchor certificate. From ietf@augustcellars.com Mon Jun 13 18:37:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6CF11E80C4 for ; Mon, 13 Jun 2011 18:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUdKk3y9itxw for ; Mon, 13 Jun 2011 18:37:54 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id BF73D11E80C2 for ; Mon, 13 Jun 2011 18:37:54 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 243A76EF32; Mon, 13 Jun 2011 18:37:54 -0700 (PDT) From: "Jim Schaad" To: "'Paul Wouters'" , "'Phillip Hallam-Baker'" References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> In-Reply-To: Date: Mon, 13 Jun 2011 19:08:37 -0700 Message-ID: <014001cc2a37$f9b13590$ed13a0b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdoBJmwYo4JkWP0rzcHmAJ1XX5vwHu1dcPAdQsrZ4A8MXOLQHPIz4fAVzV9I4C10LNuZNDd1pw Content-Language: en-us Cc: 'IETF DANE WG list' Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 01:37:55 -0000 I think the (extremely small) advance is that while you may not be talking to somebody you should be. At least nobody else can eaves drop on it. I tend to agree that this is a best an extremely marginal improvement. I would rather be told that I cannot talk securely that be in this situation. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Paul Wouters > Sent: Monday, June 13, 2011 5:21 PM > To: Phillip Hallam-Baker > Cc: IETF DANE WG list > Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases- > 03.txt > > On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: > > > If Alice is going to connect to the site en clair anyway, a DANE key without > DNSSEC offers more security. > > It offers as much as the "may contain traces of peanuts" on the snickers > wrapper.... > > If the attacker can spoof the DNS anser for the A record or DANE record, > having the DANE record there adds no security. Really, the only marginal case > you can argue for is that she is safe against all attackers that can spoof the A > record, but not the DANE record. But once this is deployed, even LulzSec will > know how to spoof a DANE record. > > People seem to think this is orthogonal to opportunistic encryption, but it is > not. > Alice can already do opportunistic https without DANE, so the protection > against passive attacks is already there. Agains active attacks, DANE without > DNSSEC adds nothing. > > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Mon Jun 13 18:43:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6D711E80A5 for ; Mon, 13 Jun 2011 18:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQCwyCy6Gqc2 for ; Mon, 13 Jun 2011 18:43:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EEDBC11E8075 for ; Mon, 13 Jun 2011 18:43:51 -0700 (PDT) Received: from [128.89.253.51] (port=64870 helo=[192.168.1.11]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QWIfV-0004cn-HW; Mon, 13 Jun 2011 21:43:50 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 13 Jun 2011 21:43:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 01:43:52 -0000 Hi Paul, Thanks for checking the revised version. > 1) Use of DANE without DNSSEC I added the paragraph you note to more correctly describe the impact of = using DANE without DNSSEC, as you, Jim, and Jeff all noted: Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html Can we agree that the current draft accurately describes the (admittedly = minor) effect of using DANE without DNSSEC? If this document has an = accurate description, then I think the discussion of whether or not this = behavior should be allowed can be addressed to the protocol document = itself. > 2) DNS control means full domain control >=20 > This text is still very wrong. As I explained before, the DNS > administrator can remove the draft-ietf-dane-protocol-7 Section > 2.1. Certificate Type Field 2 and replace it with a type 1 (EEcert) > or type 3 (pubkey) bypassing the CA limitation. There is nothing DANE > can do to prevent the DNS operator from doing so. You're correct that this is an attack, but it doesn't use "Use case 1" = DANE information, which is what the referenced text is talking about. = Bypassing the CA limitation in the manner you describe requires using = "Use Case 3" DANE information, for which DNSSEC is required. > The DNS operator could introduce a CNAME pointing to a domain under = their > control, and issuing a type 2 CA backed certificate for the CNAME = target > to get a "CA PKIX" assured DANE reference, so this statement is also = wrong. This is not correct. It depends on the application. All of the = applications described in RFC 6125 say "CNAME canonicalization is not = done", in which case this attack would not be effective. So neither of these proposed attacks has any bearing on "Use case 1" = DANE information. > 3) Some typos: >=20 > The DANE mechanism must allow a clients -> The DANE mechanism must = allow a client >=20 > case a denial of service -> cause a denial of service Thanks, I've corrected these in my working copy. --Richard= From hallam@gmail.com Mon Jun 13 19:16:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EFE21F8665 for ; Mon, 13 Jun 2011 19:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYL6CaYKHEsH for ; Mon, 13 Jun 2011 19:16:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFADE21F865B for ; Mon, 13 Jun 2011 19:16:08 -0700 (PDT) Received: by yxt33 with SMTP id 33so1167622yxt.31 for ; Mon, 13 Jun 2011 19:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PausySL8D+c+lkNKXhyYEYh95vSkiJ61npoKVxsJG3U=; b=dz1gzq/Cqqrz5RAXA+g6abYFMsd+WyUqeJOL+mYsdyUBKI0U0KLgxRZ9qNkgFKOQgy wBCUwWKfit2A+lmjxo57AQQAHoVbyIAXJXZbIAhgJemRMGiNWqVUv4x0AD89kexL4XDw m0GLgqUp4UkfPLw1yYfT5+ixWyNAqaE9/NTgk= 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=QynsHTs22KO7bsBFfP01AjY2l4FS8As7/NKE0hJOikpTMVn3bO3yojH4MPG6YPe+CH m1EqBMuOnOncqJd+AREROfro/+oFrbD1A3hvGCIO5FfWQ2WfBA4sKHoeRNxUwwaemQui psbXHOAv3b0QBLYMDs2kuhtePUBX/rLIdeW5k= MIME-Version: 1.0 Received: by 10.100.255.2 with SMTP id c2mr5829564ani.41.1308017768358; Mon, 13 Jun 2011 19:16:08 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Mon, 13 Jun 2011 19:16:08 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Date: Mon, 13 Jun 2011 22:16:08 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=00163662e6617162ab04a5a29e18 Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 02:16:09 -0000 --00163662e6617162ab04a5a29e18 Content-Type: text/plain; charset=ISO-8859-1 No, if we could get to the point where 90% of the Internet traffic was soft-scrambled with TLS, the task of attackers would be much harder. Only MITMs could attack. That cuts down the attack surface considerably. On Mon, Jun 13, 2011 at 8:20 PM, Paul Wouters wrote: > On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: > > If Alice is going to connect to the site en clair anyway, a DANE key >> without DNSSEC offers more security. >> > > It offers as much as the "may contain traces of peanuts" on the snickers > wrapper.... > > If the attacker can spoof the DNS anser for the A record or DANE record, > having the > DANE record there adds no security. Really, the only marginal case you can > argue > for is that she is safe against all attackers that can spoof the A record, > but not the > DANE record. But once this is deployed, even LulzSec will know how to spoof > a DANE > record. > > People seem to think this is orthogonal to opportunistic encryption, but it > is not. > Alice can already do opportunistic https without DANE, so the protection > against > passive attacks is already there. Agains active attacks, DANE without > DNSSEC adds > nothing. > > Paul > -- Website: http://hallambaker.com/ --00163662e6617162ab04a5a29e18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No, if we could get to the point where 90% of the Internet traffic was soft= -scrambled with TLS, the task of attackers would be much harder. Only MITMs= could attack. That cuts down the attack surface considerably.



On Mon, Jun 13, 2011 at = 8:20 PM, Paul Wouters <paul@xelerance.com> wrote:
On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote:

If Alice is going to connect to the site en clair anyway, a DANE key withou= t DNSSEC offers more security.

It offers as much as the "may contain traces of peanuts" on the s= nickers wrapper....

If the attacker can spoof the DNS anser for the A record or DANE record, ha= ving the
DANE record there adds no security. Really, the only marginal case you can = argue
for is that she is safe against all attackers that can spoof the A record, = but not the
DANE record. But once this is deployed, even LulzSec will know how to spoof= a DANE
record.

People seem to think this is orthogonal to opportunistic encryption, but it= is not.
Alice can already do opportunistic https without DANE, so the protection ag= ainst
passive attacks is already there. Agains active attacks, DANE without DNSSE= C adds
nothing.

Paul



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

--00163662e6617162ab04a5a29e18-- From paul@xelerance.com Mon Jun 13 22:55:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8357811E81D0 for ; Mon, 13 Jun 2011 22:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WKoY0uTIwHA for ; Mon, 13 Jun 2011 22:55:50 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6955811E81B2 for ; Mon, 13 Jun 2011 22:55:50 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4C880BF80; Tue, 14 Jun 2011 01:55:47 -0400 (EDT) Date: Tue, 14 Jun 2011 01:55:47 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.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: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 05:55:51 -0000 On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: > No, if we could get to the point where 90% of the Internet traffic was soft-scrambled with TLS, the task of attackers would be much harder. Only MITMs > could attack. That cuts down the attack surface considerably. I am not disagreeing that 90% of port 80 -> 443 would be good, but that was not the point below. You stated "If Alice is going to connect to the site en clair anyway". My point was that if she is going cleartext anyway, whether there is dane or not, protected by dnssec or not, would not make a difference to the attacker. I still do not understand any of the use cases for DANE without DNSSEC. Perhaps someone who does see this could explain it to me in clear steps that Alice is taking and where Malice is twarted by a DANE key without DNSSEC protection...... Paul > > On Mon, Jun 13, 2011 at 8:20 PM, Paul Wouters wrote: > On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: > > If Alice is going to connect to the site en clair anyway, a DANE key without DNSSEC offers more security. > > > It offers as much as the "may contain traces of peanuts" on the snickers wrapper.... > > If the attacker can spoof the DNS anser for the A record or DANE record, having the > DANE record there adds no security. Really, the only marginal case you can argue > for is that she is safe against all attackers that can spoof the A record, but not the > DANE record. But once this is deployed, even LulzSec will know how to spoof a DANE > record. > > People seem to think this is orthogonal to opportunistic encryption, but it is not. > Alice can already do opportunistic https without DANE, so the protection against > passive attacks is already there. Agains active attacks, DANE without DNSSEC adds > nothing. > > Paul > > > > > -- > Website: http://hallambaker.com/ > > > From ondrej.sury@nic.cz Mon Jun 13 23:35:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820441F0C4D for ; Mon, 13 Jun 2011 23:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPJh102lHxcN for ; Mon, 13 Jun 2011 23:35:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C4D351F0C35 for ; Mon, 13 Jun 2011 23:35:38 -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 D781D2A2B09 for ; Tue, 14 Jun 2011 08:35:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308033337; bh=Rr8TvjKNWGYlC3aXBGhRGMkMK3H3M+6+tGdxFX9JcOA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DKBGrZYu5W3Gsoe1dEQe72MJPBRvmpLtbfezrT0g8lexFgeXM4Q78Yfw/3egcv2Xm re+exRlKWgZTcN3XWpojdKrKZ7ineIDgiDzEsmGdfMDs3/6le6+IluT+Ht1zoV5xzG eGt/GDrU9zzCI2gYmL5BRQ8Qe8JGN3Dct7K/hyZM= Message-ID: <4DF70139.9020309@nic.cz> Date: Tue, 14 Jun 2011 08:35:37 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <4DF63206.5000409@nic.cz> <4DF63378.3080503@nic.cz> <4DF63A6D.8040709@dcrocker.net> In-Reply-To: <4DF63A6D.8040709@dcrocker.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] DANE WG Meeting at IETF-81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 06:35:39 -0000 On 13.6.2011 18:27, Dave CROCKER wrote: > > > On 6/13/2011 8:57 AM, Ondřej Surý wrote: >> Richard, >> >> thank you very much. I think that would be very useful. I see >> two benefits in doing that. One is a way of saying: "Yes, we did >> what you have asked us."). And the second is providing overview to >> a people who don't follow mailing list, but attend WG meetings (and >> I think we saw there were such people in the room in Prague). > > > I thought that dane has had plenty of activity on its list, though I > haven't tracked unresolved issues. Perhaps starting with a list of > those issues will point to a good use of the meeting time? That's a good point. We had these lists of issues before and my guess would be that we will have them in Quebec as well. I'll also try to pick one or two biggies to spend more time on them. > Working group meeting time is extremely scarce. Roughly 6 hours a > year, at most. The time is rather explicitly not meant for > tutorials. Generally I would agree, but I want to explicitly prevent what had happened in Prague, when we already had a progress, and suddenly we were sent back by people in the room. So I think that spending few minutes on "here what we have done" won't hurt and will help. > Spending time reviewing material that can be read outside the group > mostly indicates that the group has not been making much progress on > the mailing list. > > If it were making more progress on the mailing list, it would have > developed a set of unresolved issues that would benefit from the > considerable efficiencies of face-to-face discussion during that > scarce time. Again a good point, so maybe everybody could go and review our list of open issues: http://tools.ietf.org/wg/dane/trac/report/1 and tell us what they feel it is missing based on last (-07) version of the protocol draft: http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/ 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 ------------------------------------------- From paul@xelerance.com Tue Jun 14 12:37:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E391F0C62 for ; Tue, 14 Jun 2011 12:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiqS5MTerXsn for ; Tue, 14 Jun 2011 12:37:11 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 16E081F0C44 for ; Tue, 14 Jun 2011 12:37:10 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 9FD2FBF8B; Tue, 14 Jun 2011 15:37:07 -0400 (EDT) Date: Tue, 14 Jun 2011 15:37:07 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.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: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 19:37:12 -0000 On Mon, 13 Jun 2011, Richard L. Barnes wrote: > Can we agree that the current draft accurately describes the (admittedly minor) effect of using DANE without DNSSEC? If this document has an accurate description, then I think the discussion of whether or not this behavior should be allowed can be addressed to the protocol document itself. I thought the use cases document should lead to the technical spec, and not the other way around? If we're ignoring the use-cases specified here, i wonder why this whole exercise was started to begin with. >> 2) DNS control means full domain control >> >> This text is still very wrong. As I explained before, the DNS >> administrator can remove the draft-ietf-dane-protocol-7 Section >> 2.1. Certificate Type Field 2 and replace it with a type 1 (EEcert) >> or type 3 (pubkey) bypassing the CA limitation. There is nothing DANE >> can do to prevent the DNS operator from doing so. > > You're correct that this is an attack, but it doesn't use "Use case 1" DANE information, which is what the referenced text is talking about. Bypassing the CA limitation in the manner you describe requires using "Use Case 3" DANE information, for which DNSSEC is required. When I read use case 3.1, isn'tt it about restricting which CA can sign for a TLS EE cert from DNS, for both endusers and CA's ? DNS could still be spoofed there. It could be spoofed to the CA that was doing the DNS check, thereby bypassing it, and it can be spoofed to the enduser to point to the other CA once the first spoof caused Malice to obtain that "signed by wrong but qualified CA". I still don't see how lack of DNSSEC still adds security. btw. I missed an earlier typo: Note that this check does not guaranteed that -> Note that this check does not guarantee that >> The DNS operator could introduce a CNAME pointing to a domain under their >> control, and issuing a type 2 CA backed certificate for the CNAME target >> to get a "CA PKIX" assured DANE reference, so this statement is also wrong. > > This is not correct. It depends on the application. All of the applications described in RFC 6125 say "CNAME canonicalization is not done", in which case this attack would not be effective. Then it can still change or delete the DANE record. > So neither of these proposed attacks has any bearing on "Use case 1" DANE information. I still don't agree with your philosophy though. You are saying "we have a new security feature that narrows down the security further, but it is okay if this is bypassed because we still have the other security feature that did not narrow things down as much". It basically adds nothing in the case where it matters (when under attack) and does not prevent any of the incompetent/rogue CAs from issuing bad certs either. On top of that, it adds a very dangerous mode of "dane without dnssec can be okay" philosophy, which I'd argue is inheritantly more dangerous in its potential effects compared to the assets of this one miniscule corner case with a well behaving CA that's not under attack. Paul From warren@kumari.net Tue Jun 14 13:22:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9875A1F0C46 for ; Tue, 14 Jun 2011 13:22:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipxGDyCHz3Ep for ; Tue, 14 Jun 2011 13:22:27 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1721F0C3C for ; Tue, 14 Jun 2011 13:22:27 -0700 (PDT) Received: from [172.16.30.62] (unknown [67.41.131.30]) by vimes.kumari.net (Postfix) with ESMTPSA id B03B81B40175; Tue, 14 Jun 2011 16:22:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 14 Jun 2011 14:22:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:22:28 -0000 On Jun 13, 2011, at 6:20 PM, Paul Wouters wrote: > On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: >=20 >> If Alice is going to connect to the site en clair anyway, a DANE key = without DNSSEC offers more security. >=20 > It offers as much as the "may contain traces of peanuts" on the = snickers wrapper=85. I am wildly allergic to peanuts -- while the warning may be vague (and = non-authorative) I will choose NOT to eat the snickers bar (it is a DoS = on my tasty treat consumption). This is (IMO) much better than not = providing me any information and having me keel over in anaphylactic = sock. W >=20 > If the attacker can spoof the DNS anser for the A record or DANE = record, having the > DANE record there adds no security. Really, the only marginal case you = can argue > for is that she is safe against all attackers that can spoof the A = record, but not the > DANE record. But once this is deployed, even LulzSec will know how to = spoof a DANE > record. >=20 > People seem to think this is orthogonal to opportunistic encryption, = but it is not. > Alice can already do opportunistic https without DANE, so the = protection against > passive attacks is already there. Agains active attacks, DANE without = DNSSEC adds > nothing. >=20 > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From warren@kumari.net Tue Jun 14 13:24:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376E81F0C4F for ; Tue, 14 Jun 2011 13:24:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZgcCuWWzGNZ for ; Tue, 14 Jun 2011 13:24:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 920161F0C46 for ; Tue, 14 Jun 2011 13:24:33 -0700 (PDT) Received: from [172.16.30.62] (unknown [67.41.131.30]) by vimes.kumari.net (Postfix) with ESMTPSA id E7B421B404CA; Tue, 14 Jun 2011 16:24:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 14 Jun 2011 14:24:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6171F391-784D-4D1A-9878-9ADE7502703E@kumari.net> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:24:36 -0000 On Jun 14, 2011, at 2:22 PM, Warren Kumari wrote: >=20 > On Jun 13, 2011, at 6:20 PM, Paul Wouters wrote: >=20 >> On Mon, 13 Jun 2011, Phillip Hallam-Baker wrote: >>=20 >>> If Alice is going to connect to the site en clair anyway, a DANE key = without DNSSEC offers more security. >>=20 >> It offers as much as the "may contain traces of peanuts" on the = snickers wrapper=85. >=20 > I am wildly allergic to peanuts -- while the warning may be vague (and = non-authorative) I will choose NOT to eat the snickers bar (it is a DoS = on my tasty treat consumption). This is (IMO) much better than not = providing me any information and having me keel over in anaphylactic = sock. Whoops, I'm sorry all -- as I hit send I realized that this is NOT the = right time or place to be tripping down this rathole=85 Please ignore my last email=85. >=20 > W >=20 >=20 >>=20 >> If the attacker can spoof the DNS anser for the A record or DANE = record, having the >> DANE record there adds no security. Really, the only marginal case = you can argue >> for is that she is safe against all attackers that can spoof the A = record, but not the >> DANE record. But once this is deployed, even LulzSec will know how to = spoof a DANE >> record. >>=20 >> People seem to think this is orthogonal to opportunistic encryption, = but it is not. >> Alice can already do opportunistic https without DANE, so the = protection against >> passive attacks is already there. Agains active attacks, DANE without = DNSSEC adds >> nothing. >>=20 >> Paul >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From hallam@gmail.com Tue Jun 14 15:55:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE31F0C7D for ; Tue, 14 Jun 2011 15:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dl+jKhcgiub for ; Tue, 14 Jun 2011 15:55:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 141BC1F0C49 for ; Tue, 14 Jun 2011 15:55:15 -0700 (PDT) Received: by yxt33 with SMTP id 33so2009328yxt.31 for ; Tue, 14 Jun 2011 15:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W2tGceeX3LLUQuAsWKyKzkKg40N6TAvr6uMta8dNbTk=; b=g2sZYORmtoIHiS+PdJ0gRd8cyvp69epq3MJHhFgpJAJaUU5rGOBJ816oAmGNiTbIXB vYU8LFEWF8UcT0POtXYPgXPzOziJ3MMM/hz20KuDGZ7dSn/48lQB2EwwlBXw5ap6ZGfv /TjAJO6+/YLgBv5RZFdxGSzS2I5bU2FDacCZ0= 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=QpqTNvG+HWGrx+oHcRIrvoij3V1K5fy7UmkFH9tr1Qy+puy+RBRl2IKGs9ccyt1Zt/ lXFeqwtT3OUlYBcbrqW/g/EjJo7NLjtFqcbmKXUodzTwPyYu5167hDQyj/GPwT38v7Sl 5XfHcjqal7e07E4/kSisR/FnhFqUebY/lE0Fs= MIME-Version: 1.0 Received: by 10.101.194.24 with SMTP id w24mr7064113anp.151.1308092115439; Tue, 14 Jun 2011 15:55:15 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Tue, 14 Jun 2011 15:55:15 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> Date: Tue, 14 Jun 2011 18:55:15 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636c92c46dfd0dd04a5b3edb0 Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 22:55:24 -0000 --001636c92c46dfd0dd04a5b3edb0 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 3:37 PM, Paul Wouters wrote: > On Mon, 13 Jun 2011, Richard L. Barnes wrote: > > Can we agree that the current draft accurately describes the (admittedly >> minor) effect of using DANE without DNSSEC? If this document has an >> accurate description, then I think the discussion of whether or not this >> behavior should be allowed can be addressed to the protocol document itself. >> > > I thought the use cases document should lead to the technical spec, and not > the other way around? > If we're ignoring the use-cases specified here, i wonder why this whole > exercise was started to > begin with. Usually a use cases and requirements document has a statement about the constraints under which the application will be employed. In this case there are two separate DNSSEC requirements: 1) Domain name owner to deploy DNSSEC 2) Client to have access to the DNSSEC information Making #1 a requirement is a technical decision for the spec. I have no particular problem with that. #2 is a constraint that has to be addressed. There has to be a sensible story for what to do when the client does not have DNSSEC information available. -- Website: http://hallambaker.com/ --001636c92c46dfd0dd04a5b3edb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 14, 2011 at 3:37 PM, Paul Wo= uters <paul@xele= rance.com> wrote:
On Mon, 13 Jun 2011, Richard L. Barnes wrote:

Can we agree that the current draft accurately describes the (admittedly mi= nor) effect of using DANE without DNSSEC? =A0If this document has an accura= te description, then I think the discussion of whether or not this behavior= should be allowed can be addressed to the protocol document itself.

I thought the use cases document should lead to the technical spec, and not= the other way around?
If we're ignoring the use-cases specified here, i wonder why this whole= exercise was started to
begin with.

Usually a use cases and require= ments document has a statement about the constraints under which the applic= ation will be employed.

In this case there are two= separate DNSSEC requirements:

1) Domain name owner to deploy DNSSEC
2) Clie= nt to have access to the DNSSEC information

Making= #1 a requirement is a technical decision for the spec. I have no particula= r problem with that.
=A0
#2 is a constraint that has to be addressed. There has = to be a sensible story for what to do when the client does not have DNSSEC = information available.=A0

--001636c92c46dfd0dd04a5b3edb0-- From ondrej.sury@nic.cz Wed Jun 15 06:57:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99121F859F for ; Wed, 15 Jun 2011 06:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxQ90fCGQJxo for ; Wed, 15 Jun 2011 06:57:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CD28621F859E for ; Wed, 15 Jun 2011 06:57:27 -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 494792A2C48 for ; Wed, 15 Jun 2011 15:57:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308146246; bh=tW3Ry153jhb0n5om5ABHgpX0S8ZO/u9MUMKDOF9XR9c=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C8hvPEZ3reC4guVHjDMCYFnw5m1tYVqdh/xmT3IfYz7PJxe1wKYUnNRJX77w74CQC a06nod1MYTRDC86UORTXyD67dyW5Ou40sJLDMf3nrB7g5GrVIakCr2PWZYiswi3u36 5oy0+kX/Pk/KuZW31MwdpcR/3EP0v6ltX8h5d/7k= Message-ID: <4DF8BA46.7020800@nic.cz> Date: Wed, 15 Jun 2011 15:57:26 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:57:28 -0000 On 14.6.2011 07:55, Paul Wouters wrote: > I still do not understand any of the use cases for DANE without DNSSEC. > Perhaps someone > who does see this could explain it to me in clear steps that Alice is > taking and where > Malice is twarted by a DANE key without DNSSEC protection...... Youtube AS hijack. No A record was spoofed, but the traffic still went to hijackers. 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 ------------------------------------------- From paul@xelerance.com Wed Jun 15 08:13:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA33311E815F for ; Wed, 15 Jun 2011 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL3zaEjBFUlv for ; Wed, 15 Jun 2011 08:13:30 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 25F5311E815D for ; Wed, 15 Jun 2011 08:13:30 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1909EBF8A; Wed, 15 Jun 2011 11:13:28 -0400 (EDT) Date: Wed, 15 Jun 2011 11:13:27 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= , "Richard L. Barnes" In-Reply-To: <4DF8BA46.7020800@nic.cz> Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:13:31 -0000 On Wed, 15 Jun 2011, Ondøej Surý wrote: > On 14.6.2011 07:55, Paul Wouters wrote: >> I still do not understand any of the use cases for DANE without DNSSEC. >> Perhaps someone >> who does see this could explain it to me in clear steps that Alice is >> taking and where >> Malice is twarted by a DANE key without DNSSEC protection...... > > Youtube AS hijack. No A record was spoofed, but the traffic still went > to hijackers. Ahh indeed. The traffic was send to the same (stolen) IP range, and a dane record (not stolen and no massive dns polution) could have made a difference if youtube had made use of https. Richard, why don't we put something like this in the use-case document as a clear case instead of mixing it up with CA policies in use case 1. Alice runs a large https farm that is popular worldwide. Malice twarts all the traffic, for example via a BGP hijack, but is not in a position to spoof DNS traffic. Malice can receive the HTTPS traffic but needs to setup forged certificates because she does not have Alice's private key for the HTTPS cert. Alice publishing the public key or cert via DANE so that her customers will be warned/prevented from connecting to HTTPS servers under Malice's control. Paul From rbarnes@bbn.com Wed Jun 15 11:27:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7D411E810E for ; Wed, 15 Jun 2011 11:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.924 X-Spam-Level: X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jECsNb4I7dUX for ; Wed, 15 Jun 2011 11:27:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 247C311E8141 for ; Wed, 15 Jun 2011 11:27:53 -0700 (PDT) Received: from [192.1.255.163] (port=58152 helo=col-dhcp-192-1-255-163.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QWuod-000NoQ-2x; Wed, 15 Jun 2011 14:27:47 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <4DF8BA46.7020800@nic.cz> Date: Wed, 15 Jun 2011 14:27:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 18:27:57 -0000 You don't need to do it with BGP, someone on the same shared medium can = easily hijack your TCP connection without having to touch the DNS. --Richard On Jun 15, 2011, at 9:57 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 14.6.2011 07:55, Paul Wouters wrote: >> I still do not understand any of the use cases for DANE without = DNSSEC. >> Perhaps someone >> who does see this could explain it to me in clear steps that Alice is >> taking and where >> Malice is twarted by a DANE key without DNSSEC protection...... >=20 > Youtube AS hijack. No A record was spoofed, but the traffic still = went > to hijackers. >=20 > O. > --=20 > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Wed Jun 15 12:24:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518CB21F8601 for ; Wed, 15 Jun 2011 12:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBViDhTY6FTc for ; Wed, 15 Jun 2011 12:24:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4221F85FE for ; Wed, 15 Jun 2011 12:24:13 -0700 (PDT) Received: by gyf3 with SMTP id 3so14524gyf.31 for ; Wed, 15 Jun 2011 12:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gTK4QCGObZ7vsH4V3bg3Y4Fo/0utbcHHMV0zyggH8PQ=; b=p76H42Oj3zYVWtDJ/XujPNPU9cAMXd9zW0RUv41gk5SCac+XpDz1ymVbgfRrxkYXcd 5XKc4v5qfukxueKeOBThUK1kMISim0iZLkAkOT7aWRhrN/48Ejg1SHfShGAxhsRfBrQ2 SEnJfsAcGX+fAO+WlcKchn5ZdtEeSQRy84Bvs= 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=ISKUPckf8JYNwXSVJCWFdWpi4fTx41oZgvIAXLF4uQBJAp7sd6R8jOROrlgR3hEH6c pvAVkyTyfPgyZsCNN1STAbD7C8dbrJReV+jALA1XGZs3n7vmhkZGjga7gxxE+ttwQTZq WrqmigIbHaEDwLeF+iJudHDhcswjPE0TXfSNQ= MIME-Version: 1.0 Received: by 10.100.56.29 with SMTP id e29mr109827ana.129.1308165691826; Wed, 15 Jun 2011 12:21:31 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 15 Jun 2011 12:21:31 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> Date: Wed, 15 Jun 2011 15:21:31 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=001485f860e65e611704a5c50f7c Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:24:18 -0000 --001485f860e65e611704a5c50f7c Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable One area where BGP is a concern is in the hacker response to DNSSEC. While DNS spoofing is bad, the effects are generally localized. One concern with use of DNSSEC without additional security measures is that the DNSSEC control can be bypassed by attacking at the BGP layer. Attacks at the BGP layer have much wider consequences and at this point efforts towards BGP security are focused on preventing DoS attacks rather than enabling end-to-end security. Ergo it seems to me at least that if there is going to be DNSSEC enforcemen= t there has to be some means of binding keys in the DNS. Otherwise all that DNSSEC is doing is to force the attacker to switch from an attack with limited side effects to one with very large side effects. On Wed, Jun 15, 2011 at 2:27 PM, Richard L. Barnes wrote: > You don't need to do it with BGP, someone on the same shared medium can > easily hijack your TCP connection without having to touch the DNS. > --Richard > > > On Jun 15, 2011, at 9:57 AM, Ond=F8ej Sur=FD wrote: > > > On 14.6.2011 07:55, Paul Wouters wrote: > >> I still do not understand any of the use cases for DANE without DNSSEC= . > >> Perhaps someone > >> who does see this could explain it to me in clear steps that Alice is > >> taking and where > >> Malice is twarted by a DANE key without DNSSEC protection...... > > > > Youtube AS hijack. No A record was spoofed, but the traffic still went > > to hijackers. > > > > 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 > > ------------------------------------------- > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --001485f860e65e611704a5c50f7c Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable One area where BGP is a concern is in the hacker response to DNSSEC.
While DNS spoofing is bad, the effects are generally localized= . One concern with use of DNSSEC without additional security measures is th= at the DNSSEC control can be bypassed by attacking at the BGP layer. Attack= s at the BGP layer have much wider consequences and at this point efforts t= owards BGP security are focused on preventing DoS attacks rather than enabl= ing end-to-end security.

Ergo it seems to me at least that if there is going to = be DNSSEC enforcement there has to be some means of binding keys in the DNS= . Otherwise all that DNSSEC is doing is to force the attacker to switch fro= m an attack with limited side effects to one with very large side effects.<= /div>


On Wed, Jun 15, 2011 at 2:27 PM, Ri= chard L. Barnes <rb= arnes@bbn.com> wrote:
You don't need to do it with BGP, someone on the same shared medium can= easily hijack your TCP connection without having to touch the DNS.
--Richard


On Jun 15, 2011, at 9:57 AM, Ond=F8ej Sur=FD wrote:

> On 14.6.2011 07:55, Paul Wouters wrote:
>> I still do not understand any of the use cases for DANE without DN= SSEC.
>> Perhaps someone
>> who does see this could explain it to me in clear steps that Alice= is
>> taking and where
>> Malice is twarted by a DANE key without DNSSEC protection...... >
> Youtube AS hijack. =A0No A record was spoofed, but the traffic still w= ent
> to hijackers.
>
> O.
> --
> Ond=F8ej Sur=FD
> vedouc=ED v=FDzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
> Americka 23, 120 00 Praha 2, Czech Republic
> mailto:ondrej.sury@nic.cz = =A0 =A0http://nic.cz/
> tel:+420.2227= 45110 =A0 =A0 =A0 fax:+420.222745112
> -------------------------------------------
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--001485f860e65e611704a5c50f7c-- From paul@xelerance.com Wed Jun 15 12:48:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854A611E810D for ; Wed, 15 Jun 2011 12:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cy+47Pn1liVK for ; Wed, 15 Jun 2011 12:48:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 04D1411E8151 for ; Wed, 15 Jun 2011 12:48:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2EEE9BF8A; Wed, 15 Jun 2011 15:48:21 -0400 (EDT) Date: Wed, 15 Jun 2011 15:48:20 -0400 (EDT) From: Paul Wouters To: "Richard L. Barnes" In-Reply-To: Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:48:24 -0000 On Wed, 15 Jun 2011, Richard L. Barnes wrote: > You don't need to do it with BGP, someone on the same shared medium can easily hijack your TCP connection without having to touch the DNS. But then the DANE record without DNSSEC can also be forged, because the attacker can see/modify the DNS packets. So its is not a good example of DANE without DNSSEC. Paul From paul@xelerance.com Wed Jun 15 12:50:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B111E8165 for ; Wed, 15 Jun 2011 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G6kZ2EhlhSX for ; Wed, 15 Jun 2011 12:50:48 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 75E0111E810D for ; Wed, 15 Jun 2011 12:50:48 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id AC4A4BF8A; Wed, 15 Jun 2011 15:50:44 -0400 (EDT) Date: Wed, 15 Jun 2011 15:50:44 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:50:49 -0000 On Wed, 15 Jun 2011, Phillip Hallam-Baker wrote: > concern with use of DNSSEC without additional security measures is that > the DNSSEC control can be bypassed by attacking at the BGP layer. Can you explain how this works in a concrete example?. Assume an ISP nameserver with DNSESC root key preloaded, and no PKIX. Paul From nweaver@icsi.berkeley.edu Wed Jun 15 12:53:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FDD11E8161 for ; Wed, 15 Jun 2011 12:53:38 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79zo6axz6+ae for ; Wed, 15 Jun 2011 12:53:37 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9658511E8146 for ; Wed, 15 Jun 2011 12:53:37 -0700 (PDT) Received: from gala.icir.org (gala.ICIR.org [192.150.187.49]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 39AD1369FE2; Wed, 15 Jun 2011 12:53:37 -0700 (PDT) References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 15 Jun 2011 12:53:36 -0700 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:53:38 -0000 On Jun 15, 2011, at 12:21 PM, Phillip Hallam-Baker wrote: > One area where BGP is a concern is in the hacker response to DNSSEC. >=20 > While DNS spoofing is bad, the effects are generally localized. One = concern with use of DNSSEC without additional security measures is that = the DNSSEC control can be bypassed by attacking at the BGP layer. = Attacks at the BGP layer have much wider consequences and at this point = efforts towards BGP security are focused on preventing DoS attacks = rather than enabling end-to-end security. Pardon my ignorance, but I don't get the point here... DNSSEC is designed specifically so that the validator can either prove a = single possible path of trust exists from the root(s) of trust to the = target name OR that the point where the path of trust breaks, that it is = provably a break in trust where the parent cryptographically asserts = that it has no key material for the child. A full MitM attack (aka, your BGP attack) is thus provably detectable if = its tampering with DNSSEC records, and any application (EG, DANE) which = uses DNSSEC to distribute key material should naturally = scream-bloody-murder and fail if it found an unasserted break in the = chain of trust. Put simply, a BGP attack doesn't bypass the DNSSEC control, it rather = points out that DNSSEC is only useful for distributing key material or = other material in a PKI-ish like fashion (e.g. DANE). Because = otherwise, any application which uses A records is either trivially = vulnerable to the Man-in-the-middle or doesn't rely on DNS being = correct, regardless of how the attacker became a MitM (Take over the = recursive resolver, packet inject, BGP, whatever). Oh, and BGP attacks can be done without noticable side effects, having = been on a test network where such an attack was done. From rbarnes@bbn.com Wed Jun 15 14:17:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9411E813B for ; Wed, 15 Jun 2011 14:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irB97QuBsot5 for ; Wed, 15 Jun 2011 14:17:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 849A011E8136 for ; Wed, 15 Jun 2011 14:17:38 -0700 (PDT) Received: from [192.1.255.163] (port=62199 helo=col-dhcp-192-1-255-163.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QWxSy-000PzO-DM; Wed, 15 Jun 2011 17:17:36 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 15 Jun 2011 17:17:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8C326640-23F5-4032-9297-92CAA0F1225F@bbn.com> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:17:39 -0000 Agreed, not a great example. But you would need an additional set of = tools, so at least it's an annoyance for the attacker :) --Richard On Jun 15, 2011, at 3:48 PM, Paul Wouters wrote: > On Wed, 15 Jun 2011, Richard L. Barnes wrote: >=20 >> You don't need to do it with BGP, someone on the same shared medium = can easily hijack your TCP connection without having to touch the DNS. >=20 > But then the DANE record without DNSSEC can also be forged, because > the attacker can see/modify the DNS packets. So its is not a good > example of DANE without DNSSEC. >=20 > Paul From hallam@gmail.com Wed Jun 15 14:40:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CD611E819E for ; Wed, 15 Jun 2011 14:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjngM26gahgp for ; Wed, 15 Jun 2011 14:40:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E50E811E81A6 for ; Wed, 15 Jun 2011 14:39:56 -0700 (PDT) Received: by ywp31 with SMTP id 31so680505ywp.31 for ; Wed, 15 Jun 2011 14:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DMpM537Ct5X/VhqbwFx0uRHZ0zC9N7hDkd+XEl+P0Lg=; b=crSZw43l9VR9IjvXHdktkv1cZ5A+oMlv+7sgD9xgd+EAU0IbKvAtM8VqDjOHE1AIRx HNNeJj2CO+JP1a5Sg251AGdUIFERx7ka0kzhzZuS7FnaPbCNId0FGs+6ab2gnuFEV2d9 ig1Iwkpp0WRyM2lvv4oSePPwl8eKGzFywGdwc= 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=b5xGId6XGrLPNTNG/dxBH6ehZDhAcGMPbo6Srzfh3pW+PvKM/+9lDaX84Cr1qnEFmQ uKDvGRn49hi6PWAjk/OE/ckeOfwUt7tcFTkh5OKBLjXFXAdAAKCkYRJn+vhdmH1pflfs WsafqY5KWHYjCTTVfq3SkZUcSftBG2CDKJ8Hc= MIME-Version: 1.0 Received: by 10.100.255.2 with SMTP id c2mr144878ani.41.1308173996205; Wed, 15 Jun 2011 14:39:56 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Wed, 15 Jun 2011 14:39:55 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> Date: Wed, 15 Jun 2011 17:39:55 -0400 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=00163662e66159260704a5c6fe3a Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:40:16 -0000 --00163662e66159260704a5c6fe3a Content-Type: text/plain; charset=ISO-8859-1 The attacker wants to reroute the Facebook Website. Instead of manipulating the facebook.com A record, the attacker decides to reroute the Facebook IP address by advertising a bogus route. Securing the DNS name to IP mapping is not worth much unless you can also secure the mapping of the IP address to the endpoint. While BGP attacks can be done without major collateral damage by experts in the lab, the effect of less expert attackers who don't much care about that damage on the open network is likely to be rather less happy. My point was merely that all these things are connected and it is not very useful for folk to be making absolute statements about what is essential. You are not going to be able to defeat every attacker with one single scheme. But a scheme that can defeat 80% of hackers can still have real value in mitigating risk. The problem with declaring DNSSEC essential is that it is not going to be available everywhere you would want it. On Wed, Jun 15, 2011 at 3:53 PM, Nicholas Weaver wrote: > > On Jun 15, 2011, at 12:21 PM, Phillip Hallam-Baker wrote: > > > One area where BGP is a concern is in the hacker response to DNSSEC. > > > > While DNS spoofing is bad, the effects are generally localized. One > concern with use of DNSSEC without additional security measures is that the > DNSSEC control can be bypassed by attacking at the BGP layer. Attacks at the > BGP layer have much wider consequences and at this point efforts towards BGP > security are focused on preventing DoS attacks rather than enabling > end-to-end security. > > Pardon my ignorance, but I don't get the point here... > > DNSSEC is designed specifically so that the validator can either prove a > single possible path of trust exists from the root(s) of trust to the target > name OR that the point where the path of trust breaks, that it is provably a > break in trust where the parent cryptographically asserts that it has no key > material for the child. > > A full MitM attack (aka, your BGP attack) is thus provably detectable if > its tampering with DNSSEC records, and any application (EG, DANE) which uses > DNSSEC to distribute key material should naturally scream-bloody-murder and > fail if it found an unasserted break in the chain of trust. > > > Put simply, a BGP attack doesn't bypass the DNSSEC control, it rather > points out that DNSSEC is only useful for distributing key material or other > material in a PKI-ish like fashion (e.g. DANE). Because otherwise, any > application which uses A records is either trivially vulnerable to the > Man-in-the-middle or doesn't rely on DNS being correct, regardless of how > the attacker became a MitM (Take over the recursive resolver, packet inject, > BGP, whatever). > > > Oh, and BGP attacks can be done without noticable side effects, having been > on a test network where such an attack was done. > > -- Website: http://hallambaker.com/ --00163662e66159260704a5c6fe3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The attacker wants to reroute the Facebook Website.

Inst= ead of manipulating the facebook.com A = record, the attacker decides to reroute the Facebook IP address by advertis= ing a bogus route.

Securing the DNS name to IP mapping is not worth much u= nless you can also secure the mapping of the IP address to the endpoint.


While BGP attacks can be done without= major collateral damage by experts in the lab, the effect of less expert a= ttackers who don't much care about that damage on the open network is l= ikely to be rather less happy.

My point was merely that all these things are connected= and it is not very useful for folk to be making absolute statements about = what is essential.

You are not going to be able to= defeat every attacker with one single scheme. But a scheme that can defeat= 80% of hackers can still have real value in mitigating risk.

The problem with declaring DNSSEC essential is that it = is not going to be available everywhere you would want it.=A0
On Wed, Jun 15, 2011 at 3:53 PM, Nicholas Weave= r <nweave= r@icsi.berkeley.edu> wrote:

On Jun 15, 2011, at 12:21 PM, Phillip Hallam-Baker wrote:

> One area where BGP is a concern is in the hacker response to DNSSEC. >
> While DNS spoofing is bad, the effects are generally localized. One co= ncern with use of DNSSEC without additional security measures is that the D= NSSEC control can be bypassed by attacking at the BGP layer. Attacks at the= BGP layer have much wider consequences and at this point efforts towards B= GP security are focused on preventing DoS attacks rather than enabling end-= to-end security.

Pardon my ignorance, but I don't get the point here...

DNSSEC is designed specifically so that the validator can either prove a si= ngle possible path of trust exists from the root(s) of trust to the target = name OR that the point where the path of trust breaks, that it is provably = a break in trust where the parent cryptographically asserts that it has no = key material for the child.

A full MitM attack (aka, your BGP attack) is thus provably detectable if it= s tampering with DNSSEC records, and any application (EG, DANE) which uses = DNSSEC to distribute key material should naturally scream-bloody-murder and= fail if it found an unasserted break in the chain of trust.


Put simply, a BGP attack doesn't bypass the DNSSEC control, it rather p= oints out that DNSSEC is only useful for distributing key material or other= material in a PKI-ish like fashion (e.g. DANE). =A0Because otherwise, any = application which uses A records is either trivially vulnerable to the Man-= in-the-middle or doesn't rely on DNS being correct, regardless of how t= he attacker became a MitM (Take over the recursive resolver, packet inject,= BGP, whatever).


Oh, and BGP attacks can be done without noticable side effects, having been= on a test network where such an attack was done.




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

--00163662e66159260704a5c6fe3a-- From matt@mattmccutchen.net Wed Jun 15 16:07:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B07311E8178 for ; Wed, 15 Jun 2011 16:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxCdwuK+9OUW for ; Wed, 15 Jun 2011 16:07:44 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8961A11E80A0 for ; Wed, 15 Jun 2011 16:07:44 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 22C9810AFB2 for ; Wed, 15 Jun 2011 16:07:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=CGf+4PiFhZEaIMYfH5PeeDnb4tZKbjw1IxBmgHTGd/c eFrEyI2ifghtnW+Pc0EXi86hR/v/yTZSZp2gDEtAtt5PfLDl0qcqhhb66k/GvdDF bMyiVGGew+OpRZhr6EbGgO6C6NeCAqX5WTgVBLIi98sEcoMlYDcQiw0L9QGr1YGg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=qg4XuH+qs3NH7wvRyJC9+vc0AyY=; b=kpE36dae4u H9TrtxwKd3deEEGd64iuZiyFQB3wsoHq+vJRpCNVpIpKv4MoMhbY5bs8x1njeeIj BokoUD6T6dKVqClVjRlg25p+n9M07aSmdfa3ZDmCeWmmhMDbaZ+yKmqw9LX3eAQc qlMY6l/AhdFyyar/AniYnMyOTJ0a4bPkg= Received: from [192.168.1.40] (pool-74-96-35-208.washdc.east.verizon.net [74.96.35.208]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id BA14C10AFA1 for ; Wed, 15 Jun 2011 16:07:43 -0700 (PDT) From: Matt McCutchen To: dane In-Reply-To: <994BE570-2ECA-47CF-8315-5A7E276B798C@kumari.net> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <994BE570-2ECA-47CF-8315-5A7E276B798C@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 15 Jun 2011 19:07:38 -0400 Message-ID: <1308179258.2278.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 23:07:45 -0000 On Mon, 2011-06-13 at 07:32 -0600, Warren Kumari wrote: > This document has already successfully passed WGLC (and we have > clarification that the "restrictive" case is within out charter), but > as a courtesy we'd like to give the folk that provided comments / > feedback a chance to confirm that your point was captured (and not > mangled during integration). > > Please provided confirmation or *clearly* explain what was > *misunderstood* by Thursday June 16th, 00:00UTC. Silence will count as > confirmation / acceptance. > > Once again, this is *NOT* the time to reopen discussions, WGLC already > happened (and there was strong consensus) No action was taken on my comments here: https://www.ietf.org/mail-archive/web/dane/current/msg02578.html Also, between -02 and -03, the document gained some paragraphs about using DANE to restrict certificate issuance by CAs. As a use case, this is outside our charter and I don't remember it ever being discussed on the list. Of course, once DANE information is published, nothing stops CAs from looking at it as part of their fraud checks. -- Matt From matt@mattmccutchen.net Wed Jun 15 16:15:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9834111E80A0 for ; Wed, 15 Jun 2011 16:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnuJmMmvLBkE for ; Wed, 15 Jun 2011 16:15:20 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31211E8080 for ; Wed, 15 Jun 2011 16:15:20 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 0442D59806C for ; Wed, 15 Jun 2011 16:15:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=JcslAlPdOSqH4F2lpiMsT4e1eVIzU1Ahyowl6AU4MQc P0g6JUpCTX4p+/fBFGTcwgwmDUCyI5kn1KLyweNtupSpvLzJ/0W61hOpdR4MDdhp RXl1gWZnjY65dVH6xDz+fNWUAqTJPCBjkAMK9Hmr6Cd0wLpsaZMlmlh7tdYmsbeI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=SUaXob+rYzF1ZOuaPgFcWb+q9eE=; b=G8Gla4myWW 78MP3LOWURX9mJfoILRXUrhiGfaxkmLTkOn7VYGSp6+cJX6aYTe7xM0cXqVK8sbE Ce0uwYZ0bhsH9372Lze4V4rsj3IZ+aagcnkhlbmJV0KK/p6UZMMQXWye47wnmip3 Uiz+CApV+hucrTZySmGUHzbeN9081pwTM= Received: from [192.168.1.40] (pool-74-96-35-208.washdc.east.verizon.net [74.96.35.208]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id A2E57598069 for ; Wed, 15 Jun 2011 16:15:16 -0700 (PDT) From: Matt McCutchen To: dane In-Reply-To: <1308179258.2278.6.camel@localhost> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <994BE570-2ECA-47CF-8315-5A7E276B798C@kumari.net> <1308179258.2278.6.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Wed, 15 Jun 2011 19:15:14 -0400 Message-ID: <1308179714.2278.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 23:15:21 -0000 On Wed, 2011-06-15 at 19:07 -0400, Matt McCutchen wrote: > Also, between -02 and -03, the document gained some paragraphs about > using DANE to restrict certificate issuance by CAs. As a use case, this > is outside our charter and I don't remember it ever being discussed on > the list. Never mind, I found the thread now: https://www.ietf.org/mail-archive/web/dane/current/msg02583.html I guess I missed commenting then. I do not object to leaving the use case in the document pending a decision on whether it is really appropriate for DANE to do this. -- Matt From Jeff.Hodges@KingsMountain.com Wed Jun 15 19:53:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBD411E808A for ; Wed, 15 Jun 2011 19:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48uDSyxUDDTT for ; Wed, 15 Jun 2011 19:53:41 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id DDB2B11E8085 for ; Wed, 15 Jun 2011 19:53:40 -0700 (PDT) Received: (qmail 32379 invoked by uid 0); 16 Jun 2011 02:53:38 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 16 Jun 2011 02:53:38 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=EnjgO/jqe8g0imP0Ukw0mcoH8zOy1sXiqo0wZxvUvvRjUfEKBhR8FeV71FFcOPHf7UtZw6INSgU58gZmHc4803OhJz+o5y3R3i/QJ7aGW1SSVGEUJOG7g+Ly754sP9gX; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QX2iA-0006YR-3e; Wed, 15 Jun 2011 20:53:38 -0600 Message-ID: <4DF97030.3040005@KingsMountain.com> Date: Wed, 15 Jun 2011 19:53:36 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" 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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF DANE WG list Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 02:53:42 -0000 wrt my comments in.. [dane] comments on draft-ietf-dane-use-cases-02 http://www.ietf.org/mail-archive/web/dane/current/msg02582.html ..although the Introduction section in -03 is now more clear, you didn't include the portions describing MITM attacks and certificate mis-issuance. Thus the comments I and others had WRT the sudden appearance of the phrase "guarding against CA mis-issue" in the opening paragraph of "3.4. Delegated Services" are un-addressed. without material along the lines of.. However, unless there is a cryptographic binding between information in the TLS channel and information in the DNS resolution channel, as well as authentication of the DNS interaction and the returned DNS data, the information obtained via the DNS is vulnerable to being misrepresented or tampered with, thus allowing for man-in-the-middle (MITM) impersonation of the application service. Such MITM impersonation can today be accomplished by a network attacker by obtaining a so-called "mis-issued" certificate (obtained, for example, from a compromised member of the set of well-known widely trusted-by-default CAs [ref?]) for some victim application service domain, and using it along with "poisoned" DNS resolution such that an arbitrary server of the network attacker's choice appears to legitimately serve the victim application service. ..in the doc, then it lacks some important context with respect to the use cases and their security considerations. Other folks had noted on the list that having "CA mis-issue" used at the beginning of S 3.4 without definition or context confuses readers. In.. http://www.ietf.org/mail-archive/web/dane/current/msg02680.html ..Jim Schaad said amongst other things.. > 3. I find the statement referring to security consideration of section 3.1 > from 3.2 difficult as they are not clearly defined as such. Given that I > cannot easily find the security considerations - they are not in section 7 > and are not labeled then it does not make sense. Implications might be a > better word here. Also I think that if you really consider them to be > considerations they should be referenced from section 7. I agree with Jim. I'd also noted similar things in my detailed review (see link at beginning of this msg) with respect the nominal "security considerations" ( I termed them "use case security analysis and derived requirements", to some degree because they are use-case-specfic considerations, and then one could have an actual Sec Cons section with global stuff in it and refer back to these cleanly). wrt S 3.1... > I would encapsulate the below paras in a subsection entitled something like > "use case security analysis and derived requirements" because, strictly > speaking, they aren't part of the use case... > >> >> Because these constraints do not increase the scope of PKIX-based >> assertions about domains, there is not a strict requirement for >> DNSSEC. Deletion of records removes the protection provided by this >> constraint, but the client is still protected by CA practices (as >> now). Injected or modified false records are not useful unless the >> attacker can also obtain a certificate for the target domain. In the >> worst case, tampering with these constraints increases the risk of >> false authentication to the level that is now standard. >> >> Injected or modified false records can be used for denial of service, >> even if the attacker does not have a certificate for the target >> domain. If an attacker can modify DNS responses that a target host >> receives, however, there are already much simpler ways of denying >> service, such as providing a false A or AAAA record. In this case, >> DNSSEC is not helpful, since an attacker could still case a denial of >> service by blocking all DNS responses for the target domain. >> >> Continuing to require PKIX validation also limits the degree to which >> DNS operators (as distinct from the owners of domains) can interfere >> with TLS authentication through this mechanism. As above, even if a >> DNS operator falsifies DANE records, it cannot masquerade as the >> target server unless it can also obtain a certificate for the target >> domain. > And for S 3.3... > I would encapsulate the below paras in a subsection entitled something like > "use case security analysis and derived requirements"... >> >> Alice's advertising of trust anchor material in this way does not >> guarantee that Bob will accept the advertised trust anchor. For >> example, Bob might have out-of-band information (such as a pre- >> existing local policy) that indicates that the CA Trent advertised by >> Alice is not trustworthy, which would lead him to decide not to >> accept Trent as a TA, and thus to reject Alice's certificate if it is >> issued under Trent. >> >> >> >> This is not a significant incremental risk, however, relative to the >> current PKIX-based system. In the current system, CAs need to verify >> that an entity requesting a certificate for a domain is actually the >> legitimate holder of that domain. Typically this is done using >> information published about that domain, such as WHOIS email >> addresses or special records inserted into a domain. By manipulating >> these values, it is possible for DNS operators to obtain certificates >> from some well-known certificate authorities today without >> authorization from the true domain owner. Jim Schaad in the same msg also said... > 1. I cannot say that I like the title of section 3.3. To me a > Domain-Issued Certificate is not the same as making a trust anchor assertion > which is what I think the section is really about. To me a Domain-Issued > Certificate would still be a true statement if Alice got a sub-CA to Charlie > and issued here own certificates. I would prefer that this used more PKIX > style terminology as what this section is addressing is publishing trust > anchors. I also think the title of section 3.3 can be improved and had suggested.. >> 3.3. Domain-Issued Certificates > > "self issued certificate" seems to be a more commonly used term if one > searches the net for both terms. though i think i can understand why you may > want to use "domain issued" (arguably more technically accurate?). might > want a brief intro para and equate the two terms. Editorial comments are below, some of which i see others have also noticed. I may make some further comments in the list thread. thanks, =JeffH EDITORIAL --------- In S 3.1: s/does not guaranteed/does not guarantee/ s/represents provides/represents/ or s/represents provides/provides/ In S 3.3: s/since because/since/ or s/since because/because/ > Opportunistic Security The DANE mechanism must allow a clients to s/a clients/a client/ or s/a clients/clients/ ? > Clients that do not support DANE > should continue to work as if DANE information were not present perhaps.. Clients that do not support DANE should continue to work as specified, regardless of whether DANE information is present or not. --- end From Jeff.Hodges@KingsMountain.com Wed Jun 15 20:07:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6411E80F0 for ; Wed, 15 Jun 2011 20:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK5giZ7UQ18w for ; Wed, 15 Jun 2011 20:07:58 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id 7791B11E80B5 for ; Wed, 15 Jun 2011 20:07:58 -0700 (PDT) Received: (qmail 14877 invoked by uid 0); 16 Jun 2011 03:07:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 16 Jun 2011 03:07:57 -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=HUr5ZrqeOpCISUS5kZrzc1aosOIV6ytFYnlC6PBsbft8pxvh4jLEBFM7O+bdzRJMTNrpUlKi1FP+i2u4qw5HMaGTigTshE/bckptNOUqHtXt06S697dBHGX2JQJ8rRZZ; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QX2w0-0005qG-K3 for dane@ietf.org; Wed, 15 Jun 2011 21:07:56 -0600 Message-ID: <4DF9738B.1000000@KingsMountain.com> Date: Wed, 15 Jun 2011 20:07:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list 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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 03:07:59 -0000 Jim Schaad said.. > > 2. Along the same lines I would like to change the title of section 3.2 - > even a CA constraint is a constraint on a certificate. This might be better > stated as Service Certificate Constraint I'm nominally ok with the current section title, but if one used Jim's suggested title I'd use "Application Service Certificate Constraints" I also had suggested adding a short intro paragraph before the existing first paragraph briefly explaining the use case context and what is meant by "CA constraints". In http://www.ietf.org/mail-archive/web/dane/current/msg02582.html I said: >> 3.1. CA Constraints > > I would add a short intro para explaining why this use case is named "CA > constraints". > >> >> Alice runs a website on alice.example.com and has obtained a >> certificate from the well-known CA Charlie. She is concerned that >> ............ Jim Schaad also said: > > 4. In section 3.2 the following text exists: " She would like to provide a > way for visitors to her > site to know that they should expect alice.example.com to present the > specific certificate issued by Charlie." But there is nothing inherit > here that says it was issued by Charlie. I would suggest s/the specific > certificate issued by Charlie./a specific certificate./ I tend to agree with this suggestion. thanks, =JeffH From i.grok@comcast.net Wed Jun 15 21:20:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5F11E8115 for ; Wed, 15 Jun 2011 21:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZsN3j9s+SZw for ; Wed, 15 Jun 2011 21:20:38 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id CB65611E80A3 for ; Wed, 15 Jun 2011 21:20:30 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id wUKj1g0041HzFnQ59ULX0N; Thu, 16 Jun 2011 04:20:31 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta14.westchester.pa.mail.comcast.net with comcast id wULW1g00k00PQ6U3aULW61; Thu, 16 Jun 2011 04:20:30 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p5G4KTEE016911 for ; Thu, 16 Jun 2011 00:20:29 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p5G4KSOb016909 for dane@ietf.org; Thu, 16 Jun 2011 00:20:28 -0400 Date: Thu, 16 Jun 2011 00:20:28 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20110616042028.GC10766@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4DF8BA46.7020800@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 04:20:39 -0000 On Wed, Jun 15, 2011 at 03:57:26PM +0200, Ondřej Surý wrote dane: > On 14.6.2011 07:55, Paul Wouters wrote: > > I still do not understand any of the use cases for DANE without DNSSEC. > > Perhaps someone > > who does see this could explain it to me in clear steps that Alice is > > taking and where > > Malice is twarted by a DANE key without DNSSEC protection...... > > Youtube AS hijack. No A record was spoofed, but the traffic still went > to hijackers. Sure, but assuming that you're connecting via HTTPS rather than HTTP (DANE doesn't even kick in if HTTPS isn't being used), even PKIX would flag a problem with this kind of MITM, unless the hijackers also got the private keys. Honestly, if that's the threat, DANE won't help either. I guess you could claim that they could trick a CA into a misissue, but I'm having a hard time seeing how that attack is easier/cheaper than attacking a DNS server hosting an unsigned zone. -- Scott Schmit From cloos@jhcloos.com Wed Jun 15 22:22:33 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2181F11E80BA for ; Wed, 15 Jun 2011 22:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9z8ygG5mh6y for ; Wed, 15 Jun 2011 22:22:32 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5211E80B4 for ; Wed, 15 Jun 2011 22:22:31 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id D8D8840091; Thu, 16 Jun 2011 05:22:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1308201749; bh=FXnIMRMBCinll4VYSGT74HjN8nW75BKAiE0AjN3NKFE=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Qvz2x7MI3IJoIrvnZ4kW6MViwfdwho7sq5SRcIv1DUKksqGAEXTIY82TZi06bjoHS 35rHTAbLr8pWZMJUbvyn1lteqH4ee2r5K6bJwWEJIPwYI6nH4QioK02OKzDapaj1LB P074Oi0BPgNcCGRXejDT1ill97NdR9Mvmwy4DC30= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4B466260042; Thu, 16 Jun 2011 05:20:42 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20110616042028.GC10766@odin.ulthar.us> (Scott Schmit's message of "Thu, 16 Jun 2011 00:20:28 -0400") References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <20110616042028.GC10766@odin.ulthar.us> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2011 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: Thu, 16 Jun 2011 01:20:42 -0400 Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110616:dane@ietf.org::bwZeZYw+2dnhe/GH:000UClqu Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 05:22:33 -0000 >>>>> "SS" == Scott Schmit writes: SS> (DANE doesn't even kick in if HTTPS isn't being used) You really need to write TLS there; DANE applies not just to https, but to anything layered over TLS, including cases when TLS is negotiated after the sockets are up. (At the very least, smtp, pop3, imap, ftp, xmpp and http -- including protocols like ipp which are layered upon http -- support STARTTLS.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From Jeff.Hodges@KingsMountain.com Wed Jun 15 22:26:22 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062E111E80BA for ; Wed, 15 Jun 2011 22:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8wCf5Hg6PuL for ; Wed, 15 Jun 2011 22:26:21 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 09A5111E80B4 for ; Wed, 15 Jun 2011 22:26:20 -0700 (PDT) Received: (qmail 18759 invoked by uid 0); 16 Jun 2011 05:26:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 16 Jun 2011 05:26:20 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=hlUlFB1l/4OrhMY/7rLuOfgjyOyezcrKsEov4/hO9SCB2jFoIoFnwikRwL+9hLHw6M1Ws/aME0EQjGYcvogtqvfaGK6zqqAiJloKx7Jxszy2uYbqmNKe6ohserP6ZMq2; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QX55v-0007ag-Ft; Wed, 15 Jun 2011 23:26:19 -0600 Message-ID: <4DF993FA.6050806@KingsMountain.com> Date: Wed, 15 Jun 2011 22:26:18 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" 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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF DANE WG list Subject: Re: [dane] DNSSEC Optionality (was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 05:26:22 -0000 >> 1) Use of DANE without DNSSEC > > I added the paragraph you note to more correctly describe the impact of > using DANE without DNSSEC, as you, Jim, and Jeff all noted: > Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html > Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html > Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html > > Can we agree that the current draft accurately describes the (admittedly > minor) effect of using DANE without DNSSEC? I think it (the two new paras in S 3.1 CA Constraints) gets somewhat closer to accurate, though it's tough to read and puzzle out what it actually means. (yes, it's also tough to write about this gnarly stuff). (no time right now to word smith it though) there's this key paragraph in S 3.1 sandwiched between the two new paragraphs... > Because these constraints do not increase the scope of PKIX-based > assertions about domains, there is not a strict requirement for > DNSSEC. Deletion of records removes the protection provided by this > constraint, but the client is still protected by CA practices (as > now). Injected or modified false records are not useful unless the > attacker can also obtain a certificate for the target domain. In the > worst case, tampering with these constraints increases the risk of > false authentication to the level that is now standard. I think part of our concerns is the first sentence.. > Because these constraints do not increase the scope of PKIX-based > assertions about domains, there is not a strict requirement for > DNSSEC. ..which is essentially stating a requirement. As I pointed out in my prior msg you cite above... I ... note that the security analysis of the S3.1 CA Constraints use case could be updated to not state a requirement (DNSSEC optionality), and to more thoroughly analyze the case (as they [PaulW & JimS] both have done). I suggest finding a way to simply discuss, there in S3.1's analysis (or perhaps in a proper Security Considerations section), the pros and cons of whether DNSSEC is operationally employed or not. And not make a requirement statement on DNSSEC optionality. Also, the last sentence in the above quoted para.. > In the > worst case, tampering with these constraints increases the risk of > false authentication to the level that is now standard. ..appears problematic in that not everyone believes that the level of "risk of false authentication" today is acceptable, which is sort of implied (it seems to me). Would be good to find a way to re-word this too. Note as well that _until_ we can securely convey valid DNSSEC-signed DNS results directly to the application service component running on the end system (the so-called "DNSSEC last-mile problem"), use of DANE mechanisms even with DNSSEC will provide additional security ranging from "more" to "minimal/none" depending on all sorts of situational factors. This should be noted in security requirements. =JeffH From wouter@nlnetlabs.nl Thu Jun 16 02:06:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86E511E81DF for ; Thu, 16 Jun 2011 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vztKvs27Ee0H for ; Thu, 16 Jun 2011 02:06:45 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8218D11E8092 for ; Thu, 16 Jun 2011 02:06:43 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p5G96ZHu067398 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 16 Jun 2011 11:06:39 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4DF9C79B.3080401@nlnetlabs.nl> Date: Thu, 16 Jun 2011 11:06:35 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <8C326640-23F5-4032-9297-92CAA0F1225F@bbn.com> In-Reply-To: <8C326640-23F5-4032-9297-92CAA0F1225F@bbn.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Thu, 16 Jun 2011 11:06:39 +0200 (CEST) Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:06:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Richard, The usecase draft must describe cases where DNSSEC-validated data is used to secure a connection. Something that gives real security, thus the user of the data securely knows that the data is DNSSEC validated, with as example it validated itself (home user) or with VPN (some companies perhaps). (And I doubt the VPN because the VPN may well start with DNSSEC to get its key information). Using unsecured data, or the same data in absence of DNSSEC validation is not useful. These sections must be taken out of the document, apart from saying that the use of unsecured data or non-validated data is not allowed to be used to claim some gain in trustworthiness (because none has been gained). Making small hurdles that you describe now with unsecured data, although theoretically fun, are not useful for dane. Best regards, Wouter On 06/15/2011 11:17 PM, Richard L. Barnes wrote: > Agreed, not a great example. But you would need an additional set of > tools, so at least it's an annoyance for the attacker :) > > --Richard > > > On Jun 15, 2011, at 3:48 PM, Paul Wouters wrote: > >> On Wed, 15 Jun 2011, Richard L. Barnes wrote: >> >>> You don't need to do it with BGP, someone on the same shared >>> medium can easily hijack your TCP connection without having to >>> touch the DNS. >> >> But then the DANE record without DNSSEC can also be forged, >> because the attacker can see/modify the DNS packets. So its is not >> a good example of DANE without DNSSEC. >> >> Paul > > _______________________________________________ dane mailing list > dane@ietf.org https://www.ietf.org/mailman/listinfo/dane -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN+ceVAAoJEJ9vHC1+BF+NgKMQAKN8XSuqman75mc8ADXF9+fZ 1eFVrKkwKeFfG08CvAleodimexibPjXmhnycCIVtPTaDmDh6ppazYCuUyKtuyyC2 ozKUPQe8++eeutyWGPDrayByCHXfzxT8gDNv5pjcb7kGHVKa9Z4MgkOO0oiwNA8F M7e7PbKh5cCzqF6rC6/gYxjik6wnbvFzyEwmSAJEN2d+r36bW07BOIl+rDItaAID Laq90rrUxFFqr0kjhNJivmAhcSQV2yALewshnhl+mytjWYRNGjSXu6NZOVfAcz5Q z5G5/qPDm3ZetTz+atPkuNe7Essfpp2ivqiXj3bwOdRUBDPO54Q4TnuTdy2yHWoN 5ljdA+lhpIgn2kRJj2eFFjqomUixhDBA9FEU30IPkY0dLbt4ijtzFjMgja0exWdb Q3N0OT+yUpKfhycqs/PpeyC7WCoSWNHqssNUzHeQgmxpIfeL5o8+B6S1MctkuMV6 8b+eNnDS1yCeRe7RwhHBzRYgFtS9cMCvgoFhoP6Jk5g9dh2qekPMPHyrpsuhd0BD 9qeU4NWvBiOEbNjE21EVFnclsvMFfb1G3SBpYH+w5cgxdx/kNgzVMuS22CQ2b0mm x2HQIivLLBsU+4Rtg1G8QzL27f178/XxhPCmatfulr/y3nHHpJG1dSX5nR38QkbU QnUI3k1TFvoOd8OIS8H+ =5IHZ -----END PGP SIGNATURE----- From hallam@gmail.com Thu Jun 16 05:49:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794C911E80B7 for ; Thu, 16 Jun 2011 05:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip9EwDcc3DxS for ; Thu, 16 Jun 2011 05:49:44 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 541A611E8097 for ; Thu, 16 Jun 2011 05:49:44 -0700 (PDT) Received: by yie30 with SMTP id 30so1079988yie.31 for ; Thu, 16 Jun 2011 05:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QtTMUbc64b79GUpEshjAVXorzLUvPreIylZjIFFAKjE=; b=jhYMVm5YYFHFSRZruHMsJVAd0Ifj6kBF1rsqbesOGq2mpf5p64UWOHOqrBwcN0A1nJ F2xuVlYUPeU6aMIPphem9tOjwdaNJmCjO2locsVbCj3RAP7cLWaEf9Gp+smgsDChqJ3W ZvuOfwyPLlfnGc9wuBpgOyew2oMho50nyUAPc= 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=m2Qqk9gK5+UoZZuhHjzmkgqAs4p+hlOqZ0hxYZcbA+nyrEZE39UyQWqILjn0htBRO9 wnffbTWVPeMJ7qOKvJYTwbjqEMPhlj/zCxiSD+FWYiL4cUgis1yIWzY1oHWvAzUmF9e6 gxQrD9sL0ylMyeVWfl/GarYNRH+ksYuGBkO+Y= MIME-Version: 1.0 Received: by 10.101.200.1 with SMTP id c1mr1016768anq.63.1308228582997; Thu, 16 Jun 2011 05:49:42 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Thu, 16 Jun 2011 05:49:42 -0700 (PDT) In-Reply-To: <4DF993FA.6050806@KingsMountain.com> References: <4DF993FA.6050806@KingsMountain.com> Date: Thu, 16 Jun 2011 08:49:42 -0400 Message-ID: From: Phillip Hallam-Baker To: "=JeffH" Content-Type: multipart/alternative; boundary=0016e68deca8f9817804a5d3b37c Cc: IETF DANE WG list Subject: Re: [dane] DNSSEC Optionality (was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 12:49:45 -0000 --0016e68deca8f9817804a5d3b37c Content-Type: text/plain; charset=ISO-8859-1 I agree, no need to make DNSSEC a MUST. I think that would be exceptionally bad for deployment. Just set out the consequences of not having DNSSEC in the Security Considerations and in the introductory material. On Thu, Jun 16, 2011 at 1:26 AM, =JeffH wrote: > >> 1) Use of DANE without DNSSEC > > > > I added the paragraph you note to more correctly describe the impact of > > using DANE without DNSSEC, as you, Jim, and Jeff all noted: > > Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html > > Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html > > Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html > > > > Can we agree that the current draft accurately describes the (admittedly > > minor) effect of using DANE without DNSSEC? > > I think it (the two new paras in S 3.1 CA Constraints) gets somewhat closer > to accurate, though it's tough to read and puzzle out what it actually > means. (yes, it's also tough to write about this gnarly stuff). (no time > right now to word smith it though) > > there's this key paragraph in S 3.1 sandwiched between the two new > paragraphs... > > > Because these constraints do not increase the scope of PKIX-based > > assertions about domains, there is not a strict requirement for > > DNSSEC. Deletion of records removes the protection provided by this > > constraint, but the client is still protected by CA practices (as > > now). Injected or modified false records are not useful unless the > > attacker can also obtain a certificate for the target domain. In the > > worst case, tampering with these constraints increases the risk of > > false authentication to the level that is now standard. > > I think part of our concerns is the first sentence.. > > > Because these constraints do not increase the scope of PKIX-based > > assertions about domains, there is not a strict requirement for > > DNSSEC. > > ..which is essentially stating a requirement. As I pointed out in my prior > msg you cite above... > > I ... note that the security analysis of the S3.1 CA Constraints > use case could be updated to not state a requirement (DNSSEC > optionality), and to more thoroughly analyze the case (as they > [PaulW & JimS] both have done). > > I suggest finding a way to simply discuss, there in S3.1's analysis (or > perhaps in a proper Security Considerations section), the pros and cons of > whether DNSSEC is operationally employed or not. And not make a requirement > statement on DNSSEC optionality. > > Also, the last sentence in the above quoted para.. > > > In the > > worst case, tampering with these constraints increases the risk of > > false authentication to the level that is now standard. > > ..appears problematic in that not everyone believes that the level of "risk > of false authentication" today is acceptable, which is sort of implied (it > seems to me). Would be good to find a way to re-word this too. > > Note as well that _until_ we can securely convey valid DNSSEC-signed DNS > results directly to the application service component running on the end > system (the so-called "DNSSEC last-mile problem"), use of DANE mechanisms > even with DNSSEC will provide additional security ranging from "more" to > "minimal/none" depending on all sorts of situational factors. This should be > noted in security requirements. > > =JeffH > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68deca8f9817804a5d3b37c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree, no need to make DNSSEC a MUST. I think that would be exceptionally= bad for deployment.

Just set out the consequences of not havin= g DNSSEC in the Security Considerations and in the introductory material.= =A0



On Thu, J= un 16, 2011 at 1:26 AM, =3DJeffH <Jeff.Hodges@kingsmountain.com> w= rote:
>> 1) Use of DANE without DNSSEC
>
> I added the paragraph you note to more correctly describe the impact o= f
> using DANE without DNSSEC, as you, Jim, and Jeff all noted:
> Wouters: http://www.ietf.org/mail-archive/web/dane/= current/msg02559.html
> Schaad: http://www.ietf.org/mail-archive/web/dane/c= urrent/msg02564.html
> Hodges: http://www.ietf.org/mail-archive/web/dane/c= urrent/msg02579.html
>
> Can we agree that the current draft accurately describes the (admitted= ly
> minor) effect of using DANE without DNSSEC?

I think it (the two new paras in S 3.1 CA Constraints) gets somewhat closer= to accurate, though it's tough to read and puzzle out what it actually= means. (yes, it's also tough to write about this gnarly stuff). (no ti= me right now to word smith it though)

there's this key paragraph in S 3.1 sandwiched between the two new para= graphs...

> =A0 =A0Because these constraints do not increase the scope of PKIX-bas= ed
> =A0 =A0assertions about domains, there is not a strict requirement for=
> =A0 =A0DNSSEC. =A0Deletion of records removes the protection provided = by this
> =A0 =A0constraint, but the client is still protected by CA practices (= as
> =A0 =A0now). =A0Injected or modified false records are not useful unle= ss the
> =A0 =A0attacker can also obtain a certificate for the target domain. = =A0In the
> =A0 =A0worst case, tampering with these constraints increases the risk= of
> =A0 =A0false authentication to the level that is now standard.

I think part of our concerns is the first sentence..

> =A0 =A0Because these constraints do not increase the scope of PKIX-bas= ed
> =A0 =A0assertions about domains, there is not a strict requirement for=
> =A0 =A0DNSSEC.

..which is essentially stating a requirement. As I pointed out in my prior = msg you cite above...

=A0I ... note that the security analysis of the S3.1 CA Constraints
=A0use case could be updated to not state a requirement (DNSSEC
=A0optionality), and to more thoroughly analyze the case (as they
=A0[PaulW & JimS] both have done).

I suggest finding a way to simply discuss, there in S3.1's analysis (or= perhaps in a proper Security Considerations section), the pros and cons of= whether DNSSEC is operationally employed or not. And not make a requiremen= t statement on DNSSEC optionality.

Also, the last sentence in the above quoted para..

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In the
> =A0 =A0worst case, tampering with these constraints increases the risk= of
> =A0 =A0false authentication to the level that is now standard.

..appears problematic in that not everyone believes that the level of "= ;risk of false authentication" today is acceptable, which is sort of i= mplied (it seems to me). Would be good to find a way to re-word this too.
Note as well that _until_ we can securely convey valid DNSSEC-signed DNS re= sults directly to the application service component running on the end syst= em (the so-called "DNSSEC last-mile problem"), use of DANE mechan= isms even with DNSSEC will provide additional security ranging from "m= ore" to "minimal/none" depending on all sorts of situational= factors. This should be noted in security requirements.

=3DJeffH


_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016e68deca8f9817804a5d3b37c-- From paul@xelerance.com Thu Jun 16 07:50:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDE921F84AE for ; Thu, 16 Jun 2011 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBOQy8Ac-fya for ; Thu, 16 Jun 2011 07:50:56 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB5721F84AD for ; Thu, 16 Jun 2011 07:50:56 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B04EDBF9E; Thu, 16 Jun 2011 10:50:53 -0400 (EDT) Date: Thu, 16 Jun 2011 10:50:53 -0400 (EDT) From: Paul Wouters To: =JeffH In-Reply-To: <4DF993FA.6050806@KingsMountain.com> Message-ID: References: <4DF993FA.6050806@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: IETF DANE WG list Subject: Re: [dane] DNSSEC Optionality (was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:50:57 -0000 On Wed, 15 Jun 2011, =JeffH wrote: > Note as well that _until_ we can securely convey valid DNSSEC-signed DNS > results directly to the application service component running on the end > system (the so-called "DNSSEC last-mile problem"), use of DANE mechanisms > even with DNSSEC will provide additional security ranging from "more" to > "minimal/none" depending on all sorts of situational factors. This should be > noted in security requirements. Note that it seems that currently, browsers will be the first app to take DNSSEC processing with them to the user, due to the lack of guarantee for DNSSEC in the OS. I think for the browser case, the majority of TLS, no one will ever use non-DNSSEC secured DANE records, whether we allow these to go into the user-case document or not. It's just not worth the potential risks. I really hope the use-cases can make a simple a clear statement to application developers to not use DANE without DNSSEC protection. Writing up convoluted marginalised use cases where it could theoretically be useful would cause more damage by badly written implementations that got it wrong. Keep it simple. If you are using cryptographic material to base decisions on, you must be able to make a minimum assertion of trust on it. Paul From rob.stradling@comodo.com Thu Jun 16 08:58:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157611E818B for ; Thu, 16 Jun 2011 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4GJot7BuB6a for ; Thu, 16 Jun 2011 08:58:28 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4827911E814C for ; Thu, 16 Jun 2011 08:58:27 -0700 (PDT) Received: (qmail 10900 invoked from network); 10 Jun 2011 09:30:10 -0000 Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Jun 2011 09:30:10 -0000 Received: (qmail 14852 invoked by uid 1000); 10 Jun 2011 09:30:10 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Fri, 10 Jun 2011 10:30:10 +0100 From: Rob Stradling To: dane@ietf.org Date: Fri, 10 Jun 2011 10:30:08 +0100 User-Agent: KMail/1.13.7 (Linux/2.6.37-gentoo-r4; KDE/4.6.2; i686; ; ) References: <1307061063.2193.165.camel@localhost> In-Reply-To: <1307061063.2193.165.camel@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201106101030.08445.rob.stradling@comodo.com> Subject: Re: [dane] Discovery Abstraction (The place of SRV) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:58:29 -0000 On Friday 03 Jun 2011 01:31:03 Matt McCutchen wrote: > In the message I previously linked, I asserted that (DNS name, transport > protocol, port) should be the input to DANE because: > > (1) The client is bound to know these variables (at least if it does > SNI). > > (2) Under the current design of IP, TCP, and SNI and in the absence of > active attacks, the set of certificates that a client might see when > contacting a TLS server is a function of these variables and no others. Matt, I disagree with "and no others". The set of cipher suites offered by the TLS Client may also influence the set of certificates that the TLS Server chooses to send. For example... $ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2> /dev/null | grep "Certificate chain" -A 3 Certificate chain 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Server Certificate/C=CA i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Certificate Authority/C=CA --- $ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2> /dev/null | grep "Certificate chain" -A 5 Certificate chain 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/ST=Ontario/CN=tls.secg.org ECC secp256r1 Server Certificate/C=CA i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate Authority/C=CA 1 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate Authority/C=CA i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate Authority/C=CA --- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From Jeff.Hodges@KingsMountain.com Fri Jun 17 14:36:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA27711E80DF for ; Fri, 17 Jun 2011 14:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkD62bEn71Z0 for ; Fri, 17 Jun 2011 14:36:56 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 0ACCC11E807F for ; Fri, 17 Jun 2011 14:36:55 -0700 (PDT) Received: (qmail 26950 invoked by uid 0); 17 Jun 2011 21:36:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 17 Jun 2011 21:36:55 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=xdE7SDRp7O1UnXdSUQ1UutpJUl26X4od7889p8iA0MUCQ7lPe4xG90sDo0d9G3rPNPWVbFjxzUu41tVEqIlBjk/tgwDJaxCCMQeHI/Z9bKSjZrQfksOg3kIesxLHD1NH; Received: from [204.250.168.24] (helo=[192.168.1.207]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QXgik-0001at-R1; Fri, 17 Jun 2011 15:36:55 -0600 Message-ID: <4DFBC8F5.4060802@KingsMountain.com> Date: Fri, 17 Jun 2011 14:36:53 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Wouters 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 204.250.168.24 authed with jeff.hodges+kingsmountain.com} Cc: IETF DANE WG list Subject: Re: [dane] DNSSEC Optionality (was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:36:56 -0000 > I think for the browser case, the majority of TLS, no one will ever use > non-DNSSEC secured DANE records, whether we allow these to go into the > user-case document or not. It's just not worth the potential risks. > > I really hope the use-cases can make a simple a clear statement to > application developers to not use DANE without DNSSEC protection. Writing > up convoluted marginalised use cases where it could theoretically be > useful would cause more damage by badly written implementations that > got it wrong. Although I sympathize with this position, this use-case exercise, as I understand it, is to inform the protocol design work, and isn't intended to be a deployment guide. IMV, a use-cases-for-protocol-design doc generally isn't the place to be using the RFC2119 MUST, SHOULD, MAY language. We can place such imperatives in the protocol doc proper. We can also do a deployment guidelines doc if we gin up enough gumption and all. Perhaps we ought to put "This is NOT A deployment guide" right up in the front of the introductoin of -dane-use-cases. =JeffH From Jeff.Hodges@KingsMountain.com Fri Jun 17 15:03:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85B11E80DF for ; Fri, 17 Jun 2011 15:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWEXqBWgyoyY for ; Fri, 17 Jun 2011 15:03:43 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfa.amsl.com (Postfix) with SMTP id 96B6711E807F for ; Fri, 17 Jun 2011 15:03:43 -0700 (PDT) Received: (qmail 16814 invoked by uid 0); 17 Jun 2011 22:03:42 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 17 Jun 2011 22:03:42 -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=ebjasZG0BfygeUHfo5yesgmyzPAhsZsUbSw0Q0RD56KO0bewZ/6SlmYtmRuApwhbUj/U5BsPB6cgVj8QjuutNIlefDrYZTDT0UJLcY6/DB5jjHr3B6XGVHySM0jnUO66; Received: from [204.250.168.24] (helo=[192.168.1.207]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QXh8g-0002Z7-7t for dane@ietf.org; Fri, 17 Jun 2011 16:03:42 -0600 Message-ID: <4DFBCF3D.4080509@KingsMountain.com> Date: Fri, 17 Jun 2011 15:03:41 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list 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 204.250.168.24 authed with jeff.hodges+kingsmountain.com} Subject: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 22:03:44 -0000 of posible interest: Adam Langley's blog post from yesterday... DNSSEC authenticated HTTPS in Chrome (16 Jun 2011) http://www.imperialviolet.org/2011/06/16/dnssecchrome.html =JeffH From ogud@ogud.com Mon Jun 20 07:54:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2711E80E9 for ; Mon, 20 Jun 2011 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msmu4RnhPiMM for ; Mon, 20 Jun 2011 07:54:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB3B11E80BE for ; Mon, 20 Jun 2011 07:54:29 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5KEsRBn026480 for ; Mon, 20 Jun 2011 10:54:27 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4DFF5F21.4070300@ogud.com> Date: Mon, 20 Jun 2011 10:54:25 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <4DF993FA.6050806@KingsMountain.com> In-Reply-To: <4DF993FA.6050806@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dane] DNSSEC Optionality (was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 14:54:30 -0000 On 16/06/2011 1:26 AM, =JeffH wrote: > >> 1) Use of DANE without DNSSEC > > > > I added the paragraph you note to more correctly describe the impact of > > using DANE without DNSSEC, as you, Jim, and Jeff all noted: > > Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html > > Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html > > Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html > > > > Can we agree that the current draft accurately describes the (admittedly > > minor) effect of using DANE without DNSSEC? > > I think it (the two new paras in S 3.1 CA Constraints) gets somewhat > closer to accurate, though it's tough to read and puzzle out what it > actually means. (yes, it's also tough to write about this gnarly stuff). > (no time right now to word smith it though) > > there's this key paragraph in S 3.1 sandwiched between the two new > paragraphs... > > > Because these constraints do not increase the scope of PKIX-based > > assertions about domains, there is not a strict requirement for > > DNSSEC. Deletion of records removes the protection provided by this > > constraint, but the client is still protected by CA practices (as > > now). Injected or modified false records are not useful unless the > > attacker can also obtain a certificate for the target domain. In the > > worst case, tampering with these constraints increases the risk of > > false authentication to the level that is now standard. > When reading the above text I can not determine which one of the following two is the guidance: a) the zone publishing the DANE record does not need to be signed b) the DANE record does not need to be DNSSEC validated. Olafur From ondrej.sury@nic.cz Wed Jun 22 00:26:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5661321F8463 for ; Wed, 22 Jun 2011 00:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.000, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JKwFw2Bbgl3 for ; Wed, 22 Jun 2011 00:26:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9123321F8455 for ; Wed, 22 Jun 2011 00:26:40 -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 941AD2A2C80 for ; Wed, 22 Jun 2011 09:26:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308727598; bh=cbGsEEDG5BJ6MCkPR175T4L60nmdYNNbbXbnz85Spqg=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=KMQuFRwtKDOPpC12GawHIdmP41M17D9agwfasJiZg1nfDblCXITvmGOmYN5uGwNnd chriXcLFpfov2d4rU5LXsrEXMfm5Ku6Iz75IEFO9ySx55PucQEVI8Sp8/QzzRPdyfj ceL1keaMWTsQSuf6nQ9U4Ujd23soOYTUadLfIl/s= Message-ID: <4E01992E.9050602@nic.cz> Date: Wed, 22 Jun 2011 09:26:38 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <20110616042028.GC10766@odin.ulthar.us> In-Reply-To: <20110616042028.GC10766@odin.ulthar.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 07:26:41 -0000 On 16.6.2011 06:20, Scott Schmit wrote: > On Wed, Jun 15, 2011 at 03:57:26PM +0200, Ondřej Surý wrote dane: >> On 14.6.2011 07:55, Paul Wouters wrote: >>> I still do not understand any of the use cases for DANE without DNSSEC. >>> Perhaps someone >>> who does see this could explain it to me in clear steps that Alice is >>> taking and where >>> Malice is twarted by a DANE key without DNSSEC protection...... >> >> Youtube AS hijack. No A record was spoofed, but the traffic still went >> to hijackers. > > Sure, but assuming that you're connecting via HTTPS rather than HTTP > (DANE doesn't even kick in if HTTPS isn't being used), even PKIX would > flag a problem with this kind of MITM, unless the hijackers also got the > private keys. Honestly, if that's the threat, DANE won't help either. Please bear in mind that this was an example of situation where DANE helps (a little, but still helps) even without DNSSEC. > I guess you could claim that they could trick a CA into a misissue, but There's no government Pakistani CA? I would expect one in my browser :) > I'm having a hard time seeing how that attack is easier/cheaper than > attacking a DNS server hosting an unsigned zone. Oh, yes, it's much easier to do. You don't have to hack anything. Poorly configured upstream is still common and all you need to do is to send proper BGP update. Otherwise why would folks talk about RPKI again and again for some years now (applies to RIPE meetings) :). 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 ------------------------------------------- From ondrej.sury@nic.cz Wed Jun 22 00:30:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7421F84BC for ; Wed, 22 Jun 2011 00:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbg5omvGpwFa for ; Wed, 22 Jun 2011 00:30:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C450821F849B for ; Wed, 22 Jun 2011 00:30: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 E425B2A2C81 for ; Wed, 22 Jun 2011 09:30:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308727858; bh=aziHm5YnS0Z9xY+BqukknXhr2t4otYE9BM4mYhbmXKY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vx4sCVEYbmR9m3SPWD7rI38H1dMxby4e3NyZF9xxxlAmoizdQOM7+BVTIEMff/b9C FyBsmi1xfruhGhTauoTVWaAWnJK72229tSPYIwfR0cx6rqCpC0ygypVafFN/hqhaiO dn+/P5kf9TYMZSv4nzd9ZOHxjlE4Lxf5NS0lg8hQ= Message-ID: <4E019A31.70207@nic.cz> Date: Wed, 22 Jun 2011 09:30:57 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 07:30:59 -0000 On 15.6.2011 21:53, Nicholas Weaver wrote: > Oh, and BGP attacks can be done without noticable side effects, having been on a test network where such an attack was done. http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf In fact the attack is very smart if done right and cannot be detected from within hijacked IP space (because your router prevents the AS path loops). 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 ------------------------------------------- From hallam@gmail.com Wed Jun 22 05:18:55 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4196611E8130 for ; Wed, 22 Jun 2011 05:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9Htgmij-kxl for ; Wed, 22 Jun 2011 05:18:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3235311E80BC for ; Wed, 22 Jun 2011 05:18:54 -0700 (PDT) Received: by yxt33 with SMTP id 33so496940yxt.31 for ; Wed, 22 Jun 2011 05:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tIfQ0ibT6XNvD4JVxw0GTWo46rdJHlzg9X5fA5Qv73M=; b=ELXuS1VpeBmzBQvuWTqPO3oSgj0bNwoeLKKhW+Bq6OWbY07jLXHDpKVbNUoeEq5wgW 1pGkXDEV+0T72x4IN84DkvetnyPNmbd30QZX2/SqmCHzc8YCCSVpcpm6FGlCVdiZA0TH UPC9YWc1jyBvBagWA4ZwK1Dp/FYoJzCNFz4U0= 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=r/eFAs3+FUaqdCBxZdEEOvHBO52i+yG4D0z0nOAOwFCKnsg5QAMT9jt5ktGt7xht3/ xeIOxeFOOixkpYssw2h6zBumM94njrwU5KT9Y0o7uSeEpx9fUpyGuTcfGPNtKie2D+1u MIWXl+N58zhJW0dD8lLj2tVZumUpp6IKYCi8k= MIME-Version: 1.0 Received: by 10.100.241.1 with SMTP id o1mr702666anh.128.1308745133227; Wed, 22 Jun 2011 05:18:53 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Wed, 22 Jun 2011 05:18:53 -0700 (PDT) In-Reply-To: <4E019A31.70207@nic.cz> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <4E019A31.70207@nic.cz> Date: Wed, 22 Jun 2011 08:18:53 -0400 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016368e208cc47ee104a64bf87b Cc: dane@ietf.org Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 12:18:55 -0000 --0016368e208cc47ee104a64bf87b Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Again, the issue is not whether attackers could make attacks without major collateral damage, it is whether they would choose to do so. So far the evidence is that collateral damage is not a concern. On Wed, Jun 22, 2011 at 3:30 AM, Ond=F8ej Sur=FD wrote= : > On 15.6.2011 21:53, Nicholas Weaver wrote: > > > Oh, and BGP attacks can be done without noticable side effects, having > been on a test network where such an attack was done. > > > http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilos= ov-kapela.pdf > > In fact the attack is very smart if done right and cannot be detected > from within hijacked IP space (because your router prevents the AS path > loops). > > 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 > ------------------------------------------- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --=20 Website: http://hallambaker.com/ --0016368e208cc47ee104a64bf87b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Again, the issue is not whether attackers could make attacks without major = collateral damage, it is whether they would choose to do so.

=
So far the evidence is that collateral damage is not a concern.


On Wed, Jun 22, 2011 at 3:30 AM, On= d=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
On 15.6.2011 21:53, Nicholas Weaver wrote:

> Oh, and BGP attacks can be done without noticable side effects, having= been on a test network where such an attack was done.

http://www.defcon.org/images/defc= on-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

In fact the attack is very smart if done right and cannot be detected
from within hijacked IP space (because your router prevents the AS path
loops).

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=A0http://nic.cz/
=C2=A0tel:+420.222= 745110 =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112
=C2=A0-------------------------------------------
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016368e208cc47ee104a64bf87b-- From jakob@kirei.se Wed Jun 22 07:59:14 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41A611E809F for ; Wed, 22 Jun 2011 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMYNFkuNTmow for ; Wed, 22 Jun 2011 07:59:14 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6DF11E808E for ; Wed, 22 Jun 2011 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:from:content-type:content-transfer-encoding:subject:date:message-id: to:mime-version:x-mailer; bh=MggMmesXvusvQThgSN9qLYTN7cl+/9dKpGRt6hkuNJA=; b=Wn9XqDTaM/L3fQnuIAXRdL0NPPWw5H0mh3KfoDDvZJUXgE5v4eGmKfcPUSPtktDNK5mcblOQpnlwx NAIYp/eFQnH8a/80l3Q8AG3NxcJku4J8KJ8K2WxMMKU+ZzshGv9+YFT3fLWA993zajaqBhfTyC8u3w KKY/hpO5RrYSQV6s= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 22 Jun 2011 16:59:07 +0200 (CEST) From: Jakob Schlyter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2011 16:59:00 +0200 Message-Id: <28E8CFC4-0B12-4253-91B7-151DEDE8812E@kirei.se> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] FYI: Next version of draft-ietf-dane-protocol pending updated use cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:59:14 -0000 Hi, Paul and I are preparing an update to draft-ietf-dane-protocol, but are = waiting for Richard to put out the next version of the use cases first. = The update includes, among the usual nits, better use case mappings and = clarifications. jakob From bhill@paypal-inc.com Wed Jun 22 11:12:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD6811E8072 for ; Wed, 22 Jun 2011 11:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.516 X-Spam-Level: X-Spam-Status: No, score=-8.516 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNn--1KQWcXj for ; Wed, 22 Jun 2011 11:11:59 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 28635228018 for ; Wed, 22 Jun 2011 11:11:59 -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: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:MIME-Version: X-CFilter; b=AbavbunL03JDFyzL7NtVhrE5OkL5dXVAZSi3r+yTetwwQbxdqwSb8nbD nzB3tQgSx3r31rmKMFGXjdTX89aEu0MFlVTklW+05J1sd6P3NShkRVVFQ 3CJEAqPtdyzhTOE; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1308766319; x=1340302319; h=from:to:date:subject:message-id:references:in-reply-to: mime-version; bh=FmFSJ9VqARn5IhpuTAtBxmzNvPQYFN3dCPlBTlNFe/U=; b=N4HMcSDG0PsdzTkQZyrS0ucgmaaqgEqaL4BcTC00UCKxS/Fyv4/g0H7E PEQNqmlySlt3pexa/IJhHqktYSCfTrBMoV0FlSKxDejG2whjLI6/FuTIs mLLUORT1xtmnaQy; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.65,407,1304319600"; d="scan'208,217";a="2474885" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Jun 2011 11:11:58 -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, 22 Jun 2011 12:11:58 -0600 From: "Hill, Brad" To: "dane@ietf.org" Date: Wed, 22 Jun 2011 12:11:58 -0600 Thread-Topic: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) Thread-Index: Acww1pepIFnXr+SjTYWjGR0f/06WwgAL+odg Message-ID: <213E0EC97FE58F469BB618245B3118BB54F6C99A90@DEN-MEXMS-001.corp.ebay.com> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <4E019A31.70207@nic.cz> 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: l+MPnUO2sr440lDQLhpiXw== Content-Type: multipart/alternative; boundary="_000_213E0EC97FE58F469BB618245B3118BB54F6C99A90DENMEXMS001co_" MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:12:01 -0000 --_000_213E0EC97FE58F469BB618245B3118BB54F6C99A90DENMEXMS001co_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHRvIGVuY291cmFnZSB0aGUgdXNlIG9mIERBTkUgd2l0aG91dCBETlNTRUMsIGJ1dCB0aGVy ZSBhcmUgbW9yZSBjb21tb24gYW5kIG9idmlvdXMgc2NlbmFyaW9zIHRoYXQg4oCcbG9vayBsaWtl 4oCdIHRoaXMgYXR0YWNrLg0KDQpTcGxpdC10dW5uZWwgVlBOcyAoc2VsZWN0ZWQgdHJhZmZpYyBv dmVyIFZQTiwgcmVtYWluZGVyIG92ZXIgdW50cnVzdGVkIGludGVyZmFjZSkgYXJlIGluY3JlYXNp bmdseSBjb21tb24sIGFuZCBhcmUgaW5jcmVhc2luZ2x5IOKAnGFsd2F5cyBvbuKAnS4gICDigJxE aXJlY3RDb25uZWN04oCdIGluIFdpbjcgaXMgc3VjaCBhIHN5c3RlbS4NCg0KSW4gc3VjaCBjb25m aWd1cmF0aW9ucywgaXTigJlzIGVudGlyZWx5IGxpa2VseSAoY29mZmVlLXNob3AgYXR0YWNrKSB0 aGF0IGFuIGF0dGFja2VyIHdpbGwgYmUgYSBEb2xldi1ZYW8gY2xhc3MgTWl0TSBiZXR3ZWVuIEFs aWNlIGFuZCBCb2IsIGFuZCBBbGljZSBhbmQgcHVibGljLCB3ZWxsLWtub3duIENBcywgYnV0IG5v dCBiZXR3ZWVuIEFsaWNlIGFuZCBoZXIgRE5TLCB3aGljaCBpcyBvbiB0aGUgc2FtZSBtZWRpdW0g YnV0IElQU2VjIG9yIG90aGVyd2lzZSBwcm90ZWN0ZWQsIG9yIGJldHdlZW4gQWxpY2XigJlzIERO UyBhbmQgQm9i4oCZcyBETlMgd2hpY2ggaXMgb24gYSBkaWZmZXJlbnQgbWVkaXVtLg0KDQotQnJh ZA0KDQpGcm9tOiBkYW5lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkYW5lLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsbGlwIEhhbGxhbS1CYWtlcg0KU2VudDogV2VkbmVzZGF5 LCBKdW5lIDIyLCAyMDExIDU6MTkgQU0NClRvOiBPbmTFmWVqIFN1csO9DQpDYzogZGFuZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtkYW5lXSBbb2ZmLXRvcGljXSAiVW5ub3RpY2VhYmxlIiBCR1Ag TWl0TSBhdHRhY2sgKFdhczogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LWRhbmUtdXNlLWNhc2VzLTAzLnR4dCkNCg0KQWdhaW4sIHRoZSBpc3N1ZSBpcyBub3Qgd2hldGhl ciBhdHRhY2tlcnMgY291bGQgbWFrZSBhdHRhY2tzIHdpdGhvdXQgbWFqb3IgY29sbGF0ZXJhbCBk YW1hZ2UsIGl0IGlzIHdoZXRoZXIgdGhleSB3b3VsZCBjaG9vc2UgdG8gZG8gc28uDQoNClNvIGZh ciB0aGUgZXZpZGVuY2UgaXMgdGhhdCBjb2xsYXRlcmFsIGRhbWFnZSBpcyBub3QgYSBjb25jZXJu Lg0KDQpPbiBXZWQsIEp1biAyMiwgMjAxMSBhdCAzOjMwIEFNLCBPbmTFmWVqIFN1csO9IDxvbmRy ZWouc3VyeUBuaWMuY3o8bWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5jej4+IHdyb3RlOg0KT24gMTUu Ni4yMDExIDIxOjUzLCBOaWNob2xhcyBXZWF2ZXIgd3JvdGU6DQoNCj4gT2gsIGFuZCBCR1AgYXR0 YWNrcyBjYW4gYmUgZG9uZSB3aXRob3V0IG5vdGljYWJsZSBzaWRlIGVmZmVjdHMsIGhhdmluZyBi ZWVuIG9uIGEgdGVzdCBuZXR3b3JrIHdoZXJlIHN1Y2ggYW4gYXR0YWNrIHdhcyBkb25lLg0KDQpo dHRwOi8vd3d3LmRlZmNvbi5vcmcvaW1hZ2VzL2RlZmNvbi0xNi9kYzE2LXByZXNlbnRhdGlvbnMv ZGVmY29uLTE2LXBpbG9zb3Yta2FwZWxhLnBkZg0KDQpJbiBmYWN0IHRoZSBhdHRhY2sgaXMgdmVy eSBzbWFydCBpZiBkb25lIHJpZ2h0IGFuZCBjYW5ub3QgYmUgZGV0ZWN0ZWQNCmZyb20gd2l0aGlu IGhpamFja2VkIElQIHNwYWNlIChiZWNhdXNlIHlvdXIgcm91dGVyIHByZXZlbnRzIHRoZSBBUyBw YXRoDQpsb29wcykuDQoNCk8uDQotLQ0KIE9uZMWZZWogU3Vyw70NCiB2ZWRvdWPDrSB2w716a3Vt dS9IZWFkIG9mIFImRCBkZXBhcnRtZW50DQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KIENaLk5JQywgei5zLnAuby4gICAgLS0gICAgTGFib3JhdG/FmWUgQ1ou TklDDQogQW1lcmlja2EgMjMsIDEyMCAwMCBQcmFoYSAyLCBDemVjaCBSZXB1YmxpYw0KIG1haWx0 bzpvbmRyZWouc3VyeUBuaWMuY3o8bWFpbHRvOm9uZHJlai5zdXJ5QG5pYy5jej4gICAgaHR0cDov L25pYy5jei8NCiB0ZWw6KzQyMC4yMjI3NDUxMTA8dGVsOiUyQjQyMC4yMjI3NDUxMTA+ICAgICAg IGZheDorNDIwLjIyMjc0NTExMjx0ZWw6JTJCNDIwLjIyMjc0NTExMj4NCiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KZGFuZSBtYWlsaW5nIGxpc3QNCmRhbmVAaWV0Zi5vcmc8 bWFpbHRvOmRhbmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RhbmUNCg0KDQoNCi0tDQpXZWJzaXRlOiBodHRwOi8vaGFsbGFtYmFrZXIuY29tLw0K --_000_213E0EC97FE58F469BB618245B3118BB54F6C99A90DENMEXMS001co_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk5vdCB0byBl bmNvdXJhZ2UgdGhlIHVzZSBvZiBEQU5FIHdpdGhvdXQgRE5TU0VDLCBidXQgdGhlcmUgYXJlIG1v cmUgY29tbW9uIGFuZCBvYnZpb3VzIHNjZW5hcmlvcyB0aGF0IOKAnGxvb2sgbGlrZeKAnSB0aGlz IGF0dGFjay7CoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNwbGl0LXR1bm5lbCBWUE5zIChzZWxlY3Rl ZCB0cmFmZmljIG92ZXIgVlBOLCByZW1haW5kZXIgb3ZlciB1bnRydXN0ZWQgaW50ZXJmYWNlKSBh cmUgaW5jcmVhc2luZ2x5IGNvbW1vbiwgYW5kIGFyZSBpbmNyZWFzaW5nbHkg4oCcYWx3YXlzIG9u 4oCdLiDCoMKg4oCcRGlyZWN0Q29ubmVjdOKAnSBpbiBXaW43IGlzIHN1Y2ggYSBzeXN0ZW0uPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5JbiBzdWNoIGNvbmZpZ3VyYXRpb25zLCBpdOKAmXMgZW50aXJlbHkg bGlrZWx5IChjb2ZmZWUtc2hvcCBhdHRhY2spIHRoYXQgYW4gYXR0YWNrZXIgd2lsbCBiZSBhIERv bGV2LVlhbyBjbGFzcyBNaXRNIGJldHdlZW4gQWxpY2UgYW5kIEJvYiwgYW5kIEFsaWNlIGFuZCBw dWJsaWMsIHdlbGwta25vd24gQ0FzLCBidXQgbm90IGJldHdlZW4gQWxpY2UgYW5kIGhlciBETlMs IHdoaWNoIGlzIG9uIHRoZSBzYW1lIG1lZGl1bSBidXQgSVBTZWMgb3Igb3RoZXJ3aXNlIHByb3Rl Y3RlZCwgb3IgYmV0d2VlbiBBbGljZeKAmXMgRE5TIGFuZCBCb2LigJlzIEROUyB3aGljaCBpcyBv biBhIGRpZmZlcmVudCBtZWRpdW0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tQnJhZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IGRhbmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRhbmUt Ym91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsbGlwIEhhbGxhbS1CYWtl cjxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdW5lIDIyLCAyMDExIDU6MTkgQU08YnI+PGI+ VG86PC9iPiBPbmTFmWVqIFN1csO9PGJyPjxiPkNjOjwvYj4gZGFuZUBpZXRmLm9yZzxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtkYW5lXSBbb2ZmLXRvcGljXSAmcXVvdDtVbm5vdGljZWFibGUmcXVv dDsgQkdQIE1pdE0gYXR0YWNrIChXYXM6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtaWV0Zi1kYW5lLXVzZS1jYXNlcy0wMy50eHQpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+QWdh aW4sIHRoZSBpc3N1ZSBpcyBub3Qgd2hldGhlciBhdHRhY2tlcnMgY291bGQgbWFrZSBhdHRhY2tz IHdpdGhvdXQgbWFqb3IgY29sbGF0ZXJhbCBkYW1hZ2UsIGl0IGlzIHdoZXRoZXIgdGhleSB3b3Vs ZCBjaG9vc2UgdG8gZG8gc28uPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U28gZmFy IHRoZSBldmlkZW5jZSBpcyB0aGF0IGNvbGxhdGVyYWwgZGFtYWdlIGlzIG5vdCBhIGNvbmNlcm4u PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD5PbiBXZWQsIEp1biAyMiwgMjAxMSBhdCAzOjMwIEFNLCBPbmTFmWVqIFN1csO9ICZsdDs8 YSBocmVmPSJtYWlsdG86b25kcmVqLnN1cnlAbmljLmN6Ij5vbmRyZWouc3VyeUBuaWMuY3o8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+T24gMTUuNi4yMDEx IDIxOjUzLCBOaWNob2xhcyBXZWF2ZXIgd3JvdGU6PGJyPjxicj4mZ3Q7IE9oLCBhbmQgQkdQIGF0 dGFja3MgY2FuIGJlIGRvbmUgd2l0aG91dCBub3RpY2FibGUgc2lkZSBlZmZlY3RzLCBoYXZpbmcg YmVlbiBvbiBhIHRlc3QgbmV0d29yayB3aGVyZSBzdWNoIGFuIGF0dGFjayB3YXMgZG9uZS48YnI+ PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuZGVmY29uLm9yZy9pbWFnZXMvZGVmY29uLTE2L2RjMTYt cHJlc2VudGF0aW9ucy9kZWZjb24tMTYtcGlsb3Nvdi1rYXBlbGEucGRmIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3d3dy5kZWZjb24ub3JnL2ltYWdlcy9kZWZjb24tMTYvZGMxNi1wcmVzZW50YXRp b25zL2RlZmNvbi0xNi1waWxvc292LWthcGVsYS5wZGY8L2E+PGJyPjxicj5JbiBmYWN0IHRoZSBh dHRhY2sgaXMgdmVyeSBzbWFydCBpZiBkb25lIHJpZ2h0IGFuZCBjYW5ub3QgYmUgZGV0ZWN0ZWQ8 YnI+ZnJvbSB3aXRoaW4gaGlqYWNrZWQgSVAgc3BhY2UgKGJlY2F1c2UgeW91ciByb3V0ZXIgcHJl dmVudHMgdGhlIEFTIHBhdGg8YnI+bG9vcHMpLjxicj48YnI+Ty48YnI+LS08YnI+Jm5ic3A7T25k xZllaiBTdXLDvTxicj4mbmJzcDt2ZWRvdWPDrSB2w716a3VtdS9IZWFkIG9mIFImYW1wO0QgZGVw YXJ0bWVudDxicj4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPiZuYnNwO0NaLk5JQywgei5zLnAuby4gJm5ic3A7ICZuYnNwOy0tICZuYnNwOyAmbmJz cDtMYWJvcmF0b8WZZSBDWi5OSUM8YnI+Jm5ic3A7QW1lcmlja2EgMjMsIDEyMCAwMCBQcmFoYSAy LCBDemVjaCBSZXB1YmxpYzxicj4mbmJzcDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9uZHJlai5z dXJ5QG5pYy5jeiI+b25kcmVqLnN1cnlAbmljLmN6PC9hPiAmbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cDovL25pYy5jei8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmljLmN6LzwvYT48YnI+Jm5i c3A7dGVsOjxhIGhyZWY9InRlbDolMkI0MjAuMjIyNzQ1MTEwIj4rNDIwLjIyMjc0NTExMDwvYT4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZmF4OjxhIGhyZWY9InRlbDolMkI0MjAuMjIyNzQ1MTEyIj4r NDIwLjIyMjc0NTExMjwvYT48YnI+Jm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5kYW5lIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86ZGFuZUBpZXRm Lm9yZyI+ZGFuZUBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kYW5lIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kYW5lPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj48YnIgY2xlYXI9YWxs Pjxicj4tLSA8YnI+V2Vic2l0ZTogPGEgaHJlZj0iaHR0cDovL2hhbGxhbWJha2VyLmNvbS8iPmh0 dHA6Ly9oYWxsYW1iYWtlci5jb20vPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9k eT48L2h0bWw+ --_000_213E0EC97FE58F469BB618245B3118BB54F6C99A90DENMEXMS001co_-- From hallam@gmail.com Wed Jun 22 12:28:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B60D11E809C for ; Wed, 22 Jun 2011 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gCElY3SK2Xf for ; Wed, 22 Jun 2011 12:28:02 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67DD311E8073 for ; Wed, 22 Jun 2011 12:28:02 -0700 (PDT) Received: by vws12 with SMTP id 12so1158507vws.31 for ; Wed, 22 Jun 2011 12:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y7ojWF/3hrZYzTL91a49c23BT8HwNbYf8PQPygPVYrs=; b=v0nq3sc8K8ezy+MirBQX/ahPjpX7QDQpsfJzRruiGy4HgrESB5Ct1FA3RSvdvTBbRY bSBs/gZUkpJLNN/HTmcXBiCphtsOyhQvCch8yq+6mrIGjhdPDzjz70sEgiBxc6DFa/2B Q+ZZKX34I7r4odhBsPeW5HZTfZ1mjs43AUhIY= 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=YqMif+ZPdZLf1NpKLOUNHKRx+zqEaUFCvWCKtmuyqGoQzjRHNDOswBqnMbn+T/Qe+r 7q5bKZXyEUcrErRhIGjjUhCPB2OrvO4i4RloilHupla7xtSHr6Yfx/F8EDlxJ+dauZyQ +Pt2ZsdxNjvqg4SPqlX8ZLHUkh3Xl5sNkbi5A= MIME-Version: 1.0 Received: by 10.52.76.4 with SMTP id g4mr1411536vdw.278.1308770881467; Wed, 22 Jun 2011 12:28:01 -0700 (PDT) Received: by 10.52.111.230 with HTTP; Wed, 22 Jun 2011 12:28:01 -0700 (PDT) In-Reply-To: <213E0EC97FE58F469BB618245B3118BB54F6C99A90@DEN-MEXMS-001.corp.ebay.com> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <4E019A31.70207@nic.cz> <213E0EC97FE58F469BB618245B3118BB54F6C99A90@DEN-MEXMS-001.corp.ebay.com> Date: Wed, 22 Jun 2011 15:28:01 -0400 Message-ID: From: Phillip Hallam-Baker To: "Hill, Brad" Content-Type: multipart/alternative; boundary=20cf3071cdae7b75cc04a651f708 Cc: "dane@ietf.org" Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 19:28:05 -0000 --20cf3071cdae7b75cc04a651f708 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Good point, it is important to distinguish between 'DANE + DNSSEC' and DANE + DNS Security'. DNS Security is likely to be necessary to provide useful security in DANE. DNSSEC is only one way that may be achieved, it is not the only way. On Wed, Jun 22, 2011 at 2:11 PM, Hill, Brad wrote: > Not to encourage the use of DANE without DNSSEC, but there are more commo= n > and obvious scenarios that "look like" this attack. **** > > ** ** > > Split-tunnel VPNs (selected traffic over VPN, remainder over untrusted > interface) are increasingly common, and are increasingly "always on". > "DirectConnect" in Win7 is such a system.**** > > ** ** > > In such configurations, it's entirely likely (coffee-shop attack) that an > attacker will be a Dolev-Yao class MitM between Alice and Bob, and Alice = and > public, well-known CAs, but not between Alice and her DNS, which is on th= e > same medium but IPSec or otherwise protected, or between Alice's DNS and > Bob's DNS which is on a different medium.**** > > ** ** > > -Brad**** > > ** ** > > *From:* dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] *On Behalf O= f > *Phillip Hallam-Baker > *Sent:* Wednesday, June 22, 2011 5:19 AM > *To:* Ond=F8ej Sur=FD > *Cc:* dane@ietf.org > *Subject:* Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: Ne= w > Version Notification for draft-ietf-dane-use-cases-03.txt)**** > > ** ** > > Again, the issue is not whether attackers could make attacks without majo= r > collateral damage, it is whether they would choose to do so.**** > > ** ** > > So far the evidence is that collateral damage is not a concern.**** > > ** ** > > On Wed, Jun 22, 2011 at 3:30 AM, Ond=F8ej Sur=FD wro= te:** > ** > > On 15.6.2011 21:53, Nicholas Weaver wrote: > > > Oh, and BGP attacks can be done without noticable side effects, having > been on a test network where such an attack was done. > > > http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilos= ov-kapela.pdf > > In fact the attack is very smart if done right and cannot be detected > from within hijacked IP space (because your router prevents the AS path > loops). > > 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 > ------------------------------------------- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane**** > > > > > -- > Website: http://hallambaker.com/**** > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > --=20 Website: http://hallambaker.com/ --20cf3071cdae7b75cc04a651f708 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Good point, it is important to distinguish between 'DANE + DNSSEC' = and DANE + DNS Security'.

DNS Security is likely to = be necessary to provide useful security in DANE. DNSSEC is only one way tha= t may be achieved, it is not the only way.


On Wed, Jun 22, 2011 at 2:11 PM, Hi= ll, Brad <bhil= l@paypal-inc.com> wrote:

Not to encourage the use= of DANE without DNSSEC, but there are more common and obvious scenarios th= at “look like” this attack. 

 

Split-tunnel VPNs (selected traffic over VPN, remainde= r over untrusted interface) are increasingly common, and are increasingly &= ldquo;always on”.   “DirectConnect” in Win7 is = such a system.

 

In such configurations, it’s entirely likely (co= ffee-shop attack) that an attacker will be a Dolev-Yao class MitM between A= lice and Bob, and Alice and public, well-known CAs, but not between Alice a= nd her DNS, which is on the same medium but IPSec or otherwise protected, o= r between Alice’s DNS and Bob’s DNS which is on a different med= ium.

 

-Brad

<= span style=3D"font-size:11.0pt;color:#1F497D"> 

From:= dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf= Of Phillip Hallam-Baker
Sent: Wednesday, June 22, 2011 5:19 AM
To: Ond=F8ej Sur=FD=
Cc: dane@ietf= .org
Subject: Re: [dane] [off-topic] "Unnoticeable"= BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cas= es-03.txt)

 

Again, the issue is not whether attackers coul= d make attacks without major collateral damage, it is whether they would ch= oose to do so.

 

So far the evidence is that collateral damage is not a concern.<= u>

 

On Wed, Jun 22, 2011 at 3:30 AM, Ond=F8ej Sur= =FD <ondrej.sury= @nic.cz> wrote:

On 15.6.2011= 21:53, Nicholas Weaver wrote:

> Oh, and BGP attacks can be done without noticable side effects, ha= ving been on a test network where such an attack was done.

http://www.defcon.org/images/defcon-16/d= c16-presentations/defcon-16-pilosov-kapela.pdf

In fact the attack is very smart if done right and cannot be detectedfrom within hijacked IP space (because your router prevents the AS pathloops).

O.
--
 Ond=F8ej Sur=FD
 vedouc=ED v=FDz= kumu/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
 -----------------------------------------= --
_______________________________________________
dane mailing list
dan= e@ietf.org
https://www.ietf.org/mailman/listinfo/dane




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


_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane




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

--20cf3071cdae7b75cc04a651f708-- From demoss.matt@gmail.com Wed Jun 22 13:28:51 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720DA228006 for ; Wed, 22 Jun 2011 13:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igUsnMFZpnT8 for ; Wed, 22 Jun 2011 13:28:50 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE5228005 for ; Wed, 22 Jun 2011 13:28:49 -0700 (PDT) Received: by fxm15 with SMTP id 15so988938fxm.31 for ; Wed, 22 Jun 2011 13:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rFYEWX62hamFH/ocMc3btOi6kk81I+JNFPhCaKSftPo=; b=jWtosLau5tk06aEMIiROnfOKVMKnd3LtAa2vykLfOxbh6wUtJjHUIoaTSpIFU27cZ7 RABl8hHYUc0GuFcrHMR4vDMsWgJuCd2jWy/uHMVlXgxprMsU4QTGjVN9NrVSNj5FtuwZ t/cEKD8BlPcpW0WOFtt2GvFeHUn6WmAl1Lirg= 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=NAO6t/TnkwUPJmH3b4Zeh4fbKsBOsmaU8jSBOqdI/jgWSpjr4sjAb/EiJDuf5RzZQf cI3/PpLAD3ftFmVmr+wbHQqti7HhPDW6BIxQv6ZkMV99ZfXIilqMehobD+ZnPm3rkpio lPaxo3evZI9h5ahlpiZEpAjc8VlNxeeyu3JMw= MIME-Version: 1.0 Received: by 10.223.27.18 with SMTP id g18mr1417961fac.52.1308774528971; Wed, 22 Jun 2011 13:28:48 -0700 (PDT) Received: by 10.223.29.72 with HTTP; Wed, 22 Jun 2011 13:28:48 -0700 (PDT) In-Reply-To: References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <4E019A31.70207@nic.cz> <213E0EC97FE58F469BB618245B3118BB54F6C99A90@DEN-MEXMS-001.corp.ebay.com> Date: Wed, 22 Jun 2011 16:28:48 -0400 Message-ID: From: Matt DeMoss To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: "dane@ietf.org" Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:28:51 -0000 DirectAccess looks IPSec-based: http://www.microsoft.com/windows/enterprise/products/windows-7/features.asp= x#directaccess Does anyone know of any ISPs or public services offering IPSec + DNS? It might be simpler for users with a legacy OS to support. 2011/6/22 Phillip Hallam-Baker : > Good point, it is important to distinguish between 'DANE + DNSSEC' and DA= NE > + DNS Security'. > DNS Security is likely to be necessary to provide useful security in DANE= . > DNSSEC is only one way that may be achieved, it is not the only way. > > On Wed, Jun 22, 2011 at 2:11 PM, Hill, Brad wrote: >> >> Not to encourage the use of DANE without DNSSEC, but there are more comm= on >> and obvious scenarios that "look like" this attack. >> >> >> >> Split-tunnel VPNs (selected traffic over VPN, remainder over untrusted >> interface) are increasingly common, and are increasingly "always on". >> "DirectConnect" in Win7 is such a system. >> >> >> >> In such configurations, it's entirely likely (coffee-shop attack) that a= n >> attacker will be a Dolev-Yao class MitM between Alice and Bob, and Alice= and >> public, well-known CAs, but not between Alice and her DNS, which is on t= he >> same medium but IPSec or otherwise protected, or between Alice's DNS and >> Bob's DNS which is on a different medium. >> >> >> >> -Brad >> >> >> >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of >> Phillip Hallam-Baker >> Sent: Wednesday, June 22, 2011 5:19 AM >> To: Ond=F8ej Sur=FD >> Cc: dane@ietf.org >> Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New >> Version Notification for draft-ietf-dane-use-cases-03.txt) >> >> >> >> Again, the issue is not whether attackers could make attacks without maj= or >> collateral damage, it is whether they would choose to do so. >> >> >> >> So far the evidence is that collateral damage is not a concern. >> >> >> >> On Wed, Jun 22, 2011 at 3:30 AM, Ond=F8ej Sur=FD wr= ote: >> >> On 15.6.2011 21:53, Nicholas Weaver wrote: >> >> > Oh, and BGP attacks can be done without noticable side effects, having >> > been on a test network where such an attack was done. >> >> >> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilo= sov-kapela.pdf >> >> In fact the attack is very smart if done right and cannot be detected >> from within hijacked IP space (because your router prevents the AS path >> loops). >> >> 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 >> ------------------------------------------- >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> >> >> -- >> Website: http://hallambaker.com/ >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From bhill@paypal-inc.com Wed Jun 22 13:50:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6765821F8583 for ; Wed, 22 Jun 2011 13:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.517 X-Spam-Level: X-Spam-Status: No, score=-8.517 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9gBrPxQQXXX for ; Wed, 22 Jun 2011 13:50:09 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 472EC21F857A for ; Wed, 22 Jun 2011 13:50:09 -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=DI+olBcguIsvdBPiH198mqZUgbi1Ua3YrAwvyaI0LpTP4nqWpXUXSs8r 69SgcfDUYl5YnEFeehOKUG0KCcnDDKPdwt1FZ4tk/kS/KPF6FvtIGIB5/ Og64mMhnBKg1QTV; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1308775809; x=1340311809; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AJjUrgRS+JIc+wgQ9vNcuHNqlZG7ibP1KsUyCrjvE5k=; b=mms5lhttV3YWkkGVzKHKzCpwKi/WOECs0FozBxtB2iPm8x1KXnzAcNxj RAku9RLK8VOTvAK8JNzxgih7qeVfmUxkq5AT0GunWwbI9eoJgc0+4IEOx NEWPn9UEdfL79df; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.65,407,1304319600"; d="scan'208";a="2477963" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 22 Jun 2011 13:50:09 -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, 22 Jun 2011 14:50:08 -0600 From: "Hill, Brad" To: Matt DeMoss , Phillip Hallam-Baker Date: Wed, 22 Jun 2011 14:50:07 -0600 Thread-Topic: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) Thread-Index: AcwxGwy4hvLTBw0xSDaJxqP7WlDABgAAZQBA Message-ID: <213E0EC97FE58F469BB618245B3118BB54F6C99C38@DEN-MEXMS-001.corp.ebay.com> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <4E019A31.70207@nic.cz> <213E0EC97FE58F469BB618245B3118BB54F6C99A90@DEN-MEXMS-001.corp.ebay.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: q6NbgFje/wh2wdyQvXJf6Q== Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "dane@ietf.org" Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:50:10 -0000 Re: 1) yes, it is IPv6 over IPv4 + IPSec Re: 2) I am not. However, considering that DNS + Certificate Based IPSec = is available even on WinXP, it could be a start at tackling the last mile p= roblem for legacy OSs. You'd have to disable DHCP-advertised DNS servers, = which could break access to some local resources, but I bet that would affe= ct only a very tiny % of home users. Breaking laptops with legacy OSs in = captive portal scenarios is a bigger concern, but that can probably be addr= essed with a patch to the browser, not the OS. -----Original Message----- From: Matt DeMoss [mailto:demoss.matt@gmail.com]=20 Sent: Wednesday, June 22, 2011 1:29 PM To: Phillip Hallam-Baker Cc: Hill, Brad; dane@ietf.org Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Ve= rsion Notification for draft-ietf-dane-use-cases-03.txt) DirectAccess looks IPSec-based: http://www.microsoft.com/windows/enterprise/products/windows-7/features.asp= x#directaccess Does anyone know of any ISPs or public services offering IPSec + DNS? It might be simpler for users with a legacy OS to support. 2011/6/22 Phillip Hallam-Baker : > Good point, it is important to distinguish between 'DANE + DNSSEC' and=20 > DANE > + DNS Security'. > DNS Security is likely to be necessary to provide useful security in DANE= . > DNSSEC is only one way that may be achieved, it is not the only way. > > On Wed, Jun 22, 2011 at 2:11 PM, Hill, Brad wrote: >> >> Not to encourage the use of DANE without DNSSEC, but there are more=20 >> common and obvious scenarios that "look like" this attack. >> >> >> >> Split-tunnel VPNs (selected traffic over VPN, remainder over=20 >> untrusted >> interface) are increasingly common, and are increasingly "always on". >> "DirectConnect" in Win7 is such a system. >> >> >> >> In such configurations, it's entirely likely (coffee-shop attack)=20 >> that an attacker will be a Dolev-Yao class MitM between Alice and=20 >> Bob, and Alice and public, well-known CAs, but not between Alice and=20 >> her DNS, which is on the same medium but IPSec or otherwise=20 >> protected, or between Alice's DNS and Bob's DNS which is on a different = medium. >> >> >> >> -Brad >> >> >> >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf=20 >> Of Phillip Hallam-Baker >> Sent: Wednesday, June 22, 2011 5:19 AM >> To: Ond=F8ej Sur=FD >> Cc: dane@ietf.org >> Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was:=20 >> New Version Notification for draft-ietf-dane-use-cases-03.txt) >> >> >> >> Again, the issue is not whether attackers could make attacks without=20 >> major collateral damage, it is whether they would choose to do so. >> >> >> >> So far the evidence is that collateral damage is not a concern. >> >> >> >> On Wed, Jun 22, 2011 at 3:30 AM, Ond=F8ej Sur=FD wr= ote: >> >> On 15.6.2011 21:53, Nicholas Weaver wrote: >> >> > Oh, and BGP attacks can be done without noticable side effects,=20 >> > having been on a test network where such an attack was done. >> >> >> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-p >> ilosov-kapela.pdf >> >> In fact the attack is very smart if done right and cannot be detected=20 >> from within hijacked IP space (because your router prevents the AS=20 >> path loops). >> >> 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 >> ------------------------------------------- >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> >> >> -- >> Website: http://hallambaker.com/ >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >> > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From kent@bbn.com Wed Jun 22 13:58:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA1D21F85AB for ; Wed, 22 Jun 2011 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.751 X-Spam-Level: X-Spam-Status: No, score=-105.751 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvBeq7PGvEBN for ; Wed, 22 Jun 2011 13:58:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 991A821F85B0 for ; Wed, 22 Jun 2011 13:58:25 -0700 (PDT) Received: from dhcp89-089-178.bbn.com ([128.89.89.178]:49197) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QZUVE-000HUx-Mg; Wed, 22 Jun 2011 16:58:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E019A31.70207@nic.cz> References: <20110612215003.14916.98457.idtracker@ietfa.amsl.com> <0763EDAB-9349-4614-8C25-8525A7BF317D@bbn.com> <4DF8BA46.7020800@nic.cz> <4E019A31.70207@nic.cz> Date: Wed, 22 Jun 2011 16:53:11 -0400 To: =?iso-8859-1?Q?Ond=DEej_Sur=98?= From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New Version Notification for draft-ietf-dane-use-cases-03.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 20:58:26 -0000 At 9:30 AM +0200 6/22/11, Ond=DEej Sur=98 wrote: >On 15.6.2011 21:53, Nicholas Weaver wrote: > >> Oh, and BGP attacks can be done without=20 >>noticable side effects, having been on a test=20 >>network where such an attack was done. > >http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov= -kapela.pdf > >In fact the attack is very smart if done right and cannot be detected >from within hijacked IP space (because your router prevents the AS path >loops). > >O. >-- Targets of the attacks will not notice it, but=20 other observers will, in general. The issue here is that an attacker cannot know,=20 with high certainty, which other ASes may engage=20 in monitoring BGP data, and if one tries to list=20 all such ASes, the path will become very long,=20 thus less attractive, and not suitable for=20 traffic diversion. Note that IDR has approved an=20 I-D that deprecates AS sets, so one cannot game the system by putting the AS #'s=20 of potential monitoring sites into an AS set, to=20 avoid making the path longer :-). So, in general,=20 an attack of this sort is not really invisible. Steve From mrex@sap.com Fri Jun 24 01:42:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59921F84D8 for ; Fri, 24 Jun 2011 01:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.554 X-Spam-Level: X-Spam-Status: No, score=-9.554 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp9RbqGhxdSI for ; Fri, 24 Jun 2011 01:42:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ABC8621F84D6 for ; Fri, 24 Jun 2011 01:42:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5O8gkgj011338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 10:42:46 +0200 (MEST) From: Martin Rex Message-Id: <201106240842.p5O8gjjH023993@fs4113.wdf.sap.corp> To: rbarnes@bbn.com (Richard L. Barnes) Date: Fri, 24 Jun 2011 10:42:45 +0200 (MEST) In-Reply-To: from "Richard L. Barnes" at Jun 13, 11 09:43:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 08:42:54 -0000 Richard L. Barnes wrote: > > > 1) Use of DANE without DNSSEC > > I added the paragraph you note to more correctly describe the impact > of using DANE without DNSSEC, as you, Jim, and Jeff all noted: > Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html > Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html > Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html > > Can we agree that the current draft accurately describes the (admittedly > minor) effect of using DANE without DNSSEC? Excuse me while I panic (about this potentially ambiguos wording). DANE without DNSSEC has value infinitesimal close zero at best in some cases adds significant complexity and has a serious potential to harm by confusing or misleading implementors and consumers. In general, the information conveyed could be used for two significantly distinct purposes: (1) positive confirmation that a server certificate should be considered valid (2) negative indication that a server certificate should be considered invalid for that server I see (1) without DNSSEC as a real security problem creating a false sense of security And I also see (2) without DNSSEC as a security problem, because it means creating interop problems based on a vague hunch that may have been crafted by an attacker. I don't think that PKIX suggest that you should honour revocations on CRLs where the CRL signature is missing or signature verification fails for whatever reason, and I really don't see why restriction management through DANE should be any different -- in particular when the server certificate was signed under a CA from the traditional "TLS X.509 PKI". And while we're fighting with the details, we probably should not forget the bigger picture. There seems to be the notion (that I share) that when it is about average Human Users using Web Browsers, successfully completing the TLS handshake even when the server endpoint identification fails might often be preferable than the alternative, that a determined user retries entirely without HTTPS. If the reference identifier for an HTTPS request is not from a locally trusted source (which applies to 95% of the requests already today, and will apply to 99.99% of the requests once search engines are used via HTTPS exclusively), so the security value of the server endpoint identification may questionable anyway. -Martin From hallam@gmail.com Fri Jun 24 04:52:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8079321F84DD for ; Fri, 24 Jun 2011 04:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg8AGfNP5OM6 for ; Fri, 24 Jun 2011 04:52:11 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2635321F84B6 for ; Fri, 24 Jun 2011 04:52:11 -0700 (PDT) Received: by gya6 with SMTP id 6so1603178gya.31 for ; Fri, 24 Jun 2011 04:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3vcrubRcS3mx87He9xGubaBG/beCD8ND0+Bv7VrfExE=; b=Ueo/hG/AwAB8l7Jo9p+2zveeuYvlYVn807OOuDktzNZK91iLLGLda9ZhLngfi3iOXf S/SLGZJ9d3YhXHHNrM4JUUDz8usLh9DbwSPJEeRZE+AenBEWA8plH3+fYGa9LHCJHIAu DcvluKC4BgypMXuphAzkbANi6bBaSwLPB69WM= 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=aBSUaD7RRxu8XRt+TM7aFjrHCv4QHXs+HnT0x3FGtF+goCKppwFp0FGZM6bIFJuxMJ JtFK5M0iJVOxjHcS3P36bdIfRouzQWwVAdRUIiUjSKOK3YW2Wnb+X8Pbk1RXUxG9oEy+ QTLmqDNnasMULOS0D9N4a8csu4XmpK01r07Kg= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr3479309anh.40.1308916330427; Fri, 24 Jun 2011 04:52:10 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Fri, 24 Jun 2011 04:52:10 -0700 (PDT) In-Reply-To: <201106240842.p5O8gjjH023993@fs4113.wdf.sap.corp> References: <201106240842.p5O8gjjH023993@fs4113.wdf.sap.corp> Date: Fri, 24 Jun 2011 07:52:10 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016369fa252ea759304a673d45a Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 11:52:12 -0000 --0016369fa252ea759304a673d45a Content-Type: text/plain; charset=ISO-8859-1 DANE without DNSSEC can be 100% secure. The question is whether DANE can be secure without SOME form of DNS authentication. The protocol by which that is implemented in the relying party is a very different matter. This is a standards process and it is pretty important to be precise on such matters. For embedded systems, DANE might well be of most utility as a means of offloading PKI processing from the endpoint device. Yeah, I know about the end-to-end security principle. I have discussed it at length with Dave Clark and others from that era. What most people think is the end to end principle is not what they proposed or described in their papers. On Fri, Jun 24, 2011 at 4:42 AM, Martin Rex wrote: > Richard L. Barnes wrote: > > > > > 1) Use of DANE without DNSSEC > > > > I added the paragraph you note to more correctly describe the impact > > of using DANE without DNSSEC, as you, Jim, and Jeff all noted: > > Wouters: http://www.ietf.org/mail-archive/web/dane/current/msg02559.html > > Schaad: http://www.ietf.org/mail-archive/web/dane/current/msg02564.html > > Hodges: http://www.ietf.org/mail-archive/web/dane/current/msg02579.html > > > > Can we agree that the current draft accurately describes the (admittedly > > minor) effect of using DANE without DNSSEC? > > Excuse me while I panic (about this potentially ambiguos wording). > > DANE without DNSSEC has value infinitesimal close zero at best in some > cases adds significant complexity and has a serious potential to harm > by confusing or misleading implementors and consumers. > > > In general, the information conveyed could be used for two significantly > distinct purposes: > > (1) positive confirmation that a server certificate should be considered > valid > > (2) negative indication that a server certificate should be considered > invalid for that server > > > I see (1) without DNSSEC as a real security problem creating a false > sense of security > > And I also see (2) without DNSSEC as a security problem, because it > means creating interop problems based on a vague hunch that may have > been crafted by an attacker. I don't think that PKIX suggest that > you should honour revocations on CRLs where the CRL signature is > missing or signature verification fails for whatever reason, and > I really don't see why restriction management through DANE should > be any different -- in particular when the server certificate > was signed under a CA from the traditional "TLS X.509 PKI". > > > And while we're fighting with the details, we probably should not > forget the bigger picture. There seems to be the notion (that I share) > that when it is about average Human Users using Web Browsers, > successfully completing the TLS handshake even when the server endpoint > identification fails might often be preferable than the alternative, > that a determined user retries entirely without HTTPS. > > If the reference identifier for an HTTPS request is not from a > locally trusted source (which applies to 95% of the requests already > today, and will apply to 99.99% of the requests once search engines > are used via HTTPS exclusively), so the security value of the server > endpoint identification may questionable anyway. > > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016369fa252ea759304a673d45a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable DANE without DNSSEC can be 100% secure.

The question is = whether DANE can be secure without SOME form of DNS authentication. The pro= tocol by which that is implemented in the relying party is a very different= matter.


This is a standards process and it is pr= etty important to be precise on such matters.=A0

F= or embedded systems, DANE might well be of most utility as a means of offlo= ading PKI processing from the endpoint device.

Yeah, I know about the end-to-end security principle. I= have discussed it at length with Dave Clark and others from that era. What= most people think is the end to end principle is not what they proposed or= described in their papers.



On Fri, Jun 24, 2011= at 4:42 AM, Martin Rex <mrex@sap.com> wrote:
Richard L. Barnes wrote:
>
> > 1) Use of DANE without DNSSEC
>
> I added the paragraph you note to more correctly describe the impact > of using DANE without DNSSEC, as you, Jim, and Jeff all noted:
> Wouters: http://www.ietf.org/mail-archive/web/dane/= current/msg02559.html
> Schaad: http://www.ietf.org/mail-archive/web/dane/c= urrent/msg02564.html
> Hodges: http://www.ietf.org/mail-archive/web/dane/c= urrent/msg02579.html
>
> Can we agree that the current draft accurately describes the (admitted= ly
> minor) effect of using DANE without DNSSEC?

Excuse me while I panic (about this potentially ambiguos wording).

DANE without DNSSEC has value infinitesimal close zero at best in some
cases adds significant complexity and has a serious potential to harm
by confusing or misleading implementors and consumers.


In general, the information conveyed could be used for two significantly distinct purposes:

=A0(1) positive confirmation that a server certificate should be considere= d
=A0 =A0 =A0valid

=A0(2) negative indication that a server certificate should be considered<= br> =A0 =A0 =A0invalid for that server


I see (1) without DNSSEC as a real security problem creating a false
sense of security

And I also see (2) without DNSSEC as a security problem, because it
means creating interop problems based on a vague hunch that may have
been crafted by an attacker. =A0I don't think that PKIX suggest that you should honour revocations on CRLs where the CRL signature is
missing or signature verification fails for whatever reason, and
I really don't see why restriction management through DANE should
be any different -- in particular when the server certificate
was signed under a CA from the traditional "TLS X.509 PKI".


And while we're fighting with the details, we probably should not
forget the bigger picture. =A0There seems to be the notion (that I share) that when it is about average Human Users using Web Browsers,
successfully completing the TLS handshake even when the server endpoint
identification fails might often be preferable than the alternative,
that a determined user retries entirely without HTTPS.

If the reference identifier for an HTTPS request is not from a
locally trusted source (which applies to 95% of the requests already
today, and will apply to 99.99% of the requests once search engines
are used via HTTPS exclusively), so the security value of the server
endpoint identification may questionable anyway.


-Martin
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016369fa252ea759304a673d45a-- From rbarnes@bbn.com Fri Jun 24 08:19:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BCF11E80D4 for ; Fri, 24 Jun 2011 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZDytNkgWJgT for ; Fri, 24 Jun 2011 08:19:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AFA6611E80A5 for ; Fri, 24 Jun 2011 08:19:53 -0700 (PDT) Received: from ros-dhcp192-1-51-90.bbn.com ([192.1.51.90]:56427) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qa8Ad-000EQX-Q7; Fri, 24 Jun 2011 11:19:47 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <1305302244.3471.21.camel@localhost> Date: Fri, 24 Jun 2011 11:19:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <1305302244.3471.21.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1082) Cc: dane Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:19:54 -0000 Hey Matt, Sorry I missed these earlier. I think they're ultimately mostly = addressed by revisions in the new document. Some responses inline. --Richard > - The security considerations in Section 3.1 could be clarified. Here > is some alternative text as inspiration: I think this comment is addressed by the revised security considerations = in 3.1. They're not quite as detailed as your suggested text, but they = capture the basic bounds of the problem. > - This text does not belong in Section 3.3: >=20 > Deleted records > will only result in connection failure and denial of service, > although this could result in clients re-connecting without TLS (a > downgrade attack), depending on the application. Therefore, in = order > for this use case to be safe, applications must forbid clients from > falling back to unsecured channels when records appear to have been > deleted (e.g., when a missing record has no NSEC or NSEC3 record). >=20 > Preventing a downgrade from TLS to non-TLS is, strictly speaking, an > orthogonal issue to TLS server authentication. My understanding was > that the scope of DANE was only the latter, and the former would be > addressed with HASTLS or some such. If the downgrade prevention is to > be mentioned here, it should be its own use case; it is not in any way > specific to the use of domain-issued certificates. You're correct that downgrade is an issue that applications need to = address, but it is something that DANE should keep in mind. I think the = solution is pretty simple -- just require the use of NSEC/NSEC3, which = is already standard practice for DNSSEC. > - Re the newfound power of DNSSEC zone operators under DANE (Section > 3.3): I would not attempt to minimize this issue. CAs will not = hesitate > to remind us of the extra checks they perform for certain sites, so = the > comparison to domain validation is not entirely correct. Sites that > have special relationships with CAs but do not have proper oversight = of > their DNSSEC zones will, indeed, have their security weakened when > clients adopt DANE. If we are concerned about this, I think the = natural > solution is to have a flag with each DNSSEC delegation that indicates > that the registrant fully trusts the child zone operator and hence > schemes such as DANE can be enabled. I've tried to moderate this section in the new version, in particular: " It should be noted that DNS operators already have the ability to obtain = certificates for domains under their control, under certain CA policies. " > - Section 3.4: I don't understand the motivation for constraining the > certificates used by an outsourcing provider. If the provider is > operating the service, what security benefit can there be to forcing = the > provider to use a particular certificate? Is this something I missed = in > the discussion? Couple of examples: - Alice is concerned that Oscar might use a certificate that contains a = public key for which a third party (police, criminal associates) also = has the private keys, as a way of indirectly exposing Alice's traffic. - Alice is concerned that Oscar might use a certificate that contains a = public key that uses a weaker cryptographic algorithm than Alice = requires (say 1024-bit instead of 2048-bit RSA). - Alice is concerned that Oscar present a DV cert instead of the EV cert = she provided him. --Richard From mrex@sap.com Fri Jun 24 08:24:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E3A11E80A1 for ; Fri, 24 Jun 2011 08:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCykiDDJFyNh for ; Fri, 24 Jun 2011 08:24:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3F11E808C for ; Fri, 24 Jun 2011 08:24:44 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5OFOe6i009823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 17:24:40 +0200 (MEST) From: Martin Rex Message-Id: <201106241524.p5OFOe02016635@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 24 Jun 2011 17:24:40 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jun 22, 11 03:28:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 15:24:53 -0000 Phillip Hallam-Baker wrote: > > Good point, it is important to distinguish between 'DANE + DNSSEC' and DANE > + DNS Security'. > > DNS Security is likely to be necessary to provide useful security in DANE. > DNSSEC is only one way that may be achieved, it is not the only way. What you really need is data end-to-end data integrity protection plus data originiator authentication of the TLSA record from the responsible DNS admin to the TLS client that performs the server endpoint identification. It would be foolish to infer from any small intermediate hop-to-hop link going through a protected tunnel (like IPsec), that this makes the lack of security of unsigned TLSA records non-marginally less insecure / less dangerous. -Martin From hallam@gmail.com Fri Jun 24 10:25:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E1F11E816F for ; Fri, 24 Jun 2011 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zCllDn4Qik4 for ; Fri, 24 Jun 2011 10:25:57 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF7B411E809F for ; Fri, 24 Jun 2011 10:25:55 -0700 (PDT) Received: by yie30 with SMTP id 30so1773665yie.31 for ; Fri, 24 Jun 2011 10:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UqK8jW+Pz5l/ImWNbrHO9RP0oqDd0af6yz2tX2uzCiI=; b=CJGQz1YfezwIaeVIXUmj7ZGAQmbpN+xHUpuY00Jlu7VUVEicyeb+eakRL0zpFstlBh IwdyZrAkTOLwVx+vR4q73oH8FPGuMTxyOTGD9YVhzhvn/t0kXje4IkRWWpD+nT8YX6SP MhhbHPj5gxn9Bb8pHf7BFvIfwOZ4f4dnWcR9g= 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=MsTfmXWDgyyqwhWVPSHFGxwCZfpMLu+tO7Oo9bg0IMt6wxT6EVwCFyhrwD4JCiQAQD xEoh35t27hpTDSlOsvV2y60nMW1J80WQTR+DSfljaJTqHUVkbzCVT7EPnxOrgEBU+FrK o7xvdEoQqvtYbXVWD9K9WteHcLk9BjlNBWKlc= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr3860373anh.40.1308936355382; Fri, 24 Jun 2011 10:25:55 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Fri, 24 Jun 2011 10:25:55 -0700 (PDT) In-Reply-To: <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <1305302244.3471.21.camel@localhost> <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> Date: Fri, 24 Jun 2011 13:25:55 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=0016369fa2527f06e604a6787e66 Cc: dane Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 17:25:59 -0000 --0016369fa2527f06e604a6787e66 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 24, 2011 at 11:19 AM, Richard L. Barnes wrote: > > > - This text does not belong in Section 3.3: > > > > Deleted records > > will only result in connection failure and denial of service, > > although this could result in clients re-connecting without TLS (a > > downgrade attack), depending on the application. Therefore, in order > > for this use case to be safe, applications must forbid clients from > > falling back to unsecured channels when records appear to have been > > deleted (e.g., when a missing record has no NSEC or NSEC3 record). > > > > Preventing a downgrade from TLS to non-TLS is, strictly speaking, an > > orthogonal issue to TLS server authentication. My understanding was > > that the scope of DANE was only the latter, and the former would be > > addressed with HASTLS or some such. If the downgrade prevention is to > > be mentioned here, it should be its own use case; it is not in any way > > specific to the use of domain-issued certificates. > > You're correct that downgrade is an issue that applications need to > address, but it is something that DANE should keep in mind. I think the > solution is pretty simple -- just require the use of NSEC/NSEC3, which is > already standard practice for DNSSEC I agree on the requirement. But I completely disagree on the proposal. At the moment we have at least four levels of security either on the Internet or in discussion in IETF: 0) No security 1) Domain Validated Security 2) Domain Validated + Organizational (inc. EV) 3) 'Strict' Security I don't like the idea of having DANE be an implicit protection against downgrade because I want there to be the option of a more thorough downgrade protection. It would also mean a big change to browsers. It would require the browser to check DANE records on every HTTP transaction and not just when HTTPS is specified. We could argue that the DV/EV type difference can be dealt with by having DANE implicitly endorsing the relevant certificate. But that leaves a lot out of consideration, including the strict security work by Jeff Hodges and others Also, there are going to be cases where flaws are discovered in TLS or other protocols and when those get patched it is going to be necessary to specify that a particular version of TLS is in use. The tag mechanism of CAA is designed to allow for this type of assertion to be made. So there could be a property https that takes a text field that then has an internal structure to allow the relevant properties to be declared (always/required/refused + min version no.) Pushing it off into a separate feature also allows the group to move much faster as it is not necessary to go into interminable discusion of how the feature needs to work and what is essential. If something important is missed out it can be added later. If the requirement to use TLS is implicit, there can only be one set of implicit criteria. Another point here is the desire to support promiscuous security. In ESRV I propose a mechanism that is designed to be called every time a Web browser attempts to connect to a server. If the server says that TLS is always offered, it will transparently upgrade. -- Website: http://hallambaker.com/ --0016369fa2527f06e604a6787e66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 24, 2011 at 11:19 AM, Richar= d L. Barnes <rbarne= s@bbn.com> wrote:

> - This text does not belong in Section 3.3:
>
> =A0 Deleted records
> =A0 will only result in connection failure and denial of service,
> =A0 although this could result in clients re-connecting without TLS (a=
> =A0 downgrade attack), depending on the application. =A0Therefore, in = order
> =A0 for this use case to be safe, applications must forbid clients fro= m
> =A0 falling back to unsecured channels when records appear to have bee= n
> =A0 deleted (e.g., when a missing record has no NSEC or NSEC3 record).=
>
> Preventing a downgrade from TLS to non-TLS is, strictly speaking, an > orthogonal issue to TLS server authentication. =A0My understanding was=
> that the scope of DANE was only the latter, and the former would be > addressed with HASTLS or some such. =A0If the downgrade prevention is = to
> be mentioned here, it should be its own use case; it is not in any way=
> specific to the use of domain-issued certificates.

You're correct that downgrade is an issue that applications need = to address, but it is something that DANE should keep in mind. =A0I think t= he solution is pretty simple -- just require the use of NSEC/NSEC3, which i= s already standard practice for DNSSEC

I agree on the requirement. But I completely disagree o= n the proposal.

At the moment we have at least fou= r levels of security either on the Internet or in discussion in IETF:

0) No security
1) Domain Validated Security
2) Domain Validated + Organizational (inc. EV)
3) 'S= trict' Security=A0

I don't like the idea o= f having DANE be an implicit protection against downgrade because I want th= ere to be the option of a more thorough downgrade protection.

It would also mean a big change to browsers. It would r= equire the browser to check DANE records on every HTTP transaction and not = just when HTTPS is specified.


We could argue that the DV/EV type difference can be dea= lt with by having DANE implicitly endorsing the relevant certificate. But t= hat leaves a lot out of consideration, including the strict security work b= y Jeff Hodges and others

Also, there are going to be cases where flaws are disco= vered in TLS or other protocols and when those get patched it is going to b= e necessary to specify that a particular version of TLS is in use.


The tag mechanism of CAA is designed to = allow for this type of assertion to be made. So there could be a property h= ttps that takes a text field that then has an internal structure to allow t= he relevant properties to be declared (always/required/refused + min versio= n no.)

Pushing it off into a separate feature also allows the = group to move much faster as it is not necessary to go into interminable di= scusion of how the feature needs to work and what is essential. If somethin= g important is missed out it can be added later. If the requirement to use = TLS is implicit, there can only be one set of implicit criteria.


Another point here is the desire to supp= ort promiscuous security. In ESRV I propose a mechanism that is designed to= be called every time a Web browser attempts to connect to a server. If the= server says that TLS is always offered, it will transparently upgrade.

--
Website: ht= tp://hallambaker.com/

--0016369fa2527f06e604a6787e66-- From mrex@sap.com Fri Jun 24 10:53:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5C11E81B9 for ; Fri, 24 Jun 2011 10:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.641 X-Spam-Level: X-Spam-Status: No, score=-9.641 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFZ+Q-J1EADf for ; Fri, 24 Jun 2011 10:53:29 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 01B9011E81CB for ; Fri, 24 Jun 2011 10:53:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5OHrLQH009241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 19:53:21 +0200 (MEST) From: Martin Rex Message-Id: <201106241753.p5OHrLDS025187@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 24 Jun 2011 19:53:21 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jun 24, 11 01:25:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 17:53:30 -0000 Phillip Hallam-Baker wrote: > > I don't like the idea of having DANE be an implicit protection against > downgrade I do. > > because I want there to be the option of a more thorough > downgrade protection. I fail to understand. DANE (with DNSSEC) protects against downgrade of server endpoint identification and it is entirely impossible to get any stronger than DANE (the latter is formally provable). > > It would also mean a big change to browsers. It would require the browser to > check DANE records on every HTTP transaction and not just when HTTPS is > specified. I fail to understand. Since it is possible to replay DNSSEC records for as long as the RRSIG validity specifies without the resolver being able to notice, caching TLSA DNS records as well as processing results is trivial and straightforward. Certainly a magnitude easier than any of the PKIX revocation processing. > > We could argue that the DV/EV type difference can be dealt with by having > DANE implicitly endorsing the relevant certificate. But that leaves a lot > out of consideration, including the strict security work by Jeff Hodges and > others The way server endpoint identification for TLS is defined in rfc2818 and rfc6125, there is *ZERO* difference between EV, OV and DV. Any additional attributes vetted for in OV in EV certs matter only to human users of browsers that provide fancy/colorful chome feedback about additional OV/EV cert attributes beyond the server endpoint identification -- if they matter at all (which often, they don't). > > Also, there are going to be cases where flaws are discovered in TLS > or other protocols and when those get patched it is going to be > necessary to specify that a particular version of TLS is in use. Complete non-issue. DANE is orthogonal to TLS, and server endpoint identification is *EXPLICITLY* out-of-scope for TLS in every TLS spec in existence. (Check out the last sentence of Section 1 "Introduction" of your favorite TLS spec (rfc2246, rfc4346, rfc5246). > > Another point here is the desire to support promiscuous security. In ESRV I > propose a mechanism that is designed to be called every time a Web browser > attempts to connect to a server. If the server says that TLS is always > offered, it will transparently upgrade. That is commonly done via HTTP 302 or META REFRESH to a https:// address. What you suggest here sound like: I'm surfing a trusted resource via https://place-a/some/path that contains an A HREF=http://place-b/some/path and you suggest that your browser should connect to https://place-c/some/path instead, based on a DNS record for place-a? I hope you see the imperative for a valid DNSSEC signature of such a DNS record -- but ultimately this appears to be a security defect in the original resource https://place-a/some/path that really ought to be fixed there (and how it will work for all of the installed base already today). -Martin From mrex@sap.com Fri Jun 24 11:34:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A147D11E8161 for ; Fri, 24 Jun 2011 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.687 X-Spam-Level: X-Spam-Status: No, score=-9.687 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkK3EYf4mn2o for ; Fri, 24 Jun 2011 11:34:30 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 52FDA11E813A for ; Fri, 24 Jun 2011 11:34:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5OIYSuO015423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 20:34:28 +0200 (MEST) From: Martin Rex Message-Id: <201106241834.p5OIYSPE027266@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 24 Jun 2011 20:34:28 +0200 (MEST) In-Reply-To: <201106241753.p5OHrLDS025187@fs4113.wdf.sap.corp> from "Martin Rex" at Jun 24, 11 07:53:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 18:34:31 -0000 Ooops, typo: I meant to write "DNS record for place-b" (already fixed below): Martin Rex wrote: > > > > > Another point here is the desire to support promiscuous security. In ESRV I > > propose a mechanism that is designed to be called every time a Web browser > > attempts to connect to a server. If the server says that TLS is always > > offered, it will transparently upgrade. > > That is commonly done via HTTP 302 or META REFRESH to a https:// address. > > What you suggest here sound like: > > I'm surfing a trusted resource via https://place-a/some/path that contains > an A HREF=http://place-b/some/path and you suggest that your browser > should connect to https://place-c/some/path instead, based on a ! DNS record for place-b? I hope you see the imperative for > a valid DNSSEC signature of such a DNS record -- but ultimately > this appears to be a security defect in the original resource > https://place-a/some/path that really ought to be fixed there > (and how it will work for all of the installed base already today). -Martin From mrex@sap.com Fri Jun 24 14:20:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A9F11E80E9 for ; Fri, 24 Jun 2011 14:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.728 X-Spam-Level: X-Spam-Status: No, score=-9.728 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUsxuooIbwwT for ; Fri, 24 Jun 2011 14:20:56 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A377411E80D6 for ; Fri, 24 Jun 2011 14:20:55 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5OLKqrk000766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 23:20:52 +0200 (MEST) From: Martin Rex Message-Id: <201106242120.p5OLKqZj006661@fs4113.wdf.sap.corp> To: bhill@paypal-inc.com (Hill Brad) Date: Fri, 24 Jun 2011 23:20:52 +0200 (MEST) In-Reply-To: <213E0EC97FE58F469BB618245B3118BB54F6C99C38@DEN-MEXMS-001.corp.ebay.com> from "Hill, Brad" at Jun 22, 11 02:50:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 21:20:56 -0000 Hill, Brad wrote: > > Re: 1) yes, it is IPv6 over IPv4 + IPSec > > Re: 2) I am not. However, considering that DNS + Certificate Based > IPSec is available even on WinXP, it could be a start at tackling the > last mile problem for legacy OSs. You'd have to disable DHCP-advertised > DNS servers, which could break access to some local resources, but I bet > that would affect only a very tiny % of home users. Breaking laptops > with legacy OSs in captive portal scenarios is a bigger concern, > but that can probably be addressed with a patch to the browser, not the OS. Captive portals break everything except web browser anyway, so improving the browser captive-portal awareness, maybe hinting the user through chrome indicators, might be a way forward on this one. That probably wont work for MSIE on WinXP/XP-64. Since Microsoft seems to have mostly abandoned SChannel&CryptoAPI improvements for XP, you might be better of with Firefox, Opera or Google Chrome on that platform anyway (TLS AES ciphersuites, full SHA-2, SNI, details about TLS errors). -Martin From rbarnes@bbn.com Fri Jun 24 14:49:30 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3821F84CB for ; Fri, 24 Jun 2011 14:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgsolmGw0QFs for ; Fri, 24 Jun 2011 14:49:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8321F84D8 for ; Fri, 24 Jun 2011 14:49:29 -0700 (PDT) Received: from ros-dhcp192-1-51-90.bbn.com ([192.1.51.90]:58383) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QaEFk-0009kh-Dg; Fri, 24 Jun 2011 17:49:28 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4DFBCF3D.4080509@KingsMountain.com> Date: Fri, 24 Jun 2011 17:49:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2053AAFB-4CE4-4E76-8E00-84A0F69B2252@bbn.com> References: <4DFBCF3D.4080509@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) Cc: IETF DANE WG list Subject: Re: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 21:49:30 -0000 Thanks for pointing this out. Couple of notes: - This mechanism uses the CAA mechanism from draft-ietf-pkix-caa with = the "Relying Application Use" bit set -- the one that conflicts with = DANE. =20 - This mechanism would actually not be implementable with DANE, because = the "stapled" DNSSEC information is included in the cert -- including = the terminal CAA record. So if DANE (protocol-07) were used instead of = CAA, then the cert would have to include a hash of itself, which is kind = of an impossibility. - These certs have subject=3D=3Dissuer=3D=3D"DNSSEC Signed". That = breaks RFC 6125 rather badly, but since the certs are self-signed maybe = that's not a big deal. - The DNSSEC information is held in a certificate extension. The format = of this extension would be a nice PKIX draft. --Richard =20 On Jun 17, 2011, at 6:03 PM, =3DJeffH wrote: > of posible interest: Adam Langley's blog post from yesterday... >=20 > DNSSEC authenticated HTTPS in Chrome (16 Jun 2011) > http://www.imperialviolet.org/2011/06/16/dnssecchrome.html >=20 >=20 > =3DJeffH >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From hallam@gmail.com Fri Jun 24 17:56:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19C99E8018 for ; Fri, 24 Jun 2011 17:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLgYmowFl2zl for ; Fri, 24 Jun 2011 17:56:39 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB6CE9E8005 for ; Fri, 24 Jun 2011 17:56:38 -0700 (PDT) Received: by ywp31 with SMTP id 31so1931896ywp.31 for ; Fri, 24 Jun 2011 17:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Brsb3XCH9/UIfaloUh3M7gJvrYzSjLKXjDmASOkJhxE=; b=IAzYed5uoAgTRt5aXklTVRBGE1fgehmg59vpLQqtHZlryxFUQRkrJvAtjiCBNdeHG0 hSyvqBmS8MNKm4yHk9LslW42imHczMS4IBMNDxUp+xbw0L2ry+xeBmGY8CMCF9HTp1Kc MojAplF3fBKLMNBDRroYz2b+v3gYT+s1uhKCM= 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=erNjHDjYCNjDh54mWpUVyZ6xfXTMSXsN94HDGlrm2gIkSO201HYmFsMXty5yz3fJCr tC5M9CrpR2bcfPk/lVed8vpnSqMtvphd8kuTn/2GdTAyLxqUHmaIDhcaK0BytJuXU8jY kh9YDmRYTXfNQLwklka/vYpBJWqgNjDx6JlIM= MIME-Version: 1.0 Received: by 10.101.186.17 with SMTP id n17mr2046821anp.106.1308963397393; Fri, 24 Jun 2011 17:56:37 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Fri, 24 Jun 2011 17:56:36 -0700 (PDT) In-Reply-To: <201106241524.p5OFOe02016635@fs4113.wdf.sap.corp> References: <201106241524.p5OFOe02016635@fs4113.wdf.sap.corp> Date: Fri, 24 Jun 2011 20:56:36 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016368e2b7f535e9804a67ecaae Cc: dane@ietf.org Subject: Re: [dane] [off-topic] "Unnoticeable" BGP MitM attack (Was: New X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 00:56:39 -0000 --0016368e2b7f535e9804a67ecaae Content-Type: text/plain; charset=ISO-8859-1 You have no idea what my application constraints are and thus you are not qualified to give an opinion on what security model is appropriate for my application. Aside from my work for Comodo, I have for many years been working on the problem of how to establish a security model for embedded devices. I don't want to be configuring PKI in every lightbulb I deploy thank very much. Deployment has to be completely automatic. Anything more than scanning a device for a barcode is unacceptable. [Ob Disclosure: I have pending patent applications on how to deploy crypto in lightbulbs and fully reserve my rights etc.] >From the specification point of view it should be sufficient to state that the DNS responses must be trustworthy in order for the DANE key to be considered trustworthy. Trying to do anything more is counterproductive. On Fri, Jun 24, 2011 at 11:24 AM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > > > Good point, it is important to distinguish between 'DANE + DNSSEC' and > DANE > > + DNS Security'. > > > > DNS Security is likely to be necessary to provide useful security in > DANE. > > DNSSEC is only one way that may be achieved, it is not the only way. > > What you really need is data end-to-end data integrity protection > plus data originiator authentication of the TLSA record from the > responsible DNS admin to the TLS client that performs the server > endpoint identification. > > It would be foolish to infer from any small intermediate > hop-to-hop link going through a protected tunnel (like IPsec), > that this makes the lack of security of unsigned TLSA records > non-marginally less insecure / less dangerous. > > -Martin > -- Website: http://hallambaker.com/ --0016368e2b7f535e9804a67ecaae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You have no idea what my application constraints are and thus you are not q= ualified to give an opinion on what security model is appropriate for my ap= plication.

Aside from my work for Comodo, I have for man= y years been working on the problem of how to establish a security model fo= r embedded devices. I don't want to be configuring PKI in every lightbu= lb I deploy thank very much. Deployment has to be completely automatic. Any= thing more than scanning a device for a barcode is unacceptable.=A0

[Ob Disclosure: I have pending patent applications on h= ow to deploy crypto in lightbulbs and fully reserve my rights etc.]


From the specification point of view it sh= ould be sufficient to state that the DNS responses must be trustworthy in o= rder for the DANE key to be considered trustworthy. Trying to do anything m= ore is counterproductive.

On Fri, Jun 24, 2011 at 11:24 AM, Marti= n Rex <mrex@sap.com> wrote:
Phillip Hallam-Baker wrote:
>
> Good point, it is important to distinguish between 'DANE + DNSSEC&= #39; and DANE
> + DNS Security'.
>
> DNS Security is likely to be necessary to provide useful security in D= ANE.
> DNSSEC is only one way that may be achieved, it is not the only way.
What you really need is data end-to-end data integrity protection
plus data originiator authentication of the TLSA record from the
responsible DNS admin to the TLS client that performs the server
endpoint identification.

It would be foolish to infer from any small intermediate
hop-to-hop link going through a protected tunnel (like IPsec),
that this makes the lack of security of unsigned TLSA records
non-marginally less insecure / less dangerous.

-Martin



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

--0016368e2b7f535e9804a67ecaae-- From alangley@gmail.com Sat Jun 25 07:05:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79C121F849E for ; Sat, 25 Jun 2011 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veLXVqQyY29c for ; Sat, 25 Jun 2011 07:05:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43A0921F849D for ; Sat, 25 Jun 2011 07:05:42 -0700 (PDT) Received: by iye7 with SMTP id 7so4249617iye.31 for ; Sat, 25 Jun 2011 07:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GPl7AcYJG7vCmCpN5n2dOFjopMePQCnKKl5T5KB4w/c=; b=OIASxSEwCKiBDcdT3DyoIxP41bmoZ5Q7p3+077LxiLXpy1wTIAwoXNmzHbdlbfwvzb MtIyNHP8mDy1ZuDNSeN276yhM3l9lEtMnCQNPl+llX59UGlfKkyiFK9Y46TvttoAMOdP K6gUgVQDV/lNSr6AwBqU0Bg6CSifCRVFl6vCg= 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=BcSkgKaaTR2AtDDEn/nmmJ+k6hiCYaV4gix4YcbDUmvCxdrqMwDWi1JqM5PpwzvoQt zg0jBPm8FVKDzZILJCnNU3HGyDmighygvh+7XPmNVAhxtiEDx66utncVUbqim4fVmDRk brYo8aOjPeGx6LaxbQ1BP+H3YBO4LecBI9Gyg= MIME-Version: 1.0 Received: by 10.42.39.210 with SMTP id i18mr4855552ice.53.1309010741162; Sat, 25 Jun 2011 07:05:41 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.221.10 with HTTP; Sat, 25 Jun 2011 07:05:41 -0700 (PDT) In-Reply-To: <2053AAFB-4CE4-4E76-8E00-84A0F69B2252@bbn.com> References: <4DFBCF3D.4080509@KingsMountain.com> <2053AAFB-4CE4-4E76-8E00-84A0F69B2252@bbn.com> Date: Sat, 25 Jun 2011 10:05:41 -0400 X-Google-Sender-Auth: ByrxoNsDQ73orzooCQbJfJDSDkY Message-ID: From: Adam Langley To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 14:05:44 -0000 On Fri, Jun 24, 2011 at 5:49 PM, Richard L. Barnes wrote: > - This mechanism would actually not be implementable with DANE, because t= he "stapled" DNSSEC information is included in the cert -- including the te= rminal CAA record. =C2=A0So if DANE (protocol-07) were used instead of CAA,= then the cert would have to include a hash of itself, which is kind of an = impossibility. Although added after I wrote that code, I believe that DANE could support it without a hash cycle by using type 3: http://tools.ietf.org/html/draft-ietf-dane-protocol-07#section-2.1.1 > - These certs have subject=3D=3Dissuer=3D=3D"DNSSEC Signed". =C2=A0That b= reaks RFC 6125 rather badly, but since the certs are self-signed maybe that= 's not a big deal. I considered enforcing that the certificates have a certain form but I didn't in the end. It might still be a good idea in the future but, for now, the "DNSSEC Signed" string is just for clarity and just a convention in the example generating code. > - The DNSSEC information is held in a certificate extension. =C2=A0The fo= rmat of this extension would be a nice PKIX draft. Based on other comments from people, it does seem that a way of serialising an arbitrary DNS record with DNSSEC proof would be useful. I'll write it up at some point. Cheers AGL --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From hallam@gmail.com Sat Jun 25 09:30:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C897711E807B for ; Sat, 25 Jun 2011 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVavonUAR0EF for ; Sat, 25 Jun 2011 09:30:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDB11E8070 for ; Sat, 25 Jun 2011 09:30:33 -0700 (PDT) Received: by gya6 with SMTP id 6so146417gya.31 for ; Sat, 25 Jun 2011 09:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=obZvbMQV+ZoH6XwvzXwzzaJHkRwEgoswGyJ1dB9vxfs=; b=g4Yt3B/KkYiDU6lDey7umoQyXLE1o/xV4ZNazaV/0vh83WDL/ANmBhPbMPc5gPVxqP rEt+GAT1mIJe8Fzx8+Mvj3lRsBEJ1aUONS2sJr5Yf53bFCLq+mhN6PYQmkPYJC6uI2JR buxNwmTsUp7z53bUjMCA3y13vIbU2W9LxP+To= 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=iLjWeH7GhwO6poAPki08411Uin2o6LYUMY4FIoldQcLgBhBVRUN1rwzcb4QHAtoago LRnMmmDE1+sHofwtvmiv/wOyTkLUPrchw6xkzZlO+LmGAy402pZ72KR/X5RmgPGywcUn leDnt9IV6EkntySkMqygvSURy7dQPDYDAJtyU= MIME-Version: 1.0 Received: by 10.101.186.35 with SMTP id n35mr1290723anp.84.1309019433254; Sat, 25 Jun 2011 09:30:33 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Sat, 25 Jun 2011 09:30:33 -0700 (PDT) In-Reply-To: References: <4DFBCF3D.4080509@KingsMountain.com> <2053AAFB-4CE4-4E76-8E00-84A0F69B2252@bbn.com> Date: Sat, 25 Jun 2011 12:30:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: multipart/alternative; boundary=001636c5989652bdec04a68bd6d7 Cc: IETF DANE WG list Subject: Re: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 16:30:34 -0000 --001636c5989652bdec04a68bd6d7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 25, 2011 at 10:05 AM, Adam Langley wrote: > On Fri, Jun 24, 2011 at 5:49 PM, Richard L. Barnes > wrote: > > Based on other comments from people, it does seem that a way of > serialising an arbitrary DNS record with DNSSEC proof would be useful. > I'll write it up at some point. > Very much so for CAA as DNSSEC only adds value to CAA if the CAs have a means of archiving the DNSSEC chain on the CAA record that they claim gave them authorization. If this is a standard we could imagine a scheme in which CAs keep the pickled DNSSEC-CAA chain in a public repository. A big concern for me is that I recently heard a report of an organization that I presume to be a national security team attempting to compromise a trusted third party through extortion. The only reliable security control in such circumstances is multi-party control with non-repudiable audit logs of all activity. -- Website: http://hallambaker.com/ --001636c5989652bdec04a68bd6d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jun 25, 2011 at 10:05 AM, Adam Langley <agl@imperialviolet.org> w= rote:
On Fri, Jun 24, 2011 at 5:49 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
=A0
Based on other comments from people, it does seem that a way of
serialising an arbitrary DNS record with DNSSEC proof would be useful.
I'll write it up at some point.

Very much so for CAA as DNSSEC only adds value to CAA if the CAs have a me= ans of archiving the DNSSEC chain on the CAA record that they claim gave th= em authorization.

If this is a standard we could imagine a scheme in which CAs= keep the pickled DNSSEC-CAA chain in a public repository.=A0

A big concern for me is that I recently heard a = report of an organization that I presume to be a national security team att= empting to compromise a trusted third party through extortion.=A0

The only reliable security control in such circumstance= s is multi-party control with non-repudiable audit logs of all activity.

--001636c5989652bdec04a68bd6d7-- From Jeff.Hodges@KingsMountain.com Sat Jun 25 17:59:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90AA11E80CC for ; Sat, 25 Jun 2011 17:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6GDNUG5ED9b for ; Sat, 25 Jun 2011 17:59:54 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 140AE11E8080 for ; Sat, 25 Jun 2011 17:59:53 -0700 (PDT) Received: (qmail 17280 invoked by uid 0); 26 Jun 2011 00:59:52 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 26 Jun 2011 00:59:52 -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=U4i0EPAN7RqwTI+BFwIDgq1fC6AE4RhlXix156xpgtyEhLimN2vcO9w/Z9vg7NKb45lRFUy8vg8e8h5eEw9fKcCJFZGnHQ0bLWtaEeGHhVHopw34qINhLEWXRjX5PeIb; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QadhY-00058A-Gh for dane@ietf.org; Sat, 25 Jun 2011 18:59:52 -0600 Message-ID: <4E068487.90902@KingsMountain.com> Date: Sat, 25 Jun 2011 17:59:51 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list 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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 00:59:54 -0000 "Richard L. Barnes" said: > > > - These certs have subject==issuer=="DNSSEC Signed". That breaks RFC 6125 > rather badly, but since the certs are self-signed maybe that's not a big > deal. it doesn't break RFC 6125 at all because self-signed certs are explicitly out-of-scope for RFC 6125. see.. [4th bullet] > - The DNSSEC information is held in a certificate extension. The format of > this extension would be a nice PKIX draft. indeed. =JeffH From stpeter@stpeter.im Sat Jun 25 18:54:36 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D99711E80CC for ; Sat, 25 Jun 2011 18:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4yU3xlOoK68 for ; Sat, 25 Jun 2011 18:54:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0811E8099 for ; Sat, 25 Jun 2011 18:54:35 -0700 (PDT) Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 972914032B; Sat, 25 Jun 2011 19:55:24 -0600 (MDT) Message-ID: <4E069159.2030608@stpeter.im> Date: Sat, 25 Jun 2011 19:54:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =JeffH References: <4E068487.90902@KingsMountain.com> In-Reply-To: <4E068487.90902@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 01:54:36 -0000 +1 to what Jeff said. On 6/25/11 6:59 PM, =JeffH wrote: > "Richard L. Barnes" said: >> >> >> - These certs have subject==issuer=="DNSSEC Signed". That breaks RFC > 6125 >> rather badly, but since the certs are self-signed maybe that's not a big >> deal. > > it doesn't break RFC 6125 at all because self-signed certs are > explicitly out-of-scope for RFC 6125. see.. > > [4th bullet] > > >> - The DNSSEC information is held in a certificate extension. The > format of >> this extension would be a nice PKIX draft. > > indeed. From matt@mattmccutchen.net Sat Jun 25 20:31:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2E011E8096 for ; Sat, 25 Jun 2011 20:31: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx62fH7gOb6M for ; Sat, 25 Jun 2011 20:31:44 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 929E811E8085 for ; Sat, 25 Jun 2011 20:31:44 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 79028598074; Sat, 25 Jun 2011 20:31:43 -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=ObyBzUfNJ/b+n0YXH9Rqvq8NQkn/SIly/M054Agrugt 1xnsFbibbxOuStAByi3SXdZiSxtWVL6cjXrXCVJsOBQ1Tk0x8CgzfykNRPAMO/hI VC26tCAJbHA/2j8H7/fb+0DRiwXmIYGIJLGMRVHtKxwPIPMrmxuui+aF2QjSLONA = 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=lsAgL7IFtpNirpJS4fIBUBrjmjs=; b=HaZGu7u1fr RHwy/tbL+UJIrXpztg7mzhczuT7VuiPBMacc3vxf1a7JiifIiIdRne1swAJT86sQ WANbyR5pLyey/L2BS677kdfbJ9rqHSLCwDebfanM/enlsUf1QsMSa6mdsJ47xhPX UZPcqDaIbSgnKm1J0dgJbYIsu2AFZwGlA= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id C7E8C598070; Sat, 25 Jun 2011 20:31:42 -0700 (PDT) From: Matt McCutchen To: "Richard L. Barnes" In-Reply-To: <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <1305302244.3471.21.camel@localhost> <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 25 Jun 2011 23:31:34 -0400 Message-ID: <1309059094.2118.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: [dane] (Matt's comments unaddressed in draft-ietf-dane-use-cases-03) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 03:31:45 -0000 On Fri, 2011-06-24 at 11:19 -0400, Richard L. Barnes wrote: > > - The security considerations in Section 3.1 could be clarified. Here > > is some alternative text as inspiration: > > I think this comment is addressed by the revised security > considerations in 3.1. They're not quite as detailed as your > suggested text, but they capture the basic bounds of the problem. I wouldn't consider my text more detailed, but rather more precisely stated and free of controversial side remarks. E.g., what does "increase the scope of PKIX-based assertions about domains" mean, and what does it mean for there to "be" a strict requirement for DNSSEC? If I weren't already deeply engaged in the WG, I would probably have to come to my own understanding of the situation and then realize that was what you were talking about. Compare to "Because these constraints do not increase the set of cases in which server authentication succeeds, no security is lost by processing the records even if they are retrieved without DNSSEC," where the logic of the implication is clear. Why ever would we not use the more precise text? > > - This text does not belong in Section 3.3: > > > > Deleted records > > will only result in connection failure and denial of service, > > although this could result in clients re-connecting without TLS (a > > downgrade attack), depending on the application. Therefore, in order > > for this use case to be safe, applications must forbid clients from > > falling back to unsecured channels when records appear to have been > > deleted (e.g., when a missing record has no NSEC or NSEC3 record). > > > > Preventing a downgrade from TLS to non-TLS is, strictly speaking, an > > orthogonal issue to TLS server authentication. My understanding was > > that the scope of DANE was only the latter, and the former would be > > addressed with HASTLS or some such. If the downgrade prevention is to > > be mentioned here, it should be its own use case; it is not in any way > > specific to the use of domain-issued certificates. > > You're correct that downgrade is an issue that applications need to > address, but it is something that DANE should keep in mind. I think > the solution is pretty simple -- just require the use of NSEC/NSEC3, > which is already standard practice for DNSSEC. "Downgrade" is not a single issue, but rather an issue to be considered in the context of each mechanism. The scope of DANE is acceptance testing of TLS server credentials, including downgrade prevention for that process. Choice of TLS or non-TLS, including downgrade prevention for that process, is out of scope of DANE and will most likely be addressed by HASTLS. It sounds like your concern here is that if an attacker deletes a positive DANE assertion, the client may consider the TLS service broken and fall back to non-TLS. But there's a much more basic attack: intercept the TLS connection and replace the certificate with a completely bogus one, or flip some bits so the record MAC fails, or whatever. Clients that fall back to non-TLS on a TLS failure are vulnerable to downgrade, period; this has nothing whatsoever to do with DANE. If you want to discuss downgrade of TLS server authentication, deletion of positive assertions isn't it: it reduces the set of cases in which server authentication succeeds. Deletion of restrictive assertions (sections 3.1 and 3.2) is. But referring to NSEC/NSEC3 is a gratuitous violation of abstraction; instead, refer to an RFC 4033 "insecure" response as distinguished from "bogus", as in my text. > > - Re the newfound power of DNSSEC zone operators under DANE (Section > > 3.3): I would not attempt to minimize this issue. CAs will not hesitate > > to remind us of the extra checks they perform for certain sites, so the > > comparison to domain validation is not entirely correct. Sites that > > have special relationships with CAs but do not have proper oversight of > > their DNSSEC zones will, indeed, have their security weakened when > > clients adopt DANE. If we are concerned about this, I think the natural > > solution is to have a flag with each DNSSEC delegation that indicates > > that the registrant fully trusts the child zone operator and hence > > schemes such as DANE can be enabled. > > I've tried to moderate this section in the new version, in particular: > " > It should be noted that DNS operators already have the ability to obtain certificates for domains under their control, under certain CA policies. > " But for traditional "high-value domains", none of the public CAs would apply those policies (or at least so they would have us think), so the potential for weakening of security is real. > > - Section 3.4: I don't understand the motivation for constraining the > > certificates used by an outsourcing provider. If the provider is > > operating the service, what security benefit can there be to forcing the > > provider to use a particular certificate? Is this something I missed in > > the discussion? > > Couple of examples: > - Alice is concerned that Oscar might use a certificate that contains > a public key for which a third party (police, criminal associates) > also has the private keys, as a way of indirectly exposing Alice's > traffic. > - Alice is concerned that Oscar might use a certificate that contains > a public key that uses a weaker cryptographic algorithm than Alice > requires (say 1024-bit instead of 2048-bit RSA). Is Alice concerned that Oscar might post the master secret on his web site? If Oscar wants to compromise the session, Alice cannot stop him. > - Alice is concerned that Oscar present a DV cert instead of the EV > cert she provided him. What attack is prevented by requiring Oscar to use the EV cert? DANE is about security. If what Alice wants is to meddle in Oscar's operations, she can operate the DNS zone. -- Matt From hallam@gmail.com Sat Jun 25 21:18:21 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8A11E8080 for ; Sat, 25 Jun 2011 21:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G475u3vvHdOj for ; Sat, 25 Jun 2011 21:18:19 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD2B11E8072 for ; Sat, 25 Jun 2011 21:18:19 -0700 (PDT) Received: by yie30 with SMTP id 30so2296714yie.31 for ; Sat, 25 Jun 2011 21:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FapbBaUDqF/KTAMNM6aSJ9SHAYl7mNXNF8AM564Rx/8=; b=ZxwlDX003d39oD5rZuwJpWBxqqRa3e7+vpjZOBsSaDzEVawSJCpTYiXoxIHjdTIeD5 DCdW3ronLluFFResdSvkE7pN8udbchn536Ym0QNvax0075jzEl8XD40+3xnHPI+r0nO5 6OQ9kD5/pASRsDgHUetTRSsL66CH8JREBai8I= 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=ZztDeVPIEfJgqnuhH9nptslLjSdFGvBgyHzIrPtsSgr6cr8/7uqU/PKD40Yz5Y3NTE L6+zDBzVl9xfbG/gS/PZIUWgA4eD0lYmdcQ1VjgUuPyv3TKWYu0zzg0EQMBpH6nUZLyk QDkQ8SQ4WU8INPg7AE7fje9R21x0stuhzCZH4= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr5265265anh.40.1309061897213; Sat, 25 Jun 2011 21:18:17 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Sat, 25 Jun 2011 21:18:17 -0700 (PDT) In-Reply-To: <1309059094.2118.31.camel@localhost> References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <1305302244.3471.21.camel@localhost> <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> <1309059094.2118.31.camel@localhost> Date: Sun, 26 Jun 2011 00:18:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016369fa2525f566004a695b92e Cc: dane Subject: Re: [dane] (Matt's comments unaddressed in draft-ietf-dane-use-cases-03) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 04:18:21 -0000 --0016369fa2525f566004a695b92e Content-Type: text/plain; charset=ISO-8859-1 If we are choosing between mechanism A and mechanism B the ability of mechanism A to support use cases that are out of scope while B is intentionally limited to scope has me thinking we should go for A. Thus I don't see the validity of an argument that goes 'yes we know there is more to downgrade than use of TLS but we are only going to address that one issue that is in scope and do so in a way that cannot be extended to solve the whole problem'. As an adopter I would look at a DANE spec that only does half the job and say 'no thank you' because I know that adopting it is a dead end that is not going to lead to a full solution. We have the following options to address downgrade attack 1) Only do prevention of TLS downgrade as proposed in a way that cannot be extended. 2) Not do it at all but leave an extension mechanism that allows other aspects to be addressed later on. 3) Only do prevention of TLS downgrade as proposed but have an extension mechanism 4) Do the full downgrade problem including an extension mechanism. The most expeditious approach is 2 since all we have to do is convince ourselves we can address it later. Options 2,3,4 all allow the job to be done properly. On Sat, Jun 25, 2011 at 11:31 PM, Matt McCutchen wrote: > On Fri, 2011-06-24 at 11:19 -0400, Richard L. Barnes wrote: > > > - The security considerations in Section 3.1 could be clarified. Here > > > is some alternative text as inspiration: > > > > I think this comment is addressed by the revised security > > considerations in 3.1. They're not quite as detailed as your > > suggested text, but they capture the basic bounds of the problem. > > I wouldn't consider my text more detailed, but rather more precisely > stated and free of controversial side remarks. E.g., what does > "increase the scope of PKIX-based assertions about domains" mean, and > what does it mean for there to "be" a strict requirement for DNSSEC? If > I weren't already deeply engaged in the WG, I would probably have to > come to my own understanding of the situation and then realize that was > what you were talking about. Compare to "Because these constraints do > not increase the set of cases in which server authentication succeeds, > no security is lost by processing the records even if they are retrieved > without DNSSEC," where the logic of the implication is clear. > > Why ever would we not use the more precise text? > > > > - This text does not belong in Section 3.3: > > > > > > Deleted records > > > will only result in connection failure and denial of service, > > > although this could result in clients re-connecting without TLS (a > > > downgrade attack), depending on the application. Therefore, in order > > > for this use case to be safe, applications must forbid clients from > > > falling back to unsecured channels when records appear to have been > > > deleted (e.g., when a missing record has no NSEC or NSEC3 record). > > > > > > Preventing a downgrade from TLS to non-TLS is, strictly speaking, an > > > orthogonal issue to TLS server authentication. My understanding was > > > that the scope of DANE was only the latter, and the former would be > > > addressed with HASTLS or some such. If the downgrade prevention is to > > > be mentioned here, it should be its own use case; it is not in any way > > > specific to the use of domain-issued certificates. > > > > You're correct that downgrade is an issue that applications need to > > address, but it is something that DANE should keep in mind. I think > > the solution is pretty simple -- just require the use of NSEC/NSEC3, > > which is already standard practice for DNSSEC. > > "Downgrade" is not a single issue, but rather an issue to be considered > in the context of each mechanism. The scope of DANE is acceptance > testing of TLS server credentials, including downgrade prevention for > that process. Choice of TLS or non-TLS, including downgrade prevention > for that process, is out of scope of DANE and will most likely be > addressed by HASTLS. > > It sounds like your concern here is that if an attacker deletes a > positive DANE assertion, the client may consider the TLS service broken > and fall back to non-TLS. But there's a much more basic attack: > intercept the TLS connection and replace the certificate with a > completely bogus one, or flip some bits so the record MAC fails, or > whatever. Clients that fall back to non-TLS on a TLS failure are > vulnerable to downgrade, period; this has nothing whatsoever to do with > DANE. > > If you want to discuss downgrade of TLS server authentication, deletion > of positive assertions isn't it: it reduces the set of cases in which > server authentication succeeds. Deletion of restrictive assertions > (sections 3.1 and 3.2) is. But referring to NSEC/NSEC3 is a gratuitous > violation of abstraction; instead, refer to an RFC 4033 "insecure" > response as distinguished from "bogus", as in my text. > > > > - Re the newfound power of DNSSEC zone operators under DANE (Section > > > 3.3): I would not attempt to minimize this issue. CAs will not > hesitate > > > to remind us of the extra checks they perform for certain sites, so the > > > comparison to domain validation is not entirely correct. Sites that > > > have special relationships with CAs but do not have proper oversight of > > > their DNSSEC zones will, indeed, have their security weakened when > > > clients adopt DANE. If we are concerned about this, I think the > natural > > > solution is to have a flag with each DNSSEC delegation that indicates > > > that the registrant fully trusts the child zone operator and hence > > > schemes such as DANE can be enabled. > > > > I've tried to moderate this section in the new version, in particular: > > " > > It should be noted that DNS operators already have the ability to obtain > certificates for domains under their control, under certain CA policies. > > " > > But for traditional "high-value domains", none of the public CAs would > apply those policies (or at least so they would have us think), so the > potential for weakening of security is real. > > > > - Section 3.4: I don't understand the motivation for constraining the > > > certificates used by an outsourcing provider. If the provider is > > > operating the service, what security benefit can there be to forcing > the > > > provider to use a particular certificate? Is this something I missed > in > > > the discussion? > > > > Couple of examples: > > - Alice is concerned that Oscar might use a certificate that contains > > a public key for which a third party (police, criminal associates) > > also has the private keys, as a way of indirectly exposing Alice's > > traffic. > > - Alice is concerned that Oscar might use a certificate that contains > > a public key that uses a weaker cryptographic algorithm than Alice > > requires (say 1024-bit instead of 2048-bit RSA). > > Is Alice concerned that Oscar might post the master secret on his web > site? If Oscar wants to compromise the session, Alice cannot stop him. > > > - Alice is concerned that Oscar present a DV cert instead of the EV > > cert she provided him. > > What attack is prevented by requiring Oscar to use the EV cert? > > DANE is about security. If what Alice wants is to meddle in Oscar's > operations, she can operate the DNS zone. > > -- > Matt > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016369fa2525f566004a695b92e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we are choosing between mechanism A and mechanism B the ability of mecha= nism A to support use cases that are out of scope while B is intentionally = limited to scope has me thinking we should go for A.

Thus I don't see the validity of an argument that goes 'yes we know= there is more to downgrade than use of TLS but we are only going to addres= s that one issue that is in scope and do so in a way that cannot be extende= d to solve the whole problem'.


As an adopter I would look at a DANE spe= c that only does half the job and say 'no thank you' because I know= that adopting it is a dead end that is not going to lead to a full solutio= n.

We have the following options to address downgrade atta= ck

1) Only do prevention of TLS downgrade as propo= sed in a way that cannot be extended.

2) Not do it= at all but leave an extension mechanism that allows other aspects to be ad= dressed later on.

3)=A0Only do prevention of TLS downgrade as proposed bu= t have an extension mechanism

4) Do the full downg= rade problem including an extension mechanism.

The most expeditious approach is 2 since all we have to do is co= nvince ourselves we can address it later.

Options = 2,3,4 all allow the job to be done properly.


On Sat, Jun 25, 2011 at 11:31 PM, Matt McCut= chen <matt@m= attmccutchen.net> wrote:
On Fri, 2011-06-24 at 11:19 -0400, Richard L. Barnes wrote:
> > - The security considerations in Section 3.1 could be clarified. = =A0Here
> > is some alternative text as inspiration:
>
> I think this comment is addressed by the revised security
> considerations in 3.1. =A0They're not quite as detailed as your > suggested text, but they capture the basic bounds of =A0the problem.
I wouldn't consider my text more detailed, but rather more precisely stated and free of controversial side remarks. =A0E.g., what does
"increase the scope of PKIX-based assertions about domains" mean,= and
what does it mean for there to "be" a strict requirement for DNSS= EC? =A0If
I weren't already deeply engaged in the WG, I would probably have to come to my own understanding of the situation and then realize that was
what you were talking about. =A0Compare to "Because these constraints = do
not increase the set of cases in which server authentication succeeds,
no security is lost by processing the records even if they are retrieved without DNSSEC," where the logic of the implication is clear.

Why ever would we not use the more precise text?

> > - This text does not belong in Section 3.3:
> >
> > =A0 Deleted records
> > =A0 will only result in connection failure and denial of service,=
> > =A0 although this could result in clients re-connecting without T= LS (a
> > =A0 downgrade attack), depending on the application. =A0Therefore= , in order
> > =A0 for this use case to be safe, applications must forbid client= s from
> > =A0 falling back to unsecured channels when records appear to hav= e been
> > =A0 deleted (e.g., when a missing record has no NSEC or NSEC3 rec= ord).
> >
> > Preventing a downgrade from TLS to non-TLS is, strictly speaking,= an
> > orthogonal issue to TLS server authentication. =A0My understandin= g was
> > that the scope of DANE was only the latter, and the former would = be
> > addressed with HASTLS or some such. =A0If the downgrade preventio= n is to
> > be mentioned here, it should be its own use case; it is not in an= y way
> > specific to the use of domain-issued certificates.
>
> You're correct that downgrade is an issue that applications need t= o
> address, but it is something that DANE should keep in mind. =A0I think=
> the solution is pretty simple -- just require the use of NSEC/NSEC3, > which is already standard practice for DNSSEC.

"Downgrade" is not a single issue, but rather an issue to be cons= idered
in the context of each mechanism. =A0The scope of DANE is acceptance
testing of TLS server credentials, including downgrade prevention for
that process. =A0Choice of TLS or non-TLS, including downgrade prevention for that process, is out of scope of DANE and will most likely be
addressed by HASTLS.

It sounds like your concern here is that if an attacker deletes a
positive DANE assertion, the client may consider the TLS service broken
and fall back to non-TLS. =A0But there's a much more basic attack:
intercept the TLS connection and replace the certificate with a
completely bogus one, or flip some bits so the record MAC fails, or
whatever. =A0Clients that fall back to non-TLS on a TLS failure are
vulnerable to downgrade, period; this has nothing whatsoever to do with
DANE.

If you want to discuss downgrade of TLS server authentication, deletion
of positive assertions isn't it: it reduces the set of cases in which server authentication succeeds. =A0Deletion of restrictive assertions
(sections 3.1 and 3.2) is. =A0But referring to NSEC/NSEC3 is a gratuitous violation of abstraction; instead, refer to an RFC 4033 "insecure"= ;
response as distinguished from "bogus", as in my text.

> > - Re the newfound power of DNSSEC zone operators under DANE (Sect= ion
> > 3.3): I would not attempt to minimize this issue. =A0CAs will not= hesitate
> > to remind us of the extra checks they perform for certain sites, = so the
> > comparison to domain validation is not entirely correct. =A0Sites= that
> > have special relationships with CAs but do not have proper oversi= ght of
> > their DNSSEC zones will, indeed, have their security weakened whe= n
> > clients adopt DANE. =A0If we are concerned about this, I think th= e natural
> > solution is to have a flag with each DNSSEC delegation that indic= ates
> > that the registrant fully trusts the child zone operator and henc= e
> > schemes such as DANE can be enabled.
>
> I've tried to moderate this section in the new version, in particu= lar:
> "
> It should be noted that DNS operators already have the ability to obta= in certificates for domains under their control, under certain CA policies.=
> "

But for traditional "high-value domains", none of the public CAs = would
apply those policies (or at least so they would have us think), so the
potential for weakening of security is real.

> > - Section 3.4: I don't understand the motivation for constrai= ning the
> > certificates used by an outsourcing provider. =A0If the provider = is
> > operating the service, what security benefit can there be to forc= ing the
> > provider to use a particular certificate? =A0Is this something I = missed in
> > the discussion?
>
> Couple of examples:
> - Alice is concerned that Oscar might use a certificate that contains<= br> > a public key for which a third party (police, criminal associates)
> also has the private keys, as a way of indirectly exposing Alice's=
> traffic.
> - Alice is concerned that Oscar might use a certificate that contains<= br> > a public key that uses a weaker cryptographic algorithm than Alice
> requires (say 1024-bit instead of 2048-bit RSA).

Is Alice concerned that Oscar might post the master secret on his web
site? =A0If Oscar wants to compromise the session, Alice cannot stop him.
> - Alice is concerned that Oscar present a DV cert instead of the EV > cert she provided him.

What attack is prevented by requiring Oscar to use the EV cert?

DANE is about security. =A0If what Alice wants is to meddle in Oscar's<= br> operations, she can operate the DNS zone.

--
Matt

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016369fa2525f566004a695b92e-- From matt@mattmccutchen.net Sun Jun 26 08:54:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922EC21F84E2 for ; Sun, 26 Jun 2011 08:54:48 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrRMvmpOaLQ6 for ; Sun, 26 Jun 2011 08:54:47 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C87AB21F84DF for ; Sun, 26 Jun 2011 08:54:47 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 0365170406F; Sun, 26 Jun 2011 08:54:47 -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=QVd4xQ6zBM6hh5yr9DIh2twhVi+PLSPUwf5pAn9sgB9 Y+fXgrZGYIBMhYv9c710tq0agTdfS9pZKVYjD3JnF0tfDQaOiHWPJibS7KCY0Gcq Q1FDOjc2KXllSnu4ODhTbe6bfWuQF0n4HRIIFz/orTtpNrzXjLxhIXEzEsG8YrSY = 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=e9/7FS7GOANlylAn2xeMOqzdR/4=; b=Bibmxm8kZr ICW7Q/b2SKVqJVvokWW/efAR2QZ0dgnErgz9NuZ0ouzoQWX40WY3oB0gBVJI5t0j UUUUiYTZW+4iP8n4Wc1bKfEc3SwShzLycD4Zl1zZGstHM6V1ROd1Ac4UjCaGSlBC 7Y9IZQpqyOrjl195rHKNBPl1Qhg90nKRI= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 8FC3D70406A; Sun, 26 Jun 2011 08:54:46 -0700 (PDT) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <20110429041501.6901.77699.idtracker@ietfa.amsl.com> <37FB7C67-CE3B-42AE-A62D-7B20460978FA@kumari.net> <1305302244.3471.21.camel@localhost> <0498F0AB-0C54-4227-B6DF-EA8316AFD731@bbn.com> <1309059094.2118.31.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 11:12:06 -0400 Message-ID: <1309101126.2118.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] (Matt's comments unaddressed in draft-ietf-dane-use-cases-03) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 15:54:48 -0000 On Sun, 2011-06-26 at 00:18 -0400, Phillip Hallam-Baker wrote: > If we are choosing between mechanism A and mechanism B the ability of > mechanism A to support use cases that are out of scope while B is > intentionally limited to scope has me thinking we should go for A. > > Thus I don't see the validity of an argument that goes 'yes we know > there is more to downgrade than use of TLS I think you mean "choice of TLS certificates". > but we are only going to address that one issue that is in scope and > do so in a way that cannot be extended to solve the whole problem'. In most of the "general use" clients DANE is primarily designed to support, the decision to use TLS is decoupled from the decision of what server certificates to accept. E.g., in a web browser, the use of TLS is specified by the "https" URI scheme. The division of work between DANE and HASTLS simply mirrors this aspect of application design. What makes you think that the whole problem has to be solved by a single measure? Consider this analogy: to prevent your office from being burglarized, you have to close and lock the door, but the door closer and the lock are different devices. > As an adopter I would look at a DANE spec that only does half the job > and say 'no thank you' because I know that adopting it is a dead end > that is not going to lead to a full solution. Nonsense. Adopting DANE will already protect users who have bookmarked a "https" URI (or the equivalent in other applications), as I generally do. When HASTLS gets standardized, you can just add another record to your zone to advertise the availability of TLS and encourage its use. You can call HASTLS an extension of DANE if you like; it doesn't matter, the outcome is the same. -- Matt From paul@xelerance.com Sun Jun 26 10:02:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E1321F84C3 for ; Sun, 26 Jun 2011 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIwE62GOR5ix for ; Sun, 26 Jun 2011 10:02:45 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 067C821F84BB for ; Sun, 26 Jun 2011 10:02:40 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 45800570E3; Sun, 26 Jun 2011 13:02:39 -0400 (EDT) Date: Sun, 26 Jun 2011 13:02:39 -0400 (EDT) From: Paul Wouters To: Adam Langley In-Reply-To: Message-ID: References: <4DFBCF3D.4080509@KingsMountain.com> <2053AAFB-4CE4-4E76-8E00-84A0F69B2252@bbn.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DANE WG list Subject: Re: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 17:02:45 -0000 On Sat, 25 Jun 2011, Adam Langley wrote: >> - The DNSSEC information is held in a certificate extension.  The format of this extension would be a nice PKIX draft. > > Based on other comments from people, it does seem that a way of > serialising an arbitrary DNS record with DNSSEC proof would be useful. > I'll write it up at some point. While doing a negotiation where both parties present their dnssec signed chain from the root down to their first common trusted ancestor is a good that idea that has been floating around for a while, encapsulating this in PKIX and storing it at CA's as PHB suggests seems to like a terrible idea. DNS(SEC) assumes properties based on TTL and RRSIG expiry. Mixing those up with PKIX signatures and offline storage could only lead to ignoring dnssec validated properties. While I encourage the use of DNSSEC as a bandaid for PKIX, it is important to realise a bandaid is no replacement for proper care. Paul ps. The first I heard of this was when Michael Richardson proposed two offline devices could exchange their DNSSEC chain from the root to themselves . They would be able to validate each other by receiving each others chain to (at worst) the commonly trusted root. Andrew encouraged me to write a draft in my copious spare time, which alas, has not happened. From matt@mattmccutchen.net Sun Jun 26 12:11:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECB1F0C39; Sun, 26 Jun 2011 12:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h40FExey13tb; Sun, 26 Jun 2011 12:11:57 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3055E1F0C38; Sun, 26 Jun 2011 12:11:47 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 39D38284071; Sun, 26 Jun 2011 12:11:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=eYxggq7 63X/JJVRc3Pq4OCxlM7yaEKZQVbpn6jcHoHduWf7azTWgeQr+KOYdDP7EINsCmCT Mw9eGTHoxFMykI1sb9+4baqsWV5svi0W/hU0FgrKCH7o4TEhEpzN6AfiT3Da5jq/ 558rGxuUntiQa9R7V5Uyg6GLoDIxJUAlx7G0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=zlh2sipIG+SYg grEMp7lYMBPW/g=; b=IxgM/NoOnuunhzErkA5UQQ0kfWlQAkXN2Qf8IzmaXnKWG RRq0O0OUQRAkgSl9LsvYoAiVq6vWGmXCR5KLtj6C2Qmd+eIdwtlO0tHiyg6DybMV jlbzUNT/I09Uy9VMoXGh0T8sspnrJEvkvlMtxbNOpOkHb+wYK+6Korm6el4FXI= Received: from [192.168.1.41] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id A8FC928406E; Sun, 26 Jun 2011 12:11:46 -0700 (PDT) From: Matt McCutchen To: dnsext@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 15:11:44 -0400 Message-ID: <1309115504.2118.69.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: [dane] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 19:11:58 -0000 DNSSEC folks, I'm looking forward to DANE positive assertions making TLS server deployment significantly more convenient. More generally, DNSSEC holds enormous potential utility as a repository of integrity-protected authoritative information about DNS names, including configuration for new opt-in security schemes. However, each of these schemes may increase the degree of exposure to malfeasance by the DNS operator (who may not be the same entity as the authoritative holder of the domain) in some or all cases, compared to traditional practice. Proper governance of DNSSEC data to ensure that it reflects authoritative intent is essential to be able to use these schemes and realize their compelling benefits. I would much rather resolve this issue once in a principled way than come to an unsatisfactory compromise in the context of each individual scheme. Is it viable to put registrants with signed zones on notice that clients will begin to assume the data is fully authoritative, and give them a deadline by which they should establish proper governance or revert the zone to unsigned? Alternatively, do we want a flag in the DS record (which can only be set by the parent at the registrant's request) that indicates the data is fully authoritative? Note well, I propose only to enable the ascription of strong security semantics to new RR types (or subtypes) such as DANE's TLSA and not to ascribe new semantics to existing types such as CNAME or CERT, because then signing a zone could suddenly introduce vulnerabilities. -- Matt From matt@mattmccutchen.net Sun Jun 26 14:05:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1718C21F84CE; Sun, 26 Jun 2011 14:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo91xHyJsZcm; Sun, 26 Jun 2011 14:05:43 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 599B121F84CD; Sun, 26 Jun 2011 14:05:43 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 0BD3F51C063; Sun, 26 Jun 2011 14:05:43 -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=J1S7A4DNIrqA77YCw5MApnSnCt4lYpNn5Iy857JbdB+ cMpf2WOLo1vbZKFoYwDJQrxnISeeZ9pHAW5DP1v2fUYLY/74wK+ujYgc4PB3x2kV cLMsKPRHJEr0/j6ExufJ67ZtNQaS5ZVSM9XVnTtEL0ZGQSGx5EnxF0A3Zpp1CWDo = 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=+gnhmUv8Rcdjh0pk8T99lXkFLTM=; b=MAENB3J5Wb Y36ppFyGkNfkYbqxy5Pdd59siaPIgg2SrE2ybLx9/VJbVVp2H13yUC0JRMJ1JB9L ok8sH6EpkCDVt4XMV6NWqxlYBt9iAhCoQoTtXE1gWxixdZcMRFjSvYGXDXKJTgUs Vo+UKyk38OUhyQatBN1VPPOVSYTO0ULm0= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 7619C51C062; Sun, 26 Jun 2011 14:05:42 -0700 (PDT) From: Matt McCutchen To: John Levine In-Reply-To: <20110626204351.14432.qmail@joyce.lan> References: <20110626204351.14432.qmail@joyce.lan> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 17:05:38 -0400 Message-ID: <1309122338.2118.82.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:05:44 -0000 On Sun, 2011-06-26 at 20:43 +0000, John Levine wrote: > > However, each of these schemes may increase the degree of exposure > > to malfeasance by the DNS operator (who may not be the same entity > > as the authoritative holder of the domain) in some or all cases, > > compared to traditional practice. > > Current practice for SSL signers is to scrape e-mail addresses from > the domain's WHOIS, and send a confirmation message with a URL the > applicant clicks on. It's hard for me to imagine a process more > dependent on the DNS than that. Not if you asked for paypal.com. We already went through this on the dane list (https://www.ietf.org/mail-archive/web/dane/current/msg02736.html). > > Is it viable to put registrants with signed zones on notice that > > clients will begin to assume the data is fully authoritative, and > > give them a deadline by which they should establish proper > > governance or revert the zone to unsigned? > > I think the answer to this question is "no". Let's say, I'm the > registrant of examp1e.com. A strange example, given that the schemes I'm talking about address only the security of interactions with a DNS name given as input and not how the name is chosen, but sure. > What, exactly, am I supposed to do to > persuade the registrar and/or registry that I have established proper > governance. Or if I suspect that someone else's zone is improperly > governed, how do I denounce them, and to whom? Maybe the question wasn't clear. The registrant (in effect, the holder of the login information with the registrar, or the WHOIS contacts) is authoritative for the zone. The question is whether the zone data carries the full authority of the registrant. If she says it does, it does. I.e., this would be a box you check on the registrar control panel, next to where you enter the DS records. Suppose you're the registrant of myhighvaluesite.com and have special agreements with your registrar and all the public CAs so they visit your headquarters before doing anything to your domain. To cut costs, you outsource the DNS to your friend. You figure you might as well enable DNSSEC too. But now if clients start to accept DANE positive assertions, your friend can MITM your customers. With my proposal, clients would not accept positive assertions from your zone unless and until you ask your registrar to check the box, and you wouldn't do that unless you were using a DNSSEC service provider you fully trust with your site. -- Matt From matt@mattmccutchen.net Sun Jun 26 14:11:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BBD21F84CE; Sun, 26 Jun 2011 14:11:22 -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.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwT5k19x5kPZ; Sun, 26 Jun 2011 14:11:22 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9E21F84C8; Sun, 26 Jun 2011 14:11:21 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 945CC70406E; Sun, 26 Jun 2011 14:11:21 -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=oi6czgdgVmkeg+zab+e340liuc+Hls2SeJ9roSGX6Zv +X5DerCHme7/bfGJmIpBb5/goOJogsRMKfXmYY+4Awbbm9nFdFpXdWNGg65GhWQw hnbycOG5qyQHGFIVp+LAMQLJG/gOWibHcTloJYGBeLqnkQ2X1MWW0Gqsdy+oKlz4 = 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=y7eLjxlB0r12mStnu+MJI8TDdeI=; b=LzKlT+2W2G ezrzMT/t8MJ7qAtP2C/iKUEgXACMXHBEEn8i3ll9pbsHijBd9hvsUSQMUAiOLcmd gg5K2DCCWz56ngsSfL00scZHN/D/oS1LjzZISDS4+a+ct+LdpYpDSwsCOaPAdA3l ujwSd+IB9L5HaUPUDnUdFxXdwTkJfvL24= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id D769270406A; Sun, 26 Jun 2011 14:11:20 -0700 (PDT) From: Matt McCutchen To: John Levine In-Reply-To: <1309122338.2118.82.camel@localhost> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 17:11:18 -0400 Message-ID: <1309122678.2118.85.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:11:23 -0000 On Sun, 2011-06-26 at 17:05 -0400, Matt McCutchen wrote: > Maybe the question wasn't clear. The registrant (in effect, the holder > of the login information with the registrar, or the WHOIS contacts) is > authoritative for the zone. The question is whether the zone data > carries the full authority of the registrant. If she says it does, it > does. I.e., this would be a box you check on the registrar control > panel, next to where you enter the DS records. > > Suppose you're the registrant of myhighvaluesite.com and have special > agreements with your registrar and all the public CAs so they visit your > headquarters before doing anything to your domain. To cut costs, you > outsource the DNS to your friend. You figure you might as well enable > DNSSEC too. But now if clients start to accept DANE positive > assertions, your friend can MITM your customers. > > With my proposal, clients would not accept positive assertions from your > zone unless and until you ask your registrar to check the box, and you > wouldn't do that unless you were using a DNSSEC service provider you > fully trust with your site. To restate my question: is an opt-in process necessary, or could we just give registrants with signed zones a deadline to get their house in order? If it is necessary, is what I described viable? Is there an alternative? Otherwise we'll never realize the full benefit of DNSSEC. -- Matt From johnl@taugh.com Sun Jun 26 14:31:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0771F0C39 for ; Sun, 26 Jun 2011 14:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Bo7rdlCWOI for ; Sun, 26 Jun 2011 14:31:08 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C40DE1F0C36 for ; Sun, 26 Jun 2011 14:31:07 -0700 (PDT) Received: (qmail 61168 invoked from network); 26 Jun 2011 21:31:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=eeef.4e07a51b.k1106; bh=PtawA6T/6hLCdlvBKl9pvuKSxtvugoJbPr4FpXeugqI=; b=DP0F2WbPL19NSyJ4tq7Q+ukW6zA5PruHwhMI6wExx1YKk1CG1Kt/kmmccbJ5mttq/b3cr6UsOwKtnfzPqeJ5zNBzD4zPfeJVXLoz2DUYmPg73n4OMze09QNXPXp5c0BhVg4POFS+Ld1VwVtpjQU7ue4AiOnLt4czHVjiQpxcbr4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=eeef.4e07a51b.k1106; bh=PtawA6T/6hLCdlvBKl9pvuKSxtvugoJbPr4FpXeugqI=; b=huxS5BKPNCGirFGwQbCv8rmEo97SQfEjRSdomQbT6bTvKzo/PHb8ugQYerzOqLCE5+TtYeimdG/mRMdfQhy6AkkEpAzrxeNGmg10BgeVlq1R6J7wfXgZaZE7O519r+RowjYBKXR6B1o6Sy6iHXaPZ+HIjc1KVZ094TfZjdKvHag= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jun 2011 21:30:44 -0000 Date: 26 Jun 2011 17:31:06 -0400 Message-ID: From: "John R. Levine" To: "Matt McCutchen" In-Reply-To: <1309122678.2118.85.camel@localhost> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:31:08 -0000 [ note to people on the dane list: I just noticed this is cross-posted there, so my apologies if this is a dead horse. I'll go read some archives before arguing further] > To restate my question: is an opt-in process necessary, or could we just > give registrants with signed zones a deadline to get their house in > order? Who is "we" and how do "we" enforce the deadline? > With my proposal, clients would not accept positive assertions from your > zone unless and until you ask your registrar to check the box, and you > wouldn't do that unless you were using a DNSSEC service provider you > fully trust with your site. I'm trying to imagine the utility of a feature that allows zone managers to say "well, yes, I signed this, but I was just kidding." The track records of policy assertions is not good. If the plan is that this makes it easier to debug your DNSSEC setup, the track record of client-visible debug flags is no better. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From matt@mattmccutchen.net Sun Jun 26 14:51:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44531228010; Sun, 26 Jun 2011 14:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPf0rkpSCOuG; Sun, 26 Jun 2011 14:50:59 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A022800F; Sun, 26 Jun 2011 14:50:59 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 0D8B43BC063; Sun, 26 Jun 2011 14:50:59 -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=sSbc/roDeAL0fUcK2Q90/gd47oCmE7vFXIgBZidzdEP mXCXiJMy1YdcfZ5D/Lmo9zbYTzb2J+xyDTgMKVkg8pAzTFnuQMo5WZydGwMezL0D 0AnPUKK6QaB5bNhBEcKt+scOPUFyCxPNMmyeLLO9LYos6xuKTa0pkKTEw/eqbnqM = 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=3lU5efJw1d85p1VrPHZmXR8V3Qs=; b=VL0C3MMKZo moOtWjXyWQAbuKISsXFD41Zm+XVR0W76bf164iinFYaDl/9T+1IJJ8KRpD6kL0VA iSs3zHAmIONBLeFJmgz4Nybd97J3bdcjbeGOfwZIU2Y4yRCvJNxnXJP5RD9ri4yT VIiUz4MHQzPmX0r0MSULWlFznytkC+Q8E= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 7A14F3BC062; Sun, 26 Jun 2011 14:50:58 -0700 (PDT) From: Matt McCutchen To: "John R. Levine" In-Reply-To: References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 17:50:55 -0400 Message-ID: <1309125055.2118.98.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:51:00 -0000 On Sun, 2011-06-26 at 17:31 -0400, John R. Levine wrote: > [ note to people on the dane list: I just noticed this is cross-posted > there, so my apologies if this is a dead horse. I'll go read some > archives before arguing further] > > > To restate my question: is an opt-in process necessary, or could we just > > give registrants with signed zones a deadline to get their house in > > order? > > Who is "we" The Internet community, with IETF playing its customary leadership role. > and how do "we" enforce the deadline? It would be enforced in the sense that IETF encourages clients to start honoring DNSSEC-signed positive assertions on that date and no sooner, so sites that still have untrustworthy DNSSEC providers will become vulnerable. > > With my proposal, clients would not accept positive assertions from your > > zone unless and until you ask your registrar to check the box, and you > > wouldn't do that unless you were using a DNSSEC service provider you > > fully trust with your site. > > I'm trying to imagine the utility of a feature that allows zone managers > to say "well, yes, I signed this, but I was just kidding." Absolutely, this should not be necessary, but in practice it might be the only way to make a safe transition from the present state, which we have fallen into as a result of DANE not being on everyone's mind as DNSSEC was first deployed. At this point I don't have any data on how bad the situation is. I would like nothing better to find out that nobody is using untrustworthy DNSSEC providers. But I know if I don't raise this concern now, the public CAs will. -- Matt From warren@kumari.net Sun Jun 26 15:08:01 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6C2228013 for ; Sun, 26 Jun 2011 15:08:01 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trSkjsbbaBGR for ; Sun, 26 Jun 2011 15:08:00 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D2E13228011 for ; Sun, 26 Jun 2011 15:08:00 -0700 (PDT) Received: from [172.17.1.12] (222-154-253-57.adsl.xtra.co.nz [222.154.253.57]) by vimes.kumari.net (Postfix) with ESMTPSA id 4BEDD1B4014B for ; Sun, 26 Jun 2011 18:07:59 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2011 06:07:59 +0800 References: <20110624183513.7035311E81A8@ietfa.amsl.com> To: IETF DANE WG list Message-Id: <2A3775A1-8A71-4DEB-9D15-CCBAFB868CB7@kumari.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Fwd: Please help the Nomcom X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 22:08:01 -0000 Hi all, Please consider doing this if you are able / willing=85 I'm currently traveling (currently stuck in New Zealand (because of the = ash cloud), en route from Singapore to Fiji) and am way behind on my = email -- apologies for slipping behind on the list=85 W Begin forwarded message: > From: NomCom Chair > Date: June 25, 2011 2:35:13 AM GMT+08:00 > To: Working Group Chairs > Subject: Please help the Nomcom=20 >=20 > Hi WG chairs, > We have had a good response to the first call for volunteers but the=20= > rate at which new volunteers are coming in is slowing down. The Nomcom=20= > process is best served by a large pool of volunteers drawn from a wide=20= > spectrum of IETF attendees. Where else would we find this wide = spectrum > if not in the WG mailing lists. >=20 > I would really appreciate it if you can forward the message onto your > working group mailing lists.=20 >=20 > The latest volunteer status and the second call for volunteers can be > found at > https://datatracker.ietf.org/ann/nomcom/2964/ >=20 > Thanks in advance for your help. >=20 > Suresh Krishnan > Nomcom Chair 2011-2012 > Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com >=20 From matt@mattmccutchen.net Sun Jun 26 15:17:28 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7787421F84AE; Sun, 26 Jun 2011 15:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rRVLWvH6PVx; Sun, 26 Jun 2011 15:17:27 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E0E1C21F84AC; Sun, 26 Jun 2011 15:17:27 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id A4C9128406E; Sun, 26 Jun 2011 15:17:27 -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=s13UBmUkUo3ikAsESxTs8aBbdxAKbqwfI0eyBc9YYuX wS6k6qVFzla2RhYTYZ5p5Bdw7HdPNTIrHtAOeWB/7kBeEU4yq01GZHNo2Wc+j4u4 1fzJHKQFgayomp/AH1WY0qA3+Hetbwyr+kogvewlb5lYcPf5OCvKS6qr/p8UnwcQ = 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=R1RGNF+qPowH8ShaTBO6e+U+wU0=; b=Q7Pi34HsbP I3t0id2GtEYndxKvFOfojg6f7yUQ6y31PTiBXH0KwzEAV1a/LZ4KSqu3WefGD8dz /TMqSV63H/iolHU6ZmcqjW4FMtzicvq/OFrPCPs5Dz4blCgXBIHyZrjuzwhe+WiP hSsoCzqLks1B50+jA1j0m7a9SsfwkU1p4= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 1F12028406C; Sun, 26 Jun 2011 15:17:26 -0700 (PDT) From: Matt McCutchen To: dnsext@ietf.org In-Reply-To: <1309115504.2118.69.camel@localhost> References: <1309115504.2118.69.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 18:17:25 -0400 Message-ID: <1309126645.2118.109.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 22:17:28 -0000 On Sun, 2011-06-26 at 15:11 -0400, Matt McCutchen wrote: > Proper governance > of DNSSEC data to ensure that it reflects authoritative intent is > essential to be able to use these schemes and realize their compelling > benefits. To restate, the upshot of DANE and similar schemes to come is that Alice, a registrant with a signed zone, will need to apply the same standard of governance to their zones as she currently does to her relationships with public CAs. This common standard may be anything from a subscriber username and password on a sticky note on the monitor to multiple two-factor-authenticated approvals of each change. Alice may consider that the best way to achieve the above is to outsource the DNS to a company she trusts, with an interface for submitting DNS changes comparable to those for obtaining certificates from public CAs. Maybe the company can also get her publicly-recognized certs for legacy clients; maybe her registrar even provides this service. That's great. But now she will also have the option to manage the certs herself and still have the world recognize them as authoritative for her domain. It's her choice, and thereby the ideal of DNS delegation will finally be realized with respect to authentication of TLS services bound to DNS names. -- Matt From johnl@taugh.com Sun Jun 26 15:27:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82D21F84E6 for ; Sun, 26 Jun 2011 15:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtBAqjIu8ARQ for ; Sun, 26 Jun 2011 15:27:04 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79121F84E5 for ; Sun, 26 Jun 2011 15:27:04 -0700 (PDT) Received: (qmail 61656 invoked from network); 26 Jun 2011 22:20:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f0d7.4e07b0a6.k1106; bh=usgnuNb1aqtlTSh+K6jkU3s1AOUSN/KK7+GSrU5K5rE=; b=UDxvSQ8Swvb3tUU22hzGLRm3S4yq7HkfLzGecekn9Oe49TtbZ3HEJvwWKVZlAQhQu8nwnmljqx6FuQ83Bp+LC7rwP9YdhwmzdAF4M0IDT8ebT2KwzTiTnkCub8YJGt89DBIYUlqZ8U1ux87vG+vvLF8Ohd5R+No0jY2NqFpwvjE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f0d7.4e07b0a6.k1106; bh=usgnuNb1aqtlTSh+K6jkU3s1AOUSN/KK7+GSrU5K5rE=; b=e/gzb6C+DZzTw9K6YkD782KyObTp+YYSrlKlgkEvxZTb/6/YH2Mv/z2sMp3c5iywWiZ8xjaWzW+CYsCyNaTkveFBSDRhRxm7vYipcGIQO7YF1fA0rgPjfmlQFgKEl3CjtgKrkP8+av125kHN7JUDClX9DZh+covJn9dgEf3/Nkw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jun 2011 22:20:00 -0000 Date: 26 Jun 2011 18:20:21 -0400 Message-ID: From: "John R Levine" To: "Matt McCutchen" In-Reply-To: <1309125055.2118.98.camel@localhost> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> <1309125055.2118.98.camel@localhost> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 22:27:05 -0000 >> Who is "we" > > The Internet community, with IETF playing its customary leadership role. Ah. Never mind, then. R's, John From Jeff.Hodges@KingsMountain.com Sun Jun 26 18:23:13 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8856D11E8090 for ; Sun, 26 Jun 2011 18:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.665 X-Spam-Level: X-Spam-Status: No, score=-99.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ynew8NMkMa8 for ; Sun, 26 Jun 2011 18:23:13 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 56D9411E807B for ; Sun, 26 Jun 2011 18:23:10 -0700 (PDT) Received: (qmail 29929 invoked by uid 0); 27 Jun 2011 00:14:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 27 Jun 2011 00:14:54 -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:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=5taezRh/KotjD0saaOkbt20rCazXpxcks1jMvUYofiugAzhIT5iU5HDI5OyRyW/hWVaGXUU8/dIcbIARebo6U1AZzstIoYrgzr2iwB9RAqT2tpM8ey1qMdI6f+0fBLaZ; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QazTa-0005te-Bc; Sun, 26 Jun 2011 18:14:54 -0600 Message-ID: <4E07CB7C.9000009@KingsMountain.com> Date: Sun, 26 Jun 2011 17:14:52 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: dane Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 01:23:13 -0000 > More generally, DNSSEC holds > enormous potential utility as a repository of integrity-protected > authoritative information about DNS names, including configuration for > new opt-in security schemes. However, each of these schemes may > increase the degree of exposure to malfeasance by the DNS operator (who > may not be the same entity as the authoritative holder of the domain) in > some or all cases, compared to traditional practice. Not to say that having these concerns is misplaced, but the DNSop WG, as well as various DNS operators, have been thinking along these lines... http://tools.ietf.org/wg/dnsop/ "DPS" = DNSSEC Practice Statement ..perhaps further discussion should go to the dnsop@ietf.org list? There's also: Dnssec-deployment@dnssec-deployment.org HTH, =JeffH --- DNSSEC Operational Practices, Version 2 http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis Abstract This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. --- DNSSEC Policy & Practice Statement Framework http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework Abstract This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. -- DPS framework (slides) DNSSEC in Sweden: Five Years of Practical Experience (slides) Root DNSSEC docs ---------------- Root DNSSEC - documentation (many documents) http://www.root-dnssec.org/documentation/ IANA DNSSEC Information https://www.iana.org/dnssec/ Individual DPSs --------------- DNSSEC Practice Statement for the Root Zone KSK Operator https://www.iana.org/dnssec/icann-dps.txt Verisign DNSSEC Practice Statements (.net, .edu, Signing Services, root zone ZSK operator) https://verisigninc.com/en_US/repository/index.xhtml RIPE DNSSEC Policy and Practice Statement http://www.ripe.net/rs/reverse/dnssec/dps.html DNSSEC Practice Statement (DPS) -- .se http://www.iis.se/docs/se-dnssec-dps-eng.pdf DNSSEC Practice Statement for the JP Zone (JP DPS) https://jprs.jp/doc/dnssec/jp-dps-eng.html --- end From rbarnes@bbn.com Sun Jun 26 20:33:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125B021F8568; Sun, 26 Jun 2011 20:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csYXwd7OHSoj; Sun, 26 Jun 2011 20:33:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8361921F856C; Sun, 26 Jun 2011 20:33:21 -0700 (PDT) Received: from [128.89.253.249] (port=51349 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qb2Zc-000GrW-Ez; Sun, 26 Jun 2011 23:33:21 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E07CB7C.9000009@KingsMountain.com> Date: Sun, 26 Jun 2011 23:33:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF98695-B8C2-4C90-AEC2-86680CAE0B4D@bbn.com> References: <4E07CB7C.9000009@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) Cc: dnsext@ietf.org, dane Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:33:26 -0000 For example: On Jun 26, 2011, at 8:14 PM, =3DJeffH wrote: > > More generally, DNSSEC holds > > enormous potential utility as a repository of integrity-protected > > authoritative information about DNS names, including configuration = for > > new opt-in security schemes. However, each of these schemes may > > increase the degree of exposure to malfeasance by the DNS operator = (who > > may not be the same entity as the authoritative holder of the = domain) in > > some or all cases, compared to traditional practice. >=20 > Not to say that having these concerns is misplaced, but the DNSop WG, = as well as various DNS operators, have been thinking along these = lines... >=20 > http://tools.ietf.org/wg/dnsop/ >=20 > "DPS" =3D DNSSEC Practice Statement >=20 > ..perhaps further discussion should go to the dnsop@ietf.org list? >=20 > There's also: Dnssec-deployment@dnssec-deployment.org >=20 > HTH, >=20 > =3DJeffH >=20 > --- >=20 > DNSSEC Operational Practices, Version 2 > http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis >=20 > Abstract >=20 > This document describes a set of practices for operating the DNS = with > security extensions (DNSSEC). The target audience is zone > administrators deploying DNSSEC. >=20 > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. >=20 > This document obsoletes RFC 4641 as it covers more operational = ground > and gives more up-to-date requirements with respect to key sizes and > the DNSSEC operations. >=20 >=20 > --- >=20 > DNSSEC Policy & Practice Statement Framework > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework >=20 > Abstract >=20 > This document presents a framework to assist writers of DNSSEC = Policy > and Practice Statements such as Domain Managers and Zone Operators = on > both the top-level and secondary level, who is managing and = operating > a DNS zone with Security Extensions (DNSSEC) implemented. >=20 > In particular, the framework provides a comprehensive list of = topics > that should be considered for inclusion into a DNSSEC Policy > definition and Practice Statement. >=20 > -- >=20 > DPS framework (slides) > = >=20 > DNSSEC in Sweden: Five Years of Practical Experience (slides) > = >=20 >=20 > Root DNSSEC docs > ---------------- >=20 > Root DNSSEC - documentation (many documents) > http://www.root-dnssec.org/documentation/ >=20 > IANA DNSSEC Information > https://www.iana.org/dnssec/ >=20 >=20 > Individual DPSs > --------------- >=20 > DNSSEC Practice Statement for the Root Zone KSK Operator > https://www.iana.org/dnssec/icann-dps.txt >=20 > Verisign DNSSEC Practice Statements > (.net, .edu, Signing Services, root zone ZSK operator) > https://verisigninc.com/en_US/repository/index.xhtml >=20 > RIPE DNSSEC Policy and Practice Statement > http://www.ripe.net/rs/reverse/dnssec/dps.html >=20 > DNSSEC Practice Statement (DPS) -- .se > http://www.iis.se/docs/se-dnssec-dps-eng.pdf >=20 > DNSSEC Practice Statement for the JP Zone (JP DPS) > https://jprs.jp/doc/dnssec/jp-dps-eng.html >=20 >=20 >=20 > --- > end >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paf@cisco.com Sun Jun 26 20:22:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192411E809D; Sun, 26 Jun 2011 20:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cX9OT4CP-iz; Sun, 26 Jun 2011 20:22:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3B65111E8076; Sun, 26 Jun 2011 20:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=692; q=dns/txt; s=iport; t=1309144935; x=1310354535; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xT/FdTbYC31rtYi60ylgCIdiSEo0+SkUGfG6ugd+bow=; b=cCe2Ge5qZ83fwSlYWWjG7RUdeSlCwsTdamuW4cqYHYGK0h9xTyOXJgFj VRcLB93Pv2Y/Xg9PQ+j5K+YPWbW4rxLlGdTLl6xu35NULXjXFAKDN9yyD dQXPa1Ch+4CaJhgjTmrqEv2Oc3qo6pgtieLjXSyLgMVfLN+YVJtY0kvwl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAD3B06Q/khN/2dsb2JhbABSp0N3iHShUJ0dhjAEkgOQHQ X-IronPort-AV: E=Sophos;i="4.65,429,1304294400"; d="scan'208";a="98283187" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2011 03:22:14 +0000 Received: from dhcp-10-55-93-191.cisco.com (dhcp-10-55-93-191.cisco.com [10.55.93.191]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5R3MDJo001288; Mon, 27 Jun 2011 03:22:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1309122338.2118.82.camel@localhost> Date: Mon, 27 Jun 2011 05:22:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <159B4B11-5186-45C3-9FC0-C2E5EAC11C13@cisco.com> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 27 Jun 2011 00:15:36 -0700 Cc: John Levine , dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:22:16 -0000 On 26 jun 2011, at 23.05, Matt McCutchen wrote: > But now if clients start to accept DANE positive > assertions, your friend can MITM your customers. Yes, but you did choose your friend as a DNS operator. And you will = always be giving your DNS hosting provider that ability. > With my proposal, clients would not accept positive assertions from = your > zone unless and until you ask your registrar to check the box, and you > wouldn't do that unless you were using a DNSSEC service provider you > fully trust with your site. You can not ask the registrar to keep track of who is your DNS hosting = provider. That has been tried and only leads to problems. Patrik From paf@cisco.com Sun Jun 26 20:23:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9FA11E8076; Sun, 26 Jun 2011 20:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gID6DpCiTK9; Sun, 26 Jun 2011 20:23:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DBA1111E80A8; Sun, 26 Jun 2011 20:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=353; q=dns/txt; s=iport; t=1309145005; x=1310354605; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7zSK+xPxBXWS+XqgX1zhN5PF+QrmD45hVWLkw7K+s3Y=; b=b7mKZ2lHJvQtqOumFsUr4NKDfsTkr7gzFq/tSTxqcXLNlhxsDnV/kUZO H0Vq0VpZxGyJnmbczjnZTDR5f3oN9ur+tbnq4wjYwABdiBJ28cwYZrjyo bwgxtfCDPAYA62Gy+oyXYMXlhEHESHE4eOY1KHnbl7EloJIHjyWE/dQUi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAD3B06Q/khM/2dsb2JhbABSp0N3iHShUJ0dhjAEkgOQHQ X-IronPort-AV: E=Sophos;i="4.65,429,1304294400"; d="scan'208";a="98283337" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2011 03:23:24 +0000 Received: from dhcp-10-55-93-191.cisco.com (dhcp-10-55-93-191.cisco.com [10.55.93.191]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5R3NNgm026639; Mon, 27 Jun 2011 03:23:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1309122678.2118.85.camel@localhost> Date: Mon, 27 Jun 2011 05:23:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 27 Jun 2011 00:15:36 -0700 Cc: John Levine , dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:23:25 -0000 On 26 jun 2011, at 23.11, Matt McCutchen wrote: > To restate my question: is an opt-in process necessary, or could we = just > give registrants with signed zones a deadline to get their house in > order? My take is that opt-in is not needed. The opt-in happens when zone gets = signed and the DS is published in the parent zone. Patrik From vixie@isc.org Sun Jun 26 20:30:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827B11E80A8; Sun, 26 Jun 2011 20:30:46 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8Webe-pPWzP; Sun, 26 Jun 2011 20:30:46 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5111E808E; Sun, 26 Jun 2011 20:30:45 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 37A96A1031; Mon, 27 Jun 2011 03:30:44 +0000 (UTC) (envelope-from vixie@isc.org) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1D546A1021; Mon, 27 Jun 2011 03:30:44 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org, dane@ietf.org In-Reply-To: Your message of "Mon, 27 Jun 2011 05:23:23 +0200." <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 27 Jun 2011 03:30:44 +0000 Message-ID: <83087.1309145444@nsa.vix.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Mon, 27 Jun 2011 00:15:36 -0700 Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:30:46 -0000 > From: Patrik Fältström > Date: Mon, 27 Jun 2011 05:23:23 +0200 > > > To restate my question: is an opt-in process necessary, or could we just > > give registrants with signed zones a deadline to get their house in > > order? > > My take is that opt-in is not needed. The opt-in happens when zone > gets signed and the DS is published in the parent zone. +1. From fweimer@bfk.de Mon Jun 27 01:30:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE8621F8656; Mon, 27 Jun 2011 01:30:56 -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_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YoX90kb9oyl; Mon, 27 Jun 2011 01:30:56 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id CFF4321F8616; Mon, 27 Jun 2011 01:30:55 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qb7DZ-0005LY-ME; Mon, 27 Jun 2011 08:30:53 +0000 Received: by bfk.de with local id 1Qb7DZ-00035D-JW; Mon, 27 Jun 2011 08:30:53 +0000 From: Florian Weimer To: Matt McCutchen References: <1309115504.2118.69.camel@localhost> <1309126645.2118.109.camel@localhost> Date: Mon, 27 Jun 2011 08:30:53 +0000 In-Reply-To: <1309126645.2118.109.camel@localhost> (Matt McCutchen's message of "Sun, 26 Jun 2011 18:17:25 -0400") Message-ID: <8262nrisle.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, dane Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 08:30:56 -0000 * Matt McCutchen: > To restate, the upshot of DANE and similar schemes to come is that > Alice, a registrant with a signed zone, will need to apply the same > standard of governance to their zones as she currently does to her > relationships with public CAs. This is already a requirement without DANE, and with or without DNSSEC. There seems to be a persistent myth that DNS is just there and you don't have to take care. I don't know where this comes from. For most organizations, DNS is an important part of the infrastructure, one of the things where breakage is widely noticeable to users and beyond. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Mon Jun 27 01:33:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206BE11E807A; Mon, 27 Jun 2011 01:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlM7K7rKL8KX; Mon, 27 Jun 2011 01:33:31 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id E89D721F862A; Mon, 27 Jun 2011 01:33:29 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qb7G4-0005TY-Gj; Mon, 27 Jun 2011 08:33:28 +0000 Received: by bfk.de with local id 1Qb7G4-0007Jo-Di; Mon, 27 Jun 2011 08:33:28 +0000 From: Florian Weimer To: Matt McCutchen References: <1309115504.2118.69.camel@localhost> Date: Mon, 27 Jun 2011 08:33:28 +0000 In-Reply-To: <1309115504.2118.69.camel@localhost> (Matt McCutchen's message of "Sun, 26 Jun 2011 15:11:44 -0400") Message-ID: <821uyfish3.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, dane Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 08:33:32 -0000 * Matt McCutchen: > I'm looking forward to DANE positive assertions making TLS server > deployment significantly more convenient. Is there any browser vendor buy-in for this type of functionality? My gut feeling is that this is extremely unrealistic and will not happen. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pgut001@login01.cs.auckland.ac.nz Mon Jun 27 02:04:42 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA421F8644; Mon, 27 Jun 2011 02:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldHSpoLbTp+Q; Mon, 27 Jun 2011 02:04:40 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80521F85C5; Mon, 27 Jun 2011 02:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1309165481; x=1340701481; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20fweimer@bfk.de,=20matt@mattmccutchen.net|Subject: =20Re:=20[dane]=20[dnsext]=20Trustworthiness=20of=20DNSSE C=20data|Cc:=20dane@ietf.org,=20dnsext@ietf.org |In-Reply-To:=20<821uyfish3.fsf@mid.bfk.de>|Message-Id: =20|Date: =20Mon,=2027=20Jun=202011=2021:04:29=20+1200; bh=Jc8vNnQ83+F3+6gLoQG9WL7PaXZnLGKY1tDDVTw119A=; b=FnrLTUPjl1rv08IBbnZYFUiEEE492opf+2Sh0sqynwW0gf0QqZdebX9g Many+Lf5m53AxLA5HHf4xO2mVovwzTf4lgJJQJxEk/XKQRf7YTbXZN42G 59NGDQ+uxMfYonsAlWUBcEgtt+x7umvO7q0/HTvvD3ytZSgFYTnlWvwbD Q=; X-IronPort-AV: E=Sophos;i="4.65,431,1304251200"; d="scan'208";a="69185445" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jun 2011 21:04:30 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qb7k5-0003y3-Iy; Mon, 27 Jun 2011 21:04:29 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qb7k5-0005OB-RA; Mon, 27 Jun 2011 21:04:29 +1200 From: Peter Gutmann To: fweimer@bfk.de, matt@mattmccutchen.net In-Reply-To: <821uyfish3.fsf@mid.bfk.de> Message-Id: Date: Mon, 27 Jun 2011 21:04:29 +1200 Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 09:04:42 -0000 Florian Weimer writes: >* Matt McCutchen: >> I'm looking forward to DANE positive assertions making TLS server >> deployment significantly more convenient. > >My gut feeling is that this is extremely unrealistic and will not happen. I was tempted to reply to the orignial message with "And I'm looking forward to Cindy Crawford popping out of thin air and falling into my lap. I guess we're both in for some disappointment" :-), but felt I'd wait for someone else to say something... Peter. From matt@mattmccutchen.net Mon Jun 27 04:46:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6061121F8607; Mon, 27 Jun 2011 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1eb0CQtiYRO; Mon, 27 Jun 2011 04:46:06 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id A38AD21F8690; Mon, 27 Jun 2011 03:45:31 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 6CA2017EACA; Mon, 27 Jun 2011 03:43:30 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 441FF57806E; Mon, 27 Jun 2011 03:37:48 -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=sbYXAyaqtzK1DDueF/vtDja4dTlGcJxqHr9R/x6bgLS lIoqQizllYNl5KSEFR4KufRqzASHt9O3o/z/6lVrEFMKRc3xwr+AGQCMevDWVhQs ihYYoS+60ySCMAn+sGe748C6hjU9636AN+M2jvWF6iNwH6fu0ZRbUNooiffxHSK4 = 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=Ehikfsyk/TVYZMqtdccl5sFC8F4=; b=tuSSkyLkRz +JGxBwer/azpCTGPgnzBnMPHnh5ZMgtJCzjJEWD75AZbcmzw066GkbFKFByuAxCK a/hhamUl3dOLdTTtMaYcfCGmgQiDQO7ufsE520oD/u82JmdiosUN5gj8/is/9kbA iG7hEIWdzbvqjy0yr7G1AguqOmSiT5QrY= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 87D4B57806C; Mon, 27 Jun 2011 03:37:47 -0700 (PDT) From: Matt McCutchen To: Florian Weimer In-Reply-To: <821uyfish3.fsf@mid.bfk.de> References: <1309115504.2118.69.camel@localhost> <821uyfish3.fsf@mid.bfk.de> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Jun 2011 06:37:45 -0400 Message-ID: <1309171065.2040.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane Subject: [dane] (Client deployment of DANE positive assertions) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 11:46:07 -0000 On Mon, 2011-06-27 at 08:33 +0000, Florian Weimer wrote: > * Matt McCutchen: > > > I'm looking forward to DANE positive assertions making TLS server > > deployment significantly more convenient. > > Is there any browser vendor buy-in for this type of functionality? > > My gut feeling is that this is extremely unrealistic and will not > happen. Chromium accepts stapled CAA-RP RRsets (http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and Mozilla is planning to follow suit (https://bugzilla.mozilla.org/show_bug.cgi?id=589537). Hopefully they switch to the DANE TLSA format when it is standardized. The stapling is an important implementation question but irrelevant to the security of positive assertions. -- Matt From hallam@gmail.com Mon Jun 27 07:10:58 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D821F8566; Mon, 27 Jun 2011 07:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEaF2otLA2Oc; Mon, 27 Jun 2011 07:10:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1D21F86EC; Mon, 27 Jun 2011 06:14:47 -0700 (PDT) Received: by ywp31 with SMTP id 31so2788011ywp.31 for ; Mon, 27 Jun 2011 06:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5MNCDsJLeqoAn9sE1c0yp6JKH4djaQ+OuncQ5N6pw0s=; b=TXDHKXqL92aUgH++gPWLgfZe4t3jBV2oO6KrgAEMsjjQijipBd0GO6ZUKr8fVp8fgW EJXCuqnQNMakgehBFNH0ep/ufexGmVN8OUyqqpx67NA/3FAt8Okg2YgsHw5hQhCVjQ6B E/GrYidveXX/SdD2oGrakZi5CMgPLbQOypWDw= 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=J05mumyjfJYSmI4FPAMHqHN0PqsHNuy7onoNcQ65Bzml0QeAXx/Y16om5w9MReo4re fW7qzNNloTjDf3T3nQtoeIbOvmsiu5YDvV/e3jn6S9mhsAoTKvfBU++ZSlecsds7dbWc yikjrCzNeaFwL0f7dwsjsxqT97lK1T3sMPsuE= MIME-Version: 1.0 Received: by 10.101.186.21 with SMTP id n21mr1030305anp.18.1309180387567; Mon, 27 Jun 2011 06:13:07 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Mon, 27 Jun 2011 06:13:07 -0700 (PDT) In-Reply-To: <1309171065.2040.7.camel@localhost> References: <1309115504.2118.69.camel@localhost> <821uyfish3.fsf@mid.bfk.de> <1309171065.2040.7.camel@localhost> Date: Mon, 27 Jun 2011 09:13:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=001636c92acef2a97b04a6b14fc6 Cc: dane , dnsext@ietf.org Subject: Re: [dane] [dnsext] (Client deployment of DANE positive assertions) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:10:58 -0000 --001636c92acef2a97b04a6b14fc6 Content-Type: text/plain; charset=ISO-8859-1 What I see there is a tracking bug. Stating that 'Mozilla intends to do X' is pretty much like saying 'IETF intends to do X', The facts behind the statement can range from one person involved in the organization intending to do something and an actual commitment to actual code. Getting stuff done in browsers is hard. There a billions of them out there. That is why I still think that Web Services is the place to start. There are lots of Web Services, there are new ones being developed all the time and very few of them have any real security model at all. On Mon, Jun 27, 2011 at 6:37 AM, Matt McCutchen wrote: > On Mon, 2011-06-27 at 08:33 +0000, Florian Weimer wrote: > > * Matt McCutchen: > > > > > I'm looking forward to DANE positive assertions making TLS server > > > deployment significantly more convenient. > > > > Is there any browser vendor buy-in for this type of functionality? > > > > My gut feeling is that this is extremely unrealistic and will not > > happen. > > Chromium accepts stapled CAA-RP RRsets > (http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and > Mozilla is planning to follow suit > (https://bugzilla.mozilla.org/show_bug.cgi?id=589537). Hopefully they > switch to the DANE TLSA format when it is standardized. The stapling is > an important implementation question but irrelevant to the security of > positive assertions. > > -- > Matt > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --001636c92acef2a97b04a6b14fc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I see there is a tracking bug.

Stating that 'Mo= zilla intends to do X' is pretty much like saying 'IETF intends to = do X', The facts behind the statement can range from one person involve= d in the organization intending to do something and an actual commitment to= actual code.


Getting stuff done in browsers is hard. = There a billions of them out there. That is why I still think that Web Serv= ices is the place to start. There are lots of Web Services, there are new o= nes being developed all the time and very few of them have any real securit= y model at all.


On Mon, Jun 27, 2011 at = 6:37 AM, Matt McCutchen <matt@mattmccutchen.net> wrote:
On Mon, 2011-06-27 at 08:33 +0000, Florian Weimer wrote:
> * Matt McCutchen:
>
> > I'm looking forward to DANE positive assertions making TLS se= rver
> > deployment significantly more convenient.
>
> Is there any browser vendor buy-in for this type of functionality?
>
> My gut feeling is that this is extremely unrealistic and will not
> happen.

Chromium accepts stapled CAA-RP RRsets
(http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and
Mozilla is planning to follow suit
(https://bugzilla.mozilla.org/show_bug.cgi?id=3D589537). =A0= Hopefully they
switch to the DANE TLSA format when it is standardized. =A0The stapling is<= br> an important implementation question but irrelevant to the security of
positive assertions.

--
Matt

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



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

--001636c92acef2a97b04a6b14fc6-- From alangley@gmail.com Tue Jun 28 11:22:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B6111E812B for ; Tue, 28 Jun 2011 11:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72lrQsZf4FCg for ; Tue, 28 Jun 2011 11:22:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C316411E8120 for ; Tue, 28 Jun 2011 11:22:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so497024iwn.31 for ; Tue, 28 Jun 2011 11:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=+obNPlU8ErbWr1oARWr8uq91y9NrFjkN5L2M71agRrM=; b=chHMak0EyiLpBJfkTQNfu+ST2EsLkuPcN4Ci3QwebtgCAe+S60H3uDPD1wdGOncUd2 LkxMRbg6diTOvflFXV+K1MWU+GZYfXxZ+Kkc0cz7T23P0f/EHVmUQYO8/5GJC5LN0kaK /fjcKvVSGEdSTHermSrn0s+kICy+F+Gm9LesE= MIME-Version: 1.0 Received: by 10.42.39.210 with SMTP id i18mr9153457ice.53.1309285362117; Tue, 28 Jun 2011 11:22:42 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.219.138 with HTTP; Tue, 28 Jun 2011 11:22:42 -0700 (PDT) Date: Tue, 28 Jun 2011 14:22:42 -0400 X-Google-Sender-Auth: Xyiqy4jUs-ADWknCKI142Lhtek8 Message-ID: From: Adam Langley To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 18:22:46 -0000 As promised. (This is also the format that Chrome is using for it's DNSSEC stapled certificate support.) http://tools.ietf.org/html/draft-agl-dane-serializechain-00 Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From rbarnes@bbn.com Tue Jun 28 12:17:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87B611E8177 for ; Tue, 28 Jun 2011 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8D2OBUUqQNe for ; Tue, 28 Jun 2011 12:17:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1FC11E8166 for ; Tue, 28 Jun 2011 12:17:15 -0700 (PDT) Received: from [128.89.253.252] (port=57344 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QbdmW-000EfD-95; Tue, 28 Jun 2011 15:17:09 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 28 Jun 2011 15:17:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <652618FC-437A-42A0-9B4F-DEA8D735DF4E@bbn.com> References: To: Adam Langley X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:17:15 -0000 Excellent, this matches what I backed out of your example :) Couple of quick comments: - Summary: I think it would be clearer to structure the draft as: 1. Data structure 2. How to construct the chain starting from a DNS name 3. How to verify the chain - It would be helpful to have a description of the data structure in "at = rest" form, as opposed to in "parsing stream" form, in order to separate = structure from parsing logic.=20 - Because the description of verifier behavior is so focused on parsing, = the cryptographic verification steps kind of get lost. It took me a = couple of seconds to find the requirement for matching DS and DNSKEY. - The document doesn't say anything about how to construct a chain = starting from a DNS name. Given that chain.py is 471 lines, this = doesn't seem like a trivial process! - Considering the differences from normal certs, e.g., in naming = practices, it might actually be helpful to have a separate certificate = profile for DNSSEC-stapled certificates, and to signal it with something = like a CP OID (as for EV). That wouldn't rule out the use of this = extension with other types of certs, but it would provide a simple flag = that a stapled cert is different from some other self-signed cert. =20 Thanks for writing a spec, I think this could be a useful complement to = the DANE RR type. --Richard On Jun 28, 2011, at 2:22 PM, Adam Langley wrote: > As promised. (This is also the format that Chrome is using for it's > DNSSEC stapled certificate support.) >=20 > http://tools.ietf.org/html/draft-agl-dane-serializechain-00 >=20 >=20 > Cheers >=20 > AGL >=20 > --=20 > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From fanf2@hermes.cam.ac.uk Tue Jun 28 12:25:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1C11E80F2 for ; Tue, 28 Jun 2011 12:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8QTGjh4f-aL for ; Tue, 28 Jun 2011 12:25:46 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 13FA811E807B for ; Tue, 28 Jun 2011 12:25:45 -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]:45910) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QbduV-0005sb-rv (Exim 4.72) (return-path ); Tue, 28 Jun 2011 20:25:23 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QbduV-0006QA-Mo (Exim 4.67) (return-path ); Tue, 28 Jun 2011 20:25:23 +0100 Date: Tue, 28 Jun 2011 20:25:23 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adam Langley In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:25:47 -0000 Adam Langley wrote: > As promised. (This is also the format that Chrome is using for it's > DNSSEC stapled certificate support.) > > http://tools.ietf.org/html/draft-agl-dane-serializechain-00 Why not DNS wire format? i.e. concatenate the usual encoding of (1) the trust anchor DNSKEY + RRSIG DNSKEY RRs; (2) for each intermediate zone cut, (2a) the delegation DS + RRSIG DS RRs; (2b) the apex DNSKEY + RRSIG DNSKEY RRs; (3) the final RR set + RRSIG. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Northerly or northwesterly 5 to 7, perhaps gale 8 later in Trafalgar and Fitzroy. Moderate or rough. Showers. Moderate or good. From alangley@gmail.com Tue Jun 28 12:29:46 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3957811E8199 for ; Tue, 28 Jun 2011 12:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVVlTKPUK2l9 for ; Tue, 28 Jun 2011 12:29:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9E4811E8195 for ; Tue, 28 Jun 2011 12:29:45 -0700 (PDT) Received: by iwn39 with SMTP id 39so560535iwn.31 for ; Tue, 28 Jun 2011 12:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=vDBmzsjbt1TSTpn5pm8o8L8Urwrv3ROjZaBBXCFl91s=; b=xCedkpJx6sKpapxXIm9bRyAeIYdYf15ON63kwYc97aNSwQUDKjg1VFHdFpJdNin6HY Z+oy6NNMPi1xbQBO9FaTJNdfabA0auQhD2Oz5cLeMlh5UnesYAeEXR7OKowQe9E1OmX2 lmTHSm5C/N8Wj6J3a54ipKG1m4Ym0pAYG44XI= MIME-Version: 1.0 Received: by 10.42.144.8 with SMTP id z8mr5973713icu.187.1309289384974; Tue, 28 Jun 2011 12:29:44 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.219.138 with HTTP; Tue, 28 Jun 2011 12:29:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jun 2011 15:29:44 -0400 X-Google-Sender-Auth: ZN6b5pTsuLy_acrhFyyascXSFHQ Message-ID: From: Adam Langley To: Tony Finch Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:29:46 -0000 On Tue, Jun 28, 2011 at 3:25 PM, Tony Finch wrote: > Why not DNS wire format? i.e. concatenate the usual encoding of > (1) the trust anchor DNSKEY + RRSIG DNSKEY RRs; > (2) for each intermediate zone cut, > (2a) the delegation DS + RRSIG DS RRs; > (2b) the apex DNSKEY + RRSIG DNSKEY RRs; > (3) the final RR set + RRSIG. It basically is that. The reason for deviating from that exactly are that I want to keep the chain as small as possible by omitting parts of it where possible. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From fanf2@hermes.cam.ac.uk Tue Jun 28 12:44:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88EB11E819E for ; Tue, 28 Jun 2011 12:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TQ04ylyrVV5 for ; Tue, 28 Jun 2011 12:44:16 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA4011E819D for ; Tue, 28 Jun 2011 12:44: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]:57920) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QbeCk-0004ma-DD (Exim 4.72) (return-path ); Tue, 28 Jun 2011 20:44:14 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QbeCk-0000N7-2l (Exim 4.67) (return-path ); Tue, 28 Jun 2011 20:44:14 +0100 Date: Tue, 28 Jun 2011 20:44:14 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adam Langley In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:44:17 -0000 Adam Langley wrote: > On Tue, Jun 28, 2011 at 3:25 PM, Tony Finch wrote: > > > > Why not DNS wire format? > > It basically is that. The reason for deviating from that exactly are > that I want to keep the chain as small as possible by omitting parts > of it where possible. How much space do you save in practice? Tony. -- f.anthony.n.finch http://dotat.at/ Dover, Wight: Mainly west or northwest 4 or 5, increasing 6 at times. Slight or moderate. Thundery showers then fair. Moderate or poor becoming good. From alangley@gmail.com Tue Jun 28 12:54:50 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4DF11E818F for ; Tue, 28 Jun 2011 12:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBdiWLoz9QDd for ; Tue, 28 Jun 2011 12:54:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E62A711E8126 for ; Tue, 28 Jun 2011 12:54:49 -0700 (PDT) Received: by iwn39 with SMTP id 39so585693iwn.31 for ; Tue, 28 Jun 2011 12:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=UR3LJpmpT7w5xOw0wbae2m6whhInK/a9MQdd5o7dlPY=; b=UmO/k7rxuYLtHjVrm0/HS5tzbGznMdLEYPdIIXZH0Nq4en7IKyZHY2eGNYtgeIe3Tf 2GW1vjJP3KGnBBWqJD3F/PcB9KoNxA/eLPtBsi/EztW0z+tB9zwsllY5jaMxk992BGQt kGm3p5zre2AkS7HT/j4s6KMHeS3zei9Lgocow= MIME-Version: 1.0 Received: by 10.42.133.66 with SMTP id g2mr8414380ict.388.1309290888835; Tue, 28 Jun 2011 12:54:48 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.219.138 with HTTP; Tue, 28 Jun 2011 12:54:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jun 2011 15:54:48 -0400 X-Google-Sender-Auth: O-E-jXRxwGCeMVn_DD0_J-t-R38 Message-ID: From: Adam Langley To: Tony Finch Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:54:50 -0000 On Tue, Jun 28, 2011 at 3:44 PM, Tony Finch wrote: > How much space do you save in practice? Well, for a simple case we save the root key (256 bytes), 3 DS records (two from . to org and from from org to imperialviolet.org, 148 bytes) and a DSSIG (128 bytes). The resulting chain would have been 2820 bytes and it's now only 2288 bytes, so ~15%. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From fanf2@hermes.cam.ac.uk Tue Jun 28 13:01:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F408711E8126 for ; Tue, 28 Jun 2011 13:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZiWB8vgZaiN for ; Tue, 28 Jun 2011 13:01:07 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 386D111E8120 for ; Tue, 28 Jun 2011 13:01:07 -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]:44305) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QbeT4-0007H0-r9 (Exim 4.72) (return-path ); Tue, 28 Jun 2011 21:01:06 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QbeT4-0002dJ-Ez (Exim 4.67) (return-path ); Tue, 28 Jun 2011 21:01:06 +0100 Date: Tue, 28 Jun 2011 21:01:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adam Langley In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:01:08 -0000 Adam Langley wrote: > > Well, for a simple case we save the root key (256 bytes), 3 DS records > (two from . to org and from from org to imperialviolet.org, 148 bytes) > and a DSSIG (128 bytes). > > The resulting chain would have been 2820 bytes and it's now only 2288 > bytes, so ~15%. You can use the same logic to omit the same records from a wire format version of the trust chain so I don't think the saving is that big. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides, Bailey: West or southwest 4 or 5. Moderate. Showers. Good. From alangley@gmail.com Tue Jun 28 13:06:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45FE21F8584 for ; Tue, 28 Jun 2011 13:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHZ56eN8fGEJ for ; Tue, 28 Jun 2011 13:06:11 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3585A21F8583 for ; Tue, 28 Jun 2011 13:06:11 -0700 (PDT) Received: by iwn39 with SMTP id 39so596988iwn.31 for ; Tue, 28 Jun 2011 13:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=RV5WMZGUAepJgRRrosF8KJn+4srUN75HPdVGSYcs+Ug=; b=nYHfrXN4ZSWBtAukYDWKJjReh0yXLoeWYYwmLV5qsPNkbac6MeuLWo8iys7c+mBM0W BPIbmTDRjIuO3R2T3U0ru3ES9BMhxSaxxEGTzyYrigSCwH1/frY9/SPDTakKQkB2zJDy 2MjqZ9gR0NJF/mEERhjQwdC90YLalNienlVqs= MIME-Version: 1.0 Received: by 10.42.144.194 with SMTP id c2mr8897915icv.120.1309291570112; Tue, 28 Jun 2011 13:06:10 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.219.138 with HTTP; Tue, 28 Jun 2011 13:06:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jun 2011 16:06:10 -0400 X-Google-Sender-Auth: ZiPf_ucAGDCe-vaKfHqZNih_obs Message-ID: From: Adam Langley To: Tony Finch Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:06:11 -0000 On Tue, Jun 28, 2011 at 4:01 PM, Tony Finch wrote: > You can use the same logic to omit the same records from a wire format > version of the trust chain so I don't think the saving is that big. Which is pretty much what it is. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From fanf2@hermes.cam.ac.uk Tue Jun 28 13:12:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5E11E8126 for ; Tue, 28 Jun 2011 13:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4pGZCQ9w95e for ; Tue, 28 Jun 2011 13:11:59 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 210D111E80CA for ; Tue, 28 Jun 2011 13:11:58 -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]:36904) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QbedY-0001G8-QV (Exim 4.72) (return-path ); Tue, 28 Jun 2011 21:11:56 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QbedY-00044G-6T (Exim 4.67) (return-path ); Tue, 28 Jun 2011 21:11:56 +0100 Date: Tue, 28 Jun 2011 21:11:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Adam Langley In-Reply-To: Message-ID: References: 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: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:12:01 -0000 Adam Langley wrote: > On Tue, Jun 28, 2011 at 4:01 PM, Tony Finch wrote: > > You can use the same logic to omit the same records from a wire format > > version of the trust chain so I don't think the saving is that big. > > Which is pretty much what it is. Well no. The point of using exactly the standard wire format is so that you can re-use existing serializing and parsing code. Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, Faeroes: Variable mainly southwest 3 or 4, occasionally 5 at first. Slight or moderate. Showers. Moderate or good. From rbarnes@bbn.com Tue Jun 28 13:15:16 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E127421F8577 for ; Tue, 28 Jun 2011 13:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNCnkV4A2KzT for ; Tue, 28 Jun 2011 13:15:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5190121F857D for ; Tue, 28 Jun 2011 13:15:16 -0700 (PDT) Received: from [128.89.253.252] (port=57870 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qbegk-0006Pv-QV; Tue, 28 Jun 2011 16:15:15 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 28 Jun 2011 16:15:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> References: To: Tony Finch X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:15:17 -0000 I'm guessing that part of the reason that Adam didn't use the wire = formats in the first place is that your average DNS library doesn't give = you access to raw RDATA, so you basically have to re-serialize it. In = particular, Adam's generation tool uses "dig" to get DNS info, which = indeed does not provide raw wire-format bytes. --Richard On Jun 28, 2011, at 4:11 PM, Tony Finch wrote: > Adam Langley wrote: >> On Tue, Jun 28, 2011 at 4:01 PM, Tony Finch wrote: >>> You can use the same logic to omit the same records from a wire = format >>> version of the trust chain so I don't think the saving is that big. >>=20 >> Which is pretty much what it is. >=20 > Well no. The point of using exactly the standard wire format is so = that > you can re-use existing serializing and parsing code. >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Fair Isle, Faeroes: Variable mainly southwest 3 or 4, occasionally 5 = at first. > Slight or moderate. Showers. Moderate or good. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From Jeff.Hodges@KingsMountain.com Tue Jun 28 13:41:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C718911E81B2 for ; Tue, 28 Jun 2011 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETqt8lX6rfHV for ; Tue, 28 Jun 2011 13:41:51 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 90A4A11E8100 for ; Tue, 28 Jun 2011 13:41:51 -0700 (PDT) Received: (qmail 21166 invoked by uid 0); 28 Jun 2011 20:41:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 28 Jun 2011 20:41:50 -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=HMTyeJbL3/7z7KXwhNmMoP6dBTsjSXrFKniZ0TGtz/S54Lvf+1eVa24fv3AxJPFAAUiebsDpU7LHn3VetqY6KaFdOZcgHiqdn7BP2LwUk3ojCm+Ij7J4GN2WD6dZH+2Z; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.251]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qbf6U-0006Qt-1B for dane@ietf.org; Tue, 28 Jun 2011 14:41:50 -0600 Message-ID: <4E0A3C8D.9080100@KingsMountain.com> Date: Tue, 28 Jun 2011 13:41:49 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF DANE WG list 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: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:41:52 -0000 > - Summary: I think it would be clearer to structure the draft as: > 1. Data structure > 2. How to construct the chain starting from a DNS name > 3. How to verify the chain > - It would be helpful to have a description of the data structure in "at > rest" form, as opposed to in "parsing stream" form, in order to separate > structure from parsing logic. > > - Because the description of verifier behavior is so focused on parsing, the > cryptographic verification steps kind of get lost. It took me a couple of > seconds to find the requirement for matching DS and DNSKEY. > > - The document doesn't say anything about how to construct a chain starting > from a DNS name. Given that chain.py is 471 lines, this doesn't seem like a > trivial process! > > - Considering the differences from normal certs, e.g., in naming practices, > it might actually be helpful to have a separate certificate profile for > DNSSEC-stapled certificates, and to signal it with something like a CP OID > (as for EV). That wouldn't rule out the use of this extension with other > types of certs, but it would provide a simple flag that a stapled cert is > different from some other self-signed cert. > > Thanks for writing a spec, I think this could be a useful complement to the > DANE RR type. +1 to all of Richard's comments. =JeffH From hallam@gmail.com Tue Jun 28 13:46:39 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1208011E814D for ; Tue, 28 Jun 2011 13:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NT7sMWwlM7s for ; Tue, 28 Jun 2011 13:46:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F408C11E8100 for ; Tue, 28 Jun 2011 13:46:37 -0700 (PDT) Received: by yxp4 with SMTP id 4so335558yxp.31 for ; Tue, 28 Jun 2011 13:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RRNk/69WYu58p9cfra/iOY1d2MQXr56Cbn67+LcxZ7A=; b=xzCTvS9TZCZeFdoYQyt+0Km1vJjJWqD36LuO0Su8UoCscTmj2TjbD+vGbzJwHbDFey gstVO6OtuJpEJEBCHIHQJCRySPm/72nsZjzqKVhD+hzKyyqgKBH73dfoimaoK4GhkR1W exPp6AkKU1Y03GUDGWrphm2K2L6A4BhWfqiC8= MIME-Version: 1.0 Received: by 10.101.149.32 with SMTP id b32mr427127ano.150.1309293996470; Tue, 28 Jun 2011 13:46:36 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Tue, 28 Jun 2011 13:46:36 -0700 (PDT) In-Reply-To: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> Date: Tue, 28 Jun 2011 16:46:36 -0400 Message-ID: From: Phillip Hallam-Baker To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=0016e68dcedd90f20104a6cbc391 Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:46:39 -0000 --0016e68dcedd90f20104a6cbc391 Content-Type: text/plain; charset=ISO-8859-1 I think it would also be good to try to get ordering in there so that the complexity of verification can be minimized. A lot of the complexity of PKIX path math and DNSSEC validation comes from the fact that the information received can come in any order, can be incomplete and can be redundant. Oddly enough, even though X.509 requires the use of the totally pointless DER encoding which is a PITA to implement, pretty much every PKI application allows cert chains to be presented in any order the provider chooses. PKIX trust paths can have multiple roots, cross certs etc. so it would be hard to do. But DNSSEC has a single root so it would be good if the spec said to traverse in one way or the other. On Tue, Jun 28, 2011 at 4:15 PM, Richard L. Barnes wrote: > I'm guessing that part of the reason that Adam didn't use the wire formats > in the first place is that your average DNS library doesn't give you access > to raw RDATA, so you basically have to re-serialize it. In particular, > Adam's generation tool uses "dig" to get DNS info, which indeed does not > provide raw wire-format bytes. > > --Richard > > > > On Jun 28, 2011, at 4:11 PM, Tony Finch wrote: > > > Adam Langley wrote: > >> On Tue, Jun 28, 2011 at 4:01 PM, Tony Finch wrote: > >>> You can use the same logic to omit the same records from a wire format > >>> version of the trust chain so I don't think the saving is that big. > >> > >> Which is pretty much what it is. > > > > Well no. The point of using exactly the standard wire format is so that > > you can re-use existing serializing and parsing code. > > > > Tony. > > -- > > f.anthony.n.finch http://dotat.at/ > > Fair Isle, Faeroes: Variable mainly southwest 3 or 4, occasionally 5 at > first. > > Slight or moderate. Showers. Moderate or good. > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68dcedd90f20104a6cbc391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would also be good to try to get ordering in there so that the c= omplexity of verification can be minimized.

A lot of the= complexity of PKIX path math and DNSSEC validation comes from the fact tha= t the information received can come in any order, can be incomplete and can= be redundant.

Oddly enough, even though X.509 requires the use of the= totally pointless DER encoding which is a PITA to implement, pretty much e= very PKI application allows cert chains to be presented in any order the pr= ovider chooses.=A0


PKIX trust paths can have multiple roots= , cross certs etc. so it would be hard to do. But DNSSEC has a single root = so it would be good if the spec said to traverse in one way or the other.


On Tue, Jun 28, 2011 at 4:15 PM, Ri= chard L. Barnes <rb= arnes@bbn.com> wrote:
I'm guessing that part of the reason that Adam didn't use the wire = formats in the first place is that your average DNS library doesn't giv= e you access to raw RDATA, so you basically have to re-serialize it. =A0In = particular, Adam's generation tool uses "dig" to get DNS info= , which indeed does not provide raw wire-format bytes.

--Richard



On Jun 28, 2011, at 4:11 PM, Tony Finch wrote:

> Adam Langley <agl@imperia= lviolet.org> wrote:
>> On Tue, Jun 28, 2011 at 4:01 PM, Tony Finch <dot@dotat.at> wrote:
>>> You can use the same logic to omit the same records from a wir= e format
>>> version of the trust chain so I don't think the saving is = that big.
>>
>> Which is pretty much what it is.
>
> Well no. The point of using exactly the standard wire format is so tha= t
> you can re-use existing serializing and parsing code.
>
> Tony.
> --
> f.anthony.n.finch =A0<dot@dotat.at<= /a>> =A0http://dotat.at/<= /a>
> Fair Isle, Faeroes: Variable mainly southwest 3 or 4, occasionally 5 a= t first.
> Slight or moderate. Showers. Moderate or good.
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016e68dcedd90f20104a6cbc391-- From alangley@gmail.com Tue Jun 28 14:23:31 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8083411E80C0 for ; Tue, 28 Jun 2011 14:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM75ZJxG7oRi for ; Tue, 28 Jun 2011 14:23:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E43511E808C for ; Tue, 28 Jun 2011 14:23:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so667066iwn.31 for ; Tue, 28 Jun 2011 14:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=37zEuuSohd7MzQ5CyCKsdMfpodK4zVD/g/A3dESOWNA=; b=p2ZO1Qnxr8/gS9V1CpzP5zTeB91p8LPFUVTONSojPwpEIShdvSXBiYu/yKw9tIXLNo r3qX/gLZQc82L31xKDd3bjxsS8IFOUaSlmDz8qHm2eJnUqlT0WLeVgmVMOVYDqSblyMS yE9xry0eOaj8g8jNisSZ7C0KL82FNJoDDD3X4= MIME-Version: 1.0 Received: by 10.42.144.8 with SMTP id z8mr40013icu.187.1309296205702; Tue, 28 Jun 2011 14:23:25 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.219.138 with HTTP; Tue, 28 Jun 2011 14:23:25 -0700 (PDT) In-Reply-To: References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> Date: Tue, 28 Jun 2011 17:23:25 -0400 X-Google-Sender-Auth: WIUpVk5Us6ooHSJdXOLFoXkvVxI Message-ID: From: Adam Langley To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:23:32 -0000 On Tue, Jun 28, 2011 at 4:46 PM, Phillip Hallam-Baker wrote: > PKIX trust paths can have multiple roots, cross certs etc. so it would be > hard to do. But DNSSEC has a single root so it would be good if the spec > said to traverse in one way or the other. The draft, as is, requires that the serialization start at the initial zone (probably the root) and that each step match more labels (counting right to left) of the target name. I believe that only permits a single order. Additionally, the embedded RRDATAs must be in DNSSEC canonical ordering. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From marka@isc.org Tue Jun 28 19:27:03 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38EB11E810A for ; Tue, 28 Jun 2011 19:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERatWYMMTVC5 for ; Tue, 28 Jun 2011 19:27:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D002511E80F8 for ; Tue, 28 Jun 2011 19:27:02 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 80B69C9463; Wed, 29 Jun 2011 02:26:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 18A0F216C7B; Wed, 29 Jun 2011 02:26:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 145871146A84; Wed, 29 Jun 2011 12:26:48 +1000 (EST) To: "Richard L. Barnes" From: Mark Andrews References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> In-reply-to: Your message of "Tue, 28 Jun 2011 16:15:12 -0400." <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> Date: Wed, 29 Jun 2011 12:26:48 +1000 Message-Id: <20110629022648.145871146A84@drugs.dv.isc.org> Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 02:27:04 -0000 In message <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com>, "Richard L. Barnes" writes: > I'm guessing that part of the reason that Adam didn't use the wire formats in > the first place is that your average DNS library doesn't give you access to > raw RDATA, so you basically have to re-serialize it. In particular, Adam's g > eneration tool uses "dig" to get DNS info, which indeed does not provide raw > wire-format bytes. > > --Richard Actually your average DNS library MUST give you access to the raw forms to support unknown RR types. "dig" is not a library. It is a diagnotic tool and it will printout unknown records. It just doesn't have a flag to print them all out as unknown. Mark ; <<>> DiG 8.3 <<>> ns . +dnssec ;; res options: init recurs defnam dnsrch no-tld-query dnssec edns0 ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34629 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 3 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 4d6h2m39s IN NS k.root-servers.net. . 4d6h2m39s IN NS g.root-servers.net. . 4d6h2m39s IN NS d.root-servers.net. . 4d6h2m39s IN NS l.root-servers.net. . 4d6h2m39s IN NS b.root-servers.net. . 4d6h2m39s IN NS a.root-servers.net. . 4d6h2m39s IN NS c.root-servers.net. . 4d6h2m39s IN NS h.root-servers.net. . 4d6h2m39s IN NS m.root-servers.net. . 4d6h2m39s IN NS e.root-servers.net. . 4d6h2m39s IN NS i.root-servers.net. . 4d6h2m39s IN NS j.root-servers.net. . 4d6h2m39s IN NS f.root-servers.net. . 5d21h35m46s IN TYPE46 \# 147 ( ; unknown RR type 00 02 08 00 00 07 e9 00 4e 12 54 00 4e 09 0b 70 ; ........N.T.N..p 86 dd 00 7e 43 b6 6e 18 f5 48 e7 a5 20 12 09 96 ; ...~C.n..H.. ... 24 73 36 35 25 1d 95 12 fd 4b 42 e8 6f 17 fb aa ; $s65%....KB.o... 5e 09 74 87 52 46 e1 fb cf 98 bc 57 c9 07 71 70 ; ^.t.RF.....W..qp e5 cb 5d 69 26 22 a4 99 2f bc 81 90 a1 0d 4e 14 ; ..]i&"../.....N. a0 7c b2 c9 71 a2 08 01 69 eb c1 1e 14 e7 85 a4 ; .|..q...i....... 57 c7 5e 52 95 b3 03 9f e5 34 f6 b5 cf 31 03 d3 ; W.^R.....4...1.. ff 94 c1 4d 0b d1 a7 ee e8 0a 05 8b ba e0 fc 1f ; ...M............ 94 c9 ff d9 11 1f cf cd 0d bb 72 03 c9 5f 9a 46 ; ..........r.._.F 3c da f8 ) ; <.. ;; ADDITIONAL SECTION: f.root-servers.net. 3d5h30m44s IN A 192.5.5.241 f.root-servers.net. 3d5h30m44s IN AAAA 2001:500:2f::f ; EDNS: version: 0, udp=4096, flags=8000 ;; Total query time: 14 msec ;; FROM: bsdi.dv.isc.org to SERVER: 127.0.0.1 ;; WHEN: Wed Jun 29 12:24:14 2011 ;; MSG SIZE sent: 28 rcvd: 441 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Tue Jun 28 20:55:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F62211E80A0 for ; Tue, 28 Jun 2011 20:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoKk4yEoccVr for ; Tue, 28 Jun 2011 20:55:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8EF211E808D for ; Tue, 28 Jun 2011 20:55:08 -0700 (PDT) Received: by ywp31 with SMTP id 31so438925ywp.31 for ; Tue, 28 Jun 2011 20:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FVKlTqKe0DdEqj6ufaMcpC77o5kAV/6dKrTC9lVwFVc=; b=GD4FYyvXs6oavdLsvDlHwgSpXmqSWCFURi+J7Xy/ru9rKalZPey44jifI+IVbEnLvC QA/YcacfZf5w8X1FNcOcI14tDyTCGmGkKbUGLsCE5USXmCK7OlI2R1Z7oPj7Z7DaP+2V ghogD7y48k6if/cUjzJLbsVg2WL5/tpcVf0Tw= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr222161anh.40.1309319708015; Tue, 28 Jun 2011 20:55:08 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Tue, 28 Jun 2011 20:55:07 -0700 (PDT) In-Reply-To: <20110629022648.145871146A84@drugs.dv.isc.org> References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> Date: Tue, 28 Jun 2011 23:55:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=0016369fa25217fc1204a6d1c0ec Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 03:55:20 -0000 --0016369fa25217fc1204a6d1c0ec Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 28, 2011 at 10:26 PM, Mark Andrews wrote: > > In message <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com>, "Richard L. > Barnes" > writes: > > I'm guessing that part of the reason that Adam didn't use the wire > formats in > > the first place is that your average DNS library doesn't give you access > to > > raw RDATA, so you basically have to re-serialize it. In particular, > Adam's g > > eneration tool uses "dig" to get DNS info, which indeed does not provide > raw > > wire-format bytes. > > > > --Richard > > Actually your average DNS library MUST give you access to the raw > forms to support unknown RR types. You are rather lucky if your average DNS library supports SRV records, let alone the unknown records. This is being fixed, but the state of the application world is much worse than most imagine. > -- Website: http://hallambaker.com/ --0016369fa25217fc1204a6d1c0ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2011 at 10:26 PM, Mark A= ndrews <marka@isc.org= > wrote:

In message <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com>, "Richard L. = Barnes"
writes:
> I'm guessing that part of the reason that Adam d= idn't use the wire formats in
> the first place is that your average DNS library doesn't give you = access to
> raw RDATA, so you basically have to re-serialize it. =A0In particular,= Adam's g
> eneration tool uses "dig" to get DNS info, which indeed does= not provide raw
> wire-format bytes.
>
> --Richard

Actually your average DNS library MUST give you access to the raw
forms to support unknown RR types.

You are = rather lucky if your average DNS library supports SRV records, let alone th= e unknown records.

This is being fixed, but the st= ate of the application world is much worse than most imagine.

=A0
=A0
--
Website: http://hallamba= ker.com/

--0016369fa25217fc1204a6d1c0ec-- From marka@isc.org Tue Jun 28 21:34:53 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73E822800E for ; Tue, 28 Jun 2011 21:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCOXrq14Jfbb for ; Tue, 28 Jun 2011 21:34:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7E667228006 for ; Tue, 28 Jun 2011 21:34:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id D1F375F98E7; Wed, 29 Jun 2011 04:34:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D6ED9216C7B; Wed, 29 Jun 2011 04:34:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1AE571147954; Wed, 29 Jun 2011 14:34:19 +1000 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> In-reply-to: Your message of "Tue, 28 Jun 2011 23:55:07 -0400." Date: Wed, 29 Jun 2011 14:34:19 +1000 Message-Id: <20110629043419.1AE571147954@drugs.dv.isc.org> Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 04:34:53 -0000 In message , Phillip Hallam- Baker writes: > --0016369fa25217fc1204a6d1c0ec > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Jun 28, 2011 at 10:26 PM, Mark Andrews wrote: > > > > > In message <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com>, "Richard L. > > Barnes" > > writes: > > > I'm guessing that part of the reason that Adam didn't use the wire > > formats in > > > the first place is that your average DNS library doesn't give you access > > to > > > raw RDATA, so you basically have to re-serialize it. In particular, > > Adam's g > > > eneration tool uses "dig" to get DNS info, which indeed does not provide > > raw > > > wire-format bytes. > > > > > > --Richard > > > > Actually your average DNS library MUST give you access to the raw > > forms to support unknown RR types. > > You are rather lucky if your average DNS library supports SRV records, let > alone the unknown records. > > This is being fixed, but the state of the application world is much worse > than most imagine. You average resolver library can look up all types. It may not be able to break them down in type specific ways but it can return a answer from which the application can extract the desired records. To look up a submission SRV records one would do the following in the 1982 version of libresolv. unsigned char buf[65535]; int n; n = res_query("_submission._tcp.example.net", C_IN, 33, buf, sizeof(buf)); You then need to parse buf to extract the SRV record but that is all well defined. Which is almost identical to how you would query for it with a modern version of libresolv. unsigned char buf[65535]; int n; n = res_query("_submission._tcp.example.net", ns_c_in, ns_t_srv, buf, sizeof(buf)); One can do similar with most other resolver libraries. Some will give you the entire DNS response. Others will extract the records for you and present them as opaque blobs. The DNS message format was designed to allow unknown records types to be queried for and returned without the intermedite nameservers and libraries knowing anything about the type. RFC 1034 and RFC 1035 supported the passing of unknown record types. They just didn't have a master file format for them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Tue Jun 28 22:50:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4946011E8078 for ; Tue, 28 Jun 2011 22:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w36qmWdLgmm5 for ; Tue, 28 Jun 2011 22:50:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD439E8004 for ; Tue, 28 Jun 2011 22:50:55 -0700 (PDT) Received: by gyd5 with SMTP id 5so99560gyd.31 for ; Tue, 28 Jun 2011 22:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jCvhhjXHoeNs+1xm2VV35YOs8wenTnEPR+gCyzXBa2w=; b=cBq4CMkh5TFsAaOH8Vwj9EN9tXeGoslG6HK8oj6C0xEAvS/vTAvcjYJ/y1hcgaULsL kWIR9wGy/WRRKruv55E5W+KYugsxzcc5MIlP9HpQU1keiM8G9F+QdwsgeJ5hgdhwUR7I vjtwwMd46yK5P6sOCzhxpfP9hcr/NQwDj5OJQ= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr275468anh.40.1309326653919; Tue, 28 Jun 2011 22:50:53 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Tue, 28 Jun 2011 22:50:53 -0700 (PDT) In-Reply-To: <20110629043419.1AE571147954@drugs.dv.isc.org> References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> <20110629043419.1AE571147954@drugs.dv.isc.org> Date: Wed, 29 Jun 2011 01:50:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=0016369fa2521a118604a6d35e24 Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 05:50:56 -0000 --0016369fa2521a118604a6d35e24 Content-Type: text/plain; charset=ISO-8859-1 I guess that would work for the application programmers who still code in C or C++. That is not where the industry has been for a decade now. On Wed, Jun 29, 2011 at 12:34 AM, Mark Andrews wrote: > > In message , Phillip > Hallam- > Baker writes: > > --0016369fa25217fc1204a6d1c0ec > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Tue, Jun 28, 2011 at 10:26 PM, Mark Andrews wrote: > > > > > > > > In message <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com>, "Richard L. > > > Barnes" > > > writes: > > > > I'm guessing that part of the reason that Adam didn't use the wire > > > formats in > > > > the first place is that your average DNS library doesn't give you > access > > > to > > > > raw RDATA, so you basically have to re-serialize it. In particular, > > > Adam's g > > > > eneration tool uses "dig" to get DNS info, which indeed does not > provide > > > raw > > > > wire-format bytes. > > > > > > > > --Richard > > > > > > Actually your average DNS library MUST give you access to the raw > > > forms to support unknown RR types. > > > > You are rather lucky if your average DNS library supports SRV records, > let > > alone the unknown records. > > > > This is being fixed, but the state of the application world is much worse > > than most imagine. > > You average resolver library can look up all types. It may > not be able to break them down in type specific ways but > it can return a answer from which the application can extract > the desired records. > > To look up a submission SRV records one would do the following > in the 1982 version of libresolv. > > unsigned char buf[65535]; > int n; > > n = res_query("_submission._tcp.example.net", C_IN, 33, buf, > sizeof(buf)); > > You then need to parse buf to extract the SRV record but > that is all well defined. > > Which is almost identical to how you would query for it with a > modern > version of libresolv. > > unsigned char buf[65535]; > int n; > > n = res_query("_submission._tcp.example.net", ns_c_in, ns_t_srv, > buf, > sizeof(buf)); > > One can do similar with most other resolver libraries. Some > will give you the entire DNS response. Others will extract > the records for you and present them as opaque blobs. > > The DNS message format was designed to allow unknown records > types to be queried for and returned without the intermedite > nameservers and libraries knowing anything about the type. > > RFC 1034 and RFC 1035 supported the passing of unknown record > types. They just didn't have a master file format for them. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Website: http://hallambaker.com/ --0016369fa2521a118604a6d35e24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess that would work for the application programmers who still code in C= or C++. That is not where the industry has been for a decade now.

=



On = Wed, Jun 29, 2011 at 12:34 AM, Mark Andrews <marka@isc.org> wrote:

In message <BANLkTi=3D-0zaza7s8KJ4+iFuq++qErk0fNQ@mail.gmail.com>, Philli= p Hallam-
Baker writes:
> --0016369fa25217fc1204a6d1c0ec
> Content-Type: text/plain; charset=3DISO-8859-1
>
> On Tue, Jun 28, 2011 at 10:26 PM, Mark Andrews <marka@isc.org> wrote:
>
> >
> > In message <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com>, "R= ichard L.
> > Barnes"
> > writes:
> > > I'm guessing that part of the reason that Adam didn'= t use the wire
> > formats in
> > > the first place is that your average DNS library doesn't= give you access
> > to
> > > raw RDATA, so you basically have to re-serialize it. =A0In p= articular,
> > Adam's g
> > > eneration tool uses "dig" to get DNS info, which i= ndeed does not provide
> > raw
> > > wire-format bytes.
> > >
> > > --Richard
> >
> > Actually your average DNS library MUST give you access to the raw=
> > forms to support unknown RR types.
>
> You are rather lucky if your average DNS library supports SRV records,= let
> alone the unknown records.
>
> This is being fixed, but the state of the application world is much wo= rse
> than most imagine.

=A0 =A0 =A0 =A0You average resolver library can look up all ty= pes. =A0It may
=A0 =A0 =A0 =A0not be able to break them down in type specific ways but =A0 =A0 =A0 =A0it can return a answer from which the application can extra= ct
=A0 =A0 =A0 =A0the desired records.

=A0 =A0 =A0 =A0To look up a submission SRV records one would do the follow= ing
=A0 =A0 =A0 =A0in the 1982 version of libresolv.

=A0 =A0 =A0 =A0unsigned char buf[65535];
=A0 =A0 =A0 =A0int n;

=A0 =A0 =A0 =A0n =3D res_query("_submission._tcp.example.net", C_IN, 33, buf,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(buf));

=A0 =A0 =A0 =A0You then need to parse buf to extract the SRV record but =A0 =A0 =A0 =A0that is all well defined.

=A0 =A0 =A0 =A0Which is almost identical to how you would query for it wit= h a modern
=A0 =A0 =A0 =A0version of libresolv.

=A0 =A0 =A0 =A0unsigned char buf[65535];
=A0 =A0 =A0 =A0int n;

=A0 =A0 =A0 =A0n =3D res_query("_submission._tcp.example.net", ns_c_in, ns_t_srv, = buf,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(buf));

=A0 =A0 =A0 =A0One can do similar with most other resolver libraries. =A0S= ome
=A0 =A0 =A0 =A0will give you the entire DNS response. =A0Others will extra= ct
=A0 =A0 =A0 =A0the records for you and present them as opaque blobs.

=A0 =A0 =A0 =A0The DNS message format was designed to allow unknown record= s
=A0 =A0 =A0 =A0types to be queried for and returned without the intermedit= e
=A0 =A0 =A0 =A0nameservers and libraries knowing anything about the type.<= br>
=A0 =A0 =A0 =A0RFC 1034 and RFC 1035 supported the passing of unknown reco= rd
=A0 =A0 =A0 =A0types. =A0They just didn't have a master file format fo= r them.

=A0 =A0 =A0 =A0Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org



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

--0016369fa2521a118604a6d35e24-- From marka@isc.org Tue Jun 28 23:21:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000E39E8004 for ; Tue, 28 Jun 2011 23:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoepJ9v8hGQe for ; Tue, 28 Jun 2011 23:21:36 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4368022800E for ; Tue, 28 Jun 2011 23:21:36 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7BF7AC944A; Wed, 29 Jun 2011 06:21:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3C78E216C80; Wed, 29 Jun 2011 06:21:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D420A1147E37; Wed, 29 Jun 2011 16:21:21 +1000 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> <20110629043419.1AE571147954@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 29 Jun 2011 01:50:53 -0400." Date: Wed, 29 Jun 2011 16:21:21 +1000 Message-Id: <20110629062121.D420A1147E37@drugs.dv.isc.org> Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 06:21:37 -0000 In message , Phillip Hallam- Baker writes: > I guess that would work for the application programmers who still code in C > or C++. That is not where the industry has been for a decade now. The concepts are language independent. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Wed Jun 29 02:47:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7D021F86B9 for ; Wed, 29 Jun 2011 02:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1vWf7lSV0JJ for ; Wed, 29 Jun 2011 02:47:04 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3EE21F84AE for ; Wed, 29 Jun 2011 02:47: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]:45097) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1QbrML-0001pI-qt (Exim 4.72) (return-path ); Wed, 29 Jun 2011 10:47:01 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QbrML-00041a-CN (Exim 4.67) (return-path ); Wed, 29 Jun 2011 10:47:01 +0100 Date: Wed, 29 Jun 2011 10:47:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Richard L. Barnes" In-Reply-To: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> Message-ID: References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> 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: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 09:47:05 -0000 Richard L. Barnes wrote: > I'm guessing that part of the reason that Adam didn't use the wire > formats in the first place is that your average DNS library doesn't give > you access to raw RDATA, so you basically have to re-serialize it. The standard Unix resolver library gives you the necessary tools to handle wire format DNS data. If you want something higher-level, use ldns. It looks like just the thing for this task. Tony. -- f.anthony.n.finch http://dotat.at/ Northwest FitzRoy, Sole: Northwesterly 4 or 5, becoming variable 3 or 4. Moderate. Fair. Good. From alangley@gmail.com Wed Jun 29 04:21:54 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A519E8045 for ; Wed, 29 Jun 2011 04:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri+9kNG2Ze7j for ; Wed, 29 Jun 2011 04:21:53 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1C09E8043 for ; Wed, 29 Jun 2011 04:21:53 -0700 (PDT) Received: by iwn39 with SMTP id 39so1252220iwn.31 for ; Wed, 29 Jun 2011 04:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=CrgIXfbQVSTnBoavERLUEJZozsBCRiBFnyPpulfZqSs=; b=Tw9hDqGtfxL4WvpYlc7PnCEfKczlnq+pCavHdEVN1u5U4UWowW8lkUhAJG1K3aiBSB p0gcIew8137iBAKaH9HVcFUt1cQruRLfuEaPT1THcpE99FIVCOfQccCD7Gn+2RILfOAq 7tP8ERsoYuwo2VZk2MjX7zWytGsLXwIb4vMLE= MIME-Version: 1.0 Received: by 10.42.39.210 with SMTP id i18mr744381ice.53.1309346512654; Wed, 29 Jun 2011 04:21:52 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.213.9 with HTTP; Wed, 29 Jun 2011 04:21:52 -0700 (PDT) In-Reply-To: <7ADA424A25710B41B7C8201DA111AF190882236CA1@mail01.certezza.local> References: <7ADA424A25710B41B7C8201DA111AF190882236CA1@mail01.certezza.local> Date: Wed, 29 Jun 2011 07:21:52 -0400 X-Google-Sender-Auth: yxQ13v6z0sxFdxqtyAgxZuzxsj0 Message-ID: From: Adam Langley To: Rickard Bellgrim Content-Type: text/plain; charset=UTF-8 Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 11:21:54 -0000 On Wed, Jun 29, 2011 at 2:19 AM, Rickard Bellgrim wrote: > Isn't the initial_key_tag a little bit weak as a trust anchor? You could easily get a collision here. Perhaps using the DS as initial_ds instead of initial_key_tag? It's only used in the same way as in DNSSEC: an optimisation. If you have multiple keys with the same key tag then you have to try all of them. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From hallam@gmail.com Wed Jun 29 08:36:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685C721F8560 for ; Wed, 29 Jun 2011 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMZ5uNKtI45c for ; Wed, 29 Jun 2011 08:36:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB2C21F855F for ; Wed, 29 Jun 2011 08:36:21 -0700 (PDT) Received: by gyd5 with SMTP id 5so307176gyd.31 for ; Wed, 29 Jun 2011 08:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E3iYV13xSd3WuAL+m7apjH88a1845+3zjU9pt8GxQck=; b=YmIdyJXMB00MFmyc/yYAZ8pXjsi/xFfp2EEBuOitdD8c2jROla/4Fcop7omfHcM/M4 Z9joHEvRrdI8eX1OYkoHEOJ7VXY2T+oGZuSjuZVFvsCwk2Zj5/7Nf51/jNR4UZejk8rE MI1rj4P8PwRnOx2i+NS8XgD7tb0CChMOhECJY= MIME-Version: 1.0 Received: by 10.101.164.38 with SMTP id r38mr777201ano.106.1309361778847; Wed, 29 Jun 2011 08:36:18 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Wed, 29 Jun 2011 08:36:18 -0700 (PDT) In-Reply-To: <20110629062121.D420A1147E37@drugs.dv.isc.org> References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> <20110629043419.1AE571147954@drugs.dv.isc.org> <20110629062121.D420A1147E37@drugs.dv.isc.org> Date: Wed, 29 Jun 2011 11:36:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=0016e68debd4b5f20c04a6db8b0b Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 15:36:23 -0000 --0016e68debd4b5f20c04a6db8b0b Content-Type: text/plain; charset=ISO-8859-1 The concepts are independent, the code most certainly is not. This is why I have spent the past few weeks writing a DNS resolver in C# to hopefully render the issue moot. While you can call unmanaged code from a managed environment like C#, the means of doing so is not at all pretty. And making the result threadsafe is a nightmare. It is in fact much easier to recode from scratch than to use the existing stuff. Calling a math function or a crypto algorithm is one thing, but a DNS library is by its very nature asynchronous and it is possible to have multiple queries in flight at the same time. I suspect that a lot of the objections to using DNS for more sophisticated discovery come from the lack of decent DNS library support in modern programming languages. It is easy enough to support an API like this with blocking code: EDNS.Client resolver = new EDNS.Client (); EDNS.DNSMessage Response; int result = resolver.Resolve (Domain, EDNS.DNSType.CAA, out Response); But most of us would like to have multiple queries in parallel: DNSClient Client = new DNSClient (); // Non blocking request DNSMessage Request = new DNSQueryMessage (Domain, EDNS.DNSType.A ); DNSTransaction Transaction1 = Client.Send (Request); DNSMessage Request = new DNSQueryMessage (Domain, EDNS.DNSType.CAA); DNSTransaction Transaction2 = Client.Send (Request); // Does other useful stuff like create the message headers // Can poll status of transactions using DNSTransaction.Complete () Response = Client.Receive (Transaction1); Response = Client.Receive (Transaction2); And that is still much less than you would want a .NET library to provide. A proper .NET library should let the caller loop things into the asynchronous caller. Ultimately, the goal is to produce a subclass of the TcpClient class such that the only difference that the programmer needs to consider is to replace the creation method: public TcpClient(string hostname, int port) with the creation method: public InternetClient(string hostname, string service, int port) The difference here is the level of abstraction. TcpClient connects via hostname and port and always returns a raw bytestream. InternetClient uses the DNS to determine what the best connection that is available for a service. If the best connection is raw TCP it will return that, if it can form an SSL socket, it will return that. [Yes, I know that there is also the question of how to specify 'best', but that is something that is more usually something you want to specify at the host level or higher and want to avoid embedding in actual applications] This actually has a major performance advantage in the right hands because the implementation can also be asynchronous. So in the typical calling sequence we would have: // Create the socket // Generate the message headers // Check the socket is OK // Send the first byte In terms of timing what would be going on is: // Create the socket [Async socket establishment starts] // Generate the message headers [Wait for the socket to be completed] // Check the socket is OK // Send the first byte Now in my preferred programming language, you could just throw up a PAR statement and it would work anyway, but very few programmers grok that sort of stuff. On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews wrote: > > In message , Phillip > Hallam- > Baker writes: > > I guess that would work for the application programmers who still code in > C > > or C++. That is not where the industry has been for a decade now. > > The concepts are language independent. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Website: http://hallambaker.com/ --0016e68debd4b5f20c04a6db8b0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The concepts are independent, the code most certainly is not.

This is why I have spent the past few weeks writing a DNS resolver in= C# to hopefully render the issue moot.


While you can call unmanaged code from a managed environment like C#, = the means of doing so is not at all pretty. And making the result threadsaf= e is a nightmare. It is in fact much easier to recode from scratch than to = use the existing stuff.

Calling a math function or a crypto algorithm is one th= ing, but a DNS library is by its very nature asynchronous and it is possibl= e to have multiple queries in flight at the same time. I suspect that a lot= of the objections to using DNS for more sophisticated discovery come from = the lack of decent DNS library support in modern programming languages.


It is easy enough to support an API like= this with blocking code:

=A0 =A0 EDNS.Client= resolver =3D new EDNS.Client ();

=A0 =A0 EDNS.DNS= Message Response;
=A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, out= Response);


But most of us wo= uld like to have multiple queries in parallel:

=A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient ();
<= div>
=A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request
=A0 =A0 =A0 =A0 =A0 =A0 DNSMessage = Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.A);
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Client.S= end (Request);

=A0 =A0 =A0 =A0 =A0 =A0 D= NSMessage Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.CAA);
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Client= .Send (Request);

=A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuf= f like create the message headers
=A0 =A0 =A0 =A0 =A0 =A0 // Can = poll status of transactions using=A0DNSTransaction.Complete ()
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Tran= saction1);
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transa= ction2);


And that is still mu= ch less than you would want a .NET library to provide. A proper .NET librar= y should let the caller loop things into the asynchronous caller.

Ultimately, the goal is to produce a subclass of the Tc= pClient class such that the only difference that the programmer needs to co= nsider is to replace the creation method:

public TcpClient(string hostname, int p=
ort)

with the creation method:
<= div> 
public InternetClient(string hostname, string<=
/span> service, int port)


<= div> The difference here is the level of abstraction. TcpClient connects via hos= tname and port and always returns a raw bytestream. InternetClient uses the= DNS to determine what the best connection that is available for a service.= If the best connection is raw TCP it will return that, if it can form an S= SL socket, it will return that.

[Yes, I know that there is also the question of how to = specify 'best', but that is something that is more usually somethin= g you want to specify at the host level or higher and want to avoid embeddi= ng in actual applications]

This actually has a major performance advantage in the = right hands because the implementation can also be asynchronous. So in the = typical calling sequence we would have:

// Create = the socket
// Generate the message headers
// Check the socket is OK
// Send the first byte

In terms of timing = what would be going on is:

// Create the sock= et
=A0 [Async socket establishment starts]
// Generate the mess= age headers
=A0 [Wait for the socket to be completed]
/= / Check the socket is OK
// Send the first byte
<= br>

Now in my preferred programming language, you cou= ld just throw up a PAR statement and it would work anyway, but very few pro= grammers grok that sort of stuff.


On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <marka@isc.org> wrote:

In message <BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com>, Phi= llip Hallam-
Baker writes:
> I guess that would work for the application programmers who still code= in C
> or C++. That is not where the industry has been for a decade now.

The concepts are language independent.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org



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

--0016e68debd4b5f20c04a6db8b0b-- From ondrej.sury@nic.cz Wed Jun 29 09:17:17 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A723D9E805A for ; Wed, 29 Jun 2011 09:17:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHe+Nk9zLCy6 for ; Wed, 29 Jun 2011 09:17:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 489569E8053 for ; Wed, 29 Jun 2011 09:17:16 -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 2CFAA2A2B91 for ; Wed, 29 Jun 2011 18:17:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1309364230; bh=gdeR0VqZ+yjA3Rp+54u6nXzKRol5MfK/hphhhEU3CtE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=x0lQkMwE4x21Dg/ty2oklHLAk7lnofgB3DdwJIKHiQb0APnJ9vvQGBfDYWia3DGu4 7YcJPTHJyenEQ2REHHWJG0Kd2ObO4h7jWJYqKbIbSimo4USC0HqafKE6dr9U8DMOyI uxAyZv/hlZJfhVDeNe2mat+r7R8fXIlVN/rFt22U= Message-ID: <4E0B5005.1030400@nic.cz> Date: Wed, 29 Jun 2011 18:17:09 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:17:17 -0000 Hi all, I would like to thanks all for their valuable comments on use cases. Richard is going to publish new version which will address rest of the comments which were raised in the list. The one last issue where we don't have *full* consensus is "DNSSEC optional" and the chairs have decided that the document has enough support to go forward with "DNSSEC optional" in the document (with a change in the wording). We are going to request publication request on the -04 once it hits the tracker. 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 ------------------------------------------- From ondrej.sury@nic.cz Wed Jun 29 09:29:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2D821F852B for ; Wed, 29 Jun 2011 09:29:12 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOH1E3I7cFql for ; Wed, 29 Jun 2011 09:29:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 98D9321F852A for ; Wed, 29 Jun 2011 09:29:11 -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 7C9582A0809 for ; Wed, 29 Jun 2011 18:29:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1309364950; bh=23rZNtFN4KvL6P77qUYHNEi8iBJoAdlUjAVHOE9mB8s=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=dHyHVry+1iY7DvddxR7QUw5F7XYNAGSAKhQ62oNaE9mEeLkbqctMk3MH90CRsKNPB cE6fYqrbb7Xp275S850O4YDzTaPOaDpXjch7yvDNVC3GVx0Hwgk4p7Yg12jrxkP33V rMdIfPMywnE6tFOBBOwSmr2n4t93Ibd1myITryo4= Message-ID: <4E0B52D6.2090808@nic.cz> Date: Wed, 29 Jun 2011 18:29:10 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] DANE WG session scheduled @ IETF 81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 16:29:13 -0000 Hi all, we have been granted a session @ IETF 81 in Quebec: DANE Session 1 (1.5 hours) Friday, Afternoon Session I 1300-1400 Room Name: 206 A Please mail either or both of chairs if you want to have time slot. 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 ------------------------------------------- From ondrej.sury@nic.cz Wed Jun 29 10:04:56 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDB9E8063 for ; Wed, 29 Jun 2011 10:04:56 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du0lVmo2EQ9V for ; Wed, 29 Jun 2011 10:04:56 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 911D09E8060 for ; Wed, 29 Jun 2011 10:04:55 -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 1168F2A0DCD for ; Wed, 29 Jun 2011 19:04:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1309367094; bh=gtRBWkOVHbcxTKw6aqpEAXeT+d1oOwkVlcjhTJ2sJzg=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mC0+h/ZxaAp5khP27e0+XC+wp+fyDb4f5NY2snVE6XzaKGna0r2wRR8OhwyB8G7Jv 4I7n8S8y9AK/qwPtf13mMK2CdAW/Ots9lxKyVayrEuV/qZiOMrgQHEk5vru8AqLcO/ OGe6agqURMb/cNCGWr8xjYhQ+zYL1FnUEpG8gYgQ= Message-ID: <4E0B5B35.8010707@nic.cz> Date: Wed, 29 Jun 2011 19:04:53 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dane@ietf.org References: <4E0B52D6.2090808@nic.cz> In-Reply-To: <4E0B52D6.2090808@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] DANE WG session scheduled @ IETF 81 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:04:57 -0000 On 29.6.2011 18:29, Ondřej Surý wrote: > Hi all, > > we have been granted a session @ IETF 81 in Quebec: > > DANE Session 1 (1.5 hours) > Friday, Afternoon Session I 1300-1400 > Room Name: 206 A > > Please mail either or both of chairs if you want to have time slot. As Peter has kindly reminded me, we have two slots: 1300-1400 Afternoon Session I and 1415-1515 Afternoon Session II Strangely the tool had sent us only the first session, hence my oversight. 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 ------------------------------------------- From mrex@sap.com Wed Jun 29 10:12:20 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37659E805C for ; Wed, 29 Jun 2011 10:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn7vrinDH641 for ; Wed, 29 Jun 2011 10:12:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CB2289E8044 for ; Wed, 29 Jun 2011 10:12:18 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5THCBPS006422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 19:12:16 +0200 (MEST) From: Martin Rex Message-Id: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Wed, 29 Jun 2011 19:12:11 +0200 (MEST) In-Reply-To: <4E0B5005.1030400@nic.cz> from "=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=" at Jun 29, 11 06:17:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:12:20 -0000 =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= wrote: > > I would like to thanks all for their valuable comments on use cases. > Richard is going to publish new version which will address rest of the > comments which were raised in the list. > > The one last issue where we don't have *full* consensus is "DNSSEC > optional" and the chairs have decided that the document has enough > support to go forward with "DNSSEC optional" in the document (with > a change in the wording). I'm confused. The highest positive value of DANE without DNSSEC is sufficient close to zero that it is not worth bothering with it. The potential negative value (delusion,threat,vulnerbility) of DANE without DNSSEC is so huge and serious, that a proper security considerations to guard against this will have to be so long and complex that it can not possibly be comprehensible to the average reader -- so we should not even try. -Martin From hallam@gmail.com Wed Jun 29 10:25:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6AD21F8505 for ; Wed, 29 Jun 2011 10:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ErB86Fzbdq7 for ; Wed, 29 Jun 2011 10:25:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4D21F84B7 for ; Wed, 29 Jun 2011 10:25:37 -0700 (PDT) Received: by iwn39 with SMTP id 39so1609550iwn.31 for ; Wed, 29 Jun 2011 10:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=2P7afpr14pkh4Fy+BdPfeD4viPUtDfpuep2JhoUcstM=; b=jAtUSWxkr4mL2srmfzJXkIWOyLyqLO2HvUIbwyn5vT8g2L4PsQofKFOWtQPRoFjXsA IY8Z5byXMgNdXJfwSw9TzmCxZXXGXE9GzFbdjeqWerx2zl4hwRXw5915LruTxDNVSM9x JqjK7vThjaanNi14puo/6oCDa+B7asb/q27jo= Received: by 10.42.175.200 with SMTP id bb8mr994944icb.518.1309368336649; Wed, 29 Jun 2011 10:25:36 -0700 (PDT) Received: from [10.85.183.215] (mobile-166-137-136-222.mycingular.net [166.137.136.222]) by mx.google.com with ESMTPS id s2sm1232845icw.17.2011.06.29.10.25.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 10:25:35 -0700 (PDT) References: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> In-Reply-To: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8C148) From: Phillip Hallam-Baker Date: Wed, 29 Jun 2011 13:33:30 -0400 To: "mrex@sap.com" Cc: "dane@ietf.org" Subject: Re: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:25:38 -0000 This is a use cases document. Dnssec is an implementation technology. It is totally inapproprate even to m= ention it in use cases and requirements. There might be an architectural requirement to have a secure DNS channel, bu= t that is it. Mandating technology in requirements is bad. Sent from my angry birds device. On Jun 29, 2011, at 13:12, Martin Rex wrote: > =3D?UTF-8?B?T25kxZllaiBTdXLDvQ=3D=3D?=3D wrote: >>=20 >> I would like to thanks all for their valuable comments on use cases. >> Richard is going to publish new version which will address rest of the >> comments which were raised in the list. >>=20 >> The one last issue where we don't have *full* consensus is "DNSSEC >> optional" and the chairs have decided that the document has enough >> support to go forward with "DNSSEC optional" in the document (with >> a change in the wording). >=20 >=20 > I'm confused. >=20 > The highest positive value of DANE without DNSSEC is sufficient > close to zero that it is not worth bothering with it. >=20 > The potential negative value (delusion,threat,vulnerbility) of > DANE without DNSSEC is so huge and serious, that a proper security > considerations to guard against this will have to be so long > and complex that it can not possibly be comprehensible to the > average reader -- so we should not even try. >=20 > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ajs@anvilwalrusden.com Wed Jun 29 10:26:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686AC21F8550 for ; Wed, 29 Jun 2011 10:26:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH-jnEmZQXJP for ; Wed, 29 Jun 2011 10:26:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E3D4A21F854A for ; Wed, 29 Jun 2011 10:26:07 -0700 (PDT) Received: from shinkuro.com (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 19A501ECB422 for ; Wed, 29 Jun 2011 17:25:54 +0000 (UTC) Date: Wed, 29 Jun 2011 13:25:49 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20110629172549.GL8012@shinkuro.com> References: <4E0B5005.1030400@nic.cz> <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:26:08 -0000 On Wed, Jun 29, 2011 at 07:12:11PM +0200, Martin Rex wrote: > The highest positive value of DANE without DNSSEC is sufficient > close to zero that it is not worth bothering with it. > > The potential negative value (delusion,threat,vulnerbility) of > DANE without DNSSEC is so huge and serious, that a proper security > considerations to guard against this will have to be so long > and complex that it can not possibly be comprehensible to the > average reader -- so we should not even try. I couldn't say it better myself. -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Wed Jun 29 10:27:15 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4322121F854A for ; Wed, 29 Jun 2011 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxKhOTdeAIt3 for ; Wed, 29 Jun 2011 10:27:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2F721F8505 for ; Wed, 29 Jun 2011 10:27:13 -0700 (PDT) Received: from [109.183.252.62] (109-183-252-62.tmcz.cz [109.183.252.62]) by mail.nic.cz (Postfix) with ESMTPSA id BE47D2A0120; Wed, 29 Jun 2011 19:27:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1309368432; bh=ofmItfpacaIVsrvLd2FlWB5PIM+mlnORk/vNe8LqoxQ=; h=References:In-Reply-To:Mime-Version:Content-Transfer-Encoding: Content-Type:Message-Id:Cc:From:Subject:Date:To; b=Nq7knKkrSbRAiziWtH1UuvRtr7sjjpCKNq/0XSOxdEEtYU+nOmAgjE2i5q1zDRhl8 8tozrA07y5Zvp6H1t1Juq6Vyqo9m3pvaItQ1umLePUmUWtXTvRc4VS00RvYMYVOwfA ezlR9kOGBN30CFwhaXwyqduEkPoKK4Js+/TQfcnI= References: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> In-Reply-To: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <753682A1-9D69-4016-96A2-4179EB7794B5@nic.cz> X-Mailer: iPhone Mail (8J2) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Date: Wed, 29 Jun 2011 19:27:02 +0200 To: "mrex@sap.com" X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: "dane@ietf.org" Subject: Re: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:27:15 -0000 Martin, my view is that we are speaking about the use cases document and it has a pl= ace in the *use case* document. I am prepared to have the discussion whether we will have this option in the= dane protocol or not. We may tighten some places or loosen some in the prot= ocol for exactly same reasons you wrote down below. So please bear in mind that we are only talking about use cases and it *is* v= alid use case and from what I have seen in the preview of -04 the new wordin= g is very careful when it comes to this issue. Ond=C5=99ej Sur=C3=BD On 29.6.2011, at 19:12, Martin Rex wrote: > =3D?UTF-8?B?T25kxZllaiBTdXLDvQ=3D=3D?=3D wrote: >>=20 >> I would like to thanks all for their valuable comments on use cases. >> Richard is going to publish new version which will address rest of the >> comments which were raised in the list. >>=20 >> The one last issue where we don't have *full* consensus is "DNSSEC >> optional" and the chairs have decided that the document has enough >> support to go forward with "DNSSEC optional" in the document (with >> a change in the wording). >=20 >=20 > I'm confused. >=20 > The highest positive value of DANE without DNSSEC is sufficient > close to zero that it is not worth bothering with it. >=20 > The potential negative value (delusion,threat,vulnerbility) of > DANE without DNSSEC is so huge and serious, that a proper security > considerations to guard against this will have to be so long > and complex that it can not possibly be comprehensible to the > average reader -- so we should not even try. >=20 > -Martin From internet-drafts@ietf.org Wed Jun 29 10:55:38 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F121F8563; Wed, 29 Jun 2011 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JCr++Pq4w+2; Wed, 29 Jun 2011 10:55:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B121F855E; Wed, 29 Jun 2011 10:55:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110629175538.13928.91137.idtracker@ietfa.amsl.com> Date: Wed, 29 Jun 2011 10:55:38 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:55:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Use Cases and Requirements for DNS-based Authentication = of Named Entities (DANE) Author(s) : Richard Barnes Filename : draft-ietf-dane-use-cases-04.txt Pages : 12 Date : 2011-06-29 Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt From rbarnes@bbn.com Wed Jun 29 10:58:05 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D364D11E80A6 for ; Wed, 29 Jun 2011 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2vOE3Ua5328 for ; Wed, 29 Jun 2011 10:58:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2D311E80A4 for ; Wed, 29 Jun 2011 10:58:04 -0700 (PDT) Received: from [128.89.253.248] (port=60667 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qbz1V-000KYM-QJ; Wed, 29 Jun 2011 13:58:02 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: <753682A1-9D69-4016-96A2-4179EB7794B5@nic.cz> Date: Wed, 29 Jun 2011 13:58:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02452311-EA3F-40EB-86CF-56CD1C8E1FA0@bbn.com> References: <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> <753682A1-9D69-4016-96A2-4179EB7794B5@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: "dane@ietf.org" Subject: Re: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:58:05 -0000 Yep. The possibility of using DANE without DNSSEC had been raised as a = possibility by some participants, so it seemed fair to describe what the = implications would be of allowing this case. To whit, in the new = version: " In principle, DANE information expressing CA constraints can be = presented with or without DNSSEC protection. Presenting DANE = information without DNSSEC protection does not introduce any new = vulnerabilities, but neither does it add much assurance. " It is still fully possible that the ultimate DANE protocol will require = DANE clients to reject non-DNSSEC-protected DANE records. (Of course, = you can always provision them in your name server.) --Richard On Jun 29, 2011, at 1:27 PM, Ond=C5=99ej Sur=C3=BD wrote: > Martin, >=20 > my view is that we are speaking about the use cases document and it = has a place in the *use case* document. >=20 > I am prepared to have the discussion whether we will have this option = in the dane protocol or not. We may tighten some places or loosen some = in the protocol for exactly same reasons you wrote down below. >=20 > So please bear in mind that we are only talking about use cases and it = *is* valid use case and from what I have seen in the preview of -04 the = new wording is very careful when it comes to this issue. >=20 > Ond=C5=99ej Sur=C3=BD >=20 > On 29.6.2011, at 19:12, Martin Rex wrote: >=20 >> =3D?UTF-8?B?T25kxZllaiBTdXLDvQ=3D=3D?=3D wrote: >>>=20 >>> I would like to thanks all for their valuable comments on use cases. >>> Richard is going to publish new version which will address rest of = the >>> comments which were raised in the list. >>>=20 >>> The one last issue where we don't have *full* consensus is "DNSSEC >>> optional" and the chairs have decided that the document has enough >>> support to go forward with "DNSSEC optional" in the document (with >>> a change in the wording). >>=20 >>=20 >> I'm confused. >>=20 >> The highest positive value of DANE without DNSSEC is sufficient >> close to zero that it is not worth bothering with it. >>=20 >> The potential negative value (delusion,threat,vulnerbility) of >> DANE without DNSSEC is so huge and serious, that a proper security >> considerations to guard against this will have to be so long >> and complex that it can not possibly be comprehensible to the >> average reader -- so we should not even try. >>=20 >> -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rickardb@certezza.net Wed Jun 29 11:09:07 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6348821F85CA for ; Wed, 29 Jun 2011 11:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPWya4Cj2pbF for ; Wed, 29 Jun 2011 11:09:06 -0700 (PDT) Received: from mx1.certezza.net (mx2.certezza.net [82.99.51.26]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0121F85C7 for ; Wed, 29 Jun 2011 11:09:06 -0700 (PDT) From: Rickard Bellgrim To: Adam Langley , "dane@ietf.org" Date: Wed, 29 Jun 2011 08:19:05 +0200 Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw1wIZd2jLbCNZ2STWKmWAFQ6o9mAAY1GsQ Message-ID: <7ADA424A25710B41B7C8201DA111AF190882236CA1@mail01.certezza.local> References: In-Reply-To: Accept-Language: sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received-SPF: none Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 18:09:07 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Adam Langley > Sent: den 28 juni 2011 20:23 > To: dane@ietf.org > Subject: [dane] Draft for serializing DNSSEC chains >=20 > As promised. (This is also the format that Chrome is using for it's DNSSE= C > stapled certificate support.) >=20 > http://tools.ietf.org/html/draft-agl-dane-serializechain-00 Isn't the initial_key_tag a little bit weak as a trust anchor? You could ea= sily get a collision here. Perhaps using the DS as initial_ds instead of in= itial_key_tag? // Rickard From hallam@gmail.com Wed Jun 29 12:38:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B6211E80AF for ; Wed, 29 Jun 2011 12:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfE7f4G5k18g for ; Wed, 29 Jun 2011 12:38:44 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B511E809B for ; Wed, 29 Jun 2011 12:38:37 -0700 (PDT) Received: by gyd5 with SMTP id 5so414351gyd.31 for ; Wed, 29 Jun 2011 12:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8SvPR8KTADz04tXo+ey+v7s0AXDeK55LrAB27p75+zw=; b=ZycRGfNi2r1eP09i9ezMe7fqoyE0d3g2m8ocuQeuCOpB/WMCEsbkbKIlem0KYwUcrx h+71vyW4tnlMqaua+ReoqS6CVOxqAIO17TZuvshURzSpfns2ku9e0rskkpS15l97vWUq 46E/pjMm6liid8Riy62+/O+iuSLBplUDwfQ4Q= MIME-Version: 1.0 Received: by 10.101.186.35 with SMTP id n35mr1010436anp.84.1309376316866; Wed, 29 Jun 2011 12:38:36 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Wed, 29 Jun 2011 12:38:36 -0700 (PDT) In-Reply-To: <20110629172549.GL8012@shinkuro.com> References: <4E0B5005.1030400@nic.cz> <201106291712.p5THCBfu020768@fs4113.wdf.sap.corp> <20110629172549.GL8012@shinkuro.com> Date: Wed, 29 Jun 2011 15:38:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001636c598963e810204a6deee33 Cc: dane@ietf.org Subject: Re: [dane] Publication request plan of the draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 19:38:44 -0000 --001636c598963e810204a6deee33 Content-Type: text/plain; charset=ISO-8859-1 This also has bearing on whether DANE ends up conflating security policy and key distribution. While it is very clear that DANE offers little value as a key distribution mechanism without some form of assurance as to the authenticity and integrity of the DNS records,also clear that: 1) The authenticity and integrity assurances can be delivered through means other than DNSSEC (e.g. DNS over IPSEC to trusted resolver, DPLS to a trusted resolver, etc.) 2) Security policy information may have some value even if there are no authenticity or integrity controls on the DNS records (e.g. site says 'SSL upgrade is always available'). On Wed, Jun 29, 2011 at 1:25 PM, Andrew Sullivan wrote: > On Wed, Jun 29, 2011 at 07:12:11PM +0200, Martin Rex wrote: > > The highest positive value of DANE without DNSSEC is sufficient > > close to zero that it is not worth bothering with it. > > > > The potential negative value (delusion,threat,vulnerbility) of > > DANE without DNSSEC is so huge and serious, that a proper security > > considerations to guard against this will have to be so long > > and complex that it can not possibly be comprehensible to the > > average reader -- so we should not even try. > > I couldn't say it better myself. > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c598963e810204a6deee33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This also has bearing on whether DANE ends up conflating security policy an= d key distribution.

While it is very clear that DANE off= ers little value as a key distribution mechanism without some form of assur= ance as to the authenticity and integrity of the DNS records,also clear tha= t:

1) The authenticity and integrity assurances can be del= ivered through means other than DNSSEC (e.g. DNS over IPSEC to trusted reso= lver, DPLS to a trusted resolver, etc.)

2) Securit= y policy information may have some value even if there are no authenticity = or integrity controls on the DNS records (e.g. site says 'SSL upgrade i= s always available').



On Wed, J= un 29, 2011 at 1:25 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Wed, Jun 29, 2011 at 0= 7:12:11PM +0200, Martin Rex wrote:
> The highest positive value of DANE without DNSSEC is sufficient
> close to zero that it is not worth bothering with it.
>
> The potential negative value (delusion,threat,vulnerbility) of
> DANE without DNSSEC is so huge and serious, that a proper security
> considerations to guard against this will have to be so long
> and complex that it can not possibly be comprehensible to the
> average reader -- so we should not even try.

I couldn't say it better myself.

--
Andrew Sullivan
ajs@anvilwalrusden.com

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--001636c598963e810204a6deee33-- From marka@isc.org Wed Jun 29 16:54:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ABD11E8079 for ; Wed, 29 Jun 2011 16:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E8t7z-uaT36 for ; Wed, 29 Jun 2011 16:54:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2FA11E8076 for ; Wed, 29 Jun 2011 16:54:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E89B0C9424; Wed, 29 Jun 2011 23:54:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1A8CA216C7B; Wed, 29 Jun 2011 23:54:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D03A9114BCEB; Thu, 30 Jun 2011 09:54:15 +1000 (EST) To: Phillip Hallam-Baker From: Mark Andrews References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> <20110629043419.1AE571147954@drugs.dv.isc.org> <20110629062121.D420A1147E37@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 29 Jun 2011 11:36:18 -0400." Date: Thu, 30 Jun 2011 09:54:15 +1000 Message-Id: <20110629235415.D03A9114BCEB@drugs.dv.isc.org> Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 23:54:32 -0000 In message , Phillip Hallam- Baker writes: > > The concepts are independent, the code most certainly is not. > > This is why I have spent the past few weeks writing a DNS resolver in C# to > hopefully render the issue moot. > > > While you can call unmanaged code from a managed environment like C#, the > means of doing so is not at all pretty. And making the result threadsafe is > a nightmare. It is in fact much easier to recode from scratch than to use > the existing stuff. There are already plenty of thread safe resolver libraries. Which can perform queries in parallel. They can even be talking to different sets of recursive servers if you want. libresolv was made thread safe in 1900's and no it was not a giant lock. > Calling a math function or a crypto algorithm is one thing, but a DNS > library is by its very nature asynchronous and it is possible to have > multiple queries in flight at the same time. I suspect that a lot of the > objections to using DNS for more sophisticated discovery come from the lack > of decent DNS library support in modern programming languages. > > It is easy enough to support an API like this with blocking code: > > EDNS.Client resolver = new EDNS.Client (); > > EDNS.DNSMessage Response; > int result = resolver.Resolve (Domain, EDNS.DNSType.CAA, out Response); > > > But most of us would like to have multiple queries in parallel: > > DNSClient Client = new DNSClient (); > > // Non blocking request > DNSMessage Request = new DNSQueryMessage (Domain, EDNS.DNSType.A > ); > DNSTransaction Transaction1 = Client.Send (Request); > > DNSMessage Request = new DNSQueryMessage > (Domain, EDNS.DNSType.CAA); > DNSTransaction Transaction2 = Client.Send (Request); > > // Does other useful stuff like create the message headers > // Can poll status of transactions using DNSTransaction.Complete > () > > Response = Client.Receive (Transaction1); > Response = Client.Receive (Transaction2); > > > And that is still much less than you would want a .NET library to provide. A > proper .NET library should let the caller loop things into the asynchronous > caller. > > Ultimately, the goal is to produce a subclass of the TcpClient class such > that the only difference that the programmer needs to consider is to replace > the creation method: > > public TcpClient(string hostname, int port) > > > with the creation method: > > public InternetClient(string hostname, string service, int port) > > > > The difference here is the level of abstraction. TcpClient connects via > hostname and port and always returns a raw bytestream. InternetClient uses > the DNS to determine what the best connection that is available for a > service. If the best connection is raw TCP it will return that, if it can > form an SSL socket, it will return that. > > [Yes, I know that there is also the question of how to specify 'best', but > that is something that is more usually something you want to specify at the > host level or higher and want to avoid embedding in actual applications] > > This actually has a major performance advantage in the right hands because > the implementation can also be asynchronous. So in the typical calling > sequence we would have: > > // Create the socket > // Generate the message headers > // Check the socket is OK > // Send the first byte > > In terms of timing what would be going on is: > > // Create the socket > [Async socket establishment starts] > // Generate the message headers > [Wait for the socket to be completed] > // Check the socket is OK > // Send the first byte > > > Now in my preferred programming language, you could just throw up a PAR > statement and it would work anyway, but very few programmers grok that sort > of stuff. And this has gone very far from the original issue of handling unknown types. > On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews wrote: > > > > > In message , Phillip > > Hallam- > > Baker writes: > > > I guess that would work for the application programmers who still code in > > C > > > or C++. That is not where the industry has been for a decade now. > > > > The concepts are language independent. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > > -- > Website: http://hallambaker.com/ > > --0016e68debd4b5f20c04a6db8b0b > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > The concepts are independent, the code most certainly is not.

>
This is why I have spent the past few weeks writing a DNS resolver in= > C# to hopefully render the issue moot.


>
While you can call unmanaged code from a managed environment like C#, = > the means of doing so is not at all pretty. And making the result threadsaf= > e is a nightmare. It is in fact much easier to recode from scratch than to = > use the existing stuff.
>

Calling a math function or a crypto algorithm is one th= > ing, but a DNS library is by its very nature asynchronous and it is possibl= > e to have multiple queries in flight at the same time. I suspect that a lot= > of the objections to using DNS for more sophisticated discovery come from = > the lack of decent DNS library support in modern programming languages. v> >


It is easy enough to support an API like= > this with blocking code:

=A0 =A0 EDNS.Client= > resolver =3D new EDNS.Client ();

=A0 =A0 EDNS.DNS= > Message Response;
>
=A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, out= > Response);


But most of us wo= > uld like to have multiple queries in parallel:

v> > =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient ();
<= > div>
=A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request
v>
=A0 =A0 =A0 =A0 =A0 =A0 DNSMessage = > Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.A =3D"Apple-style-span">);
>
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Client.S= > end (Request);

=A0 =A0 =A0 =A0 =A0 =A0 D= > NSMessage Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.CAA); v>
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Client= > .Send (Request);
>

=A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuf= > f like create the message headers
=A0 =A0 =A0 =A0 =A0 =A0 // Can = > poll status of transactions using=A0DNSTransaction.Complete ()
r>
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Tran= > saction1);
>
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transa= > ction2);


And that is still mu= > ch less than you would want a .NET library to provide. A proper .NET librar= > y should let the caller loop things into the asynchronous caller.
>

Ultimately, the goal is to produce a subclass of the Tc= > pClient class such that the only difference that the programmer needs to co= > nsider is to replace the creation method:

ass=3D"Apple-style-span" style=3D"font-family: 'Segoe UI', Verdana,= > Arial; font-size: 17px; ">
 px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px; margin-right: =
> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas, Courier, =
> monospace; word-break: break-all; word-wrap: break-word; font-style: normal=
> ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
> public TcpClient(  blue; ">string hostname, int p=
> ort)

with the creation method:
<= > div> >
Segoe UI', Verdana, Arial; font-size: 17px; ">
 : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; margin-t=
> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font-fami=
> ly: Consolas, Courier, monospace; word-break: break-all; word-wrap: break-w=
> ord; font-style: normal; font-weight: normal; overflow-x: auto; overflow-y:=
>  auto; ">
> public InternetClient( olor: blue; ">string hostname, string<=
> /span> service, int port)


<= > div> > The difference here is the level of abstraction. TcpClient connects via hos= > tname and port and always returns a raw bytestream. InternetClient uses the= > DNS to determine what the best connection that is available for a service.= > If the best connection is raw TCP it will return that, if it can form an S= > SL socket, it will return that.
>

[Yes, I know that there is also the question of how to = > specify 'best', but that is something that is more usually somethin= > g you want to specify at the host level or higher and want to avoid embeddi= > ng in actual applications]
>

This actually has a major performance advantage in the = > right hands because the implementation can also be asynchronous. So in the = > typical calling sequence we would have:

// Create = > the socket
>
// Generate the message headers
// Check the socket is OK iv>
// Send the first byte

In terms of timing = > what would be going on is:

// Create the sock= > et
>
=A0 [Async socket establishment starts]
// Generate the mess= > age headers
=A0 [Wait for the socket to be completed]
/= > / Check the socket is OK
// Send the first byte
<= > br> >

Now in my preferred programming language, you cou= > ld just throw up a PAR statement and it would work anyway, but very few pro= > grammers grok that sort of stuff.


=3D"gmail_quote"> > On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews < =3D"mailto:marka@isc.org">marka@isc.org> wrote:
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= > id;padding-left:1ex;"> >
> In message < .gmail.com">BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com>, Phi= > llip Hallam-
>
Baker writes:
> > I guess that would work for the application programmers who still code= > in C
> > or C++. That is not where the industry has been for a decade now.
>
>
The concepts are language independent.
>
> --
>
Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2= > 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org">marka@isc.org
>



--
Website: href=3D"http://hallambaker.com/">http://hallambaker.com/

>
> > --0016e68debd4b5f20c04a6db8b0b-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Wed Jun 29 18:01:11 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC6E11E80A6 for ; Wed, 29 Jun 2011 18:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajWFcCi6UJB7 for ; Wed, 29 Jun 2011 18:01:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 561AC11E8072 for ; Wed, 29 Jun 2011 18:01:09 -0700 (PDT) Received: by yxp4 with SMTP id 4so959651yxp.31 for ; Wed, 29 Jun 2011 18:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cd7xepIIuFTRgOg0ROBi+sWk1DyVlZgQbWHeyURv8sU=; b=CK0lfgwRHE4lFJkxjY4x+CeBehkDSZUP0/nf5sJMMgpOBI9McnuRI0c16NAx3Rjtfx x051WNCdv+PguAcc79SqcgqG61Lsj7hHAPyDW9mHEbXrr/2FBoL7ntQw28F22+Pnhpkq AUGrPLlSMjsn3ot/2MdJU0XbuL+sBWVZDEpsI= MIME-Version: 1.0 Received: by 10.101.177.8 with SMTP id e8mr1269313anp.128.1309395668017; Wed, 29 Jun 2011 18:01:08 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Wed, 29 Jun 2011 18:01:07 -0700 (PDT) In-Reply-To: <20110629235415.D03A9114BCEB@drugs.dv.isc.org> References: <50F644F9-F9C0-483B-AEE2-D7E294F156A6@bbn.com> <20110629022648.145871146A84@drugs.dv.isc.org> <20110629043419.1AE571147954@drugs.dv.isc.org> <20110629062121.D420A1147E37@drugs.dv.isc.org> <20110629235415.D03A9114BCEB@drugs.dv.isc.org> Date: Wed, 29 Jun 2011 21:01:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Mark Andrews Content-Type: multipart/alternative; boundary=001636c92c62a9a1b404a6e36f48 Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 01:01:11 -0000 --001636c92c62a9a1b404a6e36f48 Content-Type: text/plain; charset=ISO-8859-1 Yes, but you try calling them from managed code and the results are going to be less than pretty. All I am saying is that there is probably a reason that very few applications seem to be making use of features like SRV and I don't think it is a problem with the ideas, its in the deployment. On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews wrote: > > In message , Phillip > Hallam- > Baker writes: > > > > The concepts are independent, the code most certainly is not. > > > > This is why I have spent the past few weeks writing a DNS resolver in C# > to > > hopefully render the issue moot. > > > > > > While you can call unmanaged code from a managed environment like C#, the > > means of doing so is not at all pretty. And making the result threadsafe > is > > a nightmare. It is in fact much easier to recode from scratch than to use > > the existing stuff. > > There are already plenty of thread safe resolver libraries. Which > can perform queries in parallel. They can even be talking to > different sets of recursive servers if you want. libresolv was > made thread safe in 1900's and no it was not a giant lock. > > > Calling a math function or a crypto algorithm is one thing, but a DNS > > library is by its very nature asynchronous and it is possible to have > > multiple queries in flight at the same time. I suspect that a lot of the > > objections to using DNS for more sophisticated discovery come from the > lack > > of decent DNS library support in modern programming languages. > > > > It is easy enough to support an API like this with blocking code: > > > > EDNS.Client resolver = new EDNS.Client (); > > > > EDNS.DNSMessage Response; > > int result = resolver.Resolve (Domain, EDNS.DNSType.CAA, out > Response); > > > > > > But most of us would like to have multiple queries in parallel: > > > > DNSClient Client = new DNSClient (); > > > > // Non blocking request > > DNSMessage Request = new DNSQueryMessage (Domain, > EDNS.DNSType.A > > ); > > DNSTransaction Transaction1 = Client.Send (Request); > > > > DNSMessage Request = new DNSQueryMessage > > (Domain, EDNS.DNSType.CAA); > > DNSTransaction Transaction2 = Client.Send (Request); > > > > // Does other useful stuff like create the message headers > > // Can poll status of transactions using > DNSTransaction.Complete > > () > > > > Response = Client.Receive (Transaction1); > > Response = Client.Receive (Transaction2); > > > > > > And that is still much less than you would want a .NET library to > provide. A > > proper .NET library should let the caller loop things into the > asynchronous > > caller. > > > > Ultimately, the goal is to produce a subclass of the TcpClient class such > > that the only difference that the programmer needs to consider is to > replace > > the creation method: > > > > public TcpClient(string hostname, int port) > > > > > > with the creation method: > > > > public InternetClient(string hostname, string service, int port) > > > > > > > > The difference here is the level of abstraction. TcpClient connects via > > hostname and port and always returns a raw bytestream. InternetClient > uses > > the DNS to determine what the best connection that is available for a > > service. If the best connection is raw TCP it will return that, if it can > > form an SSL socket, it will return that. > > > > [Yes, I know that there is also the question of how to specify 'best', > but > > that is something that is more usually something you want to specify at > the > > host level or higher and want to avoid embedding in actual applications] > > > > This actually has a major performance advantage in the right hands > because > > the implementation can also be asynchronous. So in the typical calling > > sequence we would have: > > > > // Create the socket > > // Generate the message headers > > // Check the socket is OK > > // Send the first byte > > > > In terms of timing what would be going on is: > > > > // Create the socket > > [Async socket establishment starts] > > // Generate the message headers > > [Wait for the socket to be completed] > > // Check the socket is OK > > // Send the first byte > > > > > > Now in my preferred programming language, you could just throw up a PAR > > statement and it would work anyway, but very few programmers grok that > sort > > of stuff. > > And this has gone very far from the original issue of handling unknown > types. > > > On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews wrote: > > > > > > > > In message , > Phillip > > > Hallam- > > > Baker writes: > > > > I guess that would work for the application programmers who still > code in > > > C > > > > or C++. That is not where the industry has been for a decade now. > > > > > > The concepts are language independent. > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > > --0016e68debd4b5f20c04a6db8b0b > > Content-Type: text/html; charset=ISO-8859-1 > > Content-Transfer-Encoding: quoted-printable > > > > The concepts are independent, the code most certainly is > not.

> >
This is why I have spent the past few weeks writing a DNS resolver > in= > > C# to hopefully render the issue > moot.


> >
While you can call unmanaged code from a managed environment like > C#, = > > the means of doing so is not at all pretty. And making the result > threadsaf= > > e is a nightmare. It is in fact much easier to recode from scratch than > to = > > use the existing stuff.
> >

Calling a math function or a crypto algorithm is one > th= > > ing, but a DNS library is by its very nature asynchronous and it is > possibl= > > e to have multiple queries in flight at the same time. I suspect that a > lot= > > of the objections to using DNS for more sophisticated discovery come > from = > > the lack of decent DNS library support in modern programming > languages. > v> > >


It is easy enough to support an API > like= > > this with blocking code:

=A0 =A0 > EDNS.Client= > > resolver =3D new EDNS.Client ();

=A0 =A0 > EDNS.DNS= > > Message Response;
> >
=A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, > out= > > Response);


But most of us > wo= > > uld like to have multiple queries in > parallel:

> v> > > =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient > ();
<= > > div>
=A0 =A0 =A0 =A0 =A0 =A0 // Non blocking > request
> v>
=A0 =A0 =A0 =A0 =A0 =A0 > DNSMessage = > > Request =3D new DNSQueryMessage (Domain,=A0EDNS.DNSType.A class= > > =3D"Apple-style-span">);
> >
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D > Client.S= > > end (Request);

=A0 =A0 =A0 =A0 =A0 =A0 > D= > > NSMessage Request =3D new DNSQueryMessage > (Domain,=A0EDNS.DNSType.CAA); > v>
=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D > Client= > > .Send (Request);
> >

=A0 =A0 =A0 =A0 =A0 =A0 // Does other useful > stuf= > > f like create the message headers
=A0 =A0 =A0 =A0 =A0 =A0 // > Can = > > poll status of transactions using=A0DNSTransaction.Complete > ()
> r>
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive > (Tran= > > saction1);
> >
=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive > (Transa= > > ction2);


And that is still > mu= > > ch less than you would want a .NET library to provide. A proper .NET > librar= > > y should let the caller loop things into the asynchronous caller.
> >

Ultimately, the goal is to produce a subclass of the > Tc= > > pClient class such that the only difference that the programmer needs to > co= > > nsider is to replace the creation method:

cl= > > ass=3D"Apple-style-span" style=3D"font-family: 'Segoe UI', > Verdana,= > > Arial; font-size: 17px; ">
 5=
> > px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px;
> margin-right: =
> > 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas,
> Courier, =
> > monospace; word-break: break-all; word-wrap: break-word; font-style:
> normal=
> > ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
> > public TcpClient( style=3D"color:=
> >  blue; ">string hostname, int
> p=
> > ort)

with the creation > method:
<= > > div> > >
'= > > Segoe UI', Verdana, Arial; font-size: 17px; ">
 style=3D"padding-top=
> > : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px;
> margin-t=
> > op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;
> font-fami=
> > ly: Consolas, Courier, monospace; word-break: break-all; word-wrap:
> break-w=
> > ord; font-style: normal; font-weight: normal; overflow-x: auto;
> overflow-y:=
> >  auto; ">
> > public InternetClient( style=3D"c=
> > olor: blue; ">string hostname,  ">string<=
> > /span> service, int
> port)


<= > > div> > > The difference here is the level of abstraction. TcpClient connects via > hos= > > tname and port and always returns a raw bytestream. InternetClient uses > the= > > DNS to determine what the best connection that is available for a > service.= > > If the best connection is raw TCP it will return that, if it can form an > S= > > SL socket, it will return that.
> >

[Yes, I know that there is also the question of how > to = > > specify 'best', but that is something that is more usually > somethin= > > g you want to specify at the host level or higher and want to avoid > embeddi= > > ng in actual applications]
> >

This actually has a major performance advantage in > the = > > right hands because the implementation can also be asynchronous. So in > the = > > typical calling sequence we would have:

// > Create = > > the socket
> >
// Generate the message headers
// Check the socket is > OK > iv>
// Send the first byte

In terms of > timing = > > what would be going on is:

// Create the > sock= > > et
> >
=A0 [Async socket establishment starts]
// Generate the > mess= > > age headers
=A0 [Wait for the socket to be > completed]
/= > > / Check the socket is OK
// Send the first > byte
<= > > br> > >

Now in my preferred programming language, you > cou= > > ld just throw up a PAR statement and it would work anyway, but very few > pro= > > grammers grok that sort of stuff.


class= > > =3D"gmail_quote"> > > On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews < href= > > =3D"mailto:marka@isc.org">marka@isc.org> > wrote:
> e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > sol= > > id;padding-left:1ex;"> > >
> > In message < BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail= > > .gmail.com">BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com>, > Phi= > > llip Hallam-
> >
Baker writes:
> > > I guess that would work for the application programmers who still > code= > > in C
> > > or C++. That is not where the industry has been for a decade > now.
> >
> >
The concepts are language independent.
> >
> > --
> >
Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 > 2= > > 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: href=3D"mailto:= > > marka@isc.org">marka@isc.org
> >



--
Website: > > href=3D"http://hallambaker.com/">http://hallambaker.com/

> >
> > > > --0016e68debd4b5f20c04a6db8b0b-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Website: http://hallambaker.com/ --001636c92c62a9a1b404a6e36f48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, but you try calling them from managed code and the results are going t= o be less than pretty.

All I am saying is that there is = probably a reason that very few applications seem to be making use of featu= res like SRV and I don't think it is a problem with the ideas, its in t= he deployment.




On We= d, Jun 29, 2011 at 7:54 PM, Mark Andrews <marka@isc.org> wrote:

In message <BANLkTikgeZbV28mj8nPSicDmQoqz0f9M4A@mail.gmail.com>, Phill= ip Hallam-
Baker writes:
>
> The concepts are independent, the code most certainly is not.
>
> This is why I have spent the past few weeks writing a DNS resolver in = C# to
> hopefully render the issue moot.
>
>
> While you can call unmanaged code from a managed environment like C#, = the
> means of doing so is not at all pretty. And making the result threadsa= fe is
> a nightmare. It is in fact much easier to recode from scratch than to = use
> the existing stuff.

There are already plenty of thread safe resolver libraries. =A0Which<= br> can perform queries in parallel. =A0They can even be talking to
different sets of recursive servers if you want. =A0libresolv was
made thread safe in 1900's and no it was not a giant lock.

> Calling a math function or a crypto algorithm is one thing, but a DNS<= br> > library is by its very nature asynchronous and it is possible to have<= br> > multiple queries in flight at the same time. I suspect that a lot of t= he
> objections to using DNS for more sophisticated discovery come from the= lack
> of decent DNS library support in modern programming languages.
>
> It is easy enough to support an API like this with blocking code:
>
> =A0 =A0 EDNS.Client resolver =3D new EDNS.Client ();
>
> =A0 =A0 EDNS.DNSMessage Response;
> =A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA, out= Response);
>
>
> But most of us would like to have multiple queries in parallel:
>
> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient ();
>
> =A0 =A0 =A0 =A0 =A0 =A0 // Non blocking request
> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQueryMessage (Do= main, EDNS.DNSType.A
> );
> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D Client.Send (R= equest);
>
> =A0 =A0 =A0 =A0 =A0 =A0 DNSMessage Request =3D new DNSQueryMessage
> (Domain, EDNS.DNSType.CAA);
> =A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D Client.Send (R= equest);
>
> =A0 =A0 =A0 =A0 =A0 =A0 // Does other useful stuff like create the mes= sage headers
> =A0 =A0 =A0 =A0 =A0 =A0 // Can poll status of transactions using DNSTr= ansaction.Complete
> ()
>
> =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transaction1); > =A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive (Transaction2); >
>
> And that is still much less than you would want a .NET library to prov= ide. A
> proper .NET library should let the caller loop things into the asynchr= onous
> caller.
>
> Ultimately, the goal is to produce a subclass of the TcpClient class s= uch
> that the only difference that the programmer needs to consider is to r= eplace
> the creation method:
>
> public TcpClient(string hostname, int port)
>
>
> with the creation method:
>
> public InternetClient(string hostname, string service, int port)
>
>
>
> The difference here is the level of abstraction. TcpClient connects vi= a
> hostname and port and always returns a raw bytestream. InternetClient = uses
> the DNS to determine what the best connection that is available for a<= br> > service. If the best connection is raw TCP it will return that, if it = can
> form an SSL socket, it will return that.
>
> [Yes, I know that there is also the question of how to specify 'be= st', but
> that is something that is more usually something you want to specify a= t the
> host level or higher and want to avoid embedding in actual application= s]
>
> This actually has a major performance advantage in the right hands bec= ause
> the implementation can also be asynchronous. So in the typical calling=
> sequence we would have:
>
> // Create the socket
> // Generate the message headers
> // Check the socket is OK
> // Send the first byte
>
> In terms of timing what would be going on is:
>
> // Create the socket
> =A0 [Async socket establishment starts]
> // Generate the message headers
> =A0 [Wait for the socket to be completed]
> // Check the socket is OK
> // Send the first byte
>
>
> Now in my preferred programming language, you could just throw up a PA= R
> statement and it would work anyway, but very few programmers grok that= sort
> of stuff.

And this has gone very far from the original issue of handling = unknown types.

> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <marka@isc.org> wrote:
>
> >
> > In message <BANLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com>, Phillip
> > Hallam-
> > Baker writes:
> > > I guess that would work for the application programmers who = still code in
> > C
> > > or C++. That is not where the industry has been for a decade= now.
> >
> > The concepts are language independent.
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org
> >
>
>
>
> --
> Website: http://= hallambaker.com/
>
> --0016e68debd4b5f20c04a6db8b0b
> Content-Type: text/html; charset=3DISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> The concepts are independent, the code most certainly is not.<div&g= t;<br></div=3D
> ><div>This is why I have spent the past few weeks writing a D= NS resolver in=3D
> =A0C# to hopefully render the issue moot.</div><div><br= ></div><div><br></div>
> <div>While you can call unmanaged code from a managed environmen= t like C#, =3D
> the means of doing so is not at all pretty. And making the result thre= adsaf=3D
> e is a nightmare. It is in fact much easier to recod= e from scratch than to =3D
> use the existing stuff.</div>
> <div><br></div><div>Calling a math function or= a crypto algorithm is one th=3D
> ing, but a DNS library is by its very nature asynchronous and it is po= ssibl=3D
> e to have multiple queries in flight at the same tim= e. I suspect that a lot=3D
> =A0of the objections to using DNS for more sophisticated discovery com= e from =3D
> the lack of decent DNS library support in modern programming lan= guages.</di=3D
> v>
> <div><br></div><div><br></div><= div>It is easy enough to support an API like=3D
> =A0this with blocking code:</div><div><br></div&g= t;<div><div>=3DA0 =3DA0 EDNS.Client=3D
> =A0resolver =3D3D new EDNS.Client ();</div><div><br>= </div><div>=3DA0 =3DA0 EDNS.DNS=3D
> Message Response;</div>
> <div>=3DA0 =3DA0 int result =3D3D resolver.Resolve (Domain, EDNS= .DNSType.CAA, out=3D
> =A0Response);</div><div><br></div></div>= <div><br></div><div>But most of us wo=3D
> uld like to have multiple queries in parallel:</div><div>&= lt;br></div><div><di=3D
> v>
> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSClient Client =3D3D new DNSClie= nt ();</div></div><=3D
> div><br></div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 // Non blocking request</div><di=3D
> v><div><span class=3D3D"Apple-style-span">=3D= A0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSMessage =3D
> Request =3D3D new DNSQueryMessage (Domain,=3DA0</span>EDNS.DNSTy= pe.A<span class=3D
> =3D3D"Apple-style-span">);</span></div>
> </div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSTransact= ion Transaction1 =3D3D Client.S=3D
> end (Request);</div><div><br></div><div>= <div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 D=3D
> NSMessage Request =3D3D new DNSQueryMessage (Domain,=3DA0EDNS.DNSType.= CAA);</di=3D
> v></div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 DNSTra= nsaction Transaction2 =3D3D Client=3D
> .Send (Request);</div>
> </div><div><br></div><div>=3DA0 =3DA0 = =3DA0 =3DA0 =3DA0 =3DA0 // Does other useful stuf=3D
> f like create the message headers</div><div>=3DA0 =3DA0 = =3DA0 =3DA0 =3DA0 =3DA0 // Can =3D
> poll status of transactions using=3DA0DNSTransaction.Complete ()</d= iv><div><b=3D
> r></div><div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = =3DA0 Response =3D3D Client.Receive (Tran=3D
> saction1);</div>
> </div><div><div>=3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 = Response =3D3D Client.Receive (Transa=3D
> ction2);</div></div><div><br></div><d= iv><br></div><div>And that is still mu=3D
> ch less than you would want a .NET library to provide. A proper .NET l= ibrar=3D
> y should let the caller loop things into the asynchronous caller.</= div>
> <div><br></div><div>Ultimately, the goal is to= produce a subclass of the Tc=3D
> pClient class such that the only difference that the programmer needs = to co=3D
> nsider is to replace the creation method:</div><div><br= ></div><div><span cl=3D
> ass=3D3D"Apple-style-span" style=3D3D"font-family: &= ;#39;Segoe UI&#39;, Verdana,=3D
> =A0Arial; font-size: 17px; "><pre style=3D3D"padding-t= op: 5px; padding-right: 5=3D
> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px; margin-ri= ght: =3D
> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas, Cour= ier, =3D
> monospace; word-break: break-all; word-wrap: break-word; font-style: n= ormal=3D
> ; font-weight: normal; overflow-x: auto; overflow-y: auto; "><= br> > <span style=3D3D"color: blue; ">public</span> Tc= pClient(<span style=3D3D"color:=3D
> =A0blue; ">string</span> hostname, <span style=3D3D&q= uot;color: blue; ">int</span> p=3D
> ort)</pre></span></div><div><br></div= ><div>with the creation method:</div><=3D
> div>
> <br></div><div><span class=3D3D"Apple-style-= span" style=3D3D"font-family: &#39;=3D
> Segoe UI&#39;, Verdana, Arial; font-size: 17px; "><pre = style=3D3D"padding-top=3D
> : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; mar= gin-t=3D
> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font= -fami=3D
> ly: Consolas, Courier, monospace; word-break: break-all; word-wrap: br= eak-w=3D
> ord; font-style: normal; font-weight: normal; overflow-x: auto; overfl= ow-y:=3D
> =A0auto; ">
> <span style=3D3D"color: blue; ">public</span> In= ternetClient(<span style=3D3D"c=3D
> olor: blue; ">string</span> hostname, <span style=3D3= D"color: blue; ">string<=3D
> /span> service, int port)</pre></span></div><d= iv><br></div><div><br></div><=3D
> div>
> The difference here is the level of abstraction. TcpClient connects vi= a hos=3D
> tname and port and always returns a raw bytestream. = InternetClient uses the=3D
> =A0DNS to determine what the best connection that is available for a s= ervice.=3D
> =A0If the best connection is raw TCP it will return that, if it = can form an S=3D
> SL socket, it will return that.</div>
> <div><br></div><div>[Yes, I know that there is= also the question of how to =3D
> specify &#39;best&#39;, but that is something that is more usu= ally somethin=3D
> g you want to specify at the host level or higher and want to avoid em= beddi=3D
> ng in actual applications]</div>
> <div><br></div><div>This actually has a major = performance advantage in the =3D
> right hands because the implementation can also be a= synchronous. So in the =3D
> typical calling sequence we would have:</div><div>&l= t;br></div><div>// Create =3D
> the socket</div>
> <div>// Generate the message headers</div><div>// Ch= eck the socket is OK</d=3D
> iv><div>// Send the first byte</div><div><br&g= t;</div><div>In terms of timing =3D
> what would be going on is:</div><div><br></div>= ;<div><div>// Create the sock=3D
> et</div>
> <div>=3DA0 [Async socket establishment starts]</div><di= v>// Generate the mess=3D
> age headers</div><div>=3DA0 [Wait for the socket to be com= pleted]</div><div>/=3D
> / Check the socket is OK</div><div>// Send the first byte&= lt;/div></div><div><=3D
> br>
> </div><div><br></div><div>Now in my pref= erred programming language, you cou=3D
> ld just throw up a PAR statement and it would work anyway, but very fe= w pro=3D
> grammers grok that sort of stuff.</div><div><br><= /div><div><br><div class=3D
> =3D3D"gmail_quote">
> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <span dir=3D3D"l= tr">&lt;<a href=3D
> =3D3D"mailto:marka@isc.org&q= uot;>marka@isc.org</a>&gt= ;</span> wrote:<br><blockquot=3D
> e class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;= border-left:1px #ccc sol=3D
> id;padding-left:1ex;">
> <br>
> In message &lt;<a href=3D3D"mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2= VYw@mail=3D
> .gmail.com">= ;BA= NLkTimX2XRgJHSkUq-GAAMDs+Mb6V2VYw@mail.gmail.com</a>&gt;, Phi= =3D
> llip Hallam-<br>
> <div class=3D3D"im">Baker writes:<br>
> &gt; I guess that would work for the application programmers who s= till code=3D
> =A0in C<br>
> &gt; or C++. That is not where the industry has been for a decade = now.<br>
> <br>
> </div>The concepts are language independent.<br>
> <font color=3D3D"#888888"><br>
> --<br>
> </font><div><div></div><div class=3D3D"= ;h5">Mark Andrews, ISC<br>
> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
> PHONE: <a href=3D3D"tel:%2B61%202%209871%204742" value=3D= 3D"+61298714742<= /a>">+61 2=3D
> =A09871 4742</a> =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0= INTERNET: <a href=3D3D"mailto:=3D
> marka@isc.org">marka@isc.org</a><br>
> </div></div></blockquote></div><br><b= r clear=3D3D"all"><br>-- <br>Website: <a=3D
> =A0href=3D3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>=
> </div>
>
> --0016e68debd4b5f20c04a6db8b0b--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org



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

--001636c92c62a9a1b404a6e36f48-- From eosterweil@verisign.com Thu Jun 30 07:52:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB07F11E80D4 for ; Thu, 30 Jun 2011 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f997moB5r2RI for ; Thu, 30 Jun 2011 07:52:39 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7820211E8092 for ; Thu, 30 Jun 2011 07:52:36 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTgyNtKSwynXBLVxceYHvrGBLhQbXkx/a@postini.com; Thu, 30 Jun 2011 07:52:38 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p5UEqZhI030157; Thu, 30 Jun 2011 10:52:35 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 10:52:34 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 14:51:46 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 10:51:45 -0400 From: "Osterweil, Eric" To: Adam Langley , Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw1wGuG0OumIrkES2mNmxIF/rfnfABdM+BS In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2011 14:52:34.0907 (UTC) FILETIME=[58C60AB0:01CC3735] Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:52:40 -0000 On 6/28/11 2:22 PM, "Adam Langley" wrote: > As promised. (This is also the format that Chrome is using for it's > DNSSEC stapled certificate support.) > > http://tools.ietf.org/html/draft-agl-dane-serializechain-00 I think I may be missing something here, so can someone clarify the following for me: what happens if someone encodes the chain of trust in one of these certs, and then the zones in that chain change their keys (rollovers, revocations, etc.)? Isn't encoding a dynamic chain of trust in a static cert a requirements mismatch? Eric From hallam@gmail.com Thu Jun 30 08:31:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13F711E807E for ; Thu, 30 Jun 2011 08:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlF0x06lV5UD for ; Thu, 30 Jun 2011 08:31:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2F11E81EC for ; Thu, 30 Jun 2011 08:31:10 -0700 (PDT) Received: by gyd5 with SMTP id 5so809314gyd.31 for ; Thu, 30 Jun 2011 08:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oEPQALKrn3YQyr9COlNEfe+ZK/21PpYnVEbcQ8HZHSs=; b=sUvV+VSADph6yNC9k7IawfEoH3HCysFhGuzpT0dKotLmc8dXxdmaqKjGuxpFdiJ1Qp l3YDUyrnpRAIsxXDpBC0H4G+QYGpYY+IMfyHLJbGzjBRFrv8bbOxPhwcebuN94nzGCye IxG2JPbJDvBUA4moxWluEhQoy098sRFErYdfA= MIME-Version: 1.0 Received: by 10.101.177.8 with SMTP id e8mr1984866anp.128.1309447869913; Thu, 30 Jun 2011 08:31:09 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Thu, 30 Jun 2011 08:31:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 11:31:09 -0400 Message-ID: From: Phillip Hallam-Baker To: "Osterweil, Eric" Content-Type: multipart/alternative; boundary=001636c92c6223588f04a6ef9706 Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:31:24 -0000 --001636c92c6223588f04a6ef9706 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 30, 2011 at 10:51 AM, Osterweil, Eric wrote: > > > > On 6/28/11 2:22 PM, "Adam Langley" wrote: > > > As promised. (This is also the format that Chrome is using for it's > > DNSSEC stapled certificate support.) > > > > http://tools.ietf.org/html/draft-agl-dane-serializechain-00 > > > I think I may be missing something here, so can someone clarify the > following for me: what happens if someone encodes the chain of trust in one > of these certs, and then the zones in that chain change their keys > (rollovers, revocations, etc.)? Isn't encoding a dynamic chain of trust in > a static cert a requirements mismatch? I don't understand the problem here. The RSIG values have an absolute validity interval (i.e. not relative) This is a pickled RSIG chain from a specific point in time. It says nothing about the validity of the chain at any other point in time. Unless there is a major flaw in DNSSEC, I can't see where there would be an issue here. -- Website: http://hallambaker.com/ --001636c92c6223588f04a6ef9706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 30, 2011 at 10:51 AM, Osterw= eil, Eric <= eosterweil@verisign.com> wrote:



On 6/28/11 2:22 PM, "Adam Langley" <agl@imperialviolet.org> wrote:

> As promised. (This is also the format that Chrome is using for it'= s
> DNSSEC stapled certificate support.)
>
> http://tools.ietf.org/html/draft-agl-dane-serializechai= n-00


I think I may be missing something here, so can someone clarify the following for me: what happens if someone encodes the chain of trust in one=
of these certs, and then the zones in that chain change their keys
(rollovers, revocations, etc.)? =A0Isn't encoding a dynamic chain of tr= ust in
a static cert a requirements mismatch?

I do= n't understand the problem here. The RSIG values have an absolute valid= ity interval (i.e. not relative)

This is a pic= kled RSIG chain from a specific point in time. It says nothing about the va= lidity of the chain at any other point in time.

Unless there is a major flaw in DNSSEC, I can't see wher= e there would be an issue here.
--
Website: http://hallambaker.com/

--001636c92c6223588f04a6ef9706-- From eosterweil@verisign.com Thu Jun 30 08:42:48 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985F811E8187 for ; Thu, 30 Jun 2011 08:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3MQ+u+DUXKm for ; Thu, 30 Jun 2011 08:42:47 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id C140011E8185 for ; Thu, 30 Jun 2011 08:42:46 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKTgyZdYuF24KT52H/RVZuG/maVMVAIilH@postini.com; Thu, 30 Jun 2011 08:42:47 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p5UFgiAb001624; Thu, 30 Jun 2011 11:42:44 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 11:42:44 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 15:41:47 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 11:41:47 -0400 From: "Osterweil, Eric" To: Phillip Hallam-Baker Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3OsdJNluPaZU8Tt+XduWlVYGxhQAAXETV In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 30 Jun 2011 15:42:44.0425 (UTC) FILETIME=[5A960B90:01CC373C] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:42:48 -0000 On 6/30/11 11:31 AM, "Phillip Hallam-Baker" wrote: >=20 >=20 > On Thu, Jun 30, 2011 at 10:51 AM, Osterweil, Eric > wrote: >>=20 >>=20 >>=20 >> On 6/28/11 2:22 PM, "Adam Langley" wrote: >>=20 >>>> As promised. (This is also the format that Chrome is using for it's >>>> DNSSEC stapled certificate support.) >>>>=20 >>>> http://tools.ietf.org/html/draft-agl-dane-serializechain-00 >>=20 >>=20 >> I think I may be missing something here, so can someone clarify the >> following for me: what happens if someone encodes the chain of trust in = one >> of these certs, and then the zones in that chain change their keys >> (rollovers, revocations, etc.)? =A0Isn't encoding a dynamic chain of trust= in >> a static cert a requirements mismatch? >=20 > I don't understand the problem here. The RSIG values have an absolute val= idity > interval (i.e. not relative) >=20 > This is a pickled RSIG chain from a specific point in time. It says nothi= ng > about the validity of the chain at any other point in time. >=20 > Unless there is a major flaw in DNSSEC, I can't see where there would be = an > issue here. Well if you get a cert, and it says, "I'm valid because the following DNSSE chain is valid," then you are either using THAT chain instead of the curren= t chain of trust (in which case I ask why), or something else that I don't understand. Why are you using a representation of the delegation tree that may not be current anymore? Further, are these certs going to be reissued reliably as the root key changes? I see in the draft that this is (obviously) predicated on trustin= g a root key, but this value will change (albeit slowly). So, I guess you have to re-encode your cert when the root key rolls? Eric From fanf2@hermes.cam.ac.uk Thu Jun 30 09:09:52 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40921F8633 for ; Thu, 30 Jun 2011 09:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfpXndgNjmWo for ; Thu, 30 Jun 2011 09:09:47 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5A16221F8630 for ; Thu, 30 Jun 2011 09:09:47 -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]:56477) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QcJoE-0002jf-Xn (Exim 4.72) (return-path ); Thu, 30 Jun 2011 17:09:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QcJoE-0006sQ-F8 (Exim 4.67) (return-path ); Thu, 30 Jun 2011 17:09:42 +0100 Date: Thu, 30 Jun 2011 17:09:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Osterweil, Eric" In-Reply-To: Message-ID: References: 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: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:09:52 -0000 Osterweil, Eric wrote: > > Well if you get a cert, and it says, "I'm valid because the following DNSSE > chain is valid," then you are either using THAT chain instead of the current > chain of trust (in which case I ask why), or something else that I don't > understand. It is to avoid the latency of extra DNSSEC lookups by the client. > Further, are these certs going to be reissued reliably as the root key > changes? Root key rollovers are irrelevant (and in practice impossible) since the RRSIG records will expire much much more frequently. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Northwest 5 to 7, perhaps gale 8 later. Moderate or rough. Showers. Good. From eosterweil@verisign.com Thu Jun 30 10:19:08 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7048C11E8275 for ; Thu, 30 Jun 2011 10:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmtLukUfVp98 for ; Thu, 30 Jun 2011 10:19:07 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3560B11E8271 for ; Thu, 30 Jun 2011 10:19:04 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTgywBjnyp5eW3jz37VJsMADUxi5HXW+G@postini.com; Thu, 30 Jun 2011 10:19:07 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p5UHJ15g009563; Thu, 30 Jun 2011 13:19:02 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 13:19:01 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 17:18:54 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 13:18:53 -0400 From: "Osterweil, Eric" To: Tony Finch Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3QDLvx+kKQEycTSuzjrkj9qixuAACZX9v In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2011 17:19:01.0703 (UTC) FILETIME=[CE1CB570:01CC3749] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 17:19:08 -0000 On 6/30/11 12:09 PM, "Tony Finch" wrote: > Osterweil, Eric wrote: >> >> Well if you get a cert, and it says, "I'm valid because the following DNSSE >> chain is valid," then you are either using THAT chain instead of the current >> chain of trust (in which case I ask why), or something else that I don't >> understand. > > It is to avoid the latency of extra DNSSEC lookups by the client. So, you're proposing an architecture that splits data from its authoritative sources (DNS zones), and freezes it in a cert whose semantics have no relationship to DNS, rather than incur a handful of DNS lookups to be sure the trust is intact? This is very much more likely to cause problems than save any. Keys change for various reasons (including compromises), and having frozen keys in external stores that have no coupling to the authoritative sources is a dangerous slippery slope. > >> Further, are these certs going to be reissued reliably as the root key >> changes? > > Root key rollovers are irrelevant (and in practice impossible) since the > RRSIG records will expire much much more frequently. They are neither irrelevant nor (theoretically) impossible. Without more work they are operationally troubling, but that doesn't mean that one could never do one. However, the act of engaging in one (as per https://www.iana.org/dnssec/icann-dps.txt ) could _become_ impossible if (in addition to other complexities) we now create external dependencies that have no feeback to DNS. If there is (for example) a compromise, that key needs to be rolled over (or an algo rollover), the machinery exists now to do so (though testing needs more time). However, with this approach, there is no theoretical way to roll without orphaning SSL certs. This approach adds an architectural limitation that does not exist now. Right now we have operational concerns and the need to enhance mechanisms, not a non-start situation. Eric From rbarnes@bbn.com Thu Jun 30 11:16:32 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B2D9E8012 for ; Thu, 30 Jun 2011 11:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atR4me4lyzTV for ; Thu, 30 Jun 2011 11:16:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CB7829E800E for ; Thu, 30 Jun 2011 11:16:31 -0700 (PDT) Received: from [128.89.254.8] (port=63492 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QcLml-000En0-Gf; Thu, 30 Jun 2011 14:16:22 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 30 Jun 2011 14:16:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <786EF2BE-C379-4E04-8678-689D5A1E1B9D@bbn.com> References: To: "Osterweil, Eric" X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:16:32 -0000 You keep using words like "freeze" to describe the inclusion of = information in a cert. Not all certs have long lifetimes! In = particular, this system can work with self-signed certs, which a site = can issue for itself as often as needed -- including whenever a TTL or = validity period expires in the DNSSEC change. You could think of this as a way of shifting load/latency from the = client/online to server/offline -- from fetching/validating DNSSEC = records at service time to periodically re-constructing and re-signing a = certificate. =20 --Richard On Jun 30, 2011, at 1:18 PM, Osterweil, Eric wrote: >=20 >=20 >=20 > On 6/30/11 12:09 PM, "Tony Finch" wrote: >=20 >> Osterweil, Eric wrote: >>>=20 >>> Well if you get a cert, and it says, "I'm valid because the = following DNSSE >>> chain is valid," then you are either using THAT chain instead of the = current >>> chain of trust (in which case I ask why), or something else that I = don't >>> understand. >>=20 >> It is to avoid the latency of extra DNSSEC lookups by the client. >=20 > So, you're proposing an architecture that splits data from its = authoritative > sources (DNS zones), and freezes it in a cert whose semantics have no > relationship to DNS, rather than incur a handful of DNS lookups to be = sure > the trust is intact? This is very much more likely to cause problems = than > save any. Keys change for various reasons (including compromises), = and > having frozen keys in external stores that have no coupling to the > authoritative sources is a dangerous slippery slope. >=20 >>=20 >>> Further, are these certs going to be reissued reliably as the root = key >>> changes? >>=20 >> Root key rollovers are irrelevant (and in practice impossible) since = the >> RRSIG records will expire much much more frequently. >=20 > They are neither irrelevant nor (theoretically) impossible. Without = more > work they are operationally troubling, but that doesn't mean that one = could > never do one. However, the act of engaging in one (as per > https://www.iana.org/dnssec/icann-dps.txt ) could _become_ impossible = if (in > addition to other complexities) we now create external dependencies = that > have no feeback to DNS. If there is (for example) a compromise, that = key > needs to be rolled over (or an algo rollover), the machinery exists = now to > do so (though testing needs more time). However, with this approach, = there > is no theoretical way to roll without orphaning SSL certs. This = approach > adds an architectural limitation that does not exist now. Right now = we have > operational concerns and the need to enhance mechanisms, not a = non-start > situation. >=20 > Eric >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From eosterweil@verisign.com Thu Jun 30 11:24:23 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A5C9E8028 for ; Thu, 30 Jun 2011 11:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coIxFfOGsR0w for ; Thu, 30 Jun 2011 11:24:22 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 464C19E8019 for ; Thu, 30 Jun 2011 11:24:19 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKTgy/T1/JeFUApF/9Z55rdVXA+hCBFjWJ@postini.com; Thu, 30 Jun 2011 11:24:21 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p5UIOEwi013098; Thu, 30 Jun 2011 14:24:14 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 14:24:14 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 18:24:03 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 14:24:02 -0400 From: "Osterweil, Eric" To: "Richard L. Barnes" Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3UeT3fxmErycsTyKcV+kUn9zDFgAAP3me In-Reply-To: <786EF2BE-C379-4E04-8678-689D5A1E1B9D@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2011 18:24:14.0257 (UTC) FILETIME=[EA2D1210:01CC3752] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:24:24 -0000 Indeed, I know that they _can_ change. However, they may not (because people may not realize that them must). I think this is an important operational distinction. If someone simply doesn't change their cert (perhaps they don't understand the implications of failing to do so), then we get into trouble. As an analogy, DNSSEC shouldn't be nearly as operationally difficult as it is. If everyone just knew how to use it and promised to follow best practices... Right? ;) Managing the crypto in just one system is hard enough, this seems to inheret baggage from two crypto-enhanced systems... :-/ But seriously, what worries me is that people will create certs this way (using what I'm sure will turn out to be very easy tools), and then just not regenerate them (if it ain't broke, don't fix it). These will become serious problems because large DNSSEC registries simply cannot be responsible for blacking out a large deployment cross-section if these certs will suddenly fail to validate. I chose the term "freeze" because of the relative disconnection between the cert management process that is trying to reflect the status of the DNS, and the operational lifecycle of DNS zones. Is there a better word? Perhaps the wording is confusing the issue here? Eric On 6/30/11 2:16 PM, "Richard L. Barnes" wrote: > You keep using words like "freeze" to describe the inclusion of information in > a cert. Not all certs have long lifetimes! In particular, this system can > work with self-signed certs, which a site can issue for itself as often as > needed -- including whenever a TTL or validity period expires in the DNSSEC > change. > > You could think of this as a way of shifting load/latency from the > client/online to server/offline -- from fetching/validating DNSSEC records at > service time to periodically re-constructing and re-signing a certificate. > > --Richard > > > On Jun 30, 2011, at 1:18 PM, Osterweil, Eric wrote: > >> >> >> >> On 6/30/11 12:09 PM, "Tony Finch" wrote: >> >>> Osterweil, Eric wrote: >>>> >>>> Well if you get a cert, and it says, "I'm valid because the following DNSSE >>>> chain is valid," then you are either using THAT chain instead of the >>>> current >>>> chain of trust (in which case I ask why), or something else that I don't >>>> understand. >>> >>> It is to avoid the latency of extra DNSSEC lookups by the client. >> >> So, you're proposing an architecture that splits data from its authoritative >> sources (DNS zones), and freezes it in a cert whose semantics have no >> relationship to DNS, rather than incur a handful of DNS lookups to be sure >> the trust is intact? This is very much more likely to cause problems than >> save any. Keys change for various reasons (including compromises), and >> having frozen keys in external stores that have no coupling to the >> authoritative sources is a dangerous slippery slope. >> >>> >>>> Further, are these certs going to be reissued reliably as the root key >>>> changes? >>> >>> Root key rollovers are irrelevant (and in practice impossible) since the >>> RRSIG records will expire much much more frequently. >> >> They are neither irrelevant nor (theoretically) impossible. Without more >> work they are operationally troubling, but that doesn't mean that one could >> never do one. However, the act of engaging in one (as per >> https://www.iana.org/dnssec/icann-dps.txt ) could _become_ impossible if (in >> addition to other complexities) we now create external dependencies that >> have no feeback to DNS. If there is (for example) a compromise, that key >> needs to be rolled over (or an algo rollover), the machinery exists now to >> do so (though testing needs more time). However, with this approach, there >> is no theoretical way to roll without orphaning SSL certs. This approach >> adds an architectural limitation that does not exist now. Right now we have >> operational concerns and the need to enhance mechanisms, not a non-start >> situation. >> >> Eric >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > From mrex@sap.com Thu Jun 30 11:42:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656B911E81F7 for ; Thu, 30 Jun 2011 11:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-g7F7ZYlczw for ; Thu, 30 Jun 2011 11:42:44 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 65C6711E8094 for ; Thu, 30 Jun 2011 11:42:44 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p5UIgePc004809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 20:42:40 +0200 (MEST) From: Martin Rex Message-Id: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> To: eosterweil@verisign.com (Osterweil, Eric) Date: Thu, 30 Jun 2011 20:42:39 +0200 (MEST) In-Reply-To: from "Osterweil, Eric" at Jun 30, 11 01:18:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:42:47 -0000 Osterweil, Eric wrote: > > So, you're proposing an architecture that splits data from its authoritative > sources (DNS zones), and freezes it in a cert whose semantics have no > relationship to DNS, rather than incur a handful of DNS lookups to be sure > the trust is intact? This is very much more likely to cause problems than > save any. Keys change for various reasons (including compromises), and > having frozen keys in external stores that have no coupling to the > authoritative sources is a dangerous slippery slope. I believe the RRSIG validitiy is more in the matter of hours to days. And for DNSSEC to work smoothly, there are transistion periods for DNS key rollover, so that when correctly rebuilding the to-be-signed data from currently valid data (rather than blindly resigning old data when RRSIG expires), the problem you are describing might not exist. -Martin From eosterweil@verisign.com Thu Jun 30 11:49:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1443811E80AC for ; Thu, 30 Jun 2011 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmti6l7iue5n for ; Thu, 30 Jun 2011 11:49:25 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id EAD0911E8077 for ; Thu, 30 Jun 2011 11:49:20 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKTgzFLwYzeD9JxPICG4u52UCnuLoi0gxA@postini.com; Thu, 30 Jun 2011 11:49:24 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p5UInJ0M016817; Thu, 30 Jun 2011 14:49:19 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 14:49:18 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 18:49:07 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 14:49:05 -0400 From: "Osterweil, Eric" To: Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3VZIICkayUzrQQlSu1Rqp2seQIQAANCzm In-Reply-To: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2011 18:49:18.0803 (UTC) FILETIME=[6AF49230:01CC3756] Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 18:49:27 -0000 On 6/30/11 2:42 PM, "Martin Rex" wrote: > Osterweil, Eric wrote: >> >> So, you're proposing an architecture that splits data from its authoritative >> sources (DNS zones), and freezes it in a cert whose semantics have no >> relationship to DNS, rather than incur a handful of DNS lookups to be sure >> the trust is intact? This is very much more likely to cause problems than >> save any. Keys change for various reasons (including compromises), and >> having frozen keys in external stores that have no coupling to the >> authoritative sources is a dangerous slippery slope. > > I believe the RRSIG validitiy is more in the matter of hours to days. It varies, and is set by each zone. Look at this for the current spectrum: http://secspider.cs.ucla.edu/images/key-lifetimes.png > > And for DNSSEC to work smoothly, there are transistion periods for > DNS key rollover, so that when correctly rebuilding the to-be-signed > data from currently valid data (rather than blindly resigning old > data when RRSIG expires), the problem you are describing might not > exist. In DNSSEC, yes, rollovers are handled "smoothly", but what keeps the cert in sync? If a cert exists for (say) a month, but a key rollover happens on week 1 of the cert's lifetime, then the rollover will have completed long before someone plans to re-examine and regenerate their cert. Moreover, how often do people roll their certs now? I ask because the existing behavior is a much better indicator of future behavior than what one _hopes_ people will do. Why do you think cert owners will suddenly know how to manage the cross system dependencies? Eric From hallam@gmail.com Thu Jun 30 12:04:24 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED75221F84D8 for ; Thu, 30 Jun 2011 12:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWqPfdbMjIP3 for ; Thu, 30 Jun 2011 12:04:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEFD911E80CB for ; Thu, 30 Jun 2011 12:04:17 -0700 (PDT) Received: by ywp31 with SMTP id 31so1289426ywp.31 for ; Thu, 30 Jun 2011 12:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jC+xRrAdwV8geCqS6UkjdkWJPQDipRP+HaS0qOm+Oi4=; b=gJDJ9fklhD8SBNAlYNjfcWNOq56ihkrLrKpLUjfByJIzyXmVEitnLgSFwILreagKK9 Y15MWD3xgueB1WD2wqDKvnJF12NZiWO1gt+sV3mHwKx9jPJDpB4GdAD8wqLY0Yu8RhrB 6FammYYw7fOEXaFj3wcrSgTVLu/WDwdQD9p5I= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr2161794anh.40.1309460656953; Thu, 30 Jun 2011 12:04:16 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Thu, 30 Jun 2011 12:04:16 -0700 (PDT) In-Reply-To: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> References: <201106301842.p5UIgdjK017407@fs4113.wdf.sap.corp> Date: Thu, 30 Jun 2011 15:04:16 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016369fa2524e1a5204a6f2915d Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:04:25 -0000 --0016369fa2524e1a5204a6f2915d Content-Type: text/plain; charset=ISO-8859-1 There seems to be a lot of confusion here about what such a system can provide. As I understand it, the proposal is simply a method of using the DNSSEC certification chain and the DNS RR formats to establish that the Domain Name holder authorized the issue of the certificate at the instant of issue. Thus the only relevant data required to validate the certificate would be the ICANN DNS root of roots for the time instant that the certificate was issued. The rolling of the ICANN root is going to present browsers using this scheme with the operational challenge of how to update the ICANN root when it rolls. But that is easily solved for Chrome because it insists on updating itself at regular intervals. Root rollover is not any sort of issue for the self signed cert holder. This approach solve the use cases and requirements stated in the Use cases and requirements document. It does so without requiring the end point client to have access to a DNSSEC enabled resolver. It appear to me that it is considerably better than the scheme proposed in the Hoffman et. al. draft and it has the benefit of actual deployed code. This is not the way that I imagined solving the DANE use cases, but this approach is better than my proposal in respect of the key distribution part. It does not address the issue of security policy, promiscuous use of SSL, strict security etc. but that is not a necessity. The question that comes up as far as security policy is concerned is how recent a signature should be to be recognized. Should this type of self signed cert be valid for an hour, a day a week, a year, a decade? I think we can knock out the idea of an hour or a day pretty easily. The clock synchronization problem makes systems with cert expiry times of less than about three days unnecessarily unusable. At the longer end I would really, really not like to have people recognizing such certs as valid for more than existing DV certs are recognized. I think that the max validity of such certs should be pinned at a short value, that is weeks or months. It is really easy to automate this type of system. So I don't see a reason to make the max validity long. The server already has the key, every x hours it simply checks to see if its SSL cert is out of date and generates a new one. I would guess that this is why Adam is so keen on the authentication being to the public key (which is not going to change) rather than the cert. Rolling the cert is easy in this scheme. Rolling the key will require a DNS operation, but that can be automated as well. On Thu, Jun 30, 2011 at 2:42 PM, Martin Rex wrote: > Osterweil, Eric wrote: > > > > So, you're proposing an architecture that splits data from its > authoritative > > sources (DNS zones), and freezes it in a cert whose semantics have no > > relationship to DNS, rather than incur a handful of DNS lookups to be > sure > > the trust is intact? This is very much more likely to cause problems > than > > save any. Keys change for various reasons (including compromises), and > > having frozen keys in external stores that have no coupling to the > > authoritative sources is a dangerous slippery slope. > > I believe the RRSIG validitiy is more in the matter of hours to days. > > And for DNSSEC to work smoothly, there are transistion periods for > DNS key rollover, so that when correctly rebuilding the to-be-signed > data from currently valid data (rather than blindly resigning old > data when RRSIG expires), the problem you are describing might not > exist. > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016369fa2524e1a5204a6f2915d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There seems to be a lot of confusion here about what such a system can prov= ide.

As I understand it, the proposal is simply a method= of using the DNSSEC certification chain and the DNS RR formats to establis= h that the Domain Name holder authorized the issue of the certificate at th= e instant of issue.

Thus the only relevant data required to validate the ce= rtificate would be the ICANN DNS root of roots for the time instant that th= e certificate was issued.


The rolli= ng of the ICANN root is going to present browsers using this scheme with th= e operational challenge of how to update the ICANN root when it rolls. But = that is easily solved for Chrome because it insists on updating itself at r= egular intervals. Root rollover is not any sort of issue for the self signe= d cert holder.

This approach solve the use cases and requirements stat= ed in the Use cases and requirements document. It does so without requiring= the end point client to have access to a DNSSEC enabled resolver. It appea= r to me that it is considerably better than the scheme proposed in the Hoff= man et. al. draft and it has the benefit of actual deployed code.

This is not the way that I imagined solving the DANE us= e cases, but this approach is better than my proposal in respect of the key= distribution part. It does not address the issue of security policy, promi= scuous use of SSL, strict security etc. but that is not a necessity.


The question that comes up as far as security polic= y is concerned is how recent a signature should be to be recognized. Should= this type of self signed cert be valid for an hour, a day a week, a year, = a decade?

I think we can knock out the idea of an hour or a day p= retty easily. The clock synchronization problem makes systems with cert exp= iry times of less than about three days unnecessarily unusable.

At the longer end I would really, really not like to have pe= ople recognizing such certs as valid for more than existing DV certs are re= cognized.

I think that the max validity of such ce= rts should be pinned at a short value, that is weeks or months.=A0

It is really easy to automate this type of system. So I= don't see a reason to make the max validity long. The server already h= as the key, every x hours it simply checks to see if its SSL cert is out of= date and generates a new one. I would guess that this is why Adam is so ke= en on the authentication being to the public key (which is not going to cha= nge) rather than the cert.

Rolling the cert is easy in this scheme. Rolling the ke= y will require a DNS operation, but that can be automated as well.


On Thu, Jun 30, 2011 at 2:4= 2 PM, Martin Rex <mrex= @sap.com> wrote:
Osterweil, Eric wrote: >
> So, you're proposing an architecture that splits data from its aut= horitative
> sources (DNS zones), and freezes it in a cert whose semantics have no<= br> > relationship to DNS, rather than incur a handful of DNS lookups to be = sure
> the trust is intact? =A0This is very much more likely to cause problem= s than
> save any. =A0Keys change for various reasons (including compromises), = and
> having frozen keys in external stores that have no coupling to the
> authoritative sources is a dangerous slippery slope.

I believe the RRSIG validitiy is more in the matter of hours to days.=

And for DNSSEC to work smoothly, there are transistion periods for
DNS key rollover, so that when correctly rebuilding the to-be-signed
data from currently valid data (rather than blindly resigning old
data when RRSIG expires), the problem you are describing might not
exist.

-Martin
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016369fa2524e1a5204a6f2915d-- From rbarnes@bbn.com Thu Jun 30 12:09:18 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C6311E8094 for ; Thu, 30 Jun 2011 12:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4TWFyNxDGgs for ; Thu, 30 Jun 2011 12:09:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E445421F85A5 for ; Thu, 30 Jun 2011 12:09:15 -0700 (PDT) Received: from [128.89.254.8] (port=63934 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QcMbu-000HcE-IB; Thu, 30 Jun 2011 15:09:10 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 30 Jun 2011 15:09:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Osterweil, Eric" X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:09:18 -0000 > Managing the crypto in just > one system is hard enough, this seems to inheret baggage from two > crypto-enhanced systems... :-/ I don't think it's quite that bad. There's not really any PKIX baggage, = since the all of the crypto validation comes from the DNSSEC extension. =20= The risk of falling out of sync may just be part of the trade-off for = speed. It seems like there's a plausible solution (mod_dnssec_staple), = so it doesn't seem like it necessarily has to be a blocking issue. --Richard =20 > But seriously, what worries me is that people will create certs this = way > (using what I'm sure will turn out to be very easy tools), and then = just not > regenerate them (if it ain't broke, don't fix it). These will become > serious problems because large DNSSEC registries simply cannot be > responsible for blacking out a large deployment cross-section if these = certs > will suddenly fail to validate. >=20 > I chose the term "freeze" because of the relative disconnection = between the > cert management process that is trying to reflect the status of the = DNS, and > the operational lifecycle of DNS zones. Is there a better word? = Perhaps > the wording is confusing the issue here? >=20 > Eric =20 >=20 >=20 > On 6/30/11 2:16 PM, "Richard L. Barnes" wrote: >=20 >> You keep using words like "freeze" to describe the inclusion of = information in >> a cert. Not all certs have long lifetimes! In particular, this = system can >> work with self-signed certs, which a site can issue for itself as = often as >> needed -- including whenever a TTL or validity period expires in the = DNSSEC >> change. >>=20 >> You could think of this as a way of shifting load/latency from the >> client/online to server/offline -- from fetching/validating DNSSEC = records at >> service time to periodically re-constructing and re-signing a = certificate. >>=20 >> --Richard >>=20 >>=20 >> On Jun 30, 2011, at 1:18 PM, Osterweil, Eric wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On 6/30/11 12:09 PM, "Tony Finch" wrote: >>>=20 >>>> Osterweil, Eric wrote: >>>>>=20 >>>>> Well if you get a cert, and it says, "I'm valid because the = following DNSSE >>>>> chain is valid," then you are either using THAT chain instead of = the >>>>> current >>>>> chain of trust (in which case I ask why), or something else that I = don't >>>>> understand. >>>>=20 >>>> It is to avoid the latency of extra DNSSEC lookups by the client. >>>=20 >>> So, you're proposing an architecture that splits data from its = authoritative >>> sources (DNS zones), and freezes it in a cert whose semantics have = no >>> relationship to DNS, rather than incur a handful of DNS lookups to = be sure >>> the trust is intact? This is very much more likely to cause = problems than >>> save any. Keys change for various reasons (including compromises), = and >>> having frozen keys in external stores that have no coupling to the >>> authoritative sources is a dangerous slippery slope. >>>=20 >>>>=20 >>>>> Further, are these certs going to be reissued reliably as the root = key >>>>> changes? >>>>=20 >>>> Root key rollovers are irrelevant (and in practice impossible) = since the >>>> RRSIG records will expire much much more frequently. >>>=20 >>> They are neither irrelevant nor (theoretically) impossible. Without = more >>> work they are operationally troubling, but that doesn't mean that = one could >>> never do one. However, the act of engaging in one (as per >>> https://www.iana.org/dnssec/icann-dps.txt ) could _become_ = impossible if (in >>> addition to other complexities) we now create external dependencies = that >>> have no feeback to DNS. If there is (for example) a compromise, = that key >>> needs to be rolled over (or an algo rollover), the machinery exists = now to >>> do so (though testing needs more time). However, with this = approach, there >>> is no theoretical way to roll without orphaning SSL certs. This = approach >>> adds an architectural limitation that does not exist now. Right now = we have >>> operational concerns and the need to enhance mechanisms, not a = non-start >>> situation. >>>=20 >>> Eric >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 From eosterweil@verisign.com Thu Jun 30 12:56:12 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6B511E815B for ; Thu, 30 Jun 2011 12:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu7uTAX0Wx-c for ; Thu, 30 Jun 2011 12:56:11 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB0711E8218 for ; Thu, 30 Jun 2011 12:55:36 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTgzUtrvfeUdb7g5MnVLLPzoIZDiTuRHa@postini.com; Thu, 30 Jun 2011 12:55:38 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p5UJtX2R019898; Thu, 30 Jun 2011 15:55:34 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 15:55:33 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 19:55:00 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 15:54:59 -0400 From: "Osterweil, Eric" To: Phillip Hallam-Baker , Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3WJbkZsV8qJHyRQWYWcTsYBv3YwABwCaB In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 30 Jun 2011 19:55:33.0836 (UTC) FILETIME=[AC4278C0:01CC375F] Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:56:12 -0000 On 6/30/11 3:04 PM, "Phillip Hallam-Baker" wrote: > There seems to be a lot of confusion here about what such a system can > provide. >=20 > As I understand it, the proposal is simply a method of using the DNSSEC > certification chain and the DNS RR formats to establish that the Domain N= ame > holder authorized the issue of the certificate at the instant of issue. This is the crux of the disconnect, the delegation chain is not static, it doesn't lend itself well to snapshots. If you take a snapshot w/ a key tha= t later becomes compromised, and an adversary takes the compromised key and mints a new cert, how does this approach distinguish them? In DNSSEC, the zone will be serving the NEW key, not the old one. The chain will correct itself. This approach would accept the forged cert chain as well as the ol= d one. >=20 > Thus the only relevant data required to validate the certificate would be= the > ICANN DNS root of roots for the time instant that the certificate was iss= ued. No, I don't think so. If the cert has the old root key, and chrome has the new one, then won't it look unverifiable? The cert will disagree with what's in DNS. >=20 >=20 > The rolling of the ICANN root is going to present browsers using this sch= eme > with the operational challenge of how to update the ICANN root when it ro= lls. Again, I think it is the _CERT_ that has the problem, not the browsers. > But that is easily solved for Chrome because it insists on updating itsel= f at > regular intervals. Root rollover is not any sort of issue for the self si= gned > cert holder. >=20 > This approach solve the use cases and requirements stated in the Use case= s and > requirements document. It does so without requiring the end point client = to > have access to a DNSSEC enabled resolver. It appear to me that it is > considerably better than the scheme proposed in the Hoffman et. al. draft= and > it has the benefit of actual deployed code. Deployed code can still lead to very large outages if the architecture has problems. In fact, even if the architecture is "sound" this adds a LOT of operational complexity by trying to crystallize (maybe not freeze :-P ) the dynamic chain of trust. >=20 > This is not the way that I imagined solving the DANE use cases, but this > approach is better than my proposal in respect of the key distribution pa= rt. > It does not address the issue of security policy, promiscuous use of SSL, > strict security etc. but that is not a necessity. >=20 >=20 > The question that comes up as far as security policy is concerned is how > recent a signature should be to be recognized. Should this type of self s= igned > cert be valid for an hour, a day a week, a year, a decade? No, I don't think so. You're trying to codify a new/differnt notion of freshness that is already implicit in the "is it being served in DNS right now. Trying to cobble this together from external pieces is dangerous because it is likely to be wrong/misunderstood/have new operational complexities that we don't yet understand/etc. >=20 > I think we can knock out the idea of an hour or a day pretty easily. The = clock > synchronization problem makes systems with cert expiry times of less than > about three days unnecessarily unusable. >=20 > At the longer end I would really, really not like to have people recogniz= ing > such certs as valid for more than existing DV certs are recognized. >=20 > I think that the max validity of such certs should be pinned at a short v= alue, > that is weeks or months.=A0 Should huh? Take a look at the DNSSEC key lifetimes. They SHOULD not be years, but the graph I sent shows that people will do whatever they want. It's quite important for the underlying systems to not risk breakage any more than necessary, and this approach has a lot of fragility because of it= s cross-system dependencies. =20 > It is really easy to automate this type of system. So I don't see a reaso= n to > make the max validity long. The server already has the key, every x hours= it > simply checks to see if its SSL cert is out of date and generates a new o= ne. I > would guess that this is why Adam is so keen on the authentication being = to > the public key (which is not going to change) rather than the cert. Seriously? I think reviewing some of the trials and tribulations of exactl= y this kind of statement in the DNSSEC operational work would be quite illuminating. These "easy" things really turn out to be not so easy, especially where existing practices work against the new proposals. This i= s a very complex change, even if the mechanics seem easy. >=20 > Rolling the cert is easy in this scheme. Rolling the key will require a D= NS > operation, but that can be automated as well. I think the operational machinery and learning curve should not be so greatly underestimated. Eric=20 =20 >=20 > On Thu, Jun 30, 2011 at 2:42 PM, Martin Rex wrote: >> Osterweil, Eric wrote: >>>>=20 >>>> So, you're proposing an architecture that splits data from its >>> authoritative >>>> sources (DNS zones), and freezes it in a cert whose semantics have no >>>> relationship to DNS, rather than incur a handful of DNS lookups to be = sure >>>> the trust is intact? =A0This is very much more likely to cause problems = than >>>> save any. =A0Keys change for various reasons (including compromises), an= d >>>> having frozen keys in external stores that have no coupling to the >>>> authoritative sources is a dangerous slippery slope. >>=20 >> I believe the RRSIG validitiy is more in the matter of hours to days. >>=20 >> And for DNSSEC to work smoothly, there are transistion periods for >> DNS key rollover, so that when correctly rebuilding the to-be-signed >> data from currently valid data (rather than blindly resigning old >> data when RRSIG expires), the problem you are describing might not >> exist. >>=20 >> -Martin >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 >=20 From eosterweil@verisign.com Thu Jun 30 12:57:41 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7811E815B for ; Thu, 30 Jun 2011 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eQejmIu1wNm for ; Thu, 30 Jun 2011 12:57:41 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id D7D9B11E80CF for ; Thu, 30 Jun 2011 12:57:38 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKTgzVMGpz5sgaEuYGd4qzTfyx3vDKLLWT@postini.com; Thu, 30 Jun 2011 12:57:41 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p5UJvZoJ021690; Thu, 30 Jun 2011 15:57:35 -0400 Received: from DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 15:57:35 -0400 Received: from 10.131.30.110 ([10.131.30.110]) by DUL1WNEXMB11.vcorp.ad.vrsn.com ([10.170.13.11]) with Microsoft Exchange Server HTTP-DAV ; Thu, 30 Jun 2011 19:57:21 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 30 Jun 2011 15:57:20 -0400 From: "Osterweil, Eric" To: "Richard L. Barnes" Message-ID: Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw3WT9FtCpNQz7iSFCPlX1z65r90wABqxGG In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Jun 2011 19:57:35.0046 (UTC) FILETIME=[F481A660:01CC375F] Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:57:42 -0000 On 6/30/11 3:09 PM, "Richard L. Barnes" wrote: >> Managing the crypto in just >> one system is hard enough, this seems to inheret baggage from two >> crypto-enhanced systems... :-/ > > I don't think it's quite that bad. There's not really any PKIX baggage, since > the all of the crypto validation comes from the DNSSEC extension. > > The risk of falling out of sync may just be part of the trade-off for speed. > It seems like there's a plausible solution (mod_dnssec_staple), so it doesn't > seem like it necessarily has to be a blocking issue. Again, I think the operational complexities are being vastly underestimated. The certs have to be regenerated by authorities for websites based on changes in DNS zones that exist anywhere along the validation chain. In particular, how many web server admins keep track of when the root changes its ZSKs? I know of the top of my head, but I still would find it a pain if I had to go regen certs because someone popped a key somewhere... I still don't even know how I would find that out? Eric From mrex@sap.com Thu Jun 30 13:26:37 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4E921F86D8 for ; Thu, 30 Jun 2011 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhqzUPcE3TBP for ; Thu, 30 Jun 2011 13:26:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6973C21F86D5 for ; Thu, 30 Jun 2011 13:26:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5UKQW8M027849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 22:26:32 +0200 (MEST) From: Martin Rex Message-Id: <201106302026.p5UKQVt6023244@fs4113.wdf.sap.corp> To: eosterweil@verisign.com (Osterweil Eric) Date: Thu, 30 Jun 2011 22:26:31 +0200 (MEST) In-Reply-To: from "Osterweil, Eric" at Jun 30, 11 02:49:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 20:26:37 -0000 Osterweil, Eric wrote: > > > > > I believe the RRSIG validitiy is more in the matter of hours to days. > > It varies, and is set by each zone. Look at this for the current spectrum: > http://secspider.cs.ucla.edu/images/key-lifetimes.png > > > > > And for DNSSEC to work smoothly, there are transistion periods for > > DNS key rollover, so that when correctly rebuilding the to-be-signed > > data from currently valid data (rather than blindly resigning old > > data when RRSIG expires), the problem you are describing might not > > exist. > > > In DNSSEC, yes, rollovers are handled "smoothly", but what keeps the cert in > sync? If a cert exists for (say) a month, but a key rollover happens on > week 1 of the cert's lifetime, then the rollover will have completed long > before someone plans to re-examine and regenerate their cert. Moreover, how > often do people roll their certs now? I ask because the existing behavior > is a much better indicator of future behavior than what one _hopes_ people > will do. Why do you think cert owners will suddenly know how to manage the > cross system dependencies? For use with DANE, you really want your X.509 Validity to be far far far into the future so that it will NEVER happen that you have to replace your certificate because of PKIX-style expiration. If you're using a cert issued by a CA (such as from the TLS X.509 PKI) then the server cert lifetime will be subject to their policies, of course. The purpose of the original validity in X.509 is twofold -- to maintain the commercial CA business model and invoicing for a subscription model (recurring fee or slightly reduced fee upfront for the entire period with no refund for unused time). -- to limit the growth of CRLs and to allow CAs to eventually dispose of their old keys and retire CRL publishing for a CA key. When a server certificate is _not_ from a traditional PKI, but from your own CA or self-signed and distributed through DANE, then you do NOT want any certificate validity to inflict unnecessary administrative overhead. The validity of the certificate is entirely governed by the existence of a signed DANE record refering to that cert. And the cert becomes automaticlly invalid as soon as its DANE record is deleted from the DNS zone and the RRSIG of any existing/published DNS records expire. -Martin From stephen.farrell@cs.tcd.ie Thu Jun 30 13:33:02 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC7D21F877F for ; Thu, 30 Jun 2011 13:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl3+ybZcgX2p for ; Thu, 30 Jun 2011 13:33:01 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2D021F859A for ; Thu, 30 Jun 2011 13:33:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id CBC93171C01; Thu, 30 Jun 2011 21:32:51 +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=1309465971; bh=W3BApzMqacMJ/Y DOnkPU7MlFnelKFHnpxIVHNqY1fdA=; b=57FcandRp91MowvW4AS91XWYFnI6NL kyrIzZ8UvJ4HO8S/2aX/kd3413SQ1jU2RKnuDuQ/9xg62JjvhWdMPVnGrsju/LFQ ibWYqm8bLuLfSiV0sh4t/MI0rJ0xBpVaj1S/hvjJbV3XKf1e24R+5uloaVEw89ge fghXAtvyJk7MV1PRs+BbGlk57M06IRkHGzvzT5uNFlJDbcIk1VPsp44fbVPmlPNl mfGC7WaJHg9sf/hY2TPqX104ayYFOuaEENIJR+YT3CcMrrNrSSL4TfkUQnLoMRyP UjiS/zaENErGDN/3C3xoWPPH9FwYP6onJVvzPJEksTnl9nSJle1VUjlA== 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 eJSibfrs4CaB; Thu, 30 Jun 2011 21:32:51 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.23.8]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A6441171BFE; Thu, 30 Jun 2011 21:32:49 +0100 (IST) Message-ID: <4E0CDD70.8070304@cs.tcd.ie> Date: Thu, 30 Jun 2011 21:32:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: mrex@sap.com References: <201106302026.p5UKQVt6023244@fs4113.wdf.sap.corp> In-Reply-To: <201106302026.p5UKQVt6023244@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 20:33:02 -0000 On 30/06/11 21:26, Martin Rex wrote: > The purpose of the original validity in X.509 is twofold > -- to maintain the commercial CA business model and invoicing > for a subscription model (recurring fee or slightly reduced fee > upfront for the entire period with no refund for unused time). > -- to limit the growth of CRLs and to allow CAs to eventually > dispose of their old keys and retire CRL publishing for a CA key. Not part of the argument on this, but I believe the above is incorrect. X.509 was originally the authentication framework for X.500 intended to allow DUAs to authenticate to directories. For that use-case, an expiry is quite appropriate. Of course notAfter is a PITA in some other cases and has given rise to some parts of a business model. But I don't believe that either of the above reasons were the original intent at all. S. From rbarnes@bbn.com Thu Jun 30 13:47:27 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567FE9E800C for ; Thu, 30 Jun 2011 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gest3P6ENxQX for ; Thu, 30 Jun 2011 13:47:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5DC9E8008 for ; Thu, 30 Jun 2011 13:47:26 -0700 (PDT) Received: from [128.89.254.28] (port=64150 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QcO8w-000I0v-Uh; Thu, 30 Jun 2011 16:47:23 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 30 Jun 2011 16:47:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> References: To: "Osterweil, Eric" X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 20:47:27 -0000 >>> Managing the crypto in just >>> one system is hard enough, this seems to inheret baggage from two >>> crypto-enhanced systems... :-/ >>=20 >> I don't think it's quite that bad. There's not really any PKIX = baggage, since >> the all of the crypto validation comes from the DNSSEC extension. >>=20 >> The risk of falling out of sync may just be part of the trade-off for = speed. >> It seems like there's a plausible solution (mod_dnssec_staple), so it = doesn't >> seem like it necessarily has to be a blocking issue. >=20 > Again, I think the operational complexities are being vastly = underestimated. > The certs have to be regenerated by authorities for websites based on > changes in DNS zones that exist anywhere along the validation chain. = In > particular, how many web server admins keep track of when the root = changes > its ZSKs? I know of the top of my head, but I still would find it a = pain if > I had to go regen certs because someone popped a key somewhere... I = still > don't even know how I would find that out? It's not really so mysterious, it's just the chain from the name in the = cert to the root. If I'm trying to maintain a cert for isoc.org, I have = to monitor 9 records (+RRSIGs) 1. . DNSKEY 2. . DNSKEY=20 3. org DS 4. org DNSKEY 5. org DNSKEY 6. isoc.org DS 7. isoc.org DNSKEY 8. isoc.org DNSKEY 9. isoc.org TLSA So my script polls for these records whenever the TTL expires, and = issues a new cert whenever the chain changes. Seems like a pretty = defined scope, and like I said before, a plausible solution. --Richard= From mrex@sap.com Thu Jun 30 13:53:45 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0448E11E80AA for ; Thu, 30 Jun 2011 13:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr+PLZmygTTF for ; Thu, 30 Jun 2011 13:53:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEE911E80A7 for ; Thu, 30 Jun 2011 13:53:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5UKrehr029765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 22:53:40 +0200 (MEST) From: Martin Rex Message-Id: <201106302053.p5UKrdhJ024832@fs4113.wdf.sap.corp> To: stephen.farrell@cs.tcd.ie (Stephen Farrell) Date: Thu, 30 Jun 2011 22:53:39 +0200 (MEST) In-Reply-To: <4E0CDD70.8070304@cs.tcd.ie> from "Stephen Farrell" at Jun 30, 11 09:32:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 20:53:45 -0000 Stephen Farrell wrote: > > On 30/06/11 21:26, Martin Rex wrote: > > The purpose of the original validity in X.509 is twofold > > -- to maintain the commercial CA business model and invoicing > > for a subscription model (recurring fee or slightly reduced fee > > upfront for the entire period with no refund for unused time). > > -- to limit the growth of CRLs and to allow CAs to eventually > > dispose of their old keys and retire CRL publishing for a CA key. > > Not part of the argument on this, but I believe the above > is incorrect. X.509 was originally the authentication framework > for X.500 intended to allow DUAs to authenticate to directories. > For that use-case, an expiry is quite appropriate. Of course > notAfter is a PITA in some other cases and has given rise to > some parts of a business model. But I don't believe that either > of the above reasons were the original intent at all. I don't know just how badly the original designers wanted this, but certainly these were the obvious characteristics they put into their design. But there seem to be USgov CAs that do not seem to use it to limit CRL growth (or might be using cert lifetimes with revocation policies that appear somewhat imbalanced with respect to processing performance), e.g. http://crl.disa.mil/getcrl?DOD%20CA-19 (22 MBytes, >1million revocations including revocation dates of 2008) If you're being sent S/Mime EMails signed with short-lived certificates, you may realize just how badly CA-imposed short validity impairs the usability of a whole system. The S/Mime signed Emails in my Outlook mail archives that show "signature invalid" (signer cert expired) outnumber those with a valid signature by a factor of 5, and that factor is monotonically increasing. -Martin From rbarnes@bbn.com Thu Jun 30 13:53:47 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366A411E80DF for ; Thu, 30 Jun 2011 13:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l57ayBlfpgth for ; Thu, 30 Jun 2011 13:53:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9117911E80C7 for ; Thu, 30 Jun 2011 13:53:46 -0700 (PDT) Received: from [128.89.254.28] (port=64162 helo=[172.18.184.238]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QcOF8-000I8j-6u for dane@ietf.org; Thu, 30 Jun 2011 16:53:46 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Jun 2011 16:53:45 -0400 Message-Id: <9B52A03C-4F37-49D9-B12B-B485C0740A38@bbn.com> To: "dane@ietf.org WG list" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [dane] DNSViz X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 20:53:47 -0000 Slightly off-topic, but maybe helpful for folks in this group... DNSViz is a handy web tool for visualizing DNSSEC chains: My isoc.org example from my recent email on the DNSSEC stapling thread: From ietf@augustcellars.com Thu Jun 30 14:48:34 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E7321F8576; Thu, 30 Jun 2011 14:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi1qxZjqV79N; Thu, 30 Jun 2011 14:48:34 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31411E807D; Thu, 30 Jun 2011 14:48:34 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id DB0FA6A43B; Thu, 30 Jun 2011 14:48:33 -0700 (PDT) From: "Jim Schaad" To: , References: <20110629175538.13928.91137.idtracker@ietfa.amsl.com> In-Reply-To: <20110629175538.13928.91137.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 15:19:40 -0700 Message-ID: <00b301cc3773$ce49c6d0$6add5470$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFM8OtqIBFYNIGIN51hvegfTVRZ1ZXVBUzQ Content-Language: en-us Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:48:35 -0000 In the combination text re-write a concept was lost. Combination: The DANE mechanism must allow multiple DANE statements of the above forms to be combined. For example, a domain holder should be able to specify that clients should accept a particular certificate (Section Section 3.2) or any certificate issued by its own CA (Section Section 3.3). The 'or' should be an 'and' as you want to be able to specify multiple constraints. The or case would be handled under the roll-over conditions. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, June 29, 2011 10:56 AM > To: i-d-announce@ietf.org > Cc: dane@ietf.org > Subject: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DNS-based Authentication of Named Entities > Working Group of the IETF. > > Title : Use Cases and Requirements for DNS-based > Authentication of Named Entities (DANE) > Author(s) : Richard Barnes > Filename : draft-ietf-dane-use-cases-04.txt > Pages : 12 > Date : 2011-06-29 > > Many current applications use the certificate-based authentication > features in TLS to allow clients to verify that a connected server > properly represents a desired domain name. Traditionally, this > authentication has been based on PKIX trust hierarchies, rooted in > well-known CAs, but additional information can be provided via the > DNS itself. This document describes a set of use cases in which the > DNS and DNSSEC could be used to make assertions that support the TLS > authentication process. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Thu Jun 30 16:13:00 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A065111E8075 for ; Thu, 30 Jun 2011 16:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-tN0vskNPoA for ; Thu, 30 Jun 2011 16:12:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 47399228015 for ; Thu, 30 Jun 2011 16:12:59 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p5UNCvPe009390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2011 01:12:57 +0200 (MEST) From: Martin Rex Message-Id: <201106302312.p5UNCuUp003033@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Fri, 1 Jul 2011 01:12:56 +2600 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jun 30, 11 03:04:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:13:00 -0000 Phillip Hallam-Baker wrote: > > At the longer end I would really, really not like to have people recognizing > such certs as valid for more than existing DV certs are recognized. > > I think that the max validity of such certs should be pinned at a short > value, that is weeks or months. Software that will automatically time-bomb itself with absolutely no need for it seems like a bad idea. To completely avoid any detrimental side effects, simply choose a notafter 30 years into the future is just fine -- but since there is a 32-bit time_t wrap in early January 2038, you might want to be conservative and not use a notafter date beyond Jan 1st, 2038 for a few more years. There is no security value in validity dates of self-signed X.509 server certs distributed through DANE, so including attributes that may break interop for some peers when some administrative procedures are suspended or fail for a short amount of time seems ridiculous. If certificates would be subject to accellerated bit rot impairing their security, then we should worry about the trust anchors in browser much more than about a Web-Server using a home-grown server cert for more than a year. -Martin From hallam@gmail.com Thu Jun 30 16:48:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2458C11E8308 for ; Thu, 30 Jun 2011 16:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTjxJkOASZcA for ; Thu, 30 Jun 2011 16:48:09 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1CF11E8304 for ; Thu, 30 Jun 2011 16:48:09 -0700 (PDT) Received: by yie30 with SMTP id 30so1396362yie.31 for ; Thu, 30 Jun 2011 16:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=irdb2XFhslDivwduwKDzZi+CjwBTwqksxjVJmMXUuVw=; b=l54xXmnnpYlduQ15R6w3qQy/BmtpS3ZNyttxuXNCtrAuJtqth32EkIH3MdKx+D7ahr HGC10ncLuK18w3jI2i7AnVZO6GJJAft/u0St48aQ4+0Gnd23alA3Sg8RUiPzf8/ImWiV NVpR4pjDnL7TWgbt4IM+UC6D/3Tfv/dm+UbQU= MIME-Version: 1.0 Received: by 10.101.186.21 with SMTP id n21mr2406565anp.18.1309477688719; Thu, 30 Jun 2011 16:48:08 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Thu, 30 Jun 2011 16:48:08 -0700 (PDT) In-Reply-To: <201106302053.p5UKrdhJ024832@fs4113.wdf.sap.corp> References: <4E0CDD70.8070304@cs.tcd.ie> <201106302053.p5UKrdhJ024832@fs4113.wdf.sap.corp> Date: Thu, 30 Jun 2011 19:48:08 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636c92ace7a3b8c04a6f68893 Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:48:10 -0000 --001636c92ace7a3b8c04a6f68893 Content-Type: text/plain; charset=ISO-8859-1 My operational experience of PKI is clearly different from Martins. For the purposes of TLS a cert only needs to authenticate the public key used for key exchange. Non repudiation is not a requirement, decryption of stored data is not a requirement, archiving is not a requirement. If we had reliable net time we could set the validity interval at an hour with no ill effects (well except for timing out fast restarts). Since we do have those issues a period of 72 hours is probably optimal. This is a self signed cert. The server creates it using the same key as for the TLS exchange. The RP need not even check the signature. The server does not need to store the cert on disk, it can create a new one each time it starts. In fact it could create a new cert for every connection if it wanted to (can't think of why it would). On Thu, Jun 30, 2011 at 4:53 PM, Martin Rex wrote: > Stephen Farrell wrote: > > > > On 30/06/11 21:26, Martin Rex wrote: > > > The purpose of the original validity in X.509 is twofold > > > -- to maintain the commercial CA business model and invoicing > > > for a subscription model (recurring fee or slightly reduced fee > > > upfront for the entire period with no refund for unused time). > > > -- to limit the growth of CRLs and to allow CAs to eventually > > > dispose of their old keys and retire CRL publishing for a CA key. > > > > Not part of the argument on this, but I believe the above > > is incorrect. X.509 was originally the authentication framework > > for X.500 intended to allow DUAs to authenticate to directories. > > For that use-case, an expiry is quite appropriate. Of course > > notAfter is a PITA in some other cases and has given rise to > > some parts of a business model. But I don't believe that either > > of the above reasons were the original intent at all. > > > I don't know just how badly the original designers wanted this, > but certainly these were the obvious characteristics they put into > their design. > > But there seem to be USgov CAs that do not seem to use it to limit > CRL growth (or might be using cert lifetimes with revocation policies > that appear somewhat imbalanced with respect to processing performance), > e.g. http://crl.disa.mil/getcrl?DOD%20CA-19 > (22 MBytes, >1million revocations including revocation dates of 2008) > > > If you're being sent S/Mime EMails signed with short-lived certificates, > you may realize just how badly CA-imposed short validity impairs > the usability of a whole system. The S/Mime signed Emails in my > Outlook mail archives that show "signature invalid" (signer cert expired) > outnumber those with a valid signature by a factor of 5, and that factor > is monotonically increasing. > > -Martin > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --001636c92ace7a3b8c04a6f68893 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My operational experience of PKI is clearly different from Martins.
For the purposes of TLS a cert only needs to authenticate the p= ublic key used for key exchange. Non repudiation is not a requirement, decr= yption of stored data is not a requirement, archiving is not a requirement.=

If we had reliable net time we could set the validity i= nterval at an hour with no ill effects (well except for timing out fast res= tarts). Since we do have those issues a period of 72 hours is probably opti= mal.


This is a self signed cert. The server c= reates it using the same key as for the TLS exchange. The RP need not even = check the signature.

The server does not need to s= tore the cert on disk, it can create a new one each time it starts. In fact= it could create a new cert for every connection if it wanted to (can't= think of why it would).




On Thu, Jun 30, 2011 at 4:53 PM, Martin Rex <mrex@sap.com> wrote:
Stephen Farrell wrote:
>
> On 30/06/11 21:26, Martin Rex wrote:
> > The purpose of the original validity in X.509 is twofold
> > =A0 -- to maintain the commercial CA business model and invoicing=
> > =A0 for a subscription model (recurring fee or slightly reduced f= ee
> > =A0 upfront for the entire period with no refund for unused time)= .
> > =A0 -- to limit the growth of CRLs and to allow CAs to eventually=
> > =A0 dispose of their old keys and retire CRL publishing for a CA = key.
>
> Not part of the argument on this, but I believe the above
> is incorrect. X.509 was originally the authentication framework
> for X.500 intended to allow DUAs to authenticate to directories.
> For that use-case, an expiry is quite appropriate. Of course
> notAfter is a PITA in some other cases and has given rise to
> some parts of a business model. But I don't believe that either > of the above reasons were the original intent at all.


I don't know just how badly the original designers wanted this, but certainly these were the obvious characteristics they put into
their design.

But there seem to be USgov CAs that do not seem to use it to limit
CRL growth (or might be using cert lifetimes with revocation policies
that appear somewhat imbalanced with respect to processing performance), e.g. h= ttp://crl.disa.mil/getcrl?DOD%20CA-19
(22 MBytes, >1million revocations including revocation dates of 2008)

If you're being sent S/Mime EMails signed with short-lived certificates= ,
you may realize just how badly CA-imposed short validity impairs
the usability of a whole system. =A0The S/Mime signed Emails in my
Outlook mail archives that show "signature invalid" (signer cert = expired)
outnumber those with a valid signature by a factor of 5, and that factor is monotonically increasing.

-Martin
__________________________________= _____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--001636c92ace7a3b8c04a6f68893-- From marka@isc.org Thu Jun 30 16:57:59 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03A711E809C for ; Thu, 30 Jun 2011 16:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GV8ZytfzRkDi for ; Thu, 30 Jun 2011 16:57:59 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D30F211E808E for ; Thu, 30 Jun 2011 16:57:58 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id F2B175F98EA; Thu, 30 Jun 2011 23:57:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9DC44216C7B; Thu, 30 Jun 2011 23:57:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8A6FC115363A; Fri, 1 Jul 2011 09:57:34 +1000 (EST) To: "Richard L. Barnes" From: Mark Andrews References: <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> In-reply-to: Your message of "Thu, 30 Jun 2011 16:47:20 -0400." <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com> Date: Fri, 01 Jul 2011 09:57:34 +1000 Message-Id: <20110630235734.8A6FC115363A@drugs.dv.isc.org> Cc: Adam Langley , dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 23:58:00 -0000 In message <2F57E71D-5F04-4094-8E37-F0D7C8E33111@bbn.com>, "Richard L. Barnes" writes: > >>> Managing the crypto in just > >>> one system is hard enough, this seems to inheret baggage from two > >>> crypto-enhanced systems... :-/ > >> > >> I don't think it's quite that bad. There's not really any PKIX baggage, s > ince > >> the all of the crypto validation comes from the DNSSEC extension. > >> > >> The risk of falling out of sync may just be part of the trade-off for spee > d. > >> It seems like there's a plausible solution (mod_dnssec_staple), so it does > n't > >> seem like it necessarily has to be a blocking issue. > > > > Again, I think the operational complexities are being vastly underestimated > . > > The certs have to be regenerated by authorities for websites based on > > changes in DNS zones that exist anywhere along the validation chain. In > > particular, how many web server admins keep track of when the root changes > > its ZSKs? I know of the top of my head, but I still would find it a pain i > f > > I had to go regen certs because someone popped a key somewhere... I still > > don't even know how I would find that out? > > It's not really so mysterious, it's just the chain from the name in the cert > to the root. If I'm trying to maintain a cert for isoc.org, I have to monito > r 9 records (+RRSIGs) 6 RRsets + RRSIGs > 1. . DNSKEY > 2. . DNSKEY RRSIG (15 days validity) > 3. org DS > 3. org DS RRSIG (5 days validity) > 4. org DNSKEY > 5. org DNSKEY RRSIG (20 days validity) > 6. isoc.org DS > 6. isoc.org DS RRSIG (20 days validity) > 7. isoc.org DNSKEY > 8. isoc.org DNSKEY RRSIG (14 days validity) > 9. isoc.org TLSA > 9. isoc.org TLSA (30 days validity) > > So my script polls for these records whenever the TTL expires, and issues a n > ew cert whenever the chain changes. Seems like a pretty defined scope, and l > ike I said before, a plausible solution. Now having the server maintain a DNS TTL controlled cache of the records required to validate the TLSA and returning those wouldn't break anything the DNS zone operators are depending apon. This doesn't have to be in the CERT. You can tentitively trust the CERT, then request the DNS validation chain, then decide whether you full trust the CERT. The only thing the CERT needs is a indication that the server supports requesting the DNS validation chain. Even if the returned validation chain is incomplete the client can request the missing bits. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Thu Jun 30 18:14:09 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970DB11E80DA for ; Thu, 30 Jun 2011 18:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVW2Da4bDY4E for ; Thu, 30 Jun 2011 18:14:08 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC911E80DB for ; Thu, 30 Jun 2011 18:14:07 -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 [91.125.158.24] (port=53564 helo=[192.168.0.3]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1QcSJ3-0005aj-Y1 (Exim 4.72) (return-path ); Fri, 01 Jul 2011 02:14:05 +0100 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0278EF9B-E52F-4D76-94AB-0B382AE51441@dotat.at> X-Mailer: iPhone Mail (8F190) From: Tony Finch Date: Fri, 1 Jul 2011 02:14:01 +0100 To: "Osterweil, Eric" Sender: Tony Finch Cc: Adam Langley , "" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 01:14:09 -0000 On 30 Jun 2011, at 20:57, "Osterweil, Eric" wrote:= > In particular, how many web server admins keep track of when the root chan= ges its ZSKs? I know of the top of my head, but I still would find it a pai= n if I had to go regen certs because someone popped a key somewhere...=20 No no no. Key lifetimes are not a problem. They are measured in years. You n= eed to care about signature lifetimes which are measured in days. A web server SSL cert with an embedded DNSSEC trust chain needs to be regene= rated daily at least. Tony. -- f.anthony.n.finch http://dotat.at/= From hallam@gmail.com Thu Jun 30 18:49:29 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8E11E8215 for ; Thu, 30 Jun 2011 18:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Gln8HQ+cbz for ; Thu, 30 Jun 2011 18:49:28 -0700 (PDT) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id A72E911E810B for ; Thu, 30 Jun 2011 18:49:28 -0700 (PDT) Received: by gwb15 with SMTP id 15so1751459gwb.27 for ; Thu, 30 Jun 2011 18:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NicicIhhh0rxqA2l2XxPBmQysg/N8ydljVDky9pi26w=; b=nAE79tTmFsXYF8euhJPeWiM2Tc8g7a92TinHNXjlLbje/5bUcnEyDDwfrHREaiPsg7 ANmPLw0l68J9HdulGTdDtyiMQ/CJ38zrlOhxU1hpcPdikoyeQXgmesHMu/wxieN5AdFL +6sqAJT+j8mKHOi6+kA0GKFPv3wzmdxMsmLjE= MIME-Version: 1.0 Received: by 10.101.149.32 with SMTP id b32mr2446093ano.150.1309484968087; Thu, 30 Jun 2011 18:49:28 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Thu, 30 Jun 2011 18:49:27 -0700 (PDT) In-Reply-To: <0278EF9B-E52F-4D76-94AB-0B382AE51441@dotat.at> References: <0278EF9B-E52F-4D76-94AB-0B382AE51441@dotat.at> Date: Thu, 30 Jun 2011 21:49:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=0016e68dcedd5c926104a6f83a3e Cc: Adam Langley , "" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 01:49:29 -0000 --0016e68dcedd5c926104a6f83a3e Content-Type: text/plain; charset=ISO-8859-1 Exactly, And moreover there are two cases where it is easy to automate a process reliably, one is when the event happens exactly once and the other is when it happens every day. Refreshing certs after a year is hard. If someone breaks the update scheme it may be 11 months before you find out and by then you don't know who broke it. Doing it every day is a perl script. If it is broken you will know soon enough to fix it. On Thu, Jun 30, 2011 at 9:14 PM, Tony Finch wrote: > On 30 Jun 2011, at 20:57, "Osterweil, Eric" > wrote: > > In particular, how many web server admins keep track of when the root > changes its ZSKs? I know of the top of my head, but I still would find it a > pain if I had to go regen certs because someone popped a key somewhere... > > No no no. Key lifetimes are not a problem. They are measured in years. You > need to care about signature lifetimes which are measured in days. > > A web server SSL cert with an embedded DNSSEC trust chain needs to be > regenerated daily at least. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/ --0016e68dcedd5c926104a6f83a3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Exactly,

And moreover there are two cases where it is ea= sy to automate a process reliably, one is when the event happens exactly on= ce and the other is when it happens every day.

Refreshing certs after a year is hard. If someone breaks the update scheme = it may be 11 months before you find out and by then you don't know who = broke it.

Doing it every day is a perl script. If = it is broken you will know soon enough to fix it.


On Thu, Jun 30, 2011 at 9:14 PM, To= ny Finch <dot@dotat.at= > wrote:
On 30 Jun 2011, at 20:57, "Osterweil, Eric" <= ;eosterweil@verisign.com>= wrote:
> In particular, how many web server admins keep track of when the root = changes its ZSKs? =A0I know of the top of my head, but I still would find i= t a pain if I had to go regen certs because someone popped a key somewhere.= ..

No no no. Key lifetimes are not a problem. They are measured in years= . You need to care about signature lifetimes which are measured in days.
A web server SSL cert with an embedded DNSSEC trust chain needs to be regen= erated daily at least.

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/
___________________________________= ____________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



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

--0016e68dcedd5c926104a6f83a3e-- From rbarnes@bbn.com Thu Jun 30 20:27:25 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37F21F0C4F; Thu, 30 Jun 2011 20:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be-v2rkvpN8H; Thu, 30 Jun 2011 20:27:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 723201F0C4B; Thu, 30 Jun 2011 20:27:24 -0700 (PDT) Received: from [128.89.253.190] (port=64741 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QcUO3-000NGg-B9; Thu, 30 Jun 2011 23:27:23 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <00b301cc3773$ce49c6d0$6add5470$@augustcellars.com> Date: Thu, 30 Jun 2011 23:27:20 -0400 Content-Transfer-Encoding: 7bit Message-Id: <7A4391C5-4ED3-4E9F-82C7-82A5BFEB2F12@bbn.com> References: <20110629175538.13928.91137.idtracker@ietfa.amsl.com> <00b301cc3773$ce49c6d0$6add5470$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1082) Cc: dane@ietf.org, internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 03:27:25 -0000 Thanks, I've flagged this to handle with IETF LC comments. --Richard On Jun 30, 2011, at 6:19 PM, Jim Schaad wrote: > In the combination text re-write a concept was lost. > > Combination: The DANE mechanism must allow multiple DANE statements > of the above forms to be combined. For example, a domain holder > should be able to specify that clients should accept a particular > certificate (Section Section 3.2) or any certificate issued by its > own CA (Section Section 3.3). > > The 'or' should be an 'and' as you want to be able to specify multiple > constraints. The or case would be handled under the roll-over conditions. > > Jim > > >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 29, 2011 10:56 AM >> To: i-d-announce@ietf.org >> Cc: dane@ietf.org >> Subject: [dane] I-D Action: draft-ietf-dane-use-cases-04.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the DNS-based Authentication of Named > Entities >> Working Group of the IETF. >> >> Title : Use Cases and Requirements for DNS-based >> Authentication of Named Entities (DANE) >> Author(s) : Richard Barnes >> Filename : draft-ietf-dane-use-cases-04.txt >> Pages : 12 >> Date : 2011-06-29 >> >> Many current applications use the certificate-based authentication >> features in TLS to allow clients to verify that a connected server >> properly represents a desired domain name. Traditionally, this >> authentication has been based on PKIX trust hierarchies, rooted in >> well-known CAs, but additional information can be provided via the >> DNS itself. This document describes a set of use cases in which the >> DNS and DNSSEC could be used to make assertions that support the TLS >> authentication process. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-use-cases-04.txt >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Thu Jun 30 20:34:57 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13031F0C53 for ; Thu, 30 Jun 2011 20:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIFykts4ANVG for ; Thu, 30 Jun 2011 20:34:57 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECE61F0C4B for ; Thu, 30 Jun 2011 20:34:57 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p613YtkM024144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 1 Jul 2011 05:34:55 +0200 (MEST) From: Martin Rex Message-Id: <201107010334.p613YsXr018109@fs4113.wdf.sap.corp> Orig-To: hallam@gmail.com (Phillip Hallam-Baker) To: dane@ietf.org Date: Fri, 1 Jul 2011 05:33:33 +0200 (MEST) In-Reply-To: from "Phillip Hallam-Baker" at Jun 30, 11 09:49:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-SAP: out Cc: agl@imperialviolet.org, dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 03:34:58 -0000 Phillip Hallam-Baker wrote: > > And moreover there are two cases where it is easy to automate a process > reliably, one is when the event happens exactly once and the other is when > it happens every day. > > Refreshing certs after a year is hard. If someone breaks the update scheme > it may be 11 months before you find out and by then you don't know who broke > it. Remembering a non-trivial, non-intuitive administrative procedure that you do only once a year one year later, that is hard. (like remembering a complex unique password that you set a year ago and never used since). Software can be designed to automatically give you prior notice with sufficient time left, which specific recurring administrative procedure(s) will need to be done and when. > > Doing it every day is a perl script. If it is broken you will know soon > enough to fix it. I would normally set up "refresh" in a fashion that it is tried at least 3 times well within the validity period and that I'm notified about the result, and even if I didn't manage to react on two failure notifications (vacation, swamped with work, sickness), the machine would still be running. > > Tony Finch wrote: > > > > A web server SSL cert with an embedded DNSSEC trust chain needs to be > > regenerated daily at least. Daily sounds quite extreme. What RRSIG lifetimes do you have in mind? And wouldn't you have to distribute the matching DANE/TLSA record before you could start using that cert on your server (wouldn't others that have previous replies with unexpired RRSIGs cached not request and therefore not see the new record and not be able to verify the new server cert?) I'm wondering: is it common for today's web-servers to support in-flight replacement of the server certificate. (if your web-server offers streaming or downloads of huge files, will a server cert update adversely affect currently active tls sessions?) -Martin From internet-drafts@ietf.org Thu Jun 30 23:21:40 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A275B228018; Thu, 30 Jun 2011 23:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAVtWyfFtNPg; Thu, 30 Jun 2011 23:21:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D3F228006; Thu, 30 Jun 2011 23:21:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701062140.11148.91165.idtracker@ietfa.amsl.com> Date: Thu, 30 Jun 2011 23:21:40 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 06:21:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain N= ames For TLS Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-08.txt Pages : 15 Date : 2011-06-30 TLS and DTLS use PKIX 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. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-08.txt From jakob@kirei.se Thu Jun 30 23:25:26 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAAB228033 for ; Thu, 30 Jun 2011 23:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7mqnJu+ATGn for ; Thu, 30 Jun 2011 23:25:25 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F328228023 for ; Thu, 30 Jun 2011 23:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=R6TBpycsX50l3agLv0c1vTxhxqKXYuYiIfW7a7mFASY=; b=qCbC0WJAV5PdkJKK1BBSkUn8ZD0gqSqCPsdOU6zgHR37AFT/NS68E0Ji9zhBoucVrix0Pt/x2KUs7 9LvLYz1AK7ATdigj/G8LsePJeTY11HYfcrZjJ5qqUZqboTvZ/xzH/OJfeNyj8eWYkcAuJLF5OVFplW 2B6Z8IOUd11NlgE0= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Fri, 1 Jul 2011 08:25:20 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Jakob Schlyter In-Reply-To: <20110701062140.11148.91165.idtracker@ietfa.amsl.com> Date: Fri, 1 Jul 2011 08:25:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110701062140.11148.91165.idtracker@ietfa.amsl.com> To: dane X-Mailer: Apple Mail (2.1084) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 06:25:27 -0000 Following the updated use cases draft, we have now posted a new version = of draft-ietf-dane-protocol. The update includes, among a number of minor editorial changes, removal = of optional DNSSEC and an update use case mapping section. Jakob & Paul From rickardb@certezza.net Thu Jun 30 23:31:44 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21F921F880B for ; Thu, 30 Jun 2011 23:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlHbzZIO6X6s for ; Thu, 30 Jun 2011 23:31:40 -0700 (PDT) Received: from mx2.certezza.net (mx2.certezza.net [82.99.51.26]) by ietfa.amsl.com (Postfix) with ESMTP id D58B321F85C5 for ; Thu, 30 Jun 2011 23:31:39 -0700 (PDT) From: Rickard Bellgrim To: Adam Langley Date: Fri, 1 Jul 2011 08:31:37 +0200 Thread-Topic: [dane] Draft for serializing DNSSEC chains Thread-Index: Acw2TtESd68nrNmCTa61btVRDq5T9ABaPgFQ Message-ID: <7ADA424A25710B41B7C8201DA111AF190882236E9B@mail01.certezza.local> References: <7ADA424A25710B41B7C8201DA111AF190882236CA1@mail01.certezza.local> In-Reply-To: Accept-Language: sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Received-SPF: none Cc: "dane@ietf.org" Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 06:31:44 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhbGFuZ2xleUBnbWFpbC5jb20g W21haWx0bzphbGFuZ2xleUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBBZGFtDQo+IExhbmdsZXkN Cj4gU2VudDogZGVuIDI5IGp1bmkgMjAxMSAxMzoyMg0KPiBUbzogUmlja2FyZCBCZWxsZ3JpbQ0K PiBDYzogZGFuZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RhbmVdIERyYWZ0IGZvciBzZXJp YWxpemluZyBETlNTRUMgY2hhaW5zDQo+IA0KPiBPbiBXZWQsIEp1biAyOSwgMjAxMSBhdCAyOjE5 IEFNLCBSaWNrYXJkIEJlbGxncmltIDxyaWNrYXJkYkBjZXJ0ZXp6YS5uZXQ+DQo+IHdyb3RlOg0K PiA+IElzbid0IHRoZSBpbml0aWFsX2tleV90YWcgYSBsaXR0bGUgYml0IHdlYWsgYXMgYSB0cnVz dCBhbmNob3I/IFlvdSBjb3VsZCBlYXNpbHkNCj4gZ2V0IGEgY29sbGlzaW9uIGhlcmUuIFBlcmhh cHMgdXNpbmcgdGhlIERTIGFzIGluaXRpYWxfZHMgaW5zdGVhZCBvZg0KPiBpbml0aWFsX2tleV90 YWc/DQo+IA0KPiBJdCdzIG9ubHkgdXNlZCBpbiB0aGUgc2FtZSB3YXkgYXMgaW4gRE5TU0VDOiBh biBvcHRpbWlzYXRpb24uIElmIHlvdSBoYXZlDQo+IG11bHRpcGxlIGtleXMgd2l0aCB0aGUgc2Ft ZSBrZXkgdGFnIHRoZW4geW91IGhhdmUgdG8gdHJ5IGFsbCBvZiB0aGVtLg0KDQpXaGF0IEkgbWVh bnQgd2FzIHRoYXQgaXQgaXMgZWFzeSB0byBzcG9vZiB0aGUgcm9vdCBrZXkgYmVjYXVzZSB5b3Ug YXJlIHVzaW5nIHRoZSBrZXkgdGFnIGFzIHRoZSB0cnVzdCBhbmNob3IuIE9yIHNob3VsZCB5b3Ug dXNlIGEgc2VjdXJlIHJlc29sdmVyIGluIGZyb250IG9mIHRoaXMgYXBwbGljYXRpb24/DQoNCi8v IFJpY2thcmQNCg0K From ondrej.sury@nic.cz Thu Jun 30 23:59:10 2011 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D232C11E80B8; Thu, 30 Jun 2011 23:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL+tUvGrCJIB; Thu, 30 Jun 2011 23:59:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 747F911E80C8; Thu, 30 Jun 2011 23:59: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 A1C962A2C1D; Fri, 1 Jul 2011 08:59:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1309503546; bh=WEG7pZivEx1otHgvTLgL49eizpPp/KFjkFPOkOCoYOs=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=ld48qVdL8WYANrQZPOMgRF6kt51mOtk0pr/CWvMohkk4IB8wwNnqXk5smyP3q07q5 Bzg1ikr+/vhgRu+rZI3lCBQ5qQETVc01PayzLgZFxMBZ5QDXd8h2d4l2gDmYeHAIxc rNWp8a5SI0LmBiWSrhk+ORNZv2F5Ay9iOGfnjjFI= Message-ID: <4E0D703A.3070009@nic.cz> Date: Fri, 01 Jul 2011 08:59:06 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell , iesg-secretary@ietf.org, dane@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Publication request for draft-ietf-dane-use-cases X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 06:59:11 -0000 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Ondřej Surý is the Document Shepherd. I have personally reviewed the document and I believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by both key DANE WG participants and also by members of DNS and PKIX communities. There is no concern about the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The Document Shepherd doesn't have any concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. Responsible Area Director and the IESG should be aware of that some WG members has expressed concern about a use case where the future-to-be DANE protocol can be used without DNSSEC, e.g. use DNS responses which has not been signed and/or validated by DNSSEC. However there was a rough consensus in the WG that it's OK for the use cases document to describe the security implications of not using DNSSEC, leaving the final decision on support for the protocol document. The WG chairs and the document author supports this view reached by rough consensus. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a strong consensus on this document by the active WG members with notable exception as outlined in (1.d) where only rough consensus was reached. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The document has been reviewed manually against ID Checklist Revision 1.9 and automatically with idnits 2.12.12. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document splits the references. There is no downward reference in the normative reference. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes. IANA consideration section exists in the document, but no action is required. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains no formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The DANE WG has been asked at the IETF80 meeting in Prague to write the use cases document before it continue the work on the DANE protocol draft. The draft has been discussed in the DANE WG mailing list and has a strong consensus in the WG for publication as an informational RFC with notable exception of controversy about allowing to use DNS responses not validated by DNSSEC in one of the use cases. The rough consensus is that this is still a valid use case and the issue will be addressed and resolved in the DANE protocol draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document was reviewed by various people and has been through WGLC successfully. -- 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 -------------------------------------------