From stephen.farrell@cs.tcd.ie Wed Feb 1 04:21:27 2012 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 CB2DF21F86DD for ; Wed, 1 Feb 2012 04:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNKEpH7IW5LR for ; Wed, 1 Feb 2012 04:21:27 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BF04521F86DB for ; Wed, 1 Feb 2012 04:21:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B987B153C71 for ; Wed, 1 Feb 2012 12:21:25 +0000 (GMT) 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=1328098885; bh=JD080sijHzuKw4 TBbAtMkcJ0dyCi5IAfrwJgJo0Hr7U=; b=LdVX6BiBgePTY5N1Fnza0a80zRufWf sWkYndUSwlM/0wBos6YiIM00nfbds6BYIa1DOJ1uNhPrQ6IQhH3rKDPHJXATFxwu XyJxo8QfRm+wIz2dPUnm7TRrvZAN13p+djEQFb2cZ9JC5uigbudfWQORSsw0ig4E z+XyrKsy4fMmVVyYdiJUIMgkYnOTsuPw8lmqJ5LitbYkpKs1Hv0yCNGN+/Y6CuZA rgF2EGgT/niQTjqo+WQNpU44LQ+NStN7f8QBVJk6uXoVWGYxSfqNDec73pyaT6Ia qX8IfGg02pIkibqUHNF86e+wpru+FQSSHf/FryLlDcXjG4OWR5ow1ltw== 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 yJtmkz5NTngH for ; Wed, 1 Feb 2012 12:21:25 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 65D75171C07 for ; Wed, 1 Feb 2012 12:21:25 +0000 (GMT) Message-ID: <4F292E46.7040602@cs.tcd.ie> Date: Wed, 01 Feb 2012 12:21:26 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> <30325390-DC25-427D-926C-E990A37C21D1@nic.cz> In-Reply-To: <30325390-DC25-427D-926C-E990A37C21D1@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] simple key management (was: issue #37 I think) 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 Feb 2012 12:21:28 -0000 Hi all, Here's my take on what I think this topic is about. If folks are unhappy with details of 5280 then the place to deal with that is in PKIX. If you're radically unhappy with PKIX, then we have a list for discussing possible new approaches (therightkey@ietf.org) so go there. Neither of the above are really appropriate for long discussions on the DANE list. (And since there never seems to be a *short* discussion on the DANE list, I guess that means that they're just not appropriate:-) Meanwhile, we have 5280 and its the standard way to handle x.509-based PKI in IETF protocols. So when a DANE client is doing PKIX/5280 then that's what they should do. Whether or not existing implementations do that well or badly is also not a topic for DANE. When a DANE client is not using any CA then 5280 is not very relevant, except for defining a container format for public keys. It seems to me that -14 does support this (as called for in 6394) but that that could be made a good bit clearer. In particular I reckon that the protocol doc should make it more clear that if 2,0,0,V is the value in the TLSA RR and C is the server cert provided in the TLS handshake, and if V==C and the TLSA record ValState is SECURE, then Finish(2) is the right result. (And similarly for selector==1 and matching rules 1 and 2, with appropriate changes.) I also think that -14 section 5 is wrong in how it describes how we meet the "simple key management" requirement from 6394 - IMO it ought say that you meet this requirement by supporting the mode of operation in the paragraph I've just written above. In terms of making the above clearer in the protocol draft, one way (not the only possible way) I'd suggest is to say that "PKIX validation" does mean 5280 section 6 (or however you want to say that) but also say that in implementing usage 2, you can do anything that's equivalent to first doing the test described above and then following that with PKIX validation with the same inputs if the test above doesn't result in Finish(2). There are probably a few other language tweaks that would flow from that but I'd say those should be easy enough. Note that the above is not based on re-reading all the recent mail on the list, but from reading -14 and 6394 and the bits of the list discussion that I managed to remember in my little head:-) So its possible someone already said this and got shot down for one reason or another. I'm fine with arguing the point if that's the case. Cheers, S. From paul.hoffman@vpnc.org Wed Feb 1 12:12:03 2012 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 6EF7E21F879B for ; Wed, 1 Feb 2012 12:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDwB3fdgp0NM for ; Wed, 1 Feb 2012 12:12:02 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9579721F86E2 for ; Wed, 1 Feb 2012 12:12:02 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q11KBt1P036974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Feb 2012 13:11:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F292E46.7040602@cs.tcd.ie> Date: Wed, 1 Feb 2012 12:11:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> <30325390-DC25-427D-926C-E990A37C21D1@nic.cz> <4F292E46.7040602@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: dane Subject: Re: [dane] simple key management (was: issue #37 I think) 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 Feb 2012 20:12:03 -0000 On Feb 1, 2012, at 4:21 AM, Stephen Farrell wrote: > When a DANE client is not using any CA then 5280 is not > very relevant, except for defining a container format > for public keys. It seems to me that -14 does support > this (as called for in 6394) but that that could be > made a good bit clearer. It is *meant* to support it, but it became clear that some people think = it does not. > In particular I reckon that the protocol doc should > make it more clear that if 2,0,0,V is the value in > the TLSA RR and C is the server cert provided in the > TLS handshake, and if V=3D=3DC and the TLSA record > ValState is SECURE, then Finish(2) is the right > result. That makes good sense. However... > (And similarly for selector=3D=3D1 and matching > rules 1 and 2, with appropriate changes.) It is in these details that some people have strong objections, so I = would like to tease them apart. For selector =3D 1 (SPKI instead of full cert), there is an argument = that most/all PKIX libraries do not let you ask "what is the SPKI of = this cert", so it would not make sense for a site to hope that a client = could do this. Matching rules 1 and 2 (hashes instead of full content) should be fine = if done on the full cert. With that, would you find it acceptable to say that usage type 2 MUST be = used with selector type 1? As for the definition, we could say "The target certificate either MUST = match the one in the TLSA record, or MUST pass PKIX validation with any = certificate matching the TLSA record considered to be a trust anchor for = this validation". Alternately, one that is different than what we have = specified for most of the time but is probably what most people want, is = simply "The target certificate either MUST match the one in the TLSA = record" and not have a way for DANE to give a new trust anchor. The = second alternative is like type 1 but with no expectation that the cert = chains to a trust anchor for the client. Thoughts? --Paul Hoffman From paul.hoffman@vpnc.org Wed Feb 1 12:26:15 2012 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 A528F11E80BA for ; Wed, 1 Feb 2012 12:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8w4T4wX86KW for ; Wed, 1 Feb 2012 12:26:15 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE0411E8094 for ; Wed, 1 Feb 2012 12:26:15 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q11KQBK1039657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 1 Feb 2012 13:26:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 1 Feb 2012 12:26:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB38115-E045-405C-8ABC-F5C105132D19@vpnc.org> References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> <30325390-DC25-427D-926C-E990A37C21D1@nic.cz> <4F292E46.7040602@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: dane WG list Subject: Re: [dane] simple key management (was: issue #37 I think) 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 Feb 2012 20:26:15 -0000 On Feb 1, 2012, at 12:11 PM, Paul Hoffman wrote: > On Feb 1, 2012, at 4:21 AM, Stephen Farrell wrote: >=20 >> When a DANE client is not using any CA then 5280 is not >> very relevant, except for defining a container format >> for public keys. It seems to me that -14 does support >> this (as called for in 6394) but that that could be >> made a good bit clearer. >=20 > It is *meant* to support it, but it became clear that some people = think it does not. >=20 >> In particular I reckon that the protocol doc should >> make it more clear that if 2,0,0,V is the value in >> the TLSA RR and C is the server cert provided in the >> TLS handshake, and if V=3D=3DC and the TLSA record >> ValState is SECURE, then Finish(2) is the right >> result. >=20 > That makes good sense. However... >=20 >> (And similarly for selector=3D=3D1 and matching >> rules 1 and 2, with appropriate changes.) >=20 > It is in these details that some people have strong objections, so I = would like to tease them apart. >=20 > For selector =3D 1 (SPKI instead of full cert), there is an argument = that most/all PKIX libraries do not let you ask "what is the SPKI of = this cert", so it would not make sense for a site to hope that a client = could do this. >=20 > Matching rules 1 and 2 (hashes instead of full content) should be fine = if done on the full cert. >=20 > With that, would you find it acceptable to say that usage type 2 MUST = be used with selector type 1? Sorry, MUST be used with selector type 0. >=20 > As for the definition, we could say "The target certificate either = MUST match the one in the TLSA record, or MUST pass PKIX validation with = any certificate matching the TLSA record considered to be a trust anchor = for this validation". Alternately, one that is different than what we = have specified for most of the time but is probably what most people = want, is simply "The target certificate either MUST match the one in the = TLSA record" and not have a way for DANE to give a new trust anchor. The = second alternative is like type 1 but with no expectation that the cert = chains to a trust anchor for the client. >=20 > Thoughts? --Paul Hoffman From stephen.farrell@cs.tcd.ie Wed Feb 1 14:45:57 2012 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 5BEA511E80A1 for ; Wed, 1 Feb 2012 14:45:57 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IETdcfXAb32Q for ; Wed, 1 Feb 2012 14:45:56 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F611E809F for ; Wed, 1 Feb 2012 14:45:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A0AB9171C30; Wed, 1 Feb 2012 22:45:51 +0000 (GMT) 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=1328136351; bh=CRrWoihbDOE28n zMPcTJhBaNz8rJzP+BtUQD4zNSIB4=; b=q697G9PqODjg22jNdbeeNwUVHb7GD0 Ovl508cn6EdxciN8TUJvC9oD9HHOWb1/eOIsuXAacqqdeQNN9oy14Imc9yHGlevB tsAowzo3IObMb6Q5O4b6EkbOzkhfqarKEuMX1evTXlCl0YO803opHb9WOxJNRgcq ChDwPTPiZun/wQLGZekXaVRM4AsO4WooouDFTZ3aCcuJ6g2GowBQm/jpCdjMhaEH kFJ8wL6xF0WRjEH7Rrj+QpDcCVdB1guXR1tofWeGhEN8ezyWOSqHtrN49fTuG5ce wlUCQknWZIa1Nk3V9lPEo96dRcgiSX4ZmEODC5j5Gq/JeHNGj3lafngQ== 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 iDRLIboJeosn; Wed, 1 Feb 2012 22:45:51 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.42.24.255]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F37B9171C07; Wed, 1 Feb 2012 22:45:50 +0000 (GMT) Message-ID: <4F29C09D.1000507@cs.tcd.ie> Date: Wed, 01 Feb 2012 22:45:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <20120123033124.GD14597@odin.ulthar.us> <201201231921.q0NJLS1i021543@fs4113.wdf.sap.corp> <7769AE22-B0EF-48F2-86E8-AD6977F83124@vpnc.org> <3F134138-06A0-400A-9CA6-5FF55B331D04@vpnc.org> <30325390-DC25-427D-926C-E990A37C21D1@nic.cz> <4F292E46.7040602@cs.tcd.ie> <5AB38115-E045-405C-8ABC-F5C105132D19@vpnc.org> In-Reply-To: <5AB38115-E045-405C-8ABC-F5C105132D19@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane WG list Subject: Re: [dane] simple key management 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 Feb 2012 22:45:57 -0000 Hi Paul, On 02/01/2012 08:26 PM, Paul Hoffman wrote: > On Feb 1, 2012, at 12:11 PM, Paul Hoffman wrote: > >> On Feb 1, 2012, at 4:21 AM, Stephen Farrell wrote: >> >> >>> In particular I reckon that the protocol doc should >>> make it more clear that if 2,0,0,V is the value in >>> the TLSA RR and C is the server cert provided in the >>> TLS handshake, and if V==C and the TLSA record >>> ValState is SECURE, then Finish(2) is the right >>> result. >> >> That makes good sense. However... >> >>> (And similarly for selector==1 and matching >>> rules 1 and 2, with appropriate changes.) >> >> It is in these details that some people have strong objections, so I would like to tease them apart. >> >> For selector = 1 (SPKI instead of full cert), there is an argument that most/all PKIX libraries do not let you ask "what is the SPKI of this cert", so it would not make sense for a site to hope that a client could do this. Teasing it out sounds good. Hmmm. I don't feel strongly about this but I don't see why that needs to be the case nor why things might not change if useful. I'm not so sure we should drive this based on current APIs offered by libraries. And its not like its hard to pull an SPKI out of an encoded cert. What's really wrong with 2,1,[x],V in a TLSA RR? Has anyone written the client code for that? Ta, S. >> Matching rules 1 and 2 (hashes instead of full content) should be fine if done on the full cert. >> >> With that, would you find it acceptable to say that usage type 2 MUST be used with selector type 1? > > Sorry, MUST be used with selector type 0. >> As for the definition, we could say "The target certificate either MUST match the one in the TLSA record, or MUST pass PKIX validation with any certificate matching the TLSA record considered to be a trust anchor for this validation". Alternately, one that is different than what we have specified for most of the time but is probably what most people want, is simply "The target certificate either MUST match the one in the TLSA record" and not have a way for DANE to give a new trust anchor. The second alternative is like type 1 but with no expectation that the cert chains to a trust anchor for the client. >> >> Thoughts? > > --Paul Hoffman > > From i.grok@comcast.net Wed Feb 1 22:00:50 2012 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 2525621F8996 for ; Wed, 1 Feb 2012 22:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.124 X-Spam-Level: X-Spam-Status: No, score=-102.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+VpSvtpr9Zu for ; Wed, 1 Feb 2012 22:00:49 -0800 (PST) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32C21F8993 for ; Wed, 1 Feb 2012 22:00:49 -0800 (PST) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Uu071i0010cQ2SLA8u0o1k; Thu, 02 Feb 2012 06:00:48 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta10.emeryville.ca.mail.comcast.net with comcast id Uu0n1i00N00PQ6U8Wu0nzR; Thu, 02 Feb 2012 06:00:48 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q1260i98021386 for ; Thu, 2 Feb 2012 01:00:44 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q1260iDB021385 for dane@ietf.org; Thu, 2 Feb 2012 01:00:44 -0500 Date: Thu, 2 Feb 2012 01:00:44 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120202060044.GA20352@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <30325390-DC25-427D-926C-E990A37C21D1@nic.cz> <4F292E46.7040602@cs.tcd.ie> <5AB38115-E045-405C-8ABC-F5C105132D19@vpnc.org> <4F29C09D.1000507@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <4F29C09D.1000507@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] simple key management 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 Feb 2012 06:00:50 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 01, 2012 at 10:45:49PM +0000, Stephen Farrell wrote: > On 02/01/2012 08:26 PM, Paul Hoffman wrote: > >On Feb 1, 2012, at 12:11 PM, Paul Hoffman wrote: > >>On Feb 1, 2012, at 4:21 AM, Stephen Farrell wrote: > >>>In particular I reckon that the protocol doc should make it more > >>>clear that if 2,0,0,V is the value in the TLSA RR and C is the > >>>server cert provided in the TLS handshake, and if V=3D=3DC and the TLSA > >>>record ValState is SECURE, then Finish(2) is the right result. > >> > >>That makes good sense. However... > >> > >>>(And similarly for selector=3D=3D1 and matching rules 1 and 2, with > >>>appropriate changes.) > >> > >>It is in these details that some people have strong objections, so I > >>would like to tease them apart. I haven't seen a lot of strong objection? > >>For selector =3D 1 (SPKI instead of full cert), there is an argument > >>that most/all PKIX libraries do not let you ask "what is the SPKI of > >>this cert", so it would not make sense for a site to hope that a > >>client could do this. >=20 > Teasing it out sounds good. >=20 > Hmmm. I don't feel strongly about this but I don't see why that needs > to be the case nor why things might not change if useful. I'm not so > sure we should drive this based on current APIs offered by libraries. > And its not like its hard to pull an SPKI out of an encoded cert. >=20 > What's really wrong with 2,1,[x],V in a TLSA RR? >=20 > Has anyone written the client code for that? I've written some python code to generate the TLSA records. The openssl and NSS python APIs don't provide a way to get the SPKI out of the certificate. I worked around the issue by using openssl's commandline tool to do an ASN.1 parse of the cert and extract out the SPKI that way. I've thought about writing patches for those libraries to provide functions to extract the data, but haven't found the time to do so. It seems like it should be easy for someone already familiar with the code, since the libraries need to be able to get at the various certificate parts for themselves anyway. I agree that the mechanism seems too useful to allow current lack of code to prevent us from specifying it--it's not unimplementable, there just hasn't been a reason to expose an API for extracting the SPKI from a certificate until now. > >>With that, would you find it acceptable to say that usage type 2 > >>MUST be used with selector type 1? > > > >Sorry, MUST be used with selector type 0. IMHO, that's over-restrictive. This seems adequate to resolve the issues you're alluding to (if I understand correctly, making sure the client has enough information to know what the TA *is*): a) If the TA is not known to the client and is omitted from the provided cert chain, the selector type MUST be 0 and the match type MUST be 0. b) If the TA is known to the client and/or is included in the provided cert chain, selector type 1 and/or match type 1 or 2 MAY be used. Now, using an SPKI *as* the TA is another matter. My interpretation of the draft (though it's not crystal clear on this point because of its mixed use of the word "certificate") and the consensus around issue #29 is that the selector is intended to select a certificate (using the SPKI as match criteria) not a SPKI. This would prevent us from omitting a TA unknown to the client from the certificate chain and having a TLSA 2 1 0 record (because there's no certificate for the client to match). Well, you could do it, but it wouldn't work. Using a SPKI as the TA would require a new cert usage type. > >>As for the definition, we could say "The target certificate either > >>MUST match the one in the TLSA record, or MUST pass PKIX validation > >>with any certificate matching the TLSA record considered to be a > >>trust anchor for this validation" > >>Alternately, one that is different than what we have specified for > >>most of the time but is probably what most people want, is simply > >>"The target certificate either MUST match the one in the TLSA > >>record" and not have a way for DANE to give a new trust anchor. The > >>second alternative is like type 1 but with no expectation that the > >>cert chains to a trust anchor for the client. I think there is a typo in the above: you probably meant to strike the "either" in the MUST statement (or you left out the "or" clause). I'll go with the former. Let's say hypothetically that we have the following usages: 0 - PKIX+CA (i.e., same as current spec) 1 - PKIX+EE (i.e., same as current spec) 2 - PKIX with the specified TA (i.e., same as current spec) 3 - Exactly this EE cert, ignore how it's signed ("match the record") [Another way to put this is that it's really signed by the DNS key] (Incidentally, this is how the current set of cert usage types were initially proposed, except that 3 was marked as "future".) For small domains, 1 & 3 will probably get the most use. For large domains, I could imagine that 0 & 2 would be more popular so that the zone administrators don't need to keep up with the certificate rollovers (depending on how easy/difficult it is for them to hook into whatever process keeps track of certificate renewals and generate the appropriate TLSA records). So it doesn't seem like any of the types would be unused. (i.e., I don't see a reason to eliminate the current usage type 2.) That said, if we're trying to reduce complexity, we could probably drop type 1 because the domain could always use type 3 and get the same (or =66rom their point of view better) effect in most cases. AFAICT, the only advantage type 1 has over type 3 is that if the EE cert is revoked (appropriately), and the domain doesn't do anything with the TLSA record, the clients are protected. On the other hand, the domain doesn't need to worry about whether the CAs/TAs attesting to their cert is trusted by all/most of their clients if they use type 3 instead of type 1. Most domains will probably see more benefits in type 3 than type 1. If I'm associating to a public CA, I would probably prefer to use type 0 rather than type 2, since I would otherwise put my users (and my reputation) at risk if a CA key is compromised. If I have my own private CA, I would use type 2 (otherwise it wouldn't work). HTH --=20 Scott Schmit --7AUc2qLy4jB3hD7Z Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMjAyMDYwMDQ0WjAjBgkqhkiG9w0BCQQxFgQUQP7qF5Nq rJuC0Nxv42uPa1SqPq0weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAYUUEwjqG b7c/nCW/kExVyID/U0NvXqLN5OXE+OOBvzM3GMcy6G0Ees2/V0Vnb7elbD6fjwf5pq5egHbj sw9JJrpI0tXi4VHgA4bQHuWmFOrYfhwkw6rsJ1Tfr3O6CYKepnxGs6Qcpso48zr6K08jyUsB IF3IEOm9QuZ5sO5Z5gSGwl3iRSziYF3fDmR6GNlKNjkpjHYKHLRNL49vJ3d/yHdzUI6Yki74 af5gK3Y/dXyCM45AkGW3czZSC+lNiM9lWUOoyzYwdukcyo6dPXRE5QCQ5nliNplzZq/WZ1dT cNL9Dagc/TbbFBEPLYxJj4KiSaxfBNyw+SK+BR0Gu8F+AA== --7AUc2qLy4jB3hD7Z-- From matt@mattmccutchen.net Wed Feb 1 23:44:02 2012 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 CA91321F8A8F for ; Wed, 1 Feb 2012 23:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqtn4DleFCHW for ; Wed, 1 Feb 2012 23:44:02 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2B79921F8A8E for ; Wed, 1 Feb 2012 23:44:02 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id B12D3284076; Wed, 1 Feb 2012 23:44:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=OT3qcZk3BwWwwuaoJVlcmWt4Iie2dgcb7TUtyNj2Yd+ 1h12MdpgiO9wW4Rp34moGT3VL8coKvrkmGQGDVmuL/ISr8brNhSNP9+i0PkpMvnG 6UJcXAAUpdkSoS2KinWdbWu3aAix3gCICFWu9uhJZ2sp+tvQzQTwTbIAtfgiII2o = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=bdLRUSEPlj6IfkkGkd9yIat9vJQ=; b=b7hk0oE8pu kpnjx469r9n+3uiiBKDs7wQ0wuZzAdFzaRvQ8qe70b76KY53Whuq9bSyWgFvElPk LPDSph1oPlowch3r/AbQXePVLC9Z0J9Sd+E9jVuA/ERLmY/faK9FW4dlq05qaB3i K2LqfRKQP6d9YqMcegX/SVE+kcLD1+E6w= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (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 594FD284071; Wed, 1 Feb 2012 23:44:01 -0800 (PST) Message-ID: <1328168640.1627.29.camel@localhost> From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= Date: Wed, 01 Feb 2012 23:44:00 -0800 In-Reply-To: <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 07:44:02 -0000 On Tue, 2012-01-31 at 10:21 +0100, Ond=C5=99ej Sur=C3=BD wrote: > it seems this thread is either unimportant or very hard to understand > to the rest of the working group (and I must admit it's very hard for > me to understand the underlying problem). Let me explain once more. If you do not understand, please tell me where I lost you. Suppose my TLS server has a certificate C that is signed by the root certificate R of a private CA. I want DANE clients to accept C, but not other certificates signed by R. Usages 0 and 1 do not work: since R is not in the trust anchor store of mainstream clients, validation fails. With usage 2 and association data that matches R, clients will accept any certificate signed by R, which I don't want. The debate was about what happens if the TLSA record has usage 2 and association data that matches C, meaning that C is considered to be a trust anchor for the validation. My understanding is that validation fails because "Valid paths begin with certificates issued by a trust anchor" (RFC 5280 section 6), and there is no certificate issued by C at all (remember, C is issued by R, not itself), hence there is no way to construct a valid path. > Would you be willing to accept this partial solution, so we can move > on with the draft? No. Not that I expect it to matter what I am willing to accept. I don't understand why Martin called Paul's wording a partial solution. As far as I can tell, it doesn't do anything to solve the problem Martin identified. > If not would you be willing to propose a specific > text we can work on? My proposal is to add certificate usage 3, as follows: 3 -- The target certificate MUST match the TLSA record > I think we have discussed this issue long enough and haven't gotten any= where, On the contrary, we learned that in addition to the case of a self-signed server cert (which is still unclear and likely to be a problem in real implementations), the current draft definitely does not support positive assertion of a non-self-signed server cert. Adopting usage 3, or alternatively Stephen's proposed amendment (https://www.ietf.org/mail-archive/web/dane/current/msg04239.html), would solve both problems. > From the chair viewpoint I think it's more important to stick to existi= ng > standards than to cover every possible use case. If there's one workin= g > way how to deploy EE-certificate without using existing CAs (trust anch= ors) > I am perfectly happy even if it's not the easiest way possible. Could you clarify what existing standard you believe we should stick to? Paul Wouters and I had the understanding that positive assertion of an arbitrary server certificate was within the intended scope of the use cases even though it was not specifically mentioned in RFC 6394. And I think it is an important part of making DANE convenient for server admins. But again, not that it matters what I think. --=20 Matt From ondrej.sury@nic.cz Wed Feb 1 23:56:59 2012 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 5831821F8AC8 for ; Wed, 1 Feb 2012 23:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1e37bATSKDJ for ; Wed, 1 Feb 2012 23:56:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 30E4B21F8A1D for ; Wed, 1 Feb 2012 23:56:58 -0800 (PST) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 385562A304C; Thu, 2 Feb 2012 08:56:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328169417; bh=8aUtTnq7DA7I4Ik6V5qV6L9uNbL28p9Fqv2hMpnF8NQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cusv7WkuZnB9fN5vqb45CHNvQCw3dV6nhMRDo+wXZajC4AQwQyqycNZWYxdjgCARx W1RALEf3bv2KManZUYCPDF0rBmqA8VUN0KNN/xCNNDzqoY/7VhGJZNOzDH6XVgGn4/ j+5p0wkQxoJ5Tnv5Dk+Yw/EPZqgnBA2UoioYG1NM= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <1328168640.1627.29.camel@localhost> Date: Thu, 2 Feb 2012 08:56:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 07:56:59 -0000 On 2. 2. 2012, at 8:44, Matt McCutchen wrote: > On Tue, 2012-01-31 at 10:21 +0100, Ond=C5=99ej Sur=C3=BD wrote: >> it seems this thread is either unimportant or very hard to understand >> to the rest of the working group (and I must admit it's very hard for >> me to understand the underlying problem). >=20 > Let me explain once more. If you do not understand, please tell me > where I lost you. Your new explanation is perfect. Thanks for writing it (or maybe it's combination of Stephen's email and your clearer language). > Suppose my TLS server has a certificate C that is signed by the root > certificate R of a private CA. I want DANE clients to accept C, but = not > other certificates signed by R. >=20 > Usages 0 and 1 do not work: since R is not in the trust anchor store = of > mainstream clients, validation fails. With usage 2 and association = data > that matches R, clients will accept any certificate signed by R, which = I > don't want. The debate was about what happens if the TLSA record has > usage 2 and association data that matches C, meaning that C is > considered to be a trust anchor for the validation. My understanding = is > that validation fails because "Valid paths begin with certificates > issued by a trust anchor" (RFC 5280 section 6), and there is no > certificate issued by C at all (remember, C is issued by R, not = itself), > hence there is no way to construct a valid path. >=20 >> Would you be willing to accept this partial solution, so we can move >> on with the draft? >=20 > No. Not that I expect it to matter what I am willing to accept. >=20 > I don't understand why Martin called Paul's wording a partial = solution. > As far as I can tell, it doesn't do anything to solve the problem = Martin > identified. >=20 >> If not would you be willing to propose a specific >> text we can work on? >=20 > My proposal is to add certificate usage 3, as follows: >=20 > 3 -- The target certificate MUST match the TLSA record >=20 >> I think we have discussed this issue long enough and haven't gotten = anywhere, >=20 > On the contrary, we learned that in addition to the case of a > self-signed server cert (which is still unclear and likely to be a > problem in real implementations), the current draft definitely does = not > support positive assertion of a non-self-signed server cert. =20 > Adopting usage 3, or alternatively Stephen's proposed amendment > (https://www.ietf.org/mail-archive/web/dane/current/msg04239.html), > would solve both problems. It seams reasonable, but I would like to hear more opinions from WG. >> =46rom the chair viewpoint I think it's more important to stick to = existing >> standards than to cover every possible use case. If there's one = working >> way how to deploy EE-certificate without using existing CAs (trust = anchors) >> I am perfectly happy even if it's not the easiest way possible. >=20 > Could you clarify what existing standard you believe we should stick = to? First two paragraphs of Stephen's email. He said it better. > Paul Wouters and I had the understanding that positive assertion of an > arbitrary server certificate was within the intended scope of the use > cases even though it was not specifically mentioned in RFC 6394. And = I > think it is an important part of making DANE convenient for server > admins. But again, not that it matters what I think. -- 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 i.grok@comcast.net Thu Feb 2 05:27:36 2012 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 5072721F85DB for ; Thu, 2 Feb 2012 05:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42mHBC6yEiXp for ; Thu, 2 Feb 2012 05:27:35 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id C197021F85C5 for ; Thu, 2 Feb 2012 05:27:35 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta03.emeryville.ca.mail.comcast.net with comcast id V1Q21i0040vp7WLA31Tbyd; Thu, 02 Feb 2012 13:27:35 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta05.emeryville.ca.mail.comcast.net with comcast id V1TZ1i00D00PQ6U8R1Tasc; Thu, 02 Feb 2012 13:27:35 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q12DRWCU022767 for ; Thu, 2 Feb 2012 08:27:32 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q12DRWkL022766 for dane@ietf.org; Thu, 2 Feb 2012 08:27:32 -0500 Date: Thu, 2 Feb 2012 08:27:32 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120202132732.GA22513@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 13:27:36 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 02, 2012 at 08:56:56AM +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 2. 2. 2012, at 8:44, Matt McCutchen wrote: > > On Tue, 2012-01-31 at 10:21 +0100, Ond=C5=99ej Sur=C3=BD wrote: > >> I think we have discussed this issue long enough and haven't gotten > >> anywhere, > > > > On the contrary, we learned that in addition to the case of a > > self-signed server cert (which is still unclear and likely to be a > > problem in real implementations), the current draft definitely does not > > support positive assertion of a non-self-signed server cert. =20 > > Adopting usage 3, or alternatively Stephen's proposed amendment > > (https://www.ietf.org/mail-archive/web/dane/current/msg04239.html), > > would solve both problems. >=20 > It seams reasonable, but I would like to hear more opinions from WG. I think client code will be cleaner if usage type 3 is distinct from usage type 2, so I would prefer that. Ignoring this usage will put users in the awkward place of choosing another cert usage that doesn't meet their needs. For example, if I want to directly assert an EE cert that is certified by a TA that is in some, but not all, client certificate stores, my options are: a) Loosen the assocation by using type 2, which still reduces my risk compared to not using DANE at all, but not as much as if I used a TA all my clients already accept so that I could use usage 1 instead. b) Generate a self-signed certificate and use type 2, breaking all interoperability with those clients that have my TA but don't support DANE--which might mean I support fewer clients than I did before. c) Use type 1 and pick a more widely-recognized TA to issue me a cert, if possible. This might not always be an option, because my clients could have mutually exclusive sets of TAs they trust. Also, live with the fact that DANE can't help me assert that my key is trustworthy without breaking interoperability with my clients. d) Lobby for a cert usage type 3 :-) We should add cert usage type 3 (or change type 1 to be what we're describing as type 3). --=20 Scott Schmit --AqsLC8rIMeq19msA Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMjAyMTMyNzMyWjAjBgkqhkiG9w0BCQQxFgQUEaGTTYRy W/QhPTS+6WRi61eA9AoweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAZLdLOKcp fjQFD3gd+l07bduLXfOZ8pCEn+XV8PQnluxJH4wnAkmFNKkYWobVC04P/wn6jQioc+STwaEB 6W0fAXHZ75xfroJ5Hwix54RLIr4lopi5da0l3a6L52Mlwq0BbsYPwXorjtxMB1ixoy9T7+Y0 S1c5lmuWwSWosECze+7bBAlGxvZOCobCFdK/2e0HbAsO5QQLUL0DzW/bFRAQ0ZCN3z5Zw73b gTb9cVV0tZ/QO3O3lg5Ohgqbv7JziXHU+wWv1P+susUzaKRl0xttve4NflvkfDSOaa6AS82g AkEoet3KZgfOgZon/O58CnyIScxoTqL+hXLUg2vXNjfN0w== --AqsLC8rIMeq19msA-- From jakob@kirei.se Thu Feb 2 09:52:19 2012 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 2333321F8546 for ; Thu, 2 Feb 2012 09:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n-Gve1860bO for ; Thu, 2 Feb 2012 09:52:16 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3B30A21F8601 for ; Thu, 2 Feb 2012 09:52:14 -0800 (PST) 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=V44/4PBw998e+gkt70zm8bWEKR2OaqTnVxpZY/8Beuo=; b=nvGkvs0pezwPxtRcKtRhvGxlk2SrqXdVQ4JQk8BdaUmLrYHHWrxqfmy3YeJdwJs7Jt7rJYi06aXKQ Rx4xvqYKAUfGxhFMROIOXF3IpTOj/zgE4fd5fbeFwHQcdZStqyjYcRUFab/r8TLviqDkFxhSyu6nkh PTzATcnDnkrAcvSE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 2 Feb 2012 18:52:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Jakob Schlyter In-Reply-To: Date: Thu, 2 Feb 2012 18:52:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 17:52:19 -0000 On 2 feb 2012, at 08:56, Ond=C5=99ej Sur=C3=BD wrote: > It seams reasonable, but I would like to hear more opinions from WG. I'm good with adding a type 3 ("The target certificate MUST match the = TLSA record"). jakob From paul.hoffman@vpnc.org Thu Feb 2 09:58:51 2012 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 4AF0821F860F for ; Thu, 2 Feb 2012 09:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlDFS3X-fbcL for ; Thu, 2 Feb 2012 09:58:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E358821F861F for ; Thu, 2 Feb 2012 09:58:50 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q12HwlBa049789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Feb 2012 10:58:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> Date: Thu, 2 Feb 2012 09:58:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 17:58:51 -0000 On Feb 2, 2012, at 9:52 AM, Jakob Schlyter wrote: > On 2 feb 2012, at 08:56, Ond=C5=99ej Sur=C3=BD wrote: >=20 >> It seams reasonable, but I would like to hear more opinions from WG. >=20 > I'm good with adding a type 3 ("The target certificate MUST match the = TLSA record"). +1 here. It would certainly make the documentation of type 2 clearer. --Paul Hoffman From mrex@sap.com Thu Feb 2 11:14:06 2012 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 0BB9421F858B for ; Thu, 2 Feb 2012 11:14:06 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiuSyjuo0xvY for ; Thu, 2 Feb 2012 11:14:05 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4982121F8635 for ; Thu, 2 Feb 2012 11:14:04 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q12JE3aw009618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 20:14:03 +0100 (MET) From: Martin Rex Message-Id: <201202021914.q12JE2To002053@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 2 Feb 2012 20:14:02 +0100 (MET) In-Reply-To: from "Paul Hoffman" at Feb 2, 12 09:58:47 am 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] Call for last comments on issue #37. 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, 02 Feb 2012 19:14:06 -0000 Paul Hoffman wrote: > >>Ondrej Sury wrote: >>> >>> It seams reasonable, but I would like to hear more opinions from WG. > >Jakob Schlyter wrote: >> >> I'm good with adding a type 3 >> ("The target certificate MUST match the TLSA record"). > > +1 here. It would certainly make the documentation of type 2 clearer. 11 ++ 1111 ++ 111 11 ++++++++++ 11 ++++++++++ 11 ++ 11 ++ 11 111111 -Martin From cloos@jhcloos.com Thu Feb 2 11:32:39 2012 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 E5FFA21F84DA for ; Thu, 2 Feb 2012 11:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE3w8ZXIQpjH for ; Thu, 2 Feb 2012 11:32:39 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD621F84D9 for ; Thu, 2 Feb 2012 11:32:39 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 7021640193; Thu, 2 Feb 2012 19:32:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328211157; bh=YhoBfh+l3+qt7SLRT9GLhQH71ep/NXOpy5muCKagLRU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=V8fKK9NhhyLD8T7LUrk32gHTdh7/mINIgTeld4wQYVRHb0VDxp+atVNy3wc8v416U Xr+dB+yiu8wTyEM4OG7nQDlZCAkbJXbJLVz8Rt8m+CBdvdmYVaFypYk+rBqBYCnq2m Vzi6R7tPKmA/8o1DNVaGiO0v4xPXxhxUmWoN5Wfs= Received: by carbon.jhcloos.org (Postfix, from userid 500) id B384F36004C; Thu, 2 Feb 2012 19:30:10 +0000 (UTC) From: James Cloos To: IETF DANE WG list In-Reply-To: (Paul Hoffman's message of "Thu, 2 Feb 2012 09:58:47 -0800") References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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, 02 Feb 2012 14:30:10 -0500 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120202:dane@ietf.org::sDe0LxjPTMkhkfrB:0006Rn9Q X-Hashcash: 1:30:120202:paul.hoffman@vpnc.org::MdwgUlEroW2AYdHY:0000000000000000000000000000000000000004Z/8V X-Hashcash: 1:30:120202:jakob@kirei.se::cMV2y3FW3JgxOYjJ:00Zz9nT Cc: Paul Hoffman Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 19:32:40 -0000 >>>>> "PH" == Paul Hoffman writes: PH> On Feb 2, 2012, at 9:52 AM, Jakob Schlyter wrote: >> On 2 feb 2012, at 08:56, OndÅ™ej Surý wrote: >> >>> It seams reasonable, but I would like to hear more opinions from WG. >> >> I'm good with adding a type 3 ("The target certificate MUST match the TLSA record"). PH> +1 here. It would certainly make the documentation of type 2 clearer. Also +1. I think it covers all of the concerns I've posted. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From pieter.lexis@os3.nl Thu Feb 2 11:47:51 2012 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 19DCB21F8605 for ; Thu, 2 Feb 2012 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0BCF0xSUFhw for ; Thu, 2 Feb 2012 11:47:50 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 4608421F8600 for ; Thu, 2 Feb 2012 11:47:50 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 035C117AA58 for ; Thu, 2 Feb 2012 20:47:49 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:b12f:3e2:1170:8f86] (unknown [IPv6:2001:980:5dd1:1:b12f:3e2:1170:8f86]) by smtp.os3.nl (Postfix) with ESMTPSA id D1A2F17AA31 for ; Thu, 2 Feb 2012 20:47:48 +0100 (CET) Message-ID: <4F2AE864.1060605@os3.nl> Date: Thu, 02 Feb 2012 20:47:48 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> In-Reply-To: <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 19:47:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/02/2012 06:52 PM, Jakob Schlyter wrote: > I'm good with adding a type 3 ("The target certificate MUST match the TLSA record"). > +1, and usage 2 should be better defined. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPKuhgAAoJELPqGO5ebd4jVvwQAI99tkqxxwjV5GEBYaFmfapp j+4W3Ivm2buYUYRxIH5pkQCZ0nTfx3gvK17XM/0Ypnu0ist2+HoMBpG7Gak3AbT6 kwSZLJKgeulMPi1CETB6SHp/hvPR1T+R7xXwVeeEcGGllumUdi62JX2soU7WKibE 2fSE9VBizGsgNL09PZScQG4xfBEBhVY09vbZWdzG22yfMwrBVF9GPotbA/cSu55o aO0m6E/GEO+5FrhAMdopuCJj/pQOrXXJWHaSd4EsOAlk0jrViAPqooa70CTvwr8Q ZWMlWVVf7nLf4sIcfVI+PgC9Uvo/aqUqfodqWWYEvgJoaY2oEITs+5tvUjdDDZwz +RFT7X5YRBtTU93yVgXruRCb41l8jE4oiym8E1EJUKGz/7UbteHR/8q5OfJc3uYe XqQII7bhH0pOgjvpAN/+9UrDngq1yPlgXDseu00L9PenTB8+HY5j/y7ida1pFWEL mcsorPQZ0HSgfEf2X0t6qZysRE7OQ12R/+XRpvW3tFdVd3mL8cnLWFDqsCXaIB1/ ZyvbP+k4VVKJlPWoUdFvld3IeVluSybfhlgSuqeYJdHokCTT1nk2mERRwB89Pe3D cSu3qbXliHGUFhqINxCMVQjYnprDmyC6rP3LU8pGjshTVrESXI/Lq0EyPWNBRnhx Te7b0UVzaqQHAiyZIvH2 =GfpO -----END PGP SIGNATURE----- From mrex@sap.com Thu Feb 2 11:49:12 2012 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 B31FB21F8600 for ; Thu, 2 Feb 2012 11:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.825 X-Spam-Level: X-Spam-Status: No, score=-9.825 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY7dm+kSXxgk for ; Thu, 2 Feb 2012 11:49:12 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7422D21F861A for ; Thu, 2 Feb 2012 11:49:11 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q12Jn48i019916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 20:49:04 +0100 (MET) From: Martin Rex Message-Id: <201202021949.q12Jn4Lo003981@fs4113.wdf.sap.corp> To: i.grok@comcast.net (Scott Schmit) Date: Thu, 2 Feb 2012 20:49:04 +0100 (MET) In-Reply-To: <20120202060044.GA20352@odin.ulthar.us> from "Scott Schmit" at Feb 2, 12 01:00:44 am 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] simple key management 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, 02 Feb 2012 19:49:12 -0000 Scott Schmit wrote: > > Let's say hypothetically that we have the following usages: > 0 - PKIX+CA (i.e., same as current spec) > 1 - PKIX+EE (i.e., same as current spec) > 2 - PKIX with the specified TA (i.e., same as current spec) > 3 - Exactly this EE cert, ignore how it's signed ("match the record") Seperating 2 into 2+3 is extremely desirable, because of the other issue you mentioned, which I had not thought of: > > IMHO, that's over-restrictive. This seems adequate to resolve the issues > you're alluding to (if I understand correctly, making sure the client > has enough information to know what the TA *is*): > a) If the TA is not known to the client and is omitted from the provided > cert chain, the selector type MUST be 0 and the match type MUST be 0. > b) If the TA is known to the client and/or is included in the provided > cert chain, selector type 1 and/or match type 1 or 2 MAY be used. While a TLS server must always send his TLS certificate with the public key that was used for the crypto operation in the TLS protocol itself (including when the TLS server is using a self-signed cert), there is a significant difference about path certificates. TLSv1.0 rfc2246 7.4.2 Server Certificate http://tools.ietf.org/html/rfc2246#page-39 certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed *> independently, the self-signed certificate which specifies the *> root certificate authority may optionally be omitted from the *> chain, under the assumption that the remote end must already *> possess it in order to validate it in any case. For Usage 2 with path certificates (or their SPKI) from a private CA, rather than the server's own certificate, the exemption from above no longer applies, because the remote end does _not_ already possess that cert. TLS Servers that should be used with Usage 2 MUST always send the full certificate path, including the self-signed rootCA cert at the end. -Martin From zack.weinberg@gmail.com Thu Feb 2 12:12:25 2012 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 DB07021F853A for ; Thu, 2 Feb 2012 12:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTiQBbTds172 for ; Thu, 2 Feb 2012 12:12:25 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0E21F852C for ; Thu, 2 Feb 2012 12:12:25 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3942602obb.31 for ; Thu, 02 Feb 2012 12:12:24 -0800 (PST) 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:cc:content-type; bh=aOffa6LAq44wTOTtMqU5a7/GEb/aAbuT2Oyx0KuMoM4=; b=nrjW8XI7vaW8hDPj4kDf3/FlsfLdgRYSl1oRsfypFbaQyonCXOGt7EmTuWuG8mfj04 P/a6s3otdMz/Z1+IZ1YUYrNP6bVYHSacKdaL5lNsYbNOuOrDOJL46LLnBQB6apHOyvMv 1Mv+/eJwCuYHz29JmqIdPJ06uhLirQ5eq+wSg= MIME-Version: 1.0 Received: by 10.182.7.42 with SMTP id g10mr3900328oba.7.1328213544867; Thu, 02 Feb 2012 12:12:24 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.80.104 with HTTP; Thu, 2 Feb 2012 12:12:24 -0800 (PST) In-Reply-To: <4F2AE864.1060605@os3.nl> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> <4F2AE864.1060605@os3.nl> Date: Thu, 2 Feb 2012 12:12:24 -0800 X-Google-Sender-Auth: 0h1MfHKnsk5b7m2lgfQqs6fpWs8 Message-ID: From: Zack Weinberg Cc: dane@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 20:12:26 -0000 +1 from me too. On Thu, Feb 2, 2012 at 11:47 AM, Pieter Lexis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > On 02/02/2012 06:52 PM, Jakob Schlyter wrote: >> I'm good with adding a type 3 ("The target certificate MUST match the TLSA record"). >> > > +1, and usage 2 should be better defined. > > - -- > Pieter > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPKuhgAAoJELPqGO5ebd4jVvwQAI99tkqxxwjV5GEBYaFmfapp > j+4W3Ivm2buYUYRxIH5pkQCZ0nTfx3gvK17XM/0Ypnu0ist2+HoMBpG7Gak3AbT6 > kwSZLJKgeulMPi1CETB6SHp/hvPR1T+R7xXwVeeEcGGllumUdi62JX2soU7WKibE > 2fSE9VBizGsgNL09PZScQG4xfBEBhVY09vbZWdzG22yfMwrBVF9GPotbA/cSu55o > aO0m6E/GEO+5FrhAMdopuCJj/pQOrXXJWHaSd4EsOAlk0jrViAPqooa70CTvwr8Q > ZWMlWVVf7nLf4sIcfVI+PgC9Uvo/aqUqfodqWWYEvgJoaY2oEITs+5tvUjdDDZwz > +RFT7X5YRBtTU93yVgXruRCb41l8jE4oiym8E1EJUKGz/7UbteHR/8q5OfJc3uYe > XqQII7bhH0pOgjvpAN/+9UrDngq1yPlgXDseu00L9PenTB8+HY5j/y7ida1pFWEL > mcsorPQZ0HSgfEf2X0t6qZysRE7OQ12R/+XRpvW3tFdVd3mL8cnLWFDqsCXaIB1/ > ZyvbP+k4VVKJlPWoUdFvld3IeVluSybfhlgSuqeYJdHokCTT1nk2mERRwB89Pe3D > cSu3qbXliHGUFhqINxCMVQjYnprDmyC6rP3LU8pGjshTVrESXI/Lq0EyPWNBRnhx > Te7b0UVzaqQHAiyZIvH2 > =GfpO > -----END PGP SIGNATURE----- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mrex@sap.com Thu Feb 2 12:22:02 2012 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 0B7A021F86AF for ; Thu, 2 Feb 2012 12:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.122 X-Spam-Level: X-Spam-Status: No, score=-10.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQRDQXNxcTg4 for ; Thu, 2 Feb 2012 12:22:01 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3D66C21F8666 for ; Thu, 2 Feb 2012 12:22:00 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q12KLxCM016755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2012 21:21:59 +0100 (MET) From: Martin Rex Message-Id: <201202022021.q12KLwdh005777@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Thu, 2 Feb 2012 21:21:58 +0100 (MET) In-Reply-To: <1328168640.1627.29.camel@localhost> from "Matt McCutchen" at Feb 1, 12 11:44:00 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] Call for last comments on issue #37. 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, 02 Feb 2012 20:22:02 -0000 Matt McCutchen wrote: > > > Would you be willing to accept this partial solution, so we can move > > on with the draft? > > No. Not that I expect it to matter what I am willing to accept. > > I don't understand why Martin called Paul's wording a partial solution. > As far as I can tell, it doesn't do anything to solve the problem Martin > identified. Paul's wording did not address (2) of the (3) scenarios I mentioned at all. I called it "partial solution" because with creative reading of PKIX rfc5280 section 6.1 the text could be interpreted to cover one of the (3) scenarios that I described. But creatively performing PKIX validation on a self-signed certificate which the RP does *NOT* have in posession as trust anchor will provide no security beyond a self-consistency check. -Martin From stephen.farrell@cs.tcd.ie Thu Feb 2 12:43:54 2012 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 5B8C921F8589 for ; Thu, 2 Feb 2012 12:43:54 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2UaX4fNCPbk for ; Thu, 2 Feb 2012 12:43:53 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E521F856F for ; Thu, 2 Feb 2012 12:43:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 13572171C3A for ; Thu, 2 Feb 2012 20:43:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1328215431; bh=zwJgayZcMFJFXkFC6+BbKf9b oRch3BAAnEPtzrLsfJs=; b=UL3P7c9FKcX4AQ1CBHXJzg7bo4e1qWaxD8NsWTb1 4rxMq7bn3+C/csg7beuBdwC95yEhfcr10nX7x5dKgSVmmtLY50AR/N4JZQfueJhl 37df3dI/0NcLgri4Czr1G5Yhs92nQQC1FEQA1aJAtMUsCOp1riYhGhSch/zJQU3R /SDcifSZOq8rXs7AjshzETIkWo/9a8KQ7gnn09sTVb1y0Fj2vuYE0KSjajJj17pr D8P/+84v7rKfJak2/HE8YPgyNANIObL3n2LB+uA+6Io0tH55EbS14cQu2CnZ1XRW v1MLCge2G9wdKc3tzocq0xf55UYS3pkJb/uGtkIxYE3noQ== 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 5e-8l9uLeiHB for ; Thu, 2 Feb 2012 20:43:51 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.45.53.99]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 516FE171C27 for ; Thu, 2 Feb 2012 20:43:50 +0000 (GMT) Message-ID: <4F2AF57C.5010701@cs.tcd.ie> Date: Thu, 02 Feb 2012 20:43:40 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dane] 5280 section 6 and DANE usage etc. 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 Feb 2012 20:43:54 -0000 Hi, Martin's mail just now reminded me of something else I meant to bring up. I think there's a bit of work to be done to compare each of the various DANE usage, selector and matching rules (well matching rule 0 vs. 1 or 2) against section 6 of 5280. (Mostly, or maybe completely, related to the "new" usage 2 if all those +1's keep coming for the "add usage 3" idea.) This is not really something that's easy enough to do as a group in a few mails, but is rather something where one or more people need to go off and sit down for a few hours to look at the problem and come back with a reasoned analysis. I'm worried there are corner cases we might need to document or prevent that we won't see if we just try to figure this out by arguing. (Much as I like arguing:-) Scott mentioned some cases related to private CAs where different clients have different sets of TA configured. I'm also a little uneasy with oddities like policy mappings and name constraints that have negative restrictions that "pass down" a cert chain where the TLSA value matches the middle of the chain. In particular if usage 2 (the new variety) means treating the TLSA RR as a TA, then that could generate unexpected behaviour. Note - I don't think this needs to or should lead to a 100 page essay for inclusion in the protocol draft. While the analysis does need to be done, it might well result in a very few new words in the document. And those might be guidance (e.g. "Patient: doctor doctor it hurts when I do this. Doctor: don't do that then.) or maybe some 2119 language, or a mixture. I don't think we'll know until someone's done that analysis. And if someone has already done the work, great! And if they posted it to the list, even better (except it'll make me look dumb;-) Cheers, S From ilari.liusvaara@elisanet.fi Thu Feb 2 13:20:58 2012 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 6641021F8671 for ; Thu, 2 Feb 2012 13:20:58 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmKQPU7kcV1P for ; Thu, 2 Feb 2012 13:20:58 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id C59E921F8670 for ; Thu, 2 Feb 2012 13:20:57 -0800 (PST) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh07-2.mail.saunalahti.fi (Postfix) with SMTP id 4A56B18D712; Thu, 2 Feb 2012 23:20:56 +0200 (EET) Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A028BD46388; Thu, 02 Feb 2012 23:20:56 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 23E2B2BD42; Thu, 2 Feb 2012 23:20:54 +0200 (EET) Date: Thu, 2 Feb 2012 23:20:54 +0200 From: Ilari Liusvaara To: Stephen Farrell Message-ID: <20120202212054.GA18914@LK-Perkele-VI.localdomain> References: <4F2AF57C.5010701@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F2AF57C.5010701@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: dane Subject: Re: [dane] 5280 section 6 and DANE usage etc. 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 Feb 2012 21:20:58 -0000 On Thu, Feb 02, 2012 at 08:43:40PM +0000, Stephen Farrell wrote: > > I'm worried there are corner cases we might need to > document or prevent that we won't see if we just try to > figure this out by arguing. (Much as I like arguing:-) What about the following: What does "comparison data for a certificate is malformed" in section 4.4 mean? For matching type 0? For matching types 1 and 2? Searching for "malformed" gets only 1 hit, in section 4.4. I think that for types 1 and 2, comparision data is malformed if and only if it is not the right length for matching type. But for type 0? Never malformed? Malformed iff ASN.1 decoding fails? Malformed if some PKIX checks don't pass (what checks)? -Ilari From stephen.farrell@cs.tcd.ie Thu Feb 2 13:43:29 2012 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 349DE21F8666 for ; Thu, 2 Feb 2012 13:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztGg8VeeSfmw for ; Thu, 2 Feb 2012 13:43:28 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6CA21F85D6 for ; Thu, 2 Feb 2012 13:43:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 97F5D153C2F; Thu, 2 Feb 2012 21:43:27 +0000 (GMT) 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=1328219007; bh=t3xCC5ZU4d65/5 yXS9jdR7dDJEAdek/UwOVwhcP3zLg=; b=TsyerX/5yZzq8h0KPxYDViZK6pVsiF smxJUq7CmliI8UZe29GzK2/tadvp+piafkA8KWQQZ1K9gm5nHULEue3bnthTWZcy KUg6hEeiWTiKFIOqGU0nE/mNqluNO6JIgCyu5K/Rxt3hcXkXXv5PxaaZvumgy6rP SmG83EHmLSgTGbduUpvQI0np4Icik1pJ8T41JUP9bjNpN/9uklT7VZdbNV7qzYV2 CdtETZQernLVkRhwTmtfKOo9LxxhfM7x/ZN4SQ37Wn6Uik5IVPj6TJr0rSEP768g ae7dCs4x4gc5nj3fqvDiaodDYREJqGn9b0rezYewrhIka6dJCLAkdnqg== 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 TDi4Nph1XorI; Thu, 2 Feb 2012 21:43:27 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.45.53.99]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 47A4C171C27; Thu, 2 Feb 2012 21:43:27 +0000 (GMT) Message-ID: <4F2B0373.8030704@cs.tcd.ie> Date: Thu, 02 Feb 2012 21:43:15 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ilari Liusvaara References: <4F2AF57C.5010701@cs.tcd.ie> <20120202212054.GA18914@LK-Perkele-VI.localdomain> In-Reply-To: <20120202212054.GA18914@LK-Perkele-VI.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] 5280 section 6 and DANE usage etc. 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 Feb 2012 21:43:29 -0000 On 02/02/2012 09:20 PM, Ilari Liusvaara wrote: > On Thu, Feb 02, 2012 at 08:43:40PM +0000, Stephen Farrell wrote: >> >> I'm worried there are corner cases we might need to >> document or prevent that we won't see if we just try to >> figure this out by arguing. (Much as I like arguing:-) > > What about the following: I wasn't really asking about good or bad encoding. More about the logically possible combinations given DANE -14 and 5280 section 6. S > > What does "comparison data for a certificate is malformed" > in section 4.4 mean? For matching type 0? For matching types > 1 and 2? > > Searching for "malformed" gets only 1 hit, in section 4.4. > > I think that for types 1 and 2, comparision data is malformed > if and only if it is not the right length for matching type. > > But for type 0? Never malformed? Malformed iff ASN.1 decoding > fails? Malformed if some PKIX checks don't pass (what checks)? > > -Ilari > From trac+dane@trac.tools.ietf.org Thu Feb 2 14:13:13 2012 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 1AA7521F856A for ; Thu, 2 Feb 2012 14:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvfvpQAdID8V for ; Thu, 2 Feb 2012 14:13:12 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED2A21F854C for ; Thu, 2 Feb 2012 14:13:12 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rt4t1-0006eT-LP; Thu, 02 Feb 2012 17:12:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, matt@mattmccutchen.net, mrex@sap.com, ietf@augustcellars.com, marka@isc.org, paul.hoffman@vpnc.org, rbarnes@bbn.com, bmanning@vacation.karoshi.com, dot@dotat.at, warren@kumari.net X-Trac-Project: dane Date: Thu, 02 Feb 2012 22:12:10 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/dane/trac/ticket/28#comment:11 Message-ID: <072.76951ef86ed1c59f4981793affba0b59@trac.tools.ietf.org> References: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <057.eb22cfc8c145014f66d7c72f9cf864f8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, jakob@kirei.se, matt@mattmccutchen.net, mrex@sap.com, ietf@augustcellars.com, marka@isc.org, paul.hoffman@vpnc.org, rbarnes@bbn.com, bmanning@vacation.karoshi.com, dot@dotat.at, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120202221312.8ED2A21F854C@ietfa.amsl.com> Resent-Date: Thu, 2 Feb 2012 14:13:12 -0800 (PST) Resent-From: trac+dane@trac.tools.ietf.org X-Mailman-Approved-At: Thu, 02 Feb 2012 14:22:42 -0800 Cc: dane@ietf.org Subject: Re: [dane] #28: Interaction of SRV and TLSA records X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:13:13 -0000 #28: Interaction of SRV and TLSA records Changes (by warren@…): * status: new => closed * resolution: => worksforme Comment: Having not heard any strong objections, we are finally putting this question to bed (actually, we already did, this is just the admin task of closing hte ticket :-)). http://www.ietf.org/mail-archive/web/dane/current/msg04231.html "we are going to go with the scheme that had (rough) consensus: "use the first name that has a TLSA record, unless there is a protocol specific exception" scheme. This solutions solves the vast majority of cases, and still allows protocols that need special handling the ability to define it." W -- ---------------------------+----------------------------------------- Reporter: ondrej.sury@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: worksforme Keywords: | ---------------------------+----------------------------------------- Ticket URL: dane From ondrej.sury@nic.cz Thu Feb 2 23:55:11 2012 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 9C42221F84C5 for ; Thu, 2 Feb 2012 23:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s74tRArcZeE for ; Thu, 2 Feb 2012 23:55:11 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 19E2C21F84AE for ; Thu, 2 Feb 2012 23:55:10 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:11e9:5902:70d4:2012] (unknown [IPv6:2001:1488:ac14:1400:11e9:5902:70d4:2012]) by mail.nic.cz (Postfix) with ESMTPSA id E2AA32A2FCE; Fri, 3 Feb 2012 08:55:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328255708; bh=ZGcS7ohwDw1+jszQtAyWr08E2EqSWFSzfQizXJJ0hm0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E1xOl2Lu5lrbT+ZPDroMdrAMaSiKoAr32NfZ2hbPMI5n74nVyQpovm0pITcf6HqVj Lrh09JigdNRXJnyANkIfukJKmli8uWudFLASbanrpOBHFousGMaKWckSxFeMjI4JAh GqNxDc3VYn8jSvQ5vyZRkkY5NWE87vnaQZBA48yI= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 3 Feb 2012 08:55:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53165804-A3C0-410A-8546-74F48361E49F@nic.cz> References: <201201241859.q0OIxuGI011754@fs4113.wdf.sap.corp> <1D9EEB84-8B84-4187-BB1C-E07DB561F82C@nic.cz> <1328168640.1627.29.camel@localhost> <521C483D-FD63-4FDA-8495-4ED692CAE9B6@kirei.se> <4F2AE864.1060605@os3.nl> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Call for last comments on issue #37. 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 Feb 2012 07:55:11 -0000 +1 from me too. O. On 2. 2. 2012, at 21:12, Zack Weinberg wrote: > +1 from me too. >=20 > On Thu, Feb 2, 2012 at 11:47 AM, Pieter Lexis = wrote: >> Hi, >>=20 >> On 02/02/2012 06:52 PM, Jakob Schlyter wrote: >>> I'm good with adding a type 3 ("The target certificate MUST match = the TLSA record"). >>>=20 >>=20 >> +1, and usage 2 should be better defined. -- 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 trac+dane@trac.tools.ietf.org Thu Feb 2 23:55:17 2012 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 4626911E8072 for ; Thu, 2 Feb 2012 23:55:17 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWFm6LPlLc9O for ; Thu, 2 Feb 2012 23:55:16 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id ACD3011E8074 for ; Thu, 2 Feb 2012 23:55:15 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RtDyz-0001mX-J2; Fri, 03 Feb 2012 02:54:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, rbarnes@bbn.com, ondrej.sury@nic.cz X-Trac-Project: dane Date: Fri, 03 Feb 2012 07:54:57 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/37#comment:2 Message-ID: <076.ace42967300048800da40d223edc8082@trac.tools.ietf.org> References: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <061.a8eeecd5d3e79d55021946fbc77943e1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, rbarnes@bbn.com, ondrej.sury@nic.cz, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120203075516.ACD3011E8074@ietfa.amsl.com> Resent-Date: Thu, 2 Feb 2012 23:55:15 -0800 (PST) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #37: Additive assertion of server certificate X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 07:55:17 -0000 #37: Additive assertion of server certificate Changes (by ondrej.sury@…): * status: new => closed * resolution: => fixed Comment: I am seeing a lot of +1s, seems that my threatening to close the issue has helped :). (I must remember that for future reference.) I think I can safely say that we have a consensus on #37: We will add usage type 3: > 3 -- The target certificate MUST match the TLSA record to section 2.1.1. (And make accompanying changes in the document.) -- ----------------------+----------------------------------------- Reporter: matt@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | ----------------------+----------------------------------------- Ticket URL: dane From pieter.lexis@os3.nl Fri Feb 3 04:08:17 2012 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 0070421F8574 for ; Fri, 3 Feb 2012 04:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pskx33ArxHU7 for ; Fri, 3 Feb 2012 04:08:16 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id F10D221F8557 for ; Fri, 3 Feb 2012 04:08:15 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id A87E917AA59 for ; Fri, 3 Feb 2012 13:08:13 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:851d:ceeb:bb31:f074] (unknown [IPv6:2001:980:5dd1:1:851d:ceeb:bb31:f074]) by smtp.os3.nl (Postfix) with ESMTPSA id 4BB1617AA24 for ; Fri, 3 Feb 2012 13:08:13 +0100 (CET) Message-ID: <4F2BCE2C.7030505@os3.nl> Date: Fri, 03 Feb 2012 13:08:12 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] Specifying the certificate encoding in the spec 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 Feb 2012 12:08:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, In older drafts it explicitly says that the certificate for association should be DER encoded: (from draft 6): "..are structured using the RFC 5280 formatting rules and use the DER encoding." Draft 10 dropped this sentence in favour of '..apply to PKIX-formatted certificates.' in section 2.1.1. This, to me, was unclear that it referred to the DER encoded certificate. I think this should be clarified, or at least mentioned that PKIX-formatted certificates MUST be DER encoded for use in TLSA records. This makes it immediately clear how the certificates from the TLS session should be treated without reading RFC 5280. Regards, Pieter Lexis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPK84nAAoJELPqGO5ebd4jGdwQAJj/o6f1UMnyWEIFpyoBmdVu bmx6xkIMEuQLC1Hk1NIQILm4k3L9vrLEKo00Vg/P3D0a6umcCFW8WDGLhJaPjRX2 0lbNrkf14RQA9I34dl014K20W/hXwzLWJChWNAeRSFABn93jQFy9GWIU5EDGVbb3 3Dl550Lj3VdooHwoqD+OyjmzB+yDzR3NB4XutOcqwy8yeRpO63ZGF3HPen6O+lHT LbmsGiJ6ZyHR5dH9sGipS7wSae+fPLZzI2l6vY4nIlLx4YdGymN+jAZALmhifaCB CH5dN4IS2fG6bBJ9egp4pTELKEQx7Z46+IwGo43ROJM59oLLuvR2XxaV7tSwIEL2 Ifm40PNnyGtOTz2Qrsar1h475G3uL5fJmE5YOmsrkwamVsq3NWUiQO5rjJwIzgEw F6y3YdaeKihTSl3H0fjnXlf+5T0F+vRQq3FI+/4PBVBGS3tP91nFcwPUeu2bky/7 3Zl+h2c7R1qGKRWxwO+CLAQZ48VrPuRP5IqgJdTwC5gFxMkTgFQbhWpG1x7v/cFb pgsH4MTXBfGahd1G/eA+XwIFRerMlxREbwrsY1eWa0rJqWuKSmImpEksBbBQau36 /R48JnINKlcM3VuzNbkMFOxKDGM2zpTG7lZ3vpibmTxr6CfRcUIE79uPsL2S2A1f 15VufT2+sQZYhNim0dmf =a4EB -----END PGP SIGNATURE----- From rbarnes@bbn.com Fri Feb 3 05:22:34 2012 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 3E92321F84E4 for ; Fri, 3 Feb 2012 05:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyuwo55yxrgF for ; Fri, 3 Feb 2012 05:22:33 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BD0FD21F84E2 for ; Fri, 3 Feb 2012 05:22:33 -0800 (PST) Received: from [128.89.254.103] (port=55302 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RtJ60-000N8p-Jp; Fri, 03 Feb 2012 08:22:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F2BCE2C.7030505@os3.nl> Date: Fri, 3 Feb 2012 08:22:31 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5E27B826-FA10-48BB-ABD4-D9FA0C54C1B7@bbn.com> References: <4F2BCE2C.7030505@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Specifying the certificate encoding in the spec 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 Feb 2012 13:22:34 -0000 > I think this should be clarified, or at least mentioned that > PKIX-formatted certificates MUST be DER encoded for use in TLSA records. +1 This seems like the correct phrasing to me. --Richard From paul.hoffman@vpnc.org Fri Feb 3 07:00:21 2012 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 CFD9C21F859E for ; Fri, 3 Feb 2012 07:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko4tZy6GcQZl for ; Fri, 3 Feb 2012 07:00:21 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6283C21F85A1 for ; Fri, 3 Feb 2012 07:00:21 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q13F0GLH098253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Feb 2012 08:00:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F2BCE2C.7030505@os3.nl> Date: Fri, 3 Feb 2012 07:00:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <307E923E-D773-476F-8092-A8FE9559900F@vpnc.org> References: <4F2BCE2C.7030505@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Specifying the certificate encoding in the spec 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 Feb 2012 15:00:21 -0000 On Feb 3, 2012, at 4:08 AM, Pieter Lexis wrote: > I think this should be clarified, or at least mentioned that > PKIX-formatted certificates MUST be DER encoded for use in TLSA = records. I believe we removed it because it was considered redundant. What other = encoding do you believe PKIX-formatted certificates might appear in? --Paul Hoffman From rbarnes@bbn.com Fri Feb 3 07:41:58 2012 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 8EAC121F8607 for ; Fri, 3 Feb 2012 07:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.29 X-Spam-Level: X-Spam-Status: No, score=-106.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIeetv-Hv0jZ for ; Fri, 3 Feb 2012 07:41:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1048921F8605 for ; Fri, 3 Feb 2012 07:41:58 -0800 (PST) Received: from ros-dhcp192-1-51-87.bbn.com ([192.1.51.87]:55665) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RtLGt-000FMh-MK; Fri, 03 Feb 2012 10:41:55 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <307E923E-D773-476F-8092-A8FE9559900F@vpnc.org> Date: Fri, 3 Feb 2012 10:41:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <81A1B62F-DEC7-4EEC-92E5-3835BF30CCE8@bbn.com> References: <4F2BCE2C.7030505@os3.nl> <307E923E-D773-476F-8092-A8FE9559900F@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] Specifying the certificate encoding in the spec 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 Feb 2012 15:41:58 -0000 Well, for example PEM. rbarnes$ man x509 X509(1) OpenSSL = X509(1) NAME x509 - Certificate display and signing utility SYNOPSIS openssl x509 [-inform DER|PEM|NET] [-outform DER|PEM|NET] = [-keyform DER|PEM] ... On Feb 3, 2012, at 10:00 AM, Paul Hoffman wrote: > On Feb 3, 2012, at 4:08 AM, Pieter Lexis wrote: >=20 >> I think this should be clarified, or at least mentioned that >> PKIX-formatted certificates MUST be DER encoded for use in TLSA = records. >=20 >=20 > I believe we removed it because it was considered redundant. What = other encoding do you believe PKIX-formatted certificates might appear = in? >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Fri Feb 3 07:48:57 2012 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 9606121F8539 for ; Fri, 3 Feb 2012 07:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3T-eogroK4Z for ; Fri, 3 Feb 2012 07:48:57 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3621F8545 for ; Fri, 3 Feb 2012 07:48:57 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q13Fmd9O000324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 Feb 2012 08:48:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <81A1B62F-DEC7-4EEC-92E5-3835BF30CCE8@bbn.com> Date: Fri, 3 Feb 2012 07:48:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6E8E5996-93C6-45C2-8910-363D58E28447@vpnc.org> References: <4F2BCE2C.7030505@os3.nl> <307E923E-D773-476F-8092-A8FE9559900F@vpnc.org> <81A1B62F-DEC7-4EEC-92E5-3835BF30CCE8@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] Specifying the certificate encoding in the spec 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 Feb 2012 15:48:57 -0000 > Well, for example PEM. You mean "PEM in ASCII". (PEM itself is actually binary, but people have = forgotten that...) Good point, worth adding back to the draft. --Paul Hoffman From pieter.lexis@os3.nl Fri Feb 3 08:20:52 2012 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 EAC1E21F8503 for ; Fri, 3 Feb 2012 08:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF4uKxVO7gcs for ; Fri, 3 Feb 2012 08:20:52 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 196F221F84FB for ; Fri, 3 Feb 2012 08:20:52 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id F2D0117AA59 for ; Fri, 3 Feb 2012 17:20:50 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:2826:f0f9:394e:f61b] (unknown [IPv6:2001:980:5dd1:1:2826:f0f9:394e:f61b]) by smtp.os3.nl (Postfix) with ESMTPSA id CCC4B17AA2A for ; Fri, 3 Feb 2012 17:20:50 +0100 (CET) Message-ID: <4F2C0961.5040305@os3.nl> Date: Fri, 03 Feb 2012 17:20:49 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <4F2BCE2C.7030505@os3.nl> <307E923E-D773-476F-8092-A8FE9559900F@vpnc.org> <81A1B62F-DEC7-4EEC-92E5-3835BF30CCE8@bbn.com> <6E8E5996-93C6-45C2-8910-363D58E28447@vpnc.org> In-Reply-To: <6E8E5996-93C6-45C2-8910-363D58E28447@vpnc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Specifying the certificate encoding in the spec 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 Feb 2012 16:20:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/03/2012 04:48 PM, Paul Hoffman wrote: >> Well, for example PEM. Exactly. > Good point, worth adding back to the draft. Good, it'll be easier for implementers :). Regards, Pieter Lexis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPLAlSAAoJELPqGO5ebd4joHwP+wbjnQj+fxBfa2iouy3JbhyX 43dR29bKNUs1auWS+2Jn3T3fHdB/YdRJLBYxQk3TMA8CGxKR2seX3thrihjy6pAc DzH9ktukreaHCcakXiHD3gmzmWBmATm+e6I02dYCKB+X/HdJpNB5qgLPFmQT3XBI cs/eSYFNix9XaTFCjX/t6tiG6W2N2fZwVgHr3GtnN59Azngui1xWlmDEWUwBoDs3 b92b/HSVszPH3QcmpEdlTF9U1DOzETo0njTa7KLI1ZinwcCrZZCbwZNNZNIl/4GP BCk+7ytEz0cLZKXtG+n66vZ1nxg/swCg0W3iRGfySRbyg1Qh3eSkWqslj+PfxwIn VgNzl7dJ7YUmVYpg0hWZPKDc9L9m/JA6dav8NCPmycyad8uUIRjOZzdQIDrHPXqt wQY74BlPWEZXgieTqdLulha3jzGWOj6uAK9xhRS5HF8VQH9/bheQIFNxhYwpO0Wz Fa5dMxhwe/HhYsDtyAJgDAdHn0Usc3xcFA3qKGcOkUR3Wvb4FBJM/lxJjNXhgXr7 iRNFHLkpgdSV3LpgxY9OhS+IE3v2IibWrVmooQ/DncGMY/vqAa7En4zcXpmmq/K4 hcYRjXHGUpJCNdF5TdVVq4oE0/T9No/80dsn+OrdUKBO/EZsfRqWcBPSuLjF4Z5X QJ8YTM5uEWZ3wMIjqzIh =4ZqU -----END PGP SIGNATURE----- From internet-drafts@ietf.org Sat Feb 4 00:19:26 2012 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 31A0F21F854A; Sat, 4 Feb 2012 00:19:26 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE9runziyQWH; Sat, 4 Feb 2012 00:19:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A26021F853C; Sat, 4 Feb 2012 00:19:08 -0800 (PST) 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.64p1 Message-ID: <20120204081908.991.65784.idtracker@ietfa.amsl.com> Date: Sat, 04 Feb 2012 00:19:08 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 08:19:26 -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-15.txt Pages : 27 Date : 2012-02-04 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-15.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-15.txt From jakob@kirei.se Sat Feb 4 00:36:42 2012 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 BC6AB21F85E6 for ; Sat, 4 Feb 2012 00:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohj4hYm5sX6N for ; Sat, 4 Feb 2012 00:36:42 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE2E21F85E3 for ; Sat, 4 Feb 2012 00:36:41 -0800 (PST) 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=z0w22F44kQI3/HpnNOqw1u/6rVDM3hP69b+pVUbcIc8=; b=uffctXpQuu83N8T57C1uxnWKLKziWoLTsIgv/NSCmI5qHP3u2GNt0ycCsmIfSa/55BkIn0IfrAltM QzMoJAYe9sHxlTRozbWEDI7XMa5PtGswH2hw943OcrD/L8ah84xhwcDus6svAiynTpBI3xNHQx2Scx EPD1UQtTQJILH9BY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Sat, 4 Feb 2012 09:36:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Jakob Schlyter In-Reply-To: <20120204081908.991.65784.idtracker@ietfa.amsl.com> Date: Sat, 4 Feb 2012 09:36:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 08:36:42 -0000 On 4 feb 2012, at 09:19, internet-drafts@ietf.org wrote: > 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. >=20 > Title : Using Secure DNS to Associate Certificates = with Domain Names For TLS > Author(s) : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-protocol-15.txt > Pages : 27 > Date : 2012-02-04 The new version includes, in addition to minor editorial changes, the = following updates: - "Certificate for Association" is now "Certificate Association Data" - Added usage type 3; "The target certificate MUST match the TLSA = record" - Text regarding on how to handle weak algorithms - Text regarding protocol-specific specifications - Expanded "TLSA and DANE Use Cases and Requirements" - Updated "Operational Considerations for Deploying TLSA Records" - New sections on "Securing the Last Hop" and "Handling Certificate = Rollover" - Updated psuedo-code With these changes, we believe the draft is ready for WGLC. Jakob & Paul From pieter.lexis@os3.nl Sat Feb 4 03:19:41 2012 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 2324B21F851A for ; Sat, 4 Feb 2012 03:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abwoydihlxov for ; Sat, 4 Feb 2012 03:19:40 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 20EA421F851B for ; Sat, 4 Feb 2012 03:19:39 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 8374C17AA23 for ; Sat, 4 Feb 2012 12:19:38 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:dd14:5768:6004:6e1a] (unknown [IPv6:2001:980:5dd1:1:dd14:5768:6004:6e1a]) by smtp.os3.nl (Postfix) with ESMTPSA id 0379117AA18 for ; Sat, 4 Feb 2012 12:19:37 +0100 (CET) Message-ID: <4F2D1448.9090302@os3.nl> Date: Sat, 04 Feb 2012 12:19:36 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> In-Reply-To: <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 11:19:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/04/2012 09:36 AM, Jakob Schlyter wrote: > With these changes, we believe the draft is ready for WGLC. I had a quick read, looks good. I'll give a more thorough reading today. But I did notice a mistake in the examples in section A.2.1.: sub6.example.com. IN AAAA 2001:db8::1/32 One does not note the subnet of an IPv6 address in the AAAA record. As per RFC 3596: 2.4 Textual format of AAAA records The textual representation of the data portion of the AAAA resource record used in a master database file is the textual representation of an IPv6 address as defined in [3]. Reference 3 leads to RFC 3513 this is obsoleted by RFC 4291, this RFC does not (section 2.2) add prefixes to the text representation of an IPv6 address. Could you strip off the /32's from all the examples? Regards, Pieter Lexis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPLRREAAoJELPqGO5ebd4jmIgP/2IHKUlgYdNZ8YnvhAW2m5Bn tZn0LktYR23I9qE/AfSeP6FRLFtxDK3YaNDvMscHwZSPiozRC2/vQ6RRvBBlvJP9 0QtWxW2c0kQ7/g8Zyc7LO0VvZ/i+S4b3bMGPm2v4yGhjwDx7R0i641YsFJd4iBZF O92czzRweISeYZiGIlOzsDSNpBzakKHFIT/TRGN5gUFSFGuOcBLgxaFl/VwQZzdH YSv45wIF0GZEh0sUxI7TsLBNAF9vlq5L3lndM29p3n2n0lJ83/w9RCmszkMfcvno BOyZRDD15je5l4jelNYtAQ60GorqwQ1hnbrIY4LycSu7TCbvkMd5+NpBe3eKES8S J5QimxD2t+enbca4jqpUx6uToWN4u+C0twYZCuyPNns9FkJo5G9WzTzt9D0FQw9I s+IUz2g2P2LZyirOpitz+xuzKc5logvIWuVLWe/VN4GQAAuIomtzbhD2pKyXiKpL QK4TipKPVORiF+NRFJUm+hpJGJVRxW6SQSaN4Di+WyyeoAe3Iy5nVjIBNw1bRVkx A1pfhqcEOCcWFsIFxnP8EbSaY6oZzqiQev2N8TdQwFy16IJlmcx6H8l9HsBFPXCa GFj4gctXhvEtDUTEO7jY8wNzuS6m1rdRnLL/TeF/AgqsR6kEEyY0nIG1/KAio2Wf Q+hXQIfk5VBWArzOVW31 =V8Ye -----END PGP SIGNATURE----- From jakob@kirei.se Sat Feb 4 04:22:21 2012 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 B3FCF21F84B9 for ; Sat, 4 Feb 2012 04:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-OQw+JEXvLN for ; Sat, 4 Feb 2012 04:22:20 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1E921F84B5 for ; Sat, 4 Feb 2012 04:22:19 -0800 (PST) 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=0CjqKdbtztPhYyn9CfcFQ9oaoHF6SHuW4zx/mgpYtKo=; b=HrZQKrnpsiNmdbWT8YAF+VXfYYnyeHLSgdqKMzr4OwRS/0d1u357YqVA/4IMEEPc8TDao5xsCpkxH aaSOqyQusZSJhyPD6IVzMQe5/NOa0JLwWMcZ0ae6MJ2Fe/OiVSYrA+CDmg0quOXNB4o3unj5YUqFWJ 1Kt56VzOi1UIt22w= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 4 Feb 2012 13:22:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4F2D1448.9090302@os3.nl> Date: Sat, 4 Feb 2012 13:22:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <824ED3C3-EBB2-446B-84EF-67A6F27A28CF@kirei.se> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <4F2D1448.9090302@os3.nl> To: Pieter Lexis X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 12:22:21 -0000 On 4 feb 2012, at 12:19, Pieter Lexis wrote: > sub6.example.com. IN AAAA 2001:db8::1/32 'svn blame' tells me this was my bad, apparently a copy'n'paste problem = - fixed in the next rev. Thanks! jakob From paul.hoffman@vpnc.org Sat Feb 4 07:06:58 2012 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 D69D221F851C for ; Sat, 4 Feb 2012 07:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A69V1yZhVJsT for ; Sat, 4 Feb 2012 07:06:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 675A721F84E1 for ; Sat, 4 Feb 2012 07:06:58 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q14F6uum043475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Feb 2012 08:06:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> Date: Sat, 4 Feb 2012 07:06:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6A46DC07-8E1F-41FC-BDAA-69574354CB3C@vpnc.org> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> To: Jakob Schlyter X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 15:06:58 -0000 On Feb 4, 2012, at 12:36 AM, Jakob Schlyter wrote: > With these changes, we believe the draft is ready for WGLC. Indeed. We think that all the closed issues have at least been = addressed. It is up to the chairs to decide which issues get reopened in = WG LC, but Jakob and I are happy to continue to make the changes that = the WG wants. Because there were a bunch of issues closed in this round, we would = appreciate people taking a good look at what we changed. Jakob gave the = descriptive list, I'll just do the mechanical and point to the diffs: = . --Paul Hoffman From pieter.lexis@os3.nl Sat Feb 4 11:53:21 2012 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 AAB3F21F84A2 for ; Sat, 4 Feb 2012 11:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F622m02Q2qS7 for ; Sat, 4 Feb 2012 11:53:20 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id B93E221F8499 for ; Sat, 4 Feb 2012 11:53:20 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id A646D17AA16 for ; Sat, 4 Feb 2012 20:53:19 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:bd04:b1c3:34f8:eca] (unknown [IPv6:2001:980:5dd1:1:bd04:b1c3:34f8:eca]) by smtp.os3.nl (Postfix) with ESMTPSA id 4957E17AA0A for ; Sat, 4 Feb 2012 20:53:19 +0100 (CET) Message-ID: <4F2D8CAE.90702@os3.nl> Date: Sat, 04 Feb 2012 20:53:18 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] swede updated to reflect changes introduced in draft 15 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 Feb 2012 19:53:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I've updated swede[0] to support the latest draft. Basically adding usage 3 to its repertoire. Get it at github or as a tarball[1] I've also have created a TLS service with an associated usage 3 record, check it out at dane.kiev.practicum.os3.nl, TCP/1523. While I was busy doing that, I also added a usage 2 record and service for the same hostname on TCP/1522. This record describes a private CA certificate. Cheers and have a good weekend, Pieter 0 - https://github.com/pieterlexis/swede 1 - https://github.com/pieterlexis/swede/tarball/master -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPLYyrAAoJELPqGO5ebd4jfMAP/ijBxwCxvNiJXkS9GzijdJjD 6Wrpq6acHotK0WAGE1Zits+8tayEU8yvlrV9s3pv6Cw7eW9G/itfuGRM48lNR12+ xZADvtK2yP8S80TWtNjmnS91jDwR3zJH2MrLgl5/8Vs/RdFVPfXMVQOR3az8dIri QgphjxmuFDTLplZDsOWgX4mavWrVYnX0GWMjD3l/NHY6m/8acYDwZfYUEHgCOUNJ 7dlVrR9NCEPvecsCVgv//Va9cCvqBhho4p1d8VOpQ4PfDiuUf3dPiTcEEnhbn6zx uxorF9GrdBqbQL9XH8FcDyLzgTXoieG+sNASiUwNz7gUCnmXCRWFRC/1A+yhkbhD ++VzB/4x5p165xm8S77KL51vD7+cd4hW5p1n+JI8/FERxr9yXdx+/nHwrxfGxBfo EdUht8U+IRIL9s/tXHGvetfGdyRUDbZjdtLcaKgXR+u3eTk5qVH3Rjs1FPguy3P+ kO/O/76/QCShky3oRKsMK5I1tKFwXqubUBg8zimNOdX+kFu0BDC9+w1GVzKzWC7q xfPvDTTImqkJT9sBSI0N1skYiFdEhkCDTl2gGPZQcp1sXxluGOwqkkFWFckzQ9QH xmjSN41KaU3o3M8qFy3nJhLeZW4wa9bxCsLHp2FzYMo4uvv1/qRYdMFG1w8/jsqd itNG0z4hMPY8WAaS2Os6 =j4Hp -----END PGP SIGNATURE----- From peter@palfrader.org Sat Feb 4 13:03:51 2012 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 818E721F84E1 for ; Sat, 4 Feb 2012 13:03:51 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9xKca-VfQal for ; Sat, 4 Feb 2012 13:03:50 -0800 (PST) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEFA21F84DF for ; Sat, 4 Feb 2012 13:03:50 -0800 (PST) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 8590210E7FD; Sat, 4 Feb 2012 22:03:48 +0100 (CET) Date: Sat, 4 Feb 2012 22:03:48 +0100 From: Peter Palfrader To: Jakob Schlyter Message-ID: <20120204210348.GL7691@anguilla.noreply.org> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 21:03:51 -0000 On Sam, 04 Feb 2012, Jakob Schlyter wrote: > On 4 feb 2012, at 09:19, internet-drafts@ietf.org wrote: > > > 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 : Using Secure DNS to Associate Certificates with Domain Names For TLS > > Author(s) : Paul Hoffman > > Jakob Schlyter > > Filename : draft-ietf-dane-protocol-15.txt | 2.1.2. The Selector Field | | A one-octet value, called "selector", specifying what the association | data will be matched against from the TLS certificate presented by | the server. I'm not sure that sentence is very readable or clear. I'm also a bit confused about what it selects from where. It seems, from reading the pseudo code, that it selects from the cert (chains) provided by the server. It doesn't select from the association data. If so, how about this: } A one-octet value, called "selector", specifying what data of a } TLS certificate in the chain presented by the server will be matched } against the certificate association data field. Also: | 2.1.4. The Certificate Association Data Field | | The "certificate association data" to be matched. The field contains | the bytes to be matched or the hash of the bytes to be matched. The | field contains the bytes to be matched: the raw data, for matching | type 0, or the hash of the raw data, for matching types 1 and 2. The | data refers to the certificate in the association, not to the TLS | ASN.1 Certificate object. The second and third sentences here might be a bit confusing. Maybe: } The "certificate association data" to be matched. This field contains } the data to be matched. These bytes are either raw data (e.g full } certificate or its SubjectPublicKeyInfo depending on selector) for } matching type 0, or the hash of the raw data for matching types 1 and 2. } The data refers to [..] This also spells out that the matching data contains the raw SubjectPublicKeyInfo for selector type 0. Cheers, Peter -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From paul.hoffman@vpnc.org Sat Feb 4 13:55:08 2012 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 CFF1221F84F4 for ; Sat, 4 Feb 2012 13:55:08 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGZubqVciA-r for ; Sat, 4 Feb 2012 13:55:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28621F84F2 for ; Sat, 4 Feb 2012 13:55:08 -0800 (PST) Received: from [10.224.131.209] (m330f36d0.tmodns.net [208.54.15.51]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q14Lt5MZ055894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Feb 2012 14:55:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120204210348.GL7691@anguilla.noreply.org> Date: Sat, 4 Feb 2012 13:55:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <81B5C700-44E6-4373-A77F-0536B6F0A8D0@vpnc.org> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120204210348.GL7691@anguilla.noreply.org> To: Peter Palfrader X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 21:55:08 -0000 On Feb 4, 2012, at 1:03 PM, Peter Palfrader wrote: > On Sam, 04 Feb 2012, Jakob Schlyter wrote: >=20 >> On 4 feb 2012, at 09:19, internet-drafts@ietf.org wrote: >>=20 >>> 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. >>>=20 >>> Title : Using Secure DNS to Associate Certificates = with Domain Names For TLS >>> Author(s) : Paul Hoffman >>> Jakob Schlyter >>> Filename : draft-ietf-dane-protocol-15.txt >=20 >=20 > | 2.1.2. The Selector Field > |=20 > | A one-octet value, called "selector", specifying what the = association > | data will be matched against from the TLS certificate presented = by > | the server. >=20 > I'm not sure that sentence is very readable or clear. =20 Jakob took responsibility for the last one, I'll take it for this one. = It's not clear. New text: A one-octet value, called "selector", specifying which part of the = association data and the TLS certificate presented by the server will be matched. > | 2.1.4. The Certificate Association Data Field > |=20 > | The "certificate association data" to be matched. The field = contains > | the bytes to be matched or the hash of the bytes to be matched. = The > | field contains the bytes to be matched: the raw data, for = matching > | type 0, or the hash of the raw data, for matching types 1 and 2. = The > | data refers to the certificate in the association, not to the TLS > | ASN.1 Certificate object. >=20 > The second and third sentences here might be a bit confusing. Maybe: >=20 > } The "certificate association data" to be matched. This field = contains > } the data to be matched. These bytes are either raw data (e.g full > } certificate or its SubjectPublicKeyInfo depending on selector) for > } matching type 0, or the hash of the raw data for matching types 1 = and 2. > } The data refers to [..] >=20 > This also spells out that the matching data contains the raw > SubjectPublicKeyInfo for selector type 0. That is clearer, yes. Thanks! --Paul Hoffman From cloos@jhcloos.com Sat Feb 4 14:04:21 2012 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 C133521F8471 for ; Sat, 4 Feb 2012 14:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRrCATj7Zl3N for ; Sat, 4 Feb 2012 14:04:21 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id DB11C21F841C for ; Sat, 4 Feb 2012 14:04:20 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 79848400A4; Sat, 4 Feb 2012 22:03:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328393057; bh=gU3NoaDrThRSr2cRLMCOHLxDTfXJlKcwcU5SlM8ghaI=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=YoRtauMI5bZilNnHo0/9XHWzJr/sgggRXDDEAKNr1oJTRLBrKLijkRvsTuNT5QuNu XoNwwtFEy5bKTkQo8ftPnuAvpgQqVWPeqbKNDDqk+zHAzbTUpoVZ8dR3SrFqjKfdPN izYRxKbBJKPaXb/Uj8NXV0WbZlFPrn6iE5w6/C9Y= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C948936004C; Sat, 4 Feb 2012 22:01:23 +0000 (UTC) From: James Cloos To: dane@ietf.org User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 04 Feb 2012 17:01:23 -0500 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120204:dane@ietf.org::f8HIsK3uJF0Rk5MS:000xJUNr Subject: [dane] Draft 15 test page 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 Feb 2012 22:04:21 -0000 I put up a simple test page at: https://jhcloos.com/dane/ with a supporting draft-15 TLSA RR at _443._tcp.jhcloos.com. I used Pieter Lexis’ swede¹ to generate the RR. My version of powerdns lacks the two recent fixes in svn needed to properly support the recent drafts, but I massaged the data to fit what the current release requires in order accurately to serve the newer style RR. A verified dig of the RR: :; dig _443._tcp.jhcloos.com. TYPE65468 +tcp +dnssec matches what swede generated. The next release of powerdns should work out of the box. -JimC 1] https://github.com/pieterlexis/swede -- James Cloos OpenPGP: 1024D/ED7DAEA6 From pieter.lexis@os3.nl Sat Feb 4 14:07:50 2012 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 CD15A21F847D for ; Sat, 4 Feb 2012 14:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP0dRbe4krDY for ; Sat, 4 Feb 2012 14:07:50 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 1106E21F8471 for ; Sat, 4 Feb 2012 14:07:50 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 7501F17AA0A for ; Sat, 4 Feb 2012 23:07:49 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:79f6:fbb:1b4e:84a0] (unknown [IPv6:2001:980:5dd1:1:79f6:fbb:1b4e:84a0]) by smtp.os3.nl (Postfix) with ESMTPSA id 0A7E417A9FF for ; Sat, 4 Feb 2012 23:07:48 +0100 (CET) Message-ID: <4F2DAC33.90105@os3.nl> Date: Sat, 04 Feb 2012 23:07:47 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120204210348.GL7691@anguilla.noreply.org> <81B5C700-44E6-4373-A77F-0536B6F0A8D0@vpnc.org> In-Reply-To: <81B5C700-44E6-4373-A77F-0536B6F0A8D0@vpnc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 22:07:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi On 02/04/2012 10:55 PM, Paul Hoffman wrote: > A one-octet value, called "selector", specifying which part of the association data > and the TLS certificate presented by the server will be matched. I think the following is clearer: ==== A one-octet value, called "selector", specifying which part of the TLS certificate presented by the server will be matched against the association data. ==== This eliminates the word 'part' in relation to the association data. As the full association data must be matched against a part of the certificate. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPLawwAAoJELPqGO5ebd4jtN4P/29c275D7ebIqsP+jOHsTb1+ m5a5+HdClpOoHuGAOVqfQKecTWpAKWsajEKiPDWE5BKcPFQDILVAThnTRvrg1+bJ gtnuxF6WbWpBzDI2OId5W4puy88p0E4lY8fE0tHAAzZWamZsmfuZD1tn6FfomHSN O6pYG9hS1pTt4ttmECf0gYtrMO4ddDj9uAJOMwjJIFHY5kPPZN4eZpUpMM2YZZzo Exli2zmLZ0w9KJbAdwMEfcOvr7EGDzOnxnZBuFrg7j9THbsSlylm4SvGmP12f671 HI4yPTvJ3uDxK8hPWJkE+KST5dKmPrgGYOtlK9UFGK2XvUbJUaCHDkFOVXer6KjV ckKMCoHLu1gZoKPihN6TKLlcIk1IKQumT6LCZ7gvP6wWY8+K5LSZxCxGidb24oac O61Vw90YLaS+ba8Lt8E28GtKZ3eC5pSNSVbcOhxaTAx689tKT/9DdeTS6RWMT+it rll97VogfC9l8fgWec0R3HAgTony8Mdd8wMa1RwP/hbmW8FCauVrbFophcRc8vLm 6t1GgM1FmQ8r1Qb8U75JDkU5ZDdckUAbqoSQ/Mrus2dpujgd5zzRuz8dy5T1z7T2 mFGOkzptwwhYSVRfIM4nFIrjCaeANjjJny2oYbNC3Xe5kzzz7b3wc8ifh71Lxe1T xoXdbBVTUixdRbpHh9DM =0OXY -----END PGP SIGNATURE----- From cloos@jhcloos.com Sat Feb 4 14:18:41 2012 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 0C82A21F84EC for ; Sat, 4 Feb 2012 14:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k29qhOYWCm-M for ; Sat, 4 Feb 2012 14:18:40 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 3736B21F8440 for ; Sat, 4 Feb 2012 14:18:40 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 861674019E; Sat, 4 Feb 2012 22:18:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328393919; bh=LQn/bEFGjSRGVJ2WMp3QWK4kwWRgB1ErkZLy6KAPxFw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=l7qSVGckJQYLDZq7lEBBG63RT5Jq0xKbClSyZLUhx2GWo8GEXByyBvQCDK9pHiZJR pGpQbhD0oOx2QWQCXCG1IMvQRWlenW+HZq1EOdy8KfgdoW39DwkiOsUJbr3TUxIWqm c2hSYe7f4VMOBwsgfadnIxIcf0yHWjAm2gY17vCg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id E266236004C; Sat, 4 Feb 2012 22:06:00 +0000 (UTC) From: James Cloos To: IETF DANE WG list In-Reply-To: <20120204210348.GL7691@anguilla.noreply.org> (Peter Palfrader's message of "Sat, 4 Feb 2012 22:03:48 +0100") References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120204210348.GL7691@anguilla.noreply.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 04 Feb 2012 17:06:00 -0500 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120204:dane@ietf.org::j4TNkT5laSMWKIGe:00041dfw X-Hashcash: 1:30:120204:peter@palfrader.org::jj+oU+CdNYUrh0Lj:000000000000000000000000000000000000000000NIRd X-Hashcash: 1:30:120204:jakob@kirei.se::HEh62TlrwONrsSEJ:00njDOd Cc: Peter Palfrader Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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: Sat, 04 Feb 2012 22:18:41 -0000 >>>>> "PP" == Peter Palfrader writes: Grammar nits: PP> } specifying what data of a TLS certificate If that is accepted, s/what data/which data/. PP> The second and third sentences here might be a bit confusing. Maybe: PP> } (e.g full certificate or its SubjectPublicKeyInfo And that should have an article: s/full/the full/. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From owens.bill@gmail.com Sun Feb 5 07:58:17 2012 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 2CD1821F8584 for ; Sun, 5 Feb 2012 07:58:17 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE0dagD5uLOu for ; Sun, 5 Feb 2012 07:58:16 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6217721F846E for ; Sun, 5 Feb 2012 07:58:16 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so3990282wgb.13 for ; Sun, 05 Feb 2012 07:58:15 -0800 (PST) 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 :content-type; bh=8Z/e+BD7SuCniVZSqtxshgMdxqe6F4D2i3P3fGhy7w4=; b=RRXrAKKzVzez7e5qqSnXAGIeJ5oQBKwLpE2++mzu8wsp2bd0ibyHj+tfJbFKySMtTD /VFMZB9w2orwSHks0YiItobzlZAaerPb4rAUkwHE0taJKjVCVcXc+ES9eLOB9HXXgKB8 7WS7OR8bsFM6YbCI6vkUYzdKnHLP7xD7DBEuI= MIME-Version: 1.0 Received: by 10.180.103.132 with SMTP id fw4mr28977714wib.3.1328457495609; Sun, 05 Feb 2012 07:58:15 -0800 (PST) Received: by 10.180.97.161 with HTTP; Sun, 5 Feb 2012 07:58:15 -0800 (PST) In-Reply-To: <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> Date: Sun, 5 Feb 2012 10:58:15 -0500 Message-ID: From: Bill Owens To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 05 Feb 2012 15:58:17 -0000 I see that there's an addition to the second paragraph in Section 9, Security Considerations; the last sentence now reads: Thus, such proxies might choose to aggressively block TLSA requests and/or responses, even though this is not a recommended practice. I'm still not sure that makes sense. Given the scenario that paragraph describes: a combination of an SSL-interrupting proxy, a filter that blocks TLSA requests or responses, and a DANE-aware, DNSSEC-validating client; I think that one of two things could happen. The blocker (whether it is the proxy server, or a firewall, or a local forwarder) could decide to simply suppress any query or response with a TLSA RRTYPE. Or it could recognize TLSA and return a fake NXDOMAIN. In the latter case, the client would be unable to authenticate the NXDOMAIN since there would be no NSEC/NSEC3 records, so the result would be marked bogus and TLS would stop. In the former case, the client would retry until its timer expired. I'm not entirely sure how that case would be handled; it isn't explicit in the draft as far as I can tell, but it certainly seems as though the effect should be to stop TLS. If not, such a simple filter would enable a downgrade attack. If that's all correct, the last sentence probably should be removed entirely from that paragraph; it should simply state that SSL proxies will no longer work in the presence of TLSA-aware clients. One additional observation might be that entities who rely on such proxies, either with self-generated or public subordinate CAs, may choose to suppress TLSA and/or DNSSEC capabilities for all devices behind the proxy in order to maintain the current mode of operation. That would be an unhappy side effect, but not an unreasonable choice from the perspective of someone who is willing to implement an SSL proxy in the first place. Bill. From i.grok@comcast.net Sun Feb 5 20:49:32 2012 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 048A021F8547 for ; Sun, 5 Feb 2012 20:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llBPqIhxCADl for ; Sun, 5 Feb 2012 20:49:31 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id BA32121F84FB for ; Sun, 5 Feb 2012 20:49:30 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id WUmw1i0091ap0As5CUpXjB; Mon, 06 Feb 2012 04:49:31 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta22.westchester.pa.mail.comcast.net with comcast id WUpV1i00f00PQ6U3iUpWlH; Mon, 06 Feb 2012 04:49:31 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q164nP8S004847 for ; Sun, 5 Feb 2012 23:49:25 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q164nPkD004846 for dane@ietf.org; Sun, 5 Feb 2012 23:49:25 -0500 Date: Sun, 5 Feb 2012 23:49:25 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120206044925.GA28811@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 06 Feb 2012 04:49:32 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 04, 2012 at 09:36:33AM +0100, Jakob Schlyter wrote: > On 4 feb 2012, at 09:19, internet-drafts@ietf.org wrote: > > 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. >=20 > The new version includes, in addition to minor editorial changes, the > following updates: In section 2.1.3: ] Because a client support for multiple hash algorithms might be ] limited, ... Grammar: s/a client/client/ or s/a client/a client's/ > - Text regarding protocol-specific specifications In section 3: ] Unless there is an protocol-specific specification that is different ] than this one, TLSA resource records are stored at a prefixed DNS ] domain name. The prefix is prepared in the following manner: Grammar: s/an protocol/a protocol/ Unless I misread the stated consensus, this draft doesn't address the result of Issue 28 at all. Warren stated this was the consensus: "use the first name that has a TLSA record". If I understand the called consensus correctly, the client should first do a lookup at the name provided to the client and if the TLSA record isn't there, check at the hostname on the right-hand side of the SRV record it's trying to connect to. Draft -15 doesn't say that at all. Assuming I'm not totally off-base in my reading of the stated consensus, here's some proposed text: | TLSA resource records are stored at a DNS domain name of the form: | | _._. | | : | The decimal representation of the port number on which a TLS- | based service is assumed to exist. This number has no leading | zeros. | | : | The protocol name of the transport on which a TLS-based service | is assumed to exist. The transport names defined for this | protocol are "tcp", "udp" and "sctp". | | : | The DNS domain name the TLSA resource record belongs to. | | The name and port to use to look up the TLSA resource record depends | on whether the protocol in use by the client uses SRV to determine | the port and address of the service. | | If SRV is not used, the client uses the domain name and port that the | client was provided (e.g., by the user and/or a well-known service | port) to generate the name for the TLSA lookup. | | For example, to request a TLSA resource record for an HTTP server | running TLS on port 443 at "www.example.com", you would use | "_443._tcp.www.example.com" in the request. To request a TLSA | resource record for an SMTP server running the STARTTLS protocol on | port 25 at "mail.example.com", you would use | "_25._tcp.mail.example.com". | | If SRV is used, the client begins with the domain name that the | client was provided (e.g., by the user) and first performs a SRV | lookup to get an list of port/target pairs sorted as specified by | RFC 2782. For each port/target the client is attempting to connect | to, the client first performs the TLSA lookup using the port and the | initial name. If that TLSA lookup returns no records, then the client | performs a lookup using the port and target name. | | For example, to request a TLSA resource record for an XMPP server | with the following SRV records: | | _xmpp-server._tcp.example.com. IN SRV 0 0 1234 xmpp.example.net. | _xmpp-server._tcp.example.com. IN SRV 1 0 5678 im.example.org. | | you would first do a TLSA lookup at "_1234._tcp.example.com". If that | returns no records, you would then do a lookup at | "_1234._tcp.xmpp.example.net". If you are unable to reach | xmpp.example.net, you would then do a TLSA lookup at | "_5678._tcp.example.com" and so on. | | Future protocol-specific specifications may specify a different | scheme for looking up TLSA records. In section 4.3: ] This usage allows a domain name administrator to specify a new trust ] anchor, such as if the domain issues its own certificates under its should be, given the use case names in RFC 6394: | This usage is sometimes referred to as "trust anchor assertion" and | allows a domain name administrator to specify ... Section 5: ] ... Clients that rely on another ] entity to perform the DNSSEC signature validation MUST use a secure ] transport between themselves and the validator. Examples of secure ] transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec ] [RFC6071]. ... Slight nit: "entity" is rather vague and could be interpreted as "software component" (such as the OS). Would "host" be a better term? > - Expanded "TLSA and DANE Use Cases and Requirements" ] The different types of certificates associations defined in TLSA are Grammar: s/certificates assocations/certificate assocations/ ] matched with various sections of [DANEUSECASES]. Three use cases I think you can cover all 4 usage types with a reference to the use cases in RFC 6394, so s/Three/The/ ] 3.3 Domain-Issued Certificates -- Implemented using certificate ] usage 3. Based on the title of section 3.3, I'd rewrite that as: | 3.3 Trust Anchor Assertion and Domain-Issued Certificates -- | Implemented using certificate usages 2 and 3, respectively. In section 8.1: ] In the following sections, "RFC Required" was chosen TLSA usages, and ] "Specification Required" for selectors and hashes, because of the ] amount of detail that is likely to be needed for implementers to ] correctly implement new usages as compared to new matching types and ] hash types. Grammar: s/chosen TLSA/chosen for TLSA/ Also, you don't need any of the commas after the first (and they made the text harder to read because it made me think it was delineating a parenthetical clause). Also, the terms used in the paragraph don't seem consistent with the rest of the draft/the registry names/itself. Should it read: | In the following sections, "RFC Required" was chosen for TLSA usages | and "Specification Required" for selectors and matching types because | of the amount of detail that is likely to be needed for implementers | to correctly implement new usages as compared to new selectors and | matching types. I'm not sure if specification required is sufficient for selectors, not because they're going to be tremendously complex, but because some could be a really bad idea, at least in some cases. Imagine I wrote up a specification for DN matching or certificate policy matching. With usages 0 & 1, that would be fine, but with usages 2 & 3, that would be very foolish. Perhaps local client policy considering that to be weak would resolve that, but it's not written that broadly. The matching type registry has a similar problem, IMHO. (What about a URI matching type?) As far as I can tell from RFC 5226, the main difference between RFC required & specification required is whether the referenced document must have IETF consensus. Spec required will be checked for interoperability, but nothing more AFAICT. I realize this may never be a problem in practice but why not strengthen the language? In section 9 (Security Considerations): The first two paragraphs talk about looking up A/AAAA records. Do we need to add SRV to that list? Or maybe we should just refer to DNS records (as there is also the issue of CNAMEs, etc). Also, the considerations include: ] Client treatment of any information included in the trust anchor is a ] matter of local policy. This specification does not mandate that ] such information be inspected or validated by the domain name ] administrator. Should this text be expanded to include usage 3? Do we want to add a paragraph reminding DNS admins that record expiration is controlled by RRSIG expiration and not TTL, so the signature period should take into account how long the domain can afford to wait for the TLSA record to expire in the event of a server key compromise. We should probably add a reminder that clients must exercise care that TAs introduced by type 2 aren't usable for validation of other TLS connections. It should probably be a MUST somewhere in the text, but I'm not sure where it would best fit. In section 11 (with the help of id nits): * draft-ietf-dane-use-cases has been published as RFC 6394 * draft-ietf-tls-rfc4347-bis has been published as RFC 6347 * Downref: Normative reference to an Informational RFC (the use cases) In section A.1: ] When creating TLSA record with certificate usage type 0 (CA Grammar: s/record/records/ ] and 1 (SubjectPublicKeyInfo). A careful choice is required because ] the different methods for building trust chains are used by different Grammar: s/because the/because/ In section A.1.1: ] o The client may not have an associated root certificate in trust ] store and instead uses a cross-certificate with an identical Grammar: s/in trust/in its trust/ HTH --=20 Scott Schmit --jRHKVT23PllUwdXP Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMjA2MDQ0OTI1WjAjBgkqhkiG9w0BCQQxFgQUt1gyw1P+ LSvcPqSqUWLQ1vE7eTEweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVdSv3DN5 TF6xuYQ90DydeQSf9odrj5Bz0pW3+wxxsa5IrxDfvi3wXPtkkAqqKNDlkKvAk7CTLtqptdBj Q0A7Vk3Nzj1XyhDm1QGLeoBkfQas66j9/SNgM9SvBYXG44ZX5+tGGCoOXk8dQC0+B793OdE+ xYWJu4Gp5eUccHAd9CLsk6ZKWahxfNJMwrye+MwOrB5nYLyaoYJYXLv/kYUstk/a0sFAC13c t4L+Y8GTVB4kWcsLTzCpAVOZ/a9Ii9LIE/3OH63i95XjKpbFm2T+SMTRFtDMjZtU/Wa+FTQL jqNovxkgVk3n/Dt6T3gagoZQQo13J7sdS8JBgdHVCvr+tw== --jRHKVT23PllUwdXP-- From paul.hoffman@vpnc.org Mon Feb 6 13:45:07 2012 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 0749911E80A3 for ; Mon, 6 Feb 2012 13:45:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpRQNuo0EFnr for ; Mon, 6 Feb 2012 13:45:05 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CD9AC11E809D for ; Mon, 6 Feb 2012 13:45:05 -0800 (PST) Received: from [192.168.11.124] ([12.239.109.3]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q16Lj1lb040294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Feb 2012 14:45:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120206044925.GA28811@odin.ulthar.us> Date: Mon, 6 Feb 2012 16:45:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <24BB67C8-5F0C-490E-822A-9A3BA3AC304B@vpnc.org> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120206044925.GA28811@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 06 Feb 2012 21:45:07 -0000 Great stuff! On Feb 5, 2012, at 11:49 PM, Scott Schmit wrote: > In section 2.1.3: > ] Because a client support for multiple hash algorithms might be > ] limited, ... >=20 > Grammar: s/a client/client/ or s/a client/a client's/ Got it. >> - Text regarding protocol-specific specifications >=20 > In section 3: > ] Unless there is an protocol-specific specification that is = different > ] than this one, TLSA resource records are stored at a prefixed DNS > ] domain name. The prefix is prepared in the following manner: >=20 > Grammar: s/an protocol/a protocol/ Got it. > Unless I misread the stated consensus, this draft doesn't address the > result of Issue 28 at all. Warren stated this was the consensus: "use > the first name that has a TLSA record". That's only half of what he said. The full text is "use the first name = that has a TLSA record, unless there is a protocol specific exception". > If I understand the called consensus correctly, the client should = first > do a lookup at the name provided to the client and if the TLSA record > isn't there, check at the hostname on the right-hand side of the SRV > record it's trying to connect to. Draft -15 doesn't say that at all. The draft doesn't say it because there needs to be a protocol-specific = exception to know when to look. That's why we added the text we did. = Given what we read from the chairs, there is only one defined "first = name", namely the one that *every* protocol starts with. Anything beyond = that needs to be specified, given that the lengthy discussion on the = list showed that there is no agreement on how to define what the = follow-up names are. > Assuming I'm not totally off-base in my reading of the stated = consensus, > here's some proposed text: >=20 > | TLSA resource records are stored at a DNS domain name of the form: > | > | _._. > | > | : > | The decimal representation of the port number on which a TLS- > | based service is assumed to exist. This number has no leading > | zeros. > | > | : > | The protocol name of the transport on which a TLS-based service > | is assumed to exist. The transport names defined for this > | protocol are "tcp", "udp" and "sctp". > | > | : > | The DNS domain name the TLSA resource record belongs to. > | > | The name and port to use to look up the TLSA resource record = depends > | on whether the protocol in use by the client uses SRV to determine > | the port and address of the service. > | > | If SRV is not used, the client uses the domain name and port that = the > | client was provided (e.g., by the user and/or a well-known service > | port) to generate the name for the TLSA lookup. > | > | For example, to request a TLSA resource record for an HTTP server > | running TLS on port 443 at "www.example.com", you would use > | "_443._tcp.www.example.com" in the request. To request a TLSA > | resource record for an SMTP server running the STARTTLS protocol on > | port 25 at "mail.example.com", you would use > | "_25._tcp.mail.example.com". > | > | If SRV is used, the client begins with the domain name that the > | client was provided (e.g., by the user) and first performs a SRV > | lookup to get an list of port/target pairs sorted as specified by > | RFC 2782. For each port/target the client is attempting to connect > | to, the client first performs the TLSA lookup using the port and = the > | initial name. If that TLSA lookup returns no records, then the = client > | performs a lookup using the port and target name. > | > | For example, to request a TLSA resource record for an XMPP server > | with the following SRV records: > | > | _xmpp-server._tcp.example.com. IN SRV 0 0 1234 xmpp.example.net. > | _xmpp-server._tcp.example.com. IN SRV 1 0 5678 im.example.org. > | > | you would first do a TLSA lookup at "_1234._tcp.example.com". If = that > | returns no records, you would then do a lookup at > | "_1234._tcp.xmpp.example.net". If you are unable to reach > | xmpp.example.net, you would then do a TLSA lookup at > | "_5678._tcp.example.com" and so on. > | > | Future protocol-specific specifications may specify a different > | scheme for looking up TLSA records. I think this is *way* beyond what the chairs asked us to do. If I'm = wrong, I'm sure we'll hear from the chairs soon enough. > In section 4.3: > ] This usage allows a domain name administrator to specify a new = trust > ] anchor, such as if the domain issues its own certificates under its >=20 > should be, given the use case names in RFC 6394: > | This usage is sometimes referred to as "trust anchor assertion" and > | allows a domain name administrator to specify ... Good call. > Section 5: > ] ... Clients that rely on = another > ] entity to perform the DNSSEC signature validation MUST use a secure > ] transport between themselves and the validator. Examples of secure > ] transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec > ] [RFC6071]. ... >=20 > Slight nit: "entity" is rather vague and could be interpreted as > "software component" (such as the OS). Would "host" be a better term? No, for the exact reason you gave: it might be an OS service. We should = not restrict this to "you need to go to another host". >> - Expanded "TLSA and DANE Use Cases and Requirements" >=20 > ] The different types of certificates associations defined in TLSA = are >=20 > Grammar: s/certificates assocations/certificate assocations/ Yep > ] matched with various sections of [DANEUSECASES]. Three use cases >=20 > I think you can cover all 4 usage types with a reference to the use > cases in RFC 6394, so s/Three/The/ >=20 > ] 3.3 Domain-Issued Certificates -- Implemented using certificate > ] usage 3. >=20 > Based on the title of section 3.3, I'd rewrite that as: > | 3.3 Trust Anchor Assertion and Domain-Issued Certificates -- > | Implemented using certificate usages 2 and 3, respectively. I like this! > In section 8.1: > ] In the following sections, "RFC Required" was chosen TLSA usages, = and > ] "Specification Required" for selectors and hashes, because of the > ] amount of detail that is likely to be needed for implementers to > ] correctly implement new usages as compared to new matching types = and > ] hash types. >=20 > Grammar: s/chosen TLSA/chosen for TLSA/ Yes. > Also, you don't need any of the commas after the first (and they made > the text harder to read because it made me think it was delineating a > parenthetical clause). I prefer the current way slightly, but if you were confused, that's good = enough. (Let's see if the RFC Editor adds them back in...) > Also, the terms used in the paragraph don't seem consistent with the > rest of the draft/the registry names/itself. Should it read: > | In the following sections, "RFC Required" was chosen for TLSA = usages > | and "Specification Required" for selectors and matching types = because > | of the amount of detail that is likely to be needed for = implementers > | to correctly implement new usages as compared to new selectors and > | matching types. Yep > I'm not sure if specification required is sufficient for selectors, = not > because they're going to be tremendously complex, but because some = could > be a really bad idea, at least in some cases. Imagine I wrote up a > specification for DN matching or certificate policy matching. With > usages 0 & 1, that would be fine, but with usages 2 & 3, that would be > very foolish. Perhaps local client policy considering that to be weak > would resolve that, but it's not written that broadly. This is a good consideration for WG LC. > The matching type registry has a similar problem, IMHO. (What about a > URI matching type?) Not sure how that would work. > As far as I can tell from RFC 5226, the main difference between RFC > required & specification required is whether the referenced document > must have IETF consensus. Spec required will be checked for > interoperability, but nothing more AFAICT. This is not correct: you can get an RFC without IETF consensus, and that = is actually called out in 5226. > I realize this may never be a problem in practice but why not = strengthen > the language? If the WG wants to change these rules, we can. It seems worth discussing = in WG LC. > In section 9 (Security Considerations): >=20 > The first two paragraphs talk about looking up A/AAAA records. Do we > need to add SRV to that list? No. > Or maybe we should just refer to DNS > records (as there is also the issue of CNAMEs, etc). No. :-) This is a morass that is specific to some applications that use TLS. The = current spec does *not* address them. (Your proposed change for issue = #28 would probably lead us to make this change.) > Also, the considerations include: > ] Client treatment of any information included in the trust anchor is = a > ] matter of local policy. This specification does not mandate that > ] such information be inspected or validated by the domain name > ] administrator. >=20 > Should this text be expanded to include usage 3? I believe not, but I would like to hear more. Usage 3 is "match", not = "match after poking at the contents", so there is no local policy about = included information. Did you think otherwise? > Do we want to add a paragraph reminding DNS admins that record > expiration is controlled by RRSIG expiration and not TTL, so the > signature period should take into account how long the domain can = afford > to wait for the TLSA record to expire in the event of a server key > compromise. This was discussed earlier, and I thought the resolution was that it is, = in fact, the TTL. The *ability to use a TLSA record* is based on the = RRSIG expiration, but the signature period of a certificate is unrelated = to that. > We should probably add a reminder that clients must exercise care that > TAs introduced by type 2 aren't usable for validation of other TLS > connections. It should probably be a MUST somewhere in the text, but = I'm > not sure where it would best fit. It's already there: "The TLS session that is to be set up MUST be for = the specific port number and transport name that was given in the TLSA = query." How would you suggest to make this stronger? > In section 11 (with the help of id nits): > * draft-ietf-dane-use-cases has been published as RFC 6394 > * draft-ietf-tls-rfc4347-bis has been published as RFC 6347 Good > * Downref: Normative reference to an Informational RFC (the use cases) I'll move the use cases down; I'm not sure why we said they were = normative for implementers. > In section A.1: > ] When creating TLSA record with certificate usage type 0 (CA > Grammar: s/record/records/ >=20 > ] and 1 (SubjectPublicKeyInfo). A careful choice is required because > ] the different methods for building trust chains are used by = different > Grammar: s/because the/because/ >=20 > In section A.1.1: > ] o The client may not have an associated root certificate in trust > ] store and instead uses a cross-certificate with an identical > Grammar: s/in trust/in its trust/ Yes, yes, and yes. > HTH Most definitely yes! --Paul Hoffman From i.grok@comcast.net Mon Feb 6 20:26:59 2012 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 4E28311E80DF for ; Mon, 6 Feb 2012 20:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bRLCRAijNaM for ; Mon, 6 Feb 2012 20:26:58 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 39C3611E8086 for ; Mon, 6 Feb 2012 20:26:58 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id WsGh1i00427AodY57sSyyd; Tue, 07 Feb 2012 04:26:58 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta19.westchester.pa.mail.comcast.net with comcast id WsSy1i00900PQ6U3fsSySv; Tue, 07 Feb 2012 04:26:58 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q174Qt5J007859 for ; Mon, 6 Feb 2012 23:26:55 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q174Qtj5007858 for dane@ietf.org; Mon, 6 Feb 2012 23:26:55 -0500 Date: Mon, 6 Feb 2012 23:26:55 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120207042655.GA5223@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120206044925.GA28811@odin.ulthar.us> <24BB67C8-5F0C-490E-822A-9A3BA3AC304B@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <24BB67C8-5F0C-490E-822A-9A3BA3AC304B@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 07 Feb 2012 04:26:59 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 06, 2012 at 04:45:01PM -0500, Paul Hoffman wrote: > Great stuff! I'm glad -- it look longer than I expected to write it all up. :) > Given what we read from the chairs, there is only one defined "first > name", namely the one that *every* protocol starts with. Anything > beyond that needs to be specified, given that the lengthy discussion > on the list showed that there is no agreement on how to define what > the follow-up names are. When I first read what he wrote, I got the same impression you have, but rereading it, I can't defend the interpretation. What you're saying would make perfect sense if what Warren wrote was "use the first name, unless there is a protocol specific exception". But he wrote "use the first name that has a TLSA record" which reads to me as "there are several names, so go through the list and take the first that has a record". Thus I ended up with the text I wrote. I welcome clarification from the chairs. (After writing that up, I hope you're right--doing TLSA with SRV the way I wrote sounds really slow, especially in the "no TLSA record" case.) Assuming that you're right and I'm reading too much into "that has a TLSA record", I'd amend my suggested text to the following: > > | TLSA resource records are stored at a DNS domain name of the form: > > | > > | _._. > > | > > | : > > | The decimal representation of the port number on which a TLS- > > | based service is assumed to exist. This number has no leading > > | zeros. > > | > > | : > > | The protocol name of the transport on which a TLS-based service > > | is assumed to exist. The transport names defined for this > > | protocol are "tcp", "udp" and "sctp". > > | > > | : > > | The DNS domain name that the client was provided (e.g., by > > | the user). > > | =20 > > | For example, to request a TLSA resource record for an HTTP server > > | running TLS on port 443 at "www.example.com", you would use > > | "_443._tcp.www.example.com" in the request. To request a TLSA > > | resource record for an SMTP server running the STARTTLS protocol on > > | port 25 at "mail.example.com", you would use > > | "_25._tcp.mail.example.com". > > | > > | Future protocol-specific specifications may provide a different > > | mechanism for looking up TLSA records. I think this is clearer than the current text. > > Section 5: > > ] ... Clients that rely on another > > ] entity to perform the DNSSEC signature validation MUST use a secure > > ] transport between themselves and the validator. Examples of secure > > ] transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec > > ] [RFC6071]. ... > >=20 > > Slight nit: "entity" is rather vague and could be interpreted as > > "software component" (such as the OS). Would "host" be a better term? >=20 > No, for the exact reason you gave: it might be an OS service. We > should not restrict this to "you need to go to another host". I think you've misread that. Are you suggesting that I MUST use TSIG, SIG(0), and/or IPsec to get validation from my OS? I could understand that requirement if I'm reaching out to another node... :) > > Also, the considerations include: > > ] Client treatment of any information included in the trust anchor is a > > ] matter of local policy. This specification does not mandate that > > ] such information be inspected or validated by the domain name > > ] administrator. > >=20 > > Should this text be expanded to include usage 3? >=20 > I believe not, but I would like to hear more. Usage 3 is "match", not > "match after poking at the contents", so there is no local policy > about included information. Did you think otherwise? Well, I hate to open what might be another can of worms, but the text doesn't actually say what to or not to validate from a usage 3 EE certificate. Should the client ignore EVERYTHING from the cert except for the SPKI when doing the key agreement (which essentially treats it like a TA), or should it check the validity period, DN, etc and just ignore the signature (treating the cert like it's really signed by the zone DNSKEY)? > > Do we want to add a paragraph reminding DNS admins that record > > expiration is controlled by RRSIG expiration and not TTL, so the > > signature period should take into account how long the domain can afford > > to wait for the TLSA record to expire in the event of a server key > > compromise. >=20 > This was discussed earlier, and I thought the resolution was that it > is, in fact, the TTL. The *ability to use a TLSA record* is based on > the RRSIG expiration, but the signature period of a certificate is > unrelated to that. Perhaps an example will make my point better: say I have a TLS cert that expires a year from now, an RRSIG that expires in two months, and a TTL that expires in one day. An operator not familiar with DNSSEC and reading the draft might end up thinking "ok, if the TLS certificate gets compromised, we just have to change the TLSA records and wait a day for all the clients to forget the old RR, and after that, the old TLS certificate is useless/harmless." However, if it's worth it to the attacker, the attacker has potentially 2 months in which to do his/her dirty work by resending the old record every time the TTL expires (and the TTL isn't even signed, so that can be faked too). Admittedly, if some of the records in the signing chain up to the root expire before then and keys are rolled, the time available to the attacker will be less. That's in the DNSSEC RFCs, but it might not hurt to remind people. (FWIW, I'm not saying that the "drop records at TTL" text is wrong, this doesn't affect that.) > It's already there: "The TLS session that is to be set up MUST be for > the specific port number and transport name that was given in the TLSA > query." How would you suggest to make this stronger? Sorry, you're absolutely right -- it wasn't in the sections that were changed, so I overlooked it. --=20 Scott Schmit --jI8keyz6grp/JLjh Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMjA3MDQyNjU1WjAjBgkqhkiG9w0BCQQxFgQU2mb3jXB5 H+yzVqwCVtdEum4aGLMweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAFvuUd+T3 PgIRw1hprCil+8gKV3qfWV9YkZdPbzv4TsjehheAMZuJYBeY/sWNn0OoxogkrRJPbgedVJCJ VmwhqqOlXRxC/nYdvU38gVUH1qszpHuhbAda6F2RJxjbxQzESUTHxEgLpFQ1CDNgZP0n35oL DLaxBOCMxRjY+UK0LU9HeTE5hNttNJYRbbVfvYaQBH/HHNadOSglTzxvqHRACt7KIUbHuYsg qvRwMDfUTjoEFZFzzyb0OlsDvmhx9lW5cAQPaChzmUpp0+BIGQCfTZ8EInqOpcwJFfoVTTk4 2x85fjYwt3kMij0a1sUwD8PeXtMSAYF2yKkvTgYXc26VCA== --jI8keyz6grp/JLjh-- From warren@kumari.net Tue Feb 7 10:29:26 2012 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 B3BC721F88BB for ; Tue, 7 Feb 2012 10:29:26 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laJ3OIBj-Q0z for ; Tue, 7 Feb 2012 10:29:25 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1621F88B7 for ; Tue, 7 Feb 2012 10:29:25 -0800 (PST) Received: from dhcp-220-207.meetings.nanog.org (dhcp-220-207.meetings.nanog.org [199.187.220.207]) by vimes.kumari.net (Postfix) with ESMTPSA id 743061B402A0; Tue, 7 Feb 2012 13:29:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20120207042655.GA5223@odin.ulthar.us> Date: Tue, 7 Feb 2012 10:29:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <930D93F3-6B2F-4221-A73C-5787E045CAFD@kumari.net> References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120206044925.GA28811@odin.ulthar.us> <24BB67C8-5F0C-490E-822A-9A3BA3AC304B@vpnc.org> <20120207042655.GA5223@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 07 Feb 2012 18:29:26 -0000 On Feb 6, 2012, at 8:26 PM, Scott Schmit wrote: > On Mon, Feb 06, 2012 at 04:45:01PM -0500, Paul Hoffman wrote: >> Great stuff! > I'm glad -- it look longer than I expected to write it all up. :) >=20 >> Given what we read from the chairs, there is only one defined "first >> name", namely the one that *every* protocol starts with. Anything >> beyond that needs to be specified, given that the lengthy discussion >> on the list showed that there is no agreement on how to define what >> the follow-up names are. >=20 > When I first read what he wrote, I got the same impression you have, = but > rereading it, I can't defend the interpretation. > What you're saying > would make perfect sense if what Warren wrote was "use the first name, > unless there is a protocol specific exception". > But he wrote "use the > first name that has a TLSA record" which reads to me as "there are > several names, so go through the list and take the first that has a > record". Your initial impression was correct, and that is what I intended to say = / how I intended to call it (and what was discussed, and what the WG = wanted).=20 I had a few option written down, and cut and pasted the wrong one. I = could *swear* I had "use the first name, unless there is a protocol = specific exception" in my buffer, but apparently I didn't=85=20 I apologize for: A: causing confusion / consternation and=20 B: wasting the WG's time... I have just reached my co-chair and confirmed that the way that we = agreed to call it is the "use the first name, unless there is a protocol = specific exception" way, and the crappy wording is completely my fault=85 I'll update the issue tracker.=20 Again, sorry for causing confusion / consternation, etc and then taking = so long to clarify / rectify=85=20 W > Thus I ended up with the text I wrote. >=20 > I welcome clarification from the chairs. (After writing that up, I = hope > you're right--doing TLSA with SRV the way I wrote sounds really slow, > especially in the "no TLSA record" case.) >=20 > Assuming that you're right and I'm reading too much into "that has a > TLSA record", I'd amend my suggested text to the following: >=20 >>> | TLSA resource records are stored at a DNS domain name of the = form: >>> | >>> | _._. >>> | >>> | : >>> | The decimal representation of the port number on which a TLS- >>> | based service is assumed to exist. This number has no = leading >>> | zeros. >>> | >>> | : >>> | The protocol name of the transport on which a TLS-based = service >>> | is assumed to exist. The transport names defined for this >>> | protocol are "tcp", "udp" and "sctp". >>> | >>> | : >>> | The DNS domain name that the client was provided (e.g., by >>> | the user). >>> | =20 >>> | For example, to request a TLSA resource record for an HTTP server >>> | running TLS on port 443 at "www.example.com", you would use >>> | "_443._tcp.www.example.com" in the request. To request a TLSA >>> | resource record for an SMTP server running the STARTTLS protocol = on >>> | port 25 at "mail.example.com", you would use >>> | "_25._tcp.mail.example.com". >>> | >>> | Future protocol-specific specifications may provide a different >>> | mechanism for looking up TLSA records. >=20 > I think this is clearer than the current text. >=20 >>> Section 5: >>> ] ... Clients that rely on = another >>> ] entity to perform the DNSSEC signature validation MUST use a = secure >>> ] transport between themselves and the validator. Examples of = secure >>> ] transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec >>> ] [RFC6071]. ... >>>=20 >>> Slight nit: "entity" is rather vague and could be interpreted as >>> "software component" (such as the OS). Would "host" be a better = term? >>=20 >> No, for the exact reason you gave: it might be an OS service. We >> should not restrict this to "you need to go to another host". >=20 > I think you've misread that. Are you suggesting that I MUST use TSIG, > SIG(0), and/or IPsec to get validation from my OS? I could understand > that requirement if I'm reaching out to another node... :) >=20 >>> Also, the considerations include: >>> ] Client treatment of any information included in the trust anchor = is a >>> ] matter of local policy. This specification does not mandate that >>> ] such information be inspected or validated by the domain name >>> ] administrator. >>>=20 >>> Should this text be expanded to include usage 3? >>=20 >> I believe not, but I would like to hear more. Usage 3 is "match", not >> "match after poking at the contents", so there is no local policy >> about included information. Did you think otherwise? >=20 > Well, I hate to open what might be another can of worms, but the text > doesn't actually say what to or not to validate from a usage 3 EE > certificate. Should the client ignore EVERYTHING from the cert except > for the SPKI when doing the key agreement (which essentially treats it > like a TA), or should it check the validity period, DN, etc and just > ignore the signature (treating the cert like it's really signed by the > zone DNSKEY)? >=20 >>> Do we want to add a paragraph reminding DNS admins that record >>> expiration is controlled by RRSIG expiration and not TTL, so the >>> signature period should take into account how long the domain can = afford >>> to wait for the TLSA record to expire in the event of a server key >>> compromise. >>=20 >> This was discussed earlier, and I thought the resolution was that it >> is, in fact, the TTL. The *ability to use a TLSA record* is based on >> the RRSIG expiration, but the signature period of a certificate is >> unrelated to that. >=20 > Perhaps an example will make my point better: say I have a TLS cert = that > expires a year from now, an RRSIG that expires in two months, and a = TTL > that expires in one day. An operator not familiar with DNSSEC and > reading the draft might end up thinking "ok, if the TLS certificate = gets > compromised, we just have to change the TLSA records and wait a day = for > all the clients to forget the old RR, and after that, the old TLS > certificate is useless/harmless." However, if it's worth it to the > attacker, the attacker has potentially 2 months in which to do his/her > dirty work by resending the old record every time the TTL expires (and > the TTL isn't even signed, so that can be faked too). Admittedly, if > some of the records in the signing chain up to the root expire before > then and keys are rolled, the time available to the attacker will be > less. >=20 > That's in the DNSSEC RFCs, but it might not hurt to remind people. >=20 > (FWIW, I'm not saying that the "drop records at TTL" text is wrong, = this > doesn't affect that.) >=20 >> It's already there: "The TLS session that is to be set up MUST be for >> the specific port number and transport name that was given in the = TLSA >> query." How would you suggest to make this stronger? >=20 > Sorry, you're absolutely right -- it wasn't in the sections that were > changed, so I overlooked it. >=20 > --=20 > Scott Schmit > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From paul.hoffman@vpnc.org Tue Feb 7 13:40:17 2012 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 1557D11E80CF for ; Tue, 7 Feb 2012 13:40:17 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIhRxKeuBC5h for ; Tue, 7 Feb 2012 13:40:16 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8274311E80B1 for ; Tue, 7 Feb 2012 13:40:16 -0800 (PST) Received: from [172.19.131.101] ([12.130.122.120]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q17Le2UD093556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Feb 2012 14:40:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <930D93F3-6B2F-4221-A73C-5787E045CAFD@kumari.net> Date: Tue, 7 Feb 2012 16:40:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> <20120206044925.GA28811@odin.ulthar.us> <24BB67C8-5F0C-490E-822A-9A3BA3AC304B@vpnc.org> <20120207042655.GA5223@odin.ulthar.us> <930D93F3-6B2F-4221-A73C-5787E045CAFD@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1251.1) Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 07 Feb 2012 21:40:17 -0000 Good to hear. Note that we *hope* that the SRV-using communities = (notably XMPP and SIP) come up with their definitions soon. Personally, = I hope they come up with the same one, but don't know enough about how = each protocol does the lookup to be sure that they should get the same = answer. --Paul Hoffman From owens.bill@gmail.com Wed Feb 8 05:12:10 2012 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 984C321F86F5 for ; Wed, 8 Feb 2012 05:12:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISpP4RH-AecL for ; Wed, 8 Feb 2012 05:12:09 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32DC121F86F4 for ; Wed, 8 Feb 2012 05:12:09 -0800 (PST) Received: by werm10 with SMTP id m10so464748wer.31 for ; Wed, 08 Feb 2012 05:12:08 -0800 (PST) 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 :content-type:content-transfer-encoding; bh=mUsljiGBG0VU8RfC2nBrl0pX/vHX9tMXZEHXOPkjvEo=; b=Wtdj3Z0Ar0zyAWd4ugyebG8hlmlIw8/JajT9USE5JL0dMNLUHORhkHb6Ffm0DkttUj LIOqqitx4fBJ+UmfalF21Me3K404w40xEJd6oX8I+b9SCSq+Gr9cfrv05r5k4uez30Cs U4NOzshRUd6QZH+s+D/mCmAOvZ+pGIlxOQCyA= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr51872647wib.3.1328706728416; Wed, 08 Feb 2012 05:12:08 -0800 (PST) Received: by 10.180.97.161 with HTTP; Wed, 8 Feb 2012 05:12:08 -0800 (PST) In-Reply-To: References: <20120204081908.991.65784.idtracker@ietfa.amsl.com> <73CB890F-7BC0-430B-A042-2842D260C3FD@kirei.se> Date: Wed, 8 Feb 2012 08:12:08 -0500 Message-ID: From: Bill Owens To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-15.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, 08 Feb 2012 13:12:10 -0000 On Sun, Feb 5, 2012 at 10:58 AM, Bill Owens wrote: > I see that there's an addition to the second paragraph in Section 9, > Security Considerations; the last sentence now reads: > > =A0 =A0Thus, such proxies might choose to aggressively block TLSA > requests and/or responses, even though this is not a recommended > practice. I came across another perspective on this problem while reading up on Chrome's implementation of "HTTPS pins" What about MITM proxies, Fiddler etc? There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues. Personally I think that's a very bad compromise, but I wonder whether the pressures that led to this decision would cause them to reach the same conclusion with respect to DANE? Bill. From internet-drafts@ietf.org Wed Feb 8 06:56:10 2012 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 BDE5721F86F5; Wed, 8 Feb 2012 06:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZgTBaB4XzYo; Wed, 8 Feb 2012 06:56:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112121F86C3; Wed, 8 Feb 2012 06:55:49 -0800 (PST) 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.64p1 Message-ID: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 06:55:49 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 08 Feb 2012 14:56:10 -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-16.txt Pages : 27 Date : 2012-02-08 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-16.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-16.txt From paul.hoffman@vpnc.org Wed Feb 8 07:03:41 2012 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 4A03221F8546 for ; Wed, 8 Feb 2012 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urQh8F4YzpOT for ; Wed, 8 Feb 2012 07:03:40 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33621F85D0 for ; Wed, 8 Feb 2012 07:03:40 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q18F3cLA031343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 8 Feb 2012 08:03:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> Date: Wed, 8 Feb 2012 07:03:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 08 Feb 2012 15:03:41 -0000 While we are waiting to see if the WG chairs want to move the document = to WG LC, y'all have been prolific with your editorial reviews. Here's a = new draft with those editorial fixes. --Paul Hoffman From peter@palfrader.org Wed Feb 8 08:00:07 2012 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 B535821F85DD for ; Wed, 8 Feb 2012 08:00:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrMMLJpUH8g7 for ; Wed, 8 Feb 2012 08:00:06 -0800 (PST) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6721F85B9 for ; Wed, 8 Feb 2012 08:00:05 -0800 (PST) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id 2723D10E689; Wed, 8 Feb 2012 17:00:03 +0100 (CET) Date: Wed, 8 Feb 2012 17:00:03 +0100 From: Peter Palfrader To: Paul Hoffman Message-ID: <20120208160003.GA17629@anguilla.noreply.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 08 Feb 2012 16:00:08 -0000 On Wed, 08 Feb 2012, Paul Hoffman wrote: > While we are waiting to see if the WG chairs want to move the document > to WG LC, y'all have been prolific with your editorial reviews. Here's > a new draft with those editorial fixes. Just two or three nits: | 1.1. Certificate Associations | | A certificate association is formed from a piece of information | identifying a certificate with the domain name where the data is | found. I'm not a native speaker, but should this be s/with/and/? An association is something that combines two things. Therfore, you form an association from A _and_ B, thereby associating A _with_ B. Should it be 'a domain name' instead of 'the domain name'? Which data is found at the domain name? | The data used to identify the certificate consists of either | a PKIX certificate or a hash of a PKIX certificate. The data used to identify a certificate can be other things too, like a hash of its public key, as we later specify. How about: } The data used to identify the certificate can be for example a PKIX } certificate or a hash of a PKIX certificate. | 4.3. Pass PKIX Validation and Use Trust Anchor | | Certificate usage 2 is used to specify a certificate, or the public | key of such a certificate, that must be used as a trust anchor when | validating the end entity certificate given by the server in TLS. | This usage is sometimes referred to as "trust anchor assertion" and | allows a domain name administrator to specify a new trust anchor, | such as if the domain issues its own certificates under its own CA | that is not expected to be in the end users collection of trust | anchors. I stumbled over the "such as if". Maybe replace with something else like "for example if" or "useful when". Also, "the end users collection" is missing a possessive apostrophe. | 9. Security Considerations [ssl proxy mitm] | The client, seeing the proxy's new certificate | for the supposed destination will not set up a TLS session. Thus, | such proxies might choose to aggressively block TLSA requests and/or | responses, even though this is not a recommended practice. That last sentences doesn't make any sense. If the proxy blocks TLSA requests then the dnssec status will be bogus, preventing TLS entirely. (Now that I mention this, I realize this has already been pointed out by Bill Owens recently.) Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From paul.hoffman@vpnc.org Wed Feb 8 09:25:03 2012 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 C4CE621E8011 for ; Wed, 8 Feb 2012 09:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHSaGukQOQ2Z for ; Wed, 8 Feb 2012 09:25:03 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49BB221F8710 for ; Wed, 8 Feb 2012 09:24:58 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q18HOtV9037913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Feb 2012 10:24:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120208160003.GA17629@anguilla.noreply.org> Date: Wed, 8 Feb 2012 09:24:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> To: Peter Palfrader X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 08 Feb 2012 17:25:03 -0000 On Feb 8, 2012, at 8:00 AM, Peter Palfrader wrote: > On Wed, 08 Feb 2012, Paul Hoffman wrote: >=20 >> While we are waiting to see if the WG chairs want to move the = document >> to WG LC, y'all have been prolific with your editorial reviews. = Here's >> a new draft with those editorial fixes. >=20 > Just two or three nits: But good ones! >=20 > | 1.1. Certificate Associations Man, this whole paragraph has gotten stale without anyone noticing. > |=20 > | A certificate association is formed from a piece of information > | identifying a certificate with the domain name where the data is > | found. >=20 > I'm not a native speaker, but should this be s/with/and/? An > association is something that combines two things. Therfore, you form > an association from A _and_ B, thereby associating A _with_ B. Yes, "and". > Should it be 'a domain name' instead of 'the domain name'? "The" is correct because it the data is found at one domain name. > Which data is found at the domain name? Good catch. >=20 > | The data used to identify the certificate consists of = either > | a PKIX certificate or a hash of a PKIX certificate. >=20 > The data used to identify a certificate can be other things too, like = a hash > of its public key, as we later specify. How about: >=20 > } The data used to identify the certificate can be for example a PKIX > } certificate or a hash of a PKIX certificate. Actually, I'd rather just remove the sentence; it doesn't add anything = to this introductory text. In fact, neither does the next one. Really, = all we want to be describing is the high-level idea of a certificate = association; the real definition is in the body. How about: A certificate association is formed from a piece of information = identifying a certificate (such as the contents of the certificate or a trust anchor = to which the certificate chains) and the domain name where the data is = found. This document only applies to PKIX = certificates, not certificates of other formats. > | 4.3. Pass PKIX Validation and Use Trust Anchor > |=20 > | Certificate usage 2 is used to specify a certificate, or the = public > | key of such a certificate, that must be used as a trust anchor = when > | validating the end entity certificate given by the server in TLS. >=20 > | This usage is sometimes referred to as "trust anchor assertion" = and > | allows a domain name administrator to specify a new trust anchor, > | such as if the domain issues its own certificates under its own = CA > | that is not expected to be in the end users collection of trust > | anchors. >=20 > I stumbled over the "such as if". Maybe replace with something else = like > "for example if" or "useful when". >=20 > Also, "the end users collection" is missing a possessive apostrophe. Yep. > | 9. Security Considerations > [ssl proxy mitm] > | The client, seeing the proxy's new = certificate > | for the supposed destination will not set up a TLS session. = Thus, > | such proxies might choose to aggressively block TLSA requests = and/or > | responses, even though this is not a recommended practice. >=20 > That last sentences doesn't make any sense. If the proxy blocks TLSA > requests then the dnssec status will be bogus, preventing TLS = entirely. > (Now that I mention this, I realize this has already been pointed out = by > Bill Owens recently.) This is a substantiative issue, one that should be dealt with in WG LC. --Paul Hoffman From cloos@jhcloos.com Wed Feb 8 11:40:45 2012 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 2B7F011E809A for ; Wed, 8 Feb 2012 11:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NTUiQ7J9Xzr for ; Wed, 8 Feb 2012 11:40:44 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5311E8094 for ; Wed, 8 Feb 2012 11:40:44 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 3775C401BE; Wed, 8 Feb 2012 19:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328730042; bh=fPlSJAnhdSvWsH/BF2u1trn9AD3cO80Ceu9qiIM0mZI=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CRRijNtSuZJdAzoV+JhUexhs4GMREF4+2+Dp0JcE3zuV9fuv/vo0dEDTaK+uTjcXW 1LZwqSJj5Gxt9+5l5nwYW5YrzKo5nSW3AIO6AGadJfLuA5pVufi7l6WiHhByTrBrej fN45aAkhzjUBR5UwpETDpoRvLZDJyQXVjJUitPKw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id CA69636004B; Wed, 8 Feb 2012 19:39:56 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Wed, 08 Feb 2012 06:55:49 -0800") References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Wed, 08 Feb 2012 14:39:56 -0500 Message-ID: Lines: 54 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120208:dane@ietf.org::q9obAMoSXSE2PO60:0000GvZi Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 08 Feb 2012 19:40:45 -0000 nits (based on a diff -U1 15 16): > [RFC6394] lists the ones that the protocol in this document is > meant to apply to. Don't dangle prepositions. Make it: [RFC6394] lists the ones to which the protocol in this document is meant to apply. The earlier post was correct that "such as if" needs revision. I beleive that: > Clients that validate the DNSSEC signatures themselves should be: Clients which validate the DNSSEC signatures themselves (These are /nits/ after all. :) While: > The client may not have an associated root certificate in its > trust store is properly grammatical (is that redundant?), I wonder whether some readers will confuse "may" and "MAY"? If so, s/may/might/ ought to avoid that confusion. (Notice ought instead of should. :) (A recent thread on another ietf list grew out of a complaint about using miniscule may/should/shall et al.) > certificate I1 that directly signed end entity certificate S1 > of server s/of server/of the server/, yes? And in the same paragraph: > Such association would not suffer s/Such association/Such an association/ Given that §A.2.2. Provisioning with NS Records still says "THIS SECTION NEEDS TO BE WRITTEN OR REMOVED.", what exactly is it supposed to be about? "Provisioning with NS Records" doesn't say much. Unless it was to be about putting TLSA RRs in the parent zone with the NS and DS RRs??? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul.hoffman@vpnc.org Wed Feb 8 12:26:59 2012 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 B247D21F8531 for ; Wed, 8 Feb 2012 12:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePjDObguiy1z for ; Wed, 8 Feb 2012 12:26:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E60021F8565 for ; Wed, 8 Feb 2012 12:26:59 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q18KQwri049616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Feb 2012 13:26:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Wed, 8 Feb 2012 12:26:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6FEF43EF-1B69-4775-AE74-1326C628D81C@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> To: James Cloos X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: [dane] The missing section 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 Feb 2012 20:26:59 -0000 On Feb 8, 2012, at 11:39 AM, James Cloos wrote: > Given that =A7A.2.2. Provisioning with NS Records still says "THIS > SECTION NEEDS TO BE WRITTEN OR REMOVED.", what exactly is it supposed > to be about? "Provisioning with NS Records" doesn't say much. Unless > it was to be about putting TLSA RRs in the parent zone with the NS and > DS RRs??? To be honest, I don't remember. If the person who suggested this section = can refresh our memory, that would be great. It would be even better if = they proposed text for it. --Paul Hoffman From warren@kumari.net Wed Feb 8 12:28:07 2012 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 4E3EF21F8533 for ; Wed, 8 Feb 2012 12:28:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GMLuhjsnsQ8 for ; Wed, 8 Feb 2012 12:28:06 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B9AB021F8527 for ; Wed, 8 Feb 2012 12:28:06 -0800 (PST) Received: from dhcp-220-207.meetings.nanog.org (dhcp-220-207.meetings.nanog.org [199.187.220.207]) by vimes.kumari.net (Postfix) with ESMTPSA id 4A7BD1B402A0 for ; Wed, 8 Feb 2012 15:28:06 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Feb 2012 12:28:02 -0800 Message-Id: To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 20:28:07 -0000 Hello WG, Firstly I would like to remind the Working Group about the IETF IRP = rules, and once again draw the WG's attention to the IETF Note Well ( = http://www.ietf.org/about/note-well.html ) and RFC 5378 and RFC 3979 = (updated by RFC 4879). I understand that most of the participants in = this WG are long-time participants, and are already very familiar with = the IRP rules, but please take a moment again to consider if there is = anything that you need to / should have disclosed. Phew. We are kicking off WGLC for the protocol doc -- draft-ietf-dane-protocol = ( http://tools.ietf.org/html/draft-ietf-dane-protocol-16 ) and will end = on Feb 23rd at 00:00UTC. This has been our primary document for a long time, and we have all been = working towards getting it done / done right. The contents of the draft = has been arrived at largely by using the IETF Issues Tracker to track = the issues, the discussions and then the consensus. This provides us a = great resource to understand how we got to where we are, so, during = WGLC, before raising concerns / issues, please have a look if this was = already opened and discussed, and how / why we ended where we did. I = guess, this is another way of saying, please don't reopen issues that we = have already achieved consensus on. Just because the consensus wasn't = what you wanted it to be, doesn't mean it's wrong :-P We wish to (again) thank the WG for all of your hard work and = willingness to discuss and listen to other folk's viewpoint. We would = also like to thank the WG for helping us chairs to learn from this = experience (I'm not sure *what* we learnt, but=85:-P )=20 W -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From zack.weinberg@gmail.com Wed Feb 8 12:39:56 2012 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 05ECE11E809A for ; Wed, 8 Feb 2012 12:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x1U9dL7FSJW for ; Wed, 8 Feb 2012 12:39:55 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6281321F85B9 for ; Wed, 8 Feb 2012 12:39:55 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1536503obb.31 for ; Wed, 08 Feb 2012 12:39:49 -0800 (PST) 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 :content-transfer-encoding; bh=lwHQvV+WC2XerIzvrOqwiQ+vN34ZOrRtVPhiGNz6bK8=; b=FUxgZNuJrdvmZX2A11wNzW5YsGxId0nF13tpXkKLf8lvAXG769JTyk1VkqfVIj18Go PYXVB3sKr70SHc2cyaiQUQwpkZDk+LjaeKgLdHy3GD9O02uLQiSk2VUCoos6jCG3OOnR dT59gBNsMUKI2CqbCr0mL/y4cV36QPFLsWZnA= MIME-Version: 1.0 Received: by 10.182.109.106 with SMTP id hr10mr27482491obb.27.1328733589767; Wed, 08 Feb 2012 12:39:49 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Wed, 8 Feb 2012 12:39:49 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> Date: Wed, 8 Feb 2012 12:39:49 -0800 X-Google-Sender-Auth: ZNe4qNF_r-eyH6UeeiDVMZ77p6A Message-ID: From: Zack Weinberg To: James Cloos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 08 Feb 2012 20:39:56 -0000 On Wed, Feb 8, 2012 at 11:39 AM, James Cloos wrote: > nits (based on a diff -U1 15 16): > >> [RFC6394] lists the ones that the protocol in this document is >> meant to apply to. > > Don't dangle prepositions. =C2=A0Make it: > > =C2=A0[RFC6394] lists the ones to which the protocol in this document > =C2=A0is meant to apply. This is the sort of nonsense up with which one should not put. "Don't end a sentence with a preposition" is a completely bogus rule, made up in the 19th century by grammarians who thought Latin was the acme of languages, so if you couldn't do something in Latin it ought not be allowed in English either. Actual writers of actual English have been using sentence-final prepositions all the way back to _Beowulf_. Forcing prepositions to precede something often ruins the flow of the sentence, and your revision is an excellent example of that. zw From pieter.lexis@os3.nl Thu Feb 9 01:31:24 2012 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 C1BE421F86B7 for ; Thu, 9 Feb 2012 01:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRNOGhX-hBiF for ; Thu, 9 Feb 2012 01:31:15 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8FF21F863C for ; Thu, 9 Feb 2012 01:31:08 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 266C317AA3F for ; Thu, 9 Feb 2012 10:31:06 +0100 (CET) Received: from [145.92.30.156] (156.030.092.145.hva.nl [145.92.30.156]) by smtp.os3.nl (Postfix) with ESMTPSA id DB9B017AA2F for ; Thu, 9 Feb 2012 10:31:05 +0100 (CET) Message-ID: <4F339259.1000601@os3.nl> Date: Thu, 09 Feb 2012 10:31:05 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: dane@ietf.org References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> In-Reply-To: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 09 Feb 2012 09:31:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/08/2012 03:55 PM, internet-drafts@ietf.org wrote: > 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. I was hoping that the term "Pass PKIX Validation" would have some clarification (hopefully I'm not kicking the hornets' nest here). When I google the term[0], I get some 300 results. When I search for the phrase without the word 'DANE'[1] I get 1 result (a comment in a shibboleth source file). I suggest adding something like the following text to section 2.1.1.: ====== The term 'to pass PKIX validation' in this document refers to the successful building (or traversing) of the PKIX certificate chain using the algorithm described in [RFC 5280] ====== This way there is imho no question about what it means. - -- Pieter 0 - https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22 1 - https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22+-DANE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPM5JUAAoJELPqGO5ebd4jgGIP/0C4BQQaT6l04qWxsptNte/b WtYciZZ2do/hYmo/7HT7mM09TNt4FBD1cTV6/OvtA1zFfDuGsgbJX5GLsJTA9JfX aTPQa5pjCAKoaeTw2MQOsfioSKu8c5MULnGYb6rc9MdAeYsO3Sbyf6VI5hfCv67j 9iqQAlbqGIpFk8CBbiQeSaxT7SCgDcwjF8ZMQWHT2OTi6l/l4YTcRhmtwjBQlP9g c6qTeVxUIp8BTh+551HRyeFH7zaKV6kiUdd1wKtvvXIKSuUXXJwb3raSvTFMJsCb oHpcRuiREp8RZnVG5G80XHJkoN6WeWJBxyBLRmxD6lAJN9rkLIZp7YKvKaOxjzpU uhzKj0PtpURRrm4QMwvXp/SIFLEjRvJFFlIhydoHHKqoMsdnb+KynfWiIM+WwK6z 4yzvmRak6yGNcUg3mH4NAienX84IVvZW+M7VPhYXQMt22kr+1W9dZ1jtHyW9fnoQ EuR6ufcGa4od1eXDhSf3W5zf/JxXRQEshcLRSQhM1vAeIxtOSVAiMYqx+ulBhh10 xqLCtMB9wlgS0AzObPZh4SuHoct287KwZr7kXqor/raJmO0iUokTCRZ8QrD7s6Vg ly2yZn+8pTLunSMm3fkN60mlfARlQq9xdL137g81H09ZARK0vYgfcBbEgi2K0kso B7keJ+Lwwz71JysnBvUh =t5Dn -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Thu Feb 9 07:02:56 2012 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 27AEF21F85D5 for ; Thu, 9 Feb 2012 07:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xZ9sbKr+Ljn for ; Thu, 9 Feb 2012 07:02:55 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3943621F85C9 for ; Thu, 9 Feb 2012 07:02:55 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q19F2rlV090281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Feb 2012 08:02:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F339259.1000601@os3.nl> Date: Thu, 9 Feb 2012 07:02:52 -0800 Content-Transfer-Encoding: 7bit Message-Id: <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: [dane] WG Last Call item: PKIX validation 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 Feb 2012 15:02:56 -0000 On Feb 9, 2012, at 1:31 AM, Pieter Lexis wrote: > I was hoping that the term "Pass PKIX Validation" would have some > clarification (hopefully I'm not kicking the hornets' nest here). I believe it is a hornets' nest that was already kicked by many, yes. > When I google the term[0], I get some 300 results. When I search for the > phrase without the word 'DANE'[1] I get 1 result (a comment in a > shibboleth source file). > > I suggest adding something like the following text to section 2.1.1.: > ====== > The term 'to pass PKIX validation' in this document refers to the > successful building (or traversing) of the PKIX certificate chain using > the algorithm described in [RFC 5280] > ====== > > This way there is imho no question about what it means. > > - -- > Pieter > > 0 - https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22 > 1 - > https://encrypted.google.com/search?q=%22Pass%20PKIX%20validation%22+-DANE Are others happy with this formulation? --Paul Hoffman From zack.weinberg@gmail.com Thu Feb 9 07:50:33 2012 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 B116B21F86CA for ; Thu, 9 Feb 2012 07:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRi6yC2BP8mZ for ; Thu, 9 Feb 2012 07:50:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E55B421F86C6 for ; Thu, 9 Feb 2012 07:50:32 -0800 (PST) Received: by iagf6 with SMTP id f6so3253053iag.31 for ; Thu, 09 Feb 2012 07:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FcGShCopgYsNiEXQNNDq2SyN/VbQMUiOzAQ3wudqrDg=; b=ca67HoYuunGmddgq7ug0ReqftGtGRU6RmkxoXfnhnxqEhdp7Go23DRKdZkJSSiK94N SPYAhxF5B28Gwgtk4Q1hMshmhqap5uM3Vf0NDpbTlUht42yyw5SFjAAt+29oD7gbzt7/ vikXl/di8XX25nIbePczWDKVnZx8DIkygPn30= Received: by 10.42.144.196 with SMTP id c4mr3235171icv.39.1328802632603; Thu, 09 Feb 2012 07:50:32 -0800 (PST) Received: from ardsley.local (99-113-33-155.lightspeed.sntcca.sbcglobal.net. [99.113.33.155]) by mx.google.com with ESMTPS id ng9sm4639176igc.3.2012.02.09.07.50.31 (version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 07:50:31 -0800 (PST) Sender: Zack Weinberg Message-ID: <4F33EB47.9030107@panix.com> Date: Thu, 09 Feb 2012 07:50:31 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Hoffman , IETF DANE WG list References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> In-Reply-To: <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Feb 2012 07:51:48 -0800 Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 15:50:33 -0000 On 2012-02-09 7:02 AM, Paul Hoffman wrote: > On Feb 9, 2012, at 1:31 AM, Pieter Lexis wrote: >> ====== >> The term 'to pass PKIX validation' in this document refers to the >> successful building (or traversing) of the PKIX certificate chain using >> the algorithm described in [RFC 5280] > > Are others happy with this formulation? No, but you knew that. I promised to file an issue on this and I really will get to it either today or tomorrow. From paul.hoffman@vpnc.org Thu Feb 9 08:37:43 2012 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 B177A21F854D for ; Thu, 9 Feb 2012 08:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKQU8rYWmqQ2 for ; Thu, 9 Feb 2012 08:37:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E045521F8517 for ; Thu, 9 Feb 2012 08:37:42 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q19GbeKE094509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Feb 2012 09:37:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F33EB47.9030107@panix.com> Date: Thu, 9 Feb 2012 08:37:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> To: Zack Weinberg X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 16:37:43 -0000 On Feb 9, 2012, at 7:50 AM, Zack Weinberg wrote: > No, but you knew that. We should not assume anything. > I promised to file an issue on this and I really will get to it either = today or tomorrow. Instead of filing an issue, consider sending proposed alternate text = that says exactly what you want the document to say. --Paul Hoffman From ogud@ogud.com Thu Feb 9 11:42:33 2012 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 0B2D021F8484 for ; Thu, 9 Feb 2012 11:42:33 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ArUxolH657F for ; Thu, 9 Feb 2012 11:42:31 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6A13421F8496 for ; Thu, 9 Feb 2012 11:42:31 -0800 (PST) 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 q19JgFRF076852 for ; Thu, 9 Feb 2012 14:42:16 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F342197.3020207@ogud.com> Date: Thu, 09 Feb 2012 14:42:15 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 19:42:33 -0000 On 08/02/2012 15:28, Warren Kumari wrote: > Hello WG, > > > We are kicking off WGLC for the protocol doc -- draft-ietf-dane-protocol ( http://tools.ietf.org/html/draft-ietf-dane-protocol-16 ) and will end on Feb 23rd at 00:00UTC. I have reviewed the document and I'm impressed with the quality of the doucument, the editors have done a GREAT job producing this readable document. I support that the document be advanced, below are few minor nits that need attention: Section 2.1.3 Old: Because clients' support for multiple hash algorithms might be limited, it is advisable to use the same hash algorithm for the matching type as is used for the signature in the certificate. Doing so will increase the likelihood of interoperability. This reads like a the long way around using an RFC2119 word: Proposed new text: It is RECOMMENDED that TLSA record use the same hash algorithm for matching time as is used for the signature of the certificate. This will assist clients that support small number of hash algorithms. Section A.2.2 Currently the text says this section needs to be written up or dropped. I looked at the issues and there are 3 different cases to consider 1. delegation at the service name " sub5.example.com NS ns1.example.net In this case the resolver will follow the delegation just like it would for example.net. 2. delegation at the protocol prefix _tcp.sub5.example.com NS ns1.example.net DNS lookup will proceed just like before, the only "gotcha" is that, _tcp.... zone MUST be signed as well, 3. Delegation at the port prefix _443._tcp.sub5.example.com NS ns1.example.net Practically Identical to case 2. So the only thing that this section needs to say is the same as when CNAME/DNAME points out of the zone: "In-order for TLSA validation to work the target DNS zone MUST be signed" Disclaimer: I did not try to understand Appendix B. Olafur From cloos@jhcloos.com Thu Feb 9 14:05:09 2012 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 4925221E8044 for ; Thu, 9 Feb 2012 14:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyDXqC5LlnEj for ; Thu, 9 Feb 2012 14:05:08 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7121E8019 for ; Thu, 9 Feb 2012 14:05:08 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 6B39D400B0; Thu, 9 Feb 2012 22:04:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328825106; bh=g538tAlMJxRs0vfhs3ya4H0GndHHx+tykLDQbXDuAoU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=pzxgvzn/Pv0ufCXLB9su29TuILTC6u2FC6s82YDFh/+EI2vamdixUZL1kTvZAnyvY dxnUfFopywsMUdLKUIf1aXWgbMqIh9l7XcqXc99qIbHLOcA28XOx0mQYMuwEQKpHNd 5cS1qdlhKEMohd9NEFeHqg5XIjS4lNobaxT6AnPU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 36D1C36004C; Thu, 9 Feb 2012 22:01:15 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <4F342197.3020207@ogud.com> (Olafur Gudmundsson's message of "Thu, 09 Feb 2012 14:42:15 -0500") References: <4F342197.3020207@ogud.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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, 09 Feb 2012 17:01:15 -0500 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120209:dane@ietf.org::VOUF5RpoYAmj3SLE:0009AVYy X-Hashcash: 1:30:120209:ogud@ogud.com::TUeDUmvPcG+50VNE:0001ZMqG Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 22:05:09 -0000 >>>>> "OG" == Olafur Gudmundsson writes: OG> Section 2.1.3 OG> Proposed new text: OG> It is RECOMMENDED that TLSA record use the same hash algorithm for OG> matching time as is used for the signature of the certificate. This OG> will assist clients that support small number of hash algorithms. Perhaps: > If the TLSA record's Matching Type uses a hash, It is RECOMMENDED that > it use the same hash algorithm which was used for the signature in the > certificate. This will assist clients which support a small number of > hash algorithms. Or maybe, for the last sentence: > This can help clients which support fewer cryptographic algorithms. But +1 on the concept of using RECOMMENDED. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ondrej.mikle@nic.cz Thu Feb 9 15:34:54 2012 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 C301321E8069 for ; Thu, 9 Feb 2012 15:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m-QVCLArB2N for ; Thu, 9 Feb 2012 15:34:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 298CD11E808A for ; Thu, 9 Feb 2012 15:34:32 -0800 (PST) Received: from localhost.localdomain (ip-94-113-3-132.net.upcbroadband.cz [94.113.3.132]) by mail.nic.cz (Postfix) with ESMTPSA id 4F4442A02D9 for ; Fri, 10 Feb 2012 00:34:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328830471; bh=GWkbBLvjA235OgOO8yBdKZwDwhhnWHVVdtZc4mm8cvo=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=jkgDlghLeZtXudY55uJAn44RkuSyv6iKDFtSA/i+Aya29JdWH0DqL7tyCE5P6IWFw /XuUEcsdPRrHblM05NC+pVlq19BETdwzQc0egEViP0exvn8yRbvUTk8QOx92/gmzF9 4RbRbTqAO7dICy6/PwUD/IQkxcapW0tW7D2m0ENA= Message-ID: <4F345806.90506@nic.cz> Date: Fri, 10 Feb 2012 00:34:30 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dane@ietf.org References: <4F342197.3020207@ogud.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 23:34:54 -0000 On 02/09/2012 11:01 PM, James Cloos wrote: >>>>>> "OG" == Olafur Gudmundsson writes: > > OG> Section 2.1.3 > OG> Proposed new text: > OG> It is RECOMMENDED that TLSA record use the same hash algorithm for > OG> matching time as is used for the signature of the certificate. This > OG> will assist clients that support small number of hash algorithms. > > Perhaps: > >> If the TLSA record's Matching Type uses a hash, It is RECOMMENDED that >> it use the same hash algorithm which was used for the signature in the >> certificate. This will assist clients which support a small number of >> hash algorithms. > > Or maybe, for the last sentence: > >> This can help clients which support fewer cryptographic algorithms. > > But +1 on the concept of using RECOMMENDED. +1 on RECOMMENDED and +1 on James's formulation ("if matching type is a hash..."). Maybe yet another formulation: If the TLSA record's Matching Type uses a hash, it is RECOMMENDED that it uses the hash algorithm as close as possible to the hash used for the signature in the certificate on a linear scale "MD2-MD5-SHA1-SHA256-SHA384-SHA512". In case of ambiguity, favor the algorithm to the right. This can help clients which support fewer cryptographic algorithms. I originally meant to add it to the "Creating TLSA records" subsection, but it may be a bit "overspecified" and a bit bumpy because of SHA-384 (and missing GOST). Ondrej From ondrej.mikle@nic.cz Fri Feb 10 05:17:44 2012 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 494F821F8572 for ; Fri, 10 Feb 2012 05:17:44 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY5zfsWkj1Eq for ; Fri, 10 Feb 2012 05:17:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68A21F8508 for ; Fri, 10 Feb 2012 05:17:43 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id 580122A2F79 for ; Fri, 10 Feb 2012 14:17:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328879861; bh=Up73uMKiVFl5dv9NyPh8H0Sbe2i9PJjqD10TkBz1g/g=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=v7bIc4Q5EeGlgQZGEqYhrIFz45lDYxbSngge2xs9pkHu8hGABXyLUt+LoA2OR++N5 CXtASz2AiSNX/D5eHqnOjjH42tAxew/2e/804linPZhGonuPazs4N12Akxp34/9OI6 dr3U/SddZ70mzBBZWw3uI6VFwCrYhjI1JAvKM0Xc= Message-ID: <4F3518B0.1030601@nic.cz> Date: Fri, 10 Feb 2012 14:16:32 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dane@ietf.org References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> In-Reply-To: <4F345806.90506@nic.cz> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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, 10 Feb 2012 13:17:44 -0000 On 02/10/2012 12:34 AM, Ondrej Mikle wrote: > On 02/09/2012 11:01 PM, James Cloos wrote: >> Perhaps: >> >>> If the TLSA record's Matching Type uses a hash, It is RECOMMENDED that >>> it use the same hash algorithm which was used for the signature in the >>> certificate. This will assist clients which support a small number of >>> hash algorithms. >> >> Or maybe, for the last sentence: >> >>> This can help clients which support fewer cryptographic algorithms. >> >> But +1 on the concept of using RECOMMENDED. > > +1 on RECOMMENDED and +1 on James's formulation ("if matching type is a hash..."). > > Maybe yet another formulation: > > If the TLSA record's Matching Type uses a hash, it is RECOMMENDED that it uses > the hash algorithm as close as possible to the hash used for the signature in > the certificate on a linear scale "MD2-MD5-SHA1-SHA256-SHA384-SHA512". In case > of ambiguity, favor the algorithm to the right. This can help clients which > support fewer cryptographic algorithms. A more readable version that could be added to "Creating TLSA records" to reference Olafur's or James's formulation of the recommendation in 2.1.3: A.1.3 Choosing a Matching Type Using a hash algorithm in matching type has a performance advantage in shorter length of a TLSA record's association data field. Expanding on the recommendation expressed in section 2.1.3, guidelines for choosing hash in matching type are as follows - when using a hash algorithm in matching type, then: o Use SHA-512 (matching type 2) if the associated certificate uses SHA-512 or SHA-384 in signature algorithm. o Use SHA-256 (matching type 1) otherwise. Ondrej Mikle From cloos@jhcloos.com Fri Feb 10 07:57:01 2012 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 0FDD621F863B for ; Fri, 10 Feb 2012 07:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33Hyypwd+AE6 for ; Fri, 10 Feb 2012 07:57:00 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4445421F862B for ; Fri, 10 Feb 2012 07:57:00 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 949EA58045; Fri, 10 Feb 2012 15:56:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328889417; bh=4GnmofyAFORqHGy5DBCU9TDGZKIaveqhHdQANUnLHhY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=gjppLu4foWNzyx1GSLUfBoWmLDXoRbpsL52xiX//g+6RvP3UWGw13WESKrQmz5uG1 QJ6TRRp3HE1VwO1B8/prKAayM4qepPytNWno2DxfAnWnLvju8KUpQgKKbiVa4OSwQZ HSYc3zCkO24i7iEoLQ5ZGmlx8tbSx/iA7L0xUjgw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7685336004B; Fri, 10 Feb 2012 15:46:41 +0000 (UTC) From: James Cloos To: Ondrej Mikle In-Reply-To: <4F3518B0.1030601@nic.cz> (Ondrej Mikle's message of "Fri, 10 Feb 2012 14:16:32 +0100") References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Fri, 10 Feb 2012 10:46:41 -0500 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120210:ondrej.mikle@nic.cz::e55VpjGbaqFJtnqb:000000000000000000000000000000000000000001uZWY X-Hashcash: 1:30:120210:dane@ietf.org::kTu1MQe0K4b5g/p1:000bT26e Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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, 10 Feb 2012 15:57:01 -0000 >>>>> "OM" == Ondrej Mikle writes: OM> A.1.3 Choosing a Matching Type OM> Using a hash algorithm in matching type has a performance advantage in OM> shorter length of a TLSA record's association data field. Expanding on OM> the recommendation expressed in section 2.1.3, guidelines for choosing OM> hash in matching type are as follows - when using a hash algorithm in OM> matching type, then: OM> o Use SHA-512 (matching type 2) if the associated certificate uses OM> SHA-512 or SHA-384 in signature algorithm. OM> o Use SHA-256 (matching type 1) otherwise. Yes, that is readable and well formulated. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ogud@ogud.com Fri Feb 10 10:21:57 2012 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 66CF521F87F8 for ; Fri, 10 Feb 2012 10:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjkhsOgUYwbH for ; Fri, 10 Feb 2012 10:21:56 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 081BE21F87F7 for ; Fri, 10 Feb 2012 10:21:54 -0800 (PST) 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 q1AILrd9085844; Fri, 10 Feb 2012 13:21:53 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F356040.8010303@ogud.com> Date: Fri, 10 Feb 2012 13:21:52 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ondrej Mikle References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> In-Reply-To: <4F3518B0.1030601@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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, 10 Feb 2012 18:21:57 -0000 On 10/02/2012 08:16, Ondrej Mikle wrote: > On 02/10/2012 12:34 AM, Ondrej Mikle wrote: >> On 02/09/2012 11:01 PM, James Cloos wrote: >>> Perhaps: >>> >>>> If the TLSA record's Matching Type uses a hash, It is RECOMMENDED that >>>> it use the same hash algorithm which was used for the signature in the >>>> certificate. This will assist clients which support a small number of >>>> hash algorithms. >>> >>> Or maybe, for the last sentence: >>> >>>> This can help clients which support fewer cryptographic algorithms. >>> >>> But +1 on the concept of using RECOMMENDED. >> >> +1 on RECOMMENDED and +1 on James's formulation ("if matching type is a hash..."). >> >> Maybe yet another formulation: >> >> If the TLSA record's Matching Type uses a hash, it is RECOMMENDED that it uses >> the hash algorithm as close as possible to the hash used for the signature in >> the certificate on a linear scale "MD2-MD5-SHA1-SHA256-SHA384-SHA512". In case >> of ambiguity, favor the algorithm to the right. This can help clients which >> support fewer cryptographic algorithms. > > A more readable version that could be added to "Creating TLSA records" > to reference Olafur's or James's formulation of the recommendation in 2.1.3: > > > A.1.3 Choosing a Matching Type > > Using a hash algorithm in matching type has a performance advantage in > shorter length of a TLSA record's association data field. Expanding on > the recommendation expressed in section 2.1.3, guidelines for choosing > hash in matching type are as follows - when using a hash algorithm in > matching type, then: > > o Use SHA-512 (matching type 2) if the associated certificate uses > SHA-512 or SHA-384 in signature algorithm. > o Use SHA-256 (matching type 1) otherwise. > Couple of questions: How does this work when SHA-3 is added as a matching type? Does the SHA-3 document have to "obsolete" this section and write a new section ? Is SHA-256 the right default ? Olafur From owens.bill@gmail.com Fri Feb 10 12:51:10 2012 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 22E5A21E8015 for ; Fri, 10 Feb 2012 12:51:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB4NE7I5vlbX for ; Fri, 10 Feb 2012 12:51:09 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB61121E8012 for ; Fri, 10 Feb 2012 12:51:08 -0800 (PST) Received: by werm10 with SMTP id m10so3044028wer.31 for ; Fri, 10 Feb 2012 12:51:07 -0800 (PST) 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 :content-type:content-transfer-encoding; bh=iHZ4jAm/X+dHTjlAPV4uuRE8iGY2MovGL3DOHQtvnFc=; b=P8uSC85YPZAsPDdJolvb0/NpAMEGGe2s9wa5adz1zWDNP9k/wR4fSnrVjPoWZAHQk+ Hi6vFR3DyJqUCZrQ9uKAAxhhZdgb5R79qYZY57ExumU0pTL8HACFZwbXhkIuZCt6/Iyh YNIh3S0GcBB4PMRnJCFJ1KtKd7JnIq6dHnQV0= MIME-Version: 1.0 Received: by 10.180.100.33 with SMTP id ev1mr14544789wib.3.1328907067832; Fri, 10 Feb 2012 12:51:07 -0800 (PST) Received: by 10.180.97.161 with HTTP; Fri, 10 Feb 2012 12:51:07 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> Date: Fri, 10 Feb 2012 15:51:07 -0500 Message-ID: From: Bill Owens To: Paul Hoffman , Peter Palfrader , IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 10 Feb 2012 20:51:10 -0000 On Wed, Feb 8, 2012 at 12:24 PM, Paul Hoffman wrote= : > On Feb 8, 2012, at 8:00 AM, Peter Palfrader wrote: > >> | 9. =A0Security Considerations >> [ssl proxy mitm] >> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The client, seeing= the proxy's new certificate >> | =A0 =A0for the supposed destination will not set up a TLS session. =A0= Thus, >> | =A0 =A0such proxies might choose to aggressively block TLSA requests a= nd/or >> | =A0 =A0responses, even though this is not a recommended practice. >> >> That last sentences doesn't make any sense. =A0If the proxy blocks TLSA >> requests then the dnssec status will be bogus, preventing TLS entirely. >> (Now that I mention this, I realize this has already been pointed out by >> Bill Owens recently.) > > > This is a substantiative issue, one that should be dealt with in WG LC. So, now that we're officially in WGLC, how should this be dealt with? Or is it the case that only Peter and I care about this language, and everyone else is satisfied with the current statement? If the discussion would be helped by looking at alternative language, I would suggest something along these lines: Proxies are sometimes configured to permit inspection of HTTPS sessions by acting as a man-in-the-middle between the TLS client and server. In this scenario, the client must first be configured with a new trust anchor whose private key is kept on the proxy. When the proxy receives an HTTPS request, it creates a new TLS session with the server, and sets up another TLS session with the client using a self-signed certificate. Since that certificate chains to the trust anchor installed in the client, the HTTPS session acts normally from the user's perspective. However, a TLSA-aware client would get a certificate association from the DNS that does not match the self-signed certificate from the SSL proxy and would abort the TLS connection. Blocking TLSA queries or responses in order to mount a downgrade attack on the TLSA protocol would be detected by the DNSSEC validator as a failure of authenticated denial of existence and result in the TLSA query being marked bogus, again leading the client to abort the TLS connection. Someone employing such a system might therefore choose to prevent the deployment of TLSA-aware clients. Developers who add TLSA capabilities to their clients might also choose to perform PKIX validation using locally-configured trust anchors first, and skip the TLSA process if the validation succeeds. The only part I'm concerned about is the assertion that the DNSSEC validation will come back bogus; I think that's true, and some simple tests in my sandbox environment seem to confirm it, but I'd like someone with more expertise to confirm it. . . Bill. From ilari.liusvaara@elisanet.fi Fri Feb 10 13:32:23 2012 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 7E5E421F844D for ; Fri, 10 Feb 2012 13:32:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdqiArmCDJ7A for ; Fri, 10 Feb 2012 13:32:22 -0800 (PST) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7310A21F8748 for ; Fri, 10 Feb 2012 13:32:22 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh01-2.mail.saunalahti.fi (Postfix) with SMTP id A5B198C6B3; Fri, 10 Feb 2012 23:32:20 +0200 (EET) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A0496EA2A07; Fri, 10 Feb 2012 23:32:20 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 2452D158A65; Fri, 10 Feb 2012 23:32:15 +0200 (EET) Date: Fri, 10 Feb 2012 23:32:16 +0200 From: Ilari Liusvaara To: Bill Owens Message-ID: <20120210213216.GA20331@LK-Perkele-VI.localdomain> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Peter Palfrader , Paul Hoffman , IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 10 Feb 2012 21:32:23 -0000 On Fri, Feb 10, 2012 at 03:51:07PM -0500, Bill Owens wrote: > > The only part I'm concerned about is the assertion that the DNSSEC > validation will come back bogus; I think that's true, and some simple > tests in my sandbox environment seem to confirm it, but I'd like > someone with more expertise to confirm it. . . Assume you don't have signing keys for the target domain nor to any parent domain: You can't generate valid signature with the right key because you don't have it. You can't send fake signature because it would be bogus. You can't substitute the key because it would not match the DS from parent or the TA for root and thus be bogus. You can't strip the DNSSEC data because the parent says it should be there. If you strip that, you need to apply this whole argument to the parent. And the root can't be stripped because it would be bogus due to presence of TA but not DNSSEC data. Thus given assumptions, there is no way to tamper with secure data without causing it to be regarded as bogus. -Ilari From owens.bill@gmail.com Fri Feb 10 13:41:26 2012 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 946E321F852E for ; Fri, 10 Feb 2012 13:41:26 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaYNGxgB4f+Q for ; Fri, 10 Feb 2012 13:41:26 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCFC821F8537 for ; Fri, 10 Feb 2012 13:41:25 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so2399707wgb.13 for ; Fri, 10 Feb 2012 13:41:24 -0800 (PST) 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=RQqFxL0a/QWP/IP9xn7CBlE30ktBt+ncUnnO/1/o5Ug=; b=QvGjhFrVSqPdrqqtTiRThd1vHI8IcUmXgOlbGQOUj5/egWYdi4XPxnlJTu5mRxwULO 68hyJH/+z2UVjQZZ1p73FCpsM9KO+//ojH13fLSIdPitea/4rNx9Uh6mAWp4VPigztW6 jdxlYHm1GJevBTM0vsedlOsp865EeriQLquCg= MIME-Version: 1.0 Received: by 10.216.131.100 with SMTP id l78mr1418853wei.44.1328910084296; Fri, 10 Feb 2012 13:41:24 -0800 (PST) Received: by 10.180.97.161 with HTTP; Fri, 10 Feb 2012 13:41:24 -0800 (PST) In-Reply-To: <20120210213216.GA20331@LK-Perkele-VI.localdomain> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <20120210213216.GA20331@LK-Perkele-VI.localdomain> Date: Fri, 10 Feb 2012 16:41:24 -0500 Message-ID: From: Bill Owens To: Ilari Liusvaara Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 10 Feb 2012 21:41:26 -0000 On Fri, Feb 10, 2012 at 4:32 PM, Ilari Liusvaara wrote: > On Fri, Feb 10, 2012 at 03:51:07PM -0500, Bill Owens wrote: >> >> The only part I'm concerned about is the assertion that the DNSSEC >> validation will come back bogus; I think that's true, and some simple >> tests in my sandbox environment seem to confirm it, but I'd like >> someone with more expertise to confirm it. . . > > Assume you don't have signing keys for the target domain > nor to any parent domain: > > > You can't generate valid signature with the right key > because you don't have it. > > You can't send fake signature because it would be bogus. > > You can't substitute the key because it would not match > the DS from parent or the TA for root and thus be bogus. > > You can't strip the DNSSEC data because the parent says it > should be there. If you strip that, you need to apply this > whole argument to the parent. And the root can't be > stripped because it would be bogus due to presence of > TA but not DNSSEC data. And you can't block or modify the response containing the TLSA record because the NSEC/NSEC3 record for that name includes TLSA in the type bitmap, and therefore the denial of existence fails, right? Likewise if you block both the TLSA and NSEC/3 records, because every record in a signed zone has to have an NSEC/3 or be proven not to exist? Bill. From paul.hoffman@vpnc.org Fri Feb 10 13:56:31 2012 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 A3CDC21F854F for ; Fri, 10 Feb 2012 13:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ill1DfDhHmv2 for ; Fri, 10 Feb 2012 13:56:31 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1290C21F854B for ; Fri, 10 Feb 2012 13:56:31 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1ALuUlW060748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 10 Feb 2012 14:56:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Fri, 10 Feb 2012 13:56:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: [dane] Security considerations for proxies 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, 10 Feb 2012 21:56:31 -0000 On Feb 10, 2012, at 12:51 PM, Bill Owens wrote: > On Wed, Feb 8, 2012 at 12:24 PM, Paul Hoffman = wrote: >> On Feb 8, 2012, at 8:00 AM, Peter Palfrader wrote: >>=20 >>> | 9. Security Considerations >>> [ssl proxy mitm] >>> | The client, seeing the proxy's new = certificate >>> | for the supposed destination will not set up a TLS session. = Thus, >>> | such proxies might choose to aggressively block TLSA requests = and/or >>> | responses, even though this is not a recommended practice. >>>=20 >>> That last sentences doesn't make any sense. If the proxy blocks = TLSA >>> requests then the dnssec status will be bogus, preventing TLS = entirely. >>> (Now that I mention this, I realize this has already been pointed = out by >>> Bill Owens recently.) >>=20 >>=20 >> This is a substantiative issue, one that should be dealt with in WG = LC. >=20 > So, now that we're officially in WGLC, how should this be dealt with? Yes, maybe even with an appropriate change to the subject line. :-) > Or is it the case that only Peter and I care about this language, and > everyone else is satisfied with the current statement? Not the case: Jakob and I care as well. > If the discussion would be helped by looking at alternative language, > I would suggest something along these lines: >=20 > Proxies are sometimes configured to permit inspection of HTTPS > sessions by acting as a man-in-the-middle between the TLS client and > server. In this scenario, the client must first be configured with a > new trust anchor whose private key is kept on the proxy. When the > proxy receives an HTTPS request, it creates a new TLS session with the > server, and sets up another TLS session with the client using a > self-signed certificate. Since that certificate chains to the trust > anchor installed in the client, the HTTPS session acts normally from > the user's perspective. However, a TLSA-aware client would get a > certificate association from the DNS that does not match the > self-signed certificate from the SSL proxy and would abort the TLS > connection. Blocking TLSA queries or responses in order to mount a > downgrade attack on the TLSA protocol would be detected by the DNSSEC > validator as a failure of authenticated denial of existence and result > in the TLSA query being marked bogus, again leading the client to > abort the TLS connection. Someone employing such a system might > therefore choose to prevent the deployment of TLSA-aware clients. > Developers who add TLSA capabilities to their clients might also > choose to perform PKIX validation using locally-configured trust > anchors first, and skip the TLSA process if the validation succeeds. >=20 >=20 > The only part I'm concerned about is the assertion that the DNSSEC > validation will come back bogus; I think that's true, and some simple > tests in my sandbox environment seem to confirm it, but I'd like > someone with more expertise to confirm it. . . --Paul Hoffman From cloos@jhcloos.com Fri Feb 10 14:29:24 2012 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 723F421F8636 for ; Fri, 10 Feb 2012 14:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo7Hy4cxQoqI for ; Fri, 10 Feb 2012 14:29:23 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 852AA21F8550 for ; Fri, 10 Feb 2012 14:29:23 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 193E5400A4; Fri, 10 Feb 2012 22:28:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1328912961; bh=HslUKytdAdCzt8+jcZ7wP5kwNkOjzIHkTlAX9xsqPXw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=cmprnR75xs4243KQfbfASP844hjdpKpXwpBJwcwf2IlVuvwRvbM8ow5S25CsSxa/r hvlimr+hewzLfELEea3YSfgbSGeS3KWBbApRobzpRInt0GGOmgrZu8d26nhTiIa4Xj AhT/y92Sq19ZEeNvAGr0wZr8sMVDNZZByieZMlLQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5EC2A36004C; Fri, 10 Feb 2012 22:11:08 +0000 (UTC) From: James Cloos To: IETF DANE WG List In-Reply-To: <20120210213216.GA20331@LK-Perkele-VI.localdomain> (Ilari Liusvaara's message of "Fri, 10 Feb 2012 23:32:16 +0200") References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <20120210213216.GA20331@LK-Perkele-VI.localdomain> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Fri, 10 Feb 2012 17:11:08 -0500 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120210:dane@ietf.org::EMYV0dJCPBbVF1Ea:000Nr1Ok X-Hashcash: 1:30:120210:ilari.liusvaara@elisanet.fi::YeFXn1Ie7loGNXn/:0000000000000000000000000000000004jKPb X-Hashcash: 1:30:120210:owens.bill@gmail.com::fq7nYsyJ0HkRXZpt:0000000000000000000000000000000000000000IXdBz X-Hashcash: 1:30:120210:peter@palfrader.org::YLFc2+sA2hqQPGCr:00000000000000000000000000000000000000000bmQyN X-Hashcash: 1:30:120210:paul.hoffman@vpnc.org::I2CT1L00VQeH8DwY:000000000000000000000000000000000000000URo97 Cc: Peter Palfrader , Paul Hoffman Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 10 Feb 2012 22:29:24 -0000 It seems that those who want to use TLS proxies and also support DANE-aware clients which are compliant with our drafts will need to fully proxy DNS, too. Just like they have to provide the inside clients with a cert to act as a root tls trust anchor, they will need to provide a DS RR for . which they control, verify the outside sigs, and re-sign everything before passing it on to the inside clients. This is, really, no different than what they already do to TLS. They also would need to do that for CMS and OpenPGP, should they care about encrypted email, too. Et cetera, und so weiter, and so on. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From zack.weinberg@gmail.com Fri Feb 10 15:20:44 2012 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 E51F921F865E for ; Fri, 10 Feb 2012 15:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpbiIjEa3lvp for ; Fri, 10 Feb 2012 15:20:42 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF721F8658 for ; Fri, 10 Feb 2012 15:20:42 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5266436obb.31 for ; Fri, 10 Feb 2012 15:20:41 -0800 (PST) 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=5E1DiCPYuBQZZ4nFWIDwLg6hRzIC07NZ69taBc5ng7M=; b=oVeqaxkVRkwr2i4I9nQqew7ShCbbLvjyK4DZV+5M6Q/noSVWp/voudLpiTAYEJBNrC 7WKPG7/5f9WiF35pZpXdfYT2LpxIKuilfPynOYwLabnB3cAOzC/THcJJVFcE2kCygFem LK/ksq/WPnAP3fBhN5dx1XEACsbdD0fH5ZtMM= MIME-Version: 1.0 Received: by 10.182.162.40 with SMTP id xx8mr5352010obb.17.1328916041641; Fri, 10 Feb 2012 15:20:41 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Fri, 10 Feb 2012 15:20:41 -0800 (PST) In-Reply-To: <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Fri, 10 Feb 2012 15:20:41 -0800 X-Google-Sender-Auth: FNrGfp_s8g3LecISRprYVNLsEW4 Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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, 10 Feb 2012 23:20:44 -0000 On Thu, Feb 9, 2012 at 8:37 AM, Paul Hoffman wrote: >> I promised to file an issue on this and I really will get to it either today or tomorrow. > > Instead of filing an issue, consider sending proposed alternate text that says exactly what you want the document to say. It is a substantive change, but sure, why not. Add to the end of section 1.1: "Three of the four types of association defined in this document ("usages") make use of a _certificate chain_, beginning with the target certificate from the TLS handshake, and ending with a _trust anchor_. This document does not specify how a DANE client constructs this chain; however, one algorithm for doing so is in [RFC5280]. Chain construction may include 'validation' checks for certificates that are ill-formed or contrary to client policy; again, this document does not specify any such checks." In section 2.1.1, change all four usage definitions to read: 0 -- The certificate chain MUST include a CA certificate which matches the TLSA record, and MUST terminate in a trust anchor already known to the client. 1 -- The target certificate MUST match the TLSA record, and the certificate chain MUST terminate in a trust anchor already known to the client. 2 -- The certificate chain MUST include a CA certificate which matches the TLSA record. This certificate MUST be treated as a valid trust anchor for that chain, for this TLS handshake only, whether or not it was already known to the client. 3 -- The target certificate MUST match the TLSA record. The client MUST accept this certificate regardless of the contents of the chain. Replace sections 4.1 through 4.4 inclusive with this text: 4.1. Chain Through CA Certificate usage 0 specifies a CA certificate, or the public key of such a certificate, that must appear in the certificate chain that the client has constructed from the target certificate in the TLS handshake. This usage is sometimes referred to as "CA constraint", because it limits which CAs may issue certificates for a given host name. 4.2. Chain From Target Certificate usage 1 specifies an end-entity certificate, or the public key of such a certificate, that must begin the certificate chain that the client constructs. This usage is sometimes referred to as "service certificate constraints", because it limits which end entity certificate may be used by a given host name. 4.3. Chain To Novel Trust Anchor Certificate usage 2 specifies a CA certificate, or the public key of such a certificate, that must appear in the certificate chain that the client constructs, and is to be treated as the trust anchor for that chain.This usage is sometimes referred to as "trust anchor assertion", because it allows a domain name administrator to specify use of a trust anchor that may not already be known to the client. 4.4. Match Target Certificate, Skip Chain Construction Certificate usage 3 specifies a certificate that must appear as the target certificate in the TLS handshake, and requires the client to accept this certificate without going through the normal process of chain construction and location of a trust anchor. However, the client SHOULD still perform any validation checks that apply to the certificate itself, rather than the chain (such as for improper name information, insufficiently large keys, or insecure hash algorithms). This usage is sometimes referred to as "domain-issued certificate", because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA. In appendix B, delete all occurrences of the string "pass PKIX validation and", change all occurrences of the string "PKIX validation chain H" to "certificate chain H". Change the first two occurrences of the string "C passes PKIX validation in H" to "H is a valid chain from C to a known trust anchor". Change the third occurrence of that string to "H is a valid chain from C to R". zw From tom@ritter.vg Fri Feb 10 16:39:53 2012 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 A757021E8018 for ; Fri, 10 Feb 2012 16:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml1a+dtROxN5 for ; Fri, 10 Feb 2012 16:39:52 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA6521F85C5 for ; Fri, 10 Feb 2012 16:39:52 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so1902956lbb.31 for ; Fri, 10 Feb 2012 16:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oPySiRD+Ss35MEh5Ad3ITgn+J4WigQNH80OUpGCRLCU=; b=g0gUPvrZAeVE5paJJKj+qCrulJv/TmoAgXtMULb6voxRpAlLhD6/zxErxuYiGtjMMb xVPEotL6KEM29YVUhRyff3uwunUqebWsy2gaDDLFPTLOI7V5HqZsUIfXDTb0xaPLpHQ2 H4NVRphnnV7eixLbqMDbEH8GM9SlOSKU0CLX0= Received: by 10.152.136.20 with SMTP id pw20mr5660330lab.32.1328920791125; Fri, 10 Feb 2012 16:39:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.11.67 with HTTP; Fri, 10 Feb 2012 16:39:31 -0800 (PST) In-Reply-To: <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> From: Tom Ritter Date: Fri, 10 Feb 2012 19:39:31 -0500 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnItKHxXKKG9PczlSkhFS+/0g0Ha51BlQqUaDQgchNpou8zt06JXt4JfXbSj/joPLwKnEKz Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 00:39:54 -0000 Chrome has key pinning working already, such that it will hard fail if the cert for gmail (for example) doesn't match what it has pinned. Same problem: the proxy shows a different cert. Chrome solves this by making any user installed cert override a pin.[1] If a TLSA-aware client _has_ a trust store, and certs can be added to it, then perhaps it can do the same: a cert that was installed manually (such as by the user for a proxy tool or a network admin for corporate use) will not hard-fail on a DANE failure. It may fail, but it must be allowed to be overridden. If a TLSA-aware client does not have a trust store, or certs may not be added to, then it's (probably) currently hard failing for the proxy in question already. If it hard fails for the cert vs DANE, not much different. -tom [1] http://www.imperialviolet.org/2011/05/04/pinning.html From ondrej.mikle@nic.cz Fri Feb 10 17:09:04 2012 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 D37CD21E801C for ; Fri, 10 Feb 2012 17:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKhoFqDIZqXr for ; Fri, 10 Feb 2012 17:09:02 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7485321F8501 for ; Fri, 10 Feb 2012 17:09:02 -0800 (PST) Received: from localhost.localdomain (ip-94-113-3-132.net.upcbroadband.cz [94.113.3.132]) by mail.nic.cz (Postfix) with ESMTPSA id 1DB262A02A5; Sat, 11 Feb 2012 02:09:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1328922540; bh=xXGLudSJLTyrkgrKyz5algOckEA82Q6PQFXjp1vcDAQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=s0x/vO+haANrLTMLtsergf8FH9Ay2agoZlyJR8Vrh/zVmQeDEpq46eMezO0XgzrM2 /5kyPhT0/Q+zwTdsNqfwjS77noDfKDTErpbjYXa7XUc6Ea1iJn0a16J/qNWUgJB2Me xWRYO4GogcmSatgfmfpauIEVPszQh3CfcWBjSx/k= Message-ID: <4F35BFAC.8050801@nic.cz> Date: Sat, 11 Feb 2012 02:09:00 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> In-Reply-To: <4F356040.8010303@ogud.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 01:09:04 -0000 On 02/10/2012 07:21 PM, Olafur Gudmundsson wrote: > On 10/02/2012 08:16, Ondrej Mikle wrote: >> On 02/10/2012 12:34 AM, Ondrej Mikle wrote: >> A more readable version that could be added to "Creating TLSA records" >> to reference Olafur's or James's formulation of the recommendation in 2.1.3: >> >> >> A.1.3 Choosing a Matching Type >> >> Using a hash algorithm in matching type has a performance advantage in >> shorter length of a TLSA record's association data field. Expanding on >> the recommendation expressed in section 2.1.3, guidelines for choosing >> hash in matching type are as follows - when using a hash algorithm in >> matching type, then: >> >> o Use SHA-512 (matching type 2) if the associated certificate uses >> SHA-512 or SHA-384 in signature algorithm. >> o Use SHA-256 (matching type 1) otherwise. >> > > Couple of questions: > How does this work when SHA-3 is added as a matching type? > Does the SHA-3 document have to "obsolete" this section and write a new section ? > > Is SHA-256 the right default ? Frankly, I don't have yet the experience as to what happens when RFC is updated. SHA-256 is likely a safe default for the nearest future. My expectation is that when SHA-3 is standardized by NIST, then the "2.1.3 Matching Type" section will be updated to include SHA-3, as well as the "A.1.3" section. Ondrej From tom@ritter.vg Fri Feb 10 17:09:32 2012 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 23B7321F8504 for ; Fri, 10 Feb 2012 17:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO64CPsZqxnd for ; Fri, 10 Feb 2012 17:09:31 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99BAE21F8503 for ; Fri, 10 Feb 2012 17:09:30 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so1909813lbb.31 for ; Fri, 10 Feb 2012 17:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=tz5viXmuOYDJ1NDe/cCVBwIZWWjn5M+Pwz+JPBdHaYA=; b=i6pEzKi1NnLxfRAO4EYQMgQZsD2BEN8XxMQtFIoRPY3Bhf5CwhPK99RXIrS8AFWrT9 QobVGbmT8tDi2MWg3dOpX/Kymlz5JBXBYWP8qgsu04FEXiZdI5aBDARs4IBtszlg51Bn s/unwGzYSj4Tn+s7IoXYhHLRwZr1CS2JrOc8s= Received: by 10.152.111.137 with SMTP id ii9mr5588239lab.39.1328922569587; Fri, 10 Feb 2012 17:09:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.11.67 with HTTP; Fri, 10 Feb 2012 17:09:09 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> From: Tom Ritter Date: Fri, 10 Feb 2012 20:09:09 -0500 Message-ID: To: Zack Weinberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn4VxnRBKt3wojzEc1JFU1Jzu+8C17UZK9iSYogPX/nx8pe1nynmbzWj9mesCxsrNoL4agL Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 01:09:32 -0000 > =A02 -- The certificate chain MUST include a CA certificate which > matches the TLSA record. This certificate MUST be treated as a valid > trust anchor for that chain, for this TLS handshake only, whether or > not it was already known to the client. I think "CA certificate" is the wrong phrase to use, because people will interpret it to mean "A certificate, for a CA I've heard of", rather than its intended definition of "A certificate that will act as a trust anchor in a chain." I propose simply removing 'CA'. > =A03 -- The target certificate MUST match the TLSA record. =A0The client > MUST accept this certificate regardless of the contents of the chain. I'm nervous about that extra statement. What if the certificate is a 384-bit RSA certificate? MUST the client accept it? 4.4 clarifies this question, noting such checks, but I still prefer the simpler "The target certificate MUST match the TLSA record." > 4.1. Chain Through CA > > =A0 Certificate usage 0 specifies a CA certificate, or the public key > =A0 of such a certificate, that must appear in the certificate chain > =A0 that the client has constructed from the target certificate in the > =A0 TLS handshake. =A0This usage is sometimes referred to as "CA > =A0 constraint", because it limits which CAs may issue certificates for > =A0 a given host name. I'd like to highlight we've changed "validation chains for the end entity certificate given by the server in TLS" to "certificate chain that the client has constructed from the target certificate in the TLS handshake". That may have repercussions, I'm not sure what they would be. I'll add the following changes in Section 8.2 Value Short description ---------------------------------------------------------- 0 Chain through & match trusted CA 1 Chain through trusted CA & match EE 2 Chain through & match certificate 3 Match certificate I'm in favor of clarifying 'Pass PKIX Validation', and I think this is a reasonable way to do it. -tom From paul.hoffman@vpnc.org Fri Feb 10 17:16:13 2012 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 BF36121F85A5 for ; Fri, 10 Feb 2012 17:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu3JQ0qMMziK for ; Fri, 10 Feb 2012 17:16:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 66B8F21F85A4 for ; Fri, 10 Feb 2012 17:16:12 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1B1G9ON067188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 10 Feb 2012 18:16:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F342197.3020207@ogud.com> Date: Fri, 10 Feb 2012 17:16:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15AE8BF1-78C3-47E9-99A7-80E9C494F9FE@vpnc.org> References: <4F342197.3020207@ogud.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 01:16:14 -0000 On Feb 9, 2012, at 11:42 AM, Olafur Gudmundsson wrote: > Section 2.1.3 > Old: > Because clients' support for multiple hash algorithms might be > limited, it is advisable to use the same hash algorithm for the > matching type as is used for the signature in the certificate. = Doing > so will increase the likelihood of interoperability. >=20 > This reads like a the long way around using an RFC2119 word: > Proposed new text: > It is RECOMMENDED that TLSA record use the same hash algorithm for = matching time as is used for the signature of the certificate. This will = assist clients that support small number of hash algorithms. SHOULDized version based on later suggestions will appear in the next = draft. > Section A.2.2 > Currently the text says this section needs to be written up or = dropped. > I looked at the issues and there are 3 different cases to consider > 1. delegation at the service name " > sub5.example.com NS ns1.example.net > In this case the resolver will follow the delegation just like > it would for example.net. >=20 > 2. delegation at the protocol prefix > _tcp.sub5.example.com NS ns1.example.net > DNS lookup will proceed just like before, the only "gotcha" is that, > _tcp.... zone MUST be signed as well, >=20 > 3. Delegation at the port prefix > _443._tcp.sub5.example.com NS ns1.example.net > Practically Identical to case 2. >=20 > So the only thing that this section needs to say is the same as when = CNAME/DNAME points out of the zone: >=20 > "In-order for TLSA validation to work the target DNS zone MUST be = signed" If that is all there is to it, I think we should just nuke the appendix, = give that we say that in the body of the text. --Paul Hoffman From zack.weinberg@gmail.com Fri Feb 10 17:19:25 2012 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 91B1A21F85A4 for ; Fri, 10 Feb 2012 17:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf8Gge-ZkcjX for ; Fri, 10 Feb 2012 17:19:25 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2BC621F8585 for ; Fri, 10 Feb 2012 17:19:24 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5373906obb.31 for ; Fri, 10 Feb 2012 17:19:24 -0800 (PST) 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 :content-transfer-encoding; bh=exYDZrqwF9X0aeP44UGIkP81A+xM8OR1JNNADpSRoWg=; b=dWjXva33nqd4mp1bpEqL/GVxnWZyavNY09D+mO+TTBW31dSgA1QJqlBo2wdPCjCOoY b+zqKAxQSfF/00zLiBEQ1eQOyPCkWrZzDxJzwil03wSbsk8guYw88NNgW4rSR6de3K2T 1jgxm3n/byh4eNTFJOvdso9IvA+lFD0CvUOC8= MIME-Version: 1.0 Received: by 10.182.162.40 with SMTP id xx8mr5573713obb.17.1328923164599; Fri, 10 Feb 2012 17:19:24 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Fri, 10 Feb 2012 17:19:24 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Fri, 10 Feb 2012 17:19:24 -0800 X-Google-Sender-Auth: ub2m39S2NnQBLZaDcm0SC77vsr8 Message-ID: From: Zack Weinberg To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 01:19:25 -0000 On Fri, Feb 10, 2012 at 5:09 PM, Tom Ritter wrote: >> =C2=A02 -- The certificate chain MUST include a CA certificate which >> matches the TLSA record. This certificate MUST be treated as a valid >> trust anchor for that chain, for this TLS handshake only, whether or >> not it was already known to the client. > > I think "CA certificate" is the wrong phrase to use, because people > will interpret it to mean "A certificate, for a CA I've heard of", > rather than its intended definition of "A certificate that will act as > a trust anchor in a chain." =C2=A0I propose simply removing 'CA'. The intent there is "CA certificate" as opposed to "end-entity certificate" in PKIXese - this is a distinction based solely on the contents of the certificate, not its position in the constructed chain. I am open to better ways to phrase this, but I think we do need the qualifier. >> =C2=A03 -- The target certificate MUST match the TLSA record. =C2=A0The = client >> MUST accept this certificate regardless of the contents of the chain. > > I'm nervous about that extra statement. =C2=A0What if the certificate is = a > 384-bit RSA certificate? =C2=A0MUST the client accept it? =C2=A04.4 clari= fies > this question, noting such checks, but I still prefer the simpler "The > target certificate MUST match the TLSA record." Good point, but with your one-sentence version I'm worried that the difference from usage 1 is insufficiently clear. How about 3 -- The target certificate MUST match the TLSA record. The client MUST skip chain construction in this case, but SHOULD still validate the certificate itself (for instance, checking for unacceptably weak keys and hash algorithms). which is a more precise cut-down of what I put in 4.4. > I'd like to highlight we've changed "validation chains for the end > entity certificate given by the server in TLS" to "certificate chain > that the client has constructed from the target certificate in the TLS > handshake". =C2=A0That may have repercussions, I'm not sure what they wou= ld > be. That was the intended consequence of this proposal, except that I didn't mean to convert plural to singular. How does "one of the certificate chains that the client has constructed ..." sound? zw From tom@ritter.vg Fri Feb 10 18:25:32 2012 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 3373921F863F for ; Fri, 10 Feb 2012 18:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZ2qYeQ2aN8c for ; Fri, 10 Feb 2012 18:25:31 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2512821E8019 for ; Fri, 10 Feb 2012 18:25:30 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so1925186lbb.31 for ; Fri, 10 Feb 2012 18:25:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=gq2wrxURNiiFfBzMAo5klaNBhH+JVOGT5oLRlDrDG48=; b=JSJoX5p3T93VTEzxQbfqqbvjcLbmSYhugLPJBrufVWXkHAaRgm1WzRP9fQ6ujcZUjc osZzSJ0bn7KZUdWirK2UCu/5WQrx3cADZmoQUW2NLydwq5e91SJn2cLqhuoB8bE7UUNn Ck5sRVuxum1eNgCOGkV+jsF//cggll0XR9mSM= Received: by 10.112.102.7 with SMTP id fk7mr2852281lbb.34.1328927130111; Fri, 10 Feb 2012 18:25:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.11.67 with HTTP; Fri, 10 Feb 2012 18:25:10 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> From: Tom Ritter Date: Fri, 10 Feb 2012 21:25:10 -0500 Message-ID: To: Zack Weinberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl2r/gdhRIc+hLnEFp99I8UpXQPXtsF7bCxnyWBSVfMPK0+MaxyzaEEoB4yhhsF/nyGF3nr Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 02:25:32 -0000 >>> =A03 -- The target certificate MUST match the TLSA record. =A0The clien= t >>> MUST accept this certificate regardless of the contents of the chain. >> >> I'm nervous about that extra statement. =A0What if the certificate is a >> 384-bit RSA certificate? =A0MUST the client accept it? =A04.4 clarifies >> this question, noting such checks, but I still prefer the simpler "The >> target certificate MUST match the TLSA record." > > Good point, but with your one-sentence version I'm worried that the > difference from usage 1 is insufficiently clear. =A0How about > > =A03 -- The target certificate MUST match the TLSA record. =A0The client > =A0MUST skip chain construction in this case, but SHOULD still validate > =A0the certificate itself (for instance, checking for unacceptably weak > =A0keys and hash algorithms). > > which is a more precise cut-down of what I put in 4.4. Fine by me. >> I'd like to highlight we've changed "validation chains for the end >> entity certificate given by the server in TLS" to "certificate chain >> that the client has constructed from the target certificate in the TLS >> handshake". =A0That may have repercussions, I'm not sure what they would >> be. > > That was the intended consequence of this proposal, except that I > didn't mean to convert plural to singular. =A0How does "one of the > certificate chains that the client has constructed ..." sound? That's fine. The other was fine with me to, I was just pointing out changing it from a chain sent by the server to a chain the client constructed. I'm not sure if that's strictly part of the 'PKIX Validaiton' removal, just point it out. -tom From zack.weinberg@gmail.com Fri Feb 10 18:37:49 2012 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 8A88A21F858D for ; Fri, 10 Feb 2012 18:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRlJRFAnQEmm for ; Fri, 10 Feb 2012 18:37:48 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBA021F858A for ; Fri, 10 Feb 2012 18:37:48 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5424085obb.31 for ; Fri, 10 Feb 2012 18:37:48 -0800 (PST) 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 :content-transfer-encoding; bh=1UARELBXFG++JnxyvBTmppcjtNkqTucHJB0c6lvkB9k=; b=bK5Q70GWPJgKcNqKu+oLvK3/PRZBGO85LG04gKCTnK9FKIq91mrIbStCUs5BkWnKWX gbp0bftZbVjYA2WgUvDBTO3cPUyR2aQUC3E3etUQB8epo7Shf+sS4ONTeTu1v1i6FH3X sHbsJb7i82bh6z2iOZCUuqUX2X9LkiuKePglI= MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr5699673obc.7.1328927867997; Fri, 10 Feb 2012 18:37:47 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Fri, 10 Feb 2012 18:37:47 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Fri, 10 Feb 2012 18:37:47 -0800 X-Google-Sender-Auth: t8UmtBbO-wn77a9x-pEyZ_Szo2g Message-ID: From: Zack Weinberg To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 02:37:49 -0000 On Fri, Feb 10, 2012 at 6:25 PM, Tom Ritter wrote: >>> I'd like to highlight we've changed "validation chains for the end >>> entity certificate given by the server in TLS" to "certificate chain >>> that the client has constructed from the target certificate in the TLS >>> handshake". =C2=A0That may have repercussions, I'm not sure what they w= ould >>> be. >> >> That was the intended consequence of this proposal, except that I >> didn't mean to convert plural to singular. =C2=A0How does "one of the >> certificate chains that the client has constructed ..." sound? > > That's fine. =C2=A0The other was fine with me to, I was just pointing out > changing it from a chain sent by the server to a chain the client > constructed. Ah. Yes, that's necessary - one of the many ways "PKIX validation" is an underspecified term is that some clients will take the chain provided by the server more-or-less as is, and some clients will rewrite it. zw From rbarnes@bbn.com Fri Feb 10 20:49:22 2012 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 7726E21F8564 for ; Fri, 10 Feb 2012 20:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RQIz7rh3FQA for ; Fri, 10 Feb 2012 20:49:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 673A521F855A for ; Fri, 10 Feb 2012 20:49:21 -0800 (PST) Received: from [128.89.254.202] (port=63667 helo=[172.20.51.161]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw4tj-0004X5-4c; Fri, 10 Feb 2012 23:49:19 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Fri, 10 Feb 2012 20:49:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 04:49:22 -0000 I have reviewed this document and think it is ready for publication. = Couple of minor editorial suggestions follow. --Richard Section 1: OLD " must trust a trust anchor upon which the server's certificate is rooted, = and must successfully validate the certificate. " NEW " must successfully validate the certificate, including chaining to a = trust anchor. " Section 4 just seems like a more verbose version of Section 2.1.1. = Propose removing to avoid confusion. Section 4.4: Domain-issued certificates are actually supported by both = usage 2 and usage 3. On Feb 8, 2012, at 12:28 PM, Warren Kumari wrote: > Hello WG, >=20 > Firstly I would like to remind the Working Group about the IETF IRP = rules, and once again draw the WG's attention to the IETF Note Well ( = http://www.ietf.org/about/note-well.html ) and RFC 5378 and RFC 3979 = (updated by RFC 4879). I understand that most of the participants in = this WG are long-time participants, and are already very familiar with = the IRP rules, but please take a moment again to consider if there is = anything that you need to / should have disclosed. >=20 > Phew. >=20 > We are kicking off WGLC for the protocol doc -- = draft-ietf-dane-protocol ( = http://tools.ietf.org/html/draft-ietf-dane-protocol-16 ) and will end on = Feb 23rd at 00:00UTC. >=20 > This has been our primary document for a long time, and we have all = been working towards getting it done / done right. The contents of the = draft has been arrived at largely by using the IETF Issues Tracker to = track the issues, the discussions and then the consensus. This provides = us a great resource to understand how we got to where we are, so, during = WGLC, before raising concerns / issues, please have a look if this was = already opened and discussed, and how / why we ended where we did. I = guess, this is another way of saying, please don't reopen issues that we = have already achieved consensus on. Just because the consensus wasn't = what you wanted it to be, doesn't mean it's wrong :-P >=20 > We wish to (again) thank the WG for all of your hard work and = willingness to discuss and listen to other folk's viewpoint. We would = also like to thank the WG for helping us chairs to learn from this = experience (I'm not sure *what* we learnt, but=85:-P )=20 >=20 > W >=20 >=20 > -- > Don't be impressed with unintelligible stuff said condescendingly. > -- Radia Perlman. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Fri Feb 10 20:58:03 2012 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 95D1121E8020 for ; Fri, 10 Feb 2012 20:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.469 X-Spam-Level: X-Spam-Status: No, score=-106.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s75Qb4IJlOPo for ; Fri, 10 Feb 2012 20:58:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 215F011E807F for ; Fri, 10 Feb 2012 20:58:03 -0800 (PST) Received: from [128.89.254.202] (port=63685 helo=[172.20.51.161]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw529-0004Yn-Eu; Fri, 10 Feb 2012 23:58:01 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 10 Feb 2012 20:58:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 04:58:03 -0000 >>> I promised to file an issue on this and I really will get to it = either today or tomorrow. >>=20 >> Instead of filing an issue, consider sending proposed alternate text = that says exactly what you want the document to say. >=20 > It is a substantive change, but sure, why not. >=20 > Add to the end of section 1.1: "Three of the four types of > association defined in this document ("usages") make use of a > _certificate chain_, beginning with the target certificate from the > TLS handshake, and ending with a _trust anchor_. This document does > not specify how a DANE client constructs this chain; however, one > algorithm for doing so is in [RFC5280]. =20 Could you clarify this citation? AFAICT, RFC 5280 defines an algorithm = for validating a certification path, not constructing one (although it = does provide some constraints). =20 In general, I do not find the modifications in the proposed text = helpful. On the contrary, ISTM that they open up the possibility of = alternative behaviors to RFC 5280 validation without specifying what = those alternatives are, which would be bad for interoperability. --Richard From rbarnes@bbn.com Fri Feb 10 21:01:01 2012 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 2C76321E8020 for ; Fri, 10 Feb 2012 21:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoQ8a741NreB for ; Fri, 10 Feb 2012 21:01:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 121AA11E807F for ; Fri, 10 Feb 2012 21:01:00 -0800 (PST) Received: from [128.89.254.202] (port=63751 helo=[172.20.51.161]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rw550-0004d4-G6; Sat, 11 Feb 2012 00:00:58 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 10 Feb 2012 21:00:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9865C1CC-6798-45EE-83CF-447B5AF9CBE8@bbn.com> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> To: Tom Ritter X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 05:01:01 -0000 > Chrome has key pinning working already, such that it will hard fail if > the cert for gmail (for example) doesn't match what it has pinned. > Same problem: the proxy shows a different cert. Chrome solves this by > making any user installed cert override a pin.[1] >=20 > If a TLSA-aware client _has_ a trust store, and certs can be added to > it, then perhaps it can do the same: a cert that was installed > manually (such as by the user for a proxy tool or a network admin for > corporate use) will not hard-fail on a DANE failure. It may fail, but > it must be allowed to be overridden. >=20 > If a TLSA-aware client does not have a trust store, or certs may not > be added to, then it's (probably) currently hard failing for the proxy > in question already. If it hard fails for the cert vs DANE, not much > different. This seems like a good point. The document already says the following:=20= " o A TLSA RRset whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRset. " Your proposal above seems like a local policy that would override TLSA. = Do you think we need to spell things out more? --Richard= From zack.weinberg@gmail.com Fri Feb 10 21:51:37 2012 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 8317C21F8574 for ; Fri, 10 Feb 2012 21:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Qukh5mylYbr for ; Fri, 10 Feb 2012 21:51:34 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2850F21F8575 for ; Fri, 10 Feb 2012 21:51:34 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5529298obb.31 for ; Fri, 10 Feb 2012 21:51:31 -0800 (PST) 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 :content-transfer-encoding; bh=CJxg5+O4DFSpsm2oIfiPfcubYn4Lx5aHO+XfMZVuDNc=; b=Igl3T1qRBAJSANnGzJ+PlS36xAypYYo/H/yqc7a2rfFmhy4HNZpIa0SWSmYnZjrWsp ThHKkOY3y4w0R4uR8T+mwS4Q6jp7tuTRJLkSN2XiXjtxrwmGqIrA2cXGnNKJJHyUPcVz Yp3vlr3d+fJeAHQsS/pWxhS8NqG76Zv6QI4Hg= MIME-Version: 1.0 Received: by 10.182.162.40 with SMTP id xx8mr6040060obb.17.1328939491616; Fri, 10 Feb 2012 21:51:31 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Fri, 10 Feb 2012 21:51:31 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Fri, 10 Feb 2012 21:51:31 -0800 X-Google-Sender-Auth: T6BiPdlSTDyxtbEjBSe4Unjtu-4 Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 05:51:38 -0000 On Fri, Feb 10, 2012 at 8:58 PM, Richard L. Barnes wrote: >> Add to the end of section 1.1: =C2=A0"Three of the four types of >> association defined in this document ("usages") make use of a >> _certificate chain_, beginning with the target certificate from the >> TLS handshake, and ending with a _trust anchor_. This document does >> not specify how a DANE client constructs this chain; however, one >> algorithm for doing so is in [RFC5280]. > > Could you clarify this citation? =C2=A0AFAICT, RFC 5280 defines an algori= thm > for validating a certification path, not constructing one (although it do= es > provide some constraints). You are correct; I confess I did not make it all the way through RFC 5280. Unfortunately, if RFC 5280 doesn't define path construction, I am not aware of _any_ specification that does. The easiest way forward would be to make the sentence read "This document does not specify how a DANE client constructs or validates this chain" and not give a reference. > ISTM that [the proposed modifications] open up the possibility of > alternative behaviors to RFC 5280 validation[,] without specifying > what those alternatives are[.] Yes. That is precisely the point of the change. > which would be bad for interoperability. On the contrary, it is for interoperability's sake that DANE must *not* attempt to specify chain construction or validation. No two existing clients use exactly the same algorithm; as far as I know *nobody* claims complete conformance to RFC 5280 path validation, and as we've just discovered, path _construction_ may not even be specified at all. Thus, what may have seemed like a perfectly sensible, uncontroversial, minor detail -- define a peripheral piece of the DANE algorithm by reference to the standard in which it is central -- is in fact the imposition of a major, compatibility-breaking, out-of-scope change requirement on basically every TLS client in the world. It has to go. zw From zack.weinberg@gmail.com Fri Feb 10 21:55:32 2012 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 11EF321F85A2 for ; Fri, 10 Feb 2012 21:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0-17wwD10m1 for ; Fri, 10 Feb 2012 21:55:30 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFBE21F85A1 for ; Fri, 10 Feb 2012 21:55:29 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5531613obb.31 for ; Fri, 10 Feb 2012 21:55:29 -0800 (PST) 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=vOrfQpQIjnYJIMVwAoHQf+V9owMMCdrwoa2jET/msDs=; b=UcN9+8vVamCt+z9H1K4Mnpx5/OaPzdkeGMQqzDAdd8Fy6Mfc80dsTmpdQTKN60778C GIjm/2z08RZ/dFev2HkJ64hfg+LTBLykXfXR7jr/zZbXggiUbJ3DlXaut70WpL43asdX mATqoD1kHvaS9E8AFjhhkpgHZUgcUSEoPReFA= MIME-Version: 1.0 Received: by 10.60.20.6 with SMTP id j6mr1467820oee.17.1328939729454; Fri, 10 Feb 2012 21:55:29 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Fri, 10 Feb 2012 21:55:29 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Fri, 10 Feb 2012 21:55:29 -0800 X-Google-Sender-Auth: S2DvaPBHJemytx8vvB00PGF6J4M Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 05:55:32 -0000 Addendum: I found a PKI Forum white paper on path construction. It's old (2002), but there doesn't seem to be anything more recent. Note sentence 2 of the abstract: "The certification path construction process has not been standardized." http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf From mrex@sap.com Fri Feb 10 23:03:51 2012 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 BE4B921F84EB for ; Fri, 10 Feb 2012 23:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRg8WeotR5Ec for ; Fri, 10 Feb 2012 23:03:51 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0CC21F84EA for ; Fri, 10 Feb 2012 23:03:50 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1B73gOT029570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Feb 2012 08:03:42 +0100 (MET) From: Martin Rex Message-Id: <201202110703.q1B73foL021976@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Sat, 11 Feb 2012 08:03:41 +0100 (MET) In-Reply-To: from "Zack Weinberg" at Feb 10, 12 09:55:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 07:03:51 -0000 There is an informational(!) document published as RFC: http://tools.ietf.org/html/rfc4158 Internet X.509 Public Key Infrastructure: Certification Path Building but it is not a "standard" of any kind. btw. I could not find "4158" in PKIX (rfc5280). -Martin Zack Weinberg wrote: > > Addendum: I found a PKI Forum white paper on path construction. It's > old (2002), but there doesn't seem to be anything more recent. Note > sentence 2 of the abstract: "The certification path construction > process has not been standardized." > > http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf From gnu@toad.com Sat Feb 11 01:15:18 2012 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 0992421F858E for ; Sat, 11 Feb 2012 01:15:18 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC8qKXXlbkln for ; Sat, 11 Feb 2012 01:15:17 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id A4B4B21F8476 for ; Sat, 11 Feb 2012 01:15:15 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1B9FEWD017446; Sat, 11 Feb 2012 01:15:14 -0800 Message-Id: <201202110915.q1B9FEWD017446@new.toad.com> To: IETF DANE WG list , gnu@toad.com Date: Sat, 11 Feb 2012 01:15:14 -0800 From: John Gilmore Subject: Re: [dane] dane-protocol-16 lacks real introductions 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 Feb 2012 09:15:18 -0000 I hadn't looked over the draft in awhile (instead focusing on the email discussions), which is probably good, since I'm now seeing it with fresh eyes. I find it hard to read. It lacks a lot of context and explanation for those who haven't been buried deep in the acronyms. I find myself longing for the editing touch of Jon Postel (e.g. RFC 791). For example, the abstract starts off: "TLS and DTLS use PKIX certificates..." Howabout an abstract like: Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to certify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. This gets rid of a lot of jargon ("bindings of keys", "entities that operate the DNS", "PKIX certificates") but says the same thing. Similarly, the first sentence of the first section after the Abstract, called the "Introduction", is: The first response from the server in TLS may contain a certificate. That's not a $%*$&# introduction!!! How about starting with a graf (stolen partly from RFC 2246's abstract) like: N. Motivation Applications that communicate over the Internet often need to prevent eavesdropping, tampering, or forgery of their communications. The Transport Layer Security (TLS, RFC XXXX) protocol provides this kind of communications privacy over the Internet, using encryption. Follow that with a whole section on motivation: The security properties of encryption systems depend strongly on the keys that they use. If secret keys are revealed, or if published keys can be replaced by bogus keys, these systems provide little or no security. TLS uses "certificates" to protect keys. A certificate combines a published key with other information such as the name of the service that the key is used by, and this combination is digitally signed by another key. Having a certificate for a key is only helpful if you trust the other key that signed the certificate. If that other key was itself revealed or substituted, then its signature is worthless in proving anything about the first key. On the Internet, this problem has been finessed for years by businesses called "Certifying Authorities" (CAs). They protect their secret key vigorously, while supplying their public key to the software vendors who build TLS clients. They then sign certificates, and supply those to TLS servers. TLS client software uses a set of these CA keys as "trust anchors" to validate the signatures on certificates that the client receives from TLS servers. The client software allows any CA to usefully sign any other certificate. This solution has gradually broken down by the appearance of untrustworthy CAs. A single trusted CA which betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can compromise any other certificate in TLS, by signing a replacement certificate that contains a bogus key. Several real-world occurrances that exploited such CAs for mass-scale wiretapping, subversion of major software or web sites, or large-scale fraud [add references] have brought TLS's previous CA model into disrepute. DNS Security (DNSSEC, RFC XXXX) provides a similar model that involves trusted keys signing the information for untrusted keys. However, DNSSEC provides three significant improvements. Keys are tied to names in the Domain Name System (DNS, RFC XXXX), rather than to arbitrary identifying strings; this is more convenient for Internet protocols. Signed keys for any domain are accessible online via a straightforward query using the standard DNSSEC protocol, so there is no problem distributing the signed keys. And the keys associated with a domain name can only be signed by a key associated with a suffix of that domain name (e.g. example.com's keys can only be signed by com's keys), preventing an untrustworthy signer from compromising anyone's keys except their own subdomains. Like TLS, DNSSEC relies on public keys that come built into the DNSSEC client software, but these keys come only from a single "root domain" rather than from a multiplicity of CAs. We still need a graf to connect up that previous "introduction", e.g.: N. Introduction Each client begins a TLS connection by exchanging messages with a TLS server. It looks up the server's name using the Domain Name System to get an Internet Protocol (IP) address. It then begins a TCP or UDP connection to a client-chosen port at that address, and sends an initial message there. However, the client does not know at this stage whether an adversary is intercepting and/or altering its communication before it reaches the TLS server. It does not even know whether the real TLS server associated with that domain name has ever received its initial messages. [then resume with what's now the first graf of 1. Introduction here] The first response from the server in TLS may contain a certificate. There are other places in the document which also jump right into the details without a real introduction, but let's see how well people like these first suggestions before I try to improve other places. John From paul.hoffman@vpnc.org Sat Feb 11 09:33:35 2012 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 5A54821F84B6 for ; Sat, 11 Feb 2012 09:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu6RrXc57IO0 for ; Sat, 11 Feb 2012 09:33:34 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C7DCD21F84B5 for ; Sat, 11 Feb 2012 09:33:34 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1BHXYnS010551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 11 Feb 2012 10:33:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Sat, 11 Feb 2012 09:33:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> References: To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 17:33:35 -0000 On Feb 10, 2012, at 8:49 PM, Richard L. Barnes wrote: > Section 1: > OLD > " > must trust a trust anchor upon which the server's certificate is = rooted, and must successfully validate the certificate. > " > NEW > " > must successfully validate the certificate, including chaining to a = trust anchor. > " Much clearer, yes. > Section 4 just seems like a more verbose version of Section 2.1.1. = Propose removing to avoid confusion. Y'know, I thought of that when I was reviewing it a revision or two ago. = Is the WG OK with Jakob and I nuking the section and making sure all the = semantics are just in 2.1.1? > Section 4.4: Domain-issued certificates are actually supported by both = usage 2 and usage 3. Yes, maybe, but I think that would confuse the section. This point is = covered at the beginning of Section 6; is it important to bring it up = here as well? --Paul Hoffman From paul.hoffman@vpnc.org Sat Feb 11 09:37:09 2012 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 0F4C021F84DC for ; Sat, 11 Feb 2012 09:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+ho0BHO1UPr for ; Sat, 11 Feb 2012 09:37:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3821F84BD for ; Sat, 11 Feb 2012 09:37:08 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1BHb7Pr010686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Feb 2012 10:37:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sat, 11 Feb 2012 09:37:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 17:37:09 -0000 On Feb 10, 2012, at 3:20 PM, Zack Weinberg wrote: > Add to the end of section 1.1: "Three of the four types of > association defined in this document ("usages") make use of a > _certificate chain_, beginning with the target certificate from the > TLS handshake, and ending with a _trust anchor_. This document does > not specify how a DANE client constructs this chain; however, one > algorithm for doing so is in [RFC5280]. Chain construction may > include 'validation' checks for certificates that are ill-formed or > contrary to client policy; again, this document does not specify any > such checks." Letting a client decide to make a chain in a way that is different than = RFC5280 will lead to unexpected security consequences, probably all bad. = Although I commiserate with you that parts of the PKIX path rules are = obtuse and obscure, in essence saying "you can skip them" will lead to = clients making chains that should not be made, thus reducing the = security of the protocol. --Paul Hoffman From paul.hoffman@vpnc.org Sat Feb 11 09:42:01 2012 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 6D14421F8510 for ; Sat, 11 Feb 2012 09:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO-Z1TAhS2g6 for ; Sat, 11 Feb 2012 09:42:00 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4B21F84F9 for ; Sat, 11 Feb 2012 09:42:00 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1BHfxeF010804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Feb 2012 10:42:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201202110915.q1B9FEWD017446@new.toad.com> Date: Sat, 11 Feb 2012 09:41:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9810E03A-78C5-4D5F-8157-B0A75AFB5D1E@vpnc.org> References: <201202110915.q1B9FEWD017446@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] dane-protocol-16 lacks real introductions 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 Feb 2012 17:42:01 -0000 On Feb 11, 2012, at 1:15 AM, John Gilmore wrote: > I hadn't looked over the draft in awhile (instead focusing on the > email discussions), which is probably good, since I'm now seeing it = with > fresh eyes. +1 > I find it hard to read. It lacks a lot of context and explanation for > those who haven't been buried deep in the acronyms. I find myself > longing for the editing touch of Jon Postel (e.g. RFC 791). >=20 > For example, the abstract starts off: >=20 > "TLS and DTLS use PKIX certificates..." >=20 > Howabout an abstract like: >=20 > Encrypted communication on the Internet often uses Transport Level > Security (TLS), which depends on third parties to certify the keys > used. This document improves on that situation by enabling the > administrator of a domain name to certify the keys used in that > domain's TLS servers. This requires matching improvements in TLS > client software, but no change in TLS server software. >=20 > This gets rid of a lot of jargon ("bindings of keys", "entities that > operate the DNS", "PKIX certificates") but says the same thing. Works for me. Do others like this? (And, yes, I think we can ignore DTLS = until the body of the spec.) > Similarly, the first sentence of the first section after the Abstract, > called the "Introduction", is: >=20 > The first response from the server in TLS may contain a certificate. >=20 > That's not a $%*$&# introduction!!! =20 >=20 > How about starting with a graf (stolen partly from RFC 2246's = abstract) like: >=20 > N. Motivation >=20 > Applications that communicate over the Internet often need to > prevent eavesdropping, tampering, or forgery of their > communications. The Transport Layer Security (TLS, RFC XXXX) > protocol provides this kind of communications privacy over the > Internet, using encryption. >=20 > Follow that with a whole section on motivation: >=20 > The security properties of encryption systems depend strongly on > the keys that they use. If secret keys are revealed, or if > published keys can be replaced by bogus keys, these systems > provide little or no security. >=20 > TLS uses "certificates" to protect keys. A certificate combines a > published key with other information such as the name of the > service that the key is used by, and this combination is digitally > signed by another key. Having a certificate for a key is only > helpful if you trust the other key that signed the certificate. If > that other key was itself revealed or substituted, then its > signature is worthless in proving anything about the first key. >=20 > On the Internet, this problem has been finessed for years by > businesses called "Certifying Authorities" (CAs). They protect > their secret key vigorously, while supplying their public key to > the software vendors who build TLS clients. They then sign > certificates, and supply those to TLS servers. TLS client software > uses a set of these CA keys as "trust anchors" to validate the > signatures on certificates that the client receives from TLS > servers. The client software allows any CA to usefully sign any > other certificate. >=20 > This solution has gradually broken down by the appearance of > untrustworthy CAs. A single trusted CA which betrays its trust, > either voluntarily or by providing less-than-vigorous protection > for its secrets and capabilities, can compromise any other > certificate in TLS, by signing a replacement certificate that > contains a bogus key. Several real-world occurrances that > exploited such CAs for mass-scale wiretapping, subversion of major > software or web sites, or large-scale fraud [add references] have > brought TLS's previous CA model into disrepute. >=20 > DNS Security (DNSSEC, RFC XXXX) provides a similar model that > involves trusted keys signing the information for untrusted keys. > However, DNSSEC provides three significant improvements. Keys are > tied to names in the Domain Name System (DNS, RFC XXXX), rather > than to arbitrary identifying strings; this is more convenient for > Internet protocols. Signed keys for any domain are accessible > online via a straightforward query using the standard DNSSEC > protocol, so there is no problem distributing the signed keys. And > the keys associated with a domain name can only be signed by a key > associated with a suffix of that domain name (e.g. example.com's > keys can only be signed by com's keys), preventing an untrustworthy > signer from compromising anyone's keys except their own subdomains. > Like TLS, DNSSEC relies on public keys that come built into the > DNSSEC client software, but these keys come only from a single "root > domain" rather than from a multiplicity of CAs. >=20 > We still need a graf to connect up that previous "introduction", e.g.: >=20 > N. Introduction >=20 > Each client begins a TLS connection by exchanging messages with a > TLS server. It looks up the server's name using the Domain Name > System to get an Internet Protocol (IP) address. It then begins a > TCP or UDP connection to a client-chosen port at that address, and > sends an initial message there. However, the client does not know > at this stage whether an adversary is intercepting and/or altering > its communication before it reaches the TLS server. It does not > even know whether the real TLS server associated with that domain > name has ever received its initial messages. >=20 > [then resume with what's now the first graf of 1. Introduction here] > The first response from the server in TLS may contain a certificate. >=20 > There are other places in the document which also jump right into the > details without a real introduction, but let's see how well people > like these first suggestions before I try to improve other places. I'm fine with adding these for motivation; I'm also fine with leaving = them out but adding something along the lines of "This document assumes = an understanding of TLS". --Paul Hoffman From zack.weinberg@gmail.com Sat Feb 11 10:10:57 2012 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 5A0BC21F84B5 for ; Sat, 11 Feb 2012 10:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0ZQKixJSPfG for ; Sat, 11 Feb 2012 10:10:56 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A723F21F84A0 for ; Sat, 11 Feb 2012 10:10:53 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6008886obb.31 for ; Sat, 11 Feb 2012 10:10:52 -0800 (PST) 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 :content-transfer-encoding; bh=cy9RqPdoKD1L/ED+EcrzgZe0LAuZI94q6xFvBDeRoX4=; b=T4fB9NDruRP0dSchwVg3JJXLjgpOQ67gJH6i4Gl5huZak0ddqye5AWUGzvnEkGzfxA Z9WBOLJSztrfuFh5L3vUZAdkp29o9Q7xIzvyAW86uXbO0T3VlpxyCnWs+JeGojjK/KHg G/v9vcHj099KilcSfCFdVGYbzEXvfRMWO7kD0= MIME-Version: 1.0 Received: by 10.182.118.34 with SMTP id kj2mr7176372obb.37.1328983852546; Sat, 11 Feb 2012 10:10:52 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Sat, 11 Feb 2012 10:10:52 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Sat, 11 Feb 2012 10:10:52 -0800 X-Google-Sender-Auth: 7GBX6RcaRUA9ApALxixXjWsI1ac Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 18:10:57 -0000 On Sat, Feb 11, 2012 at 9:37 AM, Paul Hoffman wrote= : >> Add to the end of section 1.1: =C2=A0"Three of the four types of >> association defined in this document ("usages") make use of a >> _certificate chain_, beginning with the target certificate from the >> TLS handshake, and ending with a _trust anchor_. This document does >> not specify how a DANE client constructs this chain; however, one >> algorithm for doing so is in [RFC5280]. =C2=A0Chain construction may >> include 'validation' checks for certificates that are ill-formed or >> contrary to client policy; again, this document does not specify any >> such checks." > > Letting a client decide to make a chain in a way that is different > than RFC5280 will lead to unexpected security consequences, > probably all bad. THEY ALREADY DO (make/validate chains in a different way, that is). The sky has not fallen, and it is inappropriate for DANE to mandate that clients change. zw From zack.weinberg@gmail.com Sat Feb 11 10:11:53 2012 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 EE07721F84B6 for ; Sat, 11 Feb 2012 10:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9piphKrRYcu for ; Sat, 11 Feb 2012 10:11:53 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 794E921F84A0 for ; Sat, 11 Feb 2012 10:11:53 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6009633obb.31 for ; Sat, 11 Feb 2012 10:11:53 -0800 (PST) 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 :content-transfer-encoding; bh=UI97VG7nGdRnjxEsvvo3A/Jq2guNSLmTWndhwtWCPiQ=; b=iXY9vPjBbx3T5Ffp3g9m59MAqNQqM9t8yZohR0Fg4rpoTK9/TZBbvunRQJgVKreUKm YNByuCOW95y3m4QjMEq8DYjKvk4XcQhPmKgigYmPvlhy6/bURnfnMbNOY7BK3OowCoVo fU2+rltBjSzPN6ZT6njnfmkeOUycrjw5uEw4s= MIME-Version: 1.0 Received: by 10.182.162.40 with SMTP id xx8mr7279271obb.17.1328983913158; Sat, 11 Feb 2012 10:11:53 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Sat, 11 Feb 2012 10:11:53 -0800 (PST) In-Reply-To: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> Date: Sat, 11 Feb 2012 10:11:53 -0800 X-Google-Sender-Auth: fya77WxEa-nyq-pNxMdyMooM4qk Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 18:11:54 -0000 On Sat, Feb 11, 2012 at 9:33 AM, Paul Hoffman wrote= : >> Section 4 just seems like a more verbose version of Section 2.1.1. =C2= =A0Propose removing to avoid confusion. > > Y'know, I thought of that when I was reviewing it a revision or two ago. = Is the WG OK with Jakob and I nuking the section and making sure all the se= mantics are just in 2.1.1? I support removing the duplication, but I'd prefer to keep the section 4 text and lose the section 2.1.1 text -- it's longer, but it's clearer IMHO. zw From pieter.lexis@os3.nl Sat Feb 11 10:56:51 2012 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 4BB8D21F8543 for ; Sat, 11 Feb 2012 10:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+VflBDFvpSE for ; Sat, 11 Feb 2012 10:56:50 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id AF31C21F8542 for ; Sat, 11 Feb 2012 10:56:49 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id A348617AA2C for ; Sat, 11 Feb 2012 19:56:48 +0100 (CET) Received: from [192.168.43.249] (195-240-16-78.ip.telfort.nl [195.240.16.78]) by smtp.os3.nl (Postfix) with ESMTPSA id 214DF17AA10 for ; Sat, 11 Feb 2012 19:56:47 +0100 (CET) Message-ID: <4F36B9EE.4050209@os3.nl> Date: Sat, 11 Feb 2012 19:56:46 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: dane@ietf.org References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> In-Reply-To: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 18:56:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/11/2012 06:33 PM, Paul Hoffman wrote: > Y'know, I thought of that when I was reviewing it a revision or two > ago. Is the WG OK with Jakob and I nuking the section and making sure > all the semantics are just in 2.1.1? +1 on merging 4 into 2.1.1. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPNrnqAAoJELPqGO5ebd4jthwP/AtDQZH0dHboGlUNoDdhECGo jVLdJCngO5OTGcHSEe5JrKAbj3+92t4lgSLb0hF1qjOBjAKdyLWg7elqm4lKtxjC 5XFwkRSqfr4T5LKB55fouH8BtBkEcdAKUouPxN0MW2F4GNYjj3zodyvrHsUirkBQ kL++KIo4FD58UCPfIamSY+ETaWPmDChFVTL/fOMYy5vz1ajawm5l9ZV4m/3iLeI4 WT/dDJPI1Ls0XVLb4qR2EWMqSvBqwdc4fuMLVwXhvnNGmeDQAggtmBeO5c2+YLu6 qyJ66Ii2Q8cJSCoBA8HwnfuWWuPtwl5s9Fu+z+LPi7ow3v1c+nO95v06t/QOYg2K uaqUeihzgwLFWMS3v5OKNYwZFhum6z0p0iHJhJI+z1b8l7o3zU8YZiR+Y9Fio998 RAvR4+gmaHvA7kEAyOvri5lY2qFrY98xAXNnmrPCOYn9MaCCONZnUkTYUPeuuW0r 9IrVtCe6LnMyxSLjPtkq6TY/dxRdqmJFBr5EwOD4QLwVfc79Tv9uDax7UHsR4qV6 DdoEczZwMCwiZZ9JfUbc09rF4nuUSiTCL0pVL0oFguyYnq4LKjyVYUOU9zood4cM /HLmqlQ37diPIzM9iHQWhs4YxxuH9aQ7KCzxRPJBIu3Zjm710FJCIEtyT4dDj1Hl nZgTjL/tobtUTBo4A/vN =yZwt -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Sat Feb 11 11:01:46 2012 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 99FE821F8569 for ; Sat, 11 Feb 2012 11:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjCKkc7IfO0q for ; Sat, 11 Feb 2012 11:01:46 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id DFF6421F8565 for ; Sat, 11 Feb 2012 11:01:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 10589171C3D; Sat, 11 Feb 2012 19:01:45 +0000 (GMT) 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=1328986904; bh=BrjsCVAUAk6GNv PXb9CpetHwQILp+yRzARqhtPLxnDU=; b=EXGh3CTykzzZX+cr55MbFTLri34Wiv 6VVEpmFltDCS/3Dv41Q5a3a1c/B7XXBLhIJfEiqS9COJ2LsY8Tj8djxwgi6pP/Ek 3vJXMynQ/CoWiaUF+uxttHzpfwrx5djCqbj0G9KbtQDZnDB5o4HuligaACtb/pfj pdU3EHdoZRzOvACpglVtT1jKFuKCUWHks0ETY3XlWbTIXNmSx/MD0FiehNjumK8G gEAPHDsW0n0FkhZH8FBYO9s5JvB4CnypkS7OzyJbRrJHvexqEmajLJhirFnu5NWo 16ddy7F39gbbRE3HdMWoR9sqEbMPAIGvBIV2QnPicxB951b0UEnujs3Q== 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 0CydudAF5v8B; Sat, 11 Feb 2012 19:01:44 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.41.10.8]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A7698171C00; Sat, 11 Feb 2012 19:01:44 +0000 (GMT) Message-ID: <4F36BB18.9070205@cs.tcd.ie> Date: Sat, 11 Feb 2012 19:01:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Zack Weinberg References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 19:01:46 -0000 On 02/11/2012 05:51 AM, Zack Weinberg wrote: > On Fri, Feb 10, 2012 at 8:58 PM, Richard L. Barnes wrote: >> Could you clarify this citation? AFAICT, RFC 5280 defines an algorithm >> for validating a certification path, not constructing one (although it does >> provide some constraints). > > You are correct; I confess I did not make it all the way through RFC 5280. Hang on. Are you saying that you're being highly critical of a document you've not actually read? That makes your argument bogus hearsay doesn't it? Apologies if I've misinterpreted you. Please do go read it if you're going to complain about it like this. From my p-o-v *informed* criticism of 5280 or anything else is welcome, Hearsay is not. S From zack.weinberg@gmail.com Sat Feb 11 11:34:54 2012 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 3989621F8551 for ; Sat, 11 Feb 2012 11:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVyvXRv88rYY for ; Sat, 11 Feb 2012 11:34:53 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA821F8550 for ; Sat, 11 Feb 2012 11:34:53 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6062562obb.31 for ; Sat, 11 Feb 2012 11:34:52 -0800 (PST) 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=EcA3BGaY+ZqVV4BX/2W/LxiI8s0ynyxTLdY41pzIT6A=; b=KRUa/X1PFfIg8BS9soWRjjMHhi8enZvHzsQo6FTzNj9sHt3iK979ZzUuJJ4Joi96a6 uuJuLEjko5wv3wZYRZIZ5mNYbj/f23Rb6/Wl6h9WCvFXYvK6efMJMSF9X+1geU5k91aE lo/zvglYh8I+18DjYHzYLAfYZL+KkFGyW8EuM= MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr7383910obc.7.1328988892938; Sat, 11 Feb 2012 11:34:52 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Sat, 11 Feb 2012 11:34:52 -0800 (PST) In-Reply-To: <4F36BB18.9070205@cs.tcd.ie> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> Date: Sat, 11 Feb 2012 11:34:52 -0800 X-Google-Sender-Auth: WipwFZ0W6X5iBEsyvRU5yH-MTko Message-ID: From: Zack Weinberg To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 19:34:54 -0000 On Sat, Feb 11, 2012 at 11:01 AM, Stephen Farrell wrote: > On 02/11/2012 05:51 AM, Zack Weinberg wrote: >> You are correct; I confess I did not make it all the way through RFC 5280. > > Hang on. Are you saying that you're being highly critical > of a document you've not actually read? I am not being critical of RFC 5280 itself. I am objecting to the inclusion in DANE of a *requirement to comply with* RFC 5280, RFC 4158, or any other published standard for path construction or validation that may be found, because I know that many existing TLS clients do not comply with any such standard -- see for example http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/b13773e6df6927bf?fwc=1 -- and I see it as out-of-scope for this WG and likely to hinder adoption. zw From lists+keyassure@seantek.com Sat Feb 11 13:10:41 2012 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 C9D1321F845E for ; Sat, 11 Feb 2012 13:10:41 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUfV1i0G0GPt for ; Sat, 11 Feb 2012 13:10:41 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5E21F8452 for ; Sat, 11 Feb 2012 13:10:41 -0800 (PST) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AAE1122E247 for ; Sat, 11 Feb 2012 16:10:40 -0500 (EST) Message-ID: <4F36D94D.2070707@seantek.com> Date: Sat, 11 Feb 2012 13:10:37 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 21:10:41 -0000 On 2/11/2012 11:34 AM, Zack Weinberg wrote: > On Sat, Feb 11, 2012 at 11:01 AM, Stephen Farrell > wrote: >> On 02/11/2012 05:51 AM, Zack Weinberg wrote: >>> You are correct; I confess I did not make it all the way through RFC 5280. >> Hang on. Are you saying that you're being highly critical >> of a document you've not actually read? > I am not being critical of RFC 5280 itself. > > I am objecting to the inclusion in DANE of a *requirement to comply > with* RFC 5280, RFC 4158, or any other published standard for path > construction or validation that may be found, because I know that many > existing TLS clients do not comply with any such standard -- see for > example http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/b13773e6df6927bf?fwc=1 > -- and I see it as out-of-scope for this WG and likely to hinder > adoption. This comment, I fear, is out of line. I wrote a detailed comparison in the follow-up to the thread you cited, detailing point-by-point how libpkix stacks up against RFC 5280, citing the actual source code. See "Re: libpkix maintenance plan" and the Google Spreadsheet "RFC 5280 vs. CERT_PKIXVerifyCert" . libpkix does, in fact, fully comply with RFC 5280. (I cited several deficiencies in CERT_PKIXVerifyCert, but those do not affect RFC 5280 compliance--they only affect the flexibility of specifying optional inputs and outputs that RFC 5280 suggests.) The general opinion of Mozilla and the NSS maintainers and users is to move to the libpkix validation path for all applications. -Sean From owens.bill@gmail.com Sat Feb 11 13:49:55 2012 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 39FF921F8574 for ; Sat, 11 Feb 2012 13:49:55 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRNJdvsKBAtR for ; Sat, 11 Feb 2012 13:49:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDDC21F8531 for ; Sat, 11 Feb 2012 13:49:54 -0800 (PST) Received: by werm10 with SMTP id m10so3614384wer.31 for ; Sat, 11 Feb 2012 13:49:53 -0800 (PST) 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:content-transfer-encoding; bh=ifD6l1HQGRYspZkjsKdeiK9sx0QilRZMkXKXpycVlSE=; b=tABcVN6xrMEhVnIfZa4xsqoiwof/jsOL5DksP6L4GNJK47oxeygcgZc6hA8gShPeZO +ui8cIWslHS5OpIQXlMJwmg0BatQg+DQhEtUhUkvEdDezNfvvP6M5y/ksV1AX0gYx4RS 6yYwPqmBkiK4k4l6a7agahv5CfNS7xQCPMPT8= MIME-Version: 1.0 Received: by 10.216.135.37 with SMTP id t37mr4169498wei.44.1328996993651; Sat, 11 Feb 2012 13:49:53 -0800 (PST) Received: by 10.180.97.161 with HTTP; Sat, 11 Feb 2012 13:49:53 -0800 (PST) In-Reply-To: <9865C1CC-6798-45EE-83CF-447B5AF9CBE8@bbn.com> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <9865C1CC-6798-45EE-83CF-447B5AF9CBE8@bbn.com> Date: Sat, 11 Feb 2012 16:49:53 -0500 Message-ID: From: Bill Owens To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 21:49:55 -0000 On Sat, Feb 11, 2012 at 12:00 AM, Richard L. Barnes wrote= : > This seems like a good point. =A0The document already says the following: > " > =A0 o =A0A TLSA RRset whose DNSSEC validation state is secure MUST be use= d > =A0 =A0 =A0as a certificate association for TLS unless a local policy wou= ld > =A0 =A0 =A0prohibit the use of the specific certificate association in th= e > =A0 =A0 =A0secure TLSA RRset. > " On the one hand, there are a number of characteristics that I'd like to have in any DANE-aware browser that I use, especially if it mirrors the Chrome behavior. But those seem like implementation choices, and I don't think they'd be appropriate in the protocol definition. And as much as I'd like to say that DANE compliance is absolute, with no option to override, the choices that have already been made in existing software and network designs seem to make that an untenable position. In the end, I think our best bet for obtaining sensible behavior will be lobbying the browser authors, not mandating it in the spec. Bill. From gnu@toad.com Sat Feb 11 15:10:39 2012 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 74A7621F84C8 for ; Sat, 11 Feb 2012 15:10:39 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAUmAxNc5y5G for ; Sat, 11 Feb 2012 15:10:39 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2A621F84B6 for ; Sat, 11 Feb 2012 15:10:38 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1BNAaWD028913; Sat, 11 Feb 2012 15:10:36 -0800 Message-Id: <201202112310.q1BNAaWD028913@new.toad.com> To: Paul Hoffman In-reply-to: <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Fri, 10 Feb 2012 13:56:30 -0800." Date: Sat, 11 Feb 2012 15:10:36 -0800 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 23:10:39 -0000 > > abort the TLS connection. Someone employing such a system might > > therefore choose to prevent the deployment of TLSA-aware clients. > > Developers who add TLSA capabilities to their clients might also > > choose to perform PKIX validation using locally-configured trust > > anchors first, and skip the TLSA process if the validation succeeds. I agree that this paragraph needs work. But what's the purpose of the paragraph? To recommend to developers how they can code to subvert the end-to-end privacy that we claim to offer? I believe that's counterproductive to the entire purpose of the DANE committee. I would say something closer to: The privacy of clients that use TLSA cannot be circumvented by traditional TLS proxies. By design, the most that such proxies can do is to prevent TLSA-protected connections from succeeding. The "use locally-configured trust anchors first and skip TLSA" approach would return us to the bad old (current) days in which untrustworthy CA trust anchors can subvert any TLS connection. I thought we'd purged that concept from the draft, but apparently this Gorgon has more ugly heads. It's a straightforward downgrade attack against TLSA -- and the draft is recommending that we make it *succeed*?! Of course, the real way to subvert TLSA is to subvert DNSSEC, e.g. by subverting the "root keys" in the DNS software in all the clients. I sincerely hope that we aren't going to suggest that in the RFC. John From owens.bill@gmail.com Sat Feb 11 16:13:36 2012 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 2840721F84FB for ; Sat, 11 Feb 2012 16:13:36 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhAPyHP441Pw for ; Sat, 11 Feb 2012 16:13:35 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF821F84F2 for ; Sat, 11 Feb 2012 16:13:34 -0800 (PST) Received: by werm10 with SMTP id m10so3653892wer.31 for ; Sat, 11 Feb 2012 16:13:33 -0800 (PST) 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:content-transfer-encoding; bh=3lM8UEKgfX+rY0FxOcPoMzdqoo0T4wdWL5VRfOlyNVg=; b=Q/eHV2eWe9AI9UzsuCeLkibXdCpQhs30EFTTnu9K6yB5QmjFfY6FRCrhEMKfyui4uk xQfv8N7pDu/jEx/b0gCTnINrZQ/7oB3tZYwj1kJFt0SNcoYeNpKlQ+T5kGQmfbBP5o6u 40md2YsB1ImaoeUEDDytD9gC0ju6ZGy8mDy6E= MIME-Version: 1.0 Received: by 10.216.131.100 with SMTP id l78mr2703636wei.44.1329005613903; Sat, 11 Feb 2012 16:13:33 -0800 (PST) Received: by 10.180.97.161 with HTTP; Sat, 11 Feb 2012 16:13:33 -0800 (PST) In-Reply-To: <201202112310.q1BNAaWD028913@new.toad.com> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <201202112310.q1BNAaWD028913@new.toad.com> Date: Sat, 11 Feb 2012 19:13:33 -0500 Message-ID: From: Bill Owens To: John Gilmore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 00:13:36 -0000 On Sat, Feb 11, 2012 at 6:10 PM, John Gilmore wrote: >> > abort the TLS connection. Someone employing such a system might >> > therefore choose to prevent the deployment of TLSA-aware clients. >> > Developers who add TLSA capabilities to their clients might also >> > choose to perform PKIX validation using locally-configured trust >> > anchors first, and skip the TLSA process if the validation succeeds. > > I agree that this paragraph needs work. =A0But what's the purpose of the > paragraph? =A0To recommend to developers how they can code to subvert > the end-to-end privacy that we claim to offer? =A0I believe that's > counterproductive to the entire purpose of the DANE committee. =A0I > would say something closer to: > > =A0The privacy of clients that use TLSA cannot be circumvented by > =A0traditional TLS proxies. =A0By design, the most that such proxies can > =A0do is to prevent TLSA-protected connections from succeeding. > > The "use locally-configured trust anchors first and skip TLSA" > approach would return us to the bad old (current) days in which > untrustworthy CA trust anchors can subvert any TLS connection. =A0I > thought we'd purged that concept from the draft, but apparently this > Gorgon has more ugly heads. =A0It's a straightforward downgrade attack > against TLSA -- and the draft is recommending that we make it > *succeed*?! First, a locally-configured trust anchor is by definition not 'untrustworthy', although we can debate the wisdom and ethical ramifications of using them to enable MITM proxies. We can imagine a scenario in which a piece of malware installs its own trust anchor, though I haven't heard of such a thing; I would certainly use that threat as an argument for better behavior on the part of the client (flagging TLS connections when a local trust anchor has trumped TLSA, for example) but I wouldn't expect that this risk would change anyone's mind about allowing or prohibiting locally-configured anchors. Second, the draft isn't recommending anything. The text addresses a legitimate security consideration, an impact that DANE will certainly have on the network as it exists today, and moreover an interaction that ought to be considered when someone is implementing the protocol. >From what I can see, that is precisely what we're supposed to put in that section. > Of course, the real way to subvert TLSA is to subvert DNSSEC, e.g. by > subverting the "root keys" in the DNS software in all the clients. =A0I > sincerely hope that we aren't going to suggest that in the RFC. There are any number of ways to subvert TLSA, of which the simplest is to decree that TLSA-capable clients cannot be used within the network. I think it's safe to assume that the authors of those clients would rather see their software used in as many places as possible, and won't want their support of TLSA to automatically disqualify them from environments that use proxies. Certainly that seems to be Google's opinion, as in the text that I quoted a few days ago. I would note that they have allowed local anchors to override their own pins - designed to protect their business, not anyone else - and that says to me they know they don't have any other choice. There is perhaps one small bright spot in this distasteful situation. Those 'enterprise customers' who have managed to purchase unrestricted subordinate CAs from foolish providers will no longer be able to have their proxies be invisible. They'll either have to prevent the deployment of TLSA or fall back to locally-installed trust anchors, either one of which will require that they reveal themselves. Even if it takes some time to reach that state, I think it's a win. Bill. From ondrej.mikle@nic.cz Sat Feb 11 17:11:30 2012 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 A02BC21F858F for ; Sat, 11 Feb 2012 17:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCVOeh454gxx for ; Sat, 11 Feb 2012 17:11:30 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A7EB021F8551 for ; Sat, 11 Feb 2012 17:11:29 -0800 (PST) Received: from localhost.localdomain (ip-94-113-3-132.net.upcbroadband.cz [94.113.3.132]) by mail.nic.cz (Postfix) with ESMTPSA id 3B8B92A26FB; Sun, 12 Feb 2012 02:11:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1329009088; bh=dnWetJBfLJN/vGAKIO6m9v3QEOOc98t7WlRWERz9gbo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oVC1cs7o8KIHToI3Mtc8w980p/xuDoPchq+/Lw3CCql34asKZYLABQLqgi6RZmNZU +Ve9ErbLhZ1sgrXYitBFz4AlIM6VmuMeBa7rJkAyevg4I71NMRSttjrc5wlrkUztI3 2pOgUh6mXU4LheAhDMtTXctf3UQvePp7F9LzrJgo= Message-ID: <4F3711BF.5020807@nic.cz> Date: Sun, 12 Feb 2012 02:11:27 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> In-Reply-To: <4F356040.8010303@ogud.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 01:11:30 -0000 On 02/10/2012 07:21 PM, Olafur Gudmundsson wrote: > On 10/02/2012 08:16, Ondrej Mikle wrote: >> >> A.1.3 Choosing a Matching Type >> >> Using a hash algorithm in matching type has a performance advantage in >> shorter length of a TLSA record's association data field. Expanding on >> the recommendation expressed in section 2.1.3, guidelines for choosing >> hash in matching type are as follows - when using a hash algorithm in >> matching type, then: >> >> o Use SHA-512 (matching type 2) if the associated certificate uses >> SHA-512 or SHA-384 in signature algorithm. >> o Use SHA-256 (matching type 1) otherwise. >> > > Couple of questions: > How does this work when SHA-3 is added as a matching type? > Does the SHA-3 document have to "obsolete" this section and write a new section ? > > Is SHA-256 the right default ? I added a note saying to use SHA-512 matching type when certificate uses one of future SHA-3 hashes (before algorithms from the SHA-3 family are added to matching type field): """ A.1.3 Choosing a Matching Type Using a hash algorithm in matching type has a performance advantage in shorter length of a TLSA record's association data field. Expanding on the recommendation expressed in section 2.1.3, guidelines for choosing hash in matching type are as follows - when using a hash algorithm in matching type, then: o Use SHA-512 (matching type 2) if the associated certificate uses SHA-512, SHA-384 or a stronger algorithm (e.g. a hash from the future SHA-3 hash family) in signature algorithm. o Use SHA-256 (matching type 1) otherwise. """ Ondrej Mikle From ondrej.mikle@nic.cz Sat Feb 11 17:43:53 2012 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 1230F21F8577 for ; Sat, 11 Feb 2012 17:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDaNqCYBY-CL for ; Sat, 11 Feb 2012 17:43:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0AB21F8551 for ; Sat, 11 Feb 2012 17:43:45 -0800 (PST) Received: from localhost.localdomain (ip-94-113-3-132.net.upcbroadband.cz [94.113.3.132]) by mail.nic.cz (Postfix) with ESMTPSA id ED1312A0597 for ; Sun, 12 Feb 2012 02:43:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1329011024; bh=6e0y6dUvFefas5GTWW+5Jk42Uiy4i/RyjuPH2Iv5eOQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pJyININlk1NAtNDEYRRSaCwPHg97w8SrS38kldSWsNIq4sCK3zN9m953T2sWKmGES o/+sApQW4SJ3TrSrV+/QpzbQaVm5MEyihvPordvggogvOyRo4YW+1S9uBxNdiG9UdB AC+4KhoUZZ22Fd3tcDVuUQy1/WA1FaEWoBvEZqXQ= Message-ID: <4F37194F.4060100@nic.cz> Date: Sun, 12 Feb 2012 02:43:43 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dane@ietf.org References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> In-Reply-To: <4F36BB18.9070205@cs.tcd.ie> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 01:43:53 -0000 On 02/11/2012 08:01 PM, Stephen Farrell wrote: > > On 02/11/2012 05:51 AM, Zack Weinberg wrote: >> On Fri, Feb 10, 2012 at 8:58 PM, Richard L. Barnes wrote: > >>> Could you clarify this citation? AFAICT, RFC 5280 defines an algorithm >>> for validating a certification path, not constructing one (although it does >>> provide some constraints). >> >> You are correct; I confess I did not make it all the way through RFC 5280. > > Hang on. Are you saying that you're being highly critical > of a document you've not actually read? > > That makes your argument bogus hearsay doesn't it? While I don't condone not reading the specs before raising criticism, it should be noted that there is not a *single one* TLS client that adheres to RFC 5280. This is likely out of scope of DANE WG, but in case anyone is interested, look here: https://github.com/hiviah/pyx509 I've noticed some "oddities" (like accept an unknown X.509v3 extension marked as critical) while debugging the code above and comparing to common TLS clients and ASN.1 parsers. I noted few certs that various TLS clients see differently (look at complete certchain sent by server): Bad Certificate Policies 1256481 | www.koscom.co.kr | 2011-09-23 20:29:33.875519-04 | 2011-11-11 03:49:58.552574-05 1084745 | www.check.co.kr | 2011-09-23 20:01:42.251445-04 | 2011-11-11 03:17:40.602504-05 88122 | bill.signkorea.com | 2011-09-23 17:24:22.871876-04 | 2011-11-11 00:16:39.087095-05 Bad CRL dist points, empty octet string (commerzbank.fr), bad certificate policies (multicert.com) - bmpString in cpsUri instead of ia5String 551047 | ocsp.teste.multicert.com | 2011-09-23 18:37:21.16381-04 | 2011-10-12 03:27:13.25224-04 75915 | banking.commerzbank.fr | 2011-09-23 17:22:28.884534-04 | 2011-11-11 00:14:25.335163-05 509059 | mon.teste.multicert.com | 2011-09-23 18:30:43.734521-04 | 2011-11-11 01:30:22.560218-05 1641032 | ocsp.teste.multicert.com | 2011-10-13 03:28:48.592789-04 | 2011-11-11 01:38:26.453528-05 Ondrej Mikle From stephen.farrell@cs.tcd.ie Sat Feb 11 18:12:27 2012 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 2227F21F847B for ; Sat, 11 Feb 2012 18:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx2eB6PJswXK for ; Sat, 11 Feb 2012 18:12:26 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72821F8475 for ; Sat, 11 Feb 2012 18:12:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EACB3171C3F; Sun, 12 Feb 2012 02:12:23 +0000 (GMT) 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=1329012743; bh=7cdfPPw/kXkurA mpISEDZAl08bUyPA55VBNMik8SGbc=; b=ZglRCGiIxnqTKMh1lrMO4+IUalWkzz F8iaAEtwf6m9Gsb3U/kkHBlzK7cSm7baYm9k494ds7SHA6S4aVihUplVotm9YVj3 h48v71Zpu2pVkT58mNgrFM4aJODnckoIL0rfrrmBtJk78UvwS33pvi3a2ZVcHBeB /qzzlAkc5pc0qFadgBxV1a3/luW6hqSxr61WV5xZotsajixpQZzxbIrL2IWw33RI 67a8X2G+NHSVCnB7khW4dpMce54L15VPuvePDZ2vgEDhZRaGoqOaipIrb947ZRDB 9R+iavTOFXsS80jvnJvx9IVtNsDZI5xbOmRXoQoaxjZhZn650yJSp1xA== 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 EpnHMEKCup+M; Sun, 12 Feb 2012 02:12:23 +0000 (GMT) Received: from [10.87.48.6] (unknown [86.44.75.177]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 622D3171C2F; Sun, 12 Feb 2012 02:12:21 +0000 (GMT) Message-ID: <4F372005.8010502@cs.tcd.ie> Date: Sun, 12 Feb 2012 02:12:21 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ondrej Mikle References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> In-Reply-To: <4F37194F.4060100@nic.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 02:12:27 -0000 On 02/12/2012 01:43 AM, Ondrej Mikle wrote: > On 02/11/2012 08:01 PM, Stephen Farrell wrote: >> >> On 02/11/2012 05:51 AM, Zack Weinberg wrote: >>> On Fri, Feb 10, 2012 at 8:58 PM, Richard L. Barnes wrote: >> >>>> Could you clarify this citation? AFAICT, RFC 5280 defines an algorithm >>>> for validating a certification path, not constructing one (although it does >>>> provide some constraints). >>> >>> You are correct; I confess I did not make it all the way through RFC 5280. >> >> Hang on. Are you saying that you're being highly critical >> of a document you've not actually read? >> >> That makes your argument bogus hearsay doesn't it? > > While I don't condone not reading the specs before raising criticism, it should > be noted that there is not a *single one* TLS client that adheres to RFC 5280. That'd possibly be a fine thing to raise on the TLS list and/or the PKIX list but not really here. > This is likely out of scope of DANE WG, but in case anyone is interested, look here: Yes, as above. > https://github.com/hiviah/pyx509 That URL above points at someone's (yours?) *alpha* code from this month. I think its great that you're writing code and making that available, but its not relevant as backing for what seems to be a "don't really do what 5280 says" argument, which some seem to be making here. I also see no evidence there about other TLS codebase support for 5280. I'd be quite interested to see such evidence, which I guess does exist but hasn't been collected in a presentable format, other than as an occasional anecdote, and I'd like to see that raised on the TLS and/or PKIX lists as appropriate. As you said yourself, its not really on topic here. (But nonetheless worthwhile gathering and then properly publishing somewhere, or sending a URL around if its been done but not noticed so much.) But back on topic: as I think I said before, if you have trouble with TLS, go there. If you've a peeve with PKIX, then go there. This list is for doing DANE which is not in the business of re-defining the minutiae of either PKIX or TLS. All of our lists are equally open so there's no barrier to entry. That's why I'm jumping in here, things would go quite funny if we had concurrent IETF WG's stomping on one another like that, saying "do RFC XXX, except not this bit and not that bit and do this other thing instead of section foo" etc. Sorry if I'm maybe over-reacting but I do get a sense that there's that desire here and, especially if not based on reading the actual documents, doing that seems like a bad plan. S > > I've noticed some "oddities" (like accept an unknown X.509v3 extension marked as > critical) while debugging the code above and comparing to common TLS clients and > ASN.1 parsers. I noted few certs that various TLS clients see differently (look > at complete certchain sent by server): > > Bad Certificate Policies > 1256481 | www.koscom.co.kr | 2011-09-23 20:29:33.875519-04 | 2011-11-11 > 03:49:58.552574-05 > 1084745 | www.check.co.kr | 2011-09-23 20:01:42.251445-04 | 2011-11-11 > 03:17:40.602504-05 > 88122 | bill.signkorea.com | 2011-09-23 17:24:22.871876-04 | 2011-11-11 > 00:16:39.087095-05 > > Bad CRL dist points, empty octet string (commerzbank.fr), bad certificate > policies (multicert.com) - bmpString in cpsUri instead of ia5String > 551047 | ocsp.teste.multicert.com | 2011-09-23 18:37:21.16381-04 | 2011-10-12 > 03:27:13.25224-04 > 75915 | banking.commerzbank.fr | 2011-09-23 17:22:28.884534-04 | 2011-11-11 > 00:14:25.335163-05 > 509059 | mon.teste.multicert.com | 2011-09-23 18:30:43.734521-04 | 2011-11-11 > 01:30:22.560218-05 > 1641032 | ocsp.teste.multicert.com | 2011-10-13 03:28:48.592789-04 | 2011-11-11 > 01:38:26.453528-05 > > Ondrej Mikle > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From zack.weinberg@gmail.com Sat Feb 11 18:24:56 2012 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 D102E21F8565 for ; Sat, 11 Feb 2012 18:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxcSUQZ9s71I for ; Sat, 11 Feb 2012 18:24:56 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBE721F8551 for ; Sat, 11 Feb 2012 18:24:56 -0800 (PST) Received: by obbwd15 with SMTP id wd15so6264839obb.31 for ; Sat, 11 Feb 2012 18:24:55 -0800 (PST) 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=PxNYVE/dzrN9MrRJlInN5RGoeaLKgLvB3Fn8YEnWzMg=; b=At5bOeJ5n8kyvYhTAR2tqvObSkHn5MI2wFIkhoIP1XHBX8w8y42a/bQkJXAUmhmIAi AnAaNbWeGw9/BLoChWY1bHPKpFYSkuMyQvi0GBzatj0WCAxfcefJ/rt7IMmpNYLkvWcM SzoyZzearxWy41RUkkMPh/X3MhYgzp/+0nOpY= MIME-Version: 1.0 Received: by 10.182.162.40 with SMTP id xx8mr8069054obb.17.1329013495753; Sat, 11 Feb 2012 18:24:55 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Sat, 11 Feb 2012 18:24:55 -0800 (PST) In-Reply-To: <4F372005.8010502@cs.tcd.ie> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> Date: Sat, 11 Feb 2012 18:24:55 -0800 X-Google-Sender-Auth: W87Qmu_8n1iP3cvthkuJmZpy_nM Message-ID: From: Zack Weinberg To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 02:24:56 -0000 On Sat, Feb 11, 2012 at 6:12 PM, Stephen Farrell wrote: > But back on topic: as I think I said before, if you have > trouble with TLS, go there. If you've a peeve with PKIX, > then go there. This list is for doing DANE which is not > in the business of re-defining the minutiae of either PKIX > or TLS. All of our lists are equally open so there's no > barrier to entry. But this is exactly what I've been saying! Existing clients do not consistently follow any particular chain construction or validation algorithm. That's bad, but it's not DANE (the WG)'s job to fix. Therefore, DANE (the spec) must not require any particular chain construction or validation algorithm! zw From ondrej.mikle@nic.cz Sat Feb 11 19:02:53 2012 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 4E4C621F847B for ; Sat, 11 Feb 2012 19:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMlYK2hz0oNR for ; Sat, 11 Feb 2012 19:02:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8040C21F846F for ; Sat, 11 Feb 2012 19:02:48 -0800 (PST) Received: from localhost.localdomain (ip-94-113-3-132.net.upcbroadband.cz [94.113.3.132]) by mail.nic.cz (Postfix) with ESMTPSA id C09252A0148; Sun, 12 Feb 2012 04:02:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1329015767; bh=4xmvkuJj90iNMirgwQTRJjaLEUJi3SfFLGu9b70ecQ8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VEtm5lCHHH0rgZVPijDIYBTLG7ecX4JMOMigzT2JK37ioaGUqB1QC9av2kV4HuUoX C4wGoVSC+taMmoN9hv6mctjsYaEseA3Qg7AYXHryyMZ9nsbwSh+y8djS7g9h3wgS+O NYlBbuFgh6HeqRWD5XAxiXdxorhS3P/zhtd2aNvo= Message-ID: <4F372BD7.1020202@nic.cz> Date: Sun, 12 Feb 2012 04:02:47 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Stephen Farrell References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> In-Reply-To: <4F372005.8010502@cs.tcd.ie> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 03:02:53 -0000 On 02/12/2012 03:12 AM, Stephen Farrell wrote: > but its not relevant as backing for > what seems to be a "don't really do what 5280 says" argument, > which some seem to be making here. FWIW, I was aiming more for a "be aware that real-world implementations do all kinds of non-RFC-5280 stuff" argument (that's what the most of A.1 section is about). > That's why I'm jumping in here, things would go quite > funny if we had concurrent IETF WG's stomping on one another > like that, saying "do RFC XXX, except not this bit and not > that bit and do this other thing instead of section foo" > etc. Sorry if I'm maybe over-reacting but I do get a sense > that there's that desire here and, especially if not based > on reading the actual documents, doing that seems like a > bad plan. Sorry about the interruption. I'm still learning to get the "feeling" about what's appropriate for which WG. Ondrej From paul@cypherpunks.ca Sat Feb 11 21:05:28 2012 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 3D4E221F85A4 for ; Sat, 11 Feb 2012 21:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L20Lj-qwiqFh for ; Sat, 11 Feb 2012 21:05:27 -0800 (PST) Received: from bofh.nohats.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A3CFC21F85A2 for ; Sat, 11 Feb 2012 21:05:26 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (8.14.5/8.14.5) with ESMTP id q1C56dQZ011493; Sun, 12 Feb 2012 00:06:39 -0500 Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1C56bNq011487; Sun, 12 Feb 2012 00:06:38 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Feb 2012 00:06:37 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: John Gilmore In-Reply-To: <201202112310.q1BNAaWD028913@new.toad.com> Message-ID: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <201202112310.q1BNAaWD028913@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 05:05:28 -0000 On Sat, 11 Feb 2012, John Gilmore wrote: >>> abort the TLS connection. Someone employing such a system might >>> therefore choose to prevent the deployment of TLSA-aware clients. >>> Developers who add TLSA capabilities to their clients might also >>> choose to perform PKIX validation using locally-configured trust >>> anchors first, and skip the TLSA process if the validation succeeds. > > I agree that this paragraph needs work. But what's the purpose of the > paragraph? To recommend to developers how they can code to subvert > the end-to-end privacy that we claim to offer? I believe that's > counterproductive to the entire purpose of the DANE committee. Agreed. At most I would say that TLS proxies need to be integrated more closely with DNSSEC and DANE and overriding locally installed policy is required to ensure the user and their software know when to bypass the the security offered by DANE that would mark this as an attack. Paul From paul@cypherpunks.ca Sat Feb 11 21:09:54 2012 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 B1E6621F8596 for ; Sat, 11 Feb 2012 21:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aghN89CgOvcq for ; Sat, 11 Feb 2012 21:09:53 -0800 (PST) Received: from bofh.nohats.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id C523921F85A2 for ; Sat, 11 Feb 2012 21:09:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (8.14.5/8.14.5) with ESMTP id q1C5B2pj011640; Sun, 12 Feb 2012 00:11:02 -0500 Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1C5B1PE011637; Sun, 12 Feb 2012 00:11:01 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 12 Feb 2012 00:11:01 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Bill Owens In-Reply-To: Message-ID: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <201202112310.q1BNAaWD028913@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 05:09:54 -0000 On Sat, 11 Feb 2012, Bill Owens wrote: > There is perhaps one small bright spot in this distasteful situation. > Those 'enterprise customers' who have managed to purchase unrestricted > subordinate CAs from foolish providers will no longer be able to have > their proxies be invisible. They'll either have to prevent the > deployment of TLSA or fall back to locally-installed trust anchors, > either one of which will require that they reveal themselves. Even if > it takes some time to reach that state, I think it's a win. They'll just go back to forcing their users to use a SOCKS proxy :/ Then the local client does not do any DNS lookups or IP connections, it only connects to the SOCKS proxy and receives its MITMed data. Note that "good" MITM SOCKS proxies exist too, such as "tor". Paul From gnu@toad.com Sun Feb 12 01:58:15 2012 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 A64DA21F85E1 for ; Sun, 12 Feb 2012 01:58:15 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTh3BylK5zOE for ; Sun, 12 Feb 2012 01:58:15 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id C2B7221F8593 for ; Sun, 12 Feb 2012 01:58:13 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1C9wBWD006823; Sun, 12 Feb 2012 01:58:11 -0800 Message-Id: <201202120958.q1C9wBWD006823@new.toad.com> To: Paul Hoffman , gnu@toad.com In-reply-to: <9810E03A-78C5-4D5F-8157-B0A75AFB5D1E@vpnc.org> Date: Sun, 12 Feb 2012 01:58:11 -0800 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] dane-protocol-16 lacks real introductions 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 Feb 2012 09:58:15 -0000 > I'm fine with adding these for motivation; I'm also fine with > leaving them out but adding something along the lines of "This > document assumes an understanding of TLS". Thank you, Paul. The beauty of Postel's RFCs was that they taught me internetworking while also teaching me which bits went into which fields. I believe that was one of the reasons that TCP/IP won over the IEEE or ANSI or telco style standards, which tell you exactly what fields exist, but not necessarily WHY they exist, nor how to think about their context. Clearly you need to understand TLS to do design work on the TLSA protocol, or to code a TLSA implementation. But at what level do you need to understand TLS to merely deploy TLSA in your domain? I think this I-D should document TLSA well enough to satisfy that much larger set of people. How is our reader going to "first understand TLS before you read this RFC" without reading RFC 5246? To really read 5246 and figure out what byte values TLS transmits, you have to be a data structures guru, or at least be able to compile nested datatypes in your head. (It's quite a redundant encoding; I suspect some people would be surprised at how much predictable plaintext is in there.) XDR was invented by Bob Lyon down the hall from me at Sun, so I am one of the few with the expertise to figure that stuff out. But my first time in there, I was shocked to find deeply nested conceptual structures as the only documentation, rather than the ascii bitfield diagrams that Postel's RFCs used to explain TCP and IP packet structures (and that our Draft uses in Section 2.1). We should find ways to explain what DANE and TLSA do, which don't involve first teaching the reader a one-hit-wonder data structure serialization language buried in another RFC. If we throw our most naive readers to THOSE lions, we'll fail part of our audience, who we should be gently educating. I'll transcribe more comments on other parts of the document soon. John From ahu@xs.powerdns.com Sun Feb 12 03:23:55 2012 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 790F421F865A for ; Sun, 12 Feb 2012 03:23:55 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3nqkRECkOl1 for ; Sun, 12 Feb 2012 03:23:55 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9421F8659 for ; Sun, 12 Feb 2012 03:23:54 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1RwXX2-0002zW-Ge; Sun, 12 Feb 2012 12:23:48 +0100 Date: Sun, 12 Feb 2012 12:23:48 +0100 From: bert hubert To: John Gilmore Message-ID: <20120212112348.GA9529@xs.powerdns.com> References: <9810E03A-78C5-4D5F-8157-B0A75AFB5D1E@vpnc.org> <201202120958.q1C9wBWD006823@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202120958.q1C9wBWD006823@new.toad.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] dane-protocol-16 lacks real introductions 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 Feb 2012 11:23:55 -0000 On Sun, Feb 12, 2012 at 01:58:11AM -0800, John Gilmore wrote: > > I'm fine with adding these for motivation; I'm also fine with > > leaving them out but adding something along the lines of "This > > document assumes an understanding of TLS". > > Thank you, Paul. > > The beauty of Postel's RFCs was that they taught me internetworking > while also teaching me which bits went into which fields. I believe > that was one of the reasons that TCP/IP won over the IEEE or ANSI or > telco style standards, which tell you exactly what fields exist, but > not necessarily WHY they exist, nor how to think about their context. I want to amplify this point. One reason I think the draft was kept short was the contentious nature of the discussion at times. One way to achieve consensus is to minimize the amount of stuff we want to achieve consensus on. It turns out there is a large class of documents that make perfect sense only once you grasp them. In other words, you can get it only once you got it. How you transition into this stage of understanding however is left as an exercise to the reader. Quite literally I might add. I hope, and will vocally support, adding the necessary verbiage and diagrams even if makes people uncomfortable again because it adds stuff someone out there might disagree with. > Clearly you need to understand TLS to do design work on the TLSA > protocol, or to code a TLSA implementation. But at what level do you > need to understand TLS to merely deploy TLSA in your domain? I think > this I-D should document TLSA well enough to satisfy that much larger > set of people. Richard Stevens showed us the way - it is an art to add only exactly what is needed, while making sure that what we leave out does not compromise the message. > I'll transcribe more comments on other parts of the document soon. Thank you! Bert From wouter@nlnetlabs.nl Mon Feb 13 07:04:50 2012 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 24F8A21F8584 for ; Mon, 13 Feb 2012 07:04:50 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFKsAz20tnWd for ; Mon, 13 Feb 2012 07:04:49 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D86421F8552 for ; Mon, 13 Feb 2012 07:04:48 -0800 (PST) Received: from axiom.nlnetlabs.nl (axiom.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4d46]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1DF4ik1067817 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 13 Feb 2012 16:04:44 +0100 (CET) (envelope-from wouter@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329145488; bh=AfddyFdPp6eBvkcgMhXRKgxB8I3QpjZUpttUN3oZFYI=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=uhzVBur53FslKf1pApldVgkcNWC6j/eeR4ujVrNtOM9XPRhqKiiVaa8hb4hWAK2eZ 7MOTv7/BbXYvAqXY7LPj23l7Wexpu/aE2LZ91IhxzoVK2E93A1E4t0WRsz1/PESs4A zZRkr0s92A+X1cHcuBkkj27GspLrKSHTy9lZGSJc= Message-ID: <4F39268C.2020806@nlnetlabs.nl> Date: Mon, 13 Feb 2012 16:04:44 +0100 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: dane@ietf.org References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> <4F3711BF.5020807@nic.cz> In-Reply-To: <4F3711BF.5020807@nic.cz> X-Enigmail-Version: 1.3.5 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]); Mon, 13 Feb 2012 16:04:44 +0100 (CET) Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 15:04:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I reviewed draft dane-16 and I endorse it. Review comments below. * s/Some people want/There is/ in section 1.0. * At 2.1.1 usage type 0 says 'chain through', does that include start and end? From appendix B I see it includes every cert in the chain. I suggest: s/a CA certificate/a CA certificate (begin and end of chain included)/ * At the bottom of page 10 it says: ';otherwise, ...' but that talks about one usage field value. Also it does not specify that one TLSA match is sufficient. New text: ; otherwise, that application attempts to use every usable TLSA record, until a TLSA record works out to a secure TLS connection, or all usable TLSA records fail and the TLS connection is aborted. (( or remove the old text and insert no new text)). * 9. in the security considerations, please add a new paragraph: If an administrator wishes to stop using a TLSA record, the administrator can simply remove it from the DNS. Normal clients stop using the TLSA record after the TTL has expired. Replay attacks are no longer possible after the expiration date on the RRSIG. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIbBAEBAgAGBQJPOSaMAAoJEJ9vHC1+BF+N5DgP9jwqJf+6yY9kaAQmb2ZG3+0Z Z+00/qVG/k8EP8K3CCCgADbVkpYeH+xc/ecHAZyqsVj6rPPXPt4/uNJaKzJf60I4 Cn6qoyuf5LqvBQAV0bAgqj20Lg0rIo/uC0nIOEq+udYc30DBpl4bojD+LK9DLC2s LLNq3PkrE8QXzTESW9JuwpfmjcnG0vTJrME7CnYyrIGbxJ+fq7fLZ6/ThXqVmaV7 puSestoMqI2/591CJ1NhbDaJkCwdXGg+7Eay5grk8fWLl8vwh3RUdH1wLY7vTPD2 OKZUXnGjuojTjAb2ZW0HQ3wEa93mm2tpFbwYYRJjk81PkyJKlIKDS5KTShALDmC/ 5feN1kJw2TzCSNivkEfsbdjqblA5phNHKsdGmWJs9+fZ+byfOO5M96rAIluODkP4 cBQru5EnMkr5Zack5jgXKEkjjHd/4byVefy372qxW+RfjJhJ4Sn5OLJE2oaAhCy4 I/7w2rtauMnv/2brMCWwEa77MQoqpAgXecSAZYswpxU4cge5/ToEhzQulDYQn+CB ClU7iTKt9EEsN9KW5MLnRqsv93Lx6fifPI7r0bv4KHN3T89VhxJ4EDUR5ui5Cber 2u99d1tZ+xvS2OWNkab6JZDBQMxo6U1iLxu6EARNrv1I/7wgTpEQh0xm3d09d7bR yDOb3ol2wdnzMr0aYHU= =jYj1 -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Mon Feb 13 07:32:48 2012 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 762EE21F8467 for ; Mon, 13 Feb 2012 07:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKozwwvulchQ for ; Mon, 13 Feb 2012 07:32:48 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EB17421F8466 for ; Mon, 13 Feb 2012 07:32:47 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1DFWkti099386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 08:32:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F39268C.2020806@nlnetlabs.nl> Date: Mon, 13 Feb 2012 07:32:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0618265A-0AA8-4946-9B2B-96F0C6B12F7C@vpnc.org> References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> <4F3711BF.5020807@nic.cz> <4F39268C.2020806@nlnetlabs.nl> To: "W.C.A. Wijngaards" X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 15:32:48 -0000 On Feb 13, 2012, at 7:04 AM, W.C.A. Wijngaards wrote: > * At 2.1.1 usage type 0 says 'chain through', does that include start > and end? =46rom appendix B I see it includes every cert in the chain. > I suggest: > s/a CA certificate/a CA certificate (begin and end of chain included)/ Given the earlier discussion that led to type 3, I believe that this = should only be the beginning (root) of the chain, yes? > * 9. in the security considerations, please add a new paragraph: > If an administrator wishes to stop using a TLSA record, the > administrator can simply remove it from the DNS. Normal clients stop > using the TLSA record after the TTL has expired. Replay attacks are > no longer possible after the expiration date on the RRSIG. Looks right to me; do others agree? --Paul Hoffman From ondrej.mikle@nic.cz Mon Feb 13 09:21:10 2012 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 3640421F86A8 for ; Mon, 13 Feb 2012 09:21:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp+8GHJS+6Ei for ; Mon, 13 Feb 2012 09:21:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9ED21F869D for ; Mon, 13 Feb 2012 09:21:09 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2] (unknown [IPv6:2001:1488:ac14:1400:222:64ff:fe2f:75c2]) by mail.nic.cz (Postfix) with ESMTPSA id E1DC72A2DC8 for ; Mon, 13 Feb 2012 18:21:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1329153667; bh=x5qMSgSeFdollldr3S7NWEIYLhzNBWLlL/L/Z2vlVS0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WYo5FhJu7C6v4JGD/INh9gMCfxettwd4YorcjFZzSaFEHjQ2ndCeZVbA6Rkm9+Hqu 7xvIfy19d2ytD3V7DLbWY5u+xgNRagNNJN+IGRBl26wC8elN3eab2tJvqpRLrakis8 T5siRXEeReaOwjQHEDM+NwHZd86CrEyskHhU/lS0= Message-ID: <4F39463B.6060903@nic.cz> Date: Mon, 13 Feb 2012 18:19:55 +0100 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> <4F3711BF.5020807@nic.cz> <4F39268C.2020806@nlnetlabs.nl> <0618265A-0AA8-4946-9B2B-96F0C6B12F7C@vpnc.org> In-Reply-To: <0618265A-0AA8-4946-9B2B-96F0C6B12F7C@vpnc.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 17:21:10 -0000 On 02/13/2012 04:32 PM, Paul Hoffman wrote: > On Feb 13, 2012, at 7:04 AM, W.C.A. Wijngaards wrote: > >> * At 2.1.1 usage type 0 says 'chain through', does that include start >> and end? From appendix B I see it includes every cert in the chain. >> I suggest: >> s/a CA certificate/a CA certificate (begin and end of chain included)/ > > Given the earlier discussion that led to type 3, I believe that this should only be the beginning (root) of the chain, yes? So far I've understood usage type 0 as "including beginning and end of chain". IIRC the usage type 3 was added to address variant (3) here: https://www.ietf.org/mail-archive/web/dane/current/msg04188.html Since usage type 0 does not add a TA, the "private CA scenario" does not matter. >> * 9. in the security considerations, please add a new paragraph: > >> If an administrator wishes to stop using a TLSA record, the >> administrator can simply remove it from the DNS. Normal clients stop >> using the TLSA record after the TTL has expired. Replay attacks are >> no longer possible after the expiration date on the RRSIG. > > > Looks right to me; do others agree? Seems fine to me as well. Ondrej From cloos@jhcloos.com Mon Feb 13 09:58:11 2012 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 384A921F8588 for ; Mon, 13 Feb 2012 09:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbhqHDNvxRpn for ; Mon, 13 Feb 2012 09:58:10 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 9109521F8625 for ; Mon, 13 Feb 2012 09:58:10 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id E98A340179; Mon, 13 Feb 2012 17:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1329155887; bh=xb1vyAM7y1sh8pl1DPSLGsOYLZmxISnhqPF8PDzoDmI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mqgfDWZSriUrmP30pPvBoBNU1RkTMcJLTp5qm7Lr7zwZgHXUG7ETcTHDQYVdt/ZL9 yDOgxtk+dhwOljrd8TOC+JJvRVfOR3//r9sGXLBmEJ6N/F7dqR4dJlQPmXRGOikNqa 5A1UPxLqFpkX23cDyN3K5En5SotHoIX3/EpixI4o= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1036E36004C; Mon, 13 Feb 2012 17:52:09 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <0618265A-0AA8-4946-9B2B-96F0C6B12F7C@vpnc.org> (Paul Hoffman's message of "Mon, 13 Feb 2012 07:32:46 -0800") References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> <4F3711BF.5020807@nic.cz> <4F39268C.2020806@nlnetlabs.nl> <0618265A-0AA8-4946-9B2B-96F0C6B12F7C@vpnc.org> User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.92 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Mon, 13 Feb 2012 12:52:09 -0500 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120213:dane@ietf.org::oyniTmUTMi4a5l69:000UHYQ4 X-Hashcash: 1:30:120213:paul.hoffman@vpnc.org::OOIlleu0rg66CN2d:000000000000000000000000000000000000000JtaeY X-Hashcash: 1:30:120213:wouter@nlnetlabs.nl::JAR8cYWBr2h508KD:00000000000000000000000000000000000000000NCSJM Cc: Paul Hoffman Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 17:58:11 -0000 >>>>> "PH" == Paul Hoffman writes: [relating to usage type 0] PH> Given the earlier discussion that led to type 3, I believe that this PH> should only be the beginning (root) of the chain, yes? It seems that it is reasonable to specify an intermediate CA cert, not only the chain's root cert. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul.hoffman@vpnc.org Mon Feb 13 10:37:29 2012 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 8C7DC21F853A for ; Mon, 13 Feb 2012 10:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVIRN7E3NXsl for ; Mon, 13 Feb 2012 10:37:29 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 086AD21F853B for ; Mon, 13 Feb 2012 10:37:29 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1DIbRvC007857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 11:37:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F39463B.6060903@nic.cz> Date: Mon, 13 Feb 2012 10:37:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F342197.3020207@ogud.com> <4F345806.90506@nic.cz> <4F3518B0.1030601@nic.cz> <4F356040.8010303@ogud.com> <4F3711BF.5020807@nic.cz> <4F39268C.2020806@nlnetlabs.nl> <0618265A-0AA8-4946-9B2B-96F0C6B12F7C@vpnc.org> <4F39463B.6060903@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 18:37:29 -0000 On Feb 13, 2012, at 9:19 AM, Ondrej Mikle wrote: > On 02/13/2012 04:32 PM, Paul Hoffman wrote: >> On Feb 13, 2012, at 7:04 AM, W.C.A. Wijngaards wrote: >>=20 >>> * At 2.1.1 usage type 0 says 'chain through', does that include = start >>> and end? =46rom appendix B I see it includes every cert in the = chain. >>> I suggest: >>> s/a CA certificate/a CA certificate (begin and end of chain = included)/ >>=20 >> Given the earlier discussion that led to type 3, I believe that this = should only be the beginning (root) of the chain, yes? >=20 > So far I've understood usage type 0 as "including beginning and end of > chain". Whoops, my bad. The end of the chain is a CA, not the EE cert. --Paul Hoffman From gnu@toad.com Mon Feb 13 14:53:28 2012 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 3F34821E8010 for ; Mon, 13 Feb 2012 14:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp51qj86qIz5 for ; Mon, 13 Feb 2012 14:53:27 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEA121E8013 for ; Mon, 13 Feb 2012 14:53:25 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1DMrNWD008593; Mon, 13 Feb 2012 14:53:23 -0800 Message-Id: <201202132253.q1DMrNWD008593@new.toad.com> To: IETF DANE WG list , John Gilmore Date: Mon, 13 Feb 2012 14:53:23 -0800 From: John Gilmore Subject: [dane] dane-protocol-16 comments on Sec 1 to 2.1.4 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 Feb 2012 22:53:28 -0000 [Formatting note: I'll put my commentary in [brackets], original -16 text indented, and suggested replacement text unbracketed and at the left margin.] [In general, the complicated parts of this protocol are in how it interacts with the pre-existing complicated parts of PKIX. I suggest that we start off the reader by explaining the least complicated use cases (e.g. Usage type 3 which avoids invoking signature validation chains), and then move into the more complicated cases in which new TLSA constraints or trust anchors get injected into the undefined process of signature validation chain construction.] [In general, we should decide whether we are referring to "this document" or "this protocol" when we make self-referential statements like: The selectors defined in this document are... This document does not specify how DNSSEC validation occurs... The use cases from Section 3 of [RFC6394] are covered in this protocol... ...if extensions to this protocol are made... The security of the protocols described in this document... I am agnostic on the question, merely seeking consistency.] [What follows starts from section 1, graf 1:] server. Currently, the client must extract the domain name from the certificate, must trust a trust anchor upon which the server's certificate is rooted, and must successfully validate the certificate. ["must trust a trust anchor" seems recursively defined, and should probably be clarified. How about "must have access to a reliable trust anchor (a locally trusted key) from which a signature validation chain to the server's certificate can be built"?] [My suggestion uses the "signature validation chain" terminology, which we haven't defined. We only use the term in the pseudocode in the Appendix, so far. In one other place we talk about "signature validation" but there we're talking about validating DNSSEC signatures. Ideas?] Some people want a different way to authenticate the association of the server's certificate with the intended domain name without trusting an external certificate authority (CA). Given that the DNS administrator for a domain name is authorized to give identifying information about the zone, it makes sense to allow that administrator to also make an authoritative binding between the domain name and a certificate that might be used by a host at that domain name. The easiest way to do this is to use the DNS. This protocol [or document] describes a different way to authenticate the association of the server's certificate with the intended domain name, without trusting an external certificate authority (CA). The DNS administrator for a domain name is already authorized to give identifying information about the zone. Using this protocol, the domain administrator can make an authoritative binding between the domain name, and a certificate that will be used by a TLS server in that domain. 1.1. Certificate Associations A certificate association is formed from a piece of information identifying a certificate with the domain name where the data is found. The data used to identify the certificate consists of either a PKIX certificate or a hash of a PKIX certificate. When using the certificate itself in the certificate association, the entire certificate in the normal format is used. [This is presented without preface, as if we were going to define the term, but we don't really define it. It's also in the passive voice ("is formed"); who forms it?] ["where the data is found"? Where WHAT data is found?] [I found the "certificate association" terminology to be confusing, partly because it looks similar to "certifying authority" but isn't at all related. It seems that the meaning you want is that a "certificate association" is what a TLSA record describes. In that case we could just call it a TLSA record, avoiding the creation of a redundant concept. Later in the document, when defining or describing the TLSA record, the RDATA field is defined to hold the "certificate association data" -- so is the certificate association the trailing part of the RDATA, or is it the whole TLSA record? Do we really need this concept? I would call the trailing part of the RDATA the "certificate or its identifier".] [If we keep the concept, how about defining it this way:] A "certificate association" is a relationship formed by securely identifying a certificate with a domain name. [move remaining sentences to sec 2.1.4] 1.1. Protocol overview A domain administrator creates a TLSA record to securely identify a certificate with a domain name. He or she publishes the record in the secured DNS zone that contains the TLS server's domain name. Each TLSA record identifies a particular certificate that is valid for securing TLS communication. The administrator may create several TLSA records to provide several ways to validate possible certificates. Multiple records are useful when a server is changing from one certificate to another, or when server software running on a single host may provide different certificates to different clients. Each TLS client retrieves the set of published TLSA records, validates them with DNSSEC, and compares them to the certificates provided by the TLS server. If they do not match, the client MUST treat the TLS connection as insecure. This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. [This statement seems to be in the wrong place. I'm not sure where it belongs, but not in the definition of a c...a... Should it instead state "TLSA records can only contain PKIX [RFC 5280] certificates", rather than talking about what this document applies to? Or should the text make it clear that other certificate formats can be used, but only as extensions to the TLSA record defined in this document? In the RDATA Usage field description we take that tack on this question.] 1.2. Securing Certificate Associations This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be be protected by DNSSEC. Because the certificate association was retrieved based on a DNS query, the domain name in the query is by definition associated with the certificate. 1.2. Securing TLSA Records Each TLSA record associates its domain name with the certificate in its RDATA field. Each TLSA record needs to be be protected by DNSSEC. DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and digital signatures to provide authentication of DNS data. Information that is retrieved from the DNS and that is validated using DNSSEC is thereby proved to be the authoritative data. The DNSSEC signature MUST be validated on all responses that use DNSSEC in order to assure the proof of origin of the data. This document does not specify how DNSSEC validation occurs because there are many different proposals for how a client might get validated DNSSEC results. This document only relates to securely getting the DNS information for the certificate association using DNSSEC; other secure DNS mechanisms are out of scope. [removing passive voice] DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and digital signatures to provide authentication of DNS data. Clients retrieve information from the DNS and validate it using DNSSEC, thereby proving it to be the authoritative information. The client MUST validate the DNSSEC signatures on all responses that use DNSSEC, in order to assure the data's proof of origin. This protocol does not specify exactly how clients perform DNSSEC validation, because there are many different proposals for how a client might get validated DNSSEC results. This protocol does require that the client have a way to make DNS queries, and a way to validate the results of those queries via DNSSEC. This protocol only relates to clients which obtain the TLSA record using DNSSEC; other mechanisms are out of scope. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document also makes use of standard PKIX, DNSSEC, and TLS terminology. See [RFC5280], [RFC4033], and [RFC5246] respectively, for these terms. In addition, terms related to TLS-protected application services and DNS names are taken from [RFC6125]. [active voice] 1.3. Terminology Please interpret the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document as described in RFC 2119 [RFC2119]. We also use standard PKIX, DNSSEC, and TLS terminology, defined in [RFC5280], [RFC4033], and [RFC5246]. In addition, we use terms related to TLS-protected application services and DNS names from [RFC6125]. 2. The TLSA Resource Record The TLSA DNS resource record (RR) is used to associate a certificate with the domain name where the record is found. The semantics of how the TLSA RR is interpreted are given later in this document. 2. Fields in the TLSA Resource Record DNS Resource Records are generally defined in [RFC 1034] and [RFC 1035]. The TLSA DNS resource record (RR) associates a certificate with the domain name where the record is found. We describe the detailed semantics of the TLSA RR later in this document. 2.1. TLSA RDATA Wire Format The RDATA for a TLSA RR consists of a one octet usage type field, a one octet selector field, a one octet matching type field and the certificate association data field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage | Selector | Matching Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Certificate Association Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. TLSA RDATA Wire Format The RDATA for a TLSA RR consists of a one octet usage type field, a one octet selector field, a one octet matching type field and the certificate or its identifier. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage | Selector | Matching Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Certificate or its Identifier / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 -- The target certificate MUST pass PKIX validation and MUST chain through a CA certificate matching the TLSA record 1 -- The target certificate MUST pass PKIX validation and MUST match the TLSA record 2 -- The target certificate MUST pass PKIX validation, with any certificate matching the TLSA record considered to be a trust anchor for this validation 3 -- The target certificate MUST match the TLSA record [I would suggest renumbering these so that the simplest form is first, i.e. 3 would become 0. How the others are numbered I don't care.] 2.1.2. The Selector Field A one-octet value, called "selector", specifying which part of the TLS certificate presented by the server will be matched against the association data. [active voice, and changed name of final RDATA field] 2.1.2. The Selector Field A one-octet value, called "selector", specifies which part of the TLS certificate presented by the server will be matched against the TLSA record. 2.1.3. The Matching Type Field A one-octet value, called "matching type", specifying how the certificate association is presented. This value is defined in a new [active voice] 2.1.3. The Matching Type Field A one-octet value, called "matching type", specifies how the certificate association is presented. This value is defined in a new 2.1.4. The Certificate Association Data Field The "certificate association data" to be matched. This field contains the data to be matched. These bytes are either raw data (that is, the full certificate or its SubjectPublicKeyInfo, depending on the selector) for matching type 0, or the hash of the raw data for matching types 1 and 2. The data refers to the certificate in the association, not to the TLS ASN.1 Certificate object. [rename; and clarify, particularly the last sentence.] 2.1.4. The Certificate or its Identifier Field This field contains the data to be matched against the certificates provided by the TLS server. If the matching type is 0, these bytes are the raw data (that is, the full certificate or its SubjectPublicKeyInfo, depending on the selector). If the matching type is 1 or 2, these bytes contain the hash of the full certificate or its SubjectPublicKeyInfo, again depending on the selector. In this section, "the full certificate" means a single one of the individual PKIX [RFC 5280] certificates offered by the TLS server. It does not mean the TLS ASN.1 Certificate object in which these certificates are offered. When constructing this field, start from the entire PKIX certificate in the normal DER format, then possibly extract the SubjectPublicKeyInfo, then possibly hash. This protocol does not allow the use of certificate formats besides PKIX. Doing so would be a reasonable subject for future protocol extensions. o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters. o The Certificate or its Identifier field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters. [That's it for this message. Subsequent suggestions in another message. John] From gnu@toad.com Mon Feb 13 15:24:37 2012 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 7838221F86B7 for ; Mon, 13 Feb 2012 15:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnwX6xZ9W-yq for ; Mon, 13 Feb 2012 15:24:37 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 469BF21F86B4 for ; Mon, 13 Feb 2012 15:24:36 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1DNOVWD009987; Mon, 13 Feb 2012 15:24:31 -0800 Message-Id: <201202132324.q1DNOVWD009987@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Mon, 13 Feb 2012 15:24:31 -0800 From: John Gilmore Subject: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 23:24:37 -0000 According to https://www.ietf.org/id-info/checklist.html section 4.3: If any sort of end-to-end checksum or integrity check is being used (especially, but not limited to, cryptographic checksums or MACs), specify precisely the contents of the fields to be checksummed, and exactly what order the operations are done in. Pay special attention to any area reserved for the checksum itself. Therefore, I think we should clarify the text in section 2.1.4. I also think we should include a worked-out example TLSA RRs in section 2.3 that shows a full certificate (in hexadecimal) in the RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S extracted SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash of that same full certificate, and another TLSA RR that provides a SHA-512 hash of the extracted SubjectPublicKeyInfo. This will provide a simple sanity check for implementers, showing whether they have the extraction and hashing right. (The full certificate in the example can be a small cert, e.g. a self-signed one with few internal fields, and using short keys and signatures, to avoid verbosity). Would the WG like me to work on producing such example text, or is there someone else who has the tools for this close at hand? John From pieter.lexis@os3.nl Mon Feb 13 15:36:09 2012 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 A730C21E8055 for ; Mon, 13 Feb 2012 15:36:09 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F70DA2I+P1l9 for ; Mon, 13 Feb 2012 15:36:09 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id BA4DA21E804C for ; Mon, 13 Feb 2012 15:36:08 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 9561417AA2A; Tue, 14 Feb 2012 00:36:07 +0100 (CET) Received: from [IPV6:2001:980:5dd1:1:5189:12b0:e0bf:cf0] (unknown [IPv6:2001:980:5dd1:1:5189:12b0:e0bf:cf0]) by smtp.os3.nl (Postfix) with ESMTPSA id 18CC317AA0A; Tue, 14 Feb 2012 00:36:06 +0100 (CET) References: <201202132324.q1DNOVWD009987@new.toad.com> User-Agent: K-9 Mail for Android In-Reply-To: <201202132324.q1DNOVWD009987@new.toad.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----CEJF5QCHNAEL1GIB3OM0MNXKCO2IZ1" From: Pieter Lexis Date: Tue, 14 Feb 2012 00:36:03 +0100 To: John Gilmore ,dane@ietf.org,gnu@toad.com Message-ID: <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 23:36:09 -0000 ------CEJF5QCHNAEL1GIB3OM0MNXKCO2IZ1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit WG and John, When making swede I used a selfsigned cert (and a cert signed by comodo using the same csr) to create a test bed. I'd be happy to supply the WG with the certificates, keys and other material to include a (partial) test vector. -- Pieter John Gilmore wrote: According to https://www.ietf.org/id-info/checklist.html section 4.3: If any sort of end-to-end checksum or integrity check is being used (especially, but not limited to, cryptographic checksums or MACs), specify precisely the contents of the fields to be checksummed, and exactly what order the operations are done in. Pay special attention to any area reserved for the checksum itself. Therefore, I think we should clarify the text in section 2.1.4. I also think we should include a worked-out example TLSA RRs in section 2.3 that shows a full certificate (in hexadecimal) in the RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S extracted SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash of that same full certificate, and another TLSA RR that provides a SHA-512 hash of the extracted SubjectPublicKeyInfo. This will provide a simple sanity check for implementers, showing whether they have the extraction and hashing right. (The full certificate in the example can be a small cert, e.g. a self-signed one with few internal fields, and using short keys and signatures, to avoid verbosity). Would the WG like me to work on producing such example text, or is there someone else who has the tools for this close at hand? John _____________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane ------CEJF5QCHNAEL1GIB3OM0MNXKCO2IZ1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit WG and John,

When making swede I used a selfsigned cert (and a cert signed by comodo using the same csr) to create a test bed. I'd be happy to supply the WG with the certificates, keys and other material to include a (partial) test vector.

--
Pieter

John Gilmore <gnu@toad.com> wrote:
According to https://www.ietf.org/id-info/checklist.html section 4.3:

  If any sort of end-to-end checksum or integrity check is being used
  (especially, but not limited to, cryptographic checksums or MACs),
  specify precisely the contents of the fields to be checksummed, and
  exactly what order the operations are done in.  Pay special attention
  to any area reserved for the checksum itself.

Therefore, I think we should clarify the text in section 2.1.4.  

I also think we should include a worked-out example TLSA RRs in
section 2.3 that shows a full certificate (in hexadecimal) in the
RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S extracted
SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash of
that same full certificate, and another TL
 SA RR
that provides a
SHA-512 hash of the extracted SubjectPublicKeyInfo.  This will provide
a simple sanity check for implementers, showing whether they have the
extraction and hashing right.

(The full certificate in the example can be a small cert, e.g. a
self-signed one with few internal fields, and using short keys and
signatures, to avoid verbosity).

Would the WG like me to work on producing such example text, or is
there someone else who has the tools for this close at hand?

	John

dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
------CEJF5QCHNAEL1GIB3OM0MNXKCO2IZ1-- From gnu@toad.com Mon Feb 13 15:57:55 2012 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 E1B1921F864E for ; Mon, 13 Feb 2012 15:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.469 X-Spam-Level: * X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcbe+gYdAIij for ; Mon, 13 Feb 2012 15:57:55 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0321F84C3 for ; Mon, 13 Feb 2012 15:57:54 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1DNveWD011409; Mon, 13 Feb 2012 15:57:40 -0800 Message-Id: <201202132357.q1DNveWD011409@new.toad.com> To: Bill Owens In-reply-to: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <9865C1CC-6798-45EE-83CF-447B5AF9CBE8@bbn.com> Comments: In-reply-to Bill Owens message dated "Sat, 11 Feb 2012 16:49:53 -0500." Date: Mon, 13 Feb 2012 15:57:40 -0800 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 23:57:56 -0000 > >   o  A TLSA RRset whose DNSSEC validation state is secure MUST be used > >      as a certificate association for TLS unless a local policy would > >      prohibit the use of the specific certificate association in the > >      secure TLSA RRset. > > On the one hand, there are a number of characteristics that I'd like > to have in any DANE-aware browser that I use, especially if it mirrors > the Chrome behavior. But those seem like implementation choices, and I > don't think they'd be appropriate in the protocol definition. And as > much as I'd like to say that DANE compliance is absolute, with no > option to override, the choices that have already been made in > existing software and network designs seem to make that an untenable > position. > > In the end, I think our best bet for obtaining sensible behavior will > be lobbying the browser authors, not mandating it in the spec. RFC 2119 is where words like MUST and SHOULD are defined. It says: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. 7. Security Considerations These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification. Indeed, that's the situation here. If the implementer ignores the MUST here, the security of the whole protocol disappears (along with the entire reason we bothered defining the protocol). So I think we should retain the MUST, but should also "take the time to elaborate the security implications of not following" it, in the subsequent sentence or paragraph in the draft. If your code run TLS and makes DNS TLSA queries, while ignoring validated TLSA records, then you have a TLS implementation (with some extra useless DNS overhead), not a TLSA implementation. A TLSA implementation has to give effect to the TLSA records that it sees. To use the preferred wording, it MUST give effect to those records. If your program isn't sure it wants to always use TLSA, then it should have a configuration flag or checkbox for "Use TLSA" or "Don't use TLSA". If the user ticks the "Use TLSA" flag and the TLSA records don't match the cert, the program should abort the TLS connection. John From rbarnes@bbn.com Mon Feb 13 16:07:27 2012 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 E839A21E8017 for ; Mon, 13 Feb 2012 16:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1i5sDbmHRUB for ; Mon, 13 Feb 2012 16:07:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71021E8010 for ; Mon, 13 Feb 2012 16:07:27 -0800 (PST) Received: from [128.89.254.229] (port=57473) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rx5vZ-0005yS-4N; Mon, 13 Feb 2012 19:07:25 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 13 Feb 2012 19:07:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <92893C85-66BB-4DF3-8EA4-613C8107019F@bbn.com> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 00:07:28 -0000 >>> Add to the end of section 1.1: "Three of the four types of >>> association defined in this document ("usages") make use of a >>> _certificate chain_, beginning with the target certificate from the >>> TLS handshake, and ending with a _trust anchor_. This document does >>> not specify how a DANE client constructs this chain; however, one >>> algorithm for doing so is in [RFC5280]. >>=20 >> Could you clarify this citation? AFAICT, RFC 5280 defines an = algorithm >> for validating a certification path, not constructing one (although = it does >> provide some constraints). >=20 > You are correct; I confess I did not make it all the way through RFC = 5280. >=20 > Unfortunately, if RFC 5280 doesn't define path construction, I am not > aware of _any_ specification that does. The easiest way forward would > be to make the sentence read "This document does not specify how a > DANE client constructs or validates this chain" and not give a > reference. >=20 >> ISTM that [the proposed modifications] open up the possibility of >> alternative behaviors to RFC 5280 validation[,] without specifying >> what those alternatives are[.] >=20 > Yes. That is precisely the point of the change. >=20 >> which would be bad for interoperability. >=20 > On the contrary, it is for interoperability's sake that DANE must > *not* attempt to specify chain construction or validation. No two > existing clients use exactly the same algorithm; as far as I know > *nobody* claims complete conformance to RFC 5280 path validation, and > as we've just discovered, path _construction_ may not even be > specified at all. The current DANE spec doesn't say anything about path construction = algorithms. It just specifies constraints on which chains are valid = (however they are constructed).=20 W.r.t. validation: This document is about PKIX certificates. PKIX = certificates are defined by RFC 5280, including how they are validated. = There is nothing new here. =20 Sorry to be so brief. Not feeling well. --Richard= From rbarnes@bbn.com Mon Feb 13 16:09:30 2012 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 C75FB21F8675 for ; Mon, 13 Feb 2012 16:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6bM9-ZFjggL for ; Mon, 13 Feb 2012 16:09:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF121F867A for ; Mon, 13 Feb 2012 16:09:29 -0800 (PST) Received: from [128.89.254.229] (port=57474) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rx5xY-0005z7-MA; Mon, 13 Feb 2012 19:09:28 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 13 Feb 2012 19:09:28 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 00:09:30 -0000 >> But back on topic: as I think I said before, if you have >> trouble with TLS, go there. If you've a peeve with PKIX, >> then go there. This list is for doing DANE which is not >> in the business of re-defining the minutiae of either PKIX >> or TLS. All of our lists are equally open so there's no >> barrier to entry. > > But this is exactly what I've been saying! > > Existing clients do not consistently follow any particular chain > construction or validation algorithm. That's bad, but it's not DANE > (the WG)'s job to fix. Therefore, DANE (the spec) must not require any > particular chain construction or validation algorithm! Construction: There's nothing in this document about that. Validation: We inherit that by using PKIX certs. (See other message.) --Richard From zack.weinberg@gmail.com Mon Feb 13 16:24:05 2012 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 0D88D21F8671 for ; Mon, 13 Feb 2012 16:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPn6cNahKbyN for ; Mon, 13 Feb 2012 16:24:04 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC2821F864D for ; Mon, 13 Feb 2012 16:24:04 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8686736obb.31 for ; Mon, 13 Feb 2012 16:24:03 -0800 (PST) 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 :content-transfer-encoding; bh=ucySIHx/6vNtur7qZAaGREWEnWtAQzb8wLzAXXrIMgE=; b=BKGsb3y2YXZz8hs1Dbpbmu3GzOUDpS9sVQCrRk/GVMmDpWbXkrr/dHn9A4CZU1tGXu ObdEZqtHFIzioEPFS3mhupzVvDSMhqwpFIOF67XG8jZ4tP3HZwLWCwsSRfB9SzqQ2Yey SOSF2HB267XTQsgw6wmjsq+HzdL3e/m1U5edw= MIME-Version: 1.0 Received: by 10.182.118.34 with SMTP id kj2mr13598291obb.37.1329179043902; Mon, 13 Feb 2012 16:24:03 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Mon, 13 Feb 2012 16:24:03 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> Date: Mon, 13 Feb 2012 16:24:03 -0800 X-Google-Sender-Auth: E86B32YhAmCIA8JZCgZTV3dvab8 Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 00:24:05 -0000 On Mon, Feb 13, 2012 at 4:09 PM, Richard L. Barnes wrote: >> Existing clients do not consistently follow any particular chain >> construction or validation algorithm. =C2=A0That's bad, but it's not DAN= E >> (the WG)'s job to fix. Therefore, DANE (the spec) must not require any >> particular chain construction or validation algorithm! > > Construction: There's nothing in this document about that. I think it is nonetheless useful to state explicitly that DANE does not require any particular path construction algorithm. > Validation: We inherit that by using PKIX certs. And that's wrong. Have I been insufficiently clear about what the problem is? Many existing clients are *not* conformant to that aspect of RFC 5280 (as pointed out upthread, some of them do plan to change that in the future, but it will be quite some time). It is therefore necessary for DANE to contain an explicit statement that it does not require clients to implement any particular path validation algorithm. zw From paul.hoffman@vpnc.org Mon Feb 13 16:39:41 2012 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 67F3B21F86E8 for ; Mon, 13 Feb 2012 16:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMXHDIyeq4h9 for ; Mon, 13 Feb 2012 16:39:41 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EF59921F86E5 for ; Mon, 13 Feb 2012 16:39:40 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1E0ddim024384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 13 Feb 2012 17:39:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Mon, 13 Feb 2012 16:39:38 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 00:39:41 -0000 On Feb 13, 2012, at 4:24 PM, Zack Weinberg wrote: > On Mon, Feb 13, 2012 at 4:09 PM, Richard L. Barnes wrote: >>> Existing clients do not consistently follow any particular chain >>> construction or validation algorithm. That's bad, but it's not DANE >>> (the WG)'s job to fix. Therefore, DANE (the spec) must not require any >>> particular chain construction or validation algorithm! >> >> Construction: There's nothing in this document about that. > > I think it is nonetheless useful to state explicitly that DANE does > not require any particular path construction algorithm. -1. There are lots of things that the document does not contain. >> Validation: We inherit that by using PKIX certs. > > And that's wrong. Have I been insufficiently clear about what the > problem is? We might agree on the problem and disagree on your propsed solution. --Paul Hoffman From paul.hoffman@vpnc.org Mon Feb 13 16:44:51 2012 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 BC8E321E8043 for ; Mon, 13 Feb 2012 16:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eOrr7+8oQr1 for ; Mon, 13 Feb 2012 16:44:50 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2421E802D for ; Mon, 13 Feb 2012 16:44:50 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1E0iokM024548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 17:44:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201202132324.q1DNOVWD009987@new.toad.com> Date: Mon, 13 Feb 2012 16:44:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202132324.q1DNOVWD009987@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 00:44:51 -0000 On Feb 13, 2012, at 3:24 PM, John Gilmore wrote: > According to https://www.ietf.org/id-info/checklist.html section 4.3: >=20 > If any sort of end-to-end checksum or integrity check is being used > (especially, but not limited to, cryptographic checksums or MACs), > specify precisely the contents of the fields to be checksummed, and > exactly what order the operations are done in. Pay special attention > to any area reserved for the checksum itself. >=20 > Therefore, I think we should clarify the text in section 2.1.4. =20 As always, specific wording is appreciated. We've worked on this section = a lot, and may have lost some of the clarity you desire. > I also think we should include a worked-out example TLSA RRs in > section 2.3 that shows a full certificate (in hexadecimal) in the > RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S extracted > SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash of > that same full certificate, and another TLSA RR that provides a > SHA-512 hash of the extracted SubjectPublicKeyInfo. This will provide > a simple sanity check for implementers, showing whether they have the > extraction and hashing right. If someone does this work, I would prefer that in goes in an appendix. NOTE HOWEVER, that even if we get two people to assure that the examples = are right, there is a good chance they will be wrong AND WILL MESS UP = IMPLEMENTERS. We have seen this over and over in the IETF, and as author = of some of those documents, I'm pretty gun-shy here, strongly preferring = to let "the market" work it out with dynamic test code that is not = locked into an RFC. Someone just discovered a many-years-old error in = the PKIX spec, for example. --Paul Hoffman From zack.weinberg@gmail.com Mon Feb 13 18:33:35 2012 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 2772F21F8733 for ; Mon, 13 Feb 2012 18:33:35 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S4fZfhPrOcr for ; Mon, 13 Feb 2012 18:33:34 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1A921F86EA for ; Mon, 13 Feb 2012 18:33:34 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8840694obb.31 for ; Mon, 13 Feb 2012 18:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7qK6ffkAp6IvrtA+f+bD+ne3urdvIziN97ZWQJ9vIPs=; b=CgXtXfudp7+2KCtVzc5OmA5U6e4Hz2bnYGRZKOy3SzYXYZmySO5XlDONUJ/s7TF94D 23M2zeaeuz+U8c2FLMmK4mdWij81LQ+i7iMcoqiM645wPuY9YHCLC1jRgsxnmM10s45O HlJkkrkpSpPFZn3rlBG8aBw08hxzoqaWy1aVc= Received: by 10.182.38.7 with SMTP id c7mr13573414obk.44.1329186814113; Mon, 13 Feb 2012 18:33:34 -0800 (PST) Received: from ardsley.local (99-113-33-155.lightspeed.sntcca.sbcglobal.net. [99.113.33.155]) by mx.google.com with ESMTPS id on10sm8359586obc.11.2012.02.13.18.33.33 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 18:33:33 -0800 (PST) Sender: Zack Weinberg Message-ID: <4F39C7FC.1080206@sv.cmu.edu> Date: Mon, 13 Feb 2012 18:33:32 -0800 From: Zack Weinberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 02:33:35 -0000 On 2012-02-13 4:39 PM, Paul Hoffman wrote: > On Feb 13, 2012, at 4:24 PM, Zack Weinberg wrote: >> I think it is nonetheless useful to state explicitly that DANE does >> not require any particular path construction algorithm. > > -1. There are lots of things that the document does not contain. Why is it important to you that the document not contain this statement? >>> Validation: We inherit that by using PKIX certs. >> >> And that's wrong. Have I been insufficiently clear about what the >> problem is? > > We might agree on the problem and disagree on your propsed solution. Just to make sure we actually agree on the problem, would you mind saying what you think it is, in your own words? zw From rbarnes@bbn.com Mon Feb 13 19:29:41 2012 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 8C33B21F878E for ; Mon, 13 Feb 2012 19:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ica9HdYu7-mU for ; Mon, 13 Feb 2012 19:29:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F196B21F878A for ; Mon, 13 Feb 2012 19:29:40 -0800 (PST) Received: from [128.89.254.233] (port=58083) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rx95E-00078r-TJ; Mon, 13 Feb 2012 22:29:37 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 13 Feb 2012 22:29:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> To: Zack Weinberg X-Mailer: Apple Mail (2.1084) Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 03:29:41 -0000 >>> Existing clients do not consistently follow any particular chain >>> construction or validation algorithm. That's bad, but it's not DANE >>> (the WG)'s job to fix. Therefore, DANE (the spec) must not require = any >>> particular chain construction or validation algorithm! >>=20 >> Construction: There's nothing in this document about that. >=20 > I think it is nonetheless useful to state explicitly that DANE does > not require any particular path construction algorithm. >=20 >> Validation: We inherit that by using PKIX certs. >=20 > And that's wrong. Have I been insufficiently clear about what the > problem is? Many existing clients are *not* conformant to that aspect > of RFC 5280 (as pointed out upthread, some of them do plan to change > that in the future, but it will be quite some time). >=20 > It is therefore necessary for DANE to contain an explicit statement > that it does not require clients to implement any particular path > validation algorithm. If the document doesn't say anything about path validation, then what = the are DANE records talking about in the first place? Suppose there's a client that validates cert chains by checking whether = each cert in the chain contains more octets than the prior cert. Or = whether the serial numbers are in ascending order. Or whether the = signatures are valid, but regardless of, say, the CA bit? What does = DANE tell these guys? I think I agree with Paul here: There are some implementors that think = they're doing good path validation, which may or may not be RFC 5280 = compliant. I don't see the benefit of giving those implementors a warm = fuzzy here, most obviously because (1) they evidently don't care whether = they're doing compliant validation or not, and (2) blindly opening the = door to non-standard validation algorithms is just nihilism (see above). = =20 --Richard From zack.weinberg@gmail.com Mon Feb 13 19:51:04 2012 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 B220221E8043 for ; Mon, 13 Feb 2012 19:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnCN7g08Oo8r for ; Mon, 13 Feb 2012 19:51:04 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2415921E8021 for ; Mon, 13 Feb 2012 19:51:04 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8922214obb.31 for ; Mon, 13 Feb 2012 19:51:03 -0800 (PST) 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 :content-transfer-encoding; bh=OBwYMeF750dqHK7+B0fi2RKNRXcmFyBzoM5bxlHuQXs=; b=hacZMzu4g4Awaevwn7tbQvhDmwkCJzGhy44vyPgBTfyd6KxtG4i8K2/F+Zg6GmbGfI w0Y8PuckYtjPTMqycJInwu9SxrnNJyD3d7m1qdp2NgIeYtB+GQCCN6tAKLNeTbSsYCKN rw8W7JE6Q2DUWScvfVjVGpnKoYvLelxDVptdQ= MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr14214192obc.7.1329191463689; Mon, 13 Feb 2012 19:51:03 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Mon, 13 Feb 2012 19:51:03 -0800 (PST) In-Reply-To: <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> Date: Mon, 13 Feb 2012 19:51:03 -0800 X-Google-Sender-Auth: o8tQ8hxz1Vx96IxoSM0Vl0DYPC4 Message-ID: From: Zack Weinberg To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 03:51:05 -0000 On Mon, Feb 13, 2012 at 7:29 PM, Richard L. Barnes wrote: > If the document doesn't say anything about path validation, then what the= are > DANE records talking about in the first place? They're talking about whatever the client's chain construction algorithm produced, and they modify the behavior of its validation algorithm. This can be defined without having to require any particular construction or validation algorithms. > Suppose there's a client that validates cert chains by checking whether e= ach cert > in the chain contains more octets than the prior cert. Or whether the ser= ial numbers > are in ascending order.=C2=A0Or whether the signatures are valid, but reg= ardless of, say, > the CA bit? What does DANE tell these guys? It is not for DANE to tell them that they are doing validation wrong. > I think I agree with Paul here: There are some implementors that think th= ey're > doing good path validation, which may or may not be RFC 5280 compliant. >=C2=A0I don't see the benefit of giving those implementors a warm fuzzy he= re It's not about giving implementors warm fuzzies; it's about removing an out-of-scope requirement from a specification where it does not belong (and incidentally helping adoption and interoperability). zw From lists+keyassure@seantek.com Mon Feb 13 22:12:12 2012 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 CCFF621F871D for ; Mon, 13 Feb 2012 22:12:12 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwWPC6rUIO7I for ; Mon, 13 Feb 2012 22:12:11 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id ABAF121F871C for ; Mon, 13 Feb 2012 22:12:11 -0800 (PST) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9368C22E247 for ; Tue, 14 Feb 2012 01:12:04 -0500 (EST) Message-ID: <4F39FB32.8000108@seantek.com> Date: Mon, 13 Feb 2012 22:12:02 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F36D94D.2070707@seantek.com> In-Reply-To: <4F36D94D.2070707@seantek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 06:12:13 -0000 On 2/11/2012 1:10 PM, Sean Leonard wrote: > See "Re: libpkix maintenance plan" and the Google Spreadsheet "RFC > 5280 vs. CERT_PKIXVerifyCert" . libpkix does, in > fact, fully comply with RFC 5280. For those who cannot read Google Spreadsheets or have an aversion to doing so, here is the CSV version: http://www.seantek.com/rfc5280/RFC5280vCERT_PKIXVerifyCert.csv No promises of it being updated. -Sean From lists+keyassure@seantek.com Mon Feb 13 22:44:07 2012 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 E69F221E8078 for ; Mon, 13 Feb 2012 22:44:06 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZhoZXhQHJbH for ; Mon, 13 Feb 2012 22:44:05 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F135121F86C1 for ; Mon, 13 Feb 2012 22:43:59 -0800 (PST) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6CA0522E247 for ; Tue, 14 Feb 2012 01:43:53 -0500 (EST) Message-ID: <4F3A02A7.60901@seantek.com> Date: Mon, 13 Feb 2012 22:43:51 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 06:44:07 -0000 On 2/13/2012 7:51 PM, Zack Weinberg wrote: > On Mon, Feb 13, 2012 at 7:29 PM, Richard L. Barnes > wrote: >> Suppose there's a client that validates cert chains by checking >> whether each cert >> in the chain contains more octets than the prior cert. Or whether the >> serial numbers >> are in ascending order. Or whether the signatures are valid, but >> regardless of, say, >> the CA bit? What does DANE tell these guys? > It is not for DANE to tell them that they are doing validation wrong. > >> I think I agree with Paul here: There are some implementors that >> think they're >> doing good path validation, which may or may not be RFC 5280 compliant. >> I don't see the benefit of giving those implementors a warm fuzzy here > It's not about giving implementors warm fuzzies; it's about removing > an out-of-scope requirement from a specification where it does not > belong (and incidentally helping adoption and interoperability). Uh, what you are suggesting might help adoption but will definitely hinder interoperability. Implementation 1 interprets validating the certificate in the sentence: "Currently, the client must extract the domain name from the certificate, must trust a trust anchor upon which the server's certificate is rooted, and must successfully validate the certificate." in Section 1 of the DANE draft, as requiring that each certificate has ascending serial numbers. Implementation 2 interprets the same language, as requiring that each certificate has descending serial numbers. Interoperability NOT achieved! If you define validation to an objective standard (PKIX validation = RFC 5280 validation), then as long as: a) Implementation 1 implements the required features of the standard, b) Implementation 2 implements the required features of the standard, and c) the DANE record identifies a certificate chain that only exhibits features limited to the required features of the standard, THEN: Implementation 1 and Implementation 2 will achieve the same result (valid/not valid). Interoperability achieved! If the DANE record identifies a certificate chain that exhibits exotic features not pinned down by the standard, then one should not expect interoperability. That is life. That is why DANE record creators should limit themselves to certificate chains that exhibit only that subset of features that are pinned down by the standard. If you don't have a standard, you have no pins. And if you have no pins, you have an empty interoperability set. -Sean From paul.hoffman@vpnc.org Tue Feb 14 07:14:19 2012 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 34B0521F87E8 for ; Tue, 14 Feb 2012 07:14:19 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaandQ3o3GP8 for ; Tue, 14 Feb 2012 07:14:18 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A020921F87FD for ; Tue, 14 Feb 2012 07:14:18 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1EFEHLX057936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Feb 2012 08:14:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F3A02A7.60901@seantek.com> Date: Tue, 14 Feb 2012 07:14:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <57747BE4-6D23-4BF7-BC6B-760742E8D856@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> <4F3A02A7.60901@seantek.com> To: Sean Leonard X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 15:14:19 -0000 On Feb 13, 2012, at 10:43 PM, Sean Leonard wrote: > Uh, what you are suggesting might help adoption but will definitely = hinder interoperability. Zack hasn't even shown that it will help adoption. As he says, some PKIX = implementations do not follow the path validation given in 5280. This = would lead one to believe that those developers don't care what we say = about path validation. --Paul Hoffman From mrex@sap.com Tue Feb 14 14:08:45 2012 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 E815C21E8028 for ; Tue, 14 Feb 2012 14:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbnYjoo8+HWF for ; Tue, 14 Feb 2012 14:08:45 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B027821E800E for ; Tue, 14 Feb 2012 14:08:31 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1EM8Tpt003768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Feb 2012 23:08:29 +0100 (MET) From: Martin Rex Message-Id: <201202142208.q1EM8TwD017864@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 14 Feb 2012 23:08:29 +0100 (MET) In-Reply-To: from "Paul Hoffman" at Feb 13, 12 04:44:49 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] Hash specs, and examples in sec. 2.3 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: Tue, 14 Feb 2012 22:08:46 -0000 Paul Hoffman wrote: > > > I also think we should include a worked-out example TLSA RRs in > > section 2.3 that shows a full certificate (in hexadecimal) in the > > RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S extracted > > SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash of > > that same full certificate, and another TLSA RR that provides a > > SHA-512 hash of the extracted SubjectPublicKeyInfo. This will provide > > a simple sanity check for implementers, showing whether they have the > > extraction and hashing right. > > If someone does this work, I would prefer that in goes in an appendix. > > NOTE HOWEVER, that even if we get two people to assure that the examples > are right, there is a good chance they will be wrong AND WILL MESS UP > IMPLEMENTERS. We have seen this over and over in the IETF, and as author > of some of those documents, I'm pretty gun-shy here, strongly preferring > to let "the market" work it out with dynamic test code that is not locked > into an RFC. Someone just discovered a many-years-old error in the PKIX > spec, for example. This sounds really scary to me, Paul. The reason why we produce standards is that people *OUTSIDE* of the IETF can implement them without having participated discussions. Your messages suggests that there might be to much "hot air" and too little running code & experience for the current document to be useful for creating independent interoperable implementations. But you should keep in mind that a typical implementation receives much less review than what dane-protocol could receive. I believe, if we can not produce examples that can be easily reviewed for correctness, then this is more likely a sign of unnecessary complexity in the protocol design or lack of clarity in the document, rather than inability to ensure that examples are correct. My personal experience is, that with more detail and redundancy it is easier to (a) recognize and (b) compensate defects in the spec when implementing it. A very fruitful means to review a spec for inconsistencies and ambiguities, is to implement it (and that is what I thought the "we believe in running code" refers to). -Martin From paul.hoffman@vpnc.org Tue Feb 14 15:06:03 2012 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 CCE7821E8105 for ; Tue, 14 Feb 2012 15:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSnfKMDvEa0q for ; Tue, 14 Feb 2012 15:06:03 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 22D6D21E800E for ; Tue, 14 Feb 2012 15:06:03 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1EN62OY081199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 14 Feb 2012 16:06:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202142208.q1EM8TwD017864@fs4113.wdf.sap.corp> Date: Tue, 14 Feb 2012 15:06:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5578E1-CC57-4511-A7C1-7E65CC436B84@vpnc.org> References: <201202142208.q1EM8TwD017864@fs4113.wdf.sap.corp> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 23:06:03 -0000 On Feb 14, 2012, at 2:08 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >>> I also think we should include a worked-out example TLSA RRs in >>> section 2.3 that shows a full certificate (in hexadecimal) in the >>> RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S = extracted >>> SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash = of >>> that same full certificate, and another TLSA RR that provides a >>> SHA-512 hash of the extracted SubjectPublicKeyInfo. This will = provide >>> a simple sanity check for implementers, showing whether they have = the >>> extraction and hashing right. >>=20 >> If someone does this work, I would prefer that in goes in an = appendix. >>=20 >> NOTE HOWEVER, that even if we get two people to assure that the = examples >> are right, there is a good chance they will be wrong AND WILL MESS UP >> IMPLEMENTERS. We have seen this over and over in the IETF, and as = author >> of some of those documents, I'm pretty gun-shy here, strongly = preferring >> to let "the market" work it out with dynamic test code that is not = locked >> into an RFC. Someone just discovered a many-years-old error in the = PKIX >> spec, for example. >=20 > This sounds really scary to me, Paul. It should. We spend inordinate amounts of time arguing about what to do = when "helpful" examples in protocol specs in fact turn out to be = harmful. > The reason why we produce standards is that people *OUTSIDE* of the = IETF > can implement them without having participated discussions. =20 Yes. > Your > messages suggests that there might be to much "hot air" and too little > running code & experience for the current document to be useful > for creating independent interoperable implementations. No, they don't suggest that at all. This particular message suggests = that the best way to help developers is to not make it too easy to copy = examples and think they don't have to read the spec. Notice the = difference? Since you read the list, you know that there are already multiple = initial implementations out there. None of those developers came to the = list and said "I can't do this unless you put more examples in the = document". They seem to be testing with each other just fine. > But you should keep in mind that a typical implementation receives > much less review than what dane-protocol could receive. Absolutely correct. > I believe, if we can not produce examples that can be easily reviewed > for correctness, then this is more likely a sign of unnecessary = complexity > in the protocol design or lack of clarity in the document, rather than > inability to ensure that examples are correct. We would disagree about that. > My personal experience is, that with more detail and redundancy it > is easier to (a) recognize and (b) compensate defects in the spec > when implementing it. A very fruitful means to review a spec for > inconsistencies and ambiguities, is to implement it > (and that is what I thought the "we believe in running code" refers = to). No offense, but is this really hurting your ability to actively = implement DANE? Or are you saying that you believe this is true for = other, unnamed developers? Again, the IETF has decades of experience with problems of examples that = were reviewed, but insufficiently. Why is TLSA different? --Paul Hoffman From mrex@sap.com Tue Feb 14 15:19:58 2012 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 6A14D21F8735 for ; Tue, 14 Feb 2012 15:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJgt+yjcV-nb for ; Tue, 14 Feb 2012 15:19:58 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7458421F8722 for ; Tue, 14 Feb 2012 15:19:55 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1ENJstx008936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Feb 2012 00:19:54 +0100 (MET) From: Martin Rex Message-Id: <201202142319.q1ENJrZe022008@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 15 Feb 2012 00:19:53 +0100 (MET) In-Reply-To: <9810E03A-78C5-4D5F-8157-B0A75AFB5D1E@vpnc.org> from "Paul Hoffman" at Feb 11, 12 09:41:59 am 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] dane-protocol-16 lacks real introductions 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: Tue, 14 Feb 2012 23:19:58 -0000 Paul Hoffman wrote: > >John Gilmore wrote: >> >> Howabout an abstract like: >> >> Encrypted communication on the Internet often uses Transport Level >> Security (TLS), which depends on third parties to certify the keys >> used. This document improves on that situation by enabling the >> administrator of a domain name to certify the keys used in that >> domain's TLS servers. This requires matching improvements in TLS >> client software, but no change in TLS server software. >> >> This gets rid of a lot of jargon ("bindings of keys", "entities that >> operate the DNS", "PKIX certificates") but says the same thing. > > Works for me. Do others like this? > (And, yes, I think we can ignore DTLS until the body of the spec.) The purpose "enabling the administrator of a domain name to certify ..." is IMHO falling short, in that it mentions only one of three purposes. The additional purposes of DANE are (2) confirming or (3) repudiating certificates issued by well-known CAs from the TLS X.509 PKI for DNS names. -Martin From zack.weinberg@gmail.com Tue Feb 14 15:20:38 2012 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 15CFE21F8763 for ; Tue, 14 Feb 2012 15:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5haKOB-5XcwL for ; Tue, 14 Feb 2012 15:20:36 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2592821F872B for ; Tue, 14 Feb 2012 15:20:36 -0800 (PST) Received: by obbwd15 with SMTP id wd15so656728obb.31 for ; Tue, 14 Feb 2012 15:20:22 -0800 (PST) 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=agJM8WcLwUfceTJ89GLSDdvf1t43KQGHHGNLVJ9tvks=; b=F84bIiHqc5FY3nvJqj5whiG2YOEfwBgx/pJ9EH0vC/25yWpZATxy+JZWuk0OnjFu6L +R3zTZthlwzWag7aHcKY9gxoQkeR1mIKbMVf1Ob6SSEh/2jbIxI1EJVVRdujD4JeNd7Z yM2I1A2GlNjDKQzuBZKXDrFh0yKUZEsxpaWrk= MIME-Version: 1.0 Received: by 10.182.118.34 with SMTP id kj2mr16733781obb.37.1329261622079; Tue, 14 Feb 2012 15:20:22 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Tue, 14 Feb 2012 15:20:22 -0800 (PST) In-Reply-To: <57747BE4-6D23-4BF7-BC6B-760742E8D856@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> <4F3A02A7.60901@seantek.com> <57747BE4-6D23-4BF7-BC6B-760742E8D856@vpnc.org> Date: Tue, 14 Feb 2012 15:20:22 -0800 X-Google-Sender-Auth: Yv5urtxDW6DOYFyxGoyyrkR7HR0 Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 23:20:38 -0000 On Tue, Feb 14, 2012 at 7:14 AM, Paul Hoffman wrote: > Zack hasn't even shown that it will help adoption. As he says, some PKIX implementations do not follow the path validation given in 5280. This would lead one to believe that those developers don't care what we say about path validation. I think this thread has gotten wound up to the point where we are just throwing strawmen at each other. Also I have a deadline for an unrelated project in two days, so I need to let this go for now. I will come back next week with specific examples of how real implementations differ from 5280 and/or 4158; I think that will put this particular conversation on much sounder footing. For right now, though, I want to say that the scenario I think most likely if the existing wording survives into the final draft is that TLSA records will have the side effect of *switching* clients into 5280 compliance mode, and that there are concrete ways in which that would be Bad (can't go into detail now, search for "transvalidity"). zw From mrex@sap.com Tue Feb 14 15:36:46 2012 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 D9A4921E8130 for ; Tue, 14 Feb 2012 15:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.126 X-Spam-Level: X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxPdHx1wyAkt for ; Tue, 14 Feb 2012 15:36:46 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E9FE221E8147 for ; Tue, 14 Feb 2012 15:36:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1ENabCJ007528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Feb 2012 00:36:42 +0100 (MET) From: Martin Rex Message-Id: <201202142336.q1ENabrq022931@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Wed, 15 Feb 2012 00:36:37 +0100 (MET) In-Reply-To: from "Zack Weinberg" at Feb 11, 12 11:34:52 am 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] WG Last Call item: PKIX validation 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: Tue, 14 Feb 2012 23:36:47 -0000 Zack Weinberg wrote: > >Stephen Farrell wrote: >> >>Zack Weinberg wrote: >>> >>> You are correct; I confess I did not make it all the way through RFC 5280. >> >> Hang on. Are you saying that you're being highly critical >> of a document you've not actually read? You must be kidding. ;-) A document the size of PKIX (rfc5280) that could only be understood if read in its entirety would definitely belong to the garbage bin. And PKIX in particular is so pretty confusing and contains a number of inconsistencies and defects that I believe no one in the IETF has thoroughly review it, including WG chairs and document authors. If "having read" would mean anything, then we would be done with assigning authorship, any kind of review would be redundant. > > I am objecting to the inclusion in DANE of a *requirement to comply > with* RFC 5280, RFC 4158, or any other published standard for path > construction or validation that may be found, because I know that many Neither TLS client nor TLS servers should use RFC-4158 *AT ALL*. A sensible implementation of TLS will restrict itself to pure certificate path validation and require the CA that issued the PKI credential to provide a complete and well-formed certification path. So an end entity would verify that path on import of the PKI credential and store it, send it in a TLS certificate message to the communication peer in a TLS handshake, and the TLS peer would also simply verify the well-formed certification path when receiving the Certificate handshake message. The mess that we're seeing in the installed base is due to - serious lack of sensible credential management (verify on import!) of PKI credentials in TLS implementations - many flawed attempts of TLS peers to cover up for the failure of their peer to perform sensible PKI credential management, including clear violations of the TLS protocol spec. -Martin From rbarnes@bbn.com Tue Feb 14 15:41:37 2012 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 5C77621E80FA for ; Tue, 14 Feb 2012 15:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elf4Ij8sZG-U for ; Tue, 14 Feb 2012 15:41:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF621E80DF for ; Tue, 14 Feb 2012 15:41:36 -0800 (PST) Received: from [128.89.255.13] (port=61445) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RxS06-0005Qg-Tz; Tue, 14 Feb 2012 18:41:34 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Tue, 14 Feb 2012 18:41:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <4F36BB18.9070205@cs.tcd.ie> <4F37194F.4060100@nic.cz> <4F372005.8010502@cs.tcd.ie> <382B7F5D-6892-4B30-888F-BADC3E73470D@bbn.com> <4F3A02A7.60901@seantek.com> <57747BE4-6D23-4BF7-BC6B-760742E8D856@vpnc.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1251.1) Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 23:41:37 -0000 >> Zack hasn't even shown that it will help adoption. As he says, some = PKIX implementations do not follow the path validation given in 5280. = This would lead one to believe that those developers don't care what we = say about path validation. >=20 > I think this thread has gotten wound up to the point where we are just > throwing strawmen at each other. Also I have a deadline for an > unrelated project in two days, so I need to let this go for now. >=20 > I will come back next week with specific examples of how real > implementations differ from 5280 and/or 4158; I think that will put > this particular conversation on much sounder footing. >=20 > For right now, though, I want to say that the scenario I think most > likely if the existing wording survives into the final draft is that > TLSA records will have the side effect of *switching* clients into > 5280 compliance mode, and that there are concrete ways in which that > would be Bad (can't go into detail now, search for "transvalidity"). To save people the googling: " # Some certs WOULD be valid if they had the appropriate intermediate = certs # attached to them. We could ignore that, except that Firefox (and = maybe # other browsers) actually cache intermediate certs, causing these certs = to # become valid if you've been surfing for a while! So this code = attempts to # compute whether there are any such certs about! " To head off this argument:=20 This is not an RFC 5280 thing. This is about path construction. If a = browser caches intermediate certs, then it will construct different = certification paths than one that doesn't. Both types of browsers = *validate* certification paths in the same way, namely following RFC = 5280 (section 6, fwiw). As we've agreed before, DANE doesn't have = anything to do with path construction, so transvalidity has nothing to = do with DANE.=20 I think the likely scenario is where we differ: IMO, the most likely = thing is that people leave their validation code exactly as-is (5280 or = not, regardless of what we say), and add DANE checks on top of it. So = it doesn't matter for these people what we say, so we should say the = right thing. --Richard From matthijs@nlnetlabs.nl Wed Feb 15 01:09:56 2012 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 70B3221F85FD for ; Wed, 15 Feb 2012 01:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvnOp9ZrpvHX for ; Wed, 15 Feb 2012 01:09:53 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D5821F85E7 for ; Wed, 15 Feb 2012 01:09:51 -0800 (PST) Received: from [192.168.178.23] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1F99kkf075423 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 15 Feb 2012 10:09:47 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329296990; bh=Qt5B/58vR8f8xK8RbfdK2ADs93il9d3GLMQhjoWysrk=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=g2eliGv/KXPqe1AjRj/kotYqERPXFf2Gc35ATDQWx6HIPaqRnAJPvZuG8/b3ct5nE xQyIiHfZrmN7wLlmXeJOdLaqaL1JI/A63c4RCnYNTsIYlSk9SYNALMzEYWNu9c7q88 2p1akgBX2DTjrveRmvduc6QkPF82Sh1YLsnY8L0E= Message-ID: <4F3B7659.3010904@nlnetlabs.nl> Date: Wed, 15 Feb 2012 10:09:45 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: dane@ietf.org References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 15 Feb 2012 10:09:47 +0100 (CET) Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 09:09:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/11/2012 07:11 PM, Zack Weinberg wrote: > On Sat, Feb 11, 2012 at 9:33 AM, Paul Hoffman wrote: >>> Section 4 just seems like a more verbose version of Section 2.1.1. Propose removing to avoid confusion. >> >> Y'know, I thought of that when I was reviewing it a revision or two ago. Is the WG OK with Jakob and I nuking the section and making sure all the semantics are just in 2.1.1? > > I support removing the duplication, but I'd prefer to keep the section > 4 text and lose the section 2.1.1 text -- it's longer, but it's > clearer IMHO. +1 for that. I support this document being published. Review comments (nits and questions) follow: Section 5: * Last sentence has a double "the the". * First bullet point states that a TLSA RRset that is secure MUST be used as a certificate association for TLS *unless* a local policy would prohibit the use of the association. Does that mean that clients can ignore the binding preference between domain and certificate, given by the DNS administrator? Why is this 'unless' necessary? * The section requires that in some cases the certificate association MUST be marked as unusable. For how long? First thought is for the corresponding TTL, but that value is not trustworthy, so maybe a smaller value SHOULD be encouraged. Section 6: * No Downgrade: Here it says that if the TSLA RRset is bogus, TLS is not attempted at all, while section 5 describes a fallback mechanism to TLS in the normal fashion if zero usable certificate associations are found. To me, having Appendix A.2.2. (Provisioning TSLA Records with NS Records) doesn't make sense. I have never seen before such a section in a publication that introduces a new RRtype for provisioning, why should this one have one? I suggest to remove it. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPO3ZZAAoJEA8yVCPsQCW5uBsIANrolt5JcozTOHneEn6ukCY5 fSZzK/mIJ5j4BkmAXGvbrmAac/bsikPGSulwBtf9KSel3w/p6LtNlOOb4KgMjj59 XCwmt8teiJi37Dlq4UDUfwz0ZqK+qT5bcJUgZqWUnwGnbzIzufZba2qSoIMPhFWM dEd/GTVV+LpYPg+9dORIr+A2ZZgW105HbbVYwzcgGuINRxbHEPnwGR/R1F16obAC 7j3iBPXMCZeVQ5bGF4RIeEodC7BMkzDfFqt4+wm3K237Ae7RbKdUnpcIOyZyGIIR WjMjmjQVkDXFyvZrsXFQrsMQEMFJfKqnF58r1lcmlQqrVTRHUyG9IeEEfDOYjU0= =WB/4 -----END PGP SIGNATURE----- From owens@nysernet.org Wed Feb 15 05:40:21 2012 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 74F9921F8734 for ; Wed, 15 Feb 2012 05:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK9wxb4Yx-EN for ; Wed, 15 Feb 2012 05:40:21 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0B721F872D for ; Wed, 15 Feb 2012 05:40:20 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id A6A06A5A767; Wed, 15 Feb 2012 08:40:18 -0500 (EST) Date: Wed, 15 Feb 2012 08:40:18 -0500 From: Bill Owens To: IETF DANE WG list Message-ID: <20120215134018.GA3119@nysernet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [dane] DANE deployment document? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:40:21 -0000 The group seems to have collected a set of issues during WGLC: - real-world implementations and their adherence to RFC5280 - a perceived lack of introductory and explanatory text - desire for full example records and associated certs - questions around behavior in the presence of local trust anchors and proxies - one more that I want to mention, but first need to read through the list archives to see whether someone else has already pointed to it ;) Would it be reasonable to consider another document to collect all of these, something like 'DANE Deployment Considerations'? It seems as though we have a usable document in draft 16, one that could be used to request an RRTYPE assignment and allow implementations to move forward, and that these issues will not end up causing changes to the normative portions of the standard. We might even have some interoperable implementations to talk about, by the time a deployment draft was ready to be taken forward. Bill. From paul.hoffman@vpnc.org Wed Feb 15 07:23:17 2012 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 569BE21F8523 for ; Wed, 15 Feb 2012 07:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGOZ-zjP5++L for ; Wed, 15 Feb 2012 07:23:16 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE28421F8517 for ; Wed, 15 Feb 2012 07:23:16 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1FFNEFw019592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Feb 2012 08:23:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120215134018.GA3119@nysernet.org> Date: Wed, 15 Feb 2012 07:23:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> References: <20120215134018.GA3119@nysernet.org> To: owens@nysernet.org X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] DANE deployment document? 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 Feb 2012 15:23:17 -0000 On Feb 15, 2012, at 5:40 AM, Bill Owens wrote: > The group seems to have collected a set of issues during WGLC: >=20 > - real-world implementations and their adherence to RFC5280 > - a perceived lack of introductory and explanatory text > - desire for full example records and associated certs > - questions around behavior in the presence of local trust anchors and = proxies > - one more that I want to mention, but first need to read through the = list archives to see whether someone else has already pointed to it ;) >=20 > Would it be reasonable to consider another document to collect all of = these, something like 'DANE Deployment Considerations'? It seems as = though we have a usable document in draft 16, one that could be used to = request an RRTYPE assignment and allow implementations to move forward, = and that these issues will not end up causing changes to the normative = portions of the standard. We might even have some interoperable = implementations to talk about, by the time a deployment draft was ready = to be taken forward. Personal opinion: a deployment considerations document would be a good = place for the "explain the context" discussion that John wants as well, = much better than the protocol document. Note that such a deployment considerations document does *not* need to = be a formal WG item, but certainly should be discussed on this mailing = list as it is put together. --Paul Hoffman From paul.hoffman@vpnc.org Wed Feb 15 07:32:43 2012 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 DB48B21F8559 for ; Wed, 15 Feb 2012 07:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paOvVkFQVUd4 for ; Wed, 15 Feb 2012 07:32:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCBB21F8549 for ; Wed, 15 Feb 2012 07:32:43 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1FFWgck020175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Feb 2012 08:32:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F3B7659.3010904@nlnetlabs.nl> Date: Wed, 15 Feb 2012 07:32:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 15:32:44 -0000 On Feb 15, 2012, at 1:09 AM, Matthijs Mekking wrote: > * First bullet point states that a TLSA RRset that is secure MUST be > used as a certificate association for TLS *unless* a local policy = would > prohibit the use of the association. Does that mean that clients can > ignore the binding preference between domain and certificate, given by > the DNS administrator? Why is this 'unless' necessary? This came out of a discussion on the list where some people wanted it to = be explicit that local policy is allowed. So, yes, it means clients can = ignore anything they like as long as it is due to local policy. > * The section requires that in some cases the certificate association > MUST be marked as unusable. For how long? First thought is for the > corresponding TTL, but that value is not trustworthy, so maybe a = smaller > value SHOULD be encouraged. Why do you say that the TTL value is not trustworthy? I thought that = section 2.2 of RFC 4035 says that it is. > Section 6: > * No Downgrade: Here it says that if the TSLA RRset is bogus, TLS is = not > attempted at all, while section 5 describes a fallback mechanism to = TLS > in the normal fashion if zero usable certificate associations are = found. Note that earlier wording is that if the record is bogus, "this MUST = cause TLS not to be started or, if the TLS negotiation is already in = progress, MUST cause the connection to be aborted". The text in section = 5 does not over-ride this. > To me, having Appendix A.2.2. (Provisioning TSLA Records with NS > Records) doesn't make sense. I have never seen before such a section = in > a publication that introduces a new RRtype for provisioning, why = should > this one have one? I suggest to remove it. How do others feel about this? --Paul Hoffman From paul.hoffman@vpnc.org Wed Feb 15 07:35:12 2012 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 9019B21F85E5 for ; Wed, 15 Feb 2012 07:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jswbVLQolOEk for ; Wed, 15 Feb 2012 07:35:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 27FEF21F85D2 for ; Wed, 15 Feb 2012 07:35:12 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1FFZBZd020375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 Feb 2012 08:35:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F3B7659.3010904@nlnetlabs.nl> Date: Wed, 15 Feb 2012 07:35:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1C1C54D3-F20B-4D35-8061-656BC4E6B1AF@vpnc.org> References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: [dane] Deduplicate usage semantics and put semantics in 4 instead of 2.1.1 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 Feb 2012 15:35:12 -0000 On Feb 15, 2012, at 1:09 AM, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 02/11/2012 07:11 PM, Zack Weinberg wrote: >> On Sat, Feb 11, 2012 at 9:33 AM, Paul Hoffman = wrote: >>>> Section 4 just seems like a more verbose version of Section 2.1.1. = Propose removing to avoid confusion. >>>=20 >>> Y'know, I thought of that when I was reviewing it a revision or two = ago. Is the WG OK with Jakob and I nuking the section and making sure = all the semantics are just in 2.1.1? >>=20 >> I support removing the duplication, but I'd prefer to keep the = section >> 4 text and lose the section 2.1.1 text -- it's longer, but it's >> clearer IMHO. >=20 > +1 for that. It seems like there is a fair amount of support for this editorial = change. Are there any objections? --Paul Hoffman From matthijs@nlnetlabs.nl Wed Feb 15 08:39:05 2012 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 F24DE21E8019 for ; Wed, 15 Feb 2012 08:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi1F83-EVoZA for ; Wed, 15 Feb 2012 08:39:00 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A5F21E8069 for ; Wed, 15 Feb 2012 08:38:59 -0800 (PST) Received: from [192.168.178.23] (a83-160-139-153.adsl.xs4all.nl [83.160.139.153]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1FGcrXC072142 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 17:38:54 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329323938; bh=zXC/MIFKuOjNjXnvUQAgB36QMTZ3Rlog4KVtRh4E8xk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=K0bqVBK90nmHXclo4pQR+ctdtS1Pdbb2SUMmYtpFqf2tX7JdyY5DianzWBWZ7v9aF z+qBb3L2E3XLZhpgscqNqFZvrABwVfWRxrLykvuoyhUs9lQVrhqP8hK359Y8nYQdC0 5fMUodM96uCzq1jKiEQoo/Y0Lz7Rms/hpEseJidw= Message-ID: <4F3BDF9E.3040604@nlnetlabs.nl> Date: Wed, 15 Feb 2012 17:38:54 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: Paul Hoffman References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> In-Reply-To: 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 [213.154.224.1]); Wed, 15 Feb 2012 17:38:55 +0100 (CET) Cc: IETF DANE WG list Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 16:39:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/15/2012 04:32 PM, Paul Hoffman wrote: > On Feb 15, 2012, at 1:09 AM, Matthijs Mekking wrote: > >> * First bullet point states that a TLSA RRset that is secure MUST >> be used as a certificate association for TLS *unless* a local >> policy would prohibit the use of the association. Does that mean >> that clients can ignore the binding preference between domain and >> certificate, given by the DNS administrator? Why is this 'unless' >> necessary? > > This came out of a discussion on the list where some people wanted > it to be explicit that local policy is allowed. So, yes, it means > clients can ignore anything they like as long as it is due to local > policy. I don't like that bit, but I guess if there were strong feelings about it I should let it slide. >> * The section requires that in some cases the certificate >> association MUST be marked as unusable. For how long? First >> thought is for the corresponding TTL, but that value is not >> trustworthy, so maybe a smaller value SHOULD be encouraged. > > Why do you say that the TTL value is not trustworthy? I thought that > section 2.2 of RFC 4035 says that it is. The TTL cannot be trustworthy if the RRset state is intermediate, insecure or bogus. In order to mitigate the effect of caching the results of an attack, you should not use the value of a TTL, especially if its high. Picking a smaller value is a similar approach as implementing a BAD CACHE. >> Section 6: * No Downgrade: Here it says that if the TSLA RRset is >> bogus, TLS is not attempted at all, while section 5 describes a >> fallback mechanism to TLS in the normal fashion if zero usable >> certificate associations are found. > > Note that earlier wording is that if the record is bogus, "this MUST > cause TLS not to be started or, if the TLS negotiation is already in > progress, MUST cause the connection to be aborted". The text in > section 5 does not over-ride this. So if an application receives a bogus TLSA RRset, thus zero usable certificate associations, what happens? TLS is not attempted at all or TLS is attempted in the normal fashion? >> To me, having Appendix A.2.2. (Provisioning TSLA Records with NS >> Records) doesn't make sense. I have never seen before such a >> section in a publication that introduces a new RRtype for >> provisioning, why should this one have one? I suggest to remove >> it. > > > How do others feel about this? > > --Paul Hoffman > > _______________________________________________ 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 Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPO9+eAAoJEA8yVCPsQCW5q+oIALPmwRjkuz6N+Zq7p7F6sBic bj6K5L8gKUwEGNhn6pwFClTkCOC9i+tho2N1VkTo/sRXbpHs3GkfYyLYyDVq5xhg wuhnbi8LW7WdosnYm0p5WwB2r6U62EDUzsyr9aNKaFmaBQcqvK5+t/0kiJNSWnLh 88SHVDaXC95dOUIXXe8AqCTmJijQ6ZPMZFvKan15C3Zkwbz3h13jTM/2U4auQmnZ 0lOyYQCZm7WekaIHLqrJnA/1PY6LB7ZTnCoRm5rbABnfn5DFp1jcE3CO4UAYySb3 MVfSHKxWNBwYasec07J7Q5VxVTXrMUW37x9pyAW4qaI6f1zTxcCNjgVwKJCFEFU= =dMe9 -----END PGP SIGNATURE----- From rbarnes@bbn.com Wed Feb 15 09:28:00 2012 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 114B821F86DB for ; Wed, 15 Feb 2012 09:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETmBSi2aRoq9 for ; Wed, 15 Feb 2012 09:27:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9D21F86D3 for ; Wed, 15 Feb 2012 09:27:56 -0800 (PST) Received: from [128.89.255.14] (port=64650) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rxie1-000JEN-Pl; Wed, 15 Feb 2012 12:27:53 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <1C1C54D3-F20B-4D35-8061-656BC4E6B1AF@vpnc.org> Date: Wed, 15 Feb 2012 12:28:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> <1C1C54D3-F20B-4D35-8061-656BC4E6B1AF@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1251.1) Cc: IETF DANE WG list Subject: Re: [dane] Deduplicate usage semantics and put semantics in 4 instead of 2.1.1 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 Feb 2012 17:28:00 -0000 >>>>> Section 4 just seems like a more verbose version of Section 2.1.1. = Propose removing to avoid confusion. >>>>=20 >>>> Y'know, I thought of that when I was reviewing it a revision or two = ago. Is the WG OK with Jakob and I nuking the section and making sure = all the semantics are just in 2.1.1? >>>=20 >>> I support removing the duplication, but I'd prefer to keep the = section >>> 4 text and lose the section 2.1.1 text -- it's longer, but it's >>> clearer IMHO. >>=20 >> +1 for that. >=20 > It seems like there is a fair amount of support for this editorial = change. Are there any objections? I do like the fact that 2.1.1 has RFC 2119 language. But perhaps the = single sentences from 2.1.1 could be used as first sentences for the = paragraphs in section 4 ?= From paul.hoffman@vpnc.org Wed Feb 15 09:30:10 2012 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 E851921F874A for ; Wed, 15 Feb 2012 09:30:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyvXCoPv7Smh for ; Wed, 15 Feb 2012 09:30:09 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EA21F86F6 for ; Wed, 15 Feb 2012 09:30:09 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1FHU7CF029481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Feb 2012 10:30:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F3BDF9E.3040604@nlnetlabs.nl> Date: Wed, 15 Feb 2012 09:30:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> <4F3BDF9E.3040604@nlnetlabs.nl> To: Matthijs Mekking X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 17:30:11 -0000 On Feb 15, 2012, at 8:38 AM, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 02/15/2012 04:32 PM, Paul Hoffman wrote: >> On Feb 15, 2012, at 1:09 AM, Matthijs Mekking wrote: >>=20 >>> * First bullet point states that a TLSA RRset that is secure MUST=20 >>> be used as a certificate association for TLS *unless* a local=20 >>> policy would prohibit the use of the association. Does that mean=20 >>> that clients can ignore the binding preference between domain and=20 >>> certificate, given by the DNS administrator? Why is this 'unless'=20 >>> necessary? >>=20 >> This came out of a discussion on the list where some people wanted >> it to be explicit that local policy is allowed. So, yes, it means=20 >> clients can ignore anything they like as long as it is due to local=20= >> policy. >=20 > I don't like that bit, but I guess if there were strong feelings about > it I should let it slide. My view is that we either tacitly admit that local policy will be used, = or we pretend that it won't be and then have to deal with that lie = later. >>> * The section requires that in some cases the certificate=20 >>> association MUST be marked as unusable. For how long? First >>> thought is for the corresponding TTL, but that value is not >>> trustworthy, so maybe a smaller value SHOULD be encouraged. >>=20 >> Why do you say that the TTL value is not trustworthy? I thought that=20= >> section 2.2 of RFC 4035 says that it is. >=20 > The TTL cannot be trustworthy if the RRset state is intermediate, > insecure or bogus. In order to mitigate the effect of caching the > results of an attack, you should not use the value of a TTL, = especially > if its high. Picking a smaller value is a similar approach as > implementing a BAD CACHE. Sorry, I mis-read your original comment. I do not think marking an = association that is marked as unusable should be cached. For example, = "insecure" can easily be due to a temporary network failure. Picking any = value other than 0 seems unnecessary to me; what value do you see? >=20 >>> Section 6: * No Downgrade: Here it says that if the TSLA RRset is=20 >>> bogus, TLS is not attempted at all, while section 5 describes a=20 >>> fallback mechanism to TLS in the normal fashion if zero usable=20 >>> certificate associations are found. >>=20 >> Note that earlier wording is that if the record is bogus, "this MUST=20= >> cause TLS not to be started or, if the TLS negotiation is already in=20= >> progress, MUST cause the connection to be aborted". The text in=20 >> section 5 does not over-ride this. >=20 > So if an application receives a bogus TLSA RRset, thus zero usable > certificate associations, what happens? TLS is not attempted at all or > TLS is attempted in the normal fashion? The former. If you see text that would lead you to think the latter, we = should fix that. --Paul Hoffman From gnu@toad.com Wed Feb 15 13:47:49 2012 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 9C30E21E809B for ; Wed, 15 Feb 2012 13:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCp9y972SMfb for ; Wed, 15 Feb 2012 13:47:48 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id CC03021E803D for ; Wed, 15 Feb 2012 13:47:46 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1FLkjWD025789; Wed, 15 Feb 2012 13:46:45 -0800 Message-Id: <201202152146.q1FLkjWD025789@new.toad.com> To: mrex@sap.com In-reply-to: <201202142319.q1ENJrZe022008@fs4113.wdf.sap.corp> References: <201202142319.q1ENJrZe022008@fs4113.wdf.sap.corp> Comments: In-reply-to Martin Rex message dated "Wed, 15 Feb 2012 00:19:53 +0100." Date: Wed, 15 Feb 2012 13:46:45 -0800 From: John Gilmore Cc: dane@ietf.org, Paul Hoffman Subject: Re: [dane] dane-protocol-16 lacks real introductions 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 Feb 2012 21:47:49 -0000 > The purpose "enabling the administrator of a domain name to certify ..." > is IMHO falling short, in that it mentions only one of three purposes. > > The additional purposes of DANE are (2) confirming or (3) repudiating > certificates issued by well-known CAs from the TLS X.509 PKI for DNS names. We're discussing the abstract -- a short paragraph. I was trying for generality and succinctness. We do get into all the details later in the document. If a TLSA record specifies the key for a trust anchor for PKIX validation, for example, then I still consider it to be "certify[ing] the keys used in that domain's TLS servers". The TLS server provides a certificate (in the chain that it sends the client) that uses that key, so the key "is used in that domain's TLS servers". And the TLSA record certifies that that key is usable as a trust anchor. (Other usage types can certify it as other path components.) I don't see how a TLSA record can be used to repudiate a certificate issued by a well-known CA (other than by certifying a different one). For example, there is no usage type of "repudiate this trust anchor". It seems to me that repudiation of bad certs or CAs is just a side effect of the certification of good ones. Am I mistaken? I welcome suggested replacement text for the abstract, if after this explanation you still think that the text is insufficient. John From gnu@toad.com Wed Feb 15 22:57:53 2012 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 25E2E21F84FB for ; Wed, 15 Feb 2012 22:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.517 X-Spam-Level: X-Spam-Status: No, score=0.517 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRfacZqGP6Sm for ; Wed, 15 Feb 2012 22:57:52 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id F3ACD21F84F7 for ; Wed, 15 Feb 2012 22:57:51 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1G6vkWD017608; Wed, 15 Feb 2012 22:57:46 -0800 Message-Id: <201202160657.q1G6vkWD017608@new.toad.com> To: Paul Hoffman In-reply-to: <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Wed, 15 Feb 2012 07:23:13 -0800." Date: Wed, 15 Feb 2012 22:57:46 -0800 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] DANE deployment document? 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 Feb 2012 06:57:53 -0000 > Personal opinion: a deployment considerations document would be a good place for the "explain the context" discussion that John wants as well, much better than the protocol document. > > Note that such a deployment considerations document does *not* need to be a formal WG item, but certainly should be discussed on this mailing list as it is put together. WG Last Call is supposed to be about the document that's been called. If it has issues and the issues aren't addressed in the document, then the document shouldn't proceed toward publication. I haven't proposed any protocol changes -- just editorial changes to how the protocol is explained in the document. The idea that we can publish an incomprehensible or self-contradictory document and then somehow patch things up with a "deploying your incomprehensible or self-contradictory standard" document looks to me like a recipe for unsuccessful adoption by the greater community. Particularly if the "deploying" document isn't a standards-track document. I thought that I (and every other WG member) was being called upon to spend many hours reviewing the document and making concrete suggestions, to make it the document and protocol that we'd all be proud to publish. It's our last chance to do so. If the real point of a WGLC is to just rubber-stamp the document, somebody should've told me not to waste my time. John PS: If anyone perceives a need to rush out a document just to get a TLSA RRTYPE allocated, we should just follow RFC 5395 and ask IANA for one. They'll send our request to a couple of expert reviewers and get back to us shortly. We don't have to publish an RFC to get an RRTYPE. From gnu@toad.com Thu Feb 16 00:31:13 2012 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 0FEE521F85DA for ; Thu, 16 Feb 2012 00:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jG433sX76jsN for ; Thu, 16 Feb 2012 00:31:12 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A521F8576 for ; Thu, 16 Feb 2012 00:31:11 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1G8V7WD021593; Thu, 16 Feb 2012 00:31:07 -0800 Message-Id: <201202160831.q1G8V7WD021593@new.toad.com> To: IETF DANE WG list , gnu@toad.com In-reply-to: <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Wed, 15 Feb 2012 07:23:13 -0800." Date: Thu, 16 Feb 2012 00:31:07 -0800 From: John Gilmore Subject: [dane] Certificate Usages 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 Feb 2012 08:31:13 -0000 Section 2.1.1 of draft-ietf-dane-protocol-16.txt punts the meaning of the certificate usage field to section 4. Section 4 attempts to finally specify the semantics of the four defined TLSA Certificate Usage values. However, Section 4 is hard to understand. First, I suggest that we present these usages in order of increasing complexity. Thus, "Match certificate" would be first, since it is most straightforward - a straight binary comparison with what came over the wire in TLS. Then "PKIX Validation and match end entity certificate", since it only adds one complexity to "Match certificate". Since the same end entity certificate (provided by the TLS server) always has to appear in any certification path, this certificate use doesn't affect the building of certificate validation chains. This also just involves a new straight binary comparison. The next most complex, "PKIX Validation and Chain through CA", involves modifying a complex and poorly documented part of the PKIX Validation process. A naive implementation of this certificate usage could vastly increase the processing time required for building a final certificate validation chain -- possibly requiring the software to try millions of combinations before succeeding. Yet we provide no warning about this, nor make any related suggestions (e.g. website admins should avoid this usage if you want fast web browsing of your site; or programmers, here are some heuristics for making your implementation fast). The most complex, "PKIX Validation and Use Trust Anchor", is poorly defined due to the absence of a dependable description of how path construction works. This usage can't necessarily be done by a naive implementation (or perhaps I don't understand how it works -- which again is a problem, if WG members can't understand the spec, how can ordinary mortals be expected to). Existing TLS implementations will not just have to surround their existing PKIX chain construction code with an extra check, as with the other two certificate usages that involve PKIX. Instead they will have to modify the guts of the chain construction code -- but since chain construction is not standardized, it's unclear exactly what the revised software will have to do. Also, it currently says: 4.3. Pass PKIX Validation and Use Trust Anchor Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that must be used as a trust anchor when validating the end entity certificate given by the server in TLS. This usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor, such as if the domain issues its own certificates under its own CA that is not expected to be in the end users collection of trust anchors. This is the complete description of this certificate usage's semantics! This certificate usage value only appears to work if the matching type field is 0, and if the selector field is 0. If only a hash of a certificate or key is provided, then how can this TLSA record provide a provide a new trust anchor "that is not expected to be in the end user[']s collection of trust anchors"? Yet this constraint is nowhere mentioned. I don't think PKIX validation can even be done when only the key of a trust anchor is known (selector = 1). Additional fields of the trust anchor, such as the CA's name and constraints are required. RFC 5280 says: In Section 6.1, the text describes basic path validation. Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths that may be validated using this key. It goes on to say: The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. To make this Certificate Usage type work with a bare public key, we would need to enhance the PKIX Path Validation described in RFC 5820 by specifying how a bare public key engages in that process. Alternatively, we should only standardize this Certificate Usage type for use with a full certificate provided in the TLSA RDATA. In addition, we should consider suggesting that the trust anchor specified in this Certificate Usage SHOULD be directly used to sign the end-entity certificate provided by the TLS server. This should reduce the opportunities for path construction irregularities. It still offers an advantage over the "Match Certificate" usage, by allowing the TLSA record to not need updating when the TLS server's key is changed. If we reorder the discussion from least complex to most complex, we should consider renumbering the field values in that order as well (so that 0 denotes the least complex usage, and so that the field values are once again described in numerical order). Finally, WG discussion has produced so many varying points of view about path construction that it will be hard to say anything concrete in the I-D about it. But rather than let our silence lead the reader to assume that the certificate usages that modify path construction algorithms are simple or well understood, we should at least warn the reader about the diversity of implementations they are likely to encounter. I suggest adding a paragraph like: 4.5. Complexities of TLSA Certificate Usage TLS specifies a certification path validation algorithm without specifying a path construction algorithm, leaving many details to vary in individual implementations. Some of the complexities hiding in those details are described in "Internet X.509 Public Key Infrastructure: Certification Path Building" [RFC4158]. The addition of TLSA records with certificate usages specifying "Chain via CA" or "Use Trust Anchor" modifies these unspecified algorithms, in ways that can change both the results and the performance of the implementation. Since implementations are free to vary in how they interpret these records, TLS server administrators should carefully consider whether and when to use these certificate usage specifiers, and if used, should test them for interoperability in a variety of TLS clients. John From gnu@toad.com Thu Feb 16 00:37:06 2012 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 9C93721F8638 for ; Thu, 16 Feb 2012 00:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.441 X-Spam-Level: X-Spam-Status: No, score=0.441 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8Z5hk11w5BT for ; Thu, 16 Feb 2012 00:37:06 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0325721F8633 for ; Thu, 16 Feb 2012 00:37:05 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1G8b4WD021787; Thu, 16 Feb 2012 00:37:04 -0800 Message-Id: <201202160837.q1G8b4WD021787@new.toad.com> To: IETF DANE WG list , John Gilmore In-reply-to: <201202160831.q1G8V7WD021593@new.toad.com> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> Comments: In-reply-to John Gilmore message dated "Thu, 16 Feb 2012 00:31:07 -0800." Date: Thu, 16 Feb 2012 00:37:04 -0800 From: John Gilmore Subject: [dane] Certificate Usages (nits) 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 Feb 2012 08:37:06 -0000 Small changes: In 4.1 and 4.2, end the last sentence of each paragraph by saying that these usages limit what certificate can be used "for a given host name, protocol and port". Currently they say "for a given host name", but name prefixing clearly allows multiple different TLS servers at the same host name, which might well use different certificate chains. John From matthijs@nlnetlabs.nl Thu Feb 16 01:11:13 2012 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 1041D21F86E2 for ; Thu, 16 Feb 2012 01:11:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdWsR+cLCveG for ; Thu, 16 Feb 2012 01:11:02 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36E21F85D8 for ; Thu, 16 Feb 2012 01:10:59 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8] (zoidberg.nlnetlabs.nl [IPv6:2001:7b8:206:1:219:d1ff:feb1:85e8]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1G9Av9E055806; Thu, 16 Feb 2012 10:10:57 +0100 (CET) (envelope-from matthijs@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329383458; bh=A4/Xm2D4HN1pCzu01Lu578Mj/ZxI6tbXxWZJbH+mEgc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BnV4FI/KfNrntCkYKLDO0nOLEwiKsSCA6N9iNy+Jl1usi1oev/sObH+kVBwz+nGYE TBg5UPlY313Y5mk6PR2OT6XQTyLt0FqQ23Pcx+8euBTdnaYigQMwqrp8YTcdeFqlD6 QH/qbExP15IoBp3fAfurPwJizMAeoOsoZW91UPpM= Message-ID: <4F3CC821.7060803@nlnetlabs.nl> Date: Thu, 16 Feb 2012 10:10:57 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> <4F3BDF9E.3040604@nlnetlabs.nl> In-Reply-To: X-Enigmail-Version: 1.4a1pre 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::53]); Thu, 16 Feb 2012 10:10:58 +0100 (CET) Cc: IETF DANE WG list Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 09:11:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/15/2012 06:30 PM, Paul Hoffman wrote: > On Feb 15, 2012, at 8:38 AM, Matthijs Mekking wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 02/15/2012 04:32 PM, Paul Hoffman wrote: >>> On Feb 15, 2012, at 1:09 AM, Matthijs Mekking wrote: >>> >>>> * First bullet point states that a TLSA RRset that is secure >>>> MUST be used as a certificate association for TLS *unless* a >>>> local policy would prohibit the use of the association. Does >>>> that mean that clients can ignore the binding preference >>>> between domain and certificate, given by the DNS >>>> administrator? Why is this 'unless' necessary? >>> >>> This came out of a discussion on the list where some people >>> wanted it to be explicit that local policy is allowed. So, >>> yes, it means clients can ignore anything they like as long as >>> it is due to local policy. >> >> I don't like that bit, but I guess if there were strong feelings >> about it I should let it slide. > > My view is that we either tacitly admit that local policy will be > used, or we pretend that it won't be and then have to deal with > that lie later. > >>>> * The section requires that in some cases the certificate >>>> association MUST be marked as unusable. For how long? First >>>> thought is for the corresponding TTL, but that value is not >>>> trustworthy, so maybe a smaller value SHOULD be encouraged. >>> >>> Why do you say that the TTL value is not trustworthy? I >>> thought that section 2.2 of RFC 4035 says that it is. >> >> The TTL cannot be trustworthy if the RRset state is intermediate, >> insecure or bogus. In order to mitigate the effect of caching >> the results of an attack, you should not use the value of a TTL, >> especially if its high. Picking a smaller value is a similar >> approach as implementing a BAD CACHE. > > Sorry, I mis-read your original comment. I do not think marking an > association that is marked as unusable should be cached. For > example, "insecure" can easily be due to a temporary network > failure. Picking any value other than 0 seems unnecessary to me; > what value do you see? I interpret the word mark incorrectly I guess. This makes this review comment a nit. To me, you mark data so that you can make a decision about it in the future. What about 'MUST be considered as unusable' or 'MUST NOT be considered as usable'. >> >>>> Section 6: * No Downgrade: Here it says that if the TSLA >>>> RRset is bogus, TLS is not attempted at all, while section 5 >>>> describes a fallback mechanism to TLS in the normal fashion >>>> if zero usable certificate associations are found. >>> >>> Note that earlier wording is that if the record is bogus, >>> "this MUST cause TLS not to be started or, if the TLS >>> negotiation is already in progress, MUST cause the connection >>> to be aborted". The text in section 5 does not over-ride this. >> >> So if an application receives a bogus TLSA RRset, thus zero >> usable certificate associations, what happens? TLS is not >> attempted at all or TLS is attempted in the normal fashion? > > The former. If you see text that would lead you to think the > latter, we should fix that. Yes, I thought a bogus TLSA RRset leaves you with zero usable certificate associations, thus a fallback can occur. Rereading it again, makes me think that I falsely made that assumption, probably because its in the list of 'determining whether a TLSA RRset can be used'. I also would move the paragraph: If an application receives zero usable certificate associations (not bogus), it processes TLS in the normal fashion without any input from the TLSA records; otherwise, that application attempts to match each certificate association with the TLS server's end entity certificate. towards the end of the section, so that it falls after all references to TSLA RRsets being unusable. Note that I suggested to add '(not bogus)' in there. Best regards, Matthijs > > --Paul Hoffman > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPPMghAAoJEA8yVCPsQCW5ySYH/36mbmuuCYSjiwptXcYgGHvc vQZHRZzvvdMbiz/lBVKrCfXaYUgb6QP0C50TGnNEtGVH+bLnVNTHxtXCC5Z6sOSs FX8Y5fraipujwOCP247QnDXakwdSTWt9P+44UMWzrjIObwRSy1kqPHjRYsER/pbc /0C56FNS7DzaDgeUass25fmX56QY9x7OuNBKqa3h3jkGAVnOF1aZF7rP/N8qcGo8 +jdYr274mIsJQkiexL6tknlUZPnO5YsCar3V1XoWqs3qsrXzi7V5HhXJvQgHzsk8 CZXJZUnATf30P9TROLX4e3bz+zfgHCaWqtFDz1GcyCwLxBwNw+jVN30fuL7efzk= =EGov -----END PGP SIGNATURE----- From gnu@toad.com Thu Feb 16 01:13:45 2012 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 BCD0721F864F for ; Thu, 16 Feb 2012 01:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.407 X-Spam-Level: X-Spam-Status: No, score=0.407 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVqY9ltsApzl for ; Thu, 16 Feb 2012 01:13:43 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id E57BF21F864E for ; Thu, 16 Feb 2012 01:13:42 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1G9DfWD023530; Thu, 16 Feb 2012 01:13:41 -0800 Message-Id: <201202160913.q1G9DfWD023530@new.toad.com> To: IETF DANE WG list , John Gilmore Date: Thu, 16 Feb 2012 01:13:41 -0800 From: John Gilmore Subject: [dane] "First" request TLSA records? 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 Feb 2012 09:13:45 -0000 Section 5 says: An application that complies with this document first requests TLSA records in order to make certificate associations. I don't see why an application must "first" request TLSA records. Is there any problem with applications that "first" open a TCP connection to the destination TLS server, and "second" request TLSA records? Talking to the server will require at least two or three round-trips, for the TCP 3-phase open, plus the TLS client's initial transmission, plus the TLS server's response, before any of the TLSA records are actually needed by the TLS client. While this is happening, a UDP DNS request for a TLSA record could frequently return the record, incurring no additional delay. This section already says that if TLSA processing fails, the TLS connection should be "not started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted", so it clearly anticipates this ordering. Also, it is presumably OK to cache DNS RRsets and reuse them throughout the TTL (without making a second DNS query for them), yet this specifies that the application "requests" the records in order to comply. I recommend removing the word "first", and also clarifying that it's talking about making DNS requests, not some other kind of requests: An implementation of this protocol makes a DNS query for TLSA records (or uses already-retrieved TLSA records, cached within their time to live value), validates these records using DNSSEC, and uses the resulting TLSA records and validation status to modify its responses to the TLS server. I also think there's a problem with the name of section 5: "Use of TLS Certificate Associations in TLS". I think it was meant to say "Use of TLSA Certificate Associations in TLS". But I think it would be clearer to say "Use of TLSA Records in TLS". As explained in an earlier comment, I found the concept of "certificate associations" to be an unnecessary complication in the description. (There's a second mention of "TLS certificate associations" in the first graf under the name, which I think was meant to refer to "TLSA certificate associations" since the cited section 2.1 is about the TLSA RDATA, not about TLS.) John From gnu@toad.com Thu Feb 16 02:29:42 2012 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 4E64321F86DD for ; Thu, 16 Feb 2012 02:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.379 X-Spam-Level: X-Spam-Status: No, score=0.379 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdvKdwetxjzF for ; Thu, 16 Feb 2012 02:29:38 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 2898621F8698 for ; Thu, 16 Feb 2012 02:29:38 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1GATaWD026584; Thu, 16 Feb 2012 02:29:36 -0800 Message-Id: <201202161029.q1GATaWD026584@new.toad.com> To: IETF DANE WG list , John Gilmore Date: Thu, 16 Feb 2012 02:29:36 -0800 From: John Gilmore Subject: [dane] Record creators and MUST? And TLSA protocol name. 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 Feb 2012 10:29:42 -0000 Section 7 specifies particular requirements on implementations in general, though it is entitled "Mandatory-to-Implement Algorithms". (That should possibly be changed.) The first graf requires: A system creating TLSA records that conforms to this specification MUST be able to create TLSA records containing certificate usages 0, 1, 2, and 3. I don't understand why we MUST this. I could presumably build a piece of software that only created TLSA records that used certificate usage 3, and there would be nothing wrong about it. This software doesn't *interpret* TLSA records that arrive from elsewhere; it only creates them. So there's no interoperability problem. This graf can't be talking about a DNS server or a DNS client library, since they will treat the RDATA as opaque. Other DNS software that translates between text and binary RR representations should not be enforcing any constraints on the four fields in the RDATA (e.g. you could make a TLSA RR with certificate usage 255 or 137 and the software should be able to parse or print it properly), but I don't think that needs to be a SHOULD or MUST, since it has no interoperability impact. Users who buy software that screws their ability to experiment or use extensions are not our protocol's problem. So this graf is really about software that e.g. creates a TLSA text record from a PKIX cert, or from command line arguments. And again, interoperability doesn't require that every variant of every field be usable or used. I recommend striking the entire first paragraph, which MUSTs and SHOULDs the cert usage, selector, and hash type fields for systems *creating* TLSA records. For TLSA clients (the second paragraph), the MUST and SHOULDs are in accord with the issue tracker. But let's fix the name from "TLS clients conforming to this specification" to "TLSA clients". That seems to be how we're thinking about this. This brings up the general question of whether we should be referring to this protocol as "TLSA" in places where we talk about "this protocol" or "this document". Indeed we seem to not have come up with a name for this protocol anywhere; I propose that we call it the "TLSA protocol". That should simplify naming in a number of places, including the title of the RFC. (The only catch is: what is TLSA an acronym of? Transport Layer Security Association? Transport Layer Security Augmentation?) Or, as in DANE, Transport Layer Security Authentication? The RRTYPE TLSA was defined in the protocol-00.txt, without a specified expansion. Whatever acronym expansion we use, we should use in the RFC title. See https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt section 4.2 (Full Title): Choosing a good title for an RFC can be a challenge. A good title should fairly represent the scope and purpose of the document without being either too general or too specific. Abbreviations (e.g., acronyms) [ABBR] in a title (as well as the Abstract and the body) must generally be expanded when first encountered. The exception is abbreviations that are so common that every participant in the IETF can be expected to recognize them immediately; examples include (but are not limited to) TCP, IP, SNMP, and FTP. Some cases are marginal, and the decision on expansion may depend upon the specific title. The RFC Editor will make the final judgment, weighing obscurity against complexity. It is often helpful to follow the expansion with the parenthesized abbreviation, as in the following example: Encoding Rules for the Common Routing Encapsulation Extension Protocol (CREEP) So, perhaps "Transport Level Security Authentication (TLSA) using DNS Security" as a title? John From owens@nysernet.org Thu Feb 16 05:31:41 2012 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 8988121F8697 for ; Thu, 16 Feb 2012 05:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JEdKKTK+M-U for ; Thu, 16 Feb 2012 05:31:40 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id 8423D21F8677 for ; Thu, 16 Feb 2012 05:31:40 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id 0A2F9A6E48F; Thu, 16 Feb 2012 08:31:38 -0500 (EST) Date: Thu, 16 Feb 2012 08:31:38 -0500 From: Bill Owens To: John Gilmore Message-ID: <20120216133138.GA92956@nysernet.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160657.q1G6vkWD017608@new.toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202160657.q1G6vkWD017608@new.toad.com> User-Agent: Mutt/1.4.2.3i Cc: IETF DANE WG list Subject: Re: [dane] DANE deployment document? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 13:31:41 -0000 On Wed, Feb 15, 2012 at 10:57:46PM -0800, John Gilmore wrote: > > Personal opinion: a deployment considerations document would be a good place for the "explain the context" discussion that John wants as well, much better than the protocol document. > > > > Note that such a deployment considerations document does *not* need to be a formal WG item, but certainly should be discussed on this mailing list as it is put together. > > WG Last Call is supposed to be about the document that's been called. > If it has issues and the issues aren't addressed in the document, then > the document shouldn't proceed toward publication. I haven't proposed > any protocol changes -- just editorial changes to how the protocol is > explained in the document. > > The idea that we can publish an incomprehensible or self-contradictory > document and then somehow patch things up with a "deploying your > incomprehensible or self-contradictory standard" document looks to me > like a recipe for unsuccessful adoption by the greater community. > Particularly if the "deploying" document isn't a standards-track > document. I thought it should be obvious, but apparently isn't, so I will be explicit; I have closely reviewed the document over the last few drafts and provided my comments to the authors and to the list, and do not believe that it is 'incomprehensible or self-contradictory'. I have the strong impression that the other members of the WG agree, or they would have previously commented as well; of course they can speak to that point if they choose. There are of course some specific points of contention, at least those that I listed and possibly more, but if they don't affect the protocol definition I don't see a need to have them dealt with in the protocol specification. I am not yet persuaded that there is a need for additional explanatory text beyond what is already included in RFC6394. I am arguing that, if further explanation is needed, it should be dealt with in a separate document explicitly written for that purpose. > PS: If anyone perceives a need to rush out a document just to get a > TLSA RRTYPE allocated, we should just follow RFC 5395 and ask IANA for > one. They'll send our request to a couple of expert reviewers and get > back to us shortly. We don't have to publish an RFC to get an RRTYPE. Let me be explicit again; I am not proposing to rush the document, rather to avoid making substantial changes to a document that the group already felt was ready for WGLC, in the name of avoiding delay. I'm glad to learn that an RFC is not required to ask for an RRTYPE, though I wonder whether the expert reviewers would want the draft to at least have passed WGLC. I accept that you are spending many hours reviewing and changing the document; please understand that your requests are requiring us to spend hours reviewing and considering your changes, to a document that some of us, at least, were already satisfied with. Bill. From owens@nysernet.org Thu Feb 16 07:27:28 2012 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 C41DA21F87DE for ; Thu, 16 Feb 2012 07:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br0gJmESWZEn for ; Thu, 16 Feb 2012 07:27:28 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4D21F87DF for ; Thu, 16 Feb 2012 07:27:28 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id 896ABA70077; Thu, 16 Feb 2012 10:27:27 -0500 (EST) Date: Thu, 16 Feb 2012 10:27:26 -0500 From: Bill Owens To: John Gilmore Message-ID: <20120216152726.GE92956@nysernet.org> References: <201202161029.q1GATaWD026584@new.toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202161029.q1GATaWD026584@new.toad.com> User-Agent: Mutt/1.4.2.3i Cc: IETF DANE WG list Subject: Re: [dane] Record creators and MUST? And TLSA protocol name. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:27:28 -0000 On Thu, Feb 16, 2012 at 02:29:36AM -0800, John Gilmore wrote: > Section 7 specifies particular requirements on implementations in > general, though it is entitled "Mandatory-to-Implement Algorithms". > (That should possibly be changed.) > > The first graf requires: > > A system creating TLSA records that conforms to this specification > MUST be able to create TLSA records containing certificate usages 0, > 1, 2, and 3. > > I don't understand why we MUST this. I could presumably build > a piece of software that only created TLSA records that used > certificate usage 3, and there would be nothing wrong about it. > This software doesn't *interpret* TLSA records that arrive from > elsewhere; it only creates them. So there's no interoperability > problem. Lifting that restriction seems reasonable; I don't see any reason to limit implementations that way. > For TLSA clients (the second paragraph), the MUST and SHOULDs are in > accord with the issue tracker. But let's fix the name from "TLS > clients conforming to this specification" to "TLSA clients". That > seems to be how we're thinking about this. +1, though I'm not sure that's the right name (see below) > This brings up the general question of whether we should be referring > to this protocol as "TLSA" in places where we talk about "this > protocol" or "this document". Indeed we seem to not have come up with > a name for this protocol anywhere; I propose that we call it the "TLSA > protocol". That should simplify naming in a number of places, > including the title of the RFC. I'll admit that I haven't really considered this question, but I was under the impression that the protocol is known as 'DNS-Based Authentication of Named Entities (DANE)' and the DNS record that implements it is called 'TLSA', without any particular expansion. That usage may not be consistent, though; for example the Abstract might better say 'DANE (DNS-based...) uses the TLSA record in the DNS to provide bindings of keys to domains... ' If that's the case, the contentious proxy considerations paragraph is wrong in referring to 'the TLSA protocol', and of course I wrote a revision of it containing those words, so clearly I haven't been thinking precisely about the protocol name either. . . > So, perhaps "Transport Level Security Authentication (TLSA) using DNS Security" > as a title? Or in keeping with RFC6394, 'The DNS-Based Authentication of Named Entities (DANE) Protocol Version 1.0' Bill. From pieter.lexis@os3.nl Thu Feb 16 10:27:26 2012 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 569E821F863F for ; Thu, 16 Feb 2012 10:27:26 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRzImKqOkqzf for ; Thu, 16 Feb 2012 10:27:05 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id C5C0611E8087 for ; Thu, 16 Feb 2012 10:27:04 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 7A0B917AA25 for ; Thu, 16 Feb 2012 19:27:03 +0100 (CET) Received: from [192.168.1.37] (82-170-86-166.ip.telfort.nl [82.170.86.166]) by smtp.os3.nl (Postfix) with ESMTPSA id 1CA1617AA1F for ; Thu, 16 Feb 2012 19:27:03 +0100 (CET) Message-ID: <4F3D4A76.70706@os3.nl> Date: Thu, 16 Feb 2012 19:27:02 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: dane@ietf.org References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> In-Reply-To: <20120216152726.GE92956@nysernet.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Record creators and MUST? And TLSA protocol name. 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 Feb 2012 18:27:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/16/2012 04:27 PM, Bill Owens wrote: >> So, perhaps "Transport Level Security Authentication (TLSA) >> using DNS Security" as a title? > > Or in keeping with RFC6394, 'The DNS-Based Authentication of Named > Entities (DANE) Protocol Version 1.0' There will also be a spec for SMIMEA, that is also be a 'The DNS-Based Authentication of Named Entities (DANE)' protocol. So 'The DNS-Based Authentication of Named Entities (DANE) for Transport Layer Security (TLS) Protocol' would be better. Although that might be a bit long.. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPPUpyAAoJELPqGO5ebd4jCH4P/1EWF6HVX+yxPQ69eNhgSPU6 nAlhoI9Ta2I1NefcrKTO23pXRtkYZSwPO4vVOPdg+9Umrp1Ln+3mA7k74N86+Ytq r8J84tJByg/Wjk3CvfLXZQRDebE9VhmH5TflidVaIHwBiyLoHeXMer3HFuV6edef kreYbDL259SiMhZhsCLhNRNmhGUFAd60JAguq9mccFU/aVB/+cJnNw9FRMYLQM1W /N3NtYKrrqPN+X+KcLG4isOynDExPMKrfeEJdidb8xVlnWSBt2z1Bq9da8ScgUA+ pCnXqZK4/fMIQAAXu6k7t82bYJ8BZj7GWr08+R6fQTqOAujOb7aaM38w+5r3Khdg LQGMYqsgvG1dnh/ddJqBZhnpd+xO6BZcIGN2DFxbvJ1nsB8ofXPIQa8SCRWaVBNW PYBL6WgcEbqPgxCD7v+8HxCymcu7T+zDDn8n0fedsT1w81G2T599peonT8IhuQKS zTjHtZdDO0M6nJJKSU2Itt9FFWgVfjVb66DmjCe1wjNSvuiwgGCOs31+KExoJY3i WJ5ZvcXGuHtBmpywtqVWBr47DUbxrVr3dJvVNNGwLCAxLOPupqsp3/RxCQXBKV9K LNC6jSUATBtvuD0pojbCz8a8LI95BsKLT9C06yX+EwJo7JHBwPTiHhRCESG1IAWu LXOZPmHNnHFuvE0wVFFB =mxe/ -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Thu Feb 16 10:48:37 2012 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 6127C11E80A1 for ; Thu, 16 Feb 2012 10:48:37 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8GzQdeWeoxb for ; Thu, 16 Feb 2012 10:48:36 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC5CC11E8074 for ; Thu, 16 Feb 2012 10:48:36 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GImYaC089953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Feb 2012 11:48:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202160657.q1G6vkWD017608@new.toad.com> Date: Thu, 16 Feb 2012 10:48:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160657.q1G6vkWD017608@new.toad.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] DANE deployment document? 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 Feb 2012 18:48:37 -0000 On Feb 15, 2012, at 10:57 PM, John Gilmore wrote: >> Personal opinion: a deployment considerations document would be a = good place for the "explain the context" discussion that John wants as = well, much better than the protocol document. >>=20 >> Note that such a deployment considerations document does *not* need = to be a formal WG item, but certainly should be discussed on this = mailing list as it is put together. >=20 > WG Last Call is supposed to be about the document that's been called. > If it has issues and the issues aren't addressed in the document, then > the document shouldn't proceed toward publication. I haven't proposed > any protocol changes -- just editorial changes to how the protocol is > explained in the document. Actually, you have, but most of what you have proposed so far is a major = editorial overhaul. So far, not many people have supported it. > The idea that we can publish an incomprehensible or self-contradictory > document and then somehow patch things up with a "deploying your > incomprehensible or self-contradictory standard" document looks to me > like a recipe for unsuccessful adoption by the greater community. To date, you are the only person who has claimed that the document is = incomprehensible or self-contradictory. Sure, there have been many = places where it was not clear; we have fixed them as they were exposed. = Others have shown by actual coding that the document is comprehensible. > Particularly if the "deploying" document isn't a standards-track > document. Oh, please. You are saying that a developer who finds a protocol = document incomprehensible or self-contradictory and finds an = informational deployment document is going to stop and say "screw it, I = won't read it unless it is on standards track". That's silly. > I thought that I (and every other WG member) was being called upon to > spend many hours reviewing the document and making concrete > suggestions, to make it the document and protocol that we'd all be > proud to publish. I cannot find "proud to publish" in the WG archives. Everyone is called = on to make the document an accurate description of what the WG believes = is the consensus of the WG. That certainly can mean editorial = improvement: it has meant that at every step of the process. > It's our last chance to do so. If the real point > of a WGLC is to just rubber-stamp the document, somebody should've > told me not to waste my time. And yet no one told you that because it is not true. It is true that if = one person asks for major changes and that request doesn't get much = support in the WG, the chairs might not ask the authors to make the = changes. It is also true that WG members should feel free to comment on = each other's requests without wondering if they will be attacked with = strawmen overstatements. > PS: If anyone perceives a need to rush out a document just to get a > TLSA RRTYPE allocated, we should just follow RFC 5395 and ask IANA for > one. They'll send our request to a couple of expert reviewers and get > back to us shortly. We don't have to publish an RFC to get an RRTYPE. Another strawman. No one has said anything about rushing, and if you = look at the archive, you will see that no one has rushed. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 11:19:11 2012 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 49B4821E8066 for ; Thu, 16 Feb 2012 11:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DPkp07PLlDo for ; Thu, 16 Feb 2012 11:19:10 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C964C21E8053 for ; Thu, 16 Feb 2012 11:19:10 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GJJ98i091737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Feb 2012 12:19:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202160831.q1G8V7WD021593@new.toad.com> Date: Thu, 16 Feb 2012 11:19:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <20B2BED1-C3DC-4F45-A235-5726FB5ACB5B@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Certificate Usages 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 Feb 2012 19:19:11 -0000 On Feb 16, 2012, at 12:31 AM, John Gilmore wrote: > Section 2.1.1 of draft-ietf-dane-protocol-16.txt punts the meaning of > the certificate usage field to section 4. Section 4 attempts to > finally specify the semantics of the four defined TLSA Certificate > Usage values. However, Section 4 is hard to understand. It sounds like you missed the recent thread on this list that asked for = us to wind the material from 4 into 2.1.1, and we said we would unless = there was any strong objection (and there has been none). > First, I suggest that we present these usages in order of increasing > complexity. =20 Presenting the usages in an order other than numeric seems silly to me. = Others might disagree. These are short paragraphs, and we expect = developers reading the document to understand all of them. > The next most complex, "PKIX Validation and Chain through CA", > involves modifying a complex and poorly documented part of the PKIX > Validation process. A naive implementation of this certificate usage > could vastly increase the processing time required for building a > final certificate validation chain -- possibly requiring the software > to try millions of combinations before succeeding. Yet we provide no > warning about this, nor make any related suggestions (e.g. website > admins should avoid this usage if you want fast web browsing of your > site; or programmers, here are some heuristics for making your > implementation fast). Implementation guidance sounds like good material for an implementation = guidance document or appendix. So far, the group seems more inclined = towards the former, but your earlier message indicates you are not. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 11:22:02 2012 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 AB6D921E8077 for ; Thu, 16 Feb 2012 11:22:02 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xxm4JZdChvwT for ; Thu, 16 Feb 2012 11:22:02 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1569221E8075 for ; Thu, 16 Feb 2012 11:22:02 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GJM1G6091912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Feb 2012 12:22:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202160831.q1G8V7WD021593@new.toad.com> Date: Thu, 16 Feb 2012 11:22:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: [dane] Getting rid of usage type 2 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 Feb 2012 19:22:02 -0000 On Feb 16, 2012, at 12:31 AM, John Gilmore wrote: > The most complex, "PKIX Validation and Use Trust Anchor", is poorly > defined due to the absence of a dependable description of how path > construction works. This usage can't necessarily be done by a naive > implementation (or perhaps I don't understand how it works -- which > again is a problem, if WG members can't understand the spec, how can > ordinary mortals be expected to). Existing TLS implementations will > not just have to surround their existing PKIX chain construction code > with an extra check, as with the other two certificate usages that > involve PKIX. Instead they will have to modify the guts of the chain > construction code -- but since chain construction is not standardized, > it's unclear exactly what the revised software will have to do. >=20 > Also, it currently says: >=20 > 4.3. Pass PKIX Validation and Use Trust Anchor >=20 > Certificate usage 2 is used to specify a certificate, or the public > key of such a certificate, that must be used as a trust anchor when > validating the end entity certificate given by the server in TLS. > This usage is sometimes referred to as "trust anchor assertion" and > allows a domain name administrator to specify a new trust anchor, > such as if the domain issues its own certificates under its own CA > that is not expected to be in the end users collection of trust > anchors. >=20 > This is the complete description of this certificate usage's = semantics! >=20 > This certificate usage value only appears to work if the matching type > field is 0, and if the selector field is 0. If only a hash of a > certificate or key is provided, then how can this TLSA record provide > a provide a new trust anchor "that is not expected to be in the end > user[']s collection of trust anchors"? Yet this constraint is nowhere > mentioned. >=20 > I don't think PKIX validation can even be done when only the key of a > trust anchor is known (selector =3D 1). Additional fields of the = trust > anchor, such as the CA's name and constraints are required. RFC 5280 > says: >=20 > In Section 6.1, the text describes basic path validation. Valid > paths begin with certificates issued by a trust anchor. The > algorithm requires the public key of the CA, the CA's name, and any > constraints upon the set of paths that may be validated using this > key. >=20 > It goes on to say: >=20 > The trust anchor information includes: > (1) the trusted issuer name, > (2) the trusted public key algorithm, > (3) the trusted public key, and > (4) optionally, the trusted public key parameters associated > with the public key. >=20 > To make this Certificate Usage type work with a bare public key, we > would need to enhance the PKIX Path Validation described in RFC 5820 > by specifying how a bare public key engages in that process. > Alternatively, we should only standardize this Certificate Usage type > for use with a full certificate provided in the TLSA RDATA. >=20 > In addition, we should consider suggesting that the trust anchor > specified in this Certificate Usage SHOULD be directly used to sign > the end-entity certificate provided by the TLS server. This should > reduce the opportunities for path construction irregularities. It > still offers an advantage over the "Match Certificate" usage, by > allowing the TLSA record to not need updating when the TLS server's > key is changed. Despite what John said in an earlier message about not making technical = changes, I think this is a request to get rid of usage type 2, or add a = lot of technical requirements on its use. I'm OK with either of those = actions, and would prefer to get rid of it to make the protocol simpler. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 11:24:15 2012 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 A079221F87A1 for ; Thu, 16 Feb 2012 11:24:14 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reJHJ+arX+eO for ; Thu, 16 Feb 2012 11:24:14 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 24E6621E800C for ; Thu, 16 Feb 2012 11:24:12 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GJO7if092045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Feb 2012 12:24:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202160837.q1G8b4WD021787@new.toad.com> Date: Thu, 16 Feb 2012 11:24:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3D230AE0-E870-4432-B0ED-F1AEE56A5E7B@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <201202160837.q1G8b4WD021787@new.toad.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Certificate Usages (nits) 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 Feb 2012 19:24:16 -0000 On Feb 16, 2012, at 12:37 AM, John Gilmore wrote: > Small changes: In 4.1 and 4.2, end the last sentence of each paragraph > by saying that these usages limit what certificate can be used "for a > given host name, protocol and port". Currently they say "for a given > host name", but name prefixing clearly allows multiple different TLS > servers at the same host name, which might well use different > certificate chains. Good catch, yes. --Paul Hoffman From pieter.lexis@os3.nl Thu Feb 16 11:39:01 2012 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 4D09621F885C for ; Thu, 16 Feb 2012 11:39:01 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkVKI3M6uQ0y for ; Thu, 16 Feb 2012 11:38:54 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 57F1D21F86EC for ; Thu, 16 Feb 2012 11:38:54 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id BCE8817AA62 for ; Thu, 16 Feb 2012 20:38:53 +0100 (CET) Received: from [192.168.1.37] (82-170-86-166.ip.telfort.nl [82.170.86.166]) by smtp.os3.nl (Postfix) with ESMTPSA id 9883F17AA5D for ; Thu, 16 Feb 2012 20:38:53 +0100 (CET) Message-ID: <4F3D5B4D.7010509@os3.nl> Date: Thu, 16 Feb 2012 20:38:53 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: dane@ietf.org References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> In-Reply-To: <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 19:39:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/16/2012 08:22 PM, Paul Hoffman wrote: > Despite what John said in an earlier message about not making > technical changes, I think this is a request to get rid of usage > type 2, or add a lot of technical requirements on its use. I'm OK > with either of those actions, and would prefer to get rid of it to > make the protocol simpler. How would one use a private CA when usage 2 gets removed? Usage 0 isn't sufficient to do this. - From a purely operational point of view, using a private CA is less burdensome (TLSA wise, with DNS server support) than usage 3 ('privately issued certs'). But if this issue is not resolvable for now, it should be removed and the PKIX WG should create a document describing the path-building algorithm. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPPVtJAAoJELPqGO5ebd4jOq8QALNzAQiIEz5bXBYo81jwmeQl UxN/zjGgETWRPXjpzfLgKg13KISbJ8CC9qPMvVhRa7/etzRJg+IkCcTeNuU49tgF 0wIWR6dyygs9/rW3xruEztHbSJdKhtOaNZw6m5qhCx2RvUI3UWwJGo7oHFQCcc/b fXOszY8rMAOT4xwAg5u9/Bqw31+kUK9kFznPvPf6KNAYDarsJ8Cp7xHV20438r2i kluVNXGwr7X0C8YDYNHd+bwVA4UWDUXFIVSq6udNbnsb6+fNW5pkRE16oHO+BKIB OU8J0q7JbPY8lmYJc1PTXXBfaOTmpj4q6+CXS3Ris7011x+tde88yiHpRGY1qXsY L5uBFaz8PEyM7+Fu4zlWbt2F8LZacZOgMR97wGOqrE63WiWgMv32G548IgW1210f F6JymU+ftQGOe9CKb4ZrqDqiSQvFU2XNCB6+ViKX+hHvbeJHmSJPifxT7lRlS3Nv 0y1Ga/Xn2ignd0ndStIwYlR4IuqC2gDiUPyJ3czpHFIl9arZvDOD3Zv9gLuJwtRi TgomOM0fRKgFc2Q9BwQKz6itdV2CT1YCOk8ZgaH3X+fJQd8YiMpUullylMQu2URG MLExHB8uUQHBEBQWs83XhmniLnL+eAh9XU9v+Q9PD7sXXkdZX/LWJ3rqXb6IUr4K Rrh7dRD6VMFNMEVEQNd7 =wSgD -----END PGP SIGNATURE----- From gnu@toad.com Thu Feb 16 12:10:20 2012 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 9D2D421F8772 for ; Thu, 16 Feb 2012 12:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.355 X-Spam-Level: X-Spam-Status: No, score=0.355 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtRmJbB3GT69 for ; Thu, 16 Feb 2012 12:10:19 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 30DD721F8794 for ; Thu, 16 Feb 2012 12:10:15 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1GKA9WD029393; Thu, 16 Feb 2012 12:10:09 -0800 Message-Id: <201202162010.q1GKA9WD029393@new.toad.com> To: IETF DANE WG list , Paul Hoffman In-reply-to: <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> Date: Thu, 16 Feb 2012 12:10:09 -0800 From: John Gilmore Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 20:10:20 -0000 Paul Hoffman said: > Despite what John said in an earlier message about not making > technical changes, I think this is a request to get rid of usage > type 2, or add a lot of technical requirements on its use. I'm OK > with either of those actions, and would prefer to get rid of it to > make the protocol simpler. I sought to document how cert usage type 2 interacts with the selector and match fields. And perhaps to *suggest* that domain administrators who make a direct 2-cert chain between the trust anchor certificate and the end-entity certificate, will likely improve their interoperability. We already have similar cautionary text in the Security Considerations section. (Nit: that text has a typo, "be come".) John From paul.hoffman@vpnc.org Thu Feb 16 12:35:28 2012 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 E3F1C11E8098 for ; Thu, 16 Feb 2012 12:35:28 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2zuJzFChwMe for ; Thu, 16 Feb 2012 12:35:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3211E8096 for ; Thu, 16 Feb 2012 12:35:27 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GKZPCx094916 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Feb 2012 13:35:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F3D5B4D.7010509@os3.nl> Date: Thu, 16 Feb 2012 12:35:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9C2B2CF7-3178-4D78-A02C-133D7961CF72@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> <4F3D5B4D.7010509@os3.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 20:35:29 -0000 On Feb 16, 2012, at 11:38 AM, Pieter Lexis wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, >=20 > On 02/16/2012 08:22 PM, Paul Hoffman wrote: >> Despite what John said in an earlier message about not making=20 >> technical changes, I think this is a request to get rid of usage >> type 2, or add a lot of technical requirements on its use. I'm OK >> with either of those actions, and would prefer to get rid of it to >> make the protocol simpler. >=20 > How would one use a private CA when usage 2 gets removed? Usage 0 > isn't sufficient to do this. Now I'm confused. Why can't type 0 be used for a private CA (that is, = one that is not already in the client's trust store)? > - =46rom a purely operational point of view, using a private CA is = less > burdensome (TLSA wise, with DNS server support) than usage 3 > ('privately issued certs'). That will be true for some folks, not for others. But regardless, we = should certainly support it. I thought that 0 did so. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 12:55:53 2012 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 9A72111E80BC for ; Thu, 16 Feb 2012 12:55:53 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck7VxqX0GLWV for ; Thu, 16 Feb 2012 12:55:53 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 212A711E80BB for ; Thu, 16 Feb 2012 12:55:53 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GKtqBs095775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 13:55:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201202160913.q1G9DfWD023530@new.toad.com> Date: Thu, 16 Feb 2012 12:55:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00264596-97FE-4BB5-A542-4684270D87C4@vpnc.org> References: <201202160913.q1G9DfWD023530@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] "First" request TLSA records? 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 Feb 2012 20:55:53 -0000 On Feb 16, 2012, at 1:13 AM, John Gilmore wrote: > I recommend removing the word "first", and also clarifying that > it's talking about making DNS requests, not some other kind of > requests: >=20 > An implementation of this protocol makes a DNS query for TLSA > records (or uses already-retrieved TLSA records, cached within > their time to live value), validates these records using DNSSEC, > and uses the resulting TLSA records and validation status to modify > its responses to the TLS server. Works for me. Does anyone have any objections to this? > I also think there's a problem with the name of section 5: "Use of TLS > Certificate Associations in TLS". I think it was meant to say "Use of > TLSA Certificate Associations in TLS". =20 Yipes! Yes. > But I think it would be > clearer to say "Use of TLSA Records in TLS". As explained in an > earlier comment, I found the concept of "certificate associations" to > be an unnecessary complication in the description. Your proposed new section title is better even if we leave "certificate = associations" in the document because using the records might lead to no = certificate associations. > (There's a second mention of "TLS certificate associations" in > the first graf under the name, which I think was meant to refer > to "TLSA certificate associations" since the cited section 2.1=20 > is about the TLSA RDATA, not about TLS.) Got it. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 13:07:32 2012 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 B360621E8070 for ; Thu, 16 Feb 2012 13:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIz1m09qeV5T for ; Thu, 16 Feb 2012 13:07:32 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 37E4321E8043 for ; Thu, 16 Feb 2012 13:07:32 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GL7OTx096176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 16 Feb 2012 14:07:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F3CC821.7060803@nlnetlabs.nl> Date: Thu, 16 Feb 2012 13:07:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0EACF169-0508-4B79-A6C3-71A2A911C242@vpnc.org> References: <60E3BE12-8BEC-43AB-A0FB-FADA2284041C@vpnc.org> <4F3B7659.3010904@nlnetlabs.nl> <4F3BDF9E.3040604@nlnetlabs.nl> <4F3CC821.7060803@nlnetlabs.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Starting WGLC for draft-ietf-dane-protocol-16. 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 Feb 2012 21:07:32 -0000 On Feb 16, 2012, at 1:10 AM, Matthijs Mekking wrote: > I interpret the word mark incorrectly I guess. This makes this review > comment a nit. To me, you mark data so that you can make a decision > about it in the future. What about 'MUST be considered as unusable' or > 'MUST NOT be considered as usable'. Sounds fine. > I also would move the paragraph: >=20 > If an application receives zero usable certificate associations > (not bogus), it > processes TLS in the normal fashion without any input from the TLSA > records; otherwise, that application attempts to match each > certificate association with the TLS server's end entity = certificate. >=20 > towards the end of the section, so that it falls after all references > to TSLA RRsets being unusable. Note that I suggested to add '(not > bogus)' in there. The move seems fine. I think putting in "(not bogus)" is not a good = idea, because it mixes two ideas (usable vs. DNSSEC status). It also = ignores "insecure" and "indeterminate". --Paul Hoffman From ajs@anvilwalrusden.com Thu Feb 16 13:09:31 2012 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 2416121F85D0 for ; Thu, 16 Feb 2012 13:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.758 X-Spam-Level: X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-1.758, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxPvgOaOyrcB for ; Thu, 16 Feb 2012 13:09:30 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03F21F85BB for ; Thu, 16 Feb 2012 13:09:30 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 57331A35809F for ; Thu, 16 Feb 2012 13:09:27 -0800 (PST) Date: Thu, 16 Feb 2012 16:09:25 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120216210924.GH29243@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Review of draft-ietf-dane-protocol-16 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 Feb 2012 21:09:31 -0000 Dear colleagues, I note the WGLC of draft-ietf-dane-protocol-16. I have read that document. I have some comments. Before beginning, I want to note that the document is, in my opinion, mostly a model of clarity. I did not find it terribly hard to read. I should note also that I am not any sort of authority on TLS or PKIX (some might say I'm not any sort of authority on anything, but the point is that I know even less about TLS and PKIX). Finally, I'm returning to this document after several weeks in which I've been too busy to follow the WG's discussion on list in any sort of detail. This review raises topics as they are first encountered, but then jumps forward in the draft to discuss other relevant parts of it when necessary. Section 2.1.1 has a forward reference to section 4 to describe what each of the Usage cases does. Even section 4, however, is not completely clear to me -- probably because I don't really understand PKIX. I think we can safely imagine that some implementers or, especially, deployers will have a shaky grasp of PKIX, however, and that the subtleties of each case will be lost on them. I think that putting the explanatory text with the definitions would be more useful -- it was certainly a little confusing to me why they're separated -- but I appreciate that it might be a little late for that sort of major editorial change. In any case, a little more explanation of what the use cases are would really help. I'm sure there's some reason, for instance, but I can't figure out why usage 1 and usage 3 aren't in operation going to be the same. Usage 2, if I am reading it correctly, looks a foot-gun loaded for bear. I saw a message from one of the editors suggesting removing it; I have no objection. If it stays, further expansion of the security considerations discussion (and a special note forward from usage 2 saying that there's important implications, see the S.C.) might be nice. Section 3 starts with a mystifying proviso: "Unless there is a protocol-specific specification that is different than this one. . ." This sounds like it's saying, "Unless someone is using a different protocol. . ." I don't think the proviso does any harm, but it strikes me as pretty odd. In Section 5, there's this: The matching or chaining MUST be done within the life of the TTL on the TLSA record; using a TLSA record past the lifetime specified in the TTL can expose the the TLS client to many types of attacks. I think this is fine, but I wonder whether it's useful to suggest what to do if the lifetime ends during the TLS set up. It seems to me that could happen on a slow link, for instance, when one got the TLSA out of the DNS cache and there wasn't much time left on it. It's a corner case, and probably not too important. I just wonder what the connection initiator ought to do: re-query for TLSA, mark the record unusable and move on, throw an error? I seem to recall a previous controversy about this item in section 5: o A TLSA RRset whose DNSSEC validation state is secure MUST be used as a certificate association for TLS unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRset. I don't have really strong opinions about it, although it does seem odd to me that TLSA hereby becomes a way of forcing the application off the more traditional validation chain absolutely. If I read this correctly, if the wrong TLSA record is in the DNS, TLS doesn't work period. This makes it hard to test the move to TLSA or to do a seamless changeover, I think: as soon as you publish your TLSA record, the existing, working infrastructure you have is broken to any client that knows how to use TLSA. Right? I notice A.4 discusses rolling once you have TLSA, but there doesn't seem to be anything about moving from no-TLSA based TLS to TLSA-based TLS. 8.1 notes that the RRTYPE code assignment is going to go through the expert review process. I'd suggest someone put the application in now. That process has not worked properly in recent cases, and has been the source of annoying delays. Section 9 starts with, "The security of the protocols described in this document relies on the security of DNSSEC as used by the client requesting A/AAAA and TLSA records." Is there some special reason why A/AAAA is called out there? Presumably it's just the security of DNSSEC as used by the client requesting any DNS records secured by DNSSEC, no? (For instance, if I can change the NS records for your zone, I can do some clever things too.) I suspect the sentence (again in 9), "A better design for authenticating DNS would be to have the same level of authentication used for all DNS additions and changes for a particular host," ought to end with, "changes for a particular owner name." Or something like that, right? That is, the host involved in accepting the changes isn't the issue; the issue is how changes in a zone or for a given owner name are authenticated. In the same section, "Thus, such proxies might choose to aggressively block TLSA requests and/or responses, even though this is not a recommended practice." Is the idea here that a proxy notices a TLSA query going out, and just sinks it so that no response ever returns? I guess an ANY query might get around this, although I'm not sure. I'm not sure I get the risk here: is the risk that the client can't get the TLSA record, or is the risk to the proxy vendors who are about to get bad news? I don't understand this paragraph: Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the domain name administrator. Which trust anchor? Given that we have a DNSSEC context in here, I'm worried this might be confusing. Also, which domain name administrator? Is the point that the person operating the authoritative zone isn't necessarily responsible for the data in the RDATA of the TLSA record? This is sort of true and sort of false (i.e. it's about as true as that a DNS operator isn't responsible if you hand them the wrong IP address for your host). I don't know what A.2.2 would mean, and I haven't thought about it. If someone wants to point me to the archives where the idea was described (yes, I'm too lazy to look it up) then I might offer text. Otherwise, I say remove this. The Pseudocode in B.2 sets class=IN but the text says that TLSA is class-independent. I know, I know. Just a nit. I think I understood the rest of the pseudocode, but I didn't try to build anything on it nor to construct a proof. Those are all my comments. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From pieter.lexis@os3.nl Thu Feb 16 13:25:29 2012 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 303C721E808E for ; Thu, 16 Feb 2012 13:25:29 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ+1IQWytNel for ; Thu, 16 Feb 2012 13:25:23 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03121E808D for ; Thu, 16 Feb 2012 13:25:23 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 0DE9D17AA25 for ; Thu, 16 Feb 2012 22:25:22 +0100 (CET) Received: from [192.168.1.37] (82-170-86-166.ip.telfort.nl [82.170.86.166]) by smtp.os3.nl (Postfix) with ESMTPSA id AF13A17AA1F for ; Thu, 16 Feb 2012 22:25:22 +0100 (CET) Message-ID: <4F3D7442.1040500@os3.nl> Date: Thu, 16 Feb 2012 22:25:22 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: dane@ietf.org References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> <4F3D5B4D.7010509@os3.nl> <9C2B2CF7-3178-4D78-A02C-133D7961CF72@vpnc.org> In-Reply-To: <9C2B2CF7-3178-4D78-A02C-133D7961CF72@vpnc.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 21:25:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/16/2012 09:35 PM, Paul Hoffman wrote: > On Feb 16, 2012, at 11:38 AM, Pieter Lexis wrote: > > Now I'm confused. Why can't type 0 be used for a private CA (that > is, one that is not already in the client's trust store)? Well, Usage 2 talks about using the association as a trust anchor and section 4.3 talks about the certificate not being expected to be in the end-user's cert-store. I assumed this means that usage 0 implies that the certificate in the association is 'well known' (aka expected to be in the user's cert store). Also, it is defined as being a 'CA certificate'. >> - From a purely operational point of view, using a private CA is >> less burdensome (TLSA wise, with DNS server support) than usage 3 >> ('privately issued certs'). > > That will be true for some folks, not for others. But regardless, > we should certainly support it. I thought that 0 did so. I though it didn't. See above. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPPXQ+AAoJELPqGO5ebd4jh3gP/0mTBpHHoiTYXStxksTjxvMJ qJWCN9G8cpJVhX4MQo3D0m1tm9tk3fmSvcquCWE13VOM2XF7/BXDUjwmFQ/9piPT Bw6uvmAGJfD42xEF6hrV02s3YXdyTMbfy/34mD6Dt73xICDBEM5h/nvCFOAZozWs rSdYGYt7L9+NZMMD3Sf78cnJ3zSEwdiwn3uDNAqxHBfyeNW9SI7+o+RZPrfEPxdZ 8sg3VlP8FU8RkvMT61uI4vSqO1g/nAzj/Cf+l30ZvCtqGXzB2ZZ0ojQciPXBZP7V d1XJifMV+a1QN0YS/LuugMw16NsT4DWZkUhP5riH9cqaKhfSjjOLSeSH2yxL/F8a 7oJ1Ybkv3k9aTKULpzgDbtp5nbcp8rdKXIknJekty1S09IdC0t9MSu7E/hc+Yq76 KBJ/Dhyax6aDy1hwBIXnlM+14UrLA+mafAl5+071qr2fKa1V/VCEG5lOwjv8r2Kd X8j2PS/DLQkc32lLO8GZEINmOt5pONmODYgZ5EjSlz14b5XuFEDztmkc5f64/Dx3 IvjqTtpoglHZRKomYDpq5E2hZCbKnkceyknnLuaz7ZUTQjM5fz0PiOxg8VJURrmJ rVb3jvFaOKttcEktZSDhlf7bUkk6LVrT449Oq3d0RUJZouh2TXqxObAe2/Slfv5U rxSYaIM7WU796ed+y16P =7kOb -----END PGP SIGNATURE----- From paul.hoffman@vpnc.org Thu Feb 16 13:52:47 2012 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 D48A521F847D for ; Thu, 16 Feb 2012 13:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW9nqV6M8KXq for ; Thu, 16 Feb 2012 13:52:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 477C421F847B for ; Thu, 16 Feb 2012 13:52:45 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GLqdoO098159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 14:52:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120216210924.GH29243@mail.yitter.info> Date: Thu, 16 Feb 2012 13:52:39 -0800 Content-Transfer-Encoding: 7bit Message-Id: <27200E53-6FC9-48C7-B78C-4011FCE92C18@vpnc.org> References: <20120216210924.GH29243@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: [dane] End of TTL during TLS setup 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 Feb 2012 21:52:47 -0000 On Feb 16, 2012, at 1:09 PM, Andrew Sullivan wrote: > In Section 5, there's this: > > The > matching or chaining MUST be done within the life of the TTL on the > TLSA record; using a TLSA record past the lifetime specified in the > TTL can expose the the TLS client to many types of attacks. > > I think this is fine, but I wonder whether it's useful to suggest what > to do if the lifetime ends during the TLS set up. It seems to me that > could happen on a slow link, for instance, when one got the TLSA out > of the DNS cache and there wasn't much time left on it. It's a corner > case, and probably not too important. I just wonder what the > connection initiator ought to do: re-query for TLSA, mark the record > unusable and move on, throw an error? Pick one so we can discuss it here. :-) --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 13:55:24 2012 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 24CE521E8019 for ; Thu, 16 Feb 2012 13:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mDrDTcQ0L8n for ; Thu, 16 Feb 2012 13:55:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A57F421E805E for ; Thu, 16 Feb 2012 13:55:23 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GLtLaW098288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 14:55:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120216210924.GH29243@mail.yitter.info> Date: Thu, 16 Feb 2012 13:55:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120216210924.GH29243@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: [dane] Forcing TLSA immediately 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 Feb 2012 21:55:24 -0000 On Feb 16, 2012, at 1:09 PM, Andrew Sullivan wrote: > o A TLSA RRset whose DNSSEC validation state is secure MUST be used > as a certificate association for TLS unless a local policy would > prohibit the use of the specific certificate association in the > secure TLSA RRset. >=20 > I don't have really strong opinions about it, although it does seem > odd to me that TLSA hereby becomes a way of forcing the application > off the more traditional validation chain absolutely. If I read this > correctly, if the wrong TLSA record is in the DNS, TLS doesn't work > period. This makes it hard to test the move to TLSA or to do a > seamless changeover, I think: as soon as you publish your TLSA record, > the existing, working infrastructure you have is broken to any client > that knows how to use TLSA. Right? I notice A.4 discusses rolling > once you have TLSA, but there doesn't seem to be anything about moving > from no-TLSA based TLS to TLSA-based TLS. What do you see as a secure alternative? There was a lot of gnashing of = teeth when we went to this, but no one came up with something that both = provided a transition to TLSA and was secure against downgrades. I ask = this given your DNSSEC history; I assume it was discussed there as well. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 16 13:58:01 2012 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 AE77721E8019 for ; Thu, 16 Feb 2012 13:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygTEEVjp68-Z for ; Thu, 16 Feb 2012 13:58:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6C021F86CF for ; Thu, 16 Feb 2012 13:58:01 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1GLvxCC098351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 14:58:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120216210924.GH29243@mail.yitter.info> Date: Thu, 16 Feb 2012 13:57:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2DAB4E40-E5F6-4118-93EA-70C8A51BF4EC@vpnc.org> References: <20120216210924.GH29243@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: [dane] Security of DNSSEC 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 Feb 2012 21:58:01 -0000 On Feb 16, 2012, at 1:09 PM, Andrew Sullivan wrote: > Section 9 starts with, "The security of the protocols described in > this document relies on the security of DNSSEC as used by the client > requesting A/AAAA and TLSA records." Is there some special reason why > A/AAAA is called out there? Presumably it's just the security of > DNSSEC as used by the client requesting any DNS records secured by > DNSSEC, no? (For instance, if I can change the NS records for your > zone, I can do some clever things too.) The logic is "if you are going to trust an address record to go to a = host, you can use the same mechanism to trust this certificate". Is = there a better way to say that? --Paul Hoffman From ajs@anvilwalrusden.com Thu Feb 16 13:58:24 2012 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 BF6A421E807A for ; Thu, 16 Feb 2012 13:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-1.430, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9Z0L9XQfHeE for ; Thu, 16 Feb 2012 13:58:24 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6955421E8077 for ; Thu, 16 Feb 2012 13:58:24 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 7634FA35809F for ; Thu, 16 Feb 2012 13:58:23 -0800 (PST) Date: Thu, 16 Feb 2012 16:58:21 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120216215821.GQ29243@mail.yitter.info> References: <20120216210924.GH29243@mail.yitter.info> <27200E53-6FC9-48C7-B78C-4011FCE92C18@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27200E53-6FC9-48C7-B78C-4011FCE92C18@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 21:58:24 -0000 On Thu, Feb 16, 2012 at 01:52:39PM -0800, Paul Hoffman wrote: > > case, and probably not too important. I just wonder what the > > connection initiator ought to do: re-query for TLSA, mark the record > > unusable and move on, throw an error? > > Pick one so we can discuss it here. :-) Ok, I'd say, "If the TTL expires during TLS negotiation, the side initiating the connection MAY query for the TLSA record again, but SHOULD NOT re-query more than [n, n{2..5}] times. If the TLSA RRset cannot be used after multiple fetches, it should be marked as unusable." A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Feb 16 14:11:47 2012 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 4D3A721F87F1 for ; Thu, 16 Feb 2012 14:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=-1.418, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDRjHD03EYMr for ; Thu, 16 Feb 2012 14:11:46 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 605B721F87DE for ; Thu, 16 Feb 2012 14:11:43 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 45B30A35809F for ; Thu, 16 Feb 2012 14:11:42 -0800 (PST) Date: Thu, 16 Feb 2012 17:11:39 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120216221139.GR29243@mail.yitter.info> References: <20120216210924.GH29243@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 22:11:47 -0000 On Thu, Feb 16, 2012 at 01:55:21PM -0800, Paul Hoffman wrote: > > What do you see as a secure alternative? There was a lot of gnashing of teeth when we went to this, but no one came up with something that both provided a transition to TLSA and was secure against downgrades. I ask this given your DNSSEC history; I assume it was discussed there as well. > I don't think there's an analogue in DNSSEC, really. And yeah, I guess there isn't really a secure alternative. Maybe simply pointing out that this can't be done would be good though. "It should be noted that the presence of a DNSSEC-valid TLSA record can block a TLS connection completely if the certificate association in the TLSA record cannot be used." That's pretty awkward, so there's probably a nicer way to say it. But I think this issue should be highlighted. A -- Andrew Sullivan ajs@anvilwalrusden.com From cloos@jhcloos.com Thu Feb 16 14:13:06 2012 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 52B7421F869F for ; Thu, 16 Feb 2012 14:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKHrDDGe0okm for ; Thu, 16 Feb 2012 14:13:01 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 0136821F8690 for ; Thu, 16 Feb 2012 14:13:01 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id F2FCD400A4; Thu, 16 Feb 2012 22:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1329430378; bh=G3378+YYpfUhmIdSVHQeJKkGnLE6zpKKQ5XW7iyeshs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mnTS7F5EXNX2zV1Jh9MWJpX6oiqJRqU0tiqkVPaRqlCFfPOs9R/JbiN6P6I7bsYyC DPgikIO/dHFNgelbeYR6oEd6ga3qxqvJa7X9JWdjdvsfofx5yJoBKYf2qsl8p6eXdE uWo8QOGkQtpI8J1AGc0wnPuu4Pm0llLDdFMT0nO4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 353D436004C; Thu, 16 Feb 2012 22:08:09 +0000 (UTC) From: James Cloos To: IETF DANE WG list In-Reply-To: <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> (Paul Hoffman's message of "Thu, 16 Feb 2012 11:22:00 -0800") References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.93 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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 Feb 2012 17:08:09 -0500 Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120216:dane@ietf.org::VIbQDVy0wGfqPE3h:000bE8h7 X-Hashcash: 1:30:120216:paul.hoffman@vpnc.org::05yWgZNNIxyAaHub:0000000000000000000000000000000000000003EsOo Cc: Paul Hoffman Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 22:13:06 -0000 >>>>> "PH" == Paul Hoffman writes: PH> I think this is a request to get rid of usage type 2, or add a lot PH> of technical requirements on its use. I'm OK with either of those PH> actions, and would prefer to get rid of it to make the protocol simpler. -1 on removal. Just add a note that the TLS server SHOULD send the cert referenced by the type 2 TLSA RR just like it currently SHOULD (MUST?) send intermediate certs. Conceptually, the cert in question IS an intermediate cert; it is just tied to DNS instead of to an OutOfBand x509 cert. So wording it that way ought to be easy to comprehend and implementations written based on that conceptualization should Just Workâ„¢. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ajs@anvilwalrusden.com Thu Feb 16 14:18:26 2012 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 0E95821E807C for ; Thu, 16 Feb 2012 14:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCdiRVJU+AlM for ; Thu, 16 Feb 2012 14:18:25 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1080521F885F for ; Thu, 16 Feb 2012 14:18:24 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 28A22A35809F for ; Thu, 16 Feb 2012 14:18:24 -0800 (PST) Date: Thu, 16 Feb 2012 17:18:21 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120216221821.GT29243@mail.yitter.info> References: <20120216210924.GH29243@mail.yitter.info> <2DAB4E40-E5F6-4118-93EA-70C8A51BF4EC@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DAB4E40-E5F6-4118-93EA-70C8A51BF4EC@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Security of DNSSEC 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 Feb 2012 22:18:26 -0000 On Thu, Feb 16, 2012 at 01:57:59PM -0800, Paul Hoffman wrote: > The logic is "if you are going to trust an address record to go to a host, you can use the same mechanism to trust this certificate". Is there a better way to say that? > Because TLS is a mechanism for securing connections, and because that connection can rely on information retrieved from the DNS, this document works from the assumption that the same mechanism can be used to retrieve the certificate for TLS. The security of the protocols described in this document relies on the security of DNSSEC as used by the client to retrieve any resource record from the DNS. (and so on). Howzzat? A -- Andrew Sullivan ajs@anvilwalrusden.com From cloos@jhcloos.com Thu Feb 16 14:43:48 2012 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 63CE721F87B9 for ; Thu, 16 Feb 2012 14:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXotluLqUz3U for ; Thu, 16 Feb 2012 14:43:43 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 164D621F87AD for ; Thu, 16 Feb 2012 14:43:43 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id BFF4E400A4; Thu, 16 Feb 2012 22:43:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1329432221; bh=Lbg0ypHsywfE+qTOPrAU17wlRiOCI+UEK9aW9gWOHco=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=XI1B/Ro/mYa/YWd7VF4nioxHAbgrQ5wgd21uDV67qjGRB4a9myNhYeJOJDUqjgCVi s1Md/wNoPVIFRm6IELDFTaVluMyyq4qv0qmZezF7F0s0pnDu4PiOJigR5yiroPMEtI Ji2OZqX3nfA+JaKbQrHEmdLMkPMfF3OXhnZiErAI= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 31F2736004D; Thu, 16 Feb 2012 22:31:21 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: (Paul Hoffman's message of "Thu, 16 Feb 2012 13:55:21 -0800") References: <20120216210924.GH29243@mail.yitter.info> User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.93 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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 Feb 2012 17:31:21 -0500 Message-ID: Lines: 29 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120216:dane@ietf.org::f3P3ZDUirRinpRk+:000Xy19V X-Hashcash: 1:30:120216:ajs@anvilwalrusden.com::A5olJrM2IwZ7FQ7v:000000000000000000000000000000000000008Ajhg Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 22:43:48 -0000 AS>> This makes it hard to test the move to TLSA or to do a seamless AS>> changeover, I think: as soon as you publish your TLSA record, the AS>> existing, working infrastructure you have is broken to any client AS>> that knows how to use TLSA. Right? Wrong. The important note is that ANY of the TLSA RRs which apply can be used, and any one of them might be current. Just like with DNSSEC ZSKs. When transitioning from non-TLSA to TLSA, first publish an RR which matches the current, existing TLS cert chain. Then, if you want to use a new cert chain, first publish the new TLSA RR, wait out the TTLs, restart the TLS server with the new key/cert info, wait out the TTLs again, and then you can removed any outdated TLSA RR(s). Since TLSA mandates DNSSEC, anyone doing this already should be familiar with the concept, as they need it for rolling ZSKs and KSKs. For sites who currently use well-known CAs to certify their EE certs, want to continue doing so and want to add TLSA -- ie those for whome usage types 0 and 1 are intended -- they only need to deploy dnssec and add TLSA RRs matching their current cert chains. For 0 and 1 the TLSA RR is just a further confirmation that the TLS server sends the actual intended certs and not some MITM-generated cert chain. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ajs@anvilwalrusden.com Thu Feb 16 15:14:02 2012 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 BAE2021E806A for ; Thu, 16 Feb 2012 15:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R8b0UnDBIlc for ; Thu, 16 Feb 2012 15:14:02 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40721E8065 for ; Thu, 16 Feb 2012 15:14:02 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 7D842A35809F for ; Thu, 16 Feb 2012 15:14:01 -0800 (PST) Date: Thu, 16 Feb 2012 18:13:58 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120216231358.GU29243@mail.yitter.info> References: <20120216210924.GH29243@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 23:14:02 -0000 On Thu, Feb 16, 2012 at 05:31:21PM -0500, James Cloos wrote: > When transitioning from non-TLSA to TLSA, first publish an RR which > matches the current, existing TLS cert chain. And at that moment, any TLSA-aware client that sees it has to use it, and nothing else. If you bollocks this step, those clients cannot connect at all. That's how I read the text, anyway, so if I'm wrong either I just didn't understand the text, or else the text needs improving. Maybe this is just my crummy PKIX understanding kicking in? > Since TLSA mandates DNSSEC, anyone doing this already should be familiar > with the concept, as they need it for rolling ZSKs and KSKs. When you roll a key, they can use _any_ of the keys that work. When you're using no-TLSA and you add TLSA, the people who are TLSA-aware can no longer use the no-TLSA mechanism. If I've understood correctly (and I am prepared to accept I haven't) this is considerably more fragile. A -- Andrew Sullivan ajs@anvilwalrusden.com From cloos@jhcloos.com Thu Feb 16 17:02:48 2012 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 CCD7F21E8081 for ; Thu, 16 Feb 2012 17:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxwzCvOdz6Sz for ; Thu, 16 Feb 2012 17:02:43 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7721F855F for ; Thu, 16 Feb 2012 17:02:43 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 1F01040151; Fri, 17 Feb 2012 01:02:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1329440562; bh=ePzx7Y8lffyzy/VsGWXoIQh2y7ZCkN5vptw5+Sn5YBU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=DDAsPp7ezjE0+yVDaqVSDIDwF01TJ6pSqqbA7USKsLnS/6Czq7opTm/hpHQk8HoIi PULNsO0FgZPNsqB/sWK0aAPRbqeTgm/30Squ1GcKkaulVIZdFk3Q2yhHCZcS/lEt/5 /eK5XtrO4kZQwHuzqsnUSTm+Umw+LiE+gVcXmaJE= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5D14336004C; Fri, 17 Feb 2012 00:59:54 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20120216231358.GU29243@mail.yitter.info> (Andrew Sullivan's message of "Thu, 16 Feb 2012 18:13:58 -0500") References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.93 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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 Feb 2012 19:59:54 -0500 Message-ID: Lines: 29 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120217:dane@ietf.org::1nMVwL2euGVVFYen:0006sX8R X-Hashcash: 1:30:120217:ajs@anvilwalrusden.com::IhdHYDaQ00MDBwTT:00000000000000000000000000000000000000kwREi Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 01:02:48 -0000 >>>>> "AS" == Andrew Sullivan writes: JC>> When transitioning from non-TLSA to TLSA, first publish an RR which JC>> matches the current, existing TLS cert chain. AS> And at that moment, any TLSA-aware client that sees it has to use it, AS> and nothing else. If you bollocks this step, those clients cannot AS> connect at all. I didn't see an "If you bollocks this step" in the previous post. Sure, an error in the TLSA RRs will block the site. But so will an error in the A, AAAA, DSK, ZSK, RRSIG or DS RRs. Or a secondary which stops updating. (I just got hit by that; the stale secondary had, by virtue of being stale, expired RRSIGs. That blocked everything which validated dnssec and happened to hit that secondary.). AS> When you roll a key, they can use _any_ of the keys that work. When AS> you're using no-TLSA and you add TLSA, the people who are TLSA-aware AS> can no longer use the no-TLSA mechanism. If I've understood correctly AS> (and I am prepared to accept I haven't) this is considerably more AS> fragile. But only if the addition has wrong RRs. I don't see how it could be a problem otherwise. But perhaps I'm wrong on that front?? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ajs@anvilwalrusden.com Thu Feb 16 20:03:25 2012 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 E8F2A21E809A for ; Thu, 16 Feb 2012 20:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=-1.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjMRAHD0PUNs for ; Thu, 16 Feb 2012 20:03:24 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26E21E804E for ; Thu, 16 Feb 2012 20:03:24 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@anvilwalrusden.com) by pdx-1.yitter.info (Postfix) with ESMTPSA id 3C800A35809F for ; Thu, 16 Feb 2012 20:03:22 -0800 (PST) Date: Thu, 16 Feb 2012 23:03:14 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120217040314.GA31408@mail.yitter.info> References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 04:03:25 -0000 On Thu, Feb 16, 2012 at 07:59:54PM -0500, James Cloos wrote: > > I didn't see an "If you bollocks this step" in the previous post. If it makes you happier, I'm willing to stipulate that I suck, and so did my review of the draft. But this is what you quoted: AS>> This makes it hard to test the move to TLSA or to do a seamless AS>> changeover, I think: as soon as you publish your TLSA record, the AS>> existing, working infrastructure you have is broken to any client AS>> that knows how to use TLSA. Right? The point of those "move to TLSA" and "existing, working infrastructure" words was -- however they failed to communicate the point -- to note that there's a startup issue for operators. It seems to me that's worth taking into account, even if the answer is, "Can't fix that." If I put on the hat of the operator who pays my mortgage today, I have to say that a deployment that involves a hard cutover point is considerably more anxiety-producing, and therefore less likely. If I take off that hat and think about my own, stupid sysadmin mistake this morning, where I messed up a line in my own mail server config file and created a mail loop for exactly long enough that my test caught it and that an IETF list got a pointless bounce from me, I _also_ have to say that a hard cutover point is more anxiety-producing. In deployment terms, given that we have an existing infrastructure that has wide deployment, a transition issue doesn't seem to be to be a totally needless worry. None of that is to say that, "Yep. Suck it up," is the wrong answer. It's rather to say that, if that's our answer, we need to point it out explicitly, because it seems to me like an important deployability issue. If the idea of IETF standards is interoperability, this is a place where two strategies fail to interoperate. > Sure, an error in the TLSA RRs will block the site. But so will an > error in the A, AAAA, DSK, ZSK, RRSIG or DS RRs. Yes. The first two of those you list are well-understood DNS operational mistakes for which people are prepared and -- at least in the case of A records -- with which we gradually built up operational experience that taught us how to do things carefully. But the introduction of DNSSEC (with its different kinds of keys, signing across the zone cuts, funny key lifetime approach, and so on) has been in some cases a good example of disruption to operational habits. It's that collective experience that makes me nervous for this case. Long after the US OMB mandate kicked in, for instance, many US federal .gov sites are either not signed or else so badly maintained that the sites go off the air to validators sometimes. I'm not sure which of these states is a less-happy omen, but in any case I think they illustrate the difficulties of just deploying, correctly, something that changes operational assumptions or involves different operational departments becoming involved with one another. In the case of TLSA, the "web department" and the "DNS department" in some organizations will need to co-ordinate their activities more tightly than perhaps they always have. I don't see how it is a disservice to point that out. Yes, this is "only if you screw up". That's the point, though, in a new deployment: it's precisely at cutover that you're _most_ likely to screw up. Operators like to have a cutover in which the entire old infrastructure keeps working while changing over. We're proposing something that can't work that way, and it's not a negligible issue. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From i.grok@comcast.net Thu Feb 16 20:28:28 2012 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 2691021E807B for ; Thu, 16 Feb 2012 20:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdMhUSy1qVGb for ; Thu, 16 Feb 2012 20:28:27 -0800 (PST) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE14421E804E for ; Thu, 16 Feb 2012 20:28:27 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta10.emeryville.ca.mail.comcast.net with comcast id as771i00C1ZMdJ4AAsUT6F; Fri, 17 Feb 2012 04:28:27 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id asUR1i00v00PQ6U8csUTKH; Fri, 17 Feb 2012 04:28:27 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q1H4SNow024656 for ; Thu, 16 Feb 2012 23:28:23 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q1H4SMeR024655 for dane@ietf.org; Thu, 16 Feb 2012 23:28:22 -0500 Date: Thu, 16 Feb 2012 23:28:22 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120217042822.GA11750@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <20120216210924.GH29243@mail.yitter.info> <20120216221139.GR29243@mail.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20120216221139.GR29243@mail.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 04:28:28 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 05:11:39PM -0500, Andrew Sullivan wrote: > I don't think there's an analogue in DNSSEC, really. And yeah, I > guess there isn't really a secure alternative. Maybe simply pointing > out that this can't be done would be good though. "It should be noted > that the presence of a DNSSEC-valid TLSA record can block a TLS > connection completely if the certificate association in the TLSA > record cannot be used." That's pretty awkward, so there's probably a > nicer way to say it. But I think this issue should be highlighted. Well, there are a few things you can do to minimize the damage: * Try it out on an alternate hostname to check out your TLSA record generation tools * Use/create tools that will validate the record against the cert chain you're using on the server before you deploy the record * If you have SNI and/or a wildcard cert, do the above but with your real server and/or key/cert (akin to the www.v6.example.com domain names) * Publish the TLSA record with a really short TTL initially so you can yank it (more) quickly should it prove to be broken. --=20 Scott Schmit --KsGdsel6WgEHnImy Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMjE3MDQyODIyWjAjBgkqhkiG9w0BCQQxFgQU+nem0CXS BROVNlEm0896W2iePUoweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAZt8fauBI FoSIR1Bz1XaL1jY8VDFIBOeCq4stXCx1d0tAE3a/JwarheAk1dOsbb9gNalIYQY4mTS2V0pT HC49p7IvSMS3B4cy6GfaSiprnb6CLNOwTceCBYzUBlZAu24+/tWpFGzgVR0Wl8v/1nUPno2S 89c+wYi9/ddLZKBiUTL4x6nVdcq1nFTOhSaC8fePxl8UXE9NnhQOKPJKAxHgwWPm52BzvZYU Ob0ZaGbAn053jetktVdlVGWUhwlBv90U0EQi43ye/Bzwk+ZjQu2FZKK9ZehZ4EIcKHB78Qp3 7PRegHzrI2hMcDsoLXhjkZNmDeMbA7Jm8VZGR6qhzzL6ww== --KsGdsel6WgEHnImy-- From cloos@jhcloos.com Fri Feb 17 13:06:27 2012 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 6A52021E8054 for ; Fri, 17 Feb 2012 13:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4XclTcmaIQD for ; Fri, 17 Feb 2012 13:06:26 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1F21E802C for ; Fri, 17 Feb 2012 13:06:26 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 304CE400A4; Fri, 17 Feb 2012 21:05:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1329512783; bh=pDweKDZmuhmaVUe0A7TXThmQ8f4bHl1qONB0Uaehdks=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MBw7XrcrJE3YZs4JTY4pPxx+CGAtvNW+3MYN33mWwgtA0ppMoTeaF4dpnY57mBx9T 7XGgvilB3GOSpLfzy+sulaiwFSppasPw0uURGajdyw858iDRQDIlLL8LOeTZ39zxbG 9An1I9/+UheZZ5OgZf/R3lX/1OWDJdCB31ojS1EU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8161736004C; Fri, 17 Feb 2012 20:58:14 +0000 (UTC) From: James Cloos To: Andrew Sullivan In-Reply-To: <20120217040314.GA31408@mail.yitter.info> (Andrew Sullivan's message of "Thu, 16 Feb 2012 23:03:14 -0500") References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> <20120217040314.GA31408@mail.yitter.info> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.93 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Fri, 17 Feb 2012 15:58:13 -0500 Message-ID: Lines: 46 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120217:ajs@anvilwalrusden.com::2ZOvwBqDbv6ttteT:00000000000000000000000000000000000000+9Bue X-Hashcash: 1:30:120217:dane@ietf.org::55WYmTDvNh+/4aMo:000ynBhV Cc: dane@ietf.org Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 21:06:27 -0000 >>>>> "AS" == Andrew Sullivan writes: AS> On Thu, Feb 16, 2012 at 07:59:54PM -0500, James Cloos wrote: >> >> I didn't see an "If you bollocks this step" in the previous post. AS> If it makes you happier, I'm willing to stipulate that I suck, and AS> so did my review of the draft. I wasn't flaming, just explaining why my first reply seems to have misunderstood your point. I /thought/ that you were talking about successful additions of accurate TLSA RRs to an already-signed zone. Which should work smoothly for all TLS clients. AS> The point of those ... [was] to note that there's a startup issue AS> for operators. It seems to me that's worth taking into account, That is reasonable. My point was simply that it is not any worse than all of the other things which can go wrong when updating networking and/or security infrastucture. AS> None of that is to say that, "Yep. Suck it up," is the wrong answer. AS> It's rather to say that, if that's our answer, we need to point it out AS> explicitly, because it seems to me like an important deployability AS> issue. If the idea of IETF standards is interoperability, this is a AS> place where two strategies fail to interoperate. If explicitly noting that will help implementers then by all means. I'm sure Paul and Jakob would prefer some suggested prose. >> Sure, an error in the TLSA RRs will block the site. But so will an >> error in the A, AAAA, DSK, ZSK, RRSIG or DS RRs. AS> Yes, this is "only if you screw up". That's the point, though, Again, I really didn't get that from the first post; else I'd have replied differently. And my apologies if my prose appeared heated; that was not my intention. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul.hoffman@vpnc.org Sun Feb 19 17:46:46 2012 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 51EA221F859B for ; Sun, 19 Feb 2012 17:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqHKX6+IaixO for ; Sun, 19 Feb 2012 17:46:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA48221F8595 for ; Sun, 19 Feb 2012 17:46:45 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1K1kfeg023242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 19 Feb 2012 18:46:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202161029.q1GATaWD026584@new.toad.com> Date: Sun, 19 Feb 2012 17:46:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <103FA98A-9554-4237-A15B-42F1C62C895D@vpnc.org> References: <201202161029.q1GATaWD026584@new.toad.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Record creators and MUST? And TLSA protocol name. 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 Feb 2012 01:46:46 -0000 On Feb 16, 2012, at 2:29 AM, John Gilmore wrote: > Section 7 specifies particular requirements on implementations in > general, though it is entitled "Mandatory-to-Implement Algorithms". > (That should possibly be changed.) Probably so: Mandatory-to-Implement Features > I recommend striking the entire first paragraph, which MUSTs and > SHOULDs the cert usage, selector, and hash type fields for systems > *creating* TLSA records. This works for me. Any objections to doing this? > For TLSA clients (the second paragraph), the MUST and SHOULDs are in > accord with the issue tracker. But let's fix the name from "TLS > clients conforming to this specification" to "TLSA clients". That > seems to be how we're thinking about this. Fully disagree that is how "we're" thinking about this. TLSA is not a = protocol (there was only one mention of that phrase in the doc, will be = fixed in the next version), it is a type of DNS record. A type of DNS = record doesn't have "clients". > This brings up the general question of whether we should be referring > to this protocol as "TLSA" in places where we talk about "this > protocol" or "this document". Indeed we seem to not have come up with > a name for this protocol anywhere; I propose that we call it the "TLSA > protocol". That should simplify naming in a number of places, > including the title of the RFC. Disagree with the latter; agree that we should not say "this protocol" = in the document. That was sloppy, so we'll fix the handful of cases of = that in the next version. --Paul Hoffman From ondrej.sury@nic.cz Mon Feb 20 07:19:13 2012 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 1D57121F84BF for ; Mon, 20 Feb 2012 07:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAt0s-WBnZ13 for ; Mon, 20 Feb 2012 07:19:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6D721F855D for ; Mon, 20 Feb 2012 07:19:07 -0800 (PST) Received: from kimac-wifi.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id EE6F32A2FAC; Mon, 20 Feb 2012 16:19:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1329751145; bh=lnDCGuiB0/1+rB3jc7HRSOIT5IiSdAFgAnSBuU0rzWg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Xzg9pdkOMW7XA+Gv4UqLU+5WvId3a6njAnOn6Zg+t83Mpgm9IZoTN5YRZTtwbuIZM JLZBW9oFhLnCysxchQKFTGyzUVFsDGaYCSuMiTElJV4MDhbGRv0vmt6cssoy+eOrNk uaMz5NHwJThxDvIOa5vnBh+stUVXhhddaNSpmR/c= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Mon, 20 Feb 2012 16:19:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90B83E04-57E6-4535-8F7D-947BEA417021@nic.cz> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <20120210213216.GA20331@LK-Perkele-VI.localdomain> To: James Cloos X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Peter Palfrader , Paul Hoffman , IETF DANE WG List Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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 Feb 2012 15:19:13 -0000 On 10. 2. 2012, at 23:11, James Cloos wrote: > It seems that those who want to use TLS proxies and also support > DANE-aware clients which are compliant with our drafts will need to > fully proxy DNS, too. >=20 > Just like they have to provide the inside clients with a cert to act = as > a root tls trust anchor, they will need to provide a DS RR for . which > they control, verify the outside sigs, and re-sign everything before > passing it on to the inside clients. >=20 > This is, really, no different than what they already do to TLS. >=20 > They also would need to do that for CMS and OpenPGP, should they care > about encrypted email, too. Et cetera, und so weiter, and so on. +1 I am not encouraging this, but writing a simple validating DNS proxy = which will (re)sign validated DNS records with own private keys should = be simple with (lib)unbound. O. -- 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 mrex@sap.com Tue Feb 21 08:31:03 2012 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 D19BE21F87B8 for ; Tue, 21 Feb 2012 08:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.759 X-Spam-Level: X-Spam-Status: No, score=-9.759 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBAoFelBZ7BK for ; Tue, 21 Feb 2012 08:31:03 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8721F87B5 for ; Tue, 21 Feb 2012 08:31:02 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1LGUxnP023168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 17:30:59 +0100 (MET) From: Martin Rex Message-Id: <201202211630.q1LGUwe4003655@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 21 Feb 2012 17:30:58 +0100 (MET) In-Reply-To: <2DAB4E40-E5F6-4118-93EA-70C8A51BF4EC@vpnc.org> from "Paul Hoffman" at Feb 16, 12 01:57:59 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] Security of DNSSEC 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: Tue, 21 Feb 2012 16:31:03 -0000 Paul Hoffman wrote: > > Andrew Sullivan wrote: > > > > Section 9 starts with, "The security of the protocols described in > > this document relies on the security of DNSSEC as used by the client > > requesting A/AAAA and TLSA records." Is there some special reason why > > A/AAAA is called out there? Presumably it's just the security of > > DNSSEC as used by the client requesting any DNS records secured by > > DNSSEC, no? (For instance, if I can change the NS records for your > > zone, I can do some clever things too.) > > The logic is "if you are going to trust an address record > to go to a host, you can use the same mechanism to trust > this certificate". Is there a better way to say that? I agree with Andrew, the mentioning of A/AAAA is invalid an ought to be removed. You NEVER trust A/AAAA in TLS, and neither in TLS+DANE. Trusting A/AAAA would be foolish anyway, since a network MITM as well as any proxies that are traversed can transparently modify all of the data, without anything spooky being visible at the IP-Address layer. -Martin From mrex@sap.com Tue Feb 21 08:38:23 2012 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 072B121F880D for ; Tue, 21 Feb 2012 08:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heBnR74uijt7 for ; Tue, 21 Feb 2012 08:38:22 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEDB21F880C for ; Tue, 21 Feb 2012 08:38:22 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1LGcIYJ025870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 17:38:18 +0100 (MET) From: Martin Rex Message-Id: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> To: ajs@anvilwalrusden.com (Andrew Sullivan) Date: Tue, 21 Feb 2012 17:38:17 +0100 (MET) In-Reply-To: <20120216215821.GQ29243@mail.yitter.info> from "Andrew Sullivan" at Feb 16, 12 04:58: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] End of TTL during TLS setup 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: Tue, 21 Feb 2012 16:38:23 -0000 Andrew Sullivan wrote: > > On Thu, Feb 16, 2012 at 01:52:39PM -0800, Paul Hoffman wrote: > > > case, and probably not too important. I just wonder what the > > > connection initiator ought to do: re-query for TLSA, mark the record > > > unusable and move on, throw an error? > > > > Pick one so we can discuss it here. :-) > > Ok, I'd say, "If the TTL expires during TLS negotiation, the side > initiating the connection MAY query for the TLSA record again, but > SHOULD NOT re-query more than [n, n{2..5}] times. If the TLSA RRset > cannot be used after multiple fetches, it should be marked as > unusable." To me that sounds _much_ too complicated. The TTL on a DNS record is not a security feature anyway, so I do not see a justification to treat TTLs of TLSA records any different than TTLs on other DNS records, so typically on *receipt* of the DNS record. If there is a local cache for DNS records, that should work transparently -- either there is a record with a non-expired TTL available, then it is used, or there isn't then a new DNS query is necessary. Obtaining a DNS record with an expired TTL from a local cache sounds like a bug in the implementation (or design) of that DNS cache. -Martin From paul.hoffman@vpnc.org Tue Feb 21 08:42:59 2012 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 9D13021F885E for ; Tue, 21 Feb 2012 08:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdqQZFTRlGvP for ; Tue, 21 Feb 2012 08:42:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF1121F85C5 for ; Tue, 21 Feb 2012 08:42:59 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1LGgr7V015175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Feb 2012 09:42:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <201202211630.q1LGUwe4003655@fs4113.wdf.sap.corp> Date: Tue, 21 Feb 2012 08:42:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <51BD6018-12FA-416F-A14D-8254BE898AED@vpnc.org> References: <201202211630.q1LGUwe4003655@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Security of DNSSEC 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, 21 Feb 2012 16:42:59 -0000 On Feb 21, 2012, at 8:30 AM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> Andrew Sullivan wrote: >>>=20 >>> Section 9 starts with, "The security of the protocols described in >>> this document relies on the security of DNSSEC as used by the client >>> requesting A/AAAA and TLSA records." Is there some special reason = why >>> A/AAAA is called out there? Presumably it's just the security of >>> DNSSEC as used by the client requesting any DNS records secured by >>> DNSSEC, no? (For instance, if I can change the NS records for your >>> zone, I can do some clever things too.) >>=20 >> The logic is "if you are going to trust an address record >> to go to a host, you can use the same mechanism to trust >> this certificate". Is there a better way to say that? >=20 > I agree with Andrew, the mentioning of A/AAAA is invalid an ought > to be removed. You NEVER trust A/AAAA in TLS, and neither in = TLS+DANE. >=20 > Trusting A/AAAA would be foolish anyway, since a network MITM=20 > as well as any proxies that are traversed can transparently > modify all of the data, without anything spooky being visible > at the IP-Address layer. Not to be too picky, but I (as co-author) asked for a better way to say = what we mean. At some point, a TLS-using application needs to have enough trust to = connect to start a connection on port 443 of a given A or AAAA record. = This is not a trust in TLS, it is a trust in DNSSEC (or in the universe, = if DNSSEC didn't give a secure response). The TLS client using TLSA = records has to have the same level of trust in DNSSEC to use the TLSA = records. What is the best way of saying this? --Paul Hoffman From paul.hoffman@vpnc.org Tue Feb 21 08:45:16 2012 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 F115C21F86FF for ; Tue, 21 Feb 2012 08:45:16 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMeKFih3QE5Q for ; Tue, 21 Feb 2012 08:45:16 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8A221F86E0 for ; Tue, 21 Feb 2012 08:45:16 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1LGjFRn015320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 21 Feb 2012 09:45:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> Date: Tue, 21 Feb 2012 08:45:15 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] End of TTL during TLS setup 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, 21 Feb 2012 16:45:17 -0000 On Feb 21, 2012, at 8:38 AM, Martin Rex wrote: > Andrew Sullivan wrote: >> >> On Thu, Feb 16, 2012 at 01:52:39PM -0800, Paul Hoffman wrote: >>>> case, and probably not too important. I just wonder what the >>>> connection initiator ought to do: re-query for TLSA, mark the record >>>> unusable and move on, throw an error? >>> >>> Pick one so we can discuss it here. :-) >> >> Ok, I'd say, "If the TTL expires during TLS negotiation, the side >> initiating the connection MAY query for the TLSA record again, but >> SHOULD NOT re-query more than [n, n{2..5}] times. If the TLSA RRset >> cannot be used after multiple fetches, it should be marked as >> unusable." > > To me that sounds _much_ too complicated. The TTL on a DNS record > is not a security feature anyway, so I do not see a justification to > treat TTLs of TLSA records any different than TTLs on other DNS records, > so typically on *receipt* of the DNS record. If there is a local cache > for DNS records, that should work transparently -- either there is > a record with a non-expired TTL available, then it is used, or > there isn't then a new DNS query is necessary. Obtaining a DNS record > with an expired TTL from a local cache sounds like a bug in the > implementation (or design) of that DNS cache. +1 to Martin's analysis. --Paul Hoffman From ajs@anvilwalrusden.com Tue Feb 21 09:01:11 2012 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 8E8A121F8661 for ; Tue, 21 Feb 2012 09:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtv1PTySYyXS for ; Tue, 21 Feb 2012 09:01:10 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1C121F8620 for ; Tue, 21 Feb 2012 09:01:10 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5B2D21ECB44F for ; Tue, 21 Feb 2012 17:01:00 +0000 (UTC) Date: Tue, 21 Feb 2012 12:00:58 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120221170058.GE34608@mail.yitter.info> References: <20120216215821.GQ29243@mail.yitter.info> <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] End of TTL during TLS setup 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, 21 Feb 2012 17:01:11 -0000 On Tue, Feb 21, 2012 at 05:38:17PM +0100, Martin Rex wrote: > > To me that sounds _much_ too complicated. The TTL on a DNS record > is not a security feature anyway, so I do not see a justification to > treat TTLs of TLSA records any different than TTLs on other DNS > records I'd actually agree with this but for the text that was already there, which says that the negotiation has to complete before the TTL expires. Your suggested alternative will not in some cases meet that requirement. I presumed the WG had a reason to phrase it this way; if not, then your suggestion is better. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Feb 21 09:05:19 2012 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 565C421F8892 for ; Tue, 21 Feb 2012 09:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1X2jo4tvFoe for ; Tue, 21 Feb 2012 09:05:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 167C821F8872 for ; Tue, 21 Feb 2012 09:05:11 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5C0B91ECB451 for ; Tue, 21 Feb 2012 17:05:10 +0000 (UTC) Date: Tue, 21 Feb 2012 12:05:08 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120221170508.GF34608@mail.yitter.info> References: <201202211630.q1LGUwe4003655@fs4113.wdf.sap.corp> <51BD6018-12FA-416F-A14D-8254BE898AED@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BD6018-12FA-416F-A14D-8254BE898AED@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Security of DNSSEC 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, 21 Feb 2012 17:05:19 -0000 On Tue, Feb 21, 2012 at 08:42:53AM -0800, Paul Hoffman wrote: > Not to be too picky, but I (as co-author) asked for a better way to say what we mean. > I think I provided a suggestion, which was basically that if you're going to use the DNS to set up your connection, your connection is exactly as secure as any data you get from the DNS. See http://www.ietf.org/mail-archive/web/dane/current/msg04405.html. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From mrex@sap.com Tue Feb 21 10:07:10 2012 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 B10CB21F87EE for ; Tue, 21 Feb 2012 10:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.91 X-Spam-Level: X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQWkSttrvgEu for ; Tue, 21 Feb 2012 10:07:10 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id ED1C821F87AA for ; Tue, 21 Feb 2012 10:07:09 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1LI780r015901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Feb 2012 19:07:08 +0100 (MET) From: Martin Rex Message-Id: <201202211807.q1LI78Za008851@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Tue, 21 Feb 2012 19:07:08 +0100 (MET) In-Reply-To: <90B83E04-57E6-4535-8F7D-947BEA417021@nic.cz> from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Feb 20, 12 04:19:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: peter@palfrader.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.txt 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: Tue, 21 Feb 2012 18:07:10 -0000 Ondrej Sury wrote: > > James Cloos wrote: > > > > It seems that those who want to use TLS proxies and also support > > DANE-aware clients which are compliant with our drafts will need to > > fully proxy DNS, too. > > > > Just like they have to provide the inside clients with a cert to act as > > a root tls trust anchor, they will need to provide a DS RR for . which > > they control, verify the outside sigs, and re-sign everything before > > passing it on to the inside clients. > > > > This is, really, no different than what they already do to TLS. > > > > They also would need to do that for CMS and OpenPGP, should they care > > about encrypted email, too. Et cetera, und so weiter, and so on. > > +1 > > I am not encouraging this, but writing a simple validating DNS proxy > which will (re)sign validated DNS records with own private keys should > be simple with (lib)unbound. I am violently opposed to the extending that nonsense that MITM TLS Proxies are currently doing (totally subverting PKI) to DNSSEC. If anything, then there should be a *NEW* Proxy-Protocol, where the browser is fully aware of the MITM proxy and authenticates that proxy as proxy and clearly shows to the user that it is talking securely _to_the_proxy_ rather than trying to fake identity assertions of the fly. There are a number of things that MITM proxies break protocol-wise including TLS client certs and TLS channel bindings. If there is a desire for a protocol for a specific purpose, then one should design a protocol for this particular pupose, rather than completely subvert and break an existing security protocol and deceive the end user and consumer about what the technology is actually doing. -Martin From paul.hoffman@vpnc.org Tue Feb 21 10:08:06 2012 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 A366C21F8880 for ; Tue, 21 Feb 2012 10:08:06 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMeFmT7jn41p for ; Tue, 21 Feb 2012 10:08:04 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A99AD21F887A for ; Tue, 21 Feb 2012 10:08:04 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1LI82CO019624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Feb 2012 11:08:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120221170508.GF34608@mail.yitter.info> Date: Tue, 21 Feb 2012 10:08:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E9C052F-3FD8-48BA-A663-6C070C712056@vpnc.org> References: <201202211630.q1LGUwe4003655@fs4113.wdf.sap.corp> <51BD6018-12FA-416F-A14D-8254BE898AED@vpnc.org> <20120221170508.GF34608@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Security of DNSSEC 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, 21 Feb 2012 18:08:06 -0000 On Feb 21, 2012, at 9:05 AM, Andrew Sullivan wrote: > On Tue, Feb 21, 2012 at 08:42:53AM -0800, Paul Hoffman wrote: >> Not to be too picky, but I (as co-author) asked for a better way to = say what we mean. >>=20 >=20 > I think I provided a suggestion, You did; my message was aimed at Martin Rex. > which was basically that if you're > going to use the DNS to set up your connection, your connection is > exactly as secure as any data you get from the DNS. See > http://www.ietf.org/mail-archive/web/dane/current/msg04405.html. Actual text from your message: Because TLS is a mechanism for securing connections, and because that connection can rely on information retrieved from the DNS, this document works from the assumption that the same mechanism can be used to retrieve the certificate for TLS. The security of the protocols described in this document relies on the security of DNSSEC as used by the client to retrieve any resource record from the DNS. That works for me, but there may be some people who don't agree with the = last part because they don't think that DNSSEC is needed for any record = if you are using TLS or TLS-with-DANE. --Paul Hoffman From ajs@anvilwalrusden.com Tue Feb 21 10:21:14 2012 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 EFE3621F88BF for ; Tue, 21 Feb 2012 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-vO05YwklJ1 for ; Tue, 21 Feb 2012 10:21:13 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6428121F88BC for ; Tue, 21 Feb 2012 10:21:13 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D094F1ECB45F for ; Tue, 21 Feb 2012 18:21:12 +0000 (UTC) Date: Tue, 21 Feb 2012 13:21:10 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120221182110.GI34608@mail.yitter.info> References: <201202211630.q1LGUwe4003655@fs4113.wdf.sap.corp> <51BD6018-12FA-416F-A14D-8254BE898AED@vpnc.org> <20120221170508.GF34608@mail.yitter.info> <5E9C052F-3FD8-48BA-A663-6C070C712056@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E9C052F-3FD8-48BA-A663-6C070C712056@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Security of DNSSEC 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, 21 Feb 2012 18:21:14 -0000 On Tue, Feb 21, 2012 at 10:08:01AM -0800, Paul Hoffman wrote: > That works for me, but there may be some people who don't agree with > the last part because they don't think that DNSSEC is needed for any > record if you are using TLS or TLS-with-DANE. Ah, yes. _De gustibus non est disputandum_. (Sorry, but I just don't see any value at all in DANE without DNSSEC.) Nevertheless, how's this: Because TLS is a mechanism for securing connections, and because that connection can rely on information retrieved from the DNS, this document works from the assumption that the same mechanism can be used to retrieve the certificate for TLS. The security of the protocols described in this document relies on the security of responses from the DNS, and what the client subsequently does with such responses. DNSSEC-validated responses provide greater assurances that the DNS message was not altered in transit than those responses that have not been validated. ? -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Tue Feb 21 14:26:54 2012 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 75CB611E809F for ; Tue, 21 Feb 2012 14:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlMHnhiqCh1c for ; Tue, 21 Feb 2012 14:26:54 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id CC9CB21F88F5 for ; Tue, 21 Feb 2012 14:26:53 -0800 (PST) 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 "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id DD62E5F9899; Tue, 21 Feb 2012 22:26:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3991:6a11:92e9:5d76]) (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 AAFCC216C33; Tue, 21 Feb 2012 22:26: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 7153C1DA58B3; Wed, 22 Feb 2012 09:26:31 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <20120216215821.GQ29243@mail.yitter.info> <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <20120221170058.GE34608@mail.yitter.info> In-reply-to: Your message of "Tue, 21 Feb 2012 12:00:58 CDT." <20120221170058.GE34608@mail.yitter.info> Date: Wed, 22 Feb 2012 09:26:30 +1100 Message-Id: <20120221222631.7153C1DA58B3@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] End of TTL during TLS setup 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, 21 Feb 2012 22:26:54 -0000 In message <20120221170058.GE34608@mail.yitter.info>, Andrew Sullivan writes: > On Tue, Feb 21, 2012 at 05:38:17PM +0100, Martin Rex wrote: > > > > To me that sounds _much_ too complicated. The TTL on a DNS record > > is not a security feature anyway, so I do not see a justification to > > treat TTLs of TLSA records any different than TTLs on other DNS > > records > > I'd actually agree with this but for the text that was already there, > which says that the negotiation has to complete before the TTL > expires. Your suggested alternative will not in some cases meet that > requirement. I presumed the WG had a reason to phrase it this way; if > not, then your suggestion is better. > > A The important time is the RRSIG's expiration time of the RRSIG that validated the RRset (i.e. you have to choose the correct one). TTL is a cache refresh parameter. You will get TTL's of zero seconds which means "use for this transaction" not "use within 0 seconds". [TTL trimming is also something that is not well specified in RFC 4035 but that is dnsext fodder for as long as dnsext exists. Personally I thing it is too early to shutdown dnsext as DNSSEC is just begining to be used widely enough for specification problems to start to surface from applications. Bcc: dnsext@ietf.org] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Tue Feb 21 16:54:02 2012 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 D47AD21E8067 for ; Tue, 21 Feb 2012 16:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rc11qjQjFXE for ; Tue, 21 Feb 2012 16:54:02 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9221E8048 for ; Tue, 21 Feb 2012 16:53:54 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B66661B40EBE for ; Tue, 21 Feb 2012 19:53:53 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 19:53:52 -0500 Message-Id: <8735DD2F-B921-4374-B412-ACF445CF3945@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] WGLC reminder. 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 Feb 2012 00:54:03 -0000 Hi there all, Firstly, thank you very much for all of your feedback, input and = discussions -- Last Call certainly has a way of stimulating discussions = :-) We will be going through all of the mail in the next few days and trying = to determine consensus on the threads -- something that would certainly = make our lives much simpler is if folk who feel that their issues have = been addressed / a compromise has been reached would *clearly* state so. Again, thank you all for your assistance, W -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From Marco.Davids@sidn.nl Wed Feb 22 00:59:37 2012 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 1C4FD21F894B for ; Wed, 22 Feb 2012 00:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmEZEPZiuELE for ; Wed, 22 Feb 2012 00:59:36 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id BE9E621F894A for ; Wed, 22 Feb 2012 00:59:35 -0800 (PST) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q1M8xXdU020539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 22 Feb 2012 09:59:33 +0100 Received: from [192.168.129.3] (192.168.129.3) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server id 14.2.247.3; Wed, 22 Feb 2012 09:59:33 +0100 Message-ID: <4F44AE75.3060607@sidn.nl> Date: Wed, 22 Feb 2012 09:59:33 +0100 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Lightning/1.0b2 Thunderbird/3.1.19 MIME-Version: 1.0 To: References: <8735DD2F-B921-4374-B412-ACF445CF3945@kumari.net> In-Reply-To: <8735DD2F-B921-4374-B412-ACF445CF3945@kumari.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=A99B8609 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.129.3] Subject: Re: [dane] WGLC reminder. 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 Feb 2012 08:59:37 -0000 On 02/22/12 01:53, Warren Kumari wrote: > something that would certainly make our lives much simpler is if folk who feel that their issues have been addressed / a compromise has been reached would *clearly* state so. I hereby state that. (is that proper English?) -- Marco From gnu@toad.com Wed Feb 22 23:48:46 2012 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 461CC21E802B for ; Wed, 22 Feb 2012 23:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYIKEuNUXJKb for ; Wed, 22 Feb 2012 23:48:45 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 560F221E8016 for ; Wed, 22 Feb 2012 23:48:45 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1N7mfWD029278; Wed, 22 Feb 2012 23:48:41 -0800 Message-Id: <201202230748.q1N7mfWD029278@new.toad.com> To: Warren Kumari In-reply-to: <8735DD2F-B921-4374-B412-ACF445CF3945@kumari.net> References: <8735DD2F-B921-4374-B412-ACF445CF3945@kumari.net> Comments: In-reply-to Warren Kumari message dated "Tue, 21 Feb 2012 19:53:52 -0500." Date: Wed, 22 Feb 2012 23:48:41 -0800 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] WGLC reminder. 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, 23 Feb 2012 07:48:46 -0000 > something that would certainly make our lives much simpler is if > folk who feel that their issues have been addressed / a compromise > has been reached would *clearly* state so. I found many nits, and many other issues, in dane-protocol-16. Some nits have clearly been recognized for correction. Other issues I raised have provoked more discussion. Some have provoked no discussion at all. I'd like to see a -17 before determining whether my issues have been addressed. I should also note for the record that I gave up on raising more issues at a certain point in the discussion. When it became clear to me that the editors were objecting to making substantial changes to the document (where "substantial" refers to things like inserting four or five short paragraphs of text already written by someone else), I narrowed my subsequent email contributions to merely the kinds of nits that not even a recalcitrant editor could ignore; and to the kind of major issues that I felt were fundamental to the document (like how the various usage types affect the TLS protocol). The idea that the document should be comprehensible to system administrators deploying TLSA records in their own domains, rather than just programmers implementing them in software, was also apparently rejected, with the suggestion that a second, unofficial document should be written by someone else (perhaps me) instead of inserting context or clarifying the prose in the official document. The suggestion that document should avoid the passive voice was not acknowledged or accepted, despite the advice of the RFC Style Guide: https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt * Passive voice (e.g., "The dog was kicked by you") may be used but is frowned upon. Text should be written in active voice (e.g., "You kicked the dog"). In some cases linked suggestions were separated and then rejected. E.g. the idea that we should (1) explain the certificate usages in the document from simplest to most complex, and (2) renumber the certificate usages from simplest to most complex. This was rejected with the remark that we should of course present the certificate usages in numerical order (the idea of renumbering was ignored). An issue that I raised which saw little discussion was that the term "Certificate Association", which is used about 36 times in the document, is not well defined. Here is its definition: 1.1. Certificate Associations A certificate association is formed from a piece of information identifying a certificate with the domain name where the data is found. That sentence may tell you how it's formed, but it doesn't tell you what it is. An object may be formed from metal, but what is it? A paperclip, a fire extinguisher, or an engine block? The generalities in the definition leach almost all the meaning from the sentence. "A piece of information"? All computing is composed of pieces of information, can we not be more specific? "Where the data is found"? What data? Who is finding it? To misquote Radia, "Don't be impressed with unintelligible stuff, period." We also use the bare word "association" in phrases like this: An example of a hashed (SHA-256) association of a PKIX CA certificate: ... This is not the King's English ("association" is usually followed by "with" or "between" to define the two things being associated, or by "of" to name a plural noun like "scientists"). Nor is it a well known term of computing art, nor is it a term that we defined clearly in the document. We should either define it clearly, or avoid the term. Is a certificate association a relationship (between a cert and a domain name)? If not, what is it? An assertion, perhaps? If it is a relationship or an assertion, why not say so? My proposed replacement text was: A "certificate association" is a relationship formed by securely identifying a certificate with a domain name. This lack of clarity in a concept so fundamental to the RFC (which even appears in the abbreviated title at the bottom of each page of the draft, "DNS Cert Association for TLS"), combined with the editors' reluctance to clarify it, is why I suggested that the document be revised in those 36 places to refer to "TLSA records" rather than to "certificate associations". We all agree on what a TLSA record is, and the document defines it clearly. > Again, thank you all for your assistance, You're welcome. John From ondrej.sury@nic.cz Thu Feb 23 07:38:30 2012 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 2300921F8829 for ; Thu, 23 Feb 2012 07:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTiIZdGG+iLG for ; Thu, 23 Feb 2012 07:38:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EDD3421F8828 for ; Thu, 23 Feb 2012 07:38:28 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:96f:8ae3:8245:cfa8] (unknown [IPv6:2001:1488:ac14:1400:96f:8ae3:8245:cfa8]) by mail.nic.cz (Postfix) with ESMTPSA id 963E92A2E88 for ; Thu, 23 Feb 2012 16:38:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330011505; bh=yjH1bOV/4d8EMm36k4fqlYlSTnS+UrkN8bfAeqdystE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=x3RQ2eI/8e+LwZxQKsgn60Y60qQKcFDRRYjLJkHhJOvJhakkFlE3UiiUP9Ym+G7is vPnicqDQwC9uLxzcLfVu5PSsr9/izMAECZDwPDRpnl0dtAqIzkO2lXRjllInGcoVVa 7L4DZwZlnfoU/kEoHNyZgH+oYX7XgAnV6UA0kV7Q= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 23 Feb 2012 16:38:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: IETF DANE WG List X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 15:38:30 -0000 Dear WG members, I have read and re-read this thread (and sorry I havn't been available = in last week(s), I've caught some nasty bug) and didn't find any support = for Zack's proposal. Since this have generated a lot of (heated) discussion, I would like to = hear simple +1/-1 if we should pursue this discussion further. I.e. I = am asking if there is anybody else supporting Zack's proposal or if = there is consensus in WG (which I feel) to not pursue this further? I think I have already stated this before, that I don't support this = idea (as a no-hatted person and as a chair). Please speak now or never :). Thanks, O. On 11. 2. 2012, at 0:20, Zack Weinberg wrote: > On Thu, Feb 9, 2012 at 8:37 AM, Paul Hoffman = wrote: >>> I promised to file an issue on this and I really will get to it = either today or tomorrow. >>=20 >> Instead of filing an issue, consider sending proposed alternate text = that says exactly what you want the document to say. >=20 > It is a substantive change, but sure, why not. >=20 > Add to the end of section 1.1: "Three of the four types of > association defined in this document ("usages") make use of a > _certificate chain_, beginning with the target certificate from the > TLS handshake, and ending with a _trust anchor_. This document does > not specify how a DANE client constructs this chain; however, one > algorithm for doing so is in [RFC5280]. Chain construction may > include 'validation' checks for certificates that are ill-formed or > contrary to client policy; again, this document does not specify any > such checks." >=20 > In section 2.1.1, change all four usage definitions to read: >=20 > 0 -- The certificate chain MUST include a CA certificate which > matches the TLSA record, and MUST terminate in a trust anchor already > known to the client. > 1 -- The target certificate MUST match the TLSA record, and the > certificate chain MUST terminate in a trust anchor already known to > the client. > 2 -- The certificate chain MUST include a CA certificate which > matches the TLSA record. This certificate MUST be treated as a valid > trust anchor for that chain, for this TLS handshake only, whether or > not it was already known to the client. > 3 -- The target certificate MUST match the TLSA record. The client > MUST accept this certificate regardless of the contents of the chain. >=20 > Replace sections 4.1 through 4.4 inclusive with this text: >=20 > 4.1. Chain Through CA >=20 > Certificate usage 0 specifies a CA certificate, or the public key > of such a certificate, that must appear in the certificate chain > that the client has constructed from the target certificate in the > TLS handshake. This usage is sometimes referred to as "CA > constraint", because it limits which CAs may issue certificates for > a given host name. >=20 > 4.2. Chain =46rom Target >=20 > Certificate usage 1 specifies an end-entity certificate, or the > public key of such a certificate, that must begin the certificate > chain that the client constructs. This usage is sometimes referred > to as "service certificate constraints", because it limits which > end entity certificate may be used by a given host name. >=20 > 4.3. Chain To Novel Trust Anchor >=20 > Certificate usage 2 specifies a CA certificate, or the public key > of such a certificate, that must appear in the certificate chain > that the client constructs, and is to be treated as the trust > anchor for that chain.This usage is sometimes referred to as "trust > anchor assertion", because it allows a domain name administrator to > specify use of a trust anchor that may not already be known to the > client. >=20 > 4.4. Match Target Certificate, Skip Chain Construction >=20 > Certificate usage 3 specifies a certificate that must appear as the > target certificate in the TLS handshake, and requires the client to > accept this certificate without going through the normal process of > chain construction and location of a trust anchor. However, the = client > SHOULD still perform any validation checks that apply to the = certificate > itself, rather than the chain (such as for improper name = information, > insufficiently large keys, or insecure hash algorithms). This usage = is > sometimes referred to as "domain-issued certificate", because it > allows for a domain name administrator to issue certificates for a > domain without involving a third-party CA. >=20 > In appendix B, delete all occurrences of the string "pass PKIX > validation and", change all occurrences of the string "PKIX validation > chain H" to "certificate chain H". Change the first two occurrences > of the string "C passes PKIX validation in H" to "H is a valid chain > from C to a known trust anchor". Change the third occurrence of that > string to "H is a valid chain from C to R". >=20 > zw > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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 Thu Feb 23 07:43:51 2012 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 8646421F8831 for ; Thu, 23 Feb 2012 07:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iALqCSC1vBvz for ; Thu, 23 Feb 2012 07:43:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BD69E21F8820 for ; Thu, 23 Feb 2012 07:43:50 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:96f:8ae3:8245:cfa8] (unknown [IPv6:2001:1488:ac14:1400:96f:8ae3:8245:cfa8]) by mail.nic.cz (Postfix) with ESMTPSA id CE1622A2FA3; Thu, 23 Feb 2012 16:43:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330011829; bh=Se/xx1e55ykvQhOB7pA1QG6oCwBzBsGgR9y5jF4TVEc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=twFvAOuyWTEIGiT33Z34coiaG9ynNXQex4BeAePEDrGnwobVYgdeY4jANuoWVwyqH bQEdJ5DJ18pRxksiMZ9HPFu6sb7YSkGziVMUhivxO+n5HVMmaPs0oLTu0g8PorjJmp LWCD0gTUij+iTqwJia8tG1qgAIZG0yp3fyGhFqcg= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201202211807.q1LI78Za008851@fs4113.wdf.sap.corp> Date: Thu, 23 Feb 2012 16:43:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202211807.q1LI78Za008851@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG List Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-16.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, 23 Feb 2012 15:43:51 -0000 On 21. 2. 2012, at 19:07, Martin Rex wrote: > Ondrej Sury wrote: >>=20 >> James Cloos wrote: >>>=20 >>> It seems that those who want to use TLS proxies and also support >>> DANE-aware clients which are compliant with our drafts will need to >>> fully proxy DNS, too. >>>=20 >>> Just like they have to provide the inside clients with a cert to act = as >>> a root tls trust anchor, they will need to provide a DS RR for . = which >>> they control, verify the outside sigs, and re-sign everything before >>> passing it on to the inside clients. >>>=20 >>> This is, really, no different than what they already do to TLS. >>>=20 >>> They also would need to do that for CMS and OpenPGP, should they = care >>> about encrypted email, too. Et cetera, und so weiter, and so on. >>=20 >> +1 >>=20 >> I am not encouraging this, but writing a simple validating DNS proxy >> which will (re)sign validated DNS records with own private keys = should >> be simple with (lib)unbound. >=20 >=20 > I am violently opposed to the extending that nonsense that MITM TLS = Proxies > are currently doing (totally subverting PKI) to DNSSEC. Martin, and I was not saying we should put anything like that in DANE. = I was just stating that it should not stop us. O. -- 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 owens@nysernet.org Thu Feb 23 07:55:09 2012 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 C1DD821F86A2 for ; Thu, 23 Feb 2012 07:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBl8Z-YtqGdD for ; Thu, 23 Feb 2012 07:55:09 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id B1C3821F8664 for ; Thu, 23 Feb 2012 07:55:07 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id 53931ADAC8B; Thu, 23 Feb 2012 10:55:06 -0500 (EST) Date: Thu, 23 Feb 2012 10:55:05 -0500 From: Bill Owens To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20120223155505.GE38830@nysernet.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:55:09 -0000 On Thu, Feb 23, 2012 at 04:38:25PM +0100, OndÅ™ej Surý wrote: > Dear WG members, > > I have read and re-read this thread (and sorry I havn't been available in last week(s), I've caught some nasty bug) and didn't find any support for Zack's proposal. > > Since this have generated a lot of (heated) discussion, I would like to hear simple +1/-1 if we should pursue this discussion further. I.e. I am asking if there is anybody else supporting Zack's proposal or if there is consensus in WG (which I feel) to not pursue this further? > > I think I have already stated this before, that I don't support this idea (as a no-hatted person and as a chair). > > Please speak now or never :). -1 I am unqualified to judge whether existing implementations are following the PKIX standards or not; however, I don't buy the argument that requiring the standard as part of DANE is going to prevent adoption. If someone is already ignoring the PKIX standard (for good reason, or not) they're not going to be put off by our reference to it. Philosophically, IETF standards ought to reference each other, and as has already been suggested any objections to PKIX should be taken up with that WG, or perhaps on the new 'therightkey' list. Bill. From zack.weinberg@gmail.com Thu Feb 23 08:05:51 2012 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 D7B2621F87E5 for ; Thu, 23 Feb 2012 08:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wcTblPOi0JV for ; Thu, 23 Feb 2012 08:05:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0CF21F87E3 for ; Thu, 23 Feb 2012 08:05:51 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1870984obb.31 for ; Thu, 23 Feb 2012 08:05:50 -0800 (PST) Received-SPF: pass (google.com: domain of zack.weinberg@gmail.com designates 10.182.109.106 as permitted sender) client-ip=10.182.109.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of zack.weinberg@gmail.com designates 10.182.109.106 as permitted sender) smtp.mail=zack.weinberg@gmail.com; dkim=pass header.i=zack.weinberg@gmail.com Received: from mr.google.com ([10.182.109.106]) by 10.182.109.106 with SMTP id hr10mr758342obb.27.1330013150648 (num_hops = 1); Thu, 23 Feb 2012 08:05:50 -0800 (PST) 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 :content-transfer-encoding; bh=EeusjTO6Ru94QLrQfwM53JB1D8OglqZM4TlkSiPnxhs=; b=akJv0kgshD2IZg6bg/fuSRZeuXvlfz70LCXI8HPHbO8UoceGLenrmcDrvgsI8NBrSz qHBgYd3hrrRa3mZsOMlOww2I6s7ZwnWC6DghXhQlGNtPGV+1j/kt6p4vvpLNOG1+ehkW WpPbem7jaaADm6S0x0+fDf9GgWOyp0MbFUzts= MIME-Version: 1.0 Received: by 10.182.109.106 with SMTP id hr10mr662103obb.27.1330013150521; Thu, 23 Feb 2012 08:05:50 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Thu, 23 Feb 2012 08:05:50 -0800 (PST) In-Reply-To: <20120223155505.GE38830@nysernet.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <20120223155505.GE38830@nysernet.org> Date: Thu, 23 Feb 2012 08:05:50 -0800 X-Google-Sender-Auth: 3FLp1UgEl-BZ5Zs6b8IeaBAkNo0 Message-ID: From: Zack Weinberg To: owens@nysernet.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 16:05:52 -0000 On Thu, Feb 23, 2012 at 7:55 AM, Bill Owens wrote: >> Since this have generated a lot of (heated) discussion, I would like to = hear simple +1/-1 if we should pursue this discussion further. =C2=A0I.e. I= am asking if there is anybody else supporting Zack's proposal or if there = is consensus in WG (which I feel) to not pursue this further? I request that instead of calling for consensus on this now, discussion be suspended for another week. It is clear to me that I did not make an adequate case for the change I want, but due to deadlines on an unrelated project, I have not had time to do any research with which to make a better case. zw From paul.hoffman@vpnc.org Thu Feb 23 08:23:01 2012 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 D333821F878E for ; Thu, 23 Feb 2012 08:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvi9MK5FsTdb for ; Thu, 23 Feb 2012 08:23:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00221F874A for ; Thu, 23 Feb 2012 08:22:59 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1NGMwh8026230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Feb 2012 09:22:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201202230748.q1N7mfWD029278@new.toad.com> Date: Thu, 23 Feb 2012 08:22:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <25A02F82-6552-4FD1-9310-9118992849E6@vpnc.org> References: <8735DD2F-B921-4374-B412-ACF445CF3945@kumari.net> <201202230748.q1N7mfWD029278@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] WGLC reminder. 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, 23 Feb 2012 16:23:02 -0000 On Feb 22, 2012, at 11:48 PM, John Gilmore wrote: > I should also note for the record that I gave up on raising more > issues at a certain point in the discussion. When it became clear to > me that the editors were objecting to making substantial changes to > the document (where "substantial" refers to things like inserting > four or five short paragraphs of text already written by someone > else), I narrowed my subsequent email contributions to merely the > kinds of nits that not even a recalcitrant editor could ignore; and to > the kind of major issues that I felt were fundamental to the document > (like how the various usage types affect the TLS protocol). That's a pretty weird reaction to me asking if others wanted the same = changes you wanted. I didn't "object": I voiced an opinion that it was = not useful, but made it clear that was just one opinion. If you have = followed the WG at all, you will know that sometimes Jakob and I voice = an opinion that the WG disagrees with, and *every time* we reflect the = WG's consensus in the document. --Paul Hoffman From paul.hoffman@vpnc.org Thu Feb 23 09:05:12 2012 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 CB08E21F86D8 for ; Thu, 23 Feb 2012 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.638 X-Spam-Level: X-Spam-Status: No, score=-102.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xy9IJxplL-v for ; Thu, 23 Feb 2012 09:05:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 337A921F86CE for ; Thu, 23 Feb 2012 09:05:12 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1NH5Bed028191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Feb 2012 10:05:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 23 Feb 2012 09:05:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <42911B41-16B2-4445-A7DB-7624F6C94F11@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <20120223155505.GE38830@nysernet.org> To: Zack Weinberg X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 17:05:12 -0000 On Feb 23, 2012, at 8:05 AM, Zack Weinberg wrote: > On Thu, Feb 23, 2012 at 7:55 AM, Bill Owens = wrote: >>> Since this have generated a lot of (heated) discussion, I would like = to hear simple +1/-1 if we should pursue this discussion further. I.e. = I am asking if there is anybody else supporting Zack's proposal or if = there is consensus in WG (which I feel) to not pursue this further? >=20 > I request that instead of calling for consensus on this now, > discussion be suspended for another week. =20 -1 > It is clear to me that I > did not make an adequate case for the change I want, but due to > deadlines on an unrelated project, I have not had time to do any > research with which to make a better case. If the WG does not support you now, you can still make this argument in = IETF Last Call. --Paul Hoffman From kent@bbn.com Thu Feb 23 10:12:53 2012 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 79A1C21F87DE for ; Thu, 23 Feb 2012 10:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy6mTVAFUDMa for ; Thu, 23 Feb 2012 10:12:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 806DC21F87E5 for ; Thu, 23 Feb 2012 10:12:38 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34393 helo=[10.243.16.34]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S0d9Z-0006LZ-Dn; Thu, 23 Feb 2012 13:12:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> Date: Thu, 23 Feb 2012 13:06:21 -0500 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: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 18:12:53 -0000 At 4:38 PM +0100 2/23/12, Ond=DEej Sur=98 wrote: >Dear WG members, > >I have read and re-read this thread (and sorry I=20 >havn't been available in last week(s), I've=20 >caught some nasty bug) and didn't find any=20 >support for Zack's proposal. > >Since this have generated a lot of (heated)=20 >discussion, I would like to hear simple +1/-1 if=20 >we should pursue this discussion further. I.e.=20 >I am asking if there is anybody else supporting=20 >Zack's proposal or if there is consensus in WG=20 >(which I feel) to not pursue this further? > >I think I have already stated this before, that=20 >I don't support this idea (as a no-hatted person=20 >and as a chair). > >Please speak now or never :). > >Thanks, >O. -1 (i.e., I do not support Zack's proposal) From zack.weinberg@gmail.com Thu Feb 23 11:25:29 2012 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 67B4221F8627 for ; Thu, 23 Feb 2012 11:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBzqYvyn5jpg for ; Thu, 23 Feb 2012 11:25:28 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C15B921F8605 for ; Thu, 23 Feb 2012 11:25:28 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2124131obb.31 for ; Thu, 23 Feb 2012 11:25:28 -0800 (PST) Received-SPF: pass (google.com: domain of zack.weinberg@gmail.com designates 10.182.188.36 as permitted sender) client-ip=10.182.188.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of zack.weinberg@gmail.com designates 10.182.188.36 as permitted sender) smtp.mail=zack.weinberg@gmail.com; dkim=pass header.i=zack.weinberg@gmail.com Received: from mr.google.com ([10.182.188.36]) by 10.182.188.36 with SMTP id fx4mr1113065obc.7.1330025128507 (num_hops = 1); Thu, 23 Feb 2012 11:25:28 -0800 (PST) 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:cc:content-type; bh=dxy+HY11efKXEtdVj7OW7nugkkv9wpljmSTNUJ5ZEJ4=; b=phDo209JZb9cKtq5BUPbyGSOaspKow75Xu7KAdd5Tlgcty0E7oqt0m4l+TQ4kmO1Sf XSZYNrJCYP49b/UM6G031IbeUO8yEagCeUaAV/9YuJMham4PtVXECdAG+dO/Wliwyy4y 8vxdQGXHZniPVlXII08NBtHjSp4JrgiQDe+NM= MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr964673obc.7.1330025128452; Thu, 23 Feb 2012 11:25:28 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.53.73 with HTTP; Thu, 23 Feb 2012 11:25:28 -0800 (PST) Date: Thu, 23 Feb 2012 11:25:28 -0800 X-Google-Sender-Auth: XToIMYO3U9SLr5SSOlcrCyY2dCM Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: IETF DANE WG list Subject: [dane] Let's all take a deep breath and SLOW DOWN (was Re: WG Last Call item: PKIX validation) 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, 23 Feb 2012 19:25:29 -0000 On Thu, Feb 23, 2012 at 9:05 AM, Paul Hoffman wrote: >> It is clear to me that I >> did not make an adequate case for the change I want, but due to >> deadlines on an unrelated project, I have not had time to do any >> research with which to make a better case. > > If the WG does not support you now, you can still make this argument in IETF Last Call. You are effectively saying that you believe this document to be *done* and you do not want to hear different from anyone. This is consistent with the responses that other people (notably John Gilmore) are getting, but it is exceedingly demotivating. It has already been made abundantly clear that presentation improvements are unwelcome, even where desperately needed; and it has also become apparent that the group is uninterested in "minor" technical problems. But I am trying to convince you that there is a *showstopper* bug here, and apparently you don't want to hear about that, either. I realize that there's been a lot of filibustering and attempted mission creep in this WG and perhaps everyone is tired of thinking about this document and *wants* it to be done, but that doesn't make it done. It seems far more important to me that this document be *completely correct* when first published than that it get out the door soon. Is there a publication deadline I am unaware of? What, precisely, is the hurry? If what you are really trying to communicate is that I have no credibility whatsoever with this WG and I should stop wasting my time, I'd be grateful if you would just say so. I do have plenty of other things I could be working on. But if not, please, everyone, let's not rush this through WGLC. Let's slow down, calm down, and get it right. zw From paul.hoffman@vpnc.org Thu Feb 23 11:39:46 2012 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 4337021F8674 for ; Thu, 23 Feb 2012 11:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKjCvhh1tIPP for ; Thu, 23 Feb 2012 11:39:45 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5221F84F9 for ; Thu, 23 Feb 2012 11:39:45 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1NJdiVg034063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Feb 2012 12:39:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 23 Feb 2012 11:39:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E10C674-C6F0-40B7-9CB7-C475ADB82527@vpnc.org> References: To: Zack Weinberg X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Let's all take a deep breath and SLOW DOWN (was Re: WG Last Call item: PKIX validation) 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, 23 Feb 2012 19:39:46 -0000 On Feb 23, 2012, at 11:25 AM, Zack Weinberg wrote: > On Thu, Feb 23, 2012 at 9:05 AM, Paul Hoffman = wrote: >>> It is clear to me that I >>> did not make an adequate case for the change I want, but due to >>> deadlines on an unrelated project, I have not had time to do any >>> research with which to make a better case. >>=20 >> If the WG does not support you now, you can still make this argument = in IETF Last Call. >=20 > You are effectively saying that you believe this document to be *done* > and you do not want to hear different from anyone. =20 Don't put words in my mouth. I am definitely (not effectively) saying = that WG Last Call is an appropriate time to discuss open issues before = sending a document to the IETF. The document is clearly *not done* = because we have gotten many good comments during WG LC that have gotten = consensus. Jakob and I will make those changes. > This is consistent > with the responses that other people (notably John Gilmore) are > getting, but it is exceedingly demotivating. The fact that you, or John, make requests for changes that are not = supported by others in the WG should not be demotivating. That's part of = the process. > It has already been made abundantly clear that presentation > improvements are unwelcome, even where desperately needed; That's bullshit. Presentation improvements suggested by the WG have been = added almost every other draft. > and it has > also become apparent that the group is uninterested in "minor" > technical problems. But I am trying to convince you that there is a > *showstopper* bug here, and apparently you don't want to hear about > that, either. Truth be told, I don't want to hear it the third time when the WG has = shown no interest earlier. > I realize that there's been a lot of filibustering and attempted > mission creep in this WG and perhaps everyone is tired of thinking > about this document and *wants* it to be done, but that doesn't make > it done. It seems far more important to me that this document be > *completely correct* when first published than that it get out the > door soon. Is there a publication deadline I am unaware of? =20 No. > What, > precisely, is the hurry? There is none. The fact that people disagree with you and don't want to = hear your same arguments again doesn't mean that there is a hurry, does = it? > If what you are really trying to communicate is that I have no > credibility whatsoever with this WG and I should stop wasting my time, > I'd be grateful if you would just say so. I wouldn't try to communicate that to you because it isn't true. > I do have plenty of other > things I could be working on. But if not, please, everyone, let's not > rush this through WGLC. Let's slow down, calm down, and get it right. There has bee a *lot* of good discussion in WG LC on lots of issues. = Your insinuation that, because we aren't waiting for you to re-explain = this one point we must be rushing, is kind of insulting to the rest of = the people who have been on top of the discussion. --Paul Hoffman From ondrej.sury@nic.cz Thu Feb 23 12:05:52 2012 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 4355C21F885B for ; Thu, 23 Feb 2012 12:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DclOO0+vEz7D for ; Thu, 23 Feb 2012 12:05:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7C021F8852 for ; Thu, 23 Feb 2012 12:05:51 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id AD0152A287D for ; Thu, 23 Feb 2012 21:05:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330027549; bh=RT2mcqXsXrt/3tFM9Dsf3YaBDT0pSgymQrb3cSrwMYI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=DmbB6d+/X4kkYgKcJByJAdOE2Mk9tPiDYXgnvTCx6B5SXs8L7in3KrFtxBt/DUhVt ZyZIJsL0zwaqF/wajNFn7XrPchDNpumRoc8/libEa1zlYXK+w2yafisa1jlSx3z+gb Dxv2fQgzfGM4S/FhYAIVI0Og0GdSKVyPCLACPs8g= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <7E10C674-C6F0-40B7-9CB7-C475ADB82527@vpnc.org> Date: Thu, 23 Feb 2012 21:05:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2CDD2EEF-01E3-462F-BC60-F961ED045181@nic.cz> References: <7E10C674-C6F0-40B7-9CB7-C475ADB82527@vpnc.org> To: IETF DANE WG List X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Let's all take a deep breath and SLOW DOWN (was Re: WG Last Call item: PKIX validation) 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, 23 Feb 2012 20:05:52 -0000 Hi all, it looks like we are on the verge of a very nice flamewar, which I would = personally like to prevent. So I am asking anybody to stick to the = technical views and if feel a great urge to respond, please don't send = the email immediately, but wait a hour, re-read the mail and rethink if = you really need to send it. Chairs would also like to ask anybody to contact them directly = (dane-chairs@tools.ietf.org) if you think that the working group opinion = has been ignored or we made any other error in handling the consensus in = the working group. Ondrej&Warren -- 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 rbarnes@bbn.com Thu Feb 23 12:36:01 2012 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 102FD21F8887 for ; Thu, 23 Feb 2012 12:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.163 X-Spam-Level: X-Spam-Status: No, score=-106.163 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC1pO2VungGy for ; Thu, 23 Feb 2012 12:35:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC2B21F8871 for ; Thu, 23 Feb 2012 12:35:59 -0800 (PST) Received: from ros-dhcp192-1-51-17.bbn.com ([192.1.51.17]:53464) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S0fOP-0004Yv-FX; Thu, 23 Feb 2012 15:35:57 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: "Richard L. Barnes" In-Reply-To: Date: Thu, 23 Feb 2012 15:35:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 20:36:01 -0000 On Feb 23, 2012, at 10:38 AM, Ond=C5=99ej Sur=C3=BD wrote: > Dear WG members, >=20 > I have read and re-read this thread (and sorry I havn't been available = in last week(s), I've caught some nasty bug) and didn't find any support = for Zack's proposal. >=20 > Since this have generated a lot of (heated) discussion, I would like = to hear simple +1/-1 if we should pursue this discussion further. I.e. = I am asking if there is anybody else supporting Zack's proposal or if = there is consensus in WG (which I feel) to not pursue this further? >=20 > I think I have already stated this before, that I don't support this = idea (as a no-hatted person and as a chair). >=20 > Please speak now or never :). >=20 > Thanks, > O. -1= From warren@kumari.net Thu Feb 23 13:46:58 2012 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 6752821E800F for ; Thu, 23 Feb 2012 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.555 X-Spam-Level: X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKntsS2GSvZR for ; Thu, 23 Feb 2012 13:46:57 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C936E11E807F for ; Thu, 23 Feb 2012 13:46:57 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1FFA11B4069C; Thu, 23 Feb 2012 16:46:57 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2012 16:46:55 -0500 Message-Id: <081B4DEA-3BE0-4896-B522-B73AEA09FBDD@kumari.net> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dane] Initial set of discussions / feedback from WGLC. 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, 23 Feb 2012 21:46:58 -0000 Hi there all, Again, thanks for all of the comments and discussions. There were a number of discussions where we felt that a consensus call = was needed / would be helpful -- there are still others, but Ondrej and = myself need to chat more about them. So, here we go: 1: dane-protocol-16 lacks real introductions Consensus:=20 The authors are requested to flesh out the introduction a little to make = is easier for newcomers to understand the point of this. John Gilmore = provided sample text, the authors are encouraged to use this as a = starting point. 2: "First" request TLSA records? Consensus: The authors are requested to incorporate John's text ("An implementation = of this protocol makes a DNS query for TLSA... " The authors are also requested to update the Section 5 title as = discussed in this thread. 3: WGLC thread (hash specs?) Consensus: The authors are requested to incorporate the Section 2.1.3 text based = upon what Olafur suggested. Paul Hoffman said : "SHOULDized version based on later suggestions will = appear in the next draft.", so it sounds like this is already done. 4: Deduplicate usage semantics in 4 and 2.1.1. The editors are requested to merge Section 4 and 2.1.1 -- the working = group *appears* to prefer Section 4 to 2.1.1, and it was suggested that = the first sentence of 2.1.1 become the first sentence of 4. In order to = keep the same voice and tone, how exactly to merge this is left to the = authors -- the WG will be given a chance to confirm the new text. 5: Stopping TLSA. Consensus: The authors are requested to insert text in the security considerations = on how to stop using TLSA. Example text provided by Wouter: "If an administrator wishes to stop using a TLSA record, the administrator can simply remove it from the DNS. Normal clients stop using the TLSA record after the TTL has expired. Replay attacks are no longer possible after the expiration date on the RRSIG." The authors are also requested to please let the chairs know if these = calls are unclear...=20 The chairs will chat more about some of the other open discussions / = places where clear consensus was not obvious. If the WG feels that the = chairs have misjudged consensus on any of the above, please let us know = directly.... W --=20 American Non-Sequitur Society;=20 we don't make sense, but we do like pizza. From tom@ritter.vg Thu Feb 23 15:01:38 2012 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 9B1E921F8877 for ; Thu, 23 Feb 2012 15:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVieniav-XJ9 for ; Thu, 23 Feb 2012 15:01:37 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1AA21F8874 for ; Thu, 23 Feb 2012 15:01:37 -0800 (PST) Received: by lahl5 with SMTP id l5so2452363lah.31 for ; Thu, 23 Feb 2012 15:01:28 -0800 (PST) Received-SPF: pass (google.com: domain of tom@ritter.vg designates 10.112.49.135 as permitted sender) client-ip=10.112.49.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom@ritter.vg designates 10.112.49.135 as permitted sender) smtp.mail=tom@ritter.vg; dkim=pass header.i=tom@ritter.vg Received: from mr.google.com ([10.112.49.135]) by 10.112.49.135 with SMTP id u7mr1411409lbn.86.1330038088237 (num_hops = 1); Thu, 23 Feb 2012 15:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dvDyqAUVyh31nDMpNqmEKODqa5Obsk7R1tbraE6O3bM=; b=jUMbK5HhlKVmfRTWhz4hW2zxh+MGcshvftiRjPibVS6Vdsr7d2bbjnD7/rooWmjL83 MsJk2ixLu/E+KYq/mB77BbU7QvqbE8v846pzfsf14kK88JgAEZrFQVfs0VQOWt1mcJPL aFuvstCjXVNZR86voH7XCJSU7cJY81PnXuta4= Received: by 10.112.49.135 with SMTP id u7mr1181450lbn.86.1330038088111; Thu, 23 Feb 2012 15:01:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.4 with HTTP; Thu, 23 Feb 2012 15:01:08 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> From: Tom Ritter Date: Thu, 23 Feb 2012 18:01:08 -0500 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnyZkekY9E7PuFLnz2MuWgt+t1glNB6j4Ahj12u02zFhPl9YO2EfAN3FyuBFoH9pMTSfAH6 Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 23:01:38 -0000 On 23 February 2012 10:38, Ond=C5=99ej Sur=C3=BD wrote= : > Since this have generated a lot of (heated) discussion, I would like to h= ear simple +1/-1 if we should pursue this discussion further. =C2=A0I.e. I = am asking if there is anybody else supporting Zack's proposal or if there i= s consensus in WG (which I feel) to not pursue this further? > > I think I have already stated this before, that I don't support this idea= (as a no-hatted person and as a chair). Sorry it's not a + or -1, but I have to reiterate my earliest statements from Jan 31. Since there isn't a -17 for me to work off of, and I have to assume thing with regards to this has changed - then I remain confused about the phrase "Pass PKIX Validation" and as far as I can tell, it is not defined in the document. I think it should be. It seems most (?) people think that statement means being compliant with all of/a section of 5280. If so, I think it should be clarified as such. The following point is good: if clients do non-standard validation now, requiring compliant validation with DANE will likewise be ignored, and probably won't slow implementation. I remain +1 towards clarifying it _somehow_. -tom From ondrej.sury@nic.cz Thu Feb 23 15:46:27 2012 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 3B0C821F883B for ; Thu, 23 Feb 2012 15:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMI1MKldy4k9 for ; Thu, 23 Feb 2012 15:46:26 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 744B621F8601 for ; Thu, 23 Feb 2012 15:46:26 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 40FC32A2726; Fri, 24 Feb 2012 00:46:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330040785; bh=FWCj6wW9gYYfdYXUrpkrQS0QD/jUYl8hozjmMhzxL7s=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YGc1LkNN57uEcQNwWPIAAZmAQwKka+oXcrWgtvwd5R2Vl6OC2ESnhcaWOVMIy11VU H7kn+Z8AC+PDf5U2newxFptDAYG4HVx+J9B8drddbciqbLxw7j0yTwy2J5FZVzepPS HKIOkzE6WX2niyJObfTMq2EgWoOXhnGKTQJzQ+9M= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 24 Feb 2012 00:46:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: Tom Ritter X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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, 23 Feb 2012 23:46:27 -0000 Tom, just to clarify, since you have stripped Zack's proposal. (I have = reordered paragraphs in your mail a little bit.) On 24. 2. 2012, at 0:01, Tom Ritter wrote: > On 23 February 2012 10:38, Ond=C5=99ej Sur=C3=BD = wrote: >> Since this have generated a lot of (heated) discussion, I would like = to hear simple +1/-1 if we should pursue this discussion further. I.e. = I am asking if there is anybody else supporting Zack's proposal or if = there is consensus in WG (which I feel) to not pursue this further? >>=20 >> I think I have already stated this before, that I don't support this = idea (as a no-hatted person and as a chair). I have asked if you support or not the proposal to drop PKIX validation = completely. > The following point is good: if clients do non-standard validation > now, requiring compliant validation with DANE will likewise be > ignored, and probably won't slow implementation. Now I am confused: This is more '-1' than '0' in my books. Which = contradicts your: > Sorry it's not a + or -1, but I have to reiterate my earliest > statements from Jan 31. ---- > Since there isn't a -17 for me to work off of, and I have to assume > thing with regards to this has changed - then I remain confused about > the phrase "Pass PKIX Validation" and as far as I can tell, it is not > defined in the document. I think it should be. >=20 > It seems most (?) people think that statement means being compliant > with all of/a section of 5280. If so, I think it should be clarified > as such. This is separate issue from what I have asked. > I remain +1 towards clarifying it _somehow_. I am fine with clarifying what 'PKIX Validation' means in our document. O. -- 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 tom@ritter.vg Thu Feb 23 16:01:55 2012 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 47CEB21F8675 for ; Thu, 23 Feb 2012 16:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM9GxqGVreCg for ; Thu, 23 Feb 2012 16:01:54 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44B21F8668 for ; Thu, 23 Feb 2012 16:01:53 -0800 (PST) Received: by lahl5 with SMTP id l5so2516792lah.31 for ; Thu, 23 Feb 2012 16:01:53 -0800 (PST) Received-SPF: pass (google.com: domain of tom@ritter.vg designates 10.112.49.135 as permitted sender) client-ip=10.112.49.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom@ritter.vg designates 10.112.49.135 as permitted sender) smtp.mail=tom@ritter.vg; dkim=pass header.i=tom@ritter.vg Received: from mr.google.com ([10.112.49.135]) by 10.112.49.135 with SMTP id u7mr1483974lbn.86.1330041713190 (num_hops = 1); Thu, 23 Feb 2012 16:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=toHT8OefyFMzkSjcU2LWsFw9JxUpm+wsFKn1on7RqbQ=; b=Ntr/Z1afYDQb7q1FXKQENDXc0nULAZrVyIPyZmfwYqd9rlNBo7rE1F1cdlnRO1naQf MV7KspLiKGEm9HkZT3dDfherxhZPcpBJm0YEuuwM0wyUhtafGl5mZXk9/8UU4krQ5am8 HdwdjCvc3EMy6si7eJVpIkFwX1vTgqtEObZA8= Received: by 10.112.49.135 with SMTP id u7mr1241864lbn.86.1330041713070; Thu, 23 Feb 2012 16:01:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.4 with HTTP; Thu, 23 Feb 2012 16:01:33 -0800 (PST) In-Reply-To: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> From: Tom Ritter Date: Thu, 23 Feb 2012 19:01:33 -0500 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnn1if8UaN75+FiGzLESj02EBt52eKPysAs2JHMlULj1aqG+c1uWFLKjrKwVvZCNP05Pqd7 Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 00:01:55 -0000 Now I'm confused =P I mostly meant "Sorry I'm not giving a 2 character response and actually making you read stuff." I am strongly for clarifying what 'PKIX Validation' means. I'm not against Zack's proposal, I'm not strongly for it. Consider me a 0. I was marginally for it originally, because I considered it a reasonable attempt to somehow clarify PKIX Validation. I understand Zack's point, and agree with it somewhat, but I think the point I repeated is also reasonable. I put forward the idea of clarifying it to mean "being compliant with all of/a section of 5280" since that was what *I* thought the consensus of the group was. I'm not against defining it as 5280, I'm marginally for it, because I think it's also a reasonable approach to clarify PKIX Validation. I typed more than a + or -1 because I wasn't sure if you were saying 'Last Call on Zack's proposal' or 'Last Call on what we have for the PKIX Validation terminology.' -tom. From paul.hoffman@vpnc.org Thu Feb 23 17:11:48 2012 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 E2A9D11E8097 for ; Thu, 23 Feb 2012 17:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqRcn2lye0ag for ; Thu, 23 Feb 2012 17:11:47 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 37DD211E808E for ; Thu, 23 Feb 2012 17:11:47 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1O1BjnV045483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Feb 2012 18:11:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: Date: Thu, 23 Feb 2012 17:11:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> To: Tom Ritter X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 01:11:48 -0000 On Feb 23, 2012, at 3:01 PM, Tom Ritter wrote: > On 23 February 2012 10:38, Ond=C5=99ej Sur=C3=BD = wrote: >> Since this have generated a lot of (heated) discussion, I would like = to hear simple +1/-1 if we should pursue this discussion further. I.e. = I am asking if there is anybody else supporting Zack's proposal or if = there is consensus in WG (which I feel) to not pursue this further? >>=20 >> I think I have already stated this before, that I don't support this = idea (as a no-hatted person and as a chair). >=20 > Sorry it's not a + or -1, but I have to reiterate my earliest > statements from Jan 31. >=20 > Since there isn't a -17 for me to work off of, and I have to assume > thing with regards to this has changed - then I remain confused about > the phrase "Pass PKIX Validation" and as far as I can tell, it is not > defined in the document. I think it should be. >=20 > It seems most (?) people think that statement means being compliant > with all of/a section of 5280. If so, I think it should be clarified > as such. Good catch. We mean "path validation", which is defined in RFC 5280. We = will make the following change (and similar throughout): 0 -- Certificate usage 0 is used to specify a CA certificate, or the = public key of such a certificate, that must be found in any of the PKIX = validation chains for the end entity certificate given by the server in TLS. This = usage is sometimes referred to as "CA constraint" because it limits which CA = can be used to issue certificates for a given host name, port, and protocol. = The target certificate MUST pass PKIX path validation and MUST chain through = a CA certificate (which might be the root of the chain) that matches the TLSA record. --Paul Hoffman From ondrej.sury@nic.cz Fri Feb 24 01:35:32 2012 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 2257C21F87C1 for ; Fri, 24 Feb 2012 01:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbesYhlVLulv for ; Fri, 24 Feb 2012 01:35:31 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 761D321F85D1 for ; Fri, 24 Feb 2012 01:35:21 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id E1FAC2A029E; Fri, 24 Feb 2012 10:35:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330076118; bh=Edl4mIzdS/s3AByrTxndtWHnmPu7omFHHMrw2lPeoa0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mxGiN/j2uhd+zRXWgYidNoz8iuZ3lKxa+qMSYEHpqkprMlbzopUt1h6U7hYBJtRmF 3vSybMZHfkp8Kw2lF8pEwpT0xAPqzI4nPD5gqjdDG/Q41PPCwcKSnnqy5/bp7kA6Lx DB+5XE4eQD59WnM3H6IBPN9zgl6il/sWLU4/jwzQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> Date: Fri, 24 Feb 2012 10:35:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 09:35:32 -0000 On 24. 2. 2012, at 2:11, Paul Hoffman wrote: > On Feb 23, 2012, at 3:01 PM, Tom Ritter wrote: >=20 >> On 23 February 2012 10:38, Ond=C5=99ej Sur=C3=BD = wrote: >>> Since this have generated a lot of (heated) discussion, I would like = to hear simple +1/-1 if we should pursue this discussion further. I.e. = I am asking if there is anybody else supporting Zack's proposal or if = there is consensus in WG (which I feel) to not pursue this further? >>>=20 >>> I think I have already stated this before, that I don't support this = idea (as a no-hatted person and as a chair). >>=20 >> Sorry it's not a + or -1, but I have to reiterate my earliest >> statements from Jan 31. >>=20 >> Since there isn't a -17 for me to work off of, and I have to assume >> thing with regards to this has changed - then I remain confused about >> the phrase "Pass PKIX Validation" and as far as I can tell, it is not >> defined in the document. I think it should be. >>=20 >> It seems most (?) people think that statement means being compliant >> with all of/a section of 5280. If so, I think it should be clarified >> as such. >=20 > Good catch. We mean "path validation", which is defined in RFC 5280. = We will make the following change (and similar throughout): >=20 > 0 -- Certificate usage 0 is used to specify a CA certificate, or the = public > key of such a certificate, that must be found in any of the PKIX = validation > chains for the end entity certificate given by the server in TLS. This = usage > is sometimes referred to as "CA constraint" because it limits which CA = can be > used to issue certificates for a given host name, port, and protocol. = The > target certificate MUST pass PKIX path validation and MUST chain = through a CA > certificate (which might be the root of the chain) that matches the = TLSA > record. RFC 5280 uses "certification path validation" (RFC 5280 Section 6) and = "validation chains" are called "certification chains" (RFC 5280 Section = 3.2), i.e. this would be: > 0 -- Certificate usage 0 is used to specify a CA certificate, or the = public > key of such a certificate, that must be found in any of the PKIX = certification > paths for the end entity certificate given by the server in TLS. This = usage > is sometimes referred to as "CA constraint" because it limits which CA = can be > used to issue certificates for a given host name, port, and protocol. = The > target certificate MUST pass PKIX certification path validation and CA = certificate > that matches the TLSA record MUST be included as part of valid = certification path. O. -- 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 paul.hoffman@vpnc.org Fri Feb 24 06:50:43 2012 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 1EE5D21F87E2 for ; Fri, 24 Feb 2012 06:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfW5sX1K4Ihl for ; Fri, 24 Feb 2012 06:50:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 653B721F878E for ; Fri, 24 Feb 2012 06:50:41 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1OEobHR072591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Feb 2012 07:50:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> Date: Fri, 24 Feb 2012 06:50:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG List Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 14:50:43 -0000 On Feb 24, 2012, at 1:35 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 24. 2. 2012, at 2:11, Paul Hoffman wrote: >=20 >> On Feb 23, 2012, at 3:01 PM, Tom Ritter wrote: >>=20 >>> On 23 February 2012 10:38, Ond=C5=99ej Sur=C3=BD = wrote: >>>> Since this have generated a lot of (heated) discussion, I would = like to hear simple +1/-1 if we should pursue this discussion further. = I.e. I am asking if there is anybody else supporting Zack's proposal or = if there is consensus in WG (which I feel) to not pursue this further? >>>>=20 >>>> I think I have already stated this before, that I don't support = this idea (as a no-hatted person and as a chair). >>>=20 >>> Sorry it's not a + or -1, but I have to reiterate my earliest >>> statements from Jan 31. >>>=20 >>> Since there isn't a -17 for me to work off of, and I have to assume >>> thing with regards to this has changed - then I remain confused = about >>> the phrase "Pass PKIX Validation" and as far as I can tell, it is = not >>> defined in the document. I think it should be. >>>=20 >>> It seems most (?) people think that statement means being compliant >>> with all of/a section of 5280. If so, I think it should be = clarified >>> as such. >>=20 >> Good catch. We mean "path validation", which is defined in RFC 5280. = We will make the following change (and similar throughout): >>=20 >> 0 -- Certificate usage 0 is used to specify a CA certificate, or the = public >> key of such a certificate, that must be found in any of the PKIX = validation >> chains for the end entity certificate given by the server in TLS. = This usage >> is sometimes referred to as "CA constraint" because it limits which = CA can be >> used to issue certificates for a given host name, port, and protocol. = The >> target certificate MUST pass PKIX path validation and MUST chain = through a CA >> certificate (which might be the root of the chain) that matches the = TLSA >> record. >=20 >=20 > RFC 5280 uses "certification path validation" (RFC 5280 Section 6) and = "validation chains" are called "certification chains" (RFC 5280 Section = 3.2), i.e. this would be: >=20 >> 0 -- Certificate usage 0 is used to specify a CA certificate, or the = public >> key of such a certificate, that must be found in any of the PKIX = certification >> paths for the end entity certificate given by the server in TLS. This = usage >> is sometimes referred to as "CA constraint" because it limits which = CA can be >> used to issue certificates for a given host name, port, and protocol. = The >> target certificate MUST pass PKIX certification path validation and = CA certificate >> that matches the TLSA record MUST be included as part of valid = certification path. Yes, that is more precise. I have changed "validation chain" to = "certification path", and "path validation" to "certificate path = validation", throughout the document (including in the pseudocode). The = main place affected is shown here; let Jakob and I know if there are = more changes to be made. 0 -- Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that must be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS. This usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given host name, port, and protocol. The target certificate MUST pass PKIX certification path validation and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path. 1 -- Certificate usage 1 is used to specify an end entity certificate, or the public key of such a certificate, that must be matched with the end entity certificate given by the server in TLS. This usage is sometimes referred to as "service certificate constraints" because it limits which end entity certificate may be used by a given host name, port, and protocol. The target certificate MUST pass PKIX certification path validation and MUST match the TLSA record. 2 -- Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that must be used as a trust anchor when validating the end entity certificate given by the server in TLS. This usage is sometimes referred to as "trust anchor assertion" and allows a domain name administrator to specify a new trust anchor, for example if the domain issues its own certificates under its own CA that is not expected to be in the end users' collection of trust anchors. The target certificate MUST pass PKIX certification path validation, with any certificate matching the TLSA record considered to be a trust anchor for this certification path validation. 3 -- Certificate usage 3 is used to specify a certificate, or the public key of such a certificate, that must match the end entity certificate given by the server in TLS. This usage is sometimes referred to as "domain-issued certificate" because it allows for a domain name administrator to issue certificates for a domain without involving a third-party CA. The target certificate MUST match the TLSA record. --Paul Hoffman From ondrej.sury@nic.cz Fri Feb 24 07:35:58 2012 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 BC83621F87C5 for ; Fri, 24 Feb 2012 07:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alwMPbMWNkyP for ; Fri, 24 Feb 2012 07:35:58 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1656F21F87B5 for ; Fri, 24 Feb 2012 07:35:58 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id 631022A2CF1; Fri, 24 Feb 2012 16:35:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330097757; bh=Jm2Fto34HfYfZZzczE3re0fEhebpwbDl/mF8xImzML8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=m3DYunvH+0/3IPLVpt8Dkl4E/Qe9Bj986hSaexfF09ICOhDk1qXGyzl5zoypIwZJa DQtCB5J9AixvqEQyMwqaqN+mDWU73Et+2PzV4CoZCLGhPtUln05L7ZCVrTVf9PXNis 2IbelqC6PtxOKhAsxZ1Dg/oV35u3RxZ22MV3oJ0Y= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 24 Feb 2012 16:35:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> To: James Cloos X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 15:35:58 -0000 On 16. 2. 2012, at 23:08, James Cloos wrote: >>>>>> "PH" =3D=3D Paul Hoffman writes: >=20 > PH> I think this is a request to get rid of usage type 2, or add a lot > PH> of technical requirements on its use. I'm OK with either of those > PH> actions, and would prefer to get rid of it to make the protocol = simpler. >=20 > -1 on removal. Just add a note that the TLS server SHOULD send the = cert > referenced by the type 2 TLSA RR just like it currently SHOULD (MUST?) > send intermediate certs. >=20 > Conceptually, the cert in question IS an intermediate cert; it is > just tied to DNS instead of to an OutOfBand x509 cert. >=20 > So wording it that way ought to be easy to comprehend and > implementations written based on that conceptualization should > Just Work=E2=84=A2. +1 to this solution. It works for me. Does it work for you, Paul? Any = objections from WG? (Reading RFC 5280 Section 6 is assumed.) O. -- 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 paul.hoffman@vpnc.org Fri Feb 24 07:40:55 2012 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 1F43821F87A2 for ; Fri, 24 Feb 2012 07:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3T1xepQ4-Qp for ; Fri, 24 Feb 2012 07:40:54 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1721F879E for ; Fri, 24 Feb 2012 07:40:54 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1OFerNR074521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Feb 2012 08:40:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: Date: Fri, 24 Feb 2012 07:40:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <01BCF918-FA1B-4F94-B0FC-CFD84416E1C7@vpnc.org> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 15:40:55 -0000 On Feb 24, 2012, at 7:35 AM, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 16. 2. 2012, at 23:08, James Cloos wrote: >=20 >>>>>>> "PH" =3D=3D Paul Hoffman writes: >>=20 >> PH> I think this is a request to get rid of usage type 2, or add a = lot >> PH> of technical requirements on its use. I'm OK with either of those >> PH> actions, and would prefer to get rid of it to make the protocol = simpler. >>=20 >> -1 on removal. Just add a note that the TLS server SHOULD send the = cert >> referenced by the type 2 TLSA RR just like it currently SHOULD = (MUST?) >> send intermediate certs. >>=20 >> Conceptually, the cert in question IS an intermediate cert; it is >> just tied to DNS instead of to an OutOfBand x509 cert. >>=20 >> So wording it that way ought to be easy to comprehend and >> implementations written based on that conceptualization should >> Just Work=E2=84=A2. >=20 >=20 > +1 to this solution. It works for me. Does it work for you, Paul? = Any objections from WG? (Reading RFC 5280 Section 6 is assumed.) Works for me if it works for the WG. --Paul Hoffman From ondrej.sury@nic.cz Fri Feb 24 07:52:24 2012 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 C300121F8834 for ; Fri, 24 Feb 2012 07:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdnVT-obPik4 for ; Fri, 24 Feb 2012 07:52:24 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 80AD421F882D for ; Fri, 24 Feb 2012 07:52:23 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id CBE242A0BBC for ; Fri, 24 Feb 2012 16:52:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330098742; bh=FqoxVSGxqFobdLe9+O8jBWxw5l3k0nDZznjJZnMbwt0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=ZXfLsnLqdgmEHClEs407rVhzrCwGdLM6xTsZT9PbA7JWuYNMuo7+08WdTDW4yvpei X4h8bHuGeqfcwQwBLGYD1ZDwtWEws3kRKvewXgxPvORQlCSBngaT1/Z/RzOBjzRSnT 8QqzhDiQ9ltta4vrLwm/VfM82YtpnJ2oBYXWeM3U= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> Date: Fri, 24 Feb 2012 16:52:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8FD95E20-12A3-4C15-BC93-BD058A9917BD@nic.cz> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 15:52:24 -0000 Does anybody else have anything to say? I have one objection to the text suggested by Bill below. As we don't = specify how the DNSSEC validation will be done, we really don't know how = this will be implemented. Thus I suggest just to remove last sentence from existing paragraph: SSL proxies can sometimes act as a man-in-the-middle for TLS clients. In these scenarios, the clients add a new trust anchor whose private key is kept on the SSL proxy; the proxy intercepts TLS requests, creates a new TLS session with the intended host, and sets up a TLS session with the client using a certificate that chains to the trust anchor installed in the client by the proxy. In such environments, the TLSA protocol will prevent the SSL proxy from functioning as expected because the TLS client will get a certificate association from the DNS that will not match the certificate that the SSL proxy uses with the client. The application that complies with this = document, seeing the proxy's new certificate for the supposed destination will = not set up a TLS session. Specifying a solution for SSL proxies is outside our WG. O. On 10. 2. 2012, at 22:56, Paul Hoffman wrote: > On Feb 10, 2012, at 12:51 PM, Bill Owens wrote: >=20 >> On Wed, Feb 8, 2012 at 12:24 PM, Paul Hoffman = wrote: >>> On Feb 8, 2012, at 8:00 AM, Peter Palfrader wrote: >>>=20 >>>> | 9. Security Considerations >>>> [ssl proxy mitm] >>>> | The client, seeing the proxy's new = certificate >>>> | for the supposed destination will not set up a TLS session. = Thus, >>>> | such proxies might choose to aggressively block TLSA requests = and/or >>>> | responses, even though this is not a recommended practice. >>>>=20 >>>> That last sentences doesn't make any sense. If the proxy blocks = TLSA >>>> requests then the dnssec status will be bogus, preventing TLS = entirely. >>>> (Now that I mention this, I realize this has already been pointed = out by >>>> Bill Owens recently.) >>>=20 >>>=20 >>> This is a substantiative issue, one that should be dealt with in WG = LC. >>=20 >> So, now that we're officially in WGLC, how should this be dealt with? >=20 > Yes, maybe even with an appropriate change to the subject line. :-) >=20 >> Or is it the case that only Peter and I care about this language, and >> everyone else is satisfied with the current statement? >=20 > Not the case: Jakob and I care as well. >=20 >> If the discussion would be helped by looking at alternative language, >> I would suggest something along these lines: >>=20 >> Proxies are sometimes configured to permit inspection of HTTPS >> sessions by acting as a man-in-the-middle between the TLS client and >> server. In this scenario, the client must first be configured with a >> new trust anchor whose private key is kept on the proxy. When the >> proxy receives an HTTPS request, it creates a new TLS session with = the >> server, and sets up another TLS session with the client using a >> self-signed certificate. Since that certificate chains to the trust >> anchor installed in the client, the HTTPS session acts normally from >> the user's perspective. However, a TLSA-aware client would get a >> certificate association from the DNS that does not match the >> self-signed certificate from the SSL proxy and would abort the TLS >> connection. Blocking TLSA queries or responses in order to mount a >> downgrade attack on the TLSA protocol would be detected by the DNSSEC >> validator as a failure of authenticated denial of existence and = result >> in the TLSA query being marked bogus, again leading the client to >> abort the TLS connection. Someone employing such a system might >> therefore choose to prevent the deployment of TLSA-aware clients. >> Developers who add TLSA capabilities to their clients might also >> choose to perform PKIX validation using locally-configured trust >> anchors first, and skip the TLSA process if the validation succeeds. >>=20 >>=20 >> The only part I'm concerned about is the assertion that the DNSSEC >> validation will come back bogus; I think that's true, and some simple >> tests in my sandbox environment seem to confirm it, but I'd like >> someone with more expertise to confirm it. . . >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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 nweaver@icsi.berkeley.edu Fri Feb 24 08:01:03 2012 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 3BA5721F87ED for ; Fri, 24 Feb 2012 08:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0mQZkWiY-XF for ; Fri, 24 Feb 2012 08:01:02 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3B021F87B0 for ; Fri, 24 Feb 2012 08:01:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 045832C4023; Fri, 24 Feb 2012 08:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iCgkUwSZPpKY; Fri, 24 Feb 2012 08:01:01 -0800 (PST) Received: from [10.0.1.7] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 954B02C4013; Fri, 24 Feb 2012 08:01:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Nicholas Weaver In-Reply-To: <8FD95E20-12A3-4C15-BC93-BD058A9917BD@nic.cz> Date: Fri, 24 Feb 2012 08:01:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4BD8AF40-40C3-416A-A3D1-1AB4A4D40C90@icsi.berkeley.edu> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <8FD95E20-12A3-4C15-BC93-BD058A9917BD@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 16:01:03 -0000 On Feb 24, 2012, at 7:52 AM, Ond=C5=99ej Sur=C3=BD wrote: > Does anybody else have anything to say? >=20 > I have one objection to the text suggested by Bill below. As we don't = specify how the DNSSEC validation will be done, we really don't know how = this will be implemented. >=20 > Thus I suggest just to remove last sentence from existing paragraph: >=20 > SSL proxies can sometimes act as a man-in-the-middle for TLS = clients. > In these scenarios, the clients add a new trust anchor whose private > key is kept on the SSL proxy; the proxy intercepts TLS requests, > creates a new TLS session with the intended host, and sets up a TLS > session with the client using a certificate that chains to the trust > anchor installed in the client by the proxy. In such environments, > the TLSA protocol will prevent the SSL proxy from functioning as > expected because the TLS client will get a certificate association > from the DNS that will not match the certificate that the SSL proxy > uses with the client. The application that complies with this = document, > seeing the proxy's new certificate for the supposed destination will = not > set up a TLS session. >=20 > Specifying a solution for SSL proxies is outside our WG. How about something like: "SSL proxies operate by requiring the client to contain an additional = root certificate belonging to the proxy. If such functionality is = desired for DANE-protected names, the network operator will also need to = create a DNSSEC proxy with its alternate root keys stored on the client. = Specifying such a configuration is outside the scope of this document." From ondrej.sury@nic.cz Fri Feb 24 08:03:35 2012 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 9916721F888C for ; Fri, 24 Feb 2012 08:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.763 X-Spam-Level: X-Spam-Status: No, score=-0.763 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E9JRfBCaYiR for ; Fri, 24 Feb 2012 08:03:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46721F8883 for ; Fri, 24 Feb 2012 08:03:35 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id 5B92A2A29BC for ; Fri, 24 Feb 2012 17:03:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330099414; bh=2Zjoav3jUEJNXrhqGFklKVowdWhvqZfgJcC5nIPav7I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=iMtCbwFofwhVaQBcaMXi6fSMjL0na34TaeCmRujCXodA/OV0UmN7LUUHIBNk6HgUh P172mRW3kOtAr6CWHxvSMdovMUPUSYh+0GhE5tr8A5MLLAAdPytxmfGfDsjhBnx04l r+agd0gGMafyAfZotVwz2QdYXq1SPWW95qwt0N7U= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F3D4A76.70706@os3.nl> Date: Fri, 24 Feb 2012 17:03:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Call on document name 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 Feb 2012 16:03:35 -0000 Hi WG, anybody else caring for name? We have these proposals: a) Using Secure DNS to Associate Certificates with Domain Names For TLS b) The DNS-Based Authentication of Named Entities (DANE) Protocol = Version 1.0 c) Transport Level Security Authentication (TLSA) using DNS Security d) The DNS-Based Authentication of Named Entities (DANE) for Transport = Layer Security (TLS) Protocol Please vote now. My preference would be: d>c>a O. -- 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 Fri Feb 24 08:06:52 2012 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 E106221F881A for ; Fri, 24 Feb 2012 08:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLYgPZQtbW5J for ; Fri, 24 Feb 2012 08:06:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 174F521F8807 for ; Fri, 24 Feb 2012 08:06:52 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id 5E5BA2A2F4B; Fri, 24 Feb 2012 17:06:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330099611; bh=CUJ0EjAVVTV7MZUzXdHsutSnaUtJ246mmkUouub1NBY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hLKtWEsomUrOszpLHcTR48/31UuW8JQY6TxdON/ukDT3x84jlK/UWbcJeIiqabeBv Qqdg1FZ5ZcNOssxAT+IKgMO5C9OUQuVbrDaNhlBR/0tVFMw9tHX2u0tjQxedX8lD4Z LBDQ8UZjXaWKNecqo/rMgYv6B484Aj3oo6ne5zrM= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 24 Feb 2012 17:06:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 16:06:53 -0000 On 21. 2. 2012, at 17:45, Paul Hoffman wrote: > On Feb 21, 2012, at 8:38 AM, Martin Rex wrote: >=20 >> Andrew Sullivan wrote: >>>=20 >>> On Thu, Feb 16, 2012 at 01:52:39PM -0800, Paul Hoffman wrote: >>>>> case, and probably not too important. I just wonder what the >>>>> connection initiator ought to do: re-query for TLSA, mark the = record >>>>> unusable and move on, throw an error? >>>>=20 >>>> Pick one so we can discuss it here. :-) >>>=20 >>> Ok, I'd say, "If the TTL expires during TLS negotiation, the side >>> initiating the connection MAY query for the TLSA record again, but >>> SHOULD NOT re-query more than [n, n{2..5}] times. If the TLSA RRset >>> cannot be used after multiple fetches, it should be marked as >>> unusable." >>=20 >> To me that sounds _much_ too complicated. The TTL on a DNS record >> is not a security feature anyway, so I do not see a justification to >> treat TTLs of TLSA records any different than TTLs on other DNS = records, >> so typically on *receipt* of the DNS record. If there is a local = cache >> for DNS records, that should work transparently -- either there is >> a record with a non-expired TTL available, then it is used, or >> there isn't then a new DNS query is necessary. Obtaining a DNS = record >> with an expired TTL from a local cache sounds like a bug in the >> implementation (or design) of that DNS cache. >=20 > +1 to Martin's analysis. +1 here. Any objections? If not I will ask authors to change the = document. O. -- 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 owens@nysernet.org Fri Feb 24 08:07:08 2012 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 47F0921F8835 for ; Fri, 24 Feb 2012 08:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK5dhE7uSuJr for ; Fri, 24 Feb 2012 08:07:07 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id C89C221F8807 for ; Fri, 24 Feb 2012 08:07:07 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id 004D8AE6AD3; Fri, 24 Feb 2012 11:06:51 -0500 (EST) Date: Fri, 24 Feb 2012 11:06:51 -0500 From: Bill Owens To: Nicholas Weaver Message-ID: <20120224160651.GD12512@nysernet.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <8FD95E20-12A3-4C15-BC93-BD058A9917BD@nic.cz> <4BD8AF40-40C3-416A-A3D1-1AB4A4D40C90@icsi.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4BD8AF40-40C3-416A-A3D1-1AB4A4D40C90@icsi.berkeley.edu> User-Agent: Mutt/1.4.2.3i Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:07:08 -0000 On Fri, Feb 24, 2012 at 08:01:02AM -0800, Nicholas Weaver wrote: > On Feb 24, 2012, at 7:52 AM, OndÅ™ej Surý wrote: > > > > Specifying a solution for SSL proxies is outside our WG. > > How about something like: > > "SSL proxies operate by requiring the client to contain an additional root certificate belonging to the proxy. If such functionality is desired for DANE-protected names, the network operator will also need to create a DNSSEC proxy with its alternate root keys stored on the client. Specifying such a configuration is outside the scope of this document." I prefer to stick with the narrow interpretation of 'security considerations'; things to consider when implementing and deploying the protocol. Not 'security recommendations' or 'security roadmaps', but 'if you implement DANE, this might happen'. Bill. From rbarnes@bbn.com Fri Feb 24 08:09:30 2012 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 61A6A21F8622 for ; Fri, 24 Feb 2012 08:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDSv6LJxzbyY for ; Fri, 24 Feb 2012 08:09:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 253B421F8621 for ; Fri, 24 Feb 2012 08:09:29 -0800 (PST) Received: from ros-dhcp192-1-51-17.bbn.com ([192.1.51.17]:57366) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S0xi3-000GGk-KW; Fri, 24 Feb 2012 11:09:27 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Fri, 24 Feb 2012 11:09:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <008E8B6C-05A9-4A5C-A6C9-A4FE5E079D60@bbn.com> References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> To: James Cloos X-Mailer: Apple Mail (2.1257) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 16:09:30 -0000 > PH> I think this is a request to get rid of usage type 2, or add a lot > PH> of technical requirements on its use. I'm OK with either of those > PH> actions, and would prefer to get rid of it to make the protocol = simpler. >=20 > -1 on removal. Just add a note that the TLS server SHOULD send the = cert > referenced by the type 2 TLSA RR just like it currently SHOULD (MUST?) > send intermediate certs. >=20 > Conceptually, the cert in question IS an intermediate cert; it is > just tied to DNS instead of to an OutOfBand x509 cert. >=20 > So wording it that way ought to be easy to comprehend and > implementations written based on that conceptualization should > Just Work=99. >=20 > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 +1 to what Jim says. --Richard From ondrej.sury@nic.cz Fri Feb 24 08:11:13 2012 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 0852321F8883 for ; Fri, 24 Feb 2012 08:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMfLETB8EbHF for ; Fri, 24 Feb 2012 08:11:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7C06621F8868 for ; Fri, 24 Feb 2012 08:11:05 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id 80DB92A2FE4; Fri, 24 Feb 2012 17:11:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330099862; bh=B1l1dL2vxCzQG2FfhDx1vSUZYyNoBtq5EEmWbAHo0Z8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qR1lBZQRWvoLMQCXnCWmHDPJtVeowNOHs41KzvKQYyiCiTg6DkN9lgiOWo4x5LMXn AwYkd5JNEM7UKiihRjkTeH5jEckbM5ZkSMymDAeUyIJnPWdoERZGCyvr6bQclBAM1c YhzVhn7NyVRqtor4v6G2ytYBz3DKYUZxiAaIoUdE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 24 Feb 2012 17:11:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <64FD7BDD-1E55-4A81-AA4F-36487424003D@nic.cz> References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> <20120217040314.GA31408@mail.yitter.info> To: James Cloos X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 16:11:14 -0000 On 17. 2. 2012, at 21:58, James Cloos wrote: > AS> None of that is to say that, "Yep. Suck it up," is the wrong = answer. > AS> It's rather to say that, if that's our answer, we need to point it = out > AS> explicitly, because it seems to me like an important deployability > AS> issue. If the idea of IETF standards is interoperability, this is = a > AS> place where two strategies fail to interoperate. >=20 > If explicitly noting that will help implementers then by all means. >=20 > I'm sure Paul and Jakob would prefer some suggested prose. I really like this suggestion :). It seems it would help to have some = simple text about what happens if you screw up TLSA deployment in = Operational Considerations (Appendix A), but somebody has to write it. = Any volunteer? O. -- 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 rbarnes@bbn.com Fri Feb 24 08:12:02 2012 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 BCE1421F8880 for ; Fri, 24 Feb 2012 08:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.194 X-Spam-Level: X-Spam-Status: No, score=-106.194 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE5mUhnbhe5h for ; Fri, 24 Feb 2012 08:11:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5115B21F8868 for ; Fri, 24 Feb 2012 08:11:57 -0800 (PST) Received: from ros-dhcp192-1-51-17.bbn.com ([192.1.51.17]:57367) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S0xk7-000F4Z-V8; Fri, 24 Feb 2012 11:11:35 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> Date: Fri, 24 Feb 2012 11:11:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <099FCD8E-1233-4F7C-A78B-38324AB32409@bbn.com> References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Call on document name 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 Feb 2012 16:12:02 -0000 > a) Using Secure DNS to Associate Certificates with Domain Names For = TLS >=20 > b) The DNS-Based Authentication of Named Entities (DANE) Protocol = Version 1.0 >=20 > c) Transport Level Security Authentication (TLSA) using DNS Security >=20 > d) The DNS-Based Authentication of Named Entities (DANE) for Transport = Layer Security (TLS) Protocol >=20 > Please vote now. >=20 > My preference would be: > d>c>a I would like my bike shed to be=85 b > c > d > a (Only, remove the "The" and "Protocol Version 1.0" from b)= From pieter.lexis@os3.nl Fri Feb 24 08:14:13 2012 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 776C821F86AA for ; Fri, 24 Feb 2012 08:14:12 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LvU2HrJdtWw for ; Fri, 24 Feb 2012 08:14:07 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id C5E8721F8673 for ; Fri, 24 Feb 2012 08:14:06 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 78DEF17AA3D for ; Fri, 24 Feb 2012 17:14:05 +0100 (CET) Received: from [IPv6:2001:4cb8:12:2:222:fbff:fec9:1314] (unknown [IPv6:2001:4cb8:12:2:222:fbff:fec9:1314]) by smtp.os3.nl (Postfix) with ESMTPSA id 4E4CF17AA28 for ; Fri, 24 Feb 2012 17:14:05 +0100 (CET) Message-ID: <4F47B74C.7000301@os3.nl> Date: Fri, 24 Feb 2012 17:14:04 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <20120215134018.GA3119@nysernet.org> <2ECA4310-CE0D-4032-BCA3-BBC74B3CF1F3@vpnc.org> <201202160831.q1G8V7WD021593@new.toad.com> <94C60C91-E90B-4BB4-9551-F80C608C8932@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Getting rid of usage type 2 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 Feb 2012 16:14:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/16/2012 11:08 PM, James Cloos wrote: > -1 on removal. Just add a note that the TLS server SHOULD send the > cert referenced by the type 2 TLSA RR just like it currently SHOULD > (MUST?) send intermediate certs. > > Conceptually, the cert in question IS an intermediate cert; it is > just tied to DNS instead of to an OutOfBand x509 cert. > > So wording it that way ought to be easy to comprehend and > implementations written based on that conceptualization should Just > Workâ„¢. +1 on JC's comment (so -1 on removal) - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPR7dCAAoJELPqGO5ebd4j51sQALNe5pYH+CLMLOMF6sXylGzG QLLwZILF+izXKrjb2O6lLCxZdH+qH6SRwaMZDXgwj/1wnE2XGPoav9PYwvEADCYr jLf/4fpf9T2M3+yoietC6U0fZ0+riQ6O0glbIp12oqROsDFqj+GEv1AgLhJoXjkA 5lqF7YK4OlyalBdCxL8W6Y6OIEAolRyzA3aFaXriSvAn1Z0KzEbpRBjBA6PMmgPL U297s3LnAJxA6Fvs/76a2Rl185F/IEkkZxDMi0+CW+OgpI0daxOBvGffjyZAdOO9 EW96NF6WgYWsysukSvpWlldpW/kSF4iR3w17LIheBKSfnS+FMPMRSwEVXMUG0TPe exmzc62D1U0iEYwmbe4q6Tz5mM85lJ/DT0Ep9wc0enAwkmuFeALOvl4cSf+KIaSL YPKRInIeKyhSDzu0Qu7XTwIvqoZ/58DhC2MTr5dCXXm9tgTKhhHLcBKmmxf1JhQ9 QSYJYqsHzpUqhd0Hc1GHi8HKW6iihumu5h7R2JcPl7fDpF/SExJtIrPlzMbVK4bS 1opHxH0AGFBd/qmH699HNNo+6iunUGJvRyYwin4Mi2k7F8Ztg+1Friz0kU/dDnuZ KC1Xlv/1CPZazuY9FGe0YnFHhg6WolanTxyKcqQERMdAKCOrTIXW+wXdnRnrXyTK K30xd6XEGVjB2f2rjE7N =0H7M -----END PGP SIGNATURE----- From ondrej.sury@nic.cz Fri Feb 24 08:15:57 2012 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 C877B21F8798 for ; Fri, 24 Feb 2012 08:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.524 X-Spam-Level: X-Spam-Status: No, score=-1.524 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvYHGYSxCaNc for ; Fri, 24 Feb 2012 08:15:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C851221F86D7 for ; Fri, 24 Feb 2012 08:15:51 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 9777B2A2F4B; Fri, 24 Feb 2012 17:15:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330100150; bh=ZutNOOrRLX4OTvItSnKZ7uyO1HfxKTG8d+gl57KX/Q0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jAWCItmnnMWY/ycAk5Y5G1CXm4G8QRS4DGm3J76EAs2Tkh7qgPTH7CM5DXlIbvfeS D2CYr7cWbiMpQKAZu3g33eKKZH+uMnSVUUYv3xZ8CuVJ+CWbTYHKs7WUHAS+y4BUyg Lllbk7PReFo2JoBpGUnNJz/wnVYGeln8kekOHe7A= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201202132324.q1DNOVWD009987@new.toad.com> Date: Fri, 24 Feb 2012 17:15:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1CAC3C79-4255-48B3-BAC1-8AC32EFE4761@nic.cz> References: <201202132324.q1DNOVWD009987@new.toad.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Wouters Subject: [dane] Clarify the text in section 2.1.4. 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 Feb 2012 16:15:57 -0000 Hi WG and early implementors, anybody of you willing to work on text to clarify 2.1.4? I am Ccing = people with know implementation, so you can: a) provide the text, since you have the experience b) cross-check the text Please at least one of you, say yes. Thanks. On 14. 2. 2012, at 0:24, John Gilmore wrote: > According to https://www.ietf.org/id-info/checklist.html section 4.3: >=20 > If any sort of end-to-end checksum or integrity check is being used > (especially, but not limited to, cryptographic checksums or MACs), > specify precisely the contents of the fields to be checksummed, and > exactly what order the operations are done in. Pay special attention > to any area reserved for the checksum itself. >=20 > Therefore, I think we should clarify the text in section 2.1.4. =20 O. -- 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 pieter.lexis@os3.nl Fri Feb 24 08:16:37 2012 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 8A31E21F8798 for ; Fri, 24 Feb 2012 08:16:37 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qubC8MOpwkeZ for ; Fri, 24 Feb 2012 08:16:36 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id E460321F86D7 for ; Fri, 24 Feb 2012 08:16:35 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 5460617AA3D for ; Fri, 24 Feb 2012 17:16:35 +0100 (CET) Received: from [IPv6:2001:4cb8:12:2:222:fbff:fec9:1314] (unknown [IPv6:2001:4cb8:12:2:222:fbff:fec9:1314]) by smtp.os3.nl (Postfix) with ESMTPSA id 2B54E17AA28 for ; Fri, 24 Feb 2012 17:16:35 +0100 (CET) Message-ID: <4F47B7E2.5060200@os3.nl> Date: Fri, 24 Feb 2012 17:16:34 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> In-Reply-To: <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Call on document name 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 Feb 2012 16:16:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/24/2012 05:03 PM, OndÅ™ej Surý wrote: > We have these proposals: > > a) Using Secure DNS to Associate Certificates with Domain Names For > TLS > > b) The DNS-Based Authentication of Named Entities (DANE) Protocol > Version 1.0 > > c) Transport Level Security Authentication (TLSA) using DNS > Security > > d) The DNS-Based Authentication of Named Entities (DANE) for > Transport Layer Security (TLS) Protocol > > Please vote now. d > c > b > a But d written as: 'The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)', to associate the word protocol with DANE and not with TLS. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPR7fiAAoJELPqGO5ebd4j4NIP/15hZQQFS09jRNMptHSHuWyC 9Lcw1xvWHwwpk6zptDIaWEyZywJj/dWYbRUWxS63NGTxvax4U7UcyqNk3quC+OwN uIweHPiyunyoI3BvBEkKGmZqKjUEeLC+CwObKhnNkU8piT0/tu1uYp7sUMHaY/co r9oIovHWLwDxnvD++5IGGQlSTKMdZ2bR8HrYWU4+nng//+EWNFD7vAD1NTUeQ5D7 Np715j39DUVSgu5LPVAVmreLc6QhQueiiS/Hy8ApTqkYJIVFmx4QPEUzue9g0bZf xCD86E14i5I2MmBlvT3KUXQKLWBgTHgX5UYopemBYVrtVpfYrLJkj8+0dA1A8EzB YEjbv/4PmK2pJtMojxuAJN8Pv7jr0NT3uEWrV3+QiPDwEwPYKthHJy1UVCrijl4r xYHqDJZ/nMfJsTOL1WH7JYVswJKsamtXH7AgCPwzFg4CrpgqfcYohM7Nx/jzEvVD bwqnTjgPGwypCoeRkJm2FEOTAb8QtpewxLjJP68yMIqttCnOSm2JnR+akxH4YtN+ E5sypGu1wrn/UTXDZ5OnZ1CvGhI+0eufB59Bc7rtzm41k8ZorfXp8wBZwNjbnvEX u8tbH8DJ+akL06hD6BN7G8Wkh2gSw1caVxVNIneAf5IniVtOSlJBuJsTwOobem/Q wNC66l/OmO0li9yA4j4i =etl2 -----END PGP SIGNATURE----- From ondrej.sury@nic.cz Fri Feb 24 08:18:08 2012 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 6993921F8810 for ; Fri, 24 Feb 2012 08:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02m+P9FV8ohc for ; Fri, 24 Feb 2012 08:18:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D3A1621F8798 for ; Fri, 24 Feb 2012 08:18:07 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 0A82E2A2CF1; Fri, 24 Feb 2012 17:18:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330100287; bh=lpauYfScaIGzf5Pyk0+F7QhCAFA3hItkOHNGaGHCXsE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p5CEEsSJX/auWnC7j1J+bV4qpenQTwCwU8ctr1qewbJ7rY6NrPbt18YFxOjyCgrrS E/acaiYuCD961SxDLxpA3uwlKtHtYLWXVrFrh7UC6GEBMzuFgHw76EABRz1B7I7+tb uFNfpJMSq43nm7pmjixVFvrJ1g/Xhhy3TtQefzFw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> Date: Fri, 24 Feb 2012 17:18:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> References: <201202132324.q1DNOVWD009987@new.toad.com> <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> To: Pieter Lexis , Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 16:18:08 -0000 Pieter, On 14. 2. 2012, at 0:36, Pieter Lexis wrote: > WG and John, >=20 > When making swede I used a selfsigned cert (and a cert signed by = comodo using the same csr) to create a test bed. I'd be happy to supply = the WG with the certificates, keys and other material to include a = (partial) test vector. That would be great. Paul, I share your concern, but I see a value in providing examples. If = we can carefully and independently check provided examples, then I think = we don't have to worry too much. O. -- 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 owens@nysernet.org Fri Feb 24 08:28:32 2012 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 07D4021F8882 for ; Fri, 24 Feb 2012 08:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTwAVbdNx+Q3 for ; Fri, 24 Feb 2012 08:28:31 -0800 (PST) Received: from cookiemonster.nysernet.org (cookiemonster.nysernet.org [IPv6:2620:f:1:1201:21b:63ff:fea4:4d92]) by ietfa.amsl.com (Postfix) with ESMTP id 320D021F8888 for ; Fri, 24 Feb 2012 08:28:31 -0800 (PST) Received: by cookiemonster.nysernet.org (Postfix, from userid 501) id 31883AE6E04; Fri, 24 Feb 2012 11:28:30 -0500 (EST) Date: Fri, 24 Feb 2012 11:28:29 -0500 From: Bill Owens To: Pieter Lexis Message-ID: <20120224162829.GF12512@nysernet.org> References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> <4F47B7E2.5060200@os3.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F47B7E2.5060200@os3.nl> User-Agent: Mutt/1.4.2.3i Cc: dane@ietf.org Subject: Re: [dane] Call on document name X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: owens@nysernet.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:28:32 -0000 On Fri, Feb 24, 2012 at 05:16:34PM +0100, Pieter Lexis wrote: > On 02/24/2012 05:03 PM, OndÅ™ej Surý wrote: > > We have these proposals: > > > > a) Using Secure DNS to Associate Certificates with Domain Names For > > TLS > > > > b) The DNS-Based Authentication of Named Entities (DANE) Protocol > > Version 1.0 > > > > c) Transport Level Security Authentication (TLSA) using DNS > > Security > > > > d) The DNS-Based Authentication of Named Entities (DANE) for > > Transport Layer Security (TLS) Protocol > > > > Please vote now. > > d > c > b > a > > But d written as: 'The DNS-Based Authentication of Named Entities > (DANE) Protocol for Transport Layer Security (TLS)', to associate the > word protocol with DANE and not with TLS. Even though I originally proposed b, I prefer Pieter's wording of d (since it was pointed out that there will be DANE for other purposes as well). Bill. From ajs@anvilwalrusden.com Fri Feb 24 08:42:53 2012 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 7992C21F881B for ; Fri, 24 Feb 2012 08:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7GNFL3lnSw1 for ; Fri, 24 Feb 2012 08:42:52 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5B821F8813 for ; Fri, 24 Feb 2012 08:42:52 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 83E2D1ECB41D for ; Fri, 24 Feb 2012 16:42:51 +0000 (UTC) Date: Fri, 24 Feb 2012 11:42:53 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120224164251.GH48576@mail.yitter.info> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 16:42:53 -0000 On Fri, Feb 24, 2012 at 05:06:51PM +0100, OndÅ™ej Surý wrote: > > > +1 here. Any objections? If not I will ask authors to change the document. > That depends on how the document is being changed. This issue has also been picked upon dnsext. My original point stands: the text says that the processing must happen before the end of the TTL. As others have noted, this is a mistake in more than one dimension: the TTL isn't the important qualified (because the lifetime of the RRSIG is actually the relevant bit), and the question should merely be whether you got data from the cache (if you get data from the cache with a negative TTL on it, then the cache is already broken and you shouldn't have received such data anyway; the draft is not in the business of warning about DNS problems nobody has ever reported in the wild, so that can't be the point of the text). So, _if_ the WG thinks there needs to be anything about what to do with data retrieved from a cache (and I was just assuming it did because the text seems kind of odd; I didn't raise this in the review and perhaps I should have instead), then we need to say something about what to do in case the TTL ticks down in that interval. But I'm in agreement with Mark, Ed Lewis, and implicitly I think Martin that the right thing to do is to remove any discussion of whether to worry about the TTL at all during TLS set up. It's a category mistake. On a related topic: I don't think the document should say anything about the TLS setup and the RRSIG expiration time, either. I think the question is merely, "When I got this record, was it valid?" How to do that is already covered by DNSSEC and if there are corner cases about RRSIG expiry, this document isn't the place to fix them. A -- Andrew Sullivan ajs@anvilwalrusden.com From pieter.lexis@os3.nl Fri Feb 24 08:53:35 2012 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 8D17721F87FF for ; Fri, 24 Feb 2012 08:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgTr6Eil9Mc5 for ; Fri, 24 Feb 2012 08:53:33 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7521F87E4 for ; Fri, 24 Feb 2012 08:53:33 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id E160E17AA5D; Fri, 24 Feb 2012 17:53:32 +0100 (CET) Received: from [IPv6:2001:4cb8:12:2:222:fbff:fec9:1314] (unknown [IPv6:2001:4cb8:12:2:222:fbff:fec9:1314]) by smtp.os3.nl (Postfix) with ESMTPSA id B00AB17AA3D; Fri, 24 Feb 2012 17:53:32 +0100 (CET) Message-ID: <4F47C08B.2070806@os3.nl> Date: Fri, 24 Feb 2012 17:53:31 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <201202132324.q1DNOVWD009987@new.toad.com> <1CAC3C79-4255-48B3-BAC1-8AC32EFE4761@nic.cz> In-Reply-To: <1CAC3C79-4255-48B3-BAC1-8AC32EFE4761@nic.cz> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IETF DANE WG list Subject: Re: [dane] Clarify the text in section 2.1.4. 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 Feb 2012 16:53:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi OndÅ™ej, On 02/24/2012 05:15 PM, OndÅ™ej Surý wrote: > Hi WG and early implementors, > > anybody of you willing to work on text to clarify 2.1.4? I am > Ccing people with know implementation, so you can: > > a) provide the text, since you have the experience Not sure how this should be written, should it be pseudo-code or text? A small try: The data in this field is created as follows: o Based the on the selector, use either the full certificate or the SubjectPublicKeyInfo from the certificate for the next step. o Retrieve the DER representation for the data from the previous step. o If the matching type states the use of a hashing algorithm, hash the result of the previous step using that algorithm. o The resulting bytes are the data for this field. Pseudocode (loosly typed and ugly, but I do python ;-)): Data = Certificate_for_association if (selector == 1) { Data = get_SubjectPublicKeyInfo(Data) } Data = as_DER(Data) if (matching_type != 0) { Data = Hash(Data) } // Data now contains the association data. I hope this gives the WG a start to work with. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPR8CIAAoJELPqGO5ebd4jKtUP/ipVqbZQCOyFewwthc/Io7j1 xdsJer1wO/KGYrwW0LOcZxY+1AiZVVMsny09yD7np3zUgDrgxoVijiFtl4XPvYDJ Xf8QOxMWFpmaJivTDOKydtRhlk7P1s2O3EKarWkmc6WPfh9P2hGFa6s0OJF74sD+ W3dyljGVozkBzkslgOqVM0MAd3ci+EG98eaWwaP2WrHRO/qtj1pJJhyLaV550Uh8 ZBemAvbePsT79uDUL+WjwPrmXrPAIGlI7rsoxq62PRTdMKh8xe+iLlePx7YMEz2J zYXC+bIaAOu0mEQoAkGeeUEX7wlq1MJweqLEPDUE4kcfvVf/49+6bkYaWLr0lEI2 7tcWn31/7Ty9ifHgdOyrBKA/rICF+Yep5N5MOwiWw2EFqvDaJggeZ/xBEk76+TNW BFd914+KczTurThu9C8XKHHBPx84o0ZW1eSTSy2UhXvzq5nPNDV7myaYR38RxacV s4Nj8OE/89/GSPeGORzmzZHB1bSKWhfwHKpynUheW3wy+o8O0NMC4+lRflJTlQMl eV+aWzFYAquOafz/ObQ2TU7mGuDk/fcpy4tkjLiYv3dEARLObGyJrz2APNddF5nC iUx4cGT5s5bzvEiDW4mvjf5rmTtxd/wOctqfQQDgyZZyZP7NXTpr2M0aARAwgFVg vyOPihnKkQPB9hyMHn8B =eUdt -----END PGP SIGNATURE----- From tom@ritter.vg Fri Feb 24 08:55:17 2012 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 7726821F867B for ; Fri, 24 Feb 2012 08:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtgVXUBZTeOv for ; Fri, 24 Feb 2012 08:55:16 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 284B921F8667 for ; Fri, 24 Feb 2012 08:55:15 -0800 (PST) Received: by lahl5 with SMTP id l5so3562732lah.31 for ; Fri, 24 Feb 2012 08:55:15 -0800 (PST) Received-SPF: pass (google.com: domain of tom@ritter.vg designates 10.112.40.101 as permitted sender) client-ip=10.112.40.101; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom@ritter.vg designates 10.112.40.101 as permitted sender) smtp.mail=tom@ritter.vg; dkim=pass header.i=tom@ritter.vg Received: from mr.google.com ([10.112.40.101]) by 10.112.40.101 with SMTP id w5mr1220081lbk.97.1330102515208 (num_hops = 1); Fri, 24 Feb 2012 08:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=4/s7fExrANY7IgDnQv+JT9yAQgmI0yki2diAKi4rGS0=; b=Yi4W75bG3sqWFGWOyip5bUBtR+LAVzmvE47UchN41jqLK9skpTGqMZYYMVuY15tXZq U2Y+37j852c2Hh9eyIXZfaT3P9CimwqmSgsJEm2YmqcaYSdWlV9njD4auslZAdUmFqD2 IsQ/ZwQpGbkRkuZu7sqpopVdsNeV7B+slXnjA= Received: by 10.112.40.101 with SMTP id w5mr1007105lbk.97.1330102515135; Fri, 24 Feb 2012 08:55:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.4 with HTTP; Fri, 24 Feb 2012 08:54:55 -0800 (PST) In-Reply-To: <20120224160651.GD12512@nysernet.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <9A3B6D9E-70C2-4E0A-A8D5-E9CEBC00C52A@vpnc.org> <20120208160003.GA17629@anguilla.noreply.org> <81EEEFD4-7D53-428B-9D41-3957EF9AD929@vpnc.org> <8FD95E20-12A3-4C15-BC93-BD058A9917BD@nic.cz> <4BD8AF40-40C3-416A-A3D1-1AB4A4D40C90@icsi.berkeley.edu> <20120224160651.GD12512@nysernet.org> From: Tom Ritter Date: Fri, 24 Feb 2012 11:54:55 -0500 Message-ID: To: owens@nysernet.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm120Q6PhOT+s3bcNUwUwBL1AW1Oz+ZZH5MTVGjoGIR91wb/PDL3rFo5Xh5TdlVLR0FOpHF Cc: IETF DANE WG list Subject: Re: [dane] Security considerations for proxies 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 Feb 2012 16:55:17 -0000 On 24 February 2012 11:06, Bill Owens wrote: > I prefer to stick with the narrow interpretation of 'security considerati= ons'; things to consider when implementing and deploying the protocol. Not = 'security recommendations' or 'security roadmaps', but 'if you implement DA= NE, this might happen'. +1 On 24 February 2012 10:52, Ond=C5=99ej Sur=C3=BD wrote= : > I have one objection to the text suggested by Bill below. =C2=A0As we don= 't specify how the DNSSEC validation will be done, we really don't know how= this will be implemented. > > Thus I suggest just to remove last sentence from existing paragraph +1 -tom From ondrej.sury@nic.cz Fri Feb 24 09:04:07 2012 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 CBFD321F8860 for ; Fri, 24 Feb 2012 09:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgV6ZDqpg--3 for ; Fri, 24 Feb 2012 09:04:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F059121F885A for ; Fri, 24 Feb 2012 09:04:06 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82] (unknown [IPv6:2001:1488:ac14:1400:8567:f33b:7ccd:8c82]) by mail.nic.cz (Postfix) with ESMTPSA id 429702A2F57; Fri, 24 Feb 2012 18:04:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330103046; bh=1qXHG4FOMwI1CWUwGsmq99YZ3u8iQVa1FG3MFJWWGkE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PPpHX5iTm3uwGxQBLQ27ZMrv0qmHsZF6tV7BsWwUpIMYq8xjSYBqYCbU/bi8iQqgI 7lMvWsLwcZ/1CM54kpr6ajyBMBQNjUiQcwXzDgv0g+RuSHwbY22sMxMBQZyJU89+3V fIpxOQvIy7DbO9SlumrIwbQECIE9vpT3Kv/Tr4dc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120224164251.GH48576@mail.yitter.info> Date: Fri, 24 Feb 2012 18:04:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 17:04:07 -0000 On 24. 2. 2012, at 17:42, Andrew Sullivan wrote: > On Fri, Feb 24, 2012 at 05:06:51PM +0100, Ond=C5=99ej Sur=C3=BD wrote: >>=20 >>=20 >> +1 here. Any objections? If not I will ask authors to change the = document. >>=20 >=20 > That depends on how the document is being changed. This issue has > also been picked upon dnsext. I propose to change: The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query. The matching or chaining MUST be done within the life of the TTL on the TLSA record; using a TLSA record past the lifetime specified in the TTL can expose the the TLS client to many types of attacks. to something like: The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query. TLSA record MUST NOT be cached and a new TLSA query must be made for each new TLS session. > On a related topic: I don't think the document should say anything > about the TLS setup and the RRSIG expiration time, either. I think > the question is merely, "When I got this record, was it valid?" How > to do that is already covered by DNSSEC and if there are corner cases > about RRSIG expiry, this document isn't the place to fix them. We don't say anything about RRSIGs, do we? O. -- 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 ajs@anvilwalrusden.com Fri Feb 24 09:28:28 2012 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 58FDC21F87E4 for ; Fri, 24 Feb 2012 09:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuaKwqGiPbpq for ; Fri, 24 Feb 2012 09:28:27 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BE62021F87CC for ; Fri, 24 Feb 2012 09:28:27 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C6A1C1ECB41D for ; Fri, 24 Feb 2012 17:28:26 +0000 (UTC) Date: Fri, 24 Feb 2012 12:28:28 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120224172827.GK48576@mail.yitter.info> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 17:28:28 -0000 On Fri, Feb 24, 2012 at 06:04:06PM +0100, OndÅ™ej Surý wrote: > to something like: > > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. TLSA > record MUST NOT be cached and a new TLSA query must be made for each > new TLS session. That is not going to fly. You're saying that TLSA is not allowed to be cached. That makes it completely unlike every single other RRTYPE in the DNS universe. Why is the TTL stuff in there at all? The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query. That's all we need to say. You get a record inside the TTL of a record, and you should _never_ get DNS data past its TTL, by definition. (If you do, your DNS cache is broken, and that's just out of scope for this I-D.) The special handling seemed to be promoting the TTL into some sort of security service, in which whether a record returned from the DNS is not the only question. In other words, as things stand the document is suggesting that the TTL is not only a control on cache behaviour, but a control on _application_ behaviour. The more I think about it, the more I think that's wrong. > > On a related topic: I don't think the document should say anything > > about the TLS setup and the RRSIG expiration time, either. I think > > the question is merely, "When I got this record, was it valid?" How > > to do that is already covered by DNSSEC and if there are corner cases > > about RRSIG expiry, this document isn't the place to fix them. > > > We don't say anything about RRSIGs, do we? Nope. But that's my point; if we have to talk about the TTL as somehow constraining the application behaviour, then we also have to talk about the RRSIG lifetime constraining application behaviour. And now you're into the same set of problems as DNS generally has about the link between the TTL and the expiry time on RRSIGs. A -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Fri Feb 24 10:29:20 2012 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 9BC5521F846B for ; Fri, 24 Feb 2012 10:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yoPa-WGCFqc for ; Fri, 24 Feb 2012 10:29:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0A14921F8836 for ; Fri, 24 Feb 2012 10:29:06 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 185702A03FC; Fri, 24 Feb 2012 19:29:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330108145; bh=ZuQOF/t+tVE1pdqywLP2aKPDoVNTXVcr7/nwiz+oGGs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QnxjtEFWDcLBJVKhXBekiLPgx4zZpRwdVITsndY8chlUl8iiaWpJNOqa+mUSzl6n3 1Si6YETU+Q7ZYn8GkMEPo0V0T/KGYm+eJu97/gLNkMKOk/NdvMfg/enaIFrtqKJtYC y+utejJ89dbeNwwQR9W9LW4/yoZbed7srTj+/NwU= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120224172827.GK48576@mail.yitter.info> Date: Fri, 24 Feb 2012 19:29:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 18:29:20 -0000 On 24. 2. 2012, at 18:28, Andrew Sullivan wrote: > On Fri, Feb 24, 2012 at 06:04:06PM +0100, Ond=C5=99ej Sur=C3=BD wrote: >> to something like: >>=20 >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. TLSA >> record MUST NOT be cached and a new TLSA query must be made for = each >> new TLS session. >=20 > That is not going to fly. You're saying that TLSA is not allowed to > be cached. That makes it completely unlike every single other RRTYPE > in the DNS universe. Are we talking about the same cache? Maybe not. I was trying to say = that TLSA record MUST NOT be cached in the _application_. Would it help to change s/cached/reused/ >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. TLSA >> record MUST NOT be reused and a new TLSA query must be made for = each >> new TLS session. -- 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 ajs@anvilwalrusden.com Fri Feb 24 10:51:29 2012 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 DA69E21F8794 for ; Fri, 24 Feb 2012 10:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4QFoI4UF2EL for ; Fri, 24 Feb 2012 10:51:29 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 54ECB21F875E for ; Fri, 24 Feb 2012 10:51:29 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 894171ECB41D for ; Fri, 24 Feb 2012 18:51:28 +0000 (UTC) Date: Fri, 24 Feb 2012 13:51:26 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120224185126.GQ48576@mail.yitter.info> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 18:51:30 -0000 On Fri, Feb 24, 2012 at 07:29:04PM +0100, OndÅ™ej Surý wrote: > > Are we talking about the same cache? Maybe not. I was trying to say that TLSA record MUST NOT be cached in the _application_. > Apparently not, and yes that solves the issue for me. A -- Andrew Sullivan ajs@anvilwalrusden.com From ondrej.sury@nic.cz Fri Feb 24 11:12:14 2012 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 C000621F8755 for ; Fri, 24 Feb 2012 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TeoODK6T-ve for ; Fri, 24 Feb 2012 11:12:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 52B0E21F8798 for ; Fri, 24 Feb 2012 11:11:47 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 9FC9D2A2FC7 for ; Fri, 24 Feb 2012 20:11:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330110705; bh=rfNUysBlX1daGaA106mG9U6QX0U+YQukihPT4iY2a9k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=dopue1+LqCRySxz+mVAzm+phtU/wSaJugWQD+uQ71VQyICuEtlHFQSFfeYBURJ09X Qt+Es4pSn902BSRxcadnFlfCIOS7Hz8KwhHic1ySI1Xj2vROPCjEP8/JMaltXiQBvd xamKt8dYhWhmucOiRQURHWhKixuTKBRT+elKnwHY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120224185126.GQ48576@mail.yitter.info> Date: Fri, 24 Feb 2012 20:11:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D76AB64-BC5A-4651-A9D3-8DB851B52A80@nic.cz> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224185126.GQ48576@mail.yitter.info> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 19:12:14 -0000 On 24. 2. 2012, at 19:51, Andrew Sullivan wrote: > On Fri, Feb 24, 2012 at 07:29:04PM +0100, Ond=C5=99ej Sur=C3=BD wrote: >>=20 >> Are we talking about the same cache? Maybe not. I was trying to say = that TLSA record MUST NOT be cached in the _application_. >>=20 >=20 > Apparently not, and yes that solves the issue for me. Cool. Ok, anybody objects to changing second paragraph of Section 5 to (just = changed second must to MUST): >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. TLSA >> record MUST NOT be reused and a new TLSA query MUST be made for each >> new TLS session. We have +1 from me, Andrew Sullivan, and in the spirit of what Martin = Rex wrote from Paul Hoffman and Martin Rex. Am I right? O. -- 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 Fri Feb 24 12:02:45 2012 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 97A8521F87FF for ; Fri, 24 Feb 2012 12:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZn0DMyO50uE for ; Fri, 24 Feb 2012 12:02:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5B70D21F8813 for ; Fri, 24 Feb 2012 12:02:43 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 99CB02A0BB3 for ; Fri, 24 Feb 2012 21:02:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330113762; bh=N7ZjkctaMU25pxU8UDkT26BFNxE8YM0hbP80fkMNnVE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=GQty8x4k8Hb3uMmGZoHiYzVWzc3BvwqvDzAMC+wLJmnolNvpllWoDYeYKolq96dOW l/QAemFTwj0KEFukdaiFMBpzLJUm5mWP9fENovY2JTbVuzL8lUP9/RqspzWxiNGlDu ndr1sJzqNFy8tBvZwiSUtTIylMa3GNhTQ6iBSTwM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 24 Feb 2012 21:02:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Call on PKIX validation -> PKIX certification path validation 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 Feb 2012 20:02:45 -0000 On 24. 2. 2012, at 15:50, Paul Hoffman wrote: > Yes, that is more precise. I have changed "validation chain" to = "certification path", and "path validation" to "certificate path = validation", throughout the Really minor nit: it's "certification path validation", but as you have = it correctly below I assume it's just a typo here (it's very easy to = slip, I did have to correct myself too). > document (including in the pseudocode). The main place affected is = shown here; let Jakob and I know if there are more changes to be made. 2.1.1 will be merged to 4, so just make sure you don't forget to update = it there when merging the text. Section 9) Security considerations might be updated to the RFC 5280 = terminology as well since it's part of the standard. I think it would be better to update Appendices A and B too to be = aligned with the protocol documentation. Would I would suggest is to search for word 'chain' and replace it with = correct terminology. If you send me current working draft, I can help = and send you back the patch. > 0 -- Certificate usage 0 is used to specify a CA certificate, or > the public key of such a certificate, that must be found in any = of > the PKIX certification paths for the end entity certificate given > by the server in TLS. This usage is sometimes referred to as "CA > constraint" because it limits which CA can be used to issue > certificates for a given host name, port, and protocol. The > target certificate MUST pass PKIX certification path validation > and a CA certificate that matches the TLSA record MUST be = included > as part of a valid certification path. >=20 > 1 -- Certificate usage 1 is used to specify an end entity > certificate, or the public key of such a certificate, that must = be > matched with the end entity certificate given by the server in > TLS. This usage is sometimes referred to as "service certificate > constraints" because it limits which end entity certificate may = be > used by a given host name, port, and protocol. The target > certificate MUST pass PKIX certification path validation and MUST > match the TLSA record. >=20 > 2 -- Certificate usage 2 is used to specify a certificate, or the > public key of such a certificate, that must be used as a trust > anchor when validating the end entity certificate given by the > server in TLS. This usage is sometimes referred to as "trust > anchor assertion" and allows a domain name administrator to > specify a new trust anchor, for example if the domain issues its > own certificates under its own CA that is not expected to be in > the end users' collection of trust anchors. The target > certificate MUST pass PKIX certification path validation, with = any > certificate matching the TLSA record considered to be a trust > anchor for this certification path validation. >=20 > 3 -- Certificate usage 3 is used to specify a certificate, or the > public key of such a certificate, that must match the end entity > certificate given by the server in TLS. This usage is sometimes > referred to as "domain-issued certificate" because it allows for = a > domain name administrator to issue certificates for a domain > without involving a third-party CA. The target certificate MUST > match the TLSA record. LGTM, thank you very much. And +1 from me to. O. -- 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 Fri Feb 24 12:07:10 2012 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 6368021F879C for ; Fri, 24 Feb 2012 12:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cywiizes7Klm for ; Fri, 24 Feb 2012 12:07:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B218121F8795 for ; Fri, 24 Feb 2012 12:07:09 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id C0D342A2E6A; Fri, 24 Feb 2012 21:07:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330114029; bh=T23ijDlp/N2n3tzdxUqq/fkuVL94U/Pgil/YzHnEqU8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=blsFy8GTnN79UcqkUpOAhWMCEa+MSkaI3GQzqF3C+hRn6s11nSFvr1rsn3VS/HN6D hLuWMkdcTl28yZmXdgX3f+JW/uXlc5/grX9CUzTqgZynzSHbr5sOz2JLrTEaESIYnj cHi2nW/h/rHEdGoNe3UNWUwkkDJw5yIFARs5VU/8= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 24 Feb 2012 21:07:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <037A83FB-96AF-456A-AB8E-088EC4FE48FA@nic.cz> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] WG Last Call item: PKIX validation 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 Feb 2012 20:07:10 -0000 Minor nit here: On 24. 2. 2012, at 15:50, Paul Hoffman wrote: > 1 -- Certificate usage 1 is used to specify an end entity > certificate, or the public key of such a certificate, that must = be > matched with the end entity certificate given by the server in > TLS. This usage is sometimes referred to as "service certificate > constraints" because it limits which end entity certificate may = be You use singulars in 0,2,3 and here you use plural form "... = constraints". > used by a given host name, port, and protocol. The target > certificate MUST pass PKIX certification path validation and MUST > match the TLSA record. -- 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 Fri Feb 24 12:08:29 2012 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 CC97E21F87C7 for ; Fri, 24 Feb 2012 12:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYOPvgIM3QMh for ; Fri, 24 Feb 2012 12:08:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4370021F879C for ; Fri, 24 Feb 2012 12:08:28 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 61E8C2A2FCD for ; Fri, 24 Feb 2012 21:08:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330114107; bh=7DdakFKCmjqfHx2uZRcXMOgZxF/QhpHRqpFN2pTtycs=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=xYiSyV8o2UrrzrrAG4iqKrreEbDlXKNq2uaI8OXekXw7LtrUSnR6ByS+spSfMGuoq QN/jvrsEgi3up4iVMuQTld0K8dw6i9xy7/zePecej9YUYRj5KULssbcCeHt5pju8+j 0hRrbavI55a5YM2wAu+OJY1xZu4UO/5q+uMjSKCA= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 21:08:27 +0100 Message-Id: <6908584F-E131-4685-98D5-8829E7BF6842@nic.cz> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] 8.2. TLSA Usages 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 Feb 2012 20:08:30 -0000 I suggest we replace Short descriptions in 8.2 with "referred" names = from Section 4. This should replace table in 8.2: Value Short description Reference ---------------------------------------------------------- 0 CA constraint [This] 1 Service certificate constraint [This] 2 Trust anchor assertion [This] 3 Domain-issued certificate [This] 4-254 Unassigned 255 Private use O. -- 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 peter@denic.de Fri Feb 24 13:06:58 2012 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 E359B21F87C7 for ; Fri, 24 Feb 2012 13:06:57 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUimX0CHHed3 for ; Fri, 24 Feb 2012 13:06:57 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 6345721F87E0 for ; Fri, 24 Feb 2012 13:06:52 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S12Li-0003LT-4c; Fri, 24 Feb 2012 22:06:42 +0100 Received: from localhost by x27.adm.denic.de with local id 1S12Li-0006Vl-05; Fri, 24 Feb 2012 22:06:42 +0100 Date: Fri, 24 Feb 2012 22:06:41 +0100 From: Peter Koch To: dane@ietf.org Message-ID: <20120224210641.GG8267@x27.adm.denic.de> Mail-Followup-To: dane@ietf.org References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120224172827.GK48576@mail.yitter.info> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 21:06:58 -0000 On Fri, Feb 24, 2012 at 12:28:28PM -0500, Andrew Sullivan wrote: > security service, in which whether a record returned from the DNS is > not the only question. In other words, as things stand the document > is suggesting that the TTL is not only a control on cache behaviour, > but a control on _application_ behaviour. The more I think about it, > the more I think that's wrong. +1; > > We don't say anything about RRSIGs, do we? > > Nope. But that's my point; if we have to talk about the TTL as > somehow constraining the application behaviour, then we also have to > talk about the RRSIG lifetime constraining application behaviour. And > now you're into the same set of problems as DNS generally has about > the link between the TTL and the expiry time on RRSIGs. DNSSEC assures authenticity, not correctness, therefore the RRSIG lifetime is not a commitment to not alter or remove the data (in the same way the TTL is an instruction to caches, not a promise that data will be unaltered until the TTL expires). Neither discussion has a place in this document. same stone, second bird: On Fri, Feb 24, 2012 at 08:11:45PM +0100, Ond??ej Surý wrote: > On 24. 2. 2012, at 19:51, Andrew Sullivan wrote: > > On Fri, Feb 24, 2012 at 07:29:04PM +0100, Ond??ej Surý wrote: > >> > >> Are we talking about the same cache? Maybe not. I was trying to say that TLSA record MUST NOT be cached in the _application_. > >> > > > > Apparently not, and yes that solves the issue for me. > > > Cool. > > Ok, anybody objects to changing second paragraph of Section 5 to (just changed second must to MUST): > > >> The TLS session that is to be set up MUST be for the specific port > >> number and transport name that was given in the TLSA query. TLSA > >> record MUST NOT be reused and a new TLSA query MUST be made for each > >> new TLS session. I do not see a reason why an application that would implement a cache MUST NOT do that, as long as it conforms to the proper protocol. That means to adhere to the TTL in this case. Do we have similar strict language in the SMTP RFCs? Are we telling web browsers not to reuse A or AAAA information? In any case, the MUST NOT as proposed above ought to be justified within the text. -Peter From ajs@anvilwalrusden.com Fri Feb 24 13:25:10 2012 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 0716B21F8597 for ; Fri, 24 Feb 2012 13:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srOdasI3WMOB for ; Fri, 24 Feb 2012 13:25:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7578F21F8595 for ; Fri, 24 Feb 2012 13:25:09 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6A8A71ECB41D for ; Fri, 24 Feb 2012 21:24:59 +0000 (UTC) Date: Fri, 24 Feb 2012 16:24:57 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120224212457.GY48576@mail.yitter.info> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120224210641.GG8267@x27.adm.denic.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 21:25:10 -0000 On Fri, Feb 24, 2012 at 10:06:41PM +0100, Peter Koch wrote: > in the SMTP RFCs? Are we telling web browsers not to reuse A or > AAAA information? In any case, the MUST NOT as proposed above ought > to be justified within the text. Actually, the "web browser" comparison makes me realise what this text is probably for. Some web browsers _do_ cache the record for themselves. They call this "pinning". It's there partly to prevent a DNSSEC-proof cross-component attack due to rebinding. See Jackson, C et al, "Protecting Browsers from DNS Rebinding Attacks" in CCS'07, October29-November 2, 2007. ACM # 978-1-59593-703-2/07/0011. There does seem to be a problem here, I'm just not sure that the TTL is the solution. A -- Andrew Sullivan ajs@anvilwalrusden.com From ynir@checkpoint.com Fri Feb 24 14:29:53 2012 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 CD50D21F8522 for ; Fri, 24 Feb 2012 14:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuNmPOE+QaOG for ; Fri, 24 Feb 2012 14:29:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ADDB621F851D for ; Fri, 24 Feb 2012 14:29:52 -0800 (PST) X-CheckPoint: {4F480B24-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1OMToQA017235; Sat, 25 Feb 2012 00:29:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 25 Feb 2012 00:29:50 +0200 From: Yoav Nir To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Date: Sat, 25 Feb 2012 00:29:50 +0200 Thread-Topic: [dane] Forcing TLSA immediately Thread-Index: AczzQ9HxOoRrrJzfQA+SVzj82hmaqA== Message-ID: <18333B3D-D8E9-47AB-8A42-053A9B8DBCA8@checkpoint.com> References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> <20120217040314.GA31408@mail.yitter.info> <64FD7BDD-1E55-4A81-AA4F-36487424003D@nic.cz> In-Reply-To: <64FD7BDD-1E55-4A81-AA4F-36487424003D@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 22:29:53 -0000 DQpPbiBGZWIgMjQsIDIwMTIsIGF0IDY6MTEgUE0sIE9uZMWZZWogU3Vyw70gd3JvdGU6DQoNCj4g T24gMTcuIDIuIDIwMTIsIGF0IDIxOjU4LCBKYW1lcyBDbG9vcyB3cm90ZToNCj4+IEFTPiBOb25l IG9mIHRoYXQgaXMgdG8gc2F5IHRoYXQsICJZZXAuICBTdWNrIGl0IHVwLCIgaXMgdGhlIHdyb25n IGFuc3dlci4NCj4+IEFTPiBJdCdzIHJhdGhlciB0byBzYXkgdGhhdCwgaWYgdGhhdCdzIG91ciBh bnN3ZXIsIHdlIG5lZWQgdG8gcG9pbnQgaXQgb3V0DQo+PiBBUz4gZXhwbGljaXRseSwgYmVjYXVz ZSBpdCBzZWVtcyB0byBtZSBsaWtlIGFuIGltcG9ydGFudCBkZXBsb3lhYmlsaXR5DQo+PiBBUz4g aXNzdWUuICBJZiB0aGUgaWRlYSBvZiBJRVRGIHN0YW5kYXJkcyBpcyBpbnRlcm9wZXJhYmlsaXR5 LCB0aGlzIGlzIGENCj4+IEFTPiBwbGFjZSB3aGVyZSB0d28gc3RyYXRlZ2llcyBmYWlsIHRvIGlu dGVyb3BlcmF0ZS4NCj4+IA0KPj4gSWYgZXhwbGljaXRseSBub3RpbmcgdGhhdCB3aWxsIGhlbHAg aW1wbGVtZW50ZXJzIHRoZW4gYnkgYWxsIG1lYW5zLg0KPj4gDQo+PiBJJ20gc3VyZSBQYXVsIGFu ZCBKYWtvYiB3b3VsZCBwcmVmZXIgc29tZSBzdWdnZXN0ZWQgcHJvc2UuDQo+IA0KPiANCj4gSSBy ZWFsbHkgbGlrZSB0aGlzIHN1Z2dlc3Rpb24gOikuICBJdCBzZWVtcyBpdCB3b3VsZCBoZWxwIHRv IGhhdmUgc29tZSBzaW1wbGUgdGV4dCBhYm91dCB3aGF0IGhhcHBlbnMgaWYgeW91IHNjcmV3IHVw IFRMU0EgZGVwbG95bWVudCBpbiBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyAoQXBwZW5kaXgg QSksIGJ1dCBzb21lYm9keSBoYXMgdG8gd3JpdGUgaXQuICBBbnkgdm9sdW50ZWVyPw0KDQpIb3cn cyBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyBhdCB0aGUgYmVnaW5uaW5nIG9mIEEuMToNCg0K QS4xLiAgQ3JlYXRpbmcgVExTQSBSZWNvcmRzDQoNCldoZW4gY3JlYXRpbmcgVExTQSByZWNvcmRz IGNhcmUgbXVzdCBiZSB0YWtlbiB0byBhdm9pZCBtaXNjb25maWd1cmF0aW9ucy4gU2VjdGlvbiA1 IG9mIHRoaXMgZG9jdW1lbnQgc3RhdGVzIHRoYXQgYSBUTFNBIFJSU0VUIHdob3NlIHZhbGlkYXRp b24gc3RhdGUgaXMgc2VjdXJlIE1VU1QgYmUgdXNlZC4gVGhpcyBtZWFucyB0aGF0IHRoZSBleGlz dGVuY2Ugb2Ygc3VjaCBhIFJSU0VUIGVmZmVjdGl2ZWx5IGRpc2FibGVzIG90aGVyIGZvcm1zIG9m IG5hbWUgYW5kIHBhdGggdmFsaWRhdGlvbi4gDQoNCkEgbWlzY29uZmlndXJlZCBUTFNBIFJSU0VU IHdpbGwgZWZmZWN0aXZlbHkgZGlzYWJsZSBhY2Nlc3MgdG8gdGhlIFRMUyBzZXJ2ZXIgZm9yIGFs bCBjb25mb3JtaW5nIGNsaWVudHMsIGFuZCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHByb3ZpZGUg YW55IG1lYW5zIG9mIG1ha2luZyBhIGdyYWR1YWwgdHJhbnNpdGlvbiB0byB1c2luZyBUTFNBLiAN Cg0KDQoNCllvYXYNCg0KDQoNCg== From ajs@anvilwalrusden.com Fri Feb 24 14:53:42 2012 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 5552321F85B5 for ; Fri, 24 Feb 2012 14:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGLkb+JFPlAp for ; Fri, 24 Feb 2012 14:53:41 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8069D21F85B1 for ; Fri, 24 Feb 2012 14:53:41 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 66D8A1ECB41D for ; Fri, 24 Feb 2012 22:53:40 +0000 (UTC) Date: Fri, 24 Feb 2012 17:53:38 -0500 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120224225338.GE48576@mail.yitter.info> References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> <20120217040314.GA31408@mail.yitter.info> <64FD7BDD-1E55-4A81-AA4F-36487424003D@nic.cz> <18333B3D-D8E9-47AB-8A42-053A9B8DBCA8@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18333B3D-D8E9-47AB-8A42-053A9B8DBCA8@checkpoint.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 22:53:42 -0000 On Sat, Feb 25, 2012 at 12:29:50AM +0200, Yoav Nir wrote: > > A.1. Creating TLSA Records > > When creating TLSA records care must be taken to avoid misconfigurations. Section 5 of this document states that a TLSA RRSET whose validation state is secure MUST be used. This means that the existence of such a RRSET effectively disables other forms of name and path validation. > > A misconfigured TLSA RRSET will effectively disable access to the TLS server for all conforming clients, and this document does not provide any means of making a gradual transition to using TLSA. This seems fine to me, modulo the spelling of RRset. A -- Andrew Sullivan ajs@anvilwalrusden.com From i.grok@comcast.net Fri Feb 24 19:29:03 2012 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 666B421E8041 for ; Fri, 24 Feb 2012 19:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXAn2laYC58w for ; Fri, 24 Feb 2012 19:29:02 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id B134911E8072 for ; Fri, 24 Feb 2012 19:29:02 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id e3Nu1i0011YDfWL543V3v8; Sat, 25 Feb 2012 03:29:03 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta20.westchester.pa.mail.comcast.net with comcast id e3V11i00W00PQ6U3g3V2zE; Sat, 25 Feb 2012 03:29:03 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q1P3Sx8s004804 for ; Fri, 24 Feb 2012 22:28:59 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q1P3SxEe004803 for dane@ietf.org; Fri, 24 Feb 2012 22:28:59 -0500 Date: Fri, 24 Feb 2012 22:28:59 -0500 From: Scott Schmit To: dane@ietf.org Message-ID: <20120225032859.GA1671@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> <4F47B7E2.5060200@os3.nl> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <4F47B7E2.5060200@os3.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Call on document name 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 Feb 2012 03:29:03 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2012 at 05:16:34PM +0100, Pieter Lexis wrote: > On 02/24/2012 05:03 PM, Ond=C5=99ej Sur=C3=BD wrote: > > We have these proposals: > >=20 > > a) Using Secure DNS to Associate Certificates with Domain Names For > > TLS > >=20 > > b) The DNS-Based Authentication of Named Entities (DANE) Protocol > > Version 1.0 > >=20 > > c) Transport Level Security Authentication (TLSA) using DNS > > Security > >=20 > > d) The DNS-Based Authentication of Named Entities (DANE) for > > Transport Layer Security (TLS) Protocol > >=20 > > Please vote now. >=20 > d > c > b > a >=20 > But d written as: 'The DNS-Based Authentication of Named Entities > (DANE) Protocol for Transport Layer Security (TLS)', to associate the > word protocol with DANE and not with TLS. d (as rewritten above) >> c >> a I don't like b at all; our charter has us working on DANE for IPsec next, and there's talk of doing it for S/MIME as well. --=20 Scott Schmit --6c2NcOVqGQ03X4Wi Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwMjI1MDMyODU5WjAjBgkqhkiG9w0BCQQxFgQU48AwNUPT pe9BXDW1uoMds+rGjsYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEArsljQAe5 dlc9lrliwz6E+lG5eekwXMQkH6cGm1EEecJLA13sQvN4uTRRomcO8ULqFHFmuSiHAKaN5+Yv PQ7rmBJNmuVUhP+rq4PcAVYimyeBPNuG7p0rOlUHJ+5+4BFnml25Nl6uZqjRrRM1q3vQjCnS 2Q0CSytus+4oseSuimbgWslu8arvmeKaozwBcJiT0ghaotSwl4xp98TdPO77f2LqyUCi7a8d KM3lFeTf4kxddtK+On58YgW++gaAFQ+L3Hb01K/hiQiS2mSuGbxMGmqWucxT9F763ynoHHhI L2eRg7jOCH5+U7d3EJsHJsni6n4KA1jic5o7csL08/4riQ== --6c2NcOVqGQ03X4Wi-- From pieter.lexis@os3.nl Sat Feb 25 01:38:28 2012 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 3ED7E21F8601 for ; Sat, 25 Feb 2012 01:38:28 -0800 (PST) X-Quarantine-ID: X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/x-x509-ca-cert, .asc, dane.kiev.practicum.os3.nl.self-signed.crt | .dat,UNKNOWN.001 X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTJrDIqDJvkA for ; Sat, 25 Feb 2012 01:38:27 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1330162708-3919-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7064321F85F0 for ; Sat, 25 Feb 2012 01:38:26 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id E1F1E17AA24; Sat, 25 Feb 2012 10:38:24 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:222:fbff:fec9:1314] (unknown [IPv6:2001:980:5dd1:1:222:fbff:fec9:1314]) by smtp.os3.nl (Postfix) with ESMTPSA id 98DB917AA23; Sat, 25 Feb 2012 10:38:24 +0100 (CET) Message-ID: <4F48AC0F.4050600@os3.nl> Date: Sat, 25 Feb 2012 10:38:23 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <201202132324.q1DNOVWD009987@new.toad.com> <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> In-Reply-To: <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 09:38:28 -0000 This is a multi-part message in MIME format... ------------=_1330162708-3919-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1330162708-3919-0 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 8bit Content-Description: Original message Return-Path: Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7064321F85F0 for ; Sat, 25 Feb 2012 01:38:26 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id E1F1E17AA24; Sat, 25 Feb 2012 10:38:24 +0100 (CET) Received: from [IPv6:2001:980:5dd1:1:222:fbff:fec9:1314] (unknown [IPv6:2001:980:5dd1:1:222:fbff:fec9:1314]) by smtp.os3.nl (Postfix) with ESMTPSA id 98DB917AA23; Sat, 25 Feb 2012 10:38:24 +0100 (CET) Message-ID: <4F48AC0F.4050600@os3.nl> Date: Sat, 25 Feb 2012 10:38:23 +0100 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= CC: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Hash specs, and examples in sec. 2.3 References: <201202132324.q1DNOVWD009987@new.toad.com> <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> In-Reply-To: <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> X-Enigmail-Version: 1.3.5 Content-Type: multipart/mixed; boundary="------------070309090200080901060605" This is a multi-part message in MIME format. --------------070309090200080901060605 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/24/2012 05:18 PM, OndÅ™ej Surý wrote: > On 14. 2. 2012, at 0:36, Pieter Lexis wrote: >> When making swede I used a selfsigned cert (and a cert signed by >> comodo using the same csr) to create a test bed. I'd be happy to >> supply the WG with the certificates, keys and other material to >> include a (partial) test vector. > > That would be great. I've included the self-signed certificate, as the permutations of the usage field are unimportant for these examples. I would also like to see the document to RECOMMEND using hashing, as a full certificate is large (for me it's over 1100 bytes for a cert with a 3072 bit key). This data can also be retrieved from DNS: _150X._tcp.dane.kiev.practicum.os3.nl Where X is between 0 and 5 (inclusive). > Paul, I share your concern, but I see a value in providing > examples. If we can carefully and independently check provided > examples, then I think we don't have to worry too much. These record were created using swede, so don't use it to verify the correctness of them :). S = Selector M = Matching Type S M Association Data 0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86 4886F70D0101050500306C310B3009060355040613024E4C31163014 0603550408130D4E6F6F72642D486F6C6C616E643112301006035504 071309416D7374657264616D310C300A060355040A13034F53333123 30210603550403131A64616E652E6B6965762E70726163746963756D 2E6F73332E6E6C301E170D3132303131363136353730335A170D3232 303131333136353730335A306C310B3009060355040613024E4C3116 30140603550408130D4E6F6F72642D486F6C6C616E64311230100603 5504071309416D7374657264616D310C300A060355040A13034F5333 312330210603550403131A64616E652E6B6965762E70726163746963 756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500 0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68 7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B 6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE 281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827 C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5 8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172 2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393 37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629 FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D 4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D 4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775 6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617 962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44 9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2 DDFF6B4CAC050203010001300D06092A864886F70D01010505000382 0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57 64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93 D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9 E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C 495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831 48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52 A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16 DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8 B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08 E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0 9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A 591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE 2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903 0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779 82D9364338D955 0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04 883503E5B024CF7A8F6A94 1 0 308201A2300D06092A864886F70D01010105000382018F0030 82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5 7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877 1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24 B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4 C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8 C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008 029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A 9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403 5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1 FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083 1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2 2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05 0203010001 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911 D9E30A924138C4 1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5 33A934B3A2D7E232C94AB4 - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPSKwLAAoJELPqGO5ebd4j6j8QAIo4amiHJa/wOgi2QEn3/Nwa 3Lst2IEuUthb/+1ixEY6d+XhAphp06+YBNTZo8lpUxhX0+ORjZzbfNPw7eg50jlj +rSUi2dY3X/Air9GyjzgXkDLxkzIOGfr+6VTB3gnwkye39fg0Vp3ReZmNbu08r4d q3+ym9BmnrYPd8YXBEIOT54mnh4ZF1LBj5U/nw94k5+oCNWnHpiMt3BTD1bfZsf5 iAatIxxGesyu0UPPWxAqJjUwSKCbCEaLnOppiHNjdQWxYTjAz4POs/+ACq8UHQS8 xQZDhchc0BTLNWtoZvzccW0gFygx/P41sUtdvduZMgjzaA5Ubs4WZVIs2uQpBC5U lzbnflrb+z1efhB0h25q8Y+5MQliqdRUkF86Qv3HunzbUOU+BCeRjQiOabQhZu3q rHxgF7MO//cZ1JPyH/QFZoeDblkIbNMU3Y2M0pS3bNbRgziVSKZuimhrXTFGIh77 1O7BzohuekTHZTFTVY/f2CyeQOseRvfIaculwUfg9TtRpG0TtZzGpM20CduSviik wbeFeGE7zH/O4/wXfo1WWZEc58kSASAYJG90q4sac3itIGbEnJBHBZDOb+1cS+H5 jC1sAN544s59lEToTL6YeLcabRpOsnVr7+UrYJVKLdsD0cWR9ASYvHpJpXpMJHFb 5hhEfCZYpdtM0jmx9fgZ =r5rA -----END PGP SIGNATURE----- --------------070309090200080901060605 Content-Type: application/x-x509-ca-cert; name="dane.kiev.practicum.os3.nl.self-signed.crt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dane.kiev.practicum.os3.nl.self-signed.crt" LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVWRENDQXJ3Q0NRQ3JXTkpPZDYwcTlq QU5CZ2txaGtpRzl3MEJBUVVGQURCc01Rc3dDUVlEVlFRR0V3Sk8KVERFV01CUUdBMVVFQ0JN TlRtOXZjbVF0U0c5c2JHRnVaREVTTUJBR0ExVUVCeE1KUVcxemRHVnlaR0Z0TVF3dwpDZ1lE VlFRS0V3TlBVek14SXpBaEJnTlZCQU1UR21SaGJtVXVhMmxsZGk1d2NtRmpkR2xqZFcwdWIz TXpMbTVzCk1CNFhEVEV5TURFeE5qRTJOVGN3TTFvWERUSXlNREV4TXpFMk5UY3dNMW93YkRF TE1Ba0dBMVVFQmhNQ1Rrd3gKRmpBVUJnTlZCQWdURFU1dmIzSmtMVWh2Ykd4aGJtUXhFakFR QmdOVkJBY1RDVUZ0YzNSbGNtUmhiVEVNTUFvRwpBMVVFQ2hNRFQxTXpNU013SVFZRFZRUURF eHBrWVc1bExtdHBaWFl1Y0hKaFkzUnBZM1Z0TG05ek15NXViRENDCkFhSXdEUVlKS29aSWh2 Y05BUUVCQlFBRGdnR1BBRENDQVlvQ2dnR0JBT1lzaEtXdjVaOEtLbXNsRGU1b2VzakYKeGdU MWZTYk9zaEdSUVArc09NUzV5NzZKSXdndWY0RmlhMnJWM3FESWR4eDA0OHFuOWhNRlN1K2pa ejVJLytSNwpQM3I1aDk0b0dtZ2pDeVM1MmhxWTNMNVJHVnRnNUMvWFVYd3lqWmcrSnFnbnlI ZXJrVTdrd2IvZXJVaTlKYjVmCkxFYzdxY0hMdmQyZ3czVFExWXc0bk1QVzJNSUdZdUdjOTJq ekpFRzM5OUZLNm9sbXpud3lvWElxczRZajBBZ0MKbXA1SEFvZy9pNWQ2R2g1U2tyK0sxeUk1 MUFPVE43aHFPc1lQb0FFcEJGSVhlL0Y1aGdtZ1doTVBBelJYcFNFbQpLZnZkdU9jT0twNWxW b2M4VDN5a2F1U29zWGp3WDdNWkFGNGNISDFMMTMzNk5BTlZZOEVtcWl3ektMa0E1NWtLCnlY aC9BZHFDOTB3OVMyWjB6T3poL1V4dStlWmtUMFkxN2Uyam5Zc09MM3lPQnRybmRXSVR2VDFn Z3hGMXZpa0UKUXJTdnhhNXZScmRwaFZvR2ZCQ1g1aGVXSlNuaFp2SXE3aERkdVlHNHpXL3hm VDF3Y2pGcEE0Mi92QnBFbkkwTgpNYnhvUEY4ODRtRkk1QzdKdTlUWjhtRldteVcxUEIxL3d0 My9hMHlzQlFJREFRQUJNQTBHQ1NxR1NJYjNEUUVCCkJRVUFBNElCZ1FBcktyNEdQcHlHckVv ZmVEVTNJSkVIbklKMnFjTEYwZXhYWk41U1A5MnIzcXMvMDA1djVzdWcKVkZnS1o0V21ZMWxk a0JNcms5UnprcDZCK2dpSDB2LzNpb0hIMEJTNWQzaXJhc25sNXBEMjlhbnBLN1g3cTNHNApW NjVwdHVHTDNNc0xwdnpaMUxDRW8wODJOUlNNU1YxSS9tTlpBN2lJN0IzckpoQlVqdDFJMWor R1VUcEZZa2FZCk1VakExZHVDMXpwTU5RcEN1MllkZGpRdy9HeU9YNTBUNmh0MnFsS2t3MWps NmdRQUQzbEdHREE2dHM3cVRwcU8KbkhUWFBCc0xlNjhXM3Q1MmxyWGk4Z2IzZHhBUFZ5Zmhh RTFCTXZYbWt2UjY5blZ1cUxRaEFBdmdNYlhZOENJTwpRMnRSK3hWUDZWbFRNOEU2SkFQNTNn amwzY1dpTDlZWUxqT1ZrK0pqZEVVQ0lMd1U4K1FQOHo4SVJTYXduRFFsCkJ3TG9vMUt6TXN6 TEQ1M2l6eXN6aUNPNUt2eGh3TGE0cTl0YTl4anRqZHFYd3Bqa2E0S2dHeFNCU0dqUHBQTEQK WW1pLy8wcFpIMEpsaS9kWkdKQXRQa0p0L2gxZjhQeHFJU0J4OXRxTDJEUCtMbFlOaDNkZWp1 a3pQQVcyKzQ2MQpaWW5aRU50ZXFRTT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= --------------070309090200080901060605 Content-Type: application/octet-stream; name="dane.kiev.practicum.os3.nl.self-signed.crt.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dane.kiev.practicum.os3.nl.self-signed.crt.sig" iQIcBAABAgAGBQJPSKwPAAoJELPqGO5ebd4joKUP/1FMUPSOC7LV6PC3UlzEowsuxgqEwuPU 4RTMIrwA9hbHARgnteafwGxJLw90H/J5HXfMYdhYGKwEp9TyB0yURi2xDBaPzRH1OX0EHxi9 dofRFWdPEc3Bh+3jOQkp0jY2AX3ZQxiQY73dGUSLf+QmNlHC1cj464IJ36R6ml8a9xbcndUu z2jxDbE5enCDei3f/rLeOHug2ZA/nKsEAtdFgSz1w5H+4XcgOxEcDaNv547r0xGZDAat98EE m6CxuVCjZuB80vUNYiSSpKYs3NCBz8dcvwY+nbZgukVxCY9g/LS5oNTVrDXqoiTFNh5L4L2L AHNKN8L6qD+cExaSHoyCKtop6nDyFXJmYPCr+Gv+QBe8a8ouB+GrDtxlJrih3itbzHQsv8Vt bQ91idG577Ih0qcABV/O330wVZXkYOUBJV8iA/nh6fohJF+q5LJbD6XzT/l6nQjte0fnhb+2 8uDWqGMC1trHUIcL4celMi2923U6t5q8fGLdKS1o1kHpDnNOaNNVnhMAcqmOZBIa2eXnjA8w /bvFPEf+6fo//NjdrDfz1kHcUJtvsOZj/kN2qhClSecMm5ZoPONx67DATf87Rcw9y7ydNcpi CPLsfKnRye2M8vYAYHJp9l4xRtaD2zAciRHx8wYQgCHfzWz39AEMpctMx5D6K5vs5zLeeMwd lnfr --------------070309090200080901060605-- ------------=_1330162708-3919-0-- From ilari.liusvaara@elisanet.fi Sat Feb 25 03:38:02 2012 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 7949121F85A5 for ; Sat, 25 Feb 2012 03:38:02 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocq2EFxGn5+b for ; Sat, 25 Feb 2012 03:38:02 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by ietfa.amsl.com (Postfix) with ESMTP id C724721F85A3 for ; Sat, 25 Feb 2012 03:38:00 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh02-2.mail.saunalahti.fi (Postfix) with SMTP id 655BDEF592; Sat, 25 Feb 2012 13:37:53 +0200 (EET) Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A019E35351F; Sat, 25 Feb 2012 13:37:53 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 975F91C6382; Sat, 25 Feb 2012 13:37:48 +0200 (EET) Date: Sat, 25 Feb 2012 13:37:48 +0200 From: Ilari Liusvaara To: Pieter Lexis Message-ID: <20120225113748.GA3851@LK-Perkele-VI.localdomain> References: <201202132324.q1DNOVWD009987@new.toad.com> <5cb76a8f-e2e8-4865-bab2-c131c25b6a72@email.android.com> <849C2DF1-C68B-42FB-AA4A-2E26E1B932AC@nic.cz> <4F48AC0F.4050600@os3.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F48AC0F.4050600@os3.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Hash specs, and examples in sec. 2.3 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 Feb 2012 11:38:02 -0000 On Sat, Feb 25, 2012 at 10:38:23AM +0100, Pieter Lexis wrote: Did some verification on these. > These record were created using swede, so don't use it to verify the > correctness of them :). Well, I used some custom tool (hex to binary converter), sha256sum, sha512sum and dumpasn1. > S = Selector > M = Matching Type > > S M Association Data > 0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86 > 2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903 - Parses without errors/warnings using dumpasn1 - No extraneous outer wrapping seen. - Seems to match the syntax defined by RFC1422 (x509v1). > 0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779 > 82D9364338D955 - SHA-256 I get matches. > 0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C > 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04 > 883503E5B024CF7A8F6A94 - SHA-512 I get matches. > 1 0 308201A2300D06092A864886F70D01010105000382018F0030 > 0203010001 - Parses without errors/warnings using dumpasn1 - Substring of full certificate. - No extraneous outer wrapping seen. - The only part of the certificate that looks even remotely like SPKI. > 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911 > D9E30A924138C4 - SHA-256 I get matches. > 1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE > C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5 > 33A934B3A2D7E232C94AB4 - SHA-512 I get matches. -Ilari From ogud@ogud.com Sat Feb 25 11:35:35 2012 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 A0D5721F8551 for ; Sat, 25 Feb 2012 11:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xAgDDUfMHr3 for ; Sat, 25 Feb 2012 11:35:35 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id A89E121F851B for ; Sat, 25 Feb 2012 11:35:34 -0800 (PST) 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 q1PJZWOK043723 for ; Sat, 25 Feb 2012 14:35:33 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F493803.2050201@ogud.com> Date: Sat, 25 Feb 2012 14:35:31 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dane@ietf.org References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> In-Reply-To: <20120224212457.GY48576@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 19:35:35 -0000 On 24/02/2012 16:24, Andrew Sullivan wrote: > On Fri, Feb 24, 2012 at 10:06:41PM +0100, Peter Koch wrote: > >> in the SMTP RFCs? Are we telling web browsers not to reuse A or >> AAAA information? In any case, the MUST NOT as proposed above ought >> to be justified within the text. > > Actually, the "web browser" comparison makes me realise what this text > is probably for. Some web browsers _do_ cache the record for > themselves. They call this "pinning". It's there partly to prevent a > DNSSEC-proof cross-component attack due to rebinding. See Jackson, C > et al, "Protecting Browsers from DNS Rebinding Attacks" in CCS'07, > October29-November 2, 2007. ACM # 978-1-59593-703-2/07/0011. > > There does seem to be a problem here, I'm just not sure that the TTL > is the solution. > > A > There are two issues here that we need to separate, 1) can this TLSA record be used to create a connection to the remote server and how long can the connection stay open? 2) How long can the application hold on to the TLSA record that it got? The answer to #2 is "Respect the DNS TTL" but pay attention to the time it takes to perform a transaction[below]. The answer to #1 if the TLSA validates it can be used to create connection and the connection can stay open as long as both sides agree to keep it open, the DNS TTL is immaterial to this issue. We had a similar discussion in DNSEXT some years back as what is the meaning of TTL == 0, the answer we agreed on is: "The record can be used for the duration of the transaction[below] it is part off". so a TLSA with TTL==0 means it can be used to create one connection and only one. [below] In this context we consider DNS transaction to involve the original lookup and any lookups that follow that one. i.e. if a zone has NS with TTL==0, the validator will keep the NS while it asks for the record asked for and then for the DNSKEY. Some resolvers will implement MIN_TTL rather than keep track of transactions, and use values in the 10..60 seconds range. Olafur From paul.hoffman@vpnc.org Sat Feb 25 16:15:38 2012 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 07B5921F84F9 for ; Sat, 25 Feb 2012 16:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGcLDAj2jj7S for ; Sat, 25 Feb 2012 16:15:37 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DB21F8496 for ; Sat, 25 Feb 2012 16:15:37 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1Q0FXNc035005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Feb 2012 17:15:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: Date: Sat, 25 Feb 2012 16:15:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72E7F45F-E250-48DE-9DF3-2F154CFBE741@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Call on PKIX validation -> PKIX certification path validation 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 Feb 2012 00:15:38 -0000 On Feb 24, 2012, at 12:02 PM, Ond=C5=99ej Sur=C3=BD wrote: >=20 > On 24. 2. 2012, at 15:50, Paul Hoffman wrote: >> Yes, that is more precise. I have changed "validation chain" to = "certification path", and "path validation" to "certificate path = validation", throughout the >=20 > Really minor nit: it's "certification path validation", but as you = have it correctly below I assume it's just a typo here (it's very easy = to slip, I did have to correct myself too). Yep, my typo. >> document (including in the pseudocode). The main place affected is = shown here; let Jakob and I know if there are more changes to be made. >=20 > 2.1.1 will be merged to 4, so just make sure you don't forget to = update it there when merging the text. Errr, I thought that the consensus was to merge 4 into 2.1.1, and then = remove 4. If this is not right, let us know and I will unwind those = changes from our internal version. > Section 9) Security considerations might be updated to the RFC 5280 = terminology as well since it's part of the standard. Did that. > I think it would be better to update Appendices A and B too to be = aligned with the protocol documentation. Can you be specific? > Would I would suggest is to search for word 'chain' and replace it = with correct terminology. If you send me current working draft, I can = help and send you back the patch. I don't understand this request: "chain" is correct terminology from RFC = 5280. It is used throughout that document. --Paul Hoffman From ondrej.sury@nic.cz Sun Feb 26 01:37:47 2012 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 80D3D21F8535 for ; Sun, 26 Feb 2012 01:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.606 X-Spam-Level: X-Spam-Status: No, score=-0.606 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_20=-0.74, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvG0YCadvxy0 for ; Sun, 26 Feb 2012 01:37:46 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE0621F85B1 for ; Sun, 26 Feb 2012 01:37:45 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 9496F2A2E3D; Sun, 26 Feb 2012 10:37:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330249060; bh=NCN0bPhVFCU4TvHqULvZHADe9J+SDlWe/qZGSgfp8a0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WVNQR7gfuXoQMsGLcmDDbc85ulI8/8IKZvzHWoZs1ofUm/KJ167xC45LFFuppYkCw 5DRfQZWdbD6iADgmZQ3Vp4rmExL9fHDZA4zZ31zfYZFRHS8mZgfpWoLJEAx+RsQ6fV Ve1vcMTAjCHVIowGZTfuz1FNHxCSCi1d4nHH9rzY= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <72E7F45F-E250-48DE-9DF3-2F154CFBE741@vpnc.org> Date: Sun, 26 Feb 2012 10:37:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E46E46A-6EF0-4399-90B6-624182ACB0B2@nic.cz> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> <72E7F45F-E250-48DE-9DF3-2F154CFBE741@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] Call on PKIX validation -> PKIX certification path validation 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 Feb 2012 09:37:47 -0000 On 26. 2. 2012, at 1:15, Paul Hoffman wrote: > On Feb 24, 2012, at 12:02 PM, Ond=C5=99ej Sur=C3=BD wrote: >=20 >>=20 >> On 24. 2. 2012, at 15:50, Paul Hoffman wrote: >>> Yes, that is more precise. I have changed "validation chain" to = "certification path", and "path validation" to "certificate path = validation", throughout the >>=20 >> Really minor nit: it's "certification path validation", but as you = have it correctly below I assume it's just a typo here (it's very easy = to slip, I did have to correct myself too). >=20 > Yep, my typo. >=20 >>> document (including in the pseudocode). The main place affected is = shown here; let Jakob and I know if there are more changes to be made. >>=20 >> 2.1.1 will be merged to 4, so just make sure you don't forget to = update it there when merging the text. >=20 > Errr, I thought that the consensus was to merge 4 into 2.1.1, and then = remove 4. If this is not right, let us know and I will unwind those = changes from our internal version. Well, the last thread I have read was: >>>> ZW: I support removing the duplication, but I'd prefer to keep the = section >>>> 4 text and lose the section 2.1.1 text -- it's longer, but it's >>>> clearer IMHO. >>>=20 >>> MM: +1 for that. >>=20 >> PH: It seems like there is a fair amount of support for this = editorial change. Are there any objections? >=20 > RB: I do like the fact that 2.1.1 has RFC 2119 language. But perhaps = the single sentences from 2.1.1 could be used as first sentences for the = paragraphs in section 4 ? But I don't really care about where the text goes. >> Section 9) Security considerations might be updated to the RFC 5280 = terminology as well since it's part of the standard. >=20 > Did that. >=20 >> I think it would be better to update Appendices A and B too to be = aligned with the protocol documentation. >=20 > Can you be specific? Ok, I'll recheck and send suggestion if I have any. >> Would I would suggest is to search for word 'chain' and replace it = with correct terminology. If you send me current working draft, I can = help and send you back the patch. >=20 > I don't understand this request: "chain" is correct terminology from = RFC 5280. It is used throughout that document. You're right. I have somehow missed that when checking RFC 5280. O. -- 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 paul.hoffman@vpnc.org Sun Feb 26 07:25:05 2012 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 5D58C21F853C for ; Sun, 26 Feb 2012 07:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCfSVAQ+qWuk for ; Sun, 26 Feb 2012 07:25:05 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 11B9B21F84E4 for ; Sun, 26 Feb 2012 07:25:05 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1QFP2VN057495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Feb 2012 08:25:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <4E46E46A-6EF0-4399-90B6-624182ACB0B2@nic.cz> Date: Sun, 26 Feb 2012 07:25:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <533CC8A9-5CAE-4359-9151-B3FD42511D30@vpnc.org> References: <20120208145549.1111.7823.idtracker@ietfa.amsl.com> <4F339259.1000601@os3.nl> <0B7A457B-F54E-4065-8F24-973370761805@vpnc.org> <4F33EB47.9030107@panix.com> <561FA48C-E4C7-407E-AF8B-DD89A3D3767E@vpnc.org> <34188FC3-AC11-44A8-BB8A-5789D4BFD85F@vpnc.org> <6C044D86-9B4B-4B1D-BB0C-29496AEBAC18@nic.cz> <72E7F45F-E250-48DE-9DF3-2F154CFBE741@vpnc.org> <4E46E46A-6EF0-4399-90B6-624182ACB0B2@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Call on PKIX validation -> PKIX certification path validation 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 Feb 2012 15:25:05 -0000 On Feb 26, 2012, at 1:37 AM, Ond=C5=99ej Sur=C3=BD wrote: > But I don't really care about where the text goes. Good, we'll leave it in 2.1.1 then. --Paul Hoffman From peter@denic.de Sun Feb 26 09:37:59 2012 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 E0C8321F855F for ; Sun, 26 Feb 2012 09:37:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msv5L+JI5J12 for ; Sun, 26 Feb 2012 09:37:59 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 51CA021F851A for ; Sun, 26 Feb 2012 09:37:59 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1S1i2m-0006aC-9n; Sun, 26 Feb 2012 18:37:56 +0100 Received: from localhost by x27.adm.denic.de with local id 1S1i2m-0002wW-4K; Sun, 26 Feb 2012 18:37:56 +0100 Date: Sun, 26 Feb 2012 18:37:56 +0100 From: Peter Koch To: IETF DANE WG list Message-ID: <20120226173756.GA5724@x27.adm.denic.de> Mail-Followup-To: IETF DANE WG list References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dane] Call on document name 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 Feb 2012 17:38:00 -0000 On Fri, Feb 24, 2012 at 05:03:34PM +0100, Ond??ej Surý wrote: > a) Using Secure DNS to Associate Certificates with Domain Names For TLS > > b) The DNS-Based Authentication of Named Entities (DANE) Protocol Version 1.0 > > c) Transport Level Security Authentication (TLSA) using DNS Security > > d) The DNS-Based Authentication of Named Entities (DANE) for Transport Layer Security (TLS) Protocol i do not care much about the name, but (a) and (c) suggest that DNSSEC rather than DNS is the key part in associating the TLSA record (or its content) with a (domain) name. That would be plain wrong. (d) or (b) are fine. -Peter From ondrej.sury@nic.cz Mon Feb 27 05:41:23 2012 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 5C76C21F8705 for ; Mon, 27 Feb 2012 05:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZySgLY34D0xT for ; Mon, 27 Feb 2012 05:41:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 97B1B21F86B8 for ; Mon, 27 Feb 2012 05:41:22 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:e1cd:2c97:596e:21a0] (unknown [IPv6:2001:1488:ac14:1400:e1cd:2c97:596e:21a0]) by mail.nic.cz (Postfix) with ESMTPSA id 50DBD2A3062 for ; Mon, 27 Feb 2012 14:41:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330350080; bh=NI3zGxuhv2PhZXhx2cIMmBAXHaLZrBGbhy2wvdNbTC4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=l3Q6rqHis83c8YtZCxCNgFgjWxnQ0nlh5OSP1zV6u5EewF6Hj5riZqK5kBKOHMpvY FMxkkX3xM8XYIqBFcmfGy/F2E54CRA1QaBtU5YAavKBMxApYtJsRqDuIMdL+2FFVwF 1XhJnE/pQKWAY2iMX8JLcARhK2ZkdoxAHv19H5YE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120224225338.GE48576@mail.yitter.info> Date: Mon, 27 Feb 2012 14:41:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5D74F8D5-0272-4B15-920E-5977DA70249C@nic.cz> References: <20120216210924.GH29243@mail.yitter.info> <20120216231358.GU29243@mail.yitter.info> <20120217040314.GA31408@mail.yitter.info> <64FD7BDD-1E55-4A81-AA4F-36487424003D@nic.cz> <18333B3D-D8E9-47AB-8A42-053A9B8DBCA8@checkpoint.com> <20120224225338.GE48576@mail.yitter.info> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Forcing TLSA immediately 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 Feb 2012 13:41:23 -0000 On 24. 2. 2012, at 23:53, Andrew Sullivan wrote: > On Sat, Feb 25, 2012 at 12:29:50AM +0200, Yoav Nir wrote: >>=20 >> A.1. Creating TLSA Records >>=20 >> When creating TLSA records care must be taken to avoid = misconfigurations. Section 5 of this document states that a TLSA RRSET = whose validation state is secure MUST be used. This means that the = existence of such a RRSET effectively disables other forms of name and = path validation.=20 >>=20 >> A misconfigured TLSA RRSET will effectively disable access to the TLS = server for all conforming clients, and this document does not provide = any means of making a gradual transition to using TLSA.=20 >=20 > This seems fine to me, modulo the spelling of RRset. I like the text (with RRset). Any objections? O. -- 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 Feb 27 05:52:53 2012 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 4B39821F8713 for ; Mon, 27 Feb 2012 05:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2N5A4ks-nD4 for ; Mon, 27 Feb 2012 05:52:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4D13221F86FD for ; Mon, 27 Feb 2012 05:52:52 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:e1cd:2c97:596e:21a0] (unknown [IPv6:2001:1488:ac14:1400:e1cd:2c97:596e:21a0]) by mail.nic.cz (Postfix) with ESMTPSA id 96A8D2A3073; Mon, 27 Feb 2012 14:52:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330350771; bh=1HqVOmMC+M8KDVfqTWDNAAEBbHpYwZQzZOidZbaXyKk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wjIWyOF9YORwH9wDj3YG0bORCoMjLjgZQQq379Mj8CDjhVaF2DeXPWOynHjQR/Z1j DYj0LQ/5BMZenD7LSjW/LMrSXRk7H5gPXFcEBSEfPMdOSzZmBi89fNfhqOzwEx2806 RJYK+TrYOkhgZs05kZ+e/i51Kvzs8XJ+NSzmnYZQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F493803.2050201@ogud.com> Date: Mon, 27 Feb 2012 14:52:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> To: Olafur Gudmundsson , Andrew Sullivan , Peter Koch X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 13:52:53 -0000 Hi Olafur, Andrew and Peter, On 25. 2. 2012, at 20:35, Olafur Gudmundsson wrote: > On 24/02/2012 16:24, Andrew Sullivan wrote: >> On Fri, Feb 24, 2012 at 10:06:41PM +0100, Peter Koch wrote: >>=20 >>> in the SMTP RFCs? Are we telling web browsers not to reuse A or >>> AAAA information? In any case, the MUST NOT as proposed above ought >>> to be justified within the text. >>=20 >> Actually, the "web browser" comparison makes me realise what this = text >> is probably for. Some web browsers _do_ cache the record for >> themselves. They call this "pinning". It's there partly to prevent = a >> DNSSEC-proof cross-component attack due to rebinding. See Jackson, C >> et al, "Protecting Browsers from DNS Rebinding Attacks" in CCS'07, >> October29-November 2, 2007. ACM # 978-1-59593-703-2/07/0011. >>=20 >> There does seem to be a problem here, I'm just not sure that the TTL >> is the solution. >>=20 >> A >>=20 >=20 >=20 > There are two issues here that we need to separate, > 1) can this TLSA record be used to create a connection to the remote = server and how long can the connection stay open? >=20 > 2) How long can the application hold on to the TLSA record that it = got? >=20 > The answer to #2 is "Respect the DNS TTL" but pay attention to the = time it takes to perform a transaction[below]. >=20 > The answer to #1 if the TLSA validates it can be used to create = connection and the connection can stay open as long as both sides agree = to keep it open, the DNS TTL is immaterial to this issue. >=20 > We had a similar discussion in DNSEXT some years back as what is the = meaning of TTL =3D=3D 0, the answer we agreed on is: > "The record can be used for the duration of the transaction[below] it = is part off". > so a TLSA with TTL=3D=3D0 means it can be used to create one = connection and only one. >=20 > [below] In this context we consider DNS transaction to involve the = original lookup and any lookups that follow that one. i.e. if a zone has = NS with TTL=3D=3D0, the validator will keep the NS while it asks for the = record asked for and then for the DNSKEY. > Some resolvers will implement MIN_TTL rather than keep track of = transactions, and use values in the 10..60 seconds range. I would really like to keep the 'DNS stuff' out of the DANE protocol = document. I don't think it belongs here. >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. TLSA >> record MUST NOT be reused and a new TLSA query MUST be made for each >> new TLS session. >=20 > I do not see a reason why an application that would implement a cache > MUST NOT do that, as long as it conforms to the proper protocol. That > means to adhere to the TTL in this case. =20 > Do we have similar strict language in the SMTP RFCs? =20 > Are we telling web browsers not to reuse A or AAAA information? Well, we kind of do (RFC 2616 Section 15.3): In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. We could add similar section to the DANE protocol Security = Considerations and only keep this simple sentence in Section 5: > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. Ondrej -- 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 Feb 27 05:56:57 2012 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 8CCD421F871A for ; Mon, 27 Feb 2012 05:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICEFPi2hOqXs for ; Mon, 27 Feb 2012 05:56:56 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B1F3221F8717 for ; Mon, 27 Feb 2012 05:56:56 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:e1cd:2c97:596e:21a0] (unknown [IPv6:2001:1488:ac14:1400:e1cd:2c97:596e:21a0]) by mail.nic.cz (Postfix) with ESMTPSA id 0ED1A2A2FF4 for ; Mon, 27 Feb 2012 14:56:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330351016; bh=OwGQKccNjtE3hFqQXG1wjnyeEKTHZ9kLTvxZzHY6vV8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=S93XS91g4lNsOgyXwSHG8cbg65jDslPMUU2CgC9FMfgx/PIQ+QnTO8t6C5yaBgl02 mXaYldCKAVOivlHycGnVwQkvPWqxpbE4O2MTiKS4XYOPCqPuTaO0ImfAfJWTEVcaep P+vrAo7QWyPmbihAG6jnWdiiA/rqz+Vv2nHu0BFo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120226173756.GA5724@x27.adm.denic.de> Date: Mon, 27 Feb 2012 14:56:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08C006E1-C77A-4ECB-9CA7-6E187F40E942@nic.cz> References: <201202161029.q1GATaWD026584@new.toad.com> <20120216152726.GE92956@nysernet.org> <4F3D4A76.70706@os3.nl> <656A6BE1-7A0D-4CA1-B6C5-A886FB8346D1@nic.cz> <20120226173756.GA5724@x27.adm.denic.de> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dane] Call on document name 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 Feb 2012 13:56:57 -0000 To not keep this issue open too long I think we have clear winner: d) rewritten as: > The DNS-Based Authentication of Named Entities (DANE) Protocol for = Transport Layer Security (TLS) Thanks to all, O. On 26. 2. 2012, at 18:37, Peter Koch wrote: > On Fri, Feb 24, 2012 at 05:03:34PM +0100, Ond??ej Sur=C3=BD wrote: >=20 >> a) Using Secure DNS to Associate Certificates with Domain Names For = TLS >>=20 >> b) The DNS-Based Authentication of Named Entities (DANE) Protocol = Version 1.0 >>=20 >> c) Transport Level Security Authentication (TLSA) using DNS Security >>=20 >> d) The DNS-Based Authentication of Named Entities (DANE) for = Transport Layer Security (TLS) Protocol >=20 > i do not care much about the name, but (a) and (c) suggest that DNSSEC > rather than DNS is the key part in associating the TLSA record (or its = content) > with a (domain) name. That would be plain wrong. (d) or (b) are fine. >=20 > -Peter > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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 Wed Feb 29 00:32:17 2012 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 AD86721F86B1 for ; Wed, 29 Feb 2012 00:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0N0iLe-F3xn for ; Wed, 29 Feb 2012 00:32:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2179721F86B3 for ; Wed, 29 Feb 2012 00:32:14 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:1112:9e06:c6ef:13e0] (unknown [IPv6:2001:1488:ac14:1400:1112:9e06:c6ef:13e0]) by mail.nic.cz (Postfix) with ESMTPSA id E9D4D2A30A7; Wed, 29 Feb 2012 09:32:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330504333; bh=i+n5hdI3d/Wdf8WgWIQxYQ8HHO9uHtuwnvRu9dqQWhM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jNXEv6MAaprJAE/oGxYFt8zsoV8mRxZQqPfcYU9ObNU+qxZV50zAVR4WnxKNTvBde RMt0iDsNeNFF45Hf6zgYhI9wgafdYSgqcaasPCz9tflHuUyOnqkgt8rlW7DPyaJuzn PZFFMWUf/kkKrFy7ofZ57Acz2yMC1iYsZ4lPOy78= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> Date: Wed, 29 Feb 2012 09:32:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> To: Olafur Gudmundsson , Andrew Sullivan , Peter Koch X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 08:32:17 -0000 Hi again, My suggestion is to: a) strip this paragraph down to: > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. b) add paragraph to Security Considerations (taken and slightly = rewritten from RFC 2616): X.Y DNS Spoofing Implementations of this protocol rely heavily on the Domain Name = Service, and are thus generally prone to security attacks based on the = deliberate mis-association of TLSA records and DNS names. Implementations need = to be cautious in assuming the continuing validity of an TLSA records/DNS = name association. In particular, implementations SHOULD rely on their name resolver for confirmation of an TLSA record/DNS name association, rather than caching the result of previous domain name lookups. Many platforms already can cache domain name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached = information will remain useful. If implementations cache the results of domain name lookups in order = to achieve a performance improvement, they MUST observe the TTL = information reported by DNS. If implementations do not observe this rule, they = could be spoofed when a previously-accessed server's TLSA record changes, = f.e. as part of certificate rollover. Does this make the document clearer? O. On 27. 2. 2012, at 14:52, Ond=C5=99ej Sur=C3=BD wrote: > Hi Olafur, Andrew and Peter, >=20 > On 25. 2. 2012, at 20:35, Olafur Gudmundsson wrote: >=20 >> On 24/02/2012 16:24, Andrew Sullivan wrote: >>> On Fri, Feb 24, 2012 at 10:06:41PM +0100, Peter Koch wrote: >>>=20 >>>> in the SMTP RFCs? Are we telling web browsers not to reuse A or >>>> AAAA information? In any case, the MUST NOT as proposed above = ought >>>> to be justified within the text. >>>=20 >>> Actually, the "web browser" comparison makes me realise what this = text >>> is probably for. Some web browsers _do_ cache the record for >>> themselves. They call this "pinning". It's there partly to prevent = a >>> DNSSEC-proof cross-component attack due to rebinding. See Jackson, = C >>> et al, "Protecting Browsers from DNS Rebinding Attacks" in CCS'07, >>> October29-November 2, 2007. ACM # 978-1-59593-703-2/07/0011. >>>=20 >>> There does seem to be a problem here, I'm just not sure that the TTL >>> is the solution. >>>=20 >>> A >>>=20 >>=20 >>=20 >> There are two issues here that we need to separate, >> 1) can this TLSA record be used to create a connection to the remote = server and how long can the connection stay open? >>=20 >> 2) How long can the application hold on to the TLSA record that it = got? >>=20 >> The answer to #2 is "Respect the DNS TTL" but pay attention to the = time it takes to perform a transaction[below]. >>=20 >> The answer to #1 if the TLSA validates it can be used to create = connection and the connection can stay open as long as both sides agree = to keep it open, the DNS TTL is immaterial to this issue. >>=20 >> We had a similar discussion in DNSEXT some years back as what is the = meaning of TTL =3D=3D 0, the answer we agreed on is: >> "The record can be used for the duration of the transaction[below] it = is part off". >> so a TLSA with TTL=3D=3D0 means it can be used to create one = connection and only one. >>=20 >> [below] In this context we consider DNS transaction to involve the = original lookup and any lookups that follow that one. i.e. if a zone has = NS with TTL=3D=3D0, the validator will keep the NS while it asks for the = record asked for and then for the DNSKEY. >> Some resolvers will implement MIN_TTL rather than keep track of = transactions, and use values in the 10..60 seconds range. >=20 >=20 > I would really like to keep the 'DNS stuff' out of the DANE protocol = document. I don't think it belongs here. >=20 >>> The TLS session that is to be set up MUST be for the specific port >>> number and transport name that was given in the TLSA query. TLSA >>> record MUST NOT be reused and a new TLSA query MUST be made for each >>> new TLS session. >>=20 >> I do not see a reason why an application that would implement a cache >> MUST NOT do that, as long as it conforms to the proper protocol. That >> means to adhere to the TTL in this case. =20 >> Do we have similar strict language in the SMTP RFCs? =20 >> Are we telling web browsers not to reuse A or AAAA information? >=20 > Well, we kind of do (RFC 2616 Section 15.3): >=20 > In particular, HTTP clients SHOULD rely on their name resolver for > confirmation of an IP number/DNS name association, rather than > caching the result of previous host name lookups. >=20 > We could add similar section to the DANE protocol Security = Considerations and > only keep this simple sentence in Section 5: >=20 >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. >=20 >=20 >=20 > Ondrej > -- > 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 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- 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 cloos@jhcloos.com Wed Feb 29 06:22:15 2012 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 DAB1B21F86FE for ; Wed, 29 Feb 2012 06:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW7FaKz5NerS for ; Wed, 29 Feb 2012 06:22:14 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38C21F867A for ; Wed, 29 Feb 2012 06:22:13 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 18A85403C6; Wed, 29 Feb 2012 14:21:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1330525332; bh=W5F8A6S0vVgIug3Mk7T3yM6turoSVVbMJSDHemjU9is=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=H8TZSBcF2uSyYWTqS7pbLIPvWNGfpf4JrQXQyNHkdn5waJO8XDlSEuQCGzzBvwJHK AP8q/jkGZhysm7DOtx3wLrRYvb8HDOKMn7vKFhw06maFFIgvH/6KAu9C09K1TmORbc j3LWSywjV/paHwaSmOvL8AeR599fAtc6o2IoFx0M= Received: by carbon.jhcloos.org (Postfix, from userid 500) id EC5C636004C; Wed, 29 Feb 2012 14:11:33 +0000 (UTC) From: James Cloos To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= In-Reply-To: <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> (=?utf-8?Q?=22O?= =?utf-8?Q?nd=C5=99ej_Sur=C3=BD=22's?= message of "Wed, 29 Feb 2012 09:32:12 +0100") References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.93 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 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: Wed, 29 Feb 2012 09:11:33 -0500 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120229:ondrej.sury@nic.cz::vswu9m2rKHAgjlNk:000000000000000000000000000000000000000000veiv5 X-Hashcash: 1:30:120229:ogud@ogud.com::YUfnyeIqjs7HtqYJ:000rfSyn X-Hashcash: 1:30:120229:ajs@anvilwalrusden.com::qa7PIx/wkS4S9F9a:00000000000000000000000000000000000000M8FK0 X-Hashcash: 1:30:120229:pk@denic.de::2/iGc4vKqEXK/sfX:00000IHN3/ X-Hashcash: 1:30:120229:dane@ietf.org::INMB2tR2xWTk6lF0:000enXJr Cc: Peter Koch , IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 14:22:15 -0000 >>>>> "OS" == OndÅ™ej Surý writes: OS> a) strip this paragraph down to: >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. OS> b) add paragraph to Security Considerations (taken and slightly rewritten from RFC 2616): OS> X.Y DNS Spoofing OS> .... OS> Does this make the document clearer? That reads well and explains the issue nicely. +1 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ogud@ogud.com Wed Feb 29 06:25:15 2012 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 0E22821F84C4 for ; Wed, 29 Feb 2012 06:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.066 X-Spam-Level: X-Spam-Status: No, score=-106.066 tagged_above=-999 required=5 tests=[AWL=-0.367, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZD9WwdxnMJ3 for ; Wed, 29 Feb 2012 06:25:14 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id A63F921F8460 for ; Wed, 29 Feb 2012 06:25:13 -0800 (PST) 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 q1TEP3ve076831; Wed, 29 Feb 2012 09:25:04 -0500 (EST) (envelope-from ogud@ogud.com) Message-ID: <4F4E353D.5010907@ogud.com> Date: Wed, 29 Feb 2012 09:25:01 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> In-Reply-To: <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: Peter Koch , IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 14:25:15 -0000 I agree Olafur On 29/02/2012 03:32, OndÅ™ej Surý wrote: > Hi again, > > My suggestion is to: > > a) strip this paragraph down to: > >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. > > b) add paragraph to Security Considerations (taken and slightly rewritten from RFC 2616): > > X.Y DNS Spoofing > > Implementations of this protocol rely heavily on the Domain Name Service, > and are thus generally prone to security attacks based on the deliberate > mis-association of TLSA records and DNS names. Implementations need to be > cautious in assuming the continuing validity of an TLSA records/DNS name > association. > > In particular, implementations SHOULD rely on their name resolver for > confirmation of an TLSA record/DNS name association, rather than > caching the result of previous domain name lookups. Many platforms > already can cache domain name lookups locally when appropriate, and > they SHOULD be configured to do so. It is proper for these lookups to > be cached, however, only when the TTL (Time To Live) information > reported by the name server makes it likely that the cached information > will remain useful. > > If implementations cache the results of domain name lookups in order to > achieve a performance improvement, they MUST observe the TTL information > reported by DNS. If implementations do not observe this rule, they could > be spoofed when a previously-accessed server's TLSA record changes, f.e. > as part of certificate rollover. > > Does this make the document clearer? > > O. > > On 27. 2. 2012, at 14:52, OndÅ™ej Surý wrote: > >> Hi Olafur, Andrew and Peter, >> >> On 25. 2. 2012, at 20:35, Olafur Gudmundsson wrote: >> >>> On 24/02/2012 16:24, Andrew Sullivan wrote: >>>> On Fri, Feb 24, 2012 at 10:06:41PM +0100, Peter Koch wrote: >>>> >>>>> in the SMTP RFCs? Are we telling web browsers not to reuse A or >>>>> AAAA information? In any case, the MUST NOT as proposed above ought >>>>> to be justified within the text. >>>> >>>> Actually, the "web browser" comparison makes me realise what this text >>>> is probably for. Some web browsers _do_ cache the record for >>>> themselves. They call this "pinning". It's there partly to prevent a >>>> DNSSEC-proof cross-component attack due to rebinding. See Jackson, C >>>> et al, "Protecting Browsers from DNS Rebinding Attacks" in CCS'07, >>>> October29-November 2, 2007. ACM # 978-1-59593-703-2/07/0011. >>>> >>>> There does seem to be a problem here, I'm just not sure that the TTL >>>> is the solution. >>>> >>>> A >>>> >>> >>> >>> There are two issues here that we need to separate, >>> 1) can this TLSA record be used to create a connection to the remote server and how long can the connection stay open? >>> >>> 2) How long can the application hold on to the TLSA record that it got? >>> >>> The answer to #2 is "Respect the DNS TTL" but pay attention to the time it takes to perform a transaction[below]. >>> >>> The answer to #1 if the TLSA validates it can be used to create connection and the connection can stay open as long as both sides agree to keep it open, the DNS TTL is immaterial to this issue. >>> >>> We had a similar discussion in DNSEXT some years back as what is the meaning of TTL == 0, the answer we agreed on is: >>> "The record can be used for the duration of the transaction[below] it is part off". >>> so a TLSA with TTL==0 means it can be used to create one connection and only one. >>> >>> [below] In this context we consider DNS transaction to involve the original lookup and any lookups that follow that one. i.e. if a zone has NS with TTL==0, the validator will keep the NS while it asks for the record asked for and then for the DNSKEY. >>> Some resolvers will implement MIN_TTL rather than keep track of transactions, and use values in the 10..60 seconds range. >> >> >> I would really like to keep the 'DNS stuff' out of the DANE protocol document. I don't think it belongs here. >> >>>> The TLS session that is to be set up MUST be for the specific port >>>> number and transport name that was given in the TLSA query. TLSA >>>> record MUST NOT be reused and a new TLSA query MUST be made for each >>>> new TLS session. >>> >>> I do not see a reason why an application that would implement a cache >>> MUST NOT do that, as long as it conforms to the proper protocol. That >>> means to adhere to the TTL in this case. >>> Do we have similar strict language in the SMTP RFCs? >>> Are we telling web browsers not to reuse A or AAAA information? >> >> Well, we kind of do (RFC 2616 Section 15.3): >> >> In particular, HTTP clients SHOULD rely on their name resolver for >> confirmation of an IP number/DNS name association, rather than >> caching the result of previous host name lookups. >> >> We could add similar section to the DANE protocol Security Considerations and >> only keep this simple sentence in Section 5: >> >>> The TLS session that is to be set up MUST be for the specific port >>> number and transport name that was given in the TLSA query. >> >> >> >> 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 >> ------------------------------------------- >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > -- > 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 internet-drafts@ietf.org Wed Feb 29 07:47:24 2012 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 BBABC21F8723; Wed, 29 Feb 2012 07:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhN9eHT4Q+9J; Wed, 29 Feb 2012 07:47:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8C21F871C; Wed, 29 Feb 2012 07:47:24 -0800 (PST) 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: 4.00 Message-ID: <20120229154724.18071.36972.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 07:47:24 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-17.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 Feb 2012 15:47:24 -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 : The DNS-Based Authentication of Named Entities (DANE) Pr= otocol for Transport Layer Security (TLS) Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-17.txt Pages : 31 Date : 2012-02-29 Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to certify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-17.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-17.txt From paul.hoffman@vpnc.org Wed Feb 29 07:50:43 2012 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 6E4BC21F8669 for ; Wed, 29 Feb 2012 07:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk-Juqc83cD8 for ; Wed, 29 Feb 2012 07:50:42 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3F821F8639 for ; Wed, 29 Feb 2012 07:50:42 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1TFofKv048895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 29 Feb 2012 08:50:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Feb 2012 07:50:41 -0800 Message-Id: To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Draft -17 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 Feb 2012 15:50:43 -0000 Greetings again. As you can see, we turned in -17 with what we think are = all the changes asked for by the WG chairs. Please review the changes at = , and = let the list and chairs know if you think we missed anything that the = chairs asked us to do. --Paul Hoffman From paul@cypherpunks.ca Wed Feb 29 08:08:05 2012 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 0551D21F87A3 for ; Wed, 29 Feb 2012 08:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKX2E5Ped5zq for ; Wed, 29 Feb 2012 08:08:04 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id AF57721F878E for ; Wed, 29 Feb 2012 08:08:02 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id C04118198B; Wed, 29 Feb 2012 11:08:40 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1TG8dvU006465; Wed, 29 Feb 2012 11:08:40 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 29 Feb 2012 11:08:39 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> Message-ID: References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 16:08:05 -0000 On Wed, 29 Feb 2012, Ondøej Surý wrote: > b) add paragraph to Security Considerations (taken and slightly rewritten from RFC 2616): > > X.Y DNS Spoofing > > Implementations of this protocol rely heavily on the Domain Name Service, > and are thus generally prone to security attacks based on the deliberate > mis-association of TLSA records and DNS names. Implementations need to be > cautious in assuming the continuing validity of an TLSA records/DNS name > association. I don't like this at all. Because "implementations of this protocol" should rely on DNSSEC as I thought was the working group conensus? This section just seems to assume DNSSEC-less dns. > In particular, implementations SHOULD rely on their name resolver for > confirmation of an TLSA record/DNS name association, rather than > caching the result of previous domain name lookups. I don't think we should try to specify localhost DNS behaviour. In fact, caching it might be advantagious for instance where I cache the TLSA when I'm on my trusted home network, and then move into an untrusted coffee shop wifi area. So I really disagree with this statement. Caching should in fact be done to the fullest extend possible to avoid attackers stripping out records. > Many platforms > already can cache domain name lookups locally when appropriate, and > they SHOULD be configured to do so. It is proper for these lookups to > be cached, however, only when the TTL (Time To Live) information > reported by the name server makes it likely that the cached information > will remain useful. Again, out of scope for this document. > If implementations cache the results of domain name lookups in order to > achieve a performance improvement, they MUST observe the TTL information > reported by DNS. If implementations do not observe this rule, they could > be spoofed when a previously-accessed server's TLSA record changes, f.e. > as part of certificate rollover. DNSSEC records cannot be spoofed, so I am not sure what this is supposed to say. > Does this make the document clearer? I don't think so. Paul From warren@kumari.net Wed Feb 29 08:20:21 2012 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 4180C21F866B for ; Wed, 29 Feb 2012 08:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDMFxl+JiXUw for ; Wed, 29 Feb 2012 08:20:20 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B085621F865E for ; Wed, 29 Feb 2012 08:20:20 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 05FD51B40091; Wed, 29 Feb 2012 11:20:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Wed, 29 Feb 2012 11:20:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <39EF8327-A6E3-4157-AFD0-E781C41DF0FE@kumari.net> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Draft -17 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 Feb 2012 16:20:21 -0000 Thank you Paul. Dear WG, Please note that the authors have folded in comments and changes as the = chairs judged consensus. If any requests were missed, or consensus was = incorrectly judged, the fault lies squarely with the chairs, and not the = authors.=20 In other words, direct flames at us, not the authors... W On Feb 29, 2012, at 10:50 AM, Paul Hoffman wrote: > Greetings again. As you can see, we turned in -17 with what we think = are all the changes asked for by the WG chairs. Please review the = changes at = , and = let the list and chairs know if you think we missed anything that the = chairs asked us to do. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ondrej.sury@nic.cz Wed Feb 29 09:42:35 2012 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 C3D7821F86CB for ; Wed, 29 Feb 2012 09:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.506 X-Spam-Level: X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw1jtnhRPPj7 for ; Wed, 29 Feb 2012 09:42:35 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C865321F86BE for ; Wed, 29 Feb 2012 09:42:34 -0800 (PST) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 2F7B22A2E81; Wed, 29 Feb 2012 18:42:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1330537352; bh=oHrecny9MNkUO9vxTp+JDN7xx1Zw/iHfWK5u8YjB7JE=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lRZSoJwQTmECWENbHiTtaiEwOn7umLE4X70Od/3gn3bucBCnpP/o30vRdp9k4olR9 z0VPuKF7wS6mWON2Z1sWdpqajAyUfFeChOnzyrdcYmmuP8hzeYkd8Nzkp3sbJtxs+f nqBpKYavklK9joeuOhEV59f8lsDUNujXYJ4jZ6yw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-2 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 29 Feb 2012 18:42:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> To: Paul Wouters X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 17:42:36 -0000 Hi Paul, On 29. 2. 2012, at 17:08, Paul Wouters wrote: > On Wed, 29 Feb 2012, Ond=F8ej Sur=FD wrote: >=20 >> b) add paragraph to Security Considerations (taken and slightly = rewritten from RFC 2616): >>=20 >> X.Y DNS Spoofing >>=20 >> Implementations of this protocol rely heavily on the Domain Name = Service, >> and are thus generally prone to security attacks based on the = deliberate >> mis-association of TLSA records and DNS names. Implementations need = to be >> cautious in assuming the continuing validity of an TLSA records/DNS = name >> association. >=20 > I don't like this at all. Because "implementations of this protocol" > should rely on DNSSEC as I thought was the working group consensus? Yes, this is correct. > This section just seems to assume DNSSEC-less dns. No, your assumption is wrong. TLSA record/DNS name association can stop = being valid by pure change in the zone. >> In particular, implementations SHOULD rely on their name resolver = for >> confirmation of an TLSA record/DNS name association, rather than >> caching the result of previous domain name lookups. >=20 > I don't think we should try to specify localhost DNS behaviour. In = fact, > caching it might be advantagious for instance where I cache the TLSA > when I'm on my trusted home network, and then move into an untrusted > coffee shop wifi area. So I really disagree with this statement. = Caching > should in fact be done to the fullest extend possible to avoid = attackers > stripping out records. I think your requirement still fits into the 'SHOULD'. >> Many platforms >> already can cache domain name lookups locally when appropriate, and >> they SHOULD be configured to do so. It is proper for these lookups = to >> be cached, however, only when the TTL (Time To Live) information >> reported by the name server makes it likely that the cached = information >> will remain useful. >=20 > Again, out of scope for this document. I disagree. It's entirely valid for this document to specify how to = handle DNS records with regards to security. >> If implementations cache the results of domain name lookups in order = to >> achieve a performance improvement, they MUST observe the TTL = information >> reported by DNS. If implementations do not observe this rule, they = could >> be spoofed when a previously-accessed server's TLSA record changes, = f.e. >> as part of certificate rollover. >=20 > DNSSEC records cannot be spoofed, so I am not sure what this is = supposed > to say. Please re-read the paragraph. It's not saying anything about DNS = records being spoofed as a part of some DNS based attack, but purely = based on the fact that you can cache obsolete information (if you cache = the record longer then their TTL). 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 ------------------------------------------- From paul.hoffman@vpnc.org Wed Feb 29 10:25:44 2012 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 7479321F868A for ; Wed, 29 Feb 2012 10:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCEJeZxRlsY9 for ; Wed, 29 Feb 2012 10:25:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83021F8669 for ; Wed, 29 Feb 2012 10:25:44 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q1TIPYSc057481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Feb 2012 11:25:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-2 From: Paul Hoffman In-Reply-To: Date: Wed, 29 Feb 2012 10:25:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <51D2DF1D-5941-49D5-8502-F8FAC4B9CD51@vpnc.org> References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 18:25:44 -0000 On Feb 29, 2012, at 9:42 AM, Ond=F8ej Sur=FD wrote: > On 29. 2. 2012, at 17:08, Paul Wouters wrote: >=20 >>=20 >> DNSSEC records cannot be spoofed, so I am not sure what this is = supposed >> to say. >=20 > Please re-read the paragraph. It's not saying anything about DNS = records being spoofed as a part of some DNS based attack, but purely = based on the fact that you can cache obsolete information (if you cache = the record longer then their TTL). Also note that I chose to change the name of this section to "DNS = Caching" to make the emphasis clearer. --Paul Hoffman From paul@cypherpunks.ca Wed Feb 29 10:50:23 2012 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 9C26521F86E1 for ; Wed, 29 Feb 2012 10:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGEI201ty6kA for ; Wed, 29 Feb 2012 10:50:22 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3D21F86AF for ; Wed, 29 Feb 2012 10:50:21 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 53D708198B; Wed, 29 Feb 2012 13:51:00 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q1TIovL1002782; Wed, 29 Feb 2012 13:50:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 29 Feb 2012 13:50:56 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: Message-ID: References: <201202211638.q1LGcHdw003904@fs4113.wdf.sap.corp> <938FD82D-C764-4995-B722-5BC68F21256C@nic.cz> <20120224164251.GH48576@mail.yitter.info> <5639B66E-D025-4FF0-AAC4-4FDE3CB0CC93@nic.cz> <20120224172827.GK48576@mail.yitter.info> <20120224210641.GG8267@x27.adm.denic.de> <20120224212457.GY48576@mail.yitter.info> <4F493803.2050201@ogud.com> <17B7CAE2-D86B-4020-BCAC-10568FC78BC2@nic.cz> <2E23A147-FFDF-4C6F-BEF1-2B6B25792C33@nic.cz> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DANE WG list Subject: Re: [dane] End of TTL during TLS setup 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 Feb 2012 18:50:23 -0000 On Wed, 29 Feb 2012, Ondøej Surý wrote: >>> b) add paragraph to Security Considerations (taken and slightly rewritten from RFC 2616): >>> >>> X.Y DNS Spoofing >>> >>> Implementations of this protocol rely heavily on the Domain Name Service, >>> and are thus generally prone to security attacks based on the deliberate >>> mis-association of TLSA records and DNS names. Implementations need to be >>> cautious in assuming the continuing validity of an TLSA records/DNS name >>> association. >> >> I don't like this at all. Because "implementations of this protocol" >> should rely on DNSSEC as I thought was the working group consensus? > > Yes, this is correct. > >> This section just seems to assume DNSSEC-less dns. > > No, your assumption is wrong. TLSA record/DNS name association can stop being valid by pure change in the zone. Please show me the "Security Consideration" for an admin changing/adding/removing TLSA records. If you want to say "be sure not to remove it before $TTL seconds, then say that. >>> In particular, implementations SHOULD rely on their name resolver for >>> confirmation of an TLSA record/DNS name association, rather than >>> caching the result of previous domain name lookups. >> >> I don't think we should try to specify localhost DNS behaviour. In fact, >> caching it might be advantagious for instance where I cache the TLSA >> when I'm on my trusted home network, and then move into an untrusted >> coffee shop wifi area. So I really disagree with this statement. Caching >> should in fact be done to the fullest extend possible to avoid attackers >> stripping out records. > > I think your requirement still fits into the 'SHOULD'. My point is, applications do caching. Browsers cache dns lookups, even if the system resolver is on localhost. There is no valid reason whatsoever to suggest them here in the security considerations not to do so and to re-ask a DNS server. My cached TLSA record MUST be considered valid from the moment I got it (validated by DNSSEC) until the shortest of RRSIG expiry and TTL. I don't need to ask anyone anything else nor do I have to discard it beforehand. You are suggesting the opposite with "rather than caching the result of previous domain name lookups". >>> If implementations cache the results of domain name lookups in order to >>> achieve a performance improvement, they MUST observe the TTL information >>> reported by DNS. If implementations do not observe this rule, they could >>> be spoofed when a previously-accessed server's TLSA record changes, f.e. >>> as part of certificate rollover. >> >> DNSSEC records cannot be spoofed, so I am not sure what this is supposed >> to say. > > Please re-read the paragraph. It's not saying anything about DNS records being spoofed as a part of some DNS based attack, but purely based on the fact that you can cache obsolete information (if you cache the record longer then their TTL). right, so I suggest text along the lines of "An application MUST NOT use cached TLSA records past RRRSIG expiry or TTL" Paul From gnu@toad.com Wed Feb 29 15:22:24 2012 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 9B87C21F865A for ; Wed, 29 Feb 2012 15:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.318 X-Spam-Level: X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gTgpPJsmpj0 for ; Wed, 29 Feb 2012 15:22:20 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1F68421F8542 for ; Wed, 29 Feb 2012 15:22:19 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q1TNMIWD028275; Wed, 29 Feb 2012 15:22:18 -0800 Message-Id: <201202292322.q1TNMIWD028275@new.toad.com> To: Paul Hoffman In-reply-to: References: Comments: In-reply-to Paul Hoffman message dated "Wed, 29 Feb 2012 07:50:41 -0800." Date: Wed, 29 Feb 2012 15:22:18 -0800 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] Draft -17 comments 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 Feb 2012 23:22:24 -0000 Thank you, editors! -17 is a big improvement, editorially, over -16. Most of my comments are small nits, though there's one 2-paragraph insertion that I think is worthwhile. Comments: In 1.2: > There are many use cases for such functionality. [RFC6394] lists the > ones that the DNS RRtype in this document are meant to apply. Perhaps you meant "to apply to". A clearer wording for the last sentence is "This document's DNS RRtypes are designed to apply to the use cases listed in [RFC6394]." Shouldn't we define RRtype the first time we use it, e.g. "This document's DNS Resource Record types (RRtypes) are designed to apply to the use cases listed in [RFC6394]." But why are we talking about RRtypes here in a general statement? It seems to be because we're unwilling to talk about this document as defining a protocol, though it clearly defines more than an RRtype. In 2.1.1 under cert usage 2: > specify a new trust anchor, for example if the domain issues its > own certificates under its own CA that is not expected to be in > the end users' collection of trust anchors. "the end users' collection" uses both the definite article and a plural possessive of a singular noun. Since we are talking about many end users, the plural is right; the singular is not. How about saying "many end users' collections"? In section 4: > An implementation of this protocol makes a DNS query for TLSA records... If you wanted to avoid the p-word, this sentence will need changing. > If a certificate association contains a matching type or certificate > association data that uses a cryptographic algorithm that is > considered too weak for the TLS client's policy, the certificate > association MUST be marked as unusable. s/marked as/considered/g In section 5: > Roll-over -- Section 4 states that applications must not cache TLSA > records beyond their TTL expiration. This ensures that clients > will not latch onto assertions made by expired TLSA records, and > will be able to transition between using one DANE mechanism to > another. Section 4 no longer says that about TTL cacheing, so this will need modification. Perhaps refer now to section 8.1? But that describes security considerations, not requirements on implementations. I'd also suggest replacing the last phrase with "will be able to transition from using one DANE public key or certificate usage type to another." In section 6: > A system creating TLSA records that conforms to this specification > MUST be able to create TLSA records containing certificate usages 0, > 1, 2, and 3. A system creating TLSA records that conforms to this > specification MUST be able to create TLSA records with selectors 0 > (full certificate) and 1 (SubjectPublicKeyInfo). A system creating > TLSA records that conforms to this specification MUST be able to > create TLSA records using matching type 0 (no hash used) and matching > type 1 (SHA-256), and SHOULD be able to create TLSA records using > matching type 2 (SHA-512). I thought we had agreed to pull this paragraph. In section 7.2: > 3 Domain-issued certificate [This] There's an extra space before "[This]". In section 8: > The security of the DNS RRtype described in this document relies on > the security of DNSSEC... This is almost a tautology, caused by replacing "protocol" with "DNS RRtype". But it's not the security of the RRtype that the reader should be concerned with -- it's the security of the TLS-protected communication. Perhaps we should say so. > A better design for > authenticating DNS would be to have the same level of authentication > used for all DNS additions and changes for a particular owner name. I'd replace "owner name" with "domain name", since owner name is not defined anywhere, while everyone knows what a domain name is. > In such environments, > the using TLSA records will prevent the SSL proxy from functioning More clumsy wording used in an attempt to avoid the p-word. If we can't say the obvious, at least remove "the" from "the using". In section 8.1: > Implementations need to > be cautious in assuming the continuing validity of an TLSA records/ > DNS name association. "An TLSA records" sounds bad, even though I know it ultimately refers to "an association". Perhaps you mean "Implementations need to be cautious in assuming the continuing validity of the association between TLSA records and a domain name." But that is almost a tautology, caused by the confusing "association" language. Every DNS resource record produces an association between the domain name and the contents of the record. That association is always only good for a brief time, specified in the TTL. So what are we really trying to say here? > If implementations cache the results of domain name lookups in order > to achieve a performance improvement, they MUST observe the TTL > information reported by DNS. Implementations that fail to follow > this rule this rule could be spoofed when a previously-accessed > server's TLSA record changes, such as during a certificate rollover. I don't see how this can cause an implementation to be "spoofed". If clients cache beyond the TTL, they'll use the old TLSA records, and may be unable to access a TLS server that uses a new certificate. But that's denial of service, not spoofing. The only way I can see to be spoofed is if the TLS server's previous private-key credentials had been exposed (and then this is why the TLS server's certificate has changed and why the corresponding TLSA records were changed). In that case, someone who obtained the server's previous private-key credentials, and who can also act as a man-in-the-middle of the TLS connection, can spoof clients who use the old TLSA records. But that's a much more detailed and less likely scenario than the one described. In section A.1: > When creating TLSA records care must be taken to avoid > misconfigurations. Section 4 of this document states that a TLSA > RRset whose validation state is secure MUST be used. This means that > the existence of such a RRset effectively disables other forms of > name and path validation. A misconfigured TLSA RRset will > effectively disable access to the TLS server for all conforming > clients, and this document does not provide any means of making a > gradual transition to using TLSA. I agree that this paragraph needs to be in the document. I think it belongs in the security considerations section rather than in an appendix. Also, what is a "conforming client"? To what does it conform? Heaven forefend that it conform to a "p-word"! Here there's an important paragraph or 2 missing, just before "When creating TLSA records with certificate usage type 0 (CA Certificate) or type 2 (Trust Anchor)...". Before we spend a few pages saying why it can be tricky to use TLSA in many ways, let's describe a straightforward, non-tricky way to transition to using TLSA: Many TLS server operators will be looking for a straightforward way to transition from only supporting traditional CA-based TLS, or traditional TLS using self-signed certificates, to supporting both traditional TLS and TLSA-based TLS. The most straightforward way to do so is to add a TLSA record with certificate usage 3 which matches the TLS server's current end entity certificate. At the moment that the operator signs the TLSA record and publishes it in the DNS, clients which understand TLSA records will switch to validating the end entity certificate by comparing it directly to the TLSA record. At the same time, clients which do not understand the TLSA record will continue validating the TLS server using traditional TLS as always. This situation will persist over time without interoperability problems. When using certificate usage 3 (domain-issued certificate), whenever the TLS server's end entity certificate is eventually replaced (perhaps on a regular rotation schedule, or due to a security breach), the operator must update the TLSA record to match the new end entity certificate. During this process, operators should also have their CA sign their new certificate as usual (or they should self-sign it) to preserve access for traditional TLS clients. Preplanning will avoid TLSA-based clients being briefly unable to reach the TLS server during the transition. If possible, at least one TTL-period before the TLS server changes its end-entity certificate, the operator should sign and publish both the new and old TLSA records. (For example, if your TTL is 24 hours, publish both records 24 hours or more before you update the TLS server's certificate.) Immediately after the operator changes the TLS server's certificate, whether or not they had published both TLSA records, they should remove the old TLSA record, and sign and publish a TLSA RRset consisting of just the new TLSA record. > When creating TLSA records with certificate usage type 0 (CA > Certificate) or type 2 (Trust Anchor), one needs to understand the > implications when choosing between selector type 0 (full certificate) > and 1 (SubjectPublicKeyInfo). A careful choice is required because > different methods for building trust chains are used by different TLS > clients. The following outlines the cases that one should be aware > of and discusses the implications of the choice of selector type. I'd rewrite to say (particularly after inserting the above graf): TLSA server operators who create TLSA records with certificate types 0, 1, or 2 must take more care, because of the variability in how TLS clients build trust chains. When creating TLSA records with certificate usage type 0 (CA Certificate) or type 2 (Trust Anchor), one needs to understand the implications. The following outlines the cases that TLS server operators should be aware of. I don't understand this phrase from the document: > one needs to understand the > implications when choosing between selector type 0 (full certificate) > and 1 (SubjectPublicKeyInfo). We do have a section later about this (A.1.2), but it seems to me that the much bigger question for TLS server operators is which certificate usage type to use, and which certificate it should identify. Whether it matches the whole cert, or just the public key; and whether it hashes, or provides the whole thing, are secondary to that initial choice that we don't even discuss. For example, the TLS server operator could create a TLSA record that identifies: the end-entity certificate the CA certificate that traditionally signs the EE certificate some other intermediate CA certificate a trust anchor and/or, multiple TLSA records that identify more than one of the above. In several places we suggest identifying the end-entity certificate as a way to reduce interoperability headaches. Can we say more than that, e.g. about what those headaches might be when the TLS server operator makes one of the other choices? > Certificate usage 2 is not affected by the different types of chain > building when the end entity certificate is the same as the trust > anchor certificate. Here's a clearer way to say it, which also points out that usage 3 is also immune from the troubles discussed: "Certificate usages 2 and 3 are not affected by the different types of chain building, if the end entity certificate provided by the TLS server is the same as the certificate identified by (or provided in) the TLSA record." In section A.1.2.2: > One specific use-case should be noted: creating a TLSA association to > certificate I1 that directly signed end entity certificate S1 of the > server. Since the key used to sign S1 is fixed, association to I1 > must succeed: if a client swaps I1 for I2 (a different certificate), > its SPKI must match SPKI of I1. Such and association would not > suffer from a false-negative failure on client's side if the client > uses a reissued CA certificate I2 in place of I1. A few issues here. This is very dense and hard to understand; it took me a few readings. Second, we use "SPKI" without defining it (the previous graf says SubjectPublicKeyInfo and is where we could hang a "(SPKI)"). Third, "Such and association" should be "Such an association". In Appendix C: It's not clear whether these examples all refer to the exact same self-signed certificate. If they do, the lead paragraph should say so. If they don't refer to the same self-signed cert, then perhaps they should. Examples using Matching type 3 should also be provided. (Is there a prejudice in this document against type 3?) Thanks again... John From paul@cypherpunks.ca Wed Feb 29 20:43:50 2012 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 33DC821E803B for ; Wed, 29 Feb 2012 20:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiqqUxxizKlr for ; Wed, 29 Feb 2012 20:43:49 -0800 (PST) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE7621E802A for ; Wed, 29 Feb 2012 20:43:49 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id BBE0A8198B; Wed, 29 Feb 2012 23:44:27 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q214iQLn021164; Wed, 29 Feb 2012 23:44:27 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 29 Feb 2012 23:44:26 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: John Gilmore In-Reply-To: <201202292322.q1TNMIWD028275@new.toad.com> Message-ID: References: <201202292322.q1TNMIWD028275@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Draft -17 comments 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, 01 Mar 2012 04:43:50 -0000 On Wed, 29 Feb 2012, John Gilmore wrote: > This situation will persist over time without > interoperability problems. I think you mean "This situation can persist over time ....." > When using certificate usage 3 (domain-issued certificate), whenever > the TLS server's end entity certificate is eventually replaced > (perhaps on a regular rotation schedule, or due to a security breach), > the operator must update the TLSA record to match the new end entity > certificate. During this process, operators should also have their CA > sign their new certificate as usual (or they should self-sign it) to > preserve access for traditional TLS clients. Preplanning will avoid > TLSA-based clients being briefly unable to reach the TLS server during > the transition. If possible, at least one TTL-period before the TLS > server changes its end-entity certificate, the operator should sign > and publish both the new and old TLSA records. (For example, if your > TTL is 24 hours, publish both records 24 hours or more before you > update the TLS server's certificate.) Immediately after the operator > changes the TLS server's certificate, whether or not they had > published both TLSA records, they should remove the old TLSA record, and > sign and publish a TLSA RRset consisting of just the new TLSA record. This is a rather piece of text and only covers ony specific scenario. I think it will actually be common that domain owners will publish their personal CA certs instead of end entity certificates (or if they don't use their own CA, they probably just go straight for bare keys in TLSA, though keeping it wrapped in a regular cert for compatibility) Perhaps something more generic like: If the DNS operator needs to rollover to a new TLSA record, it should prepublish the new TLSA record along with the old TLSA recrod for at least as long as the TTL on the old TLSA record, before removing that old TLSA record from the zone. Some people might consider prepublishing a TLSA record for a key that is stored offline, to use in case of a server compromise, so that a compromised certificate can be removed immediately. > In several places we suggest identifying the end-entity certificate > as a way to reduce interoperability headaches. Can we say more than > that, e.g. about what those headaches might be when the TLS server > operator makes one of the other choices? Using your own CA is also more flexible when quickly changing certificates on compromised hosts. You don't have to wait any TTL period to change the certificate, as long as the CA itself is not compromised. Paul