From warren@kumari.net Sun Dec 1 11:00:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70731AE5C8 for ; Sun, 1 Dec 2013 11:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXsOUrdF1zzs for ; Sun, 1 Dec 2013 11:00:45 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7A1AE5DF for ; Sun, 1 Dec 2013 11:00:45 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id 4D1251B40621; Sun, 1 Dec 2013 14:00:42 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <309DDDEA-6A01-4A68-AFCE-9B6A1B2CE874@ogud.com> Date: Sun, 1 Dec 2013 14:00:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2A8E39E3-5E76-4724-8CE0-839EA2678B65@kumari.net> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <309DDDEA-6A01-4A68-AFCE-9B6A1B2CE874@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1510) Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2013 19:00:48 -0000 On Oct 16, 2013, at 4:41 PM, Olafur Gudmundsson wrote: >=20 > On Oct 6, 2013, at 5:38 PM, Jim Schaad wrote: >=20 >> Sorry for being late on getting this in. >>=20 >> 1. I do not understand the reasoning behind the 2119 language in the >> introduction. How would one test this in a protocol fashion? The = document >> states that it does not change DANE in anyway, but there are = requirement >> language statements that can be made? This should be stated in = natural >> language not requirement language. Section 1.1 can them be removed = in its >> entirety. >>=20 >=20 > There two instances of MAY and MAY NOT > I reworded them and removed section 1.1 >=20 >> It is expected that DANE parsers in applications and DNS software = will adopt >> these acronyms for parsing and display purposes, however there are no >> requirements that they do so. >>=20 >> 2. In section 2, it states that the references should be both RFC = 6698 and >> this document, however that is not the way that the tables starting = in >> section 2.1 are laid out. They only use RFC 6698 as a reference = document. >>=20 >=20 > There are two different set of references=20 > a) the references for the Registry itself=20 > b) the references for each allocation in the registry.=20 >=20 > This document only applies to the first one=20 > and that is what I said.=20 >=20 >=20 >> 3 s/input>/input./ >>=20 > Fixed >=20 >> 4. I don't think that this phrase "fewer bad TLSA records" is very = helpful. >> What is meant by a bad TLSA record? Is this just ones where the = fields were >> put out of order or does it include ones where the certificate is >> incorrectly hashed? If the goal is to avoid issues with the = certificates >> and what is extracted, then doing something about what goes into the = blob >> would make sense as well. I would agree that specifying how this = would be >> done is out of scope, but noting it as an issue would be reasonable. >>=20 >=20 > I agree and removed that sentence.=20 >=20 >> 5. As I have stated before, I am not a fan of using DANE-TA for = value 2. >> To me this loses the fact that there will be PKIX processing that = occurs >> with this section. I would strongly recommend that this become = PKIX-TA. >> The use of PKIX-TA for the value of 0 never made any sense since = there is >> not trust anchor decision that is associated with the certificate in = this >> record. The only two records currently that have a trust anchor, as = oppose >> to a constraint, component are 2 and 3.=20 >=20 > I leave a call on that to the wise chairs :-)=20 > I do not care personally=20 I'm not sure where these "wise chairs" are, but I believe we have = consensus for PKIX-TA. It's not ideal but seems good enough. Apologies for the delay, digging out from under backlogged mail from the = NANOG/RIPE/IETF/ICANN roadshow=85 W >=20 >>=20 >> 6. The note component at the end of section 2.1 should be deleted. >=20 > Gone >=20 >>=20 >> 7. In section 3, the descriptive text and the example records do not = match >> in very significant ways. >>=20 >=20 > I must be dense, there is not supposed to be any correlation between = the > two paragraphs in section 3 they are supposed to be separate examples.=20= > thanks for good comments.=20 >=20 > Olafur >=20 >> Jim >>=20 >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 "I think it would be a good idea."=20 - Mahatma Ghandi, when asked what he thought of Western civilization From internet-drafts@ietf.org Sun Dec 1 13:01:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759291ADF69; Sun, 1 Dec 2013 13:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2oW-z8eAJFI; Sun, 1 Dec 2013 13:01:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5641AE14D; Sun, 1 Dec 2013 13:01:50 -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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131201210150.12084.26675.idtracker@ietfa.amsl.com> Date: Sun, 01 Dec 2013 13:01:50 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-registry-acronyms-02.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 21:01:52 -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 Entitie= s Working Group of the IETF. Title : Adding acronyms to simplify DANE conversations Author(s) : Olafur Gudmundsson Filename : draft-ietf-dane-registry-acronyms-02.txt Pages : 5 Date : 2013-12-01 Abstract: Experience has show that people get confused using the three numeric fields the TLSA record. This document specifies descriptive acronyms for the three numeric fields in the TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-registry-acronyms-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ogud@ogud.com Sun Dec 1 13:03:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C731AE168 for ; Sun, 1 Dec 2013 13:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7slFaA4eSlw6 for ; Sun, 1 Dec 2013 13:03:14 -0800 (PST) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id B09651AE167 for ; Sun, 1 Dec 2013 13:03:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A9A77500CE; Sun, 1 Dec 2013 16:03:12 -0500 (EST) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5BBA8500BE; Sun, 1 Dec 2013 16:03:11 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <2A8E39E3-5E76-4724-8CE0-839EA2678B65@kumari.net> Date: Sun, 1 Dec 2013 16:03:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <309DDDEA-6A01-4A68-AFCE-9B6A1B2CE874@ogud.com> <2A8E39E3-5E76-4724-8CE0-839EA2678B65@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1510) Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2013 21:03:16 -0000 New version addressing this call by the chairs posted.=20 Olafur On Dec 1, 2013, at 2:00 PM, Warren Kumari wrote: >=20 > On Oct 16, 2013, at 4:41 PM, Olafur Gudmundsson wrote: >=20 >>=20 >> On Oct 6, 2013, at 5:38 PM, Jim Schaad = wrote: >>=20 >>> Sorry for being late on getting this in. >>>=20 >>> 1. I do not understand the reasoning behind the 2119 language in = the >>> introduction. How would one test this in a protocol fashion? The = document >>> states that it does not change DANE in anyway, but there are = requirement >>> language statements that can be made? This should be stated in = natural >>> language not requirement language. Section 1.1 can them be removed = in its >>> entirety. >>>=20 >>=20 >> There two instances of MAY and MAY NOT >> I reworded them and removed section 1.1 >>=20 >>> It is expected that DANE parsers in applications and DNS software = will adopt >>> these acronyms for parsing and display purposes, however there are = no >>> requirements that they do so. >>>=20 >>> 2. In section 2, it states that the references should be both RFC = 6698 and >>> this document, however that is not the way that the tables starting = in >>> section 2.1 are laid out. They only use RFC 6698 as a reference = document. >>>=20 >>=20 >> There are two different set of references=20 >> a) the references for the Registry itself=20 >> b) the references for each allocation in the registry.=20 >>=20 >> This document only applies to the first one=20 >> and that is what I said.=20 >>=20 >>=20 >>> 3 s/input>/input./ >>>=20 >> Fixed >>=20 >>> 4. I don't think that this phrase "fewer bad TLSA records" is very = helpful. >>> What is meant by a bad TLSA record? Is this just ones where the = fields were >>> put out of order or does it include ones where the certificate is >>> incorrectly hashed? If the goal is to avoid issues with the = certificates >>> and what is extracted, then doing something about what goes into the = blob >>> would make sense as well. I would agree that specifying how this = would be >>> done is out of scope, but noting it as an issue would be reasonable. >>>=20 >>=20 >> I agree and removed that sentence.=20 >>=20 >>> 5. As I have stated before, I am not a fan of using DANE-TA for = value 2. >>> To me this loses the fact that there will be PKIX processing that = occurs >>> with this section. I would strongly recommend that this become = PKIX-TA. >>> The use of PKIX-TA for the value of 0 never made any sense since = there is >>> not trust anchor decision that is associated with the certificate in = this >>> record. The only two records currently that have a trust anchor, as = oppose >>> to a constraint, component are 2 and 3.=20 >>=20 >> I leave a call on that to the wise chairs :-)=20 >> I do not care personally=20 >=20 > I'm not sure where these "wise chairs" are, but I believe we have = consensus for PKIX-TA. > It's not ideal but seems good enough. >=20 >=20 > Apologies for the delay, digging out from under backlogged mail from = the NANOG/RIPE/IETF/ICANN roadshow=85 >=20 > W >=20 >=20 >>=20 >>>=20 >>> 6. The note component at the end of section 2.1 should be deleted. >>=20 >> Gone >>=20 >>>=20 >>> 7. In section 3, the descriptive text and the example records do = not match >>> in very significant ways. >>>=20 >>=20 >> I must be dense, there is not supposed to be any correlation between = the >> two paragraphs in section 3 they are supposed to be separate = examples.=20 >> thanks for good comments.=20 >>=20 >> Olafur >>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > --=20 > "I think it would be a good idea."=20 > - Mahatma Ghandi, when asked what he thought of Western civilization >=20 >=20 >=20 From viktor1dane@dukhovni.org Sun Dec 1 13:34:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87FE1AE19F for ; Sun, 1 Dec 2013 13:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arSfzD-4MCYp for ; Sun, 1 Dec 2013 13:34:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id D17B51ADFA3 for ; Sun, 1 Dec 2013 13:34:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3080C2AB16A; Sun, 1 Dec 2013 21:34:28 +0000 (UTC) Date: Sun, 1 Dec 2013 21:34:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131201213427.GH761@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <309DDDEA-6A01-4A68-AFCE-9B6A1B2CE874@ogud.com> <2A8E39E3-5E76-4724-8CE0-839EA2678B65@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A8E39E3-5E76-4724-8CE0-839EA2678B65@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 21:34:33 -0000 On Sun, Dec 01, 2013 at 02:00:41PM -0500, Warren Kumari wrote: > I'm not sure where these "wise chairs" are, but I believe we have > consensus for PKIX-TA. It's not ideal but seems good enough. [ FWIW, I still maintain that PKIX-CA (being just a constraint and not necessarily an anchor for the chain) is correct, while PKIX-TA is misleading. PKIX-CA is quite different from DANE-TA, where the association data in fact specifies a trust-anchor. Multiple implementations have failed to correctly capture the semantics of DANE-TA, we should not IMNSHO make PKIX-CA and DANE-TA appear to be more similar than they are. ] Suggested word-smithing final touches: In the Abstract change: ----- Experience has show that people get confused using the three numeric fields the TLSA record. ----- to: ----- Experience has shown that people are sometimes confused by the three numeric fields in the TLSA record. ----- Replace the introduction: ----- In discussions on how to add DANE [RFC6698] technology to new protocols/services people repeatedly have got confused as what the numeric values stand for and even the order of the fields of a TLSA record. This document updates the IANA registry definition for TLSA record to add a column with acronym for each specified field, in order to reduce confusion. This document does not change the DANE protocol in any way. It is expected that DANE parsers in applications and DNS software can adopt parsing the acronyms for each field. ----- with: ----- In discussions on how to add DANE [RFC6698] technology to new protocols/services there has been repeated confusion as to what the numeric values stand for and even the order of these fields in a TLSA record. This document updates the IANA registry definition for the TLSA record to add an acronym for each specified field, in order to reduce confusion. This document does not change the DANE protocol in any way. It is expected that parsers in applications and DNS software will accept the new acronyms as alternatives to the underlying numeric values in the presentation format of TLSA records. ----- In "IANA considerations replace: ----- [RFC6698] and this document are both to be the reference documents for the three sub-registries. As these acronyms are offered for human consumption, case does not matter, it is expected that software that parses TLSA records will handle either upper or lower case use as input. ----- with: ----- [RFC6698] and this document will be the reference documents for the three sub-registries. As these acronyms are offered for human consumption, case does not matter, it is expected that software that parses TLSA records will process the acronyms in a case-insensitive manner. ----- In "Acknowledgements" replace: ----- Scott Schmit offered real good suggestions to decrease the possibility of confusion. Viktor Dukhovni provided comments from expert point of view. Jim Schaad, Wes Hardaker and Paul Hoffman provided feedback during WGLC. ----- with ----- The author thanks Jim Schaad, Paul Hoffman, Scott Schmit, Viktor Dukhovni and Wes Hardaker for their helpful comments. ----- -- Viktor. From ietf@augustcellars.com Sun Dec 1 18:52:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864661AE2E7 for ; Sun, 1 Dec 2013 18:52:13 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k368VwOA3NoI for ; Sun, 1 Dec 2013 18:52:11 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A4CA51AE25B for ; Sun, 1 Dec 2013 18:52:11 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id A30F22CA0C for ; Sun, 1 Dec 2013 18:52:09 -0800 (PST) From: "Jim Schaad" To: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <309DDDEA-6A01-4A68-AFCE-9B6A1B2CE874@ogud.com> <2A8E39E3-5E76-4724-8CE0-839EA2678B65@kumari.net> <20131201213427.GH761@mournblade.imrryr.org> In-Reply-To: <20131201213427.GH761@mournblade.imrryr.org> Date: Sun, 1 Dec 2013 18:50:43 -0800 Message-ID: <070e01ceef09$4bbe4d30$e33ae790$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ39s23NI8MTM4J4gsDf6CIX3S72AH+2eVVAfb+EFAC0Mr2cAEA7dH4AtkJKYiYmSAcQA== Content-Language: en-us Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 02:52:13 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni > Sent: Sunday, December 01, 2013 1:34 PM > To: dane@ietf.org > Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym > > On Sun, Dec 01, 2013 at 02:00:41PM -0500, Warren Kumari wrote: > > > I'm not sure where these "wise chairs" are, but I believe we have > > consensus for PKIX-TA. It's not ideal but seems good enough. > > [ FWIW, I still maintain that PKIX-CA (being just a constraint and > not necessarily an anchor for the chain) is correct, while PKIX-TA > is misleading. PKIX-CA is quite different from DANE-TA, where the > association data in fact specifies a trust-anchor. Multiple > implementations have failed to correctly capture the semantics > of DANE-TA, we should not IMNSHO make PKIX-CA and DANE-TA appear > to be more similar than they are. ] +1 > > Suggested word-smithing final touches: > > In the Abstract change: > > ----- > Experience has show that people get confused using the three numeric > fields the TLSA record. > ----- > > to: > > ----- > Experience has shown that people are sometimes confused by the > three numeric fields in the TLSA record. > ----- > > Replace the introduction: > > ----- > In discussions on how to add DANE [RFC6698] technology to new > protocols/services people repeatedly have got confused as what the > numeric values stand for and even the order of the fields of a TLSA > record. This document updates the IANA registry definition for TLSA > record to add a column with acronym for each specified field, in > order to reduce confusion. This document does not change the DANE > protocol in any way. > > It is expected that DANE parsers in applications and DNS software can > adopt parsing the acronyms for each field. > ----- > > with: > > ----- > In discussions on how to add DANE [RFC6698] technology to new > protocols/services there has been repeated confusion as to what > the numeric values stand for and even the order of these fields > in a TLSA record. This document updates the IANA registry > definition for the TLSA record to add an acronym for each > specified field, in order to reduce confusion. This document > does not change the DANE protocol in any way. > > It is expected that parsers in applications and DNS software > will accept the new acronyms as alternatives to the underlying > numeric values in the presentation format of TLSA records. > ----- > > In "IANA considerations replace: > > ----- > [RFC6698] and this document are both to be the reference documents > for the three sub-registries. > > As these acronyms are offered for human consumption, case does not > matter, it is expected that software that parses TLSA records will > handle either upper or lower case use as input. > ----- > > with: > > ----- > [RFC6698] and this document will be the reference documents for > the three sub-registries. > > As these acronyms are offered for human consumption, case does not > matter, it is expected that software that parses TLSA records will > process the acronyms in a case-insensitive manner. > ----- > > In "Acknowledgements" replace: > > ----- > Scott Schmit offered real good suggestions to decrease the > possibility of confusion. Viktor Dukhovni provided comments from > expert point of view. Jim Schaad, Wes Hardaker and Paul Hoffman > provided feedback during WGLC. > ----- > > with > > ----- > The author thanks Jim Schaad, Paul Hoffman, Scott Schmit, Viktor > Dukhovni and Wes Hardaker for their helpful comments. > ----- > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From warren@kumari.net Mon Dec 2 10:44:54 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDA81ACCFF for ; Mon, 2 Dec 2013 10:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE_Sw1o8E2lh for ; Mon, 2 Dec 2013 10:44:53 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5795A1AC7F0 for ; Mon, 2 Dec 2013 10:44:53 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id BF97A1B4049E; Mon, 2 Dec 2013 13:44:50 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Dec 2013 13:44:49 -0500 Message-Id: To: "dane@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dane] =?windows-1252?q?On_the_PKIX-TA_/_PKIX-CA_question=85_=5B_?= =?windows-1252?q?One_week_WGLC_=5D?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 18:44:54 -0000 Hi all, So, it seems that I judged consensus without enough data. I should know = by now that naming things is always a fun topic :-) So, lets try and get this "what to call it" question nailed down once = and for all. Please express a preference for: PKIX-TA PKIX-CA DANE- I don't think that anyone really *loves* any of the above, so an even = better outcome is that someone proposes a better acronym that everyone = likes... We are keeping this to 1 week -- please get a response in before Monday, = Dec 9th. W --=20 Outside of a dog, a book is your best friend, and inside of a dog, it's = too dark to read=20 From viktor1dane@dukhovni.org Mon Dec 2 12:32:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAB1ADEC8 for ; Mon, 2 Dec 2013 12:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7iF34qUs-lk for ; Mon, 2 Dec 2013 12:32:46 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id AA2A91ACC81 for ; Mon, 2 Dec 2013 12:32:44 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B3EAE2AB172; Mon, 2 Dec 2013 20:32:41 +0000 (UTC) Date: Mon, 2 Dec 2013 20:32:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131202203241.GM761@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 20:32:48 -0000 On Mon, Dec 02, 2013 at 01:44:49PM -0500, Warren Kumari wrote: > So, lets try and get this "what to call it" question nailed down > once and for all. > > Please express a preference for: > > PKIX-TA > PKIX-CA > DANE- > > I don't think that anyone really *loves* any of the above, so an > even better outcome is that someone proposes a better acronym that > everyone likes... We should attempt to capture something of the flavour of (be at least as clear as) the short names in RFC 6698: 0 - "CA constraint" 1 - "service certificate constraint" 2 - "trust anchor assertion" 3 - "domain-issued certificate" Of these 0 and 2 are reasonably clear, while 1 and especially 3 are a bit oblique. Thus the shorter acronyms I would propose are: 0 CA-CHECK 1 EE-CHECK 2 DANE-TA 3 DANE-EE The word "check" is one of the shorter synonyms for "constraint" when used to mean "restriction". If brevity is not a major priority, we could use "CONSTRAINT" rather than "CHECK". The above has the advantage of not using "PKIX" as a contrast to DANE in 0/1, which was problematic, because 2 is also PKIX, just with a dynamically established X.509 trust anchor. The only non PKIX usage was 3. A similar alternative is: 0 LIMIT-CA 1 LIMIT-EE 2 DANE-TA 3 DANE-EE -- Viktor. From cloos@jhcloos.com Mon Dec 2 13:37:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC781ADF7B for ; Mon, 2 Dec 2013 13:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5mBGRzTqABR for ; Mon, 2 Dec 2013 13:36:58 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 73D221ADF10 for ; Mon, 2 Dec 2013 13:36:56 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 37E951DF55; Mon, 2 Dec 2013 21:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1386020214; bh=PobLUHMyWmPHDQoZInMKhRH6bdPd4e2E0dMQl+HK5sE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=j+O443eeXgOPbCDnUOT5TDb5DgJ9fPSth8SqjPxx6nWqL+4mUYMc8o762c61GadCH of3Mal587T5S6tozj3U27jE3nPomPdfnyouAn/krkQZHV/fyqH6gxURcGtQAsOeRnD W06jKhMJbh6u7SQMHFZyycbd9wNMu2EThLmWFcB6zCw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8F10360027; Mon, 2 Dec 2013 21:34:37 +0000 (UTC) From: James Cloos To: In-Reply-To: (Warren Kumari's message of "Mon, 2 Dec 2013 13:44:49 -0500") References: User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 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, 02 Dec 2013 16:34:37 -0500 Message-ID: Lines: 6 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:131202:dane@ietf.org::Wzhr1PSTR8+8lM3M:000aF6jp Subject: Re: [dane] =?utf-8?q?On_the_PKIX-TA_/_PKIX-CA_question=E2=80=A6_=5B_O?= =?utf-8?q?ne_week_WGLC_=5D?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 21:37:00 -0000 My pref is that the suffices be the same for each of the prefices, therefore PKIX-TA vs DANE-TA vs PKIX-EE vs DANE-EE. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Mon Dec 2 14:15:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F7D1ADF9A for ; Mon, 2 Dec 2013 14:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM_dtgMzC2O3 for ; Mon, 2 Dec 2013 14:15:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 53D801ADFB4 for ; Mon, 2 Dec 2013 14:15:29 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ED2482AB165; Mon, 2 Dec 2013 22:15:25 +0000 (UTC) Date: Mon, 2 Dec 2013 22:15:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131202221525.GO761@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:15:30 -0000 On Mon, Dec 02, 2013 at 04:34:37PM -0500, James Cloos wrote: > My pref is that the suffices be the same for each of the prefices, > therefore PKIX-TA vs DANE-TA vs PKIX-EE vs DANE-EE. I'm all for neatly aligned text, and I appreciate the increased cosmetic appeal, but surely the fact that this masks semantic differences is more important. The CA in usage 0 is not a trust anchor, but it is in usage 2. The chain in usage 2 still requires PKIX validation, be it with a dynamically obtained trust anchor. So PKIX-TA and DANE-TA are each misleading, the first is not a TA, the second is still PKIX. Are the acronyms just supposed to be more memorable than the numbers, or are they supposed to concisely convey the associated meaning? -- Viktor. From bdickson@verisign.com Mon Dec 2 14:47:10 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8891ADEB5 for ; Mon, 2 Dec 2013 14:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9VumvnN5gt7 for ; Mon, 2 Dec 2013 14:47:08 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 625411ADBCD for ; Mon, 2 Dec 2013 14:47:08 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUp0N6qo5fiCKKTC9SGokQUsC1joxXaz8@postini.com; Mon, 02 Dec 2013 14:47:06 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rB2Ml5ON013404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Dec 2013 17:47:05 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 2 Dec 2013 17:47:05 -0500 From: "Dickson, Brian" To: "dane@ietf.org" Thread-Topic: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] Thread-Index: AQHO76wG5822/4zPjUefUdCiEuM5sJpBgbeA Date: Mon, 2 Dec 2013 22:47:04 +0000 Message-ID: In-Reply-To: <20131202221525.GO761@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 22:47:10 -0000 The asymmetry between 0/1 and 2/3 can be confusing - I had to read 6698 several times to sort it out. (I am glad I did, though.) IMHO the acronym should clarify things, or at least suggest which angle to hold 6698 while squinting. How about these: 0 - CERT-CA 1 - CERT-EE 2 - ROOT-TA 3 - JUST-EE 0 can be either a root CA, or intermediate CA. If the latter, this cert itself must PKIX-validate. 2 can be either a root CA, or another trust anchor - but must be the root of the validation chain either way. 1 requires PKIX validation, 3 does not, hence "just" an End Entity. Thus, a ROOT-CA cert, can be used as either type 0 or type 2 - but that is the only likely place where there is likely confusion. (Of course, if your EE is a root CA, it could be type 1 - but then you are clearly insane. :-)) Brian On 12/2/13 5:15 PM, "Viktor Dukhovni" wrote: >On Mon, Dec 02, 2013 at 04:34:37PM -0500, James Cloos wrote: > >> My pref is that the suffices be the same for each of the prefices, >> therefore PKIX-TA vs DANE-TA vs PKIX-EE vs DANE-EE. > >I'm all for neatly aligned text, and I appreciate the increased >cosmetic appeal, but surely the fact that this masks semantic >differences is more important. > > The CA in usage 0 is not a trust anchor, but it is in usage 2. > > The chain in usage 2 still requires PKIX validation, be it with > a dynamically obtained trust anchor. > >So PKIX-TA and DANE-TA are each misleading, the first is not a TA, >the second is still PKIX. Are the acronyms just supposed to be >more memorable than the numbers, or are they supposed to concisely >convey the associated meaning? > >--=20 > Viktor. >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From gnu@toad.com Mon Dec 2 15:05:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C721ADF9D for ; Mon, 2 Dec 2013 15:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrCt4_qcFPjk for ; Mon, 2 Dec 2013 15:05:41 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3771ADF9B for ; Mon, 2 Dec 2013 15:05:41 -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 rB2N5doW027178 for ; Mon, 2 Dec 2013 15:05:39 -0800 Message-Id: <201312022305.rB2N5doW027178@new.toad.com> To: dane@ietf.org In-reply-to: <20131202203241.GM761@mournblade.imrryr.org> References: <20131202203241.GM761@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Mon, 02 Dec 2013 20:32:41 +0000." Date: Mon, 02 Dec 2013 15:05:39 -0800 From: John Gilmore Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 23:05:42 -0000 I propose that we reject the draft entirely and stick with numbers. If we can't agree on the acronyms, can we stop rearranging the deck chairs? A focus on making "running code" for the current DANE RFC would produce far more deployment than replacing numbers with words. John From viktor1dane@dukhovni.org Mon Dec 2 15:19:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEA41ADF46 for ; Mon, 2 Dec 2013 15:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-AY-57GsmHZ for ; Mon, 2 Dec 2013 15:19:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id B57091ADBCD for ; Mon, 2 Dec 2013 15:19:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 718892AB165; Mon, 2 Dec 2013 23:19:30 +0000 (UTC) Date: Mon, 2 Dec 2013 23:19:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131202231930.GP761@mournblade.imrryr.org> References: <20131202221525.GO761@mournblade.imrryr.org> 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] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:19:36 -0000 On Mon, Dec 02, 2013 at 10:47:04PM +0000, Dickson, Brian wrote: > IMHO the acronym should clarify things, or at least suggest which > angle to hold 6698 while squinting. > > How about these: > 0 - CERT-CA > 1 - CERT-EE > 2 - ROOT-TA > 3 - JUST-EE What is the "CERT" prefix intended to suggest? > 0 can be either a root CA, or intermediate CA. If the latter, this cert > itself must PKIX-validate. A simpler view of 0 is that one constructs a chain to a trusted root as usual, but it is only valid if it also contains the DANE specified CA (CA constraint). Thus there is only one case not two. PKIX validation of two separate half-chains, from the root down to the intermediate CA, and from the intermediate CA down the leaf, is *not* equivalent to PKIX validation of a complete chain. It can fail to enforce pathlength limits and name constraints. > 2 can be either a root CA, or another trust anchor - but must be > the root of the validation chain either way. This conflicts with the usual meaning of "root" (meaning self-signed). You're using "root" to mean top of validation chain which is what the "TA" part means so "ROOT-TA" is redundant. > Thus, a ROOT-CA cert, can be used as either type 0 or type 2 - > but that is the only likely place where there is likely confusion. Any CA (root or not) can be used with either 0 or 2. Since root already means something else (self-issued a.k.a. self-signed) we should avoid using it here, since DANE does not treat root CAs differently from other CAs. > (Of course, if your EE is a root CA, it could be type 1 - but > then you are clearly insane. :-)) PKIX chains don't include the trust anchor, and may not be empty, so any TLS peer that presents a leaf self-signed certificate should fail PKIX (and can only be validated by some other mechanism). In usage 3, self-signed certificates will often be root CAs that nobody trusts to sign any other certificates. The "basicConstraints: CA:true" bit is harmless noise in this context. Some users will carefully generate self-signed certs with "CA:false", but this makes little to no difference. -- Viktor. From viktor1dane@dukhovni.org Mon Dec 2 15:47:52 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287001ADFC4 for ; Mon, 2 Dec 2013 15:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFOsDOWhrfgG for ; Mon, 2 Dec 2013 15:47:50 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 772231ADFC2 for ; Mon, 2 Dec 2013 15:47:50 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A67892AB165; Mon, 2 Dec 2013 23:47:47 +0000 (UTC) Date: Mon, 2 Dec 2013 23:47:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131202234747.GQ761@mournblade.imrryr.org> References: <20131202203241.GM761@mournblade.imrryr.org> <201312022305.rB2N5doW027178@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201312022305.rB2N5doW027178@new.toad.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 23:47:52 -0000 On Mon, Dec 02, 2013 at 03:05:39PM -0800, John Gilmore wrote: > I propose that we reject the draft entirely and stick with numbers. > If we can't agree on the acronyms, can we stop rearranging the deck > chairs? A focus on making "running code" for the current DANE RFC > would produce far more deployment than replacing numbers with words. I never found the numbers to be an obstacle, and my focus is as you suggest implementation. I am looking at (really) adding DANE support to OpenSSL (the experimental code in 1.0.2 is IMHO not satisfactory). There is also an optional DANE interface in GnuTLS, it too is not a production-quality DANE implementation. If any GnuTLS maintainers are on the list, they should get in touch. As for the acronyms, I took the draft introduction at its word, which is to say that for this discussion I assumed that indeed some implementors or server operators who need to generate TLSA records do find the numbers confusing. Perhaps as John suggests numbers are better than misleading acronyms, at least then people will read the RFC, rather than guess incorrectly from the acronym. So in the end acronyms would only be useful if they make operator mistakes less likely: 0 - REQUIRED-CA 1 - REQUIRED-LEAF 2 - TRUSTED-CA 3 - MATCHING-LEAF or perhaps :-) 0 - CA-LOVER 1 - CA-SLAVE 2 - CA-OWNER 3 - CA-HATER -- Viktor. From warren@kumari.net Tue Dec 3 12:57:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61FD1ACCFF for ; Tue, 3 Dec 2013 12:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n49Lh-kNts-R for ; Tue, 3 Dec 2013 12:57:48 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313991ACC81 for ; Tue, 3 Dec 2013 12:57:48 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id 25EBD1B40379; Tue, 3 Dec 2013 15:57:45 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Dec 2013 15:57:44 -0500 Message-Id: <913EEE97-FA79-4CF4-9DFC-15229C9709BD@kumari.net> To: "dane@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dane] Meeting in London... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2013 20:57:50 -0000 Hi there all, So, we received the message in Vancouver -- I have just requested a 2 = hour slot for DANE in London. See y'all then :-) W --=20 Eagles soar but a weasel will never get sucked into a jet engine=20 From stpeter@stpeter.im Tue Dec 3 13:13:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282211ADE71 for ; Tue, 3 Dec 2013 13:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgR0KgpUrFpE for ; Tue, 3 Dec 2013 13:13:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4B81AD9B8 for ; Tue, 3 Dec 2013 13:13:01 -0800 (PST) Received: from sjc-vpn7-1126.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4306A4032B; Tue, 3 Dec 2013 14:12:57 -0700 (MST) Message-ID: <529E4957.4080807@stpeter.im> Date: Tue, 03 Dec 2013 14:12:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dane@ietf.org References: <913EEE97-FA79-4CF4-9DFC-15229C9709BD@kumari.net> In-Reply-To: <913EEE97-FA79-4CF4-9DFC-15229C9709BD@kumari.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Meeting in London... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2013 21:13:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/3/13 1:57 PM, Warren Kumari wrote: > Hi there all, > > > So, we received the message in Vancouver Was there ever a report of some kind about the informal meetup held in Vancouver? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSnklXAAoJEOoGpJErxa2pef8P/j3ssECnxnu1eQszpiUIZ1IJ +PEH/Mq21QGg8enp+ZVRAc7/XXZ5rCWDRtEOUwA3LoKHQIcUQs1x6mdbXIgj4WnZ 1w/jjDUJZFLJhSyjj5emBO02snxX82b8DZe2llSzvLGD7D1d9PSGBcQJTPPZRqfU x7t13O3b9N7426Dp37Pyo2w56HLm9TTxYgc0ZR3EjmZuS20uA4g798QCXeMDmWyb zwwsWTJ313pSXkHizzWG+gKccITb0NruibINgbJtdhrukCRUM4hIWgibxkTnnu5L G4Fn3Kk5Gyue+ar3u/yJBECSttegRwaOG2GNjujdkEYQBuUm+VOOyYPKD2hPXGdm GQeKH6fBE4SfWwp6/8MZPDUYYbHX/F889gA7lGtZArmO9eL9hzyebaFmIVWfjGis I0wdyp/q7fA4qRciEF3UeOGpROVE2U4+GP1pOCQiFKwTGu4lAJZCkwfFry1p2qWD Guc2u+LaK0bVcMgolop9H9PgDvUgD+2GKi215C3UadtS3J/OfzXYpR9gCtNRALoe il2nmouw5hXefxiWZSUhYg1deii9UZvMYDmkQu3Nk/+nIdK9STXdynattTJTrMEq FeswFDP9pzjGwTNaa2zFhPNgYaENztR3mSsC2FQVSr5fupOwyak7P3rP1UsiBr+L BBV6fjj0aTyLOSrh0Q6A =3Npz -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Dec 3 16:17:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8B11AE1A2 for ; Tue, 3 Dec 2013 16:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozkT-IEyjE9S for ; Tue, 3 Dec 2013 16:17:21 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 052D91ADFD1 for ; Tue, 3 Dec 2013 16:17:20 -0800 (PST) Received: from sjc-vpn4-368.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 474C94032B; Tue, 3 Dec 2013 17:17:14 -0700 (MST) Message-ID: <529E7488.80601@stpeter.im> Date: Tue, 03 Dec 2013 17:17:12 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "dane@ietf.org list" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] terminology question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2013 00:17:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In RFC 6125, Jeff Hodges and I tried hard to define some terminology related to certificate checking in TLS. That terminology might not be ideal, but I'd like to see if we can align draft-ogud-dane-vocabulary with the RFC 6125 terms. In particular, RFC 6125 uses the term "source domain" to refer to the fully qualified domain name that a TLS client expects to find in the certificate (or, in DANE, potentially the key) that is presented by the TLS server. RFC 6125 also uses the term "derived domain" to refer to a domain name (or host name) that the client has derived from the source domain in an automated fashion (e.g., via a DNS SRV record). As far as I can determine, draft-ogud-dane-vocabulary uses the terms "Query [Name]" and "Final [Name]" for something like "source domain" and "derived domain". However, draft-ogud-dane-vocabulary also uses the terms "Service Specification Records" and "Service Address Records" in a way that might be similar, although I confess that I don't really grok draft-ogud-dane-vocabulary in fullness and the latter two terms are unclear to me. Naming is hard, and I hope we can get it right. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSnnSIAAoJEOoGpJErxa2pIPcP/3ynoIh5Xn1oBXMtf1Tj4yyZ sJc2kEoA1r49CLCz3TsqHaQonB/lK6tZP0WGYoNobj/C6Vd9U8RQW2TElWM7fVo1 ltZmBA0Tx6KHv/XQmnNsrKVbiueqMui5tWvyHDE/x/Wt18lJPM1n4LdY+xkR4O62 en7PCNTLNxAjkpjPKrEqbp0YYiI67rsnKxNOEJkjry3l+j9FOYlPyBtHAyRZISgV YKy6eIyIEGYOfIXtiiEYPx3UNgIuOLpozu5OWAmypdP6xTfXYmHpAX9HVD7lPPqK ZOGzz61RYDSid186uBQGizahaAabRvIwayQ8ZZTr7C+JYW//CckRRrC04R12h9K+ qNfnzSzf11x01VMfEK2V7muD2uqi28LBXsC/vY2E/r6FRxAp7BS1OZccFK224NnK xI+ETnMsl/ZaWIOKhyJk44bWODWr6ij1Gxen3UoEIsU90akFmzCuCEdbdgf0lATr wX71rVUi5O/ytHQZ/YfhOtc2j7qbrnfSc7KZcgr7X7IkhexP3/nVKtuziqdrbL4U i7pVh5xlgyTszEyowyKWIjr0+J98Llbdz0Xs1hTOTwEONW4cx7TsUd05cwdmoc4G KLabfuUTYKp4NslfIV4smBIl2uzrYUaz0ACjLQSrzk4dNGZAj0L6IlyS92g211Pl WEIrV0m+zIhv6K1ffWiS =VUnT -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Tue Dec 3 16:42:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95E61ADE89 for ; Tue, 3 Dec 2013 16:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HYO4wum7Rvd for ; Tue, 3 Dec 2013 16:42:10 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6B1ADF79 for ; Tue, 3 Dec 2013 16:42:10 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2D6C72AB141; Wed, 4 Dec 2013 00:42:07 +0000 (UTC) Date: Wed, 4 Dec 2013 00:42:07 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131204004207.GX761@mournblade.imrryr.org> References: <529E7488.80601@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529E7488.80601@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] terminology question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 00:42:12 -0000 On Tue, Dec 03, 2013 at 05:17:12PM -0700, Peter Saint-Andre wrote: > In particular, RFC 6125 uses the term "source domain" to refer to the > fully qualified domain name that a TLS client expects to find in the > certificate (or, in DANE, potentially the key) that is presented by > the TLS server. RFC 6125 also uses the term "derived domain" to refer > to a domain name (or host name) that the client has derived from the > source domain in an automated fashion (e.g., via a DNS SRV record). > > As far as I can determine, draft-ogud-dane-vocabulary uses the terms > "Query [Name]" and "Final [Name]" for something like "source domain" > and "derived domain". However, draft-ogud-dane-vocabulary also uses > the terms "Service Specification Records" and "Service Address > Records" in a way that might be similar, although I confess that I > don't really grok draft-ogud-dane-vocabulary in fullness and the > latter two terms are unclear to me. > > Naming is hard, and I hope we can get it right. With DANE the name the client expects to find in a peer certificate is the "TLSA base domain". Thus if the TLSA records were found via: _25._tcp.mx.example.com. IN TLSA 3 1 1 {blob} (even if that was an alias for some other location in DNS) the "TLSA base domain" is "mx.example.com" and with usages other than 3, that's basically what one looks for in the peer certificate. At least for SMTP, there is an additional twist, because when the TLSA base is the result of an MX lookup: example.com. IN MX 0 mx.example.com. the DANE SMTP draft (in agreement with the expired SRV draft) specifies that "example.com" is also an acceptable name in the peer certificate. This allows sites with pre-DANE "UCC" certificates that only match the email domain, to be acceptable to both DANE and non-DANE clients. Thus a DANE SMTP client will admit either the original domain or the MX hostname as a valid SMTP server name. All that said, I am not directly answering your question. Just pointing out that the "TLSA base domain" is the natural analogue of the actual (derived?) domain used for peer verification, except that with DANE the "derivation" process is always DNSSEC validated. With SMTP (and perhaps if we stay with the spirit of the expired SRV draft) when the TLSA base domain differs from the "source domain" (e.g. envelope recipient domain) it would be also be a valid peername. -- Viktor. From bry8star@inventati.org Tue Dec 3 21:34:50 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393191AE1EA for ; Tue, 3 Dec 2013 21:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtOzT_kb_vPZ for ; Tue, 3 Dec 2013 21:34:47 -0800 (PST) Received: from latitanza.investici.org (latitanza.investici.org [82.94.249.234]) by ietfa.amsl.com (Postfix) with ESMTP id 770EC1AE03F for ; Tue, 3 Dec 2013 21:34:47 -0800 (PST) Received: from [82.94.249.234] (latitanza [82.94.249.234]) (Authenticated sender: bry8star@inventati.org) by localhost (Postfix) with ESMTPSA id 559E1984BE for ; Wed, 4 Dec 2013 05:34:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inventati.org; s=stigmate; t=1386135283; bh=9Ew8UdDHt8LhHsHhn1ITf0KCNdiAWouDsEn8CV5PdRc=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=iohR6RNKnE/0r3OwXoR4Q3dL0AeoJKGKWzHAcBF4zPuAqqy02DhSvK4SH7e3S89nC Vdf+T0Hs5T5pmk5C0qfENWFNykHsDKdF3NAMtVgLeaXQYmfAu2QhY71/E3fC7uGNdS 8WfX65YtPwH1xkoc2+QPIj3nNmS8oujqj+LLbxjo= Message-ID: <529EBF12.8000101@inventati.org> Date: Tue, 03 Dec 2013 21:35:14 -0800 From: Bry8 Star User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dane] =?windows-1252?q?On_the_PKIX-TA_/_PKIX-CA_question=85_=5B_?= =?windows-1252?q?One_week_WGLC_=5D?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bry8star@inventati.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 05:34:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 U = Usage DANE = TLSA PKIX = PKIX certification path validation (CPV) EE = End entity. That can be DOI or ZOI (Domain/Zone Owner Issued) ? ? or DI / ZI (Domain/Zone Issued). This 4 U categories are not enough, as "The Certificate Usage Field" (Section 2.1.1 of RFC 6698). *Please add* at least few more appropriate category for declaring very accurately & correctly, so that no confusion exists, for publicly declaring to others: (A) INTERMEDIATE CA or TA certs (under U=0 & U=2), (B) a category for EE certs with PKIX *AND* DANE check under TA (U=2) certs (if U=1 is not for that purpose). Joining suggestion from this thread: 0 - "CA constraint" = CA-CHECK = PKIX-CA = LIMIT-CA = REQUIRED-CA = CA-LOVER 1 - "service certificate constraint" = EE-CHECK = LIMIT-EE = REQUIRED-LEAF = CA-SLAVE 2 - "trust anchor assertion" = DANE-TA = PKIX-TA = TRUSTED-CA = CA-OWNER 3 - "domain-issued certificate" = DANE-EE = MATCHING-LEAF = CA-HATER U = 0 can be used for either a TA or CA cert declaration. U = 2 is for Domain-issued TA cert declaration. U = 3 is for Domain-issued EE cert declaration. TLSA = DANE So these seems to be appropriate from my point of view for now: 0 = 3PI-CA:TLSA+PKIX (for 3rd Party Issued CA or TA cert) or 3PI-TA 1 = EE:TLSA+PKIX (for End entity cert) 2 = DOI-TA:TLSA+PKIX (for Domain Owner Issued TA cert) or ZOI-TA (for Zone Owner Issued TA cert) 3 = DOI-EE:TLSA+NO-PKIX (for Domain Owner Issued EE cert) or ZOI-EE TLSA = DANE U = 1 type of SSL cert declaration, (are PKIX+TLSA *checked*), and 1 can be: either under the U = 0 (are also PKIX+DANE *checked*) cert, or can be under the U = 2 (are PKIX+DANE *checked*) cert. Since U = 3 DO *NOT* REQUIRE a PKIX CPV check, then, *WHERE* is the EE-DANE+PKIX-CHECKED category !? for declaring certs that are under U=2 ? So, can U = 1 type cert TLSA(DANE) declaration, be used for such certs, which can be either under a CA (U=0) or under a TA (U=2), to me this seems to make sense. Then U=1 can serve EE_DANE+PKIX_CHECKED, for both U=0 & U=2. BrS Received from Warren Kumari, on 2013-12-02 10:44 AM: > Hi all, > > So, it seems that I judged consensus without enough data. I should know by now that naming things is always a fun topic :-) > > So, lets try and get this "what to call it" question nailed down once and for all. > > Please express a preference for: > > PKIX-TA > PKIX-CA > DANE- > > I don't think that anyone really *loves* any of the above, so an even better outcome is that someone proposes a better acronym that everyone likes... > > We are keeping this to 1 week -- please get a response in before Monday, Dec 9th. > > W > Reference, from RFC 6698: Hoffman & Schlyter Standards Track [Page 7] RFC 6698 DNS-Based Authentication for TLS August 2012 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 certificate usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given service on a host. The presented 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. Because this certificate usage allows both trust anchors and CA certificates, the certificate might or might not have the basicConstraints extension present. 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 certificate usage is sometimes referred to as "service certificate constraint" because it limits which end entity certificate can be used by a given service on a host. 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 the trust anchor when validating the end entity certificate given by the server in TLS. This certificate 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 certificate 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. The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3. Note: Pls make sure to reply only into one email address: dane@ietf.org , when you reply, Thanks in advance. -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJSnr8SXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDNzBGRDNEMDcwRUI1Q0FERkMwNDBGQ0I4 MEY2OEE0NjFGNTkyM0ZBAAoJEID2ikYfWSP6O3oP/0e6+6BPo2FsASnXLgdcbp08 qc2GHTH6brZ4S/qAswgj/VIJRE/1/SFQhZHAtRlRz96GIoZZ1g9WrIjsXt4qsmto 74jJqC9Ay3fa2dj9qVJZSpLcImDtnVoZIvaXkfCDS6afU3anTa5KjUFoNS3PRHjg KX1eiNzP+4r1phf+gQNv8OOxRM54/FHvmfx5f0T34Ac9bv80NHNUNZR1VpsGCxBB uKVB+gIF6Pnt/RP+XN9wAdT7cOPmPdNIVN39ebqsgt3MGL694otr3rUlczSD+OcD tpAv+uEhdXUQN5RZt9z2cwxxh3V6iM1vQhoHRA3eHYgkrB3TOhKwmJRNuDREAVnd kLXn6fLei+asvauVlyFYACjmdk8tTPJ1wCDb3FumbYOZ3u8guXuAfLOJdJYGLbSP c2RKu0GJq9DtIxQqTKIHz32Tydf3VccAy2e/C9IxuHcfiVqbq6rTE1kYxbci6zv9 1EvFH+QKVRiZg2OzGFmLqu0tzD/QGsIjTBVpvIc2CVru52RsmzSGDxLaFsozf7PS kAkQN1q44PGUstixajhtpE9BYQ3ZiyTrG5LSciG8yzLNbSmajFm29GSs//GU60SB zLTt7JNJnvmoHzVfVCE1LkoMw/zve+xdvStwIuo47fCOV/AHntxJ+hI0rRLK/Bbr nQvVKM+49opvJY9Bdzwj =rwXE -----END PGP SIGNATURE----- From ogud@ogud.com Wed Dec 4 05:47:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A211AE127 for ; Wed, 4 Dec 2013 05:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS4c57ajGq4c for ; Wed, 4 Dec 2013 05:47:56 -0800 (PST) Received: from smtp116.ord1c.emailsrvr.com (smtp116.ord1c.emailsrvr.com [108.166.43.116]) by ietfa.amsl.com (Postfix) with ESMTP id DE2031AE11B for ; Wed, 4 Dec 2013 05:47:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 1BFFD1B8162; Wed, 4 Dec 2013 08:47:52 -0500 (EST) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D912A1B8133; Wed, 4 Dec 2013 08:47:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <529E7488.80601@stpeter.im> Date: Wed, 4 Dec 2013 08:47:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529E7488.80601@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org list" Subject: Re: [dane] terminology question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2013 13:47:58 -0000 On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > In RFC 6125, Jeff Hodges and I tried hard to define some terminology > related to certificate checking in TLS. That terminology might not be > ideal, but I'd like to see if we can align draft-ogud-dane-vocabulary > with the RFC 6125 terms. >=20 > In particular, RFC 6125 uses the term "source domain" to refer to the > fully qualified domain name that a TLS client expects to find in the > certificate (or, in DANE, potentially the key) that is presented by > the TLS server. RFC 6125 also uses the term "derived domain" to refer > to a domain name (or host name) that the client has derived from the > source domain in an automated fashion (e.g., via a DNS SRV record). >=20 > As far as I can determine, draft-ogud-dane-vocabulary uses the terms > "Query [Name]" and "Final [Name]" for something like "source domain" > and "derived domain". However, draft-ogud-dane-vocabulary also uses > the terms "Service Specification Records" and "Service Address > Records" in a way that might be similar, although I confess that I > don't really grok draft-ogud-dane-vocabulary in fullness and the > latter two terms are unclear to me. Peter,=20 Thanks asking this question,=20 You made me read RFC6125 and to my horror the vocabulary there is = attempting similar things as I'm doing in my draft, but in section 1.8 I realized = that you might have taken a=20 shortcut that leads to a incomplete specification i.e. you are not = taking into account the effects of CNAME and DNAME records on the resolution, in particular DNAME requires = careful rules=20 as to the names used to present to the servers. (my guess is this is = where the "i don't really grok"=20 comment comes from) (I think NAPTR has similar effects).=20 "Source domain" definition is a good example of this. In -vocabulary- = draft=20 the application issues query for "query name" where it is expecting to = find the "Service Specification Records".=20 but DNAME/NAPTER/CNAME rules may rewrite the name sent to application = server to the "resulting name" from the query=20 thus the term "Offered Name".=20 For HTTP Service Specification Records =3D=3D Service Address records = i.e. address record is the service specification,=20 but Jabber uses SRV records for the Service Specification Records=20 and the Service Address Records are associated with the servers listed = in the SRV RRset.=20 To a large extent I think the differences we see are due to the = different approaches, i.e. you are attempting to word rules for existing = applications. I'm defining rules that are general and ignore the names existing = applications have used an concentrate on concepts that then can be used by application specifications. =20 I wanted to create definitions that allow minimal DNS related text = inside a DANE application specification=20 (not sure I'm there yet).=20 >=20 > Naming is hard, and I hope we can get it right. >=20 Naming of concepts is hard, definitions are hard,=20 understanding the nuances of interaction of multiple protocols is even = harder :-)=20 Olafur > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJSnnSIAAoJEOoGpJErxa2pIPcP/3ynoIh5Xn1oBXMtf1Tj4yyZ > sJc2kEoA1r49CLCz3TsqHaQonB/lK6tZP0WGYoNobj/C6Vd9U8RQW2TElWM7fVo1 > ltZmBA0Tx6KHv/XQmnNsrKVbiueqMui5tWvyHDE/x/Wt18lJPM1n4LdY+xkR4O62 > en7PCNTLNxAjkpjPKrEqbp0YYiI67rsnKxNOEJkjry3l+j9FOYlPyBtHAyRZISgV > YKy6eIyIEGYOfIXtiiEYPx3UNgIuOLpozu5OWAmypdP6xTfXYmHpAX9HVD7lPPqK > ZOGzz61RYDSid186uBQGizahaAabRvIwayQ8ZZTr7C+JYW//CckRRrC04R12h9K+ > qNfnzSzf11x01VMfEK2V7muD2uqi28LBXsC/vY2E/r6FRxAp7BS1OZccFK224NnK > xI+ETnMsl/ZaWIOKhyJk44bWODWr6ij1Gxen3UoEIsU90akFmzCuCEdbdgf0lATr > wX71rVUi5O/ytHQZ/YfhOtc2j7qbrnfSc7KZcgr7X7IkhexP3/nVKtuziqdrbL4U > i7pVh5xlgyTszEyowyKWIjr0+J98Llbdz0Xs1hTOTwEONW4cx7TsUd05cwdmoc4G > KLabfuUTYKp4NslfIV4smBIl2uzrYUaz0ACjLQSrzk4dNGZAj0L6IlyS92g211Pl > WEIrV0m+zIhv6K1ffWiS > =3DVUnT > -----END PGP SIGNATURE----- > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Thu Dec 5 09:53:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2E21AE0C9 for ; Thu, 5 Dec 2013 09:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frsEpxAdXCbC for ; Thu, 5 Dec 2013 09:53:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E608D1A1F66 for ; Thu, 5 Dec 2013 09:53:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D13582AB126; Thu, 5 Dec 2013 17:53:14 +0000 (UTC) Date: Thu, 5 Dec 2013 17:53:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131205175314.GH761@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:53:23 -0000 The sample size of responses seems too small to reach a meaningful consensus. Perhaps posting something a bit more controversial will get the silent majority to speak up. :-) To wit: - Assign explanatory names only to usages 2 and 3: 2 - TRUST-ANCHOR 3 - END-ENTITY - Since usages 0/1 merely complicate DANE implementation without[*] enhancing security, they can remain anonymous, or be given names that clearly indicate that these are discouraged/deprecated. 0 - SECURITY-THEATRE-0 1 - SECURITY-THEATRE-1 This would remove all confusion about the DANE usages. If someone can justify the existence of 0 and 1 in a pair of pithy acronyms then those are the names. Otherwise, out they go! [ I have begun design/implementation of general-purpose DANE support for OpenSSL. Supporting all four usages is rather more complex than one might imagine, and is largely wasted effort, but the protocol requires 0/1 for now, so I have no choice. I would be thrilled to bits were the above to be taken seriously, and usages 0/1 dropped from DANE TLSA in a future revision of the protocol. ] -- Viktor. * If DNSSEC *is not* compromised, 2/3 are sufficient. If DNSSEC *is* compromised, the attacker will publish 2/3, thus a domain owner's use of 0/1 offers no protection against DNS attacks. There will be no measurable deployment of out-of-band mechanisms that harden 0/1 or application protocols that implement DANE, with just usages 0 and 1. From oej@edvina.net Fri Dec 6 06:22:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1501AE39A for ; Fri, 6 Dec 2013 06:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8Bq6QDWZnC9 for ; Fri, 6 Dec 2013 06:22:01 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 746681ADFE5 for ; Fri, 6 Dec 2013 06:22:00 -0800 (PST) Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 56F7093C2A1; Fri, 6 Dec 2013 14:21:56 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Dec 2013 15:21:55 +0100 Message-Id: To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [dane] SIP and Dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Dec 2013 14:22:03 -0000 Hi! Earlier this year I published this draft about SIP and Dane: http://tools.ietf.org/html/draft-johansson-dane-sip-00 I know it is not something for this wg, but I've received almost null = feedback from the dispatch wg in the RAI area and I rather not drop = this, as I think it would be good for SIP to move forward with DANE. Any advice or hints on what to do in order to get some progress? Have a good weekend! /O= From stpeter@stpeter.im Fri Dec 6 11:53:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEB01ACCDA for ; Fri, 6 Dec 2013 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OorL40yDaWj for ; Fri, 6 Dec 2013 11:53:26 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 777B01AE133 for ; Fri, 6 Dec 2013 11:53:26 -0800 (PST) Received: from sjc-vpn7-1962.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EEFDC40332; Fri, 6 Dec 2013 12:53:21 -0700 (MST) Message-ID: <52A22B30.2040508@stpeter.im> Date: Fri, 06 Dec 2013 12:53:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Olle E. Johansson" , "dane@ietf.org list" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] SIP and Dane X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Dec 2013 19:53:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/6/13 7:21 AM, Olle E. Johansson wrote: > Hi! > > Earlier this year I published this draft about SIP and Dane: > http://tools.ietf.org/html/draft-johansson-dane-sip-00 > > I know it is not something for this wg, but I've received almost > null feedback from the dispatch wg in the RAI area and I rather not > drop this, as I think it would be good for SIP to move forward with > DANE. > > Any advice or hints on what to do in order to get some progress? Hej Olle, I agree that defining this usage would be good. Matt Miller and I have been doing the same for XMPP, and we'll also be updating the dane-srv I-D soon. I'll add your I-D to my list of documents to review. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoiswAAoJEOoGpJErxa2pG4wP/2pQG7WdK7XogI2COkWSuvqT OTyk1scO3yVdcyyjH4G+lqWAWA+85jRIXT6/Xqlo4yU85KMqWBvikZhDUMYRCewm 94Ezk71g1YfSCPk1BTWWk5n7isbfrJuabV9xvUaHAykYDL5RU2Omvo3XvNj6ZGov u2W7kE/4oeMLVPt8rXdSZemKjoLK3utlh9bzXweiaY+EyRd0LW9VXBfpsBm8np+P r8DcGllLKApoz0KQrfherNcvSUH9dw1p8FSQgqZFghTDB1Dji6R7LG5s41zhdCgC Bd+h1xToNunI0JyErWb9tJ6fgnRKBEjHse1aXbW7353N2UAQ7xutY/tBzao9ofBg iCsfL+xnD464FIK6aw3WbrrvZt5rDN7Ljy+wsw86TB0kkm8xiHqNjtPND6WdVToX 8ry7K300Nv2kjo+piMWPDIMi+wKoiQx80ceejo2feMjzzQMHtTLWcZEdJF1KgYZj q3bJcue8pBbNhYr0Jmd+UVlR9iihmeRzZ2IgguovpMEVxeXwEtohiPrI8aL2nL4v b2usXK7GIRbgWFhydLy+jXpR/zMgGA7IkEIx/L2Vh7OlqsUY1BTD9c+AlVLKWi3s rTPAXmC8jWeKJDez/0iI0Au2Ec1cAU3mt5kRDFj6Sw+XZ9Pxz7VezBFSZyTqrr9b xIykS+MhloK/ESG+bOcp =YZb5 -----END PGP SIGNATURE----- From warren@kumari.net Fri Dec 6 12:00:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3491AE3BD for ; Fri, 6 Dec 2013 12:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfNHvzfLFwxO for ; Fri, 6 Dec 2013 12:00:22 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1C1AE3C1 for ; Fri, 6 Dec 2013 12:00:22 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id 98C6B1B404A4; Fri, 6 Dec 2013 15:00:18 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Warren Kumari In-Reply-To: <20131205175314.GH761@mournblade.imrryr.org> Date: Fri, 6 Dec 2013 15:00:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131205175314.GH761@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1816) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Dec 2013 20:00:26 -0000 On Dec 5, 2013, at 12:53 PM, Viktor Dukhovni = wrote: >=20 > The sample size of responses seems too small to reach a meaningful > consensus. Unfortunately both to small, and not all in agreement. I=92m going to extend this LC to Wednesday and suggest that, if we don=92t= get consensus on this we simply stick with what is in the current = (draft-ietf-dane-registry-acronyms-02) document. We don=92t need these names / acronyms to be perfect, simply clearer / = easier to remember than the ordinals. Any (strong) objections? W >=20 > Perhaps posting something a bit more controversial will get the > silent majority to speak up. :-) To wit: >=20 > - Assign explanatory names only to usages 2 and 3: >=20 > 2 - TRUST-ANCHOR > 3 - END-ENTITY >=20 > - Since usages 0/1 merely complicate DANE implementation without[*] > enhancing security, they can remain anonymous, or be given names > that clearly indicate that these are discouraged/deprecated. >=20 > 0 - SECURITY-THEATRE-0 > 1 - SECURITY-THEATRE-1 >=20 > This would remove all confusion about the DANE usages. If someone > can justify the existence of 0 and 1 in a pair of pithy acronyms > then those are the names. Otherwise, out they go! >=20 > [ I have begun design/implementation of general-purpose DANE support > for OpenSSL. Supporting all four usages is rather more complex > than one might imagine, and is largely wasted effort, but the > protocol requires 0/1 for now, so I have no choice. I would be > thrilled to bits were the above to be taken seriously, and usages > 0/1 dropped from DANE TLSA in a future revision of the protocol. ] >=20 > --=20 > Viktor. >=20 > * If DNSSEC *is not* compromised, 2/3 are sufficient. >=20 > If DNSSEC *is* compromised, the attacker will publish 2/3, thus > a domain owner's use of 0/1 offers no protection against DNS = attacks. >=20 > There will be no measurable deployment of out-of-band mechanisms > that harden 0/1 or application protocols that implement DANE, with > just usages 0 and 1. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 Eagles soar but a weasel will never get sucked into a jet engine=20 From stpeter@stpeter.im Fri Dec 6 12:40:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7131AE3CE for ; Fri, 6 Dec 2013 12:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.49 X-Spam-Level: X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4woZ4quBEJD for ; Fri, 6 Dec 2013 12:40:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF961AE3CC for ; Fri, 6 Dec 2013 12:40:55 -0800 (PST) Received: from sjc-vpn7-1962.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 283B240332; Fri, 6 Dec 2013 13:40:51 -0700 (MST) Message-ID: <52A23651.4000504@stpeter.im> Date: Fri, 06 Dec 2013 13:40:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Olafur Gudmundsson References: <529E7488.80601@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dane@ietf.org list" Subject: Re: [dane] terminology question X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 06 Dec 2013 20:40:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Olafur, thanks for the reply. Comments inline. On 12/4/13 6:47 AM, Olafur Gudmundsson wrote: > > On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre > wrote: > > In RFC 6125, Jeff Hodges and I tried hard to define some > terminology related to certificate checking in TLS. That > terminology might not be ideal, but I'd like to see if we can > align draft-ogud-dane-vocabulary with the RFC 6125 terms. > > In particular, RFC 6125 uses the term "source domain" to refer to > the fully qualified domain name that a TLS client expects to find > in the certificate (or, in DANE, potentially the key) that is > presented by the TLS server. RFC 6125 also uses the term "derived > domain" to refer to a domain name (or host name) that the client > has derived from the source domain in an automated fashion (e.g., > via a DNS SRV record). > > As far as I can determine, draft-ogud-dane-vocabulary uses the > terms "Query [Name]" and "Final [Name]" for something like "source > domain" and "derived domain". However, draft-ogud-dane-vocabulary > also uses the terms "Service Specification Records" and "Service > Address Records" in a way that might be similar, although I confess > that I don't really grok draft-ogud-dane-vocabulary in fullness and > the latter two terms are unclear to me. > >> Peter, > >> Thanks asking this question, > >> You made me read RFC6125 and to my horror the vocabulary there >> is attempting similar things as I'm doing in my draft, but in >> section 1.8 I realized that you might have taken a shortcut that >> leads to a incomplete specification i.e. you are not taking into >> account the effects of CNAME and DNAME records on the resolution, >> in particular DNAME requires careful rules as to the names used >> to present to the servers. (my guess is this is where the "i >> don't really grok" comment comes from) (I think NAPTR has >> similar effects). You are right, we did not address CNAME, DNAME, or NAPTR. The spec was already convoluted enough. :-) But I think that was an oversight on our part. I've bcc'd Jeff so he's aware of it. >> "Source domain" definition is a good example of this. In >> -vocabulary- draft the application issues query for "query name" Which, I take it, is roughly equivalent to "Name" in RFC 2782, right? >> where it is expecting to find the "Service Specification >> Records". I'm not clear on exactly what those are. Perhaps a few (clearer?) examples would help. The current examples confuse me: Protocols have different ways to provide information about where servers are located. Web servers are frequently specified by name i.e. the "www" prefix. Email servers have a special RR type (MX), Jabber uses SR records, ENUM uses NAPTR records etc. and there are also protocols that use a combination like S-NAPTR a schema where NAPTR records are used to specify where to look for SRV records. For all practical purposes NAPTR + SRV should combined be treated as the Service Specification. Does this mean that "www" is a Service Specification Record? ;-) It makes sense to me that, say, the result of an MX or SRV query is a "Service Specification Record" -- a query for _Service._Proto.Name gives you one or more addresses that together specify the service. For example: $ dig +short -t SRV _xmpp-server._tcp.google.com 5 0 5269 xmpp-server.l.google.com. 20 0 5269 alt3.xmpp-server.l.google.com. 20 0 5269 alt2.xmpp-server.l.google.com. 20 0 5269 alt1.xmpp-server.l.google.com. 20 0 5269 alt4.xmpp-server.l.google.com. Is that what you have in mind? >> but DNAME/NAPTER/CNAME rules may rewrite the name sent to >> application server to the "resulting name" from the query Understood. >> thus the term "Offered Name". Offered by whom? >> For HTTP Service Specification Records == Service Address >> records i.e. address record is the service specification, I assume that's because no MX, SRV, etc. is used for HTTP? >> but Jabber uses SRV records for the Service Specification >> Records and the Service Address Records are associated with the >> servers listed in the SRV RRset. What does "associated with" mean here? I find the definition of "Service Address Records" confusing, too: This is where the address records used by the servers reside, specifications SHOULD NOT make a difference between what kind of address records are used. I am not sure what you mean when you talk about location here, i.e., the place where the address records reside. What kind of location are we talking about? >> To a large extent I think the differences we see are due to the >> different approaches, i.e. you are attempting to word rules for >> existing applications. Yes. Plus I don't have a pair of DNS glasses that enables me to see things the way you do. >> I'm defining rules that are general and ignore the names >> existing applications have used an concentrate on concepts that >> then can be used by application specifications. I wanted to >> create definitions that allow minimal DNS related text inside a >> DANE application specification (not sure I'm there yet). Yes, I can see that's what you're doing. However, I find the level of abstraction you've reached to be a bit rarified. At least, it's not grounded in things that I can grasp easily (application space). But that's perhaps my problem, not yours. :-) > Naming is hard, and I hope we can get it right. > > >> Naming of concepts is hard, definitions are hard, understanding >> the nuances of interaction of multiple protocols is even harder >> :-) Indeed. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSojZQAAoJEOoGpJErxa2p0h0P/3fOSLCMyKc2Z4yxQkEtCXf+ xRtPDIhpbpdTmrYPzg8t73HN5gPYYlKKiWknmT4W+k75Gq6OGh7vZSLU+nxD3Tp+ iC42LqEeknpR7SOcWRCmPOloTTJY33E31dQy+K8Dc3/ehzrvtC+Cp7uus5ZbjESS jU3Bzp9ou/q48ALrskDuiIJa8+GXKsOyjSLKv4NZxWnSa8+9yt+xNxGZNlsU4p5M kYXpGPcM4FOhxkb9y35uvLzKciqNE+/NLDc/bat9cMLhwHsEbOQOdaJJhnROb8XD hzvuMhCOJtQdrm1dFBz3oJFqB7/VH/vRoipBzLgBnrR4eprDmljCXVKHvF4EBP47 xxruB9Vz3jWUJ+Bu+XcRaGdYutbmdm/DaylwZoKaLCXqD8hyCtdkcdSMLA7XlpCr ZZyfB3wzVOMSWSD/numW5TZxRAwMTaDQSvHZOg9qzRf+JVMaZviH91U4iTY7xAGU s9Y0+8HEpJ+Jvs7CdcR+DssEGGtBMA/VCijjAP9wvZibJBjzBuysWrsBT6Jt8eHd Iatffaggul5KAgQeup4NrURUUo4BzgYt/ND2oTocwvPVeeqMUJrWgKC597iWKwdh 4DcIPcmcXCmLG7m0eDnRaUAOacqA0eItQkwK+0hy47k+QMYGfGqw2OUWpFnR1BlG GZ7kxLGOJGk3NqcwXYAG =CHE4 -----END PGP SIGNATURE----- From viktor1dane@dukhovni.org Fri Dec 6 12:51:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671161AE01A for ; Fri, 6 Dec 2013 12:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FdbGDhR0kzL for ; Fri, 6 Dec 2013 12:51:45 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 501C71AD957 for ; Fri, 6 Dec 2013 12:51:45 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D0E352AABD1; Fri, 6 Dec 2013 20:51:40 +0000 (UTC) Date: Fri, 6 Dec 2013 20:51:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131206205140.GN761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> 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] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:51:47 -0000 On Fri, Dec 06, 2013 at 03:00:17PM -0500, Warren Kumari wrote: > > The sample size of responses seems too small to reach a meaningful > > consensus. > > Unfortunately both too small, and not all in agreement. > > I'm going to extend this LC to Wednesday and suggest that, if we > don't get consensus on this we simply stick with what is in the > current (draft-ietf-dane-registry-acronyms-02) document. I think the main audience for the short names is server administrators too busy to read RFCs. Until I joined this group, I'd never seen the terms "EE" and "TA" and had only a vague notion of what "PKIX" was about. Rather, I had a decent working knowledge of root, intermediate and leaf certificates and public keys. So if I rewind the clock back 8 months, to where I knew nothing about DANE and was not steeped in related IETF TLS slang, I would note that none of the components of the proposed acronyms will connect to concepts familar to system administrators deploying DANE. To make the acronyms less confusing than the numbers, we need to use words people already understand: 0 - LIMIT-ISSUER 1 - LIMIT-LEAF 2 - TRUST-CA 3 - FIXED-LEAF These are I think not only more clear, but use more familiar terms. The first two limit (or constrain) the chain to have an acceptable issuer or leaf certificate. The last two specify a trusted CA or a fixed leaf certificate that are sufficient to verify the chain. > We don't need these names / acronyms to be perfect, simply clearer > / easier to remember than the ordinals. > > Any (strong) objections? Returning to the origin acronyms, I for one still prefer PKIX-CA to PKIX-TA, but I won't change my code to do the wrong thing should the final name be misleading. I can't make a similar assurance about server administrators provisioning TLSA recrods. -- Viktor. From gnu@toad.com Sat Dec 7 18:34:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF9C1AE48C for ; Sat, 7 Dec 2013 18:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZFyRg9UsQhC for ; Sat, 7 Dec 2013 18:34:45 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 07A891AE0E9 for ; Sat, 7 Dec 2013 18:34: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 rB82YeoW029387; Sat, 7 Dec 2013 18:34:40 -0800 Message-Id: <201312080234.rB82YeoW029387@new.toad.com> To: Warren Kumari In-reply-to: References: <20131205175314.GH761@mournblade.imrryr.org> Comments: In-reply-to Warren Kumari message dated "Fri, 06 Dec 2013 15:00:17 -0500." Date: Sat, 07 Dec 2013 18:34:40 -0800 From: John Gilmore Cc: dane@ietf.org Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2013 02:34:46 -0000 > I’m going to extend this LC to Wednesday and suggest that, if we don’t get consensus on this we simply stick with what is in the current (draft-ietf-dane-registry-acronyms-02) document. ... > Any (strong) objections? Yes, I object. If there is no consensus on acronyms, we should stick with what is in the current RFC 6698, rather than forwarding an acronym proposal for adoption as a standard, even though we can't agree on what it should say. It's unnecessary, which probably explains the paucity of responses, and divisive among those who did respond. It should be abandoned. John From viktor1dane@dukhovni.org Sun Dec 8 15:53:23 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA161AE17D for ; Sun, 8 Dec 2013 15:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqNOx3WdJMEJ for ; Sun, 8 Dec 2013 15:53:22 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6A1AE11A for ; Sun, 8 Dec 2013 15:53:21 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0C63A2AABD1; Sun, 8 Dec 2013 23:53:16 +0000 (UTC) Date: Sun, 8 Dec 2013 23:53:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131208235315.GU761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201312080234.rB82YeoW029387@new.toad.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 23:53:23 -0000 On Sat, Dec 07, 2013 at 06:34:40PM -0800, John Gilmore wrote: > > Any (strong) objections? > > Yes, I object. If there is no consensus on acronyms, we should stick > with what is in the current RFC 6698, rather than forwarding an > acronym proposal for adoption as a standard, even though we can't > agree on what it should say. It's unnecessary, which probably > explains the paucity of responses, and divisive among those who did > respond. It should be abandoned. Perhaps the author is willing to take a look at the history of the thread, and propose one final set of names for the 4 usages that makes most sense to him. We can then object or concur with those without (yet again) proposing changes. I am not fundamentally opposed to human-readable TLSA RRs: ; _25._tcp.mx.example.com. IN TLSA 3 1 2 _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[ ; _25._tcp.mx.example.com. IN TLSA 2 0 2 _25._tcp.mx.example.com. IN TLSA TRUSTED-CA CERTIFICATE SHA2-512 {blob} ; _25._tcp.mx.example.com. IN TLSA 1 0 1 _25._tcp.mx.example.com. IN TLSA VALID-LEAF PUBLIC-KEY SHA2-256 {blob} ; _25._tcp.mx.example.com. IN TLSA 0 1 0 _25._tcp.mx.example.com. IN TLSA VALID-CA PUBLIC-KEY VALUE {blob} As much possible, the acronyms should avoid jargon unfamiliar to their intended audience and in a full TLSA record should ideally read like a complete sentence, as above. The dichotomy between "TRUSTED" (sufficient on its own) and "VALID" (not sufficient without external trust) is I think one reasonable way to communicate the usage values. Anyway, I think it is up to the author to propose a final revision, or as John suggests, give up. -- Viktor. From marka@isc.org Sun Dec 8 17:10:08 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAA11AE18C for ; Sun, 8 Dec 2013 17:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWup89S3TYLI for ; Sun, 8 Dec 2013 17:10:06 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1F1AE18B for ; Sun, 8 Dec 2013 17:10:06 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id EE6452383C6 for ; Mon, 9 Dec 2013 01:09:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B0A2D160446 for ; Mon, 9 Dec 2013 01:17:55 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8F409160436 for ; Mon, 9 Dec 2013 01:17:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5AA2FB5C445 for ; Mon, 9 Dec 2013 12:09:45 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131208235315.GU761@mournblade.imrryr.org> In-reply-to: Your message of "Sun, 08 Dec 2013 23:53:15 -0000." <20131208235315.GU761@mournblade.imrryr.org> Date: Mon, 09 Dec 2013 12:09:44 +1100 Message-Id: <20131209010945.5AA2FB5C445@rock.dv.isc.org> Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2013 01:10:08 -0000 In message <20131208235315.GU761@mournblade.imrryr.org>, Viktor Dukhovni writes : > On Sat, Dec 07, 2013 at 06:34:40PM -0800, John Gilmore wrote: > > > > Any (strong) objections? > > > > Yes, I object. If there is no consensus on acronyms, we should stick > > with what is in the current RFC 6698, rather than forwarding an > > acronym proposal for adoption as a standard, even though we can't > > agree on what it should say. It's unnecessary, which probably > > explains the paucity of responses, and divisive among those who did > > respond. It should be abandoned. > > Perhaps the author is willing to take a look at the history of the > thread, and propose one final set of names for the 4 usages that > makes most sense to him. We can then object or concur with those > without (yet again) proposing changes. > > I am not fundamentally opposed to human-readable TLSA RRs: > > ; _25._tcp.mx.example.com. IN TLSA 3 1 2 > _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[ If anything other than numeric values appear in the records you will break existing TLSA record parsers. Names are useful when describing thing. They are no useful for portability and definitely break the future proofing in the original presentation format. For DNSKEY we display them as comments after the record. The record itself purely numeric and future proof. e.g. ; <<>> DiG 9.10.0a1 <<>> dnskey . +rrcomments ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7742 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 4753 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ; KSK; alg = RSASHA256; key id = 19036 . 4753 IN DNSKEY 256 3 8 AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33 4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V ; ZSK; alg = RSASHA256; key id = 59085 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Dec 09 11:52:43 EST 2013 ;; MSG SIZE rcvd: 450 TLSA, like DNSKEY, will need tools to take certs etc. and generate TLSA records. Those tools can use names but they emit records in numeric form. > ; _25._tcp.mx.example.com. IN TLSA 2 0 2 > _25._tcp.mx.example.com. IN TLSA TRUSTED-CA CERTIFICATE SHA2-512 {blob} > > ; _25._tcp.mx.example.com. IN TLSA 1 0 1 > _25._tcp.mx.example.com. IN TLSA VALID-LEAF PUBLIC-KEY SHA2-256 {blob} > > ; _25._tcp.mx.example.com. IN TLSA 0 1 0 > _25._tcp.mx.example.com. IN TLSA VALID-CA PUBLIC-KEY VALUE {blob} > > As much possible, the acronyms should avoid jargon unfamiliar to > their intended audience and in a full TLSA record should ideally > read like a complete sentence, as above. > > The dichotomy between "TRUSTED" (sufficient on its own) and "VALID" > (not sufficient without external trust) is I think one reasonable > way to communicate the usage values. > > Anyway, I think it is up to the author to propose a final revision, > or as John suggests, give up. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From viktor1dane@dukhovni.org Sun Dec 8 17:32:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7D1AE19B for ; Sun, 8 Dec 2013 17:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_afvHWp_bm5 for ; Sun, 8 Dec 2013 17:32:27 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id D14C21AE198 for ; Sun, 8 Dec 2013 17:32:26 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B91C22AABD1; Mon, 9 Dec 2013 01:32:21 +0000 (UTC) Date: Mon, 9 Dec 2013 01:32:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131209013221.GV761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131208235315.GU761@mournblade.imrryr.org> <20131209010945.5AA2FB5C445@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131209010945.5AA2FB5C445@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 01:32:29 -0000 On Mon, Dec 09, 2013 at 12:09:44PM +1100, Mark Andrews wrote: > > I am not fundamentally opposed to human-readable TLSA RRs: > > > > ; _25._tcp.mx.example.com. IN TLSA 3 1 2 > > _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[ > > If anything other than numeric values appear in the records you > will break existing TLSA record parsers. Names are useful when > describing things. ... Thanks, finally I said something wrong enough, to elicit a follow-up! :-) Yes, tools that emit records in canonical form should use numbers. Users may elect to enter mnemonic forms when supported by the target application. Now that you're here, any suggestions for good names, or thoughts on what to do with the draft? > TLSA, like DNSKEY, will need tools to take certs etc. and generate > TLSA records. Those tools can use names but they emit records in > numeric form. A humble example below. -- Viktor. #! /bin/sh extract() { case "$(echo $4 | tr '[A-Z]' '[a-z]')" in 0|cert*) openssl x509 -in "$1" -outform DER;; 1|spki|public*) openssl x509 -in "$1" -noout -pubkey | openssl pkey -pubin -outform DER;; *) error "Invalid selector: $4";; esac } digest() { case "$(echo $5 | tr '[A-Z]' '[a-z]')" in 0|full*) cat;; 1|sha2-256|sha256|sha-256) openssl dgst -sha256 -binary;; 2|sha2-512|sha512|sha-512) openssl dgst -sha512 -binary;; *) error "Invalid matching type: $5";; esac } encode() { perl -e ' ($cert, $hostport, $u, $s, $m) = @ARGV; ($host, $port) = split(":", $hostport); $port ||= 443; $/=undef; ($a=) =~ s/(.)/sprintf("%02X", ord($1))/egs; printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n", $port, $host, $u, $s, $m, $a; ' "$@" } error() { echo "$1" 1>&2; exit 1; } usage() { error "Usage: $0 cert.pem host[:port] usage selector mtype"; } if [ $# -ne 5 ]; then usage; fi case "$(echo $3 | tr '[A-Z]' '[a-z]')" in 0|PKIX-CA|PKIX-TA|VALID-CA) usage=0;; 1|PKIX-EE|VALID-LEAF) usage=1;; 2|DANE-TA|TRUSTED-CA) usage=2;; 3|DANE-EE|TRUSTED-LEAF) usage=3;; *) error "Invalid certificate usage: $3";; esac extract "$@" | digest "$@" | encode "$@" From jakob@kirei.se Sun Dec 8 23:42:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D591ADEB7 for ; Sun, 8 Dec 2013 23:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaSkNkE-8Jfy for ; Sun, 8 Dec 2013 23:42:46 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2C51ADEA7 for ; Sun, 8 Dec 2013 23:42:45 -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=m0Ns/CfHJOxwZRooGxel5E/U0QcOsahIjUsIT0zfduE=; b=dIcCBJtTwZJAFgPLTYagIW9d1IJ4DYRzNGC5fd6/LLEccSs1OIDiIo/RKFfoPaRQ0HYJ69bScsN9u 6MkO63Vh17Lftj8FPpHC2c293mYoJJlsJM2ZuT1htGA5iokxQOf7F+jf5m0gFHmHqkJnxhOvIfan7M M4kPKFR2DODl8wsw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Mon, 9 Dec 2013 08:42:39 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Jakob Schlyter In-Reply-To: <20131208235315.GU761@mournblade.imrryr.org> Date: Mon, 9 Dec 2013 08:42:37 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131208235315.GU761@mournblade.imrryr.org> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1822) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2013 07:42:48 -0000 On 9 dec 2013, at 00:53, Viktor Dukhovni wrote: > Anyway, I think it is up to the author to propose a final revision, > or as John suggests, give up. +1 jakob From cloos@jhcloos.com Mon Dec 9 13:56:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00661AE57C for ; Mon, 9 Dec 2013 13:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr4_7qaWDG6F for ; Mon, 9 Dec 2013 13:56:51 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id E8D521AE5BB for ; Mon, 9 Dec 2013 13:56:50 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 227391DFB2; Mon, 9 Dec 2013 21:56:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1386626206; bh=hWoZvxxPXf/8so0DJ+TLYO+2fhNzMboj5pfD2ub7ByI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Y/uGcr507eQBKiMdFDGMv/Cun064o2Un5CpiQITM9dGoJu2PqZHwnDAU2IWyacfl3 VNdXw8fF0UjLuX5/UHSdGoWG6ATX+JKeldcv2P4ThLZx6Q6Ofi3Xym1PsneXdhYLhU dkTTjZ32NJahF//t0dNT6pywbjTpiE5M2ZwoUYF9O4A== Received: by carbon.jhcloos.org (Postfix, from userid 500) id DBEB460027; Mon, 9 Dec 2013 21:50:43 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <201312080234.rB82YeoW029387@new.toad.com> (John Gilmore's message of "Sat, 07 Dec 2013 18:34:40 -0800") References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 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, 09 Dec 2013 16:50:43 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:131209:dane@ietf.org::67MXi8N6Z7wB5fkt:000c4EYl X-Hashcash: 1:30:131209:warren@kumari.net::etwZ9lTJmxa1GKYz:0000000000000000000000000000000000000000000PaWKb X-Hashcash: 1:30:131209:gnu@toad.com::RpcOg4M2hfNj5pSV:0000t0TQY Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2013 21:56:51 -0000 Since I've posted wrt this draft, I feel compelled to add that I encouraged symmetry, iff names are used, because I do not expect that anyone will remember them otherwise. With emphasis on "iff". There is no value in names if one has to look them up; in that case numbers are at least as useful. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Mon Dec 9 15:19:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BA1ADEAE for ; Mon, 9 Dec 2013 15:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XamoJmX5reTt for ; Mon, 9 Dec 2013 15:19:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BC62D1ADEA0 for ; Mon, 9 Dec 2013 15:19:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1B4692AB183; Mon, 9 Dec 2013 23:19:19 +0000 (UTC) Date: Mon, 9 Dec 2013 23:19:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131209231919.GY761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> 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] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 23:19:27 -0000 On Mon, Dec 09, 2013 at 04:50:43PM -0500, James Cloos wrote: > Since I've posted wrt this draft, I feel compelled to add that I > encouraged symmetry, iff names are used, because I do not expect > that anyone will remember them otherwise. What do you mean by symmetry? If you mean that the names for 0/1 should each differ in the same way from 2/3 respectively, then this requires names that fail to distinguish between a vanilla CA (in usage 0) and a trust-anchor (in usage 2). Is such "symmetry" more important than semantic fidelity? [ Usages 0/1 are a blunder, we're continuing to pay the cost of this blunder. ] > There is no value in names if one has to look them up; in that > case numbers are at least as useful. Are the names in your view primary intended as alternative input forms, or (perhaps as comments) in display forms of RRs? -- Viktor. From jakob@kirei.se Mon Dec 9 23:12:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915891ADBCF for ; Mon, 9 Dec 2013 23:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skaIit8QozUW for ; Mon, 9 Dec 2013 23:12:54 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id AA13C1AE1F5 for ; Mon, 9 Dec 2013 23:12:53 -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=m215+2Guns+06+sYGpMesujPbmIjtsNFWU43fSibZPE=; b=cIZ2izjxbeUSjvhumvuRlfqErFEEezzS71bLU9K370VdmkqfmMVXBkvSXqgjeh4fh5ok4EqUuQQjO yzXATjZR85Mub37VvRf48wcTbwpPvChDYgLDZOC/d1sw6BamK/tq/gLG6N6uZcxBY2NEV4Tll3zjBN wLBcGQS+rSyTNw/A= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Tue, 10 Dec 2013 08:12:46 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Jakob Schlyter In-Reply-To: <20131209231919.GY761@mournblade.imrryr.org> Date: Tue, 10 Dec 2013 08:12:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1822) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 07:12:55 -0000 On 10 dec 2013, at 00:19, Viktor Dukhovni = wrote: > [ Usages 0/1 are a blunder, we're continuing to pay the cost of > this blunder. ] As the author of 6698, I don't agree and believe 0/1 are still useful as = an additional layer of security for traditional PKIX. The world is not = always black and white. jakob From viktor1dane@dukhovni.org Mon Dec 9 23:34:10 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A81ADEA1 for ; Mon, 9 Dec 2013 23:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxp9PE7RNX1T for ; Mon, 9 Dec 2013 23:34:08 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 91AB21ADDAF for ; Mon, 9 Dec 2013 23:34:08 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 22CF52AB174; Tue, 10 Dec 2013 07:34:03 +0000 (UTC) Date: Tue, 10 Dec 2013 07:34:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131210073402.GA761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 07:34:10 -0000 On Tue, Dec 10, 2013 at 08:12:42AM +0100, Jakob Schlyter wrote: > > [ Usages 0/1 are a blunder, we're continuing to pay the cost of > > this blunder. ] > > As the author of 6698, I don't agree and believe 0/1 are still > useful as an additional layer of security for traditional PKIX. You left out the word "theatre" after "security". :-) I guess time will tell whether the definition of 0/1 in 6698 is in fact pointless complexity. The critical thing now is to drive DNSSEC adoption, so that DANE becomes viable (or perhaps adoption of both in parallel, if DANE is the carrot for DNSSEC adoption). In the mean-time, I have a working, and plausibly correct, be it not yet extensively tested, general purpose DANE interface for OpenSSL. It fully supports all the DANE usages (including the theatrical ones). It even supports out-of-band "2 x 0" certificates and keys and certificates even when these are not in the peer's TLS chain. Let's hope that support for DANE verification with OpenSSL will encourage broader application support for DANE. With a bit of luck, someone from the OpenSSL team will volunteer to work with me to integrate the code into the development tree. This took just over 1200 lines of commented code. It should work with OpenSSL 0.9.8 or newer. A very recent insight made it possible to remove the need for signing operations and generation of internal private keys in the verifier, so it is now about as simple as it can get. The usage 2 implementation is radically different from all the other cases, and accounts for the bulk of the code. This is why I am not comfortable with language that suggests that the difference between 0 and 2 is just like that between 1 and 3. This is very far from the truth. -- Viktor. From benl@google.com Tue Dec 10 03:21:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32601AD8F5 for ; Tue, 10 Dec 2013 03:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz1RZrcH9JZs for ; Tue, 10 Dec 2013 03:21:23 -0800 (PST) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CB9031AD7C0 for ; Tue, 10 Dec 2013 03:21:22 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so4624453veb.21 for ; Tue, 10 Dec 2013 03:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YbLkhrTUKh999tgne2/TRdC0AHcrhPG2p/9pYxj/qXU=; b=HIykQPYN798q7x2eGVyB1a8b/v9J8fv6/MGlOaohXVt5cjij7loTKtAXQLoRaj+YXA DNRsnZiFKaDTCKs4JKNSt5HiXSDdg8BV3yUDysJIwn2Z4EFqMOTFIfJ4omLv77a00EGu pwfemj6TSA8aF5sXLjTVCv6+z57V4ebusIO5+OzurA5jxmMHhkB2wcYZDbUenMrJt/PS WyMsSweNp/UTwgPtlJBR6OrnLZ+la4H/scuwkY+r9+s5kWaeKRpaVoX7NP6POosrFE+s 0oc9WJ01SWCO4x8LEio8qiVC9AhBX/UaVaDzWCLQVFiTVULIH0zKFd8l4GNA6DEVIXfa ba5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YbLkhrTUKh999tgne2/TRdC0AHcrhPG2p/9pYxj/qXU=; b=cjBdojhwsh9m0hlAqYL4GCI9Fyfi+Hrr+uAcYwdQ1LFSpcOyjEG79c9+rfCPLZsy9t ubPmcAlRgZRNDdnIiqlCv4RNw6yPTX7jW5ibm300fZaoT+iWT3l2YkS/egRdgFRwaPYn jAsenWYfR7sKENcjkF032Z/4Ij8ZXKM/bJFlqowR7XyijQGd4gawYAr+wqwPabb/VQT5 z5NwVrQHj6zs0D5XvZ2TfganYOfJEYpyGlePLSv6HxOsb6mXo+5DIQSyDcdeAmeoO4SY 3+gBOFyGRYm1EIfaDjTwv3qktwbNszepijChNuJ09T5hdg+zJ0fxqMCrvx8QTUxNS6lo sCnw== X-Gm-Message-State: ALoCoQlTOQS62FseVH1UxOHXajxSFjg5/N6I23ZsraRoCuRYpJXg27meZUs2FwLhE+UXV0NwOsTY4PH+VgLxExXQ5to0Wivf4ovzcMyAg3rex4sD/LDasLdaDgcpDC/Hjx3+ch6o8BXbqh8/EN6TKZGIMk2WaLty0+xDORF7Hd38f8aQm4aZjztImaHwAEP2O7x/NeqInJzV MIME-Version: 1.0 X-Received: by 10.52.165.240 with SMTP id zb16mr11129877vdb.19.1386674477390; Tue, 10 Dec 2013 03:21:17 -0800 (PST) Received: by 10.52.183.65 with HTTP; Tue, 10 Dec 2013 03:21:17 -0800 (PST) In-Reply-To: <20131210073402.GA761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> Date: Tue, 10 Dec 2013 11:21:17 +0000 Message-ID: From: Ben Laurie To: IETF DANE WG list Content-Type: multipart/alternative; boundary=001a11c24e80a4f25204ed2c4fd3 Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 11:21:24 -0000 --001a11c24e80a4f25204ed2c4fd3 Content-Type: text/plain; charset=ISO-8859-1 On 10 December 2013 07:34, Viktor Dukhovni wrote: > On Tue, Dec 10, 2013 at 08:12:42AM +0100, Jakob Schlyter wrote: > > > > [ Usages 0/1 are a blunder, we're continuing to pay the cost of > > > this blunder. ] > > > > As the author of 6698, I don't agree and believe 0/1 are still > > useful as an additional layer of security for traditional PKIX. > > You left out the word "theatre" after "security". :-) I guess time > will tell whether the definition of 0/1 in 6698 is in fact pointless > complexity. The critical thing now is to drive DNSSEC adoption, > so that DANE becomes viable (or perhaps adoption of both in parallel, > if DANE is the carrot for DNSSEC adoption). > > In the mean-time, I have a working, and plausibly correct, be it > not yet extensively tested, general purpose DANE interface for > OpenSSL. It fully supports all the DANE usages (including the > theatrical ones). It even supports out-of-band "2 x 0" certificates > and keys and certificates even when these are not in the peer's > TLS chain. > > Let's hope that support for DANE verification with OpenSSL will > encourage broader application support for DANE. With a bit of > luck, someone from the OpenSSL team will volunteer to work with me > to integrate the code into the development tree. > I'm willing to consider it. But I'm still concerned that without something akin to CT, DANE is more dangerous than the existing PKI. > > This took just over 1200 lines of commented code. It should work > with OpenSSL 0.9.8 or newer. A very recent insight made it possible > to remove the need for signing operations and generation of internal > private keys in the verifier, so it is now about as simple as it > can get. > 0.9.8 is closed to new functionality, as are some of the more recent branches. > > The usage 2 implementation is radically different from all the > other cases, and accounts for the bulk of the code. This is why > I am not comfortable with language that suggests that the difference > between 0 and 2 is just like that between 1 and 3. This is very > far from the truth. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a11c24e80a4f25204ed2c4fd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 10 December 2013 07:34, Viktor Dukhovni <viktor1dane@duk= hovni.org> wrote:
On Tue, Dec 10, 2013 at 08= :12:42AM +0100, Jakob Schlyter wrote:

> > [ Usages 0/1 are a blunder, we're continuing to pay the cost = of
> > =A0this blunder. ]
>
> As the author of 6698, I don't agree and believe 0/1 are still
> useful as an additional layer of security for traditional PKIX.

You left out the word "theatre" after "security".= :-) =A0I guess time
will tell whether the definition of 0/1 in 6698 is in fact pointless
complexity. =A0The critical thing now is to drive DNSSEC adoption,
so that DANE becomes viable (or perhaps adoption of both in parallel,
if DANE is the carrot for DNSSEC adoption).

In the mean-time, I have a working, and plausibly correct, be it
not yet extensively tested, general purpose DANE interface for
OpenSSL. =A0It fully supports all the DANE usages (including the
theatrical ones). =A0It even supports out-of-band "2 x 0" certifi= cates
and keys and certificates even when these are not in the peer's
TLS chain.

Let's hope that support for DANE verification with OpenSSL will
encourage broader application support for DANE. =A0With a bit of
luck, someone from the OpenSSL team will volunteer to work with me
to integrate the code into the development tree.

<= /div>
I'm willing to consider it. But I'm still concerned that = without something akin to CT, DANE is more dangerous than the existing PKI.=
=A0

This took just over 1200 lines of commented code. =A0It should work
with OpenSSL 0.9.8 or newer. =A0A very recent insight made it possible
to remove the need for signing operations and generation of internal
private keys in the verifier, so it is now about as simple as it
can get.

0.9.8 is closed to new functio= nality, as are some of the more recent branches.
=A0

The usage 2 implementation is radically different from all the
other cases, and accounts for the bulk of the code. =A0This is why
I am not comfortable with language that suggests that the difference
between 0 and 2 is just like that between 1 and 3. =A0This is very
far from the truth.

--
=A0 =A0 =A0 =A0 Viktor.
_____________________= __________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--001a11c24e80a4f25204ed2c4fd3-- From kent@bbn.com Tue Dec 10 07:17:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1597A1AE0CF for ; Tue, 10 Dec 2013 07:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfMAXvjWBHzH for ; Tue, 10 Dec 2013 07:17:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 39EBA1ADF8B for ; Tue, 10 Dec 2013 07:17:14 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51539) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VqP3c-000Mnu-UR for dane@ietf.org; Tue, 10 Dec 2013 10:17:08 -0500 Message-ID: <52A73074.1050904@bbn.com> Date: Tue, 10 Dec 2013 10:17:08 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dane@ietf.org References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 15:17:16 -0000 Ben, > ... > > I'm willing to consider it. But I'm still concerned that without > something akin to CT, DANE is more dangerous than the existing PKI. > Can you elaborate, without reference to CY :-)? DANE seems preferable because the DNS hierarchy constrains the range of names that a node may assert (validly), unlike the WebPKI model. Steve From benl@google.com Tue Dec 10 07:22:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD7A1AE158 for ; Tue, 10 Dec 2013 07:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-6UMmQah3EX for ; Tue, 10 Dec 2013 07:22:18 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AD4231AE157 for ; Tue, 10 Dec 2013 07:22:18 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so4885981veb.19 for ; Tue, 10 Dec 2013 07:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NUQEM/wtE/h7asRGjLDoFS4HdPMZ7PGpvUjjw0YdVwI=; b=Me4hxyUOS2kke5oPauDb8yByYT+xT4Cx3QQhv16BY3C6dSDVr/d0RUxPu0+w99aRZY uYZ6Tzcs0aBix5WkA8Bx95AsG7N+Lq1DRUA//miwmeEETkdby0su/2lOH1W1J7KiPNky O8TEE5B+wbSRqvfbUEO2TB6cEbk3PWjt0Yo/vv3lSK83m88cRCyk+LZkAbCdrt4YJuwy riF3+Anntgn6+sR71ELS3hwaNsjr5fe+yDmBQMxN+0YuGes7NMkxbNLr7Kbn7Tk6Z+Rs J+eUcCz2z69/P3nxzNLmRel7SFLT+VH07nPcFzAFu4W3zTZ5wSgmUKZbzKtG+hho8i2v w6Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NUQEM/wtE/h7asRGjLDoFS4HdPMZ7PGpvUjjw0YdVwI=; b=VuwR4HJPWL9KEKmle4TuCKqKLurasj4jB6F6OXMDEIM/PBdg8PJqYZLzJInsWSRfsp BXrR36vOpn2FmaQzM8tb69su+u4ne8C1Bbc8p1IG1cbnRPwxHUYjM+uDMzZNXXShbVqN Bt0TY5W772nOcYYjxAkwR9nWu4SG/TBeLmo4+hvp9B1yA6KqoVfykQV4z1p24Yj9/dUN fdXCFIHNR+w+dqikhSq/IxJjHnAtEEUgzaPRhfQbpSEe6C+Yv4JYlyyG1O9vEajoZobq KacWf7m/1/RiCfSYl/U8bWh3BZPsqfT2aeBjUV6Y7B558n7EkDoX5MK36MnVuOEH4Eic TFRA== X-Gm-Message-State: ALoCoQnCCY5CZRsPQPgIkwzcxdDG004By/Wf3LvGgwAwHFN/6QG+6/NPuGWEXoB0HW7sfp0mrkLku51oVKakqJMWevciEyqvidCK1Pb/X04k26b9eBggcgNWczi0iGgtBQLCIJxdT74gDoRQszNYF+moyYKSrWWAPucNi99wWzF0z1xVujjt2cQbvr0e9EKL3ogXGIUbVYZO MIME-Version: 1.0 X-Received: by 10.52.78.193 with SMTP id d1mr54089vdx.57.1386688933279; Tue, 10 Dec 2013 07:22:13 -0800 (PST) Received: by 10.52.183.65 with HTTP; Tue, 10 Dec 2013 07:22:13 -0800 (PST) In-Reply-To: <52A73074.1050904@bbn.com> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> <52A73074.1050904@bbn.com> Date: Tue, 10 Dec 2013 15:22:13 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11365c9048506e04ed2fad12 Cc: IETF DANE WG list Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 15:22:21 -0000 --001a11365c9048506e04ed2fad12 Content-Type: text/plain; charset=ISO-8859-1 On 10 December 2013 15:17, Stephen Kent wrote: > Ben, > >> ... >> >> >> I'm willing to consider it. But I'm still concerned that without >> something akin to CT, DANE is more dangerous than the existing PKI. >> >> Can you elaborate, without reference to CY :-)? DANE seems preferable > because the DNS hierarchy constrains the range of names that a node may > assert (validly), unlike the WebPKI model. > I agree that there is this additional constraint. It doesn't really address the core problem, though, which is that registries and registrars, like CAs, are vulnerable to error, coercion and getting pwned. Registries are also in a great position to mount targeted attacks, unlike CAs. Experience suggests that their record, on the whole, is less good than CAs. --001a11365c9048506e04ed2fad12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 10 December 2013 15:17, Stephen Kent <kent@bbn.com> wr= ote:
Ben,
...


I'm willing to consider it. But I'm still concerned that without so= mething akin to CT, DANE is more dangerous than the existing PKI.

Can you elaborate, without reference to CY :-)? DANE seems preferable becau= se the DNS hierarchy constrains the range of names that a node may assert (= validly), unlike the WebPKI model.

I agree that there is this additional constraint. It doesn't really add= ress the core problem, though, which is that registries and registrars, lik= e CAs, are vulnerable to error, coercion and getting pwned. Registries are = also in a great position to mount targeted attacks, unlike CAs.

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

--001a11365c9048506e04ed2fad12-- From warren@kumari.net Tue Dec 10 07:38:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802E01AD7C5 for ; Tue, 10 Dec 2013 07:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1_-wfD8KpVT for ; Tue, 10 Dec 2013 07:37:58 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CBD1ADF98 for ; Tue, 10 Dec 2013 07:37:58 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id 68B6C1B404A7; Tue, 10 Dec 2013 10:37:52 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Dec 2013 10:37:50 -0500 Message-Id: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> To: dane@ietf.org, Stephen Farrell Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 15:38:00 -0000 Dear DANE WG, We (the chairs) have met and discussed this issue with our AD (CCed). We still see there being consensus for the document itself, and have = seen a number of cases and discussions where more memorable names for = the ordinals would have been useful (the at mic discussions in Berlin = spring to mind). So, we are forging ahead with what is in the document (James=92 = suggestions =97 PKIX-TA, DANE-TA, PKIX-EE, DANE-EE) and will be = forwarding this to our AD. We understand that these names are not perfect and do not please = everyone. Despite that, there is sufficient value in the document and we = believe it will aid discussion and (hopefully) deployment. This will = also allow us to move on and discuss things of more substance. If you are still concerned that this document might cause the sky to = fall, mail the list, and our AD will review when doing the AD review. = There is also IETF LC, so we have another chance to discuss this, this = time in a more public setting=85 :-P W -- It is a mistake to think you can solve any major problem just with = potatoes. --Douglas Adams From kent@bbn.com Tue Dec 10 08:23:50 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC8E1AE08E for ; Tue, 10 Dec 2013 08:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olPb5gwUAvD3 for ; Tue, 10 Dec 2013 08:23:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2A31AE07B for ; Tue, 10 Dec 2013 08:23:48 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51663) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VqQ63-000OFS-7D; Tue, 10 Dec 2013 11:23:43 -0500 Message-ID: <52A7400F.4090402@bbn.com> Date: Tue, 10 Dec 2013 11:23:43 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ben Laurie References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> <52A73074.1050904@bbn.com> 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] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 16:23:50 -0000 Ben, Thanks for the clarification. I disagree with the relative merit of the two approaches, but I don't dispute your observations. Steve From warren@kumari.net Tue Dec 10 08:24:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E024C1AE08E for ; Tue, 10 Dec 2013 08:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjTSgymBYB98 for ; Tue, 10 Dec 2013 08:24:02 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A93F1AE07B for ; Tue, 10 Dec 2013 08:24:02 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id EAC821B405C5; Tue, 10 Dec 2013 11:23:55 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Warren Kumari In-Reply-To: Date: Tue, 10 Dec 2013 11:23:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> <52A73074.1050904@bbn.com> To: Ben Laurie X-Mailer: Apple Mail (2.1822) Cc: IETF DANE WG list Subject: Re: [dane] DANE, constrains and CT and similar.... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:24:05 -0000 [ No hats]=20 [ Changed the subject to hopefully more correctly identify the = discussion ]=20 On Dec 10, 2013, at 10:22 AM, Ben Laurie wrote: >=20 >> On 10 December 2013 15:17, Stephen Kent wrote: >>> Ben, >>> ... >>>=20 >>>=20 >>> I'm willing to consider it. But I'm still concerned that without = something akin to CT, DANE is more dangerous than the existing PKI. >>>=20 >> Can you elaborate, without reference to CY :-)? DANE seems preferable = because the DNS hierarchy constrains the range of names that a node may = assert (validly), unlike the WebPKI model. >>=20 > I agree that there is this additional constraint. It doesn't really = address the core problem, though, which is that registries and = registrars, like CAs, are vulnerable to error, coercion and getting = pwned. Registries are also in a great position to mount targeted = attacks, unlike CAs. >=20 So, we had numerous discussions on this topic back at the beginning. At the core of the discussion was the fact that an attacker who is able = to manipulate the DNS can get a CA signed cert (the attacker points the = MX to a box under their control, applies for a DV cert at = www.certs-r-us.com, receives the authentication cookie mail and sends it = back to the CA). This attack doesn=92t allow the attacker to get a cert = that requires special validation, and also doesn=92t work for the = special golden names)=85 When we were having these discussions I think that a number of us had a = somewhat different (and some would say naive) view of the threat = landscape. I personally was more focused on the lone attacker scenario, = and not the "nation state who doesn=92t mind being noticed=94 attack. In many / most cases the ccTLD operator is in country (I believe that = ICANN now requires the cc Admin contact to be in county) and could be = compelled to publish fake DS and NS records for a specific domain and = serve a parallel DNS tree[0]. This would be technically tricky (what = with caching and the difficulty of correctly doing key rolls even which = all parties co-operating), but not impossible. It would (probably) be = fairly noticeable, but this might be acceptable to the attacker. The above is conceptually similar to just seizing the domain (like the = ICE / DHS counterfeit seizures), but with DANE could allow the attacker = to also get a lock icon. Having something like CT but for DANE / DNSSEC would (IMO) be very = useful =97 I believe that there was some activity on this front, any = updates? > Experience suggests that their record, on the whole, is less good than = CAs. >=20 [0]: I=92m using cc=92s as an example here, but the same applies to = gTLDs in the attacking country. P.S: Apologies =97 for some reason my MUA refused to understand Ben=92s = quoting level. I tried to requote correctly but may be misattributing. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- It's a mistake trying to cheer up camels. You might as well drop = meringues into a black hole. -- Terry Prachett From viktor1dane@dukhovni.org Tue Dec 10 10:27:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD51AE171 for ; Tue, 10 Dec 2013 10:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvSmZhEfWQ7E for ; Tue, 10 Dec 2013 10:27:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 36AC31AE052 for ; Tue, 10 Dec 2013 10:27:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E15582AB16E; Tue, 10 Dec 2013 18:27:09 +0000 (UTC) Date: Tue, 10 Dec 2013 18:27:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131210182709.GE761@mournblade.imrryr.org> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> 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: [dane] OpenSSL DANE support... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:27:18 -0000 On Tue, Dec 10, 2013 at 11:21:17AM +0000, Ben Laurie wrote: > > Let's hope that support for DANE verification with OpenSSL will > > encourage broader application support for DANE. With a bit of > > luck, someone from the OpenSSL team will volunteer to work with me > > to integrate the code into the development tree. > > I'm willing to consider it. Thanks. Please drop me a note off list, I'd like to find some mutually convenient time to chat about the design over a voice Google hangout. If you want to look at the code first: https://github.com/vdukhovni/ssl_dane The work-flow is basically: SSL_library_init() SSL_dane_library_init() SSL_CTX_new() SSL_CTX_dane_init() /* DANE connections get a dedicated context */ SSL_new() SSL_dane_init() /* allocate dane state, set SNI, ... */ SSL_dane_add_tlsa() /* Once per record */ SSL_connect() /* off to the races... */ SSL_get_verify_result() /* Learn the outcome */ SSL_dane_cleanup() /* Dispose of DANE state */ You can see this at work in ssl_dane_test.c. It verifies imap.gmail.com, with all the various usages, selectors, digests and relevant certificate depths (and out-of-band TLSA records constructed by pointing the code at a PEM file). > But I'm still concerned that without something > akin to CT, DANE is more dangerous than the existing PKI. [ There is (for various reasons described in the draft) in practice no *existing PKI* for SMTP, so there is at least one use case where we're comparing DANE to *nothing* rather than DANE to existing PKI. ] In any case, the question of the relative merits of DANE in any particular use-case is rather orthogonal to implementation of the requisite library support. The decision to use or not use DANE will happen above the library layer. I should note that my code does not enable DANE by default for any connections, it does not even do any DNS lookups. Rather, I provide an API for the application to explicitly turn on DANE support for a given connection by providing appropriate parameters (including any TLSA RRs the application obtained by other means). > > This took just over 1200 lines of commented code. It should work > > with OpenSSL 0.9.8 or newer. A very recent insight made it possible > > to remove the need for signing operations and generation of internal > > private keys in the verifier, so it is now about as simple as it > > can get. > > > > 0.9.8 is closed to new functionality, as are some of the more recent > branches. I am not changing any existing OpenSSL code, my work is essentially an add-on library, though tighter integration would be appropriate in the future and would allow me to simplify the DANE side. -- Viktor. From viktor1dane@dukhovni.org Tue Dec 10 11:42:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5841AE068 for ; Tue, 10 Dec 2013 11:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax9YAbtx6CoG for ; Tue, 10 Dec 2013 11:42:20 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9892A1ADFF5 for ; Tue, 10 Dec 2013 11:42:20 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6BBDF2AB163; Tue, 10 Dec 2013 19:42:14 +0000 (UTC) Date: Tue, 10 Dec 2013 19:42:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131210194214.GH761@mournblade.imrryr.org> References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:42:22 -0000 On Tue, Dec 10, 2013 at 10:37:50AM -0500, Warren Kumari wrote: > We understand that these names are not perfect and do not please > everyone. Despite that, there is sufficient value in the document > and we believe it will aid discussion and (hopefully) deployment. > This will also allow us to move on and discuss things of more > substance. > > If you are still concerned that this document might cause the > sky to fall, mail the list, and our AD will review when doing the > AD review. There is also IETF LC, so we have another chance to > discuss this, this time in a more public setting? :-P So long as server operators understand that PKIX-TA is not a TA, and DANE-TA actually employs PKIX, and are not mislead into publishing incorrect records, all is well. The names could equally well be "Chico, Harpo, Groucho and Zeppo". I also hope that future implementors will have read the standard thoroughly and will have thought carefully about how to validate each of the four usages and will not be misled by the acronyms' false dichotomy. This said, the names are reasonably memorable, so I guess we can hope that their use will promote ease of discussion without creating confusion. I am too steeped in the details now to know whether I would have been confused initially. -- Viktor. From rlb@ipv.sx Tue Dec 10 13:13:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8E1AE0FE for ; Tue, 10 Dec 2013 13:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRUMMRGtVoyA for ; Tue, 10 Dec 2013 13:13:18 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 430CA1AE089 for ; Tue, 10 Dec 2013 13:13:18 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id uy5so6020842obc.12 for ; Tue, 10 Dec 2013 13:13:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=KPLhTaOdoGlkjK7ABEEJmOLHAAc5kvSxil9OtESaj0o=; b=B3IEZS2PY+hOHNIAnbrW8+FuOWKGLnuOIGHRl/Nw9cjEutfwsWwz0LctJx8D00NAfG qF9Qinn4/nZ4961r0P62UL6vuCjMhQK6zj6MT1vtB97DvYb4zNkvhDRVYzbRJCQgm2ap Iy39TyzKwKqwprUGGUCZmBxtqagNqYDPwrWsqeoXn7y2xfq7AIYb1zmesBv8vG/lNKfL dJbgAfnPdV05kqeLL49Z1t8APXNPfAib1MEooYnjo8Xcd+znIjjhbzGaKosGyFNXpnk/ /q7lnA2AJS3D7lhcO/smvetwjobgKSn8rLiN42V0Ekksm6e81mD8+DybbkXF+EbjuBWt 5qPg== X-Gm-Message-State: ALoCoQl92E4WOfu7v45uJNhxtq2n4LdQu+lb9+E0KIUtKJrSLJzwCgy4oiJCvxQbiQMVWCeKNOrs MIME-Version: 1.0 X-Received: by 10.60.58.134 with SMTP id r6mr17926348oeq.17.1386709992776; Tue, 10 Dec 2013 13:13:12 -0800 (PST) Received: by 10.60.31.74 with HTTP; Tue, 10 Dec 2013 13:13:12 -0800 (PST) In-Reply-To: <20131210194214.GH761@mournblade.imrryr.org> References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> <20131210194214.GH761@mournblade.imrryr.org> Date: Tue, 10 Dec 2013 16:13:12 -0500 Message-ID: From: Richard Barnes To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=089e013c71e486bf1804ed349424 Subject: Re: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 21:13:21 -0000 --089e013c71e486bf1804ed349424 Content-Type: text/plain; charset=ISO-8859-1 I'm a little confused, since I see a message from Warren on 6 Dec saying that the call would be extended until tomorrow. I admit that I have not been following this discussion closely, though. In case the window for comments / proposals is still open, my only insight here is that usages 0/1 are very much like the "pinning" work being done in draft-ietf-websec-key-pinning, so it might be helpful to re-use that term here. For 2/3, it seems like people I've talked to understand the verbs "assert" (since that's what the domain holder is doing) or "trust" (since that's what the recipient is being asked to do). 0 - PIN-CA 1 - PIN-EE 2 - ASSERT-CA or TRUST-CA 3 - ASSERT-EE or TRUST-EE So that's my favorite color for the bike shed. --Richard On Tue, Dec 10, 2013 at 2:42 PM, Viktor Dukhovni wrote: > On Tue, Dec 10, 2013 at 10:37:50AM -0500, Warren Kumari wrote: > > > We understand that these names are not perfect and do not please > > everyone. Despite that, there is sufficient value in the document > > and we believe it will aid discussion and (hopefully) deployment. > > This will also allow us to move on and discuss things of more > > substance. > > > > If you are still concerned that this document might cause the > > sky to fall, mail the list, and our AD will review when doing the > > AD review. There is also IETF LC, so we have another chance to > > discuss this, this time in a more public setting? :-P > > So long as server operators understand that PKIX-TA is not a TA, > and DANE-TA actually employs PKIX, and are not mislead into publishing > incorrect records, all is well. The names could equally well be > "Chico, Harpo, Groucho and Zeppo". > > I also hope that future implementors will have read the standard > thoroughly and will have thought carefully about how to validate > each of the four usages and will not be misled by the acronyms' > false dichotomy. > > This said, the names are reasonably memorable, so I guess we can > hope that their use will promote ease of discussion without creating > confusion. I am too steeped in the details now to know whether I > would have been confused initially. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --089e013c71e486bf1804ed349424 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm a little confused, since I see a message from Warr= en on 6 Dec saying that the call would be extended until tomorrow. =A0I adm= it that I have not been following this discussion closely, though.

=
In case the window for comments / proposals is still open, my only ins= ight here is that usages 0/1 are very much like the "pinning" wor= k being done in draft-ietf-websec-key-pinning, so it might be helpful to re= -use that term here. =A0For 2/3, it seems like people I've talked to un= derstand the verbs "assert" (since that's what the domain hol= der is doing) or "trust" (since that's what the recipient is = being asked to do).

=A0 =A0 =A0 =A0 0 - PIN-CA
=A0 =A0 =A0 =A0 1 - PIN-EE
=A0 =A0 =A0 =A0= 2 - ASSERT-CA or TRUST-CA
=A0 =A0 =A0 =A0 3 - ASSERT-EE or TRUST-EE

So = that's my favorite color for the bike shed. =A0

--Richard


On Tue, Dec 10, 2013 at 2:42 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
On Tue, Dec 10, 2013 at 10= :37:50AM -0500, Warren Kumari wrote:

> We understand that these names are not perfect and do not please
> everyone. Despite that, there is sufficient value in the document
> and we believe it will aid discussion and (hopefully) deployment.
> This will also allow us to move on and discuss things of more
> substance.
>
> If you are still concerned that this document might cause the
> sky to fall, mail the list, and our AD will review when doing the
> AD review. There is also IETF LC, so we have another chance to
> discuss this, this time in a more public setting? :-P

So long as server operators understand that PKIX-TA is not a TA,
and DANE-TA actually employs PKIX, and are not mislead into publishing
incorrect records, all is well. =A0The names could equally well be
"Chico, Harpo, Groucho and Zeppo".

I also hope that future implementors will have read the standard
thoroughly and will have thought carefully about how to validate
each of the four usages and will not be misled by the acronyms'
false dichotomy.

This said, the names are reasonably memorable, so I guess we can
hope that their use will promote ease of discussion without creating
confusion. =A0I am too steeped in the details now to know whether I
would have been confused initially.

--
=A0 =A0 =A0 =A0 Viktor.
_____________________= __________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--089e013c71e486bf1804ed349424-- From rlb@ipv.sx Tue Dec 10 13:29:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E980B1AE068 for ; Tue, 10 Dec 2013 13:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ4KEWgkH-Eg for ; Tue, 10 Dec 2013 13:29:45 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id 279F51AD73F for ; Tue, 10 Dec 2013 13:29:45 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so6063552obc.9 for ; Tue, 10 Dec 2013 13:29:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=sEuszAi2ZRd6C3ZBKpO9jmDIIYXH9q0SkdgpYgGAcuI=; b=G/GA+5pd5n9mz2FInxdUaXqqy6u/PzOVoBsqMbzplzxEjGYO9P2vOJOqhRPCV7npK4 K8RIwrHUB02xaTs2VmMT/9LmyGV8cH30mbGN/Fb/VHhpQxMlC44Yvm7K1A+/XWDn45GD 0cMRbHXPw9Y3PeUKTNWV6rTGvuGqSrlwYkQJurgmdtzwKCDgKI9hZ9Kbrw6lY9VF/a8L uohX7WcVWPfK8LvVstvlFG1ISWxpKlxpwRCQMY5U/bjQmhR2PDpgb3Pdh6HeLGB7xrjT eZ8CP5TBZXjYob7eNAFZm62rgy9U9fnpTFurz1oM1BNqmnIomxAxDEtl19n492TMid1M Tz8Q== X-Gm-Message-State: ALoCoQllsK3VKQTs1lZnlx8gyho0usRzgT9lEV93hC9zFWRwuT9Oe+31ZIFk8eWrrSrEq8CHMyqH MIME-Version: 1.0 X-Received: by 10.60.142.8 with SMTP id rs8mr18399671oeb.34.1386710979751; Tue, 10 Dec 2013 13:29:39 -0800 (PST) Received: by 10.60.31.74 with HTTP; Tue, 10 Dec 2013 13:29:39 -0800 (PST) Date: Tue, 10 Dec 2013 16:29:39 -0500 Message-ID: From: Richard Barnes To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33cd745ac9d704ed34cf00 Subject: [dane] Digest identifiers in -registry-acronyms-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 21:29:47 -0000 --047d7b33cd745ac9d704ed34cf00 Content-Type: text/plain; charset=ISO-8859-1 (Sorry if this has already been raised, but...) The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a little silly, in that nobody else in the world really seems to care that these are variants of SHA2. The standard practice across many libraries is to just use some variant of "SHA-XXX", where XXX=256,384,512. OpenSSL: shaXXX WebCrypto: SHA-XXX BouncyCastle: SHAXXXDigest CNG: BCRYPT_SHAXXX_ALGORITHM PKCS#11: CKM_SHAXXX So I would suggest we just change these to "SHA-256" and "SHA-512". --Richard --047d7b33cd745ac9d704ed34cf00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(Sorry if this has already been raised, but...)

The digest identifiers in draft-ietf-dane-registry-acronyms-02 see= m a little silly, in that nobody else in the world really seems to care tha= t these are variants of SHA2. =A0The standard practice across many librarie= s is to just use some variant of "SHA-XXX", where XXX=3D256,384,5= 12.

OpenSSL: shaXXX
WebCrypto: SHA-XXX
= BouncyCastle: SHAXXXDigest
CNG: BCRYPT_SHAXXX_ALGORITHM
PKCS#11:=A0CKM_SHAXXX

So I would suggest we just = change these to "SHA-256" and "SHA-512".

--Richard

--047d7b33cd745ac9d704ed34cf00-- From ogud@ogud.com Tue Dec 10 13:34:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44DB1AE0D0 for ; Tue, 10 Dec 2013 13:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku75_B9lCAZh for ; Tue, 10 Dec 2013 13:34:40 -0800 (PST) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) by ietfa.amsl.com (Postfix) with ESMTP id EF4021AD73F for ; Tue, 10 Dec 2013 13:34:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 950671E8235; Tue, 10 Dec 2013 16:34:34 -0500 (EST) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 88F471E820C; Tue, 10 Dec 2013 16:34:32 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: Date: Tue, 10 Dec 2013 16:34:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <278BCBAE-5D0C-42F5-A73A-D31B6CCF93BF@ogud.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org" Subject: Re: [dane] Digest identifiers in -registry-acronyms-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 21:34:41 -0000 On Dec 10, 2013, at 4:29 PM, Richard Barnes wrote: > (Sorry if this has already been raised, but=85) >=20 > The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a = little silly, in that nobody else in the world really seems to care that = these are variants of SHA2. The standard practice across many libraries = is to just use some variant of "SHA-XXX", where XXX=3D256,384,512. >=20 Richard,=20 First version had this but an comment was made that we could have both = SHA2 and SHA3 in 512 bit variant thus the recommendation=20 was to future proof us.=20 > OpenSSL: shaXXX > WebCrypto: SHA-XXX > BouncyCastle: SHAXXXDigest > CNG: BCRYPT_SHAXXX_ALGORITHM > PKCS#11: CKM_SHAXXX >=20 > So I would suggest we just change these to "SHA-256" and "SHA-512". Unless the chair's tell me to make the change it will not be made,=20 feel free to bring this up in the IETF LC if you think this is = important.=20 Olafur >=20 > --Richard >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From guido@witmond.nl Tue Dec 10 14:10:48 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7D81AE08B for ; Tue, 10 Dec 2013 14:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnux2pEHd07a for ; Tue, 10 Dec 2013 14:10:46 -0800 (PST) Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3]) by ietfa.amsl.com (Postfix) with ESMTP id 683631AE053 for ; Tue, 10 Dec 2013 14:10:45 -0800 (PST) Received: from [10.1.2.6] (unknown [10.1.2.6]) by mail.witmond.nl (Postfix) with ESMTP id 77D02CA79E for ; Tue, 10 Dec 2013 22:10:35 +0000 (UTC) Message-ID: <52A79155.1040100@witmond.nl> Date: Tue, 10 Dec 2013 23:10:29 +0100 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: dane@ietf.org References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> <20131210194214.GH761@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QDBTQJLLPFQCNJVPSPFC" Subject: Re: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 22:10:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QDBTQJLLPFQCNJVPSPFC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/10/13 22:13, Richard Barnes wrote: > I'm a little confused, since I see a message from Warren on 6 Dec sayin= g > that the call would be extended until tomorrow. I admit that I have no= t > been following this discussion closely, though. >=20 > In case the window for comments / proposals is still open, my only > insight here is that usages 0/1 are very much like the "pinning" work > being done in draft-ietf-websec-key-pinning, so it might be helpful to > re-use that term here. For 2/3, it seems like people I've talked to > understand the verbs "assert" (since that's what the domain holder is > doing) or "trust" (since that's what the recipient is being asked to do= ). >=20 > 0 - PIN-CA > 1 - PIN-EE > 2 - ASSERT-CA or TRUST-CA > 3 - ASSERT-EE or TRUST-EE >=20 > So that's my favorite color for the bike shed. =20 To add my own color: DANE can only specify *intent*. Intent of the domain owner what they choose for their certificate source. Without *verification* that intent is worthless. 1. The owner of the domain must regularly validate that their chosen DNS-registrar still publishes the owners' intent, preferably with something like Perspectives that registers and remembers historic measurements. 2. People doing a lookup for the current value of TLSA records should validate these against the Perspectives history. When it matches, it's OK. When there is a mismatch, there is a problem. The only solution for the resolver is to fail fast and for the user to twitter about it. Make it public and let the community resolve the problem. It could be lousy DNS-registrar, the domain owner looks for a better one. It could be a MitM-device, the end user learns of its existence. In short, without *verification* DANE doesn't do so much. With verification, it's a big leap ahead. CT protects in the 0/1 cases, Perspectives in the 2/3 cases. IMHO, the naming should reflect the source of the certificate: 0: Global trusted CA; 1: End certificate in a chain from a Global trusted CA; 2: My own CA; ( from the perspective of the domain owner) 3: My own Certificate; (same perspective) Cheers, Guido. ------enig2QDBTQJLLPFQCNJVPSPFC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJSp5FaAAoJEHPd8GglaNRmFTMP/RjUP4nEGUp5tRo3JMm7pFkF hog+cd+S+gF1Vekfg5Vb+1N1Z/WOPCjVLRRAdkBK0+U7P94eBbzsBKydQSmzweR7 E4ofzteyFXWvhtK4FF66QjxOAG/hTEP8epFIHInNpyJcEMLdlQvdpev8RqZblMzg 5c9guYzCMCFhITpOrgzn028AJxEr/DfBMpw7m5+sDaHm3ozopgJZXaNMyN24h28J gsKAhD1sm5ZbgSrbBcgVRWphQD+cvbzZjAx0xmlXgvCOSahM0P3+peUqhF9imzhh vvz1UKOXu9EozdcUkzY7Xe3YANkMhBbOb7DK8vNzZ+LoG5R2w1Ktjygz4CFGi/PE /r8SFfRW/+Yi0kQ4TRtiRmQgazchBDVF+su6gLhtd3cD0QU5d0D56zx1ucP1jx3y 7kFOSB+Q++h/LlzI85GJ4ZiYwjrpRGvnBvOa9MlTjgsuaVpR3+MMHKQTsrKE8RoN BTt2r4KT3TgLaeQwXLw2ZMFXH5WZmKIoGvl4CqN85q191w9N2e9iR7R1e+Xug9Gp vHuz7AXbPMwRbQKnzfE/OJxEsZzQ5mUjuTnun0pLYSlSE39XhgUkOBrsynIslS0I OXCdSXxJI9OeKwZLzd5K5lVk2bgAQ/E9O9/YB/TF3N82A4ygeF2VBZWTF7fCuYLg F9Or/277gvQGiRwvJC9r =rgSI -----END PGP SIGNATURE----- ------enig2QDBTQJLLPFQCNJVPSPFC-- From rlb@ipv.sx Tue Dec 10 14:18:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5F1AE0FA for ; Tue, 10 Dec 2013 14:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M5jhNNq4-_U for ; Tue, 10 Dec 2013 14:18:34 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id C54D71AE0F3 for ; Tue, 10 Dec 2013 14:18:34 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id h16so6237840oag.25 for ; Tue, 10 Dec 2013 14:18:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XoY9VIM3pwy1jPVDeucbSXyiRjsbVsjcyk3Arqq8fLA=; b=IAao67Cnfo86shb5yYHBci7DmgNTaDcjkQRg2sQBA+AoxQoxSjARhH1qgGjJgWfLVV YTHKGo2d2UDEQjLafK/KJ6sXttbA2pZc4aUrTXrTUS9PkPUX/eERiHRr8osTDAzVYRwu +3NrD64LA2TxAdTu+rz78ac7V8zwlRkPJ/owahOiNwqhO2k5/+K4lM6sndE5vigBUjRc xqn7oeR6py6AKZUC3eqsvl+QfRFAGCJBwgoHTZWeNN27000SqmyySjkCcH4daeolMtri cJh75GFpB/vTEfLp/L5c0P5iwJFKXbkapwvDpCejXSJWpiiCfSfzGW+HfjauCiQRxNUC pHuw== X-Gm-Message-State: ALoCoQlWdctSIDxFP2JlY/4kLJ/Nrh7RnmCfVdePuGpHuRzzDpkocBsgWtRtMKok8K6lKSSaBLtV MIME-Version: 1.0 X-Received: by 10.183.3.102 with SMTP id bv6mr18565262obd.18.1386713909391; Tue, 10 Dec 2013 14:18:29 -0800 (PST) Received: by 10.60.31.74 with HTTP; Tue, 10 Dec 2013 14:18:29 -0800 (PST) In-Reply-To: <278BCBAE-5D0C-42F5-A73A-D31B6CCF93BF@ogud.com> References: <278BCBAE-5D0C-42F5-A73A-D31B6CCF93BF@ogud.com> Date: Tue, 10 Dec 2013 17:18:29 -0500 Message-ID: From: Richard Barnes To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=001a1134a45cf9835304ed357d47 Cc: "dane@ietf.org" Subject: Re: [dane] Digest identifiers in -registry-acronyms-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 22:18:37 -0000 --001a1134a45cf9835304ed357d47 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fair enough, I guess. But all of these libraries already have algorithm IDs for SHA256/SHA512, so some new convention is going to have to come for SHA3/512. I can just see the administrators saying "Damn, I forgot the '2' again!" On Tue, Dec 10, 2013 at 4:34 PM, Olafur Gudmundsson wrote: > > On Dec 10, 2013, at 4:29 PM, Richard Barnes wrote: > > > (Sorry if this has already been raised, but=85) > > > > The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a > little silly, in that nobody else in the world really seems to care that > these are variants of SHA2. The standard practice across many libraries = is > to just use some variant of "SHA-XXX", where XXX=3D256,384,512. > > > > Richard, > > First version had this but an comment was made that we could have both > SHA2 and SHA3 in 512 bit variant thus the recommendation > was to future proof us. > > > OpenSSL: shaXXX > > WebCrypto: SHA-XXX > > BouncyCastle: SHAXXXDigest > > CNG: BCRYPT_SHAXXX_ALGORITHM > > PKCS#11: CKM_SHAXXX > > > > So I would suggest we just change these to "SHA-256" and "SHA-512". > > Unless the chair's tell me to make the change it will not be made, > feel free to bring this up in the IETF LC if you think this is important. > > Olafur > > > > > --Richard > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > --001a1134a45cf9835304ed357d47 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Fair enough, I guess. =A0But all of these libraries alread= y have algorithm IDs for SHA256/SHA512, so some new convention is going to = have to come for SHA3/512.

I can just see the administra= tors saying "Damn, I forgot the '2' again!" =A0


On Tue,= Dec 10, 2013 at 4:34 PM, Olafur Gudmundsson <ogud@ogud.com> wr= ote:

On Dec 10, 2013, at 4:29 PM, Richard Barnes <rlb@ipv.sx> wrote:

> (Sorry if this has already been raised, but=85)
>
> The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a = little silly, in that nobody else in the world really seems to care that th= ese are variants of SHA2. =A0The standard practice across many libraries is= to just use some variant of "SHA-XXX", where XXX=3D256,384,512.<= br> >

Richard,

First version had this but an comment was made that we could have both SHA2= =A0and SHA3 in 512 bit variant thus the recommendation
was to future proof us.

> OpenSSL: shaXXX
> WebCrypto: SHA-XXX
> BouncyCastle: SHAXXXDigest
> CNG: BCRYPT_SHAXXX_ALGORITHM
> PKCS#11: CKM_SHAXXX
>
> So I would suggest we just change these to "SHA-256" and &qu= ot;SHA-512".

Unless the chair's tell me to make the change it will not be made= ,
feel free to bring this up in the IETF LC if you think this is important.
=A0 =A0 =A0 =A0 Olafur

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


--001a1134a45cf9835304ed357d47-- From viktor1dane@dukhovni.org Tue Dec 10 14:47:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2911AE154 for ; Tue, 10 Dec 2013 14:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwWeB67fkWmx for ; Tue, 10 Dec 2013 14:47:39 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 64A981AE0F3 for ; Tue, 10 Dec 2013 14:47:39 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D77D2AB163; Tue, 10 Dec 2013 22:47:33 +0000 (UTC) Date: Tue, 10 Dec 2013 22:47:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131210224733.GJ761@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Digest identifiers in -registry-acronyms-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:47:40 -0000 On Tue, Dec 10, 2013 at 04:29:39PM -0500, Richard Barnes wrote: > So I would suggest we just change these to "SHA-256" and "SHA-512". It is not possible to find digest names that universally match prior practice. So likely any recognizable non-confusing names are sufficient. For example in OpenSSL the names are: #define SN_sha256 "SHA256" #define LN_sha256 "sha256" with no hyphens at all. So, perhaps surprisingly, I have no objects to the digest names, it is clear what they mean, and no single choice matches established practice. -- Viktor. From viktor1dane@dukhovni.org Tue Dec 10 14:58:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C101A1F1A for ; Tue, 10 Dec 2013 14:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqj92r9d92cB for ; Tue, 10 Dec 2013 14:58:45 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6E71AE281 for ; Tue, 10 Dec 2013 14:58:45 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A2202AB163; Tue, 10 Dec 2013 22:58:39 +0000 (UTC) Date: Tue, 10 Dec 2013 22:58:39 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131210225838.GK761@mournblade.imrryr.org> References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> <20131210194214.GH761@mournblade.imrryr.org> <52A79155.1040100@witmond.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A79155.1040100@witmond.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:58:47 -0000 On Tue, Dec 10, 2013 at 11:10:29PM +0100, Guido Witmond wrote: > DANE can only specify *intent*. Intent of the domain owner what they > choose for their certificate source. The intent of the holder of the current zone signing key. > Without *verification* that intent is worthless. The intent is conveniently verified by an RRSIG generated by the zone signing public key. Arguing against the DANE security model has no bearing on the acronyms. > IMHO, the naming should reflect the source of the certificate: > 0: Global trusted CA; Except that the record value is not a global trusted CA. Rather its value is a CA constraint on the chain from some trusted CA requiring the presence of some intermediate at or below such a CA. The record should be named after what is specifies, which is a CA required in your chain, not a trusted root. This was my objection to the change from PKIX-CA to PKIX-TA. The change from PKIX-CA to PKIX-TA is still wrong (even if I am willing to let it slide), as it will perpetuate confusion by many people who don't understand usage 0 or usage 2, but think they do. > 1: End certificate in a chain from a Global trusted CA; Sure. But I don't see an ancronym here... > 2: My own CA; ( from the perspective of the domain owner) Your own trust-anchor. > 3: My own Certificate; (same perspective) Still no actual acronym. -- Viktor. From guido@witmond.nl Tue Dec 10 15:45:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC01ADEA0 for ; Tue, 10 Dec 2013 15:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYiI-pPM5BYB for ; Tue, 10 Dec 2013 15:45:28 -0800 (PST) Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3]) by ietfa.amsl.com (Postfix) with ESMTP id 62EA31ADEAE for ; Tue, 10 Dec 2013 15:45:27 -0800 (PST) Received: from [10.1.2.6] (unknown [10.1.2.6]) by mail.witmond.nl (Postfix) with ESMTP id 46DAFC55EB for ; Tue, 10 Dec 2013 23:45:19 +0000 (UTC) Message-ID: <52A7A789.401@witmond.nl> Date: Wed, 11 Dec 2013 00:45:13 +0100 From: Guido Witmond User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: dane@ietf.org References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> <20131210194214.GH761@mournblade.imrryr.org> <52A79155.1040100@witmond.nl> <20131210225838.GK761@mournblade.imrryr.org> In-Reply-To: <20131210225838.GK761@mournblade.imrryr.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2WSHLALTIHDCKNKNURGUO" Subject: Re: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2013 23:45:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2WSHLALTIHDCKNKNURGUO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/10/13 23:58, Viktor Dukhovni wrote: > On Tue, Dec 10, 2013 at 11:10:29PM +0100, Guido Witmond wrote: >=20 >> DANE can only specify *intent*. Intent of the domain owner what they >> choose for their certificate source. >=20 > The intent of the holder of the current zone signing key. >=20 >> Without *verification* that intent is worthless. >=20 > The intent is conveniently verified by an RRSIG generated by the > zone signing public key. Which could be changed by a malicious Register. Ie. That's what needs to be verified by both the domain owner and the end user. > Arguing against the DANE security model has no bearing on the acronyms.= I'm arguing to propose names that the matches the End Users' expectation. That might lead to some smart domain owners to consider how their TLSA-records are received. Can't protect against Stupid, regrettabl= y. >> IMHO, the naming should reflect the source of the certificate: >> 0: Global trusted CA; >=20 > Except that the record value is not a global trusted CA. Rather > its value is a CA constraint on the chain from some trusted CA > requiring the presence of some intermediate at or below such a CA. >=20 > The record should be named after what is specifies, which is a CA > required in your chain, not a trusted root. This was my objection > to the change from PKIX-CA to PKIX-TA. The change from PKIX-CA to > PKIX-TA is still wrong (even if I am willing to let it slide), as > it will perpetuate confusion by many people who don't understand > usage 0 or usage 2, but think they do. My misunderstanding. I believed it would specify my chosen CA for my domain, I understand it could be more specific than that: A certain subCA from that CA. Would it mean that that specific CA has *less* options to get coerced to issue a fake certificate for my domain? >> 1: End certificate in a chain from a Global trusted CA; >=20 > Sure. But I don't see an acronym here... >=20 >> 2: My own CA; ( from the perspective of the domain owner) >=20 > Your own trust-anchor. >=20 >> 3: My own Certificate; (same perspective) >=20 > Still no actual acronym. I left acronyms to those better able to decide. I just wanted to point out my ideas. Especially the idea to frame the acronyms in the mind-set of the end-user. Because I believe, that's the person we need to protect.= Regards, Guido. ------enig2WSHLALTIHDCKNKNURGUO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJSp6eJAAoJEHPd8GglaNRm1vcP/0OxyN8rQfcWRNEn/E2R18tl YDYhwKV5Lxd57usBVxZHXHT79+HLgyx+2/SdEAHH6fqXElnzbRhMjCanytKHQSdz WvRLqFVsB5yn+APWzNOiDlyuniR41G+nVdQsrTRgejzivIE21pJqyuMHpiGvU2iF MP/FCtqQorhA9pT8Pm4rPbrTcGrg3CTOTdb4YGRQrnQTvFDfXpJ3tfk3tEEpmGdi NeqAGKtNnLIr1bn6O8J64TM/94D7tgNWFOPpgiCiH3EcfXrA/ms6r10CEYsWNVsu +BXYMvhjF5TLaGhi+Pnpa96rA3wlLLkF/nfN7QBbGOa4pLylWRiE2y6K4tChDFSi KuooqtYGo+aWK9/ek4PSw7qbPcgKLSfFlp3q33kCRZJt7lVAVA6cUC3F0GxNNM2J 2fXrCvzInazzWXJ6TRbnb5rbmT+f9m8gfJsEgmzW2/LPb04Ub//7xW6NQqYn7k8a 2rsekiuwJ/K4VO4QdsoQo6wG9lIGnis3gFvLnKimTFA9AtqTYIbWW//b3z38YFQC JDPjD4kUfspeMveVhQy6PgqpSVqDxpOS/mDhL1JHDE8SPILIIkza8XeYNFVCiuCX SPFs1w/4hqB1IY/JYq8+tMGY80Wm6kHZfBj7lran+5zEjMhgKuxsXdQjZaAzr1Vw yeq6AF8wr8PRUnv31i7f =0gwg -----END PGP SIGNATURE----- ------enig2WSHLALTIHDCKNKNURGUO-- From mrex@sap.com Tue Dec 10 16:05:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87F91AE2DC for ; Tue, 10 Dec 2013 16:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wn5v9XC1CZa for ; Tue, 10 Dec 2013 16:05:25 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7B1AE2D2 for ; Tue, 10 Dec 2013 16:05:24 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rBB05IW8012723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 01:05:18 +0100 (MET) In-Reply-To: To: Richard Barnes Date: Wed, 11 Dec 2013 01:05:18 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131211000518.1F78E1AB45@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "dane@ietf.org" Subject: Re: [dane] Digest identifiers in -registry-acronyms-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:05:28 -0000 Richard Barnes wrote: > > The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a > little silly, in that nobody else in the world really seems to care that > these are variants of SHA2. The standard practice across many libraries is > to just use some variant of "SHA-XXX", where XXX=256,384,512. while sha224, sha256, sha384 and sha512 are members of the SHA2-Family, they're not all the same algorithm, they use two seperate algorithms. sha256 + sha224 use the same 32-bit algorithm (different internal start value, output truncation for sha224) http://tools.ietf.org/html/rfc6234#section-5.1 sha512 + sha384 use the same 64-bit algorithm (different internal start value, output truncation for sha384) http://tools.ietf.org/html/rfc6234#section-5.2 > > So I would suggest we just change these to "SHA-256" and "SHA-512". In theory, reusing (or copying) an existing IANA registry would be preferable to inventing yet another different variant. Unfortunately, it seems that all variants already exist... TLS: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18 0 none Y [RFC5246] 1 md5 Y [RFC5246] 2 sha1 Y [RFC5246] 3 sha224 Y [RFC5246] 4 sha256 Y [RFC5246] 5 sha384 Y [RFC5246] 6 sha512 Y [RFC5246] PKIX/CMS: http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml "md2" 1.2.840.113549.2.2 [RFC3279] "md5" 1.2.840.113549.2.5 [RFC3279] "sha-1" 1.3.14.3.2.26 [RFC3279] "sha-224" 2.16.840.1.101.3.4.2.4 [RFC4055] "sha-256" 2.16.840.1.101.3.4.2.1 [RFC4055] "sha-384" 2.16.840.1.101.3.4.2.2 [RFC4055] "sha-512" 2.16.840.1.101.3.4.2.3 [RFC4055] IPSEC: http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-6 1 MD5 [RFC1321] 2 SHA [NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.] 3 Tiger [Anderson, R., and Biham, E., "Fast Software Encryption", Springer LNCS v. 1039, 1996.] 4 SHA2-256 [Marcus_Leech][RFC4868] 5 SHA2-384 [Marcus_Leech][RFC4868] 6 SHA2-512 [Marcus_Leech][RFC4868] DKIM: http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml#dkim-parameters-7 sha1 [FIPS-180-3-2008] active sha256 [FIPS-180-3-2008] active DNSSEC/NSEC3: http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3 0 Reserved [RFC5155] 1 SHA-1 [RFC5155] DNSSEC: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 Number Description Mnemonic 5 RSA/SHA-1 RSASHA1 Y Y [RFC3110][RFC4034] 6 DSA-NSEC3-SHA1 DSA-NSEC3-SHA1 Y Y [RFC5155][proposed standard] 8 RSA/SHA-256 RSASHA256 Y * [RFC5702][proposed standard] 9 Reserved [RFC6725] 10 RSA/SHA-512 RSASHA512 Y * [RFC5702][proposed standard] RFC 4634 / 6234 http://tools.ietf.org/html/rfc6234#page-3 4.1. SHA-224 and SHA-256 4.2. SHA-384 and SHA-512 -Martin From viktor1dane@dukhovni.org Tue Dec 10 16:31:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D11B1ADF86 for ; Tue, 10 Dec 2013 16:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn2PmMhl36T2 for ; Tue, 10 Dec 2013 16:31:47 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD21AD94A for ; Tue, 10 Dec 2013 16:31:46 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F10E12AB16E; Wed, 11 Dec 2013 00:31:40 +0000 (UTC) Date: Wed, 11 Dec 2013 00:31:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131211003140.GM761@mournblade.imrryr.org> References: <77C3BA84-1EC4-4536-B66D-D9C36CCF7C1A@kumari.net> <20131210194214.GH761@mournblade.imrryr.org> <52A79155.1040100@witmond.nl> <20131210225838.GK761@mournblade.imrryr.org> <52A7A789.401@witmond.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A7A789.401@witmond.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Calling the naming issue... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:31:49 -0000 On Wed, Dec 11, 2013 at 12:45:13AM +0100, Guido Witmond wrote: > > The record should be named after what is specifies, which is a CA > > required in your chain, not a trusted root. This was my objection > > to the change from PKIX-CA to PKIX-TA. The change from PKIX-CA to > > PKIX-TA is still wrong (even if I am willing to let it slide), as > > it will perpetuate confusion by many people who don't understand > > usage 0 or usage 2, but think they do. > > My misunderstanding. I believed it would specify my chosen CA for my > domain, I understand it could be more specific than that: A certain > subCA from that CA. Would it mean that that specific CA has *less* > options to get coerced to issue a fake certificate for my domain? [ EXACTLY. This is the misunderstanding I want to discourage by NOT naming "0" DANE-TA, but that is exactly what is is NOT. My objection to DANE-TA is looking stronger. Please REVERT it to DANE-CA, and the draft can then move forward without reinforcing confusion. ] Yes, one can exclude various reseller subordinate CAs, or other intermediates issued by some trusted CA, and thus protect verifiers of your domain for being fooled by certificates issued by unrelated rogue intermediates. Provider your intermediate CA is not rogue, you're safe(r). > I left acronyms to those better able to decide. I just wanted to point > out my ideas. Especially the idea to frame the acronyms in the mind-set > of the end-user. Because I believe, that's the person we need to protect. I agree. Thus my earlier posts suggesting we use name components more familar to every-day users. This excludes "PKIX" (almost nobody knows what that means), "TA" and "EE". The only proposed name component that might mean something to people is "DANE" but that applies to *all* the usages, they are all "DANE". So the proposed names are somewhat memorable, but meaningless. The following would be much better: - LIMIT-ISSUING-AUTHORITY - LIMIT-LEAF-ENTITY - ASSERT-TRUSTED-ISSUER - ASSERT-LEAF-ENTITY but unless the author decides to propose a revision, perhaps we're stuck with the broken names and any confusion they may entrench. I encourage the author to boldly change the names if he has seen any merit in my arguments. It is of course possible that I'm not convincing anyone at all. That's fine, I have actual code to write and test. -- Viktor. From benl@google.com Wed Dec 11 04:54:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8AC1AD8EC for ; Wed, 11 Dec 2013 04:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMbuWJAkY675 for ; Wed, 11 Dec 2013 04:54:39 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB241ACC87 for ; Wed, 11 Dec 2013 04:54:39 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so5882730veb.36 for ; Wed, 11 Dec 2013 04:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=08C1X6fj3qPGde0TZtZKOR0jHEtTVsDbnMNd9z8ZITw=; b=kOWcImxyHIAWBgS+dGPWXjGjbCxy8c5VbAHsqnzcLEbAiF3ZLvwOz1cr840xKBtzgK /vv+EuFdoiioi3bmfHx0X3PJhtlJ5xVfV6hRaw3vd+AHuxGAsYPtQxdu6PdN6dZqzp84 3s4IRfEgbximhoEcPG62b4ekQRPHZSWo1YI1SKxkD2dTlZjIGeoyEFkATPTITtD8Hd7y WmMcpcGSf50FqTXD4GW+ZvJ+5I1U7PG/As4daClivBoX+dmOH4e+AEYzshhMGPaWLamK zf0WWls0FIwFbTBzRfAqDtXZ7iCgeuGkeG/QrCrYSWmq+r+GvjjJ9AE0irVuIDiP8PN1 Uzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=08C1X6fj3qPGde0TZtZKOR0jHEtTVsDbnMNd9z8ZITw=; b=nAGRlPcicd1+2Mta8HelrlYgDO1hnfImdRO8AljA+VL6RSldzVE/tS4obt1fH6Pm06 ymW05ULVlGlhky8hCZTWydn/VzY3rN51XEnbzFq6w6HPpF7l+xXoNTpwb3ngbnEX26u7 iZ6t4s4ATSoDhjcIBlDsXq9ESn56hODVBQB94izEUgVTDA/to3O0dABk4LG76BOO1YE7 0S+ajipK6dPZX2jQ7WEbOOu2zsQ6bknAqiaxj/LgV2F62urHkRDLNPfzHmKDXGHfiQxg aZAvlVx5lBkO4aolEgyZR+ooE2DIzBWp0yqgOWzZdavbOuc7R3bM1EfcK9U60iFmlcnh q8oA== X-Gm-Message-State: ALoCoQnPpVUVOt0AAdQxvo6YuisxpVUETbzRtSTsSE7BzzkQ0R42atVl10Bm0FeKNhyUtdCL93k6CSKU1cdwQ6somNO1vBPrJCoAOHB4CiVsHowTu691/1qEs7opOZ/jKuO1Z09k5ElyHeMpDl6i+xYSvsNjSXtmmRqVsaWm9schd2HCJQchHO2ua5BxU75GrJhVrrWRGCKs MIME-Version: 1.0 X-Received: by 10.52.157.232 with SMTP id wp8mr450953vdb.4.1386766473709; Wed, 11 Dec 2013 04:54:33 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 04:54:33 -0800 (PST) In-Reply-To: <52A7400F.4090402@bbn.com> References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> <20131209231919.GY761@mournblade.imrryr.org> <4FAF6906-D258-4AB3-B76C-888C35566097@kirei.se> <20131210073402.GA761@mournblade.imrryr.org> <52A73074.1050904@bbn.com> <52A7400F.4090402@bbn.com> Date: Wed, 11 Dec 2013 12:54:33 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF DANE WG list Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2013 12:54:41 -0000 On 10 December 2013 16:23, Stephen Kent wrote: > Ben, > > Thanks for the clarification. I disagree with the relative merit of the > two approaches, but I don't dispute your observations. I'm not particularly interested in which is more defective: they both need fixing. From wjhns1@hardakers.net Wed Dec 11 09:50:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B71E1AE103 for ; Wed, 11 Dec 2013 09:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn_VT17jNB6h for ; Wed, 11 Dec 2013 09:50:38 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 99FDA1ADFAB for ; Wed, 11 Dec 2013 09:50:38 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:75b2:586f:4b28:6a62]) by mail.hardakers.net (Postfix) with ESMTPSA id D0A2229107; Wed, 11 Dec 2013 09:50:32 -0800 (PST) From: Wes Hardaker To: Warren Kumari References: Date: Wed, 11 Dec 2013 09:50:31 -0800 In-Reply-To: (Warren Kumari's message of "Mon, 2 Dec 2013 13:44:49 -0500") Message-ID: <0l1u1jp994.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "dane@ietf.org" Subject: Re: [dane] =?utf-8?q?On_the_PKIX-TA_/_PKIX-CA_question=E2=80=A6_=5B_O?= =?utf-8?q?ne_week_WGLC_=5D?= X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2013 17:50:43 -0000 Warren Kumari writes: > PKIX-TA > PKIX-CA > DANE- That's exactly the order I'd prefer. Types 0/1 require PKIX, so the prefix makes sense and I like the alignment that allows: |---------+---------| | PKIX-TA | PKIX-EE | |---------+---------| | DANE-TA | DANE-EE | |---------+---------| (even though a future type 5 may not align well, those four still can and probably should) That being said, I'm fine with PKIX-CA as well. I disagree(ish) that a type 0 reference is not a trust-anchor and thus shouldn't be called that. And the reason I disagree is that though in-itself it isn't one because the true trust anchor must also be pre-programmed, it still is very much restricting use to a single TA and pointed to as a reference. Thus it truly is being used as a form of trust, because both the internally recorded TA and the DANE TLSA record must match or all bets are off. Thus they're both equally as important when DANE is in play. -- Wes Hardaker Parsons From wjhns1@hardakers.net Wed Dec 11 09:55:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31951AE069 for ; Wed, 11 Dec 2013 09:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJVOuX_yFtHf for ; Wed, 11 Dec 2013 09:55:15 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE91AE03E for ; Wed, 11 Dec 2013 09:55:15 -0800 (PST) Received: from localhost (unknown [IPv6:2001:470:1f00:187:75b2:586f:4b28:6a62]) by mail.hardakers.net (Postfix) with ESMTPSA id 6F098290BD; Wed, 11 Dec 2013 09:55:09 -0800 (PST) From: Wes Hardaker To: John Gilmore References: <20131205175314.GH761@mournblade.imrryr.org> <201312080234.rB82YeoW029387@new.toad.com> Date: Wed, 11 Dec 2013 09:55:08 -0800 In-Reply-To: <201312080234.rB82YeoW029387@new.toad.com> (John Gilmore's message of "Sat, 07 Dec 2013 18:34:40 -0800") Message-ID: <0lvbyvnugz.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2013 17:55:17 -0000 John Gilmore writes: > It's unnecessary, which probably explains the paucity of responses, > and divisive among those who did respond. It should be abandoned. I disagree because of the huge number of conversations I've had with people where they just couldn't get the three-tuple numbers in their head. A consensus call on "which acronyms do you state are absolutely abysmal" might end up with a better set of "ok, most people don't out-right-hate those" than a voting competition where only the favorite should win. EG, I'd be happier with both PKIX-CA or PKIX-TA over "0" and "1" even though my preferred choice is still PKIX-TA. -- Wes Hardaker Parsons From paul@cypherpunks.ca Thu Dec 12 12:14:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D2B1AE434 for ; Thu, 12 Dec 2013 12:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjtUNEzpejQ5 for ; Thu, 12 Dec 2013 12:13:58 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE051AE0C8 for ; Thu, 12 Dec 2013 12:13:57 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4274D80A00; Thu, 12 Dec 2013 15:13:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2CE86809FA; Thu, 12 Dec 2013 15:13:51 -0500 (EST) Date: Thu, 12 Dec 2013 15:13:51 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Martin Rex In-Reply-To: <20131211000518.1F78E1AB45@ld9781.wdf.sap.corp> Message-ID: References: <20131211000518.1F78E1AB45@ld9781.wdf.sap.corp> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dane@ietf.org" Subject: Re: [dane] Digest identifiers in -registry-acronyms-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2013 20:14:01 -0000 On Wed, 11 Dec 2013, Martin Rex wrote: > Unfortunately, it seems that all variants already exist... > IPSEC: http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-6 > > 1 MD5 [RFC1321] > 2 SHA [NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.] > 3 Tiger [Anderson, R., and Biham, E., "Fast Software Encryption", Springer LNCS v. 1039, 1996.] > 4 SHA2-256 [Marcus_Leech][RFC4868] > 5 SHA2-384 [Marcus_Leech][RFC4868] > 6 SHA2-512 [Marcus_Leech][RFC4868] Awesome. IPsec is the only registry that did it right[1] :) Paul [1] Apart from the 1 missing in SHA1 From internet-drafts@ietf.org Thu Dec 19 08:07:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E501AE009; Thu, 19 Dec 2013 08:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee_ucNy_FSFP; Thu, 19 Dec 2013 08:07:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5E71ADFB5; Thu, 19 Dec 2013 08:07:10 -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.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219160710.8908.47958.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 08:07:10 -0800 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 16:07:13 -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 Entitie= s Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) = TLSA records with SRV and MX records. Author(s) : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-03.txt Pages : 12 Date : 2013-12-13 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols use SRV records (RFC 2782) to indirectly name the server hosts for a service domain (SMTP uses MX records for the same purpose). This specification gives generic instructions for how these application protocols locate and use TLSA records when technologies such as SRV records are used. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-srv-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From viktor1dane@dukhovni.org Thu Dec 19 09:30:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81B51AE12B for ; Thu, 19 Dec 2013 09:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5xzHDMJtpHB for ; Thu, 19 Dec 2013 09:30:32 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0271AE128 for ; Thu, 19 Dec 2013 09:30:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9AA982AB01A; Thu, 19 Dec 2013 17:30:27 +0000 (UTC) Date: Thu, 19 Dec 2013 17:30:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131219173027.GB1285@mournblade.imrryr.org> References: <20131219160710.8908.47958.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131219160710.8908.47958.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] draft-ietf-dane-srv-03.txt: name checks, ... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:30:34 -0000 On Thu, Dec 19, 2013 at 08:07:10AM -0800, internet-drafts@ietf.org wrote: > Filename : draft-ietf-dane-srv-03.txt > Date : 2013-12-13 Section 5 (no exception for usage 3): Section 7 (MUST and SHOULD on server name are too strong): Section 10.3 (no exception for usage 3): This still conflicts with the smtp-with-dane and ops drafts with respect to name checks (server identity checks) in usage 3. In the two conflicting documents usage 3 certificates are validated exclusively by matching against DANE TLSA RRs. No name checks, key usage checks, expiration checks, ... apply with usage 3. Rather, the binding of the EE certificate to the service end-point is entirely established by the DNSSEC TLSA record (also its validity lifetime is the lifetime of the TLSA record). Correspondingly, all requirements on the content of the server certificate are relaxed with usage 3, it may, if desired, contain no identity information. For example, given the following TLSA record: _25._tcp.mail.example. IN TLSA 3 1 1 \ 4D8CC746810AB5C7D7D24EE2A78AA6D5 \ 687E5CCA54A85846DAACD71E1B172F00 the below would be a valid certificate (which is, absent DANE, anonymous and never valid): Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA256 Issuer: Validity Not Before: Dec 19 17:16:51 2013 GMT Not After : Dec 18 17:16:51 2013 GMT Subject: Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: ... ASN1 OID: prime256v1 Signature Algorithm: ecdsa-with-SHA256 ... -----BEGIN CERTIFICATE----- MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xMzEyMTkxNzE2NTFaFw0x MzEyMTgxNzE2NTFaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARIR1J5ykq+ 0/4O7VBur2Sv9tgrMvql0kzZzuaMxyFWxbL9bNtkT3zcjrXHVxdhZOZLZo9Fs5AI MW+zRCwxNcbbMAoGCCqGSM49BAMCA0gAMEUCIFkPVySlkXTbg6mlEUbDGrABN+a2 V9aZR87f+1X+JKydAiEAwlccNJAVHQmkU5kVelXbx8UsVc66Q8Qt6QrT1L5Xg10= -----END CERTIFICATE----- -- Viktor. From viktor1dane@dukhovni.org Thu Dec 19 09:43:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7361B1AE320 for ; Thu, 19 Dec 2013 09:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsADrV3EpYuA for ; Thu, 19 Dec 2013 09:43:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BD67D1AE270 for ; Thu, 19 Dec 2013 09:43:11 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CC0F62AB01A; Thu, 19 Dec 2013 17:43:09 +0000 (UTC) Date: Thu, 19 Dec 2013 17:43:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131219174309.GC1285@mournblade.imrryr.org> References: <20131219160710.8908.47958.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131219160710.8908.47958.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-03.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 17:43:13 -0000 On Thu, Dec 19, 2013 at 08:07:10AM -0800, internet-drafts@ietf.org wrote: > Filename : draft-ietf-dane-srv-03.txt Another point I should raise is the question of when to perform TLSA lookups. In implementing DANE for Postfix, I found that it is unwise to search for TLSA RRs for an MX host whose hostname -> address mapping is insecure (that is when the MX RRset is in a secure zone, but the MX host is not). The example I posted to this group was nist.gov's MX RRset: ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com. ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 nist-gov.mail.protection.outlook.com. IN A 207.46.163.170 nist-gov.mail.protection.outlook.com. IN A 207.46.163.215 nist-gov.mail.protection.outlook.com. IN A 207.46.163.247 nist-gov.mail.protection.outlook.com. IN A 207.46.163.138 $ dig +dnssec +noall +comment +ans -t tlsa nist-gov.mail.protection.outlook.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14224 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 Attempts to retrieve the TLSA RRset SRVFAIL. Postfix (as likely should all other applications that want to find TLSA RRs) skips the TLSA lookup when the MX (form of SRV) host's zone is not secure. -- Viktor.