From cloos@jhcloos.com Sun Apr 1 10:50:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF57521F8B63 for ; Sun, 1 Apr 2012 10:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpM8vbqQPDbF for ; Sun, 1 Apr 2012 10:50:16 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id DA38721F8971 for ; Sun, 1 Apr 2012 10:50:16 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 7671840107; Sun, 1 Apr 2012 17:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1333302613; bh=6GNUoUk0UNOQ+hL80tiNA3b1KNJdJKjEyPAmnZ4cdWY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=z0HdvfZ0XHdA4ng1GC3DDwQ207qE176kEOw8qvWJjjnRS1Qg+zgWiFbzL6BmYbW0T EW9pVsjRfO5mK71WvHo5lErGW4DR+4hTl3Po9bt/u+ay8rdKIdV0TcfewvVLT3s+Is P0k0ESfYaBh7hNLVEdcH4iz3e0dRXtjeBGOtdTTo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C2F0536004B; Sun, 1 Apr 2012 17:49:35 +0000 (UTC) From: James Cloos To: Stephen Farrell In-Reply-To: <4F779EBF.2040609@cs.tcd.ie> (Stephen Farrell's message of "Sun, 01 Apr 2012 01:18:07 +0100") References: <4F779EBF.2040609@cs.tcd.ie> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 01 Apr 2012 13:49:35 -0400 Message-ID: Lines: 5 MIME-Version: 1.0 Content-Type: text/plain Cc: dane Subject: Re: [dane] base64 vs base64url X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:50:17 -0000 TLSA specified hex, not base64. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From stephen.farrell@cs.tcd.ie Sun Apr 1 12:00:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F1B21F8A7E for ; Sun, 1 Apr 2012 12:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTUXD48ug5h9 for ; Sun, 1 Apr 2012 12:00:57 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9044621F8A90 for ; Sun, 1 Apr 2012 12:00:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EC20E171C04; Sun, 1 Apr 2012 20:00:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333306846; bh=hUokhRCrxaXsI7 9j3Y3gBBh6ZzZ0fydP2lPT5syfJOw=; b=YIqmFWxLsp7/rR5OVwe2QfOGkMO4Ge zkt6APB9WWZcphpyYmT6JH9/WS3MN5s4FlNQ+MsxvbLMeqr5b0Cl0Qmo8LPxcoBh GZMeKlaanXTMkWgPcBS8FAePUYX89zknuj/Ycp9oIFPFR6evPeQeH+wJYHZQ8NBP +uSXt3rMgLoqprWUEzHPs6NmounRp3tzfBy8kDWN4js38r7LXhODl2L/kKCm/MTS s8W9LPdIlvbxqAGdlDOxheAUBqGj9P01R+/Z1BsoH6HHhHpZJGAspV/dtm5pD4oh pzob95oAFraS5YiQ/4uLsdpCo0a4O8goZO6dLfUD6q/BE53/tsNDiEkg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id BVWQZJ7aPz9u; Sun, 1 Apr 2012 20:00:46 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.31.132]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A3403171BFD; Sun, 1 Apr 2012 20:00:43 +0100 (IST) Message-ID: <4F78A5DB.90906@cs.tcd.ie> Date: Sun, 01 Apr 2012 20:00:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: James Cloos References: <4F779EBF.2040609@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dane] base64 vs base64url X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 19:00:57 -0000 On 04/01/2012 06:49 PM, James Cloos wrote: > TLSA specified hex, not base64. Oops, silly me. Yeah that's in 2.2 isn't it. Never mind, S. > > -JimC From paul.hoffman@vpnc.org Sun Apr 1 17:33:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE0321F8739 for ; Sun, 1 Apr 2012 17:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyHlkWBPofw3 for ; Sun, 1 Apr 2012 17:33:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C20A921F8738 for ; Sun, 1 Apr 2012 17:33:02 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q320X0KV040868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Apr 2012 17:33:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> Date: Sun, 1 Apr 2012 17:33:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 00:33:03 -0000 >> From: "Murray S. Kucherawy" >> Subject: AppsDir review of draft-ietf-dane-protocol-18 >> Date: March 31, 2012 1:39:56 PM PDT >> To: "apps-discuss@ietf.org" , = "draft-ietf-dane-protocol.all@tools.ietf.org" = >>=20 >> Major Issues (things I think the WG needs to think about, clarify, = reconsider, overhaul, describe better, fret about, talk me out of, = etc.): >> =20 >> Section 2.1.3: I don=92t know understand why this is a SHOULD. = Doesn=92t it have to match exactly? =20 The hash being described in 2.1.3 is *in addition* to the hash used in = the key's signature, so there is no matching between these two hashes. >> What=92s an example of a situation where one could/should/would = legitimately deviate from what this field says with a meaningful result? = =20 The person putting together the DNS record might not even know what's in = the certificate. >> The pseudocode in Appendix B leaves no room for SHOULD-style = evaluation, so maybe this really ought to be a MUST. The pseudocode gets this right: it's a second level of hash. >> Section 10: RFC1034 and RFC1035 should be normative references, = probably dragged in very early in this document. The examples in = Section 2.3 rely on zone file syntax defined there, and Appendix A.2 = includes quite a bit of material that requires DNS familiarity. A = reference for DNAME (I don=92t have it handy) would probably also be a = good idea, though that one could be informative. I'm leery of "you must understand DNS" being the same as "these two RFCs = are what you need to understand". There is a whole lot after RFCs = 103{4|5} that people need to understand to understand the DNS. How do = others feel about this? --Paul Hoffman From msk@cloudmark.com Sun Apr 1 21:33:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD4A11E80AF for ; Sun, 1 Apr 2012 21:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.949 X-Spam-Level: X-Spam-Status: No, score=-103.949 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnkg6aFhtV7V for ; Sun, 1 Apr 2012 21:33:35 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7E211E80AA for ; Sun, 1 Apr 2012 21:33:35 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Sun, 1 Apr 2012 21:33:34 -0700 From: "Murray S. Kucherawy" To: dane list Thread-Topic: [dane] AppsDir review of draft-ietf-dane-protocol-18 Thread-Index: AQHNEGgt/N/Oi9gbc0eufc+Jz/eezZaG75WA Date: Mon, 2 Apr 2012 04:33:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C478F@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 04:33:37 -0000 Hi Paul, thanks for the reply. > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Sunday, April 01, 2012 5:33 PM > To: dane list > Cc: Murray S. Kucherawy > Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 >=20 > >> Section 2.1.3: I don't know understand why this is a SHOULD. > >> Doesn't it have to match exactly? >=20 > The hash being described in 2.1.3 is *in addition* to the hash used in > the key's signature, so there is no matching between these two hashes. >=20 > >> What's an example of a situation where one could/should/would > >> legitimately deviate from what this field says with a meaningful > >> result? >=20 > The person putting together the DNS record might not even know what's > in the certificate. Ah, I see now. Then my question swings the other way: Is there a reason to= use SHOULD at all, since it's a hash of already-hashed data? What interop= erability > I'm leery of "you must understand DNS" being the same as "these two > RFCs are what you need to understand". There is a whole lot after RFCs > 103{4|5} that people need to understand to understand the DNS. How do > others feel about this? If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs that upda= te it. RFC1035 has 22. At least in our parlance, that means one might rea= sonably be expected to know or at least be familiar with (or be aware of) t= he full set if either or both of those are normative here. -MSK From msk@cloudmark.com Sun Apr 1 21:34:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7F011E80B0 for ; Sun, 1 Apr 2012 21:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD5zr8qyeGD3 for ; Sun, 1 Apr 2012 21:34:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4395211E8085 for ; Sun, 1 Apr 2012 21:34:47 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sun, 1 Apr 2012 21:34:46 -0700 From: "Murray S. Kucherawy" To: dane list Thread-Topic: [dane] AppsDir review of draft-ietf-dane-protocol-18 Thread-Index: AQHNEGgt/N/Oi9gbc0eufc+Jz/eezZaG75WAgAADOrA= Date: Mon, 2 Apr 2012 04:34:43 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C47A2@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 04:34:48 -0000 Terrific, I found some magic "send this now while I'm still typing" key seq= uence in this client. Apologies. > -----Original Message----- > From: Murray S. Kucherawy > Sent: Sunday, April 01, 2012 9:34 PM > To: dane list > Subject: RE: [dane] AppsDir review of draft-ietf-dane-protocol-18 >=20 > Ah, I see now. Then my question swings the other way: Is there a > reason to use SHOULD at all, since it's a hash of already-hashed data? > What interoperability ...is lost if this were to be removed, for example? -MSK From lconroy@insensate.co.uk Mon Apr 2 03:00:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511BF21F895B for ; Mon, 2 Apr 2012 03:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcx-v1BllvnG for ; Mon, 2 Apr 2012 03:00:32 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7971021F895C for ; Mon, 2 Apr 2012 03:00:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id C55B5677B9F; Mon, 2 Apr 2012 11:00:29 +0100 (BST) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re4cy-QigJ4g; Mon, 2 Apr 2012 11:00:28 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 54BAF677B94; Mon, 2 Apr 2012 11:00:28 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <9452079D1A51524AA5749AD23E0039280C478F@exch-mbx901.corp.cloudmark.com> Date: Mon, 2 Apr 2012 11:00:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> <9452079D1A51524AA5749AD23E0039280C478F@exch-mbx901.corp.cloudmark.com> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1084) Cc: dane list Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 10:00:33 -0000 Hi Murray, folks, True, and useful to know, but ... In the time I've been using the RFC series, I've always used the ASCII = versions of referenced RFCs, which are not updated (and so don't have = this metadata). Yes, one *could* get the latest copy of rfc-index to see the metadata = for any RFC, or use this new-fangled online mechanism to get it. However, I would prefer that an RFC references the docs we expect = implementers to read (and so, in effect, carries its own metadata). Particularly with DNS, there is such a thicket of docs, searching = through all of the "updated by" docs to see if the section they update = is the one germane to this document is a tad harsh. (IMHO) that would not help interop as implementers shouldn't NEED to be = experts in the RFC series. -- look through this ML for the Talmudic discussions there have been to = see the fun that may raise. all the best, Lawrence On 2 Apr 2012, at 05:33, Murray S. Kucherawy wrote: > If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs that = update it. RFC1035 has 22. At least in our parlance, that means one = might reasonably be expected to know or at least be familiar with (or be = aware of) the full set if either or both of those are normative here. >=20 > -MSK From paul.hoffman@vpnc.org Mon Apr 2 05:23:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB521F8848 for ; Mon, 2 Apr 2012 05:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyzBBSRUQLNM for ; Mon, 2 Apr 2012 05:23:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC3C21F8846 for ; Mon, 2 Apr 2012 05:23:58 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32CNj8S058981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 05:23:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <9452079D1A51524AA5749AD23E0039280C478F@exch-mbx901.corp.cloudmark.com> Date: Mon, 2 Apr 2012 05:23:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <876DD67E-1565-40F5-B83A-0C2C9D08491C@vpnc.org> References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> <9452079D1A51524AA5749AD23E0039280C478F@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1257) Cc: dane list Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 12:23:58 -0000 On Apr 1, 2012, at 9:33 PM, Murray S. Kucherawy wrote: >>>> Section 2.1.3: I don't know understand why this is a SHOULD. >>>> Doesn't it have to match exactly? >>=20 >> The hash being described in 2.1.3 is *in addition* to the hash used = in >> the key's signature, so there is no matching between these two = hashes. >>=20 >>>> What's an example of a situation where one could/should/would >>>> legitimately deviate from what this field says with a meaningful >>>> result? >>=20 >> The person putting together the DNS record might not even know what's >> in the certificate. >=20 > Ah, I see now. Then my question swings the other way: Is there a = reason to use SHOULD at all, since it's a hash of already-hashed data? = What interoperability is lost if this were to be removed, for example? Assume that the inner hash algorithm (on the certificate) is SHA1 and = the outer hash algorithm (on DNSSEC) is SHA256. We know that the relying = party MUST have SHA1 in order to validate the signature in the = certificate, but they might not have SHA256 on their computer. By saying = "you should use the same alg if you know it", we're saying "this is more = likely to work". >> I'm leery of "you must understand DNS" being the same as "these two >> RFCs are what you need to understand". There is a whole lot after = RFCs >> 103{4|5} that people need to understand to understand the DNS. How do >> others feel about this? >=20 > If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs that = update it. RFC1035 has 22. At least in our parlance, that means one = might reasonably be expected to know or at least be familiar with (or be = aware of) the full set if either or both of those are normative here. Noted. I'm going to take this one to the DNSEXT WG mailing list to see = what they say. --Paul Hoffman From msk@cloudmark.com Mon Apr 2 10:17:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6C21F85F9 for ; Mon, 2 Apr 2012 10:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGO3UTAuprGZ for ; Mon, 2 Apr 2012 10:17:38 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6921F8565 for ; Mon, 2 Apr 2012 10:17:38 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 2 Apr 2012 10:17:37 -0700 From: "Murray S. Kucherawy" To: Paul Hoffman Thread-Topic: [dane] AppsDir review of draft-ietf-dane-protocol-18 Thread-Index: AQHNEGgt/N/Oi9gbc0eufc+Jz/eezZaG75WAgAD72ID//9x3wA== Date: Mon, 2 Apr 2012 17:17:36 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C5600@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> <9452079D1A51524AA5749AD23E0039280C478F@exch-mbx901.corp.cloudmark.com> <876DD67E-1565-40F5-B83A-0C2C9D08491C@vpnc.org> In-Reply-To: <876DD67E-1565-40F5-B83A-0C2C9D08491C@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dane list Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:17:38 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Monday, April 02, 2012 5:24 AM > To: Murray S. Kucherawy > Cc: dane list > Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18 >=20 > > Ah, I see now. Then my question swings the other way: Is there a > > reason to use SHOULD at all, since it's a hash of already-hashed data? > > What interoperability is lost if this were to be removed, for example? >=20 > Assume that the inner hash algorithm (on the certificate) is SHA1 and > the outer hash algorithm (on DNSSEC) is SHA256. We know that the > relying party MUST have SHA1 in order to validate the signature in the > certificate, but they might not have SHA256 on their computer. By > saying "you should use the same alg if you know it", we're saying "this > is more likely to work". Excellent. I suggest adding a sentence or two to tie this all together. > > If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs > > that update it. RFC1035 has 22. At least in our parlance, that means > > one might reasonably be expected to know or at least be familiar with > > (or be aware of) the full set if either or both of those are normative > > here. >=20 > Noted. I'm going to take this one to the DNSEXT WG mailing list to see > what they say. Also excellent. Thanks for the follow-up. -MSK From paul.hoffman@vpnc.org Tue Apr 3 08:43:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08411E810D for ; Tue, 3 Apr 2012 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, FRT_BELOW2=2.154, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRIviVu627KD for ; Tue, 3 Apr 2012 08:43:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6409B11E80FF for ; Tue, 3 Apr 2012 08:43:16 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q33FhE3s010809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Apr 2012 08:43:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 3 Apr 2012 08:43:14 -0700 References: <20120403143833.GL15938@registro.br> To: dane list Message-Id: <7E113308-ABE6-4AA6-9AA0-41622FD0071D@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Fwd: [dnsext] TLSA RRTYPE review - result [IANA #550878] X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 15:43:17 -0000 Begin forwarded message: > From: Frederico A C Neves > Subject: Re: [dnsext] TLSA RRTYPE review - result [IANA #550878] > Date: April 3, 2012 7:38:33 AM PDT > To: dnsext@ietf.org > Cc: iana-prot-param@iana.org > > Dear Colleagues, > > This message ends the review process for the TLSA RRTYPE. According to > my judgment this request meets RFC6195 at both requirements of section > 3.1.1 and none of section 3.1.2 and should be accepted. > > Best Regards, > Frederico Neves > > On Tue, Mar 13, 2012 at 12:55:08AM -0300, Frederico A C Neves wrote: >> Dear Colleagues, >> >> Bellow is a completed template requesting a new RRTYPE assignment >> under the procedures of RFC6195. >> >> This message starts a 3 weeks period for an expert-review of the DNS >> RRTYPE parameter allocation for TLSA specified in >> http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt >> IANA #550878 >> >> If you have comments regarding this request please post them here >> before Apr 3rd 18:00 UTC. >> >> Best Regards, >> Frederico Neves >> >> --begin 6195 template TLSA-- >> A. Submission Date: 12 March 2012 >> >> B. Submission Type: >> [X] New RRTYPE >> [ ] Modification to existing RRTYPE >> >> C. Contact Information for submitter (will be publicly posted): >> Name: Warren Kumari >> Email Address: warren@kumari.net >> International telephone number: +1-571-748-4373 >> Other contact handles: >> >> D. Motivation for the new RRTYPE application. >> Encrypted communication on the Internet often uses Transport Level >> Security (TLS), which depends on third parties to certify the keys >> used. The allocation of this RRTYPE will improve this situation by >> enabling the administrator of a domain name to certify the keys used >> in that domain's TLS servers by publishing information in the DNS. >> >> E. Description of the proposed RR type. >> A description of the RRtype is in >> draft-ietf-dane-protocol-18.txt, Section 2 The TLSA Resource Record >> ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt ) >> >> F. What existing RRTYPE or RRTYPEs come closest to filling that need >> and why are they unsatisfactory? >> The CERT (37) RR, RFC 4398 is closest. It is not suitable for this >> particular use as it is not flexible enough. It *would* be possible >> to shoehorn this into the CERT RR, but would be very kludgy. >> >> G. What mnemonic is requested for the new RRTYPE (optional)? >> TLSA >> >> H. Does the requested RRTYPE make use of any existing IANA registry >> or require the creation of a new IANA sub-registry in DNS >> Parameters? If so, please indicate which registry is to be used >> or created. If a new sub-registry is needed, specify the >> allocation policy for it and its initial contents. Also include >> what the modification procedures will be. >> >> This is in the the draft >> (http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt). >> >> It is included here for completeness, but reviewers are encouraged to >> consult the draft as the formatting is cleaner. >> >> #1: TLSA Usages. >> A new registry, "Certificate Usages for TLSA Resource Records". >> The registry policy is "RFC Required". >> The initial entries in the registry are: >> Value Short description Reference >> ---------------------------------------------------------- >> 0 CA constraint [This] >> 1 Service certificate constraint [This] >> 2 Trust anchor assertion [This] >> 3 Domain-issued certificate [This] >> 4-254 Unassigned >> 255 Private use >> >> #2: TLSA Selectors >> A new registry, "Selectors for TLSA Resource Records". >> The registry policy is "Specification Required". >> The initial entries in the registry are: >> Value Short description Reference >> ---------------------------------------------------------- >> 0 Full Certificate [This] >> 1 SubjectPublicKeyInfo [This] >> 2-254 Unassigned >> 255 Private use >> >> #3: TLSA Matching Types >> A new registry, "Matching Types for TLSA Resource Records". >> The registry policy is "Specification Required". >> The initial entries in the registry are: >> Value Short description Reference >> -------------------------------------------------------- >> 0 No hash used [This] >> 1 SHA-256 RFC 6234 >> 2 SHA-512 RFC 6234 >> 3-254 Unassigned >> 255 Private use >> >> I. Does the proposal require/expect any changes in DNS >> servers/resolvers that prevent the new type from being processed as an >> unknown RRTYPE (see [RFC3597])? No. >> >> J. Comments: >> A number of participants in DNSEXT / DNSOPS (and the DNS Directorate) >> have been involved in / following / are aware of this work. >> --end 6195 template TLSA-- > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ondrej.sury@nic.cz Fri Apr 6 00:32:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AA921F85EA for ; Fri, 6 Apr 2012 00:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.211 X-Spam-Level: X-Spam-Status: No, score=-0.211 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf4dX+EJP8BM for ; Fri, 6 Apr 2012 00:32:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52621F85E4 for ; Fri, 6 Apr 2012 00:32:13 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75] (unknown [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75]) by mail.nic.cz (Postfix) with ESMTPSA id 4BB3213F871; Fri, 6 Apr 2012 09:32:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333697532; bh=H5NgmPdXMXVU2mUbr1SVwFz9InZiT76qJtaOiTumbUk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bMawaBB5VSNnmtH38gihobG3tWo6KTbyq9xEAaVMPn0oxKHfyw+HJBPq9k4d5A+o7 LBXpOMPCp93ZD/f+vCLMFrDu+uDLf+gsWMOKyfGahf7b62nYCDbFBkEoUgbZLSt7vy 5Q594xtgLoZ7sXikcOp87EIACHAoS+iXiLeQsMHU= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <49B930F7-FCAD-44D0-8413-BE61A62D3661@vpnc.org> Date: Fri, 6 Apr 2012 09:32:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E0A1840-8010-48DE-90D6-A0B169CEA220@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <49B930F7-FCAD-44D0-8413-BE61A62D3661@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane WG list Subject: Re: [dane] 1: Q for 1.3 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 07:32:16 -0000 On 20. 3. 2012, at 14:48, Paul Hoffman wrote: > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >> 1. What does this, in 1.3, mean? "This document does not specify how >> DNSSEC validation occurs because there are many different proposals = for >> how a client might get validated DNSSEC results." We've just said = that >> DNSSEC signatures MUST be validated and referenced DNSSEC RFCs, so = what >> "different proposals" do you mean and why have they no references? This means that you can get DNSSEC validated results either: a) from the DNSSEC-aware resolver coded in the application b) from trusted localhost DNSSEC resolver c) from trusted DNSSEC resolver over a secured channel (TSIG, SIG0, = IPSEC) d) from trusted DNSSEC resolver over a secured network (802.11x = networks) We may add an reference to RFC4033 Section 7 here. Ondrej -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 00:34:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1617F21F85E7 for ; Fri, 6 Apr 2012 00:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv-+HkEAWTIK for ; Fri, 6 Apr 2012 00:34:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D467221F85E6 for ; Fri, 6 Apr 2012 00:34:43 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 2FE8913F871; Fri, 6 Apr 2012 09:34:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333697683; bh=RUC6HMIti15GUnqQYjXA78OynlkfLnlGqk28nYKNDL0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CQkKSdlYADykddI3LuaEOnqbsfI83+yVyJ/r4CXNDbyeTDDl90Dm9pf2VJ4RBNB5D t6U4VjcwPzl0gcDVu8FItg6AJq21/9EftbYv+HYAe5k2/C/iplnjo2YXI0MRZb2nv1 7nQiBuN8ytHmYXMpqcqXn+wHnxWpSdl2GZ3o5kNA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> Date: Fri, 6 Apr 2012 09:34:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane Subject: Re: [dane] 2: Usage 0 clarity X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 07:34:45 -0000 On 20. 3. 2012, at 14:49, Paul Hoffman wrote: > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >=20 >> 2. Is usage 0 clear enough? For example, a CA cert that's not a trust >> anchor will have a basicConstraints extension with cA set, but a = trust >> anchor need not have that, so should usage 0 mean "CA certificate or >> trust anchor" or is it just worth noting that the associated = certificate >> in this usage can be either? I have no strong opinion on this (or rather I am inclined to "CA = certificate or trust anchor" because that's what I think we originally meant). What the WG think? O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 00:41:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8469921F8630 for ; Fri, 6 Apr 2012 00:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.714 X-Spam-Level: X-Spam-Status: No, score=0.714 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn9MFUlZeXDR for ; Fri, 6 Apr 2012 00:41:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C2C0521F862F for ; Fri, 6 Apr 2012 00:40:59 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75] (unknown [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75]) by mail.nic.cz (Postfix) with ESMTPSA id 1244213F871; Fri, 6 Apr 2012 09:40:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333698059; bh=KCT8RDMo8ywSb+jpZr+0+HQ8FD3+Nm0+I3ARb9dZd4U=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ChUlf/v4QW4iTGcF0XtICn0TWgGXuKWELKFqGwk5KBHng7CGzjYMEnpB+5yf4fuZL H0c7SgfwIUc5zMH/KytMRbnAAEw7d0l5n0pgwTT+l35+qV5/LBVwTjDirCZx+Jjc0K BCYSWokVDoJk8gt/eJQm4GYqYGbgiCGdkyk58Yxc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 6 Apr 2012 09:40:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <309B64BC-3E42-428C-AC80-8E1D1C0E51F2@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list Subject: Re: [dane] 4: Length of certificate association data field X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 07:41:00 -0000 On 20. 3. 2012, at 16:36, Paul Hoffman wrote: > On Mar 20, 2012, at 7:55 AM, Jim Schaad wrote: >=20 >> The length of the field is well known because it is every left in the = TLSA >> RDATA record. The more interesting question is what happens if there = are >> extra bytes on the end of the data block. This should probably be an = error. >> But the length of the data field is computed from the TLSA RDATA = record and >> not from the contents of the record. >=20 > Agree. I'm pretty sure this is an error that would be caught in the = software signing the zone. I don't see what we can say in 2.1.4 that = would not just be confusing, but am open to suggestions. +1 Section 2.1.4 says: The "certificate association data" to be matched. This field contains the data to be matched. [...] I just cannot think of any sentence which would not be superfluous = (anything like "the data must match exactly" is superfluous in my view). I am inclined to let this be, but if somebody has better suggestion then = hey go ahead and send the text. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 00:42:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218EB21F8645 for ; Fri, 6 Apr 2012 00:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLC7BoD-vsPM for ; Fri, 6 Apr 2012 00:42:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 99F7321F8644 for ; Fri, 6 Apr 2012 00:42:20 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id ECDC613F871; Fri, 6 Apr 2012 09:42:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333698139; bh=DH2yWr5SZE8feph76RPzkOCC5D/uiJsrHUbAiDNUvcY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qD4zStAZjTWVrHEydSW3EDczsmrK6ZnQCd+9Fpzo24prPGto/j+FmHsU/t0p+MQgb LK0iEqAVoTBRokZaExajR+PhBEYqudjXavymgkNTe/qwmceUDAgtLV2xreaSn7oIi3 9xdu0RLgQiwaO3eYHqkyuApS0tQO72MA4ORX2IKw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 6 Apr 2012 09:42:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <640E0A57-81AF-4988-B059-3C3BF7CFFA87@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <261E1F5D-DEEE-4453-8679-D5F3B00852E8@vpnc.org> <021001cd06aa$0d809530$2881bf90$@augustcellars.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list Subject: Re: [dane] 6: No matching associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 07:42:21 -0000 On 20. 3. 2012, at 16:39, Paul Hoffman wrote: > On Mar 20, 2012, at 7:59 AM, Jim Schaad wrote: >=20 >> Fair enough comment. >> Suggested text >>=20 >> If an application fails to match any certificate association, then = the TLS >> session is aborted or never started. >=20 > I think that is OK, but would rather be clearer: >=20 > During the TLS handshake, if none of the certificate associations = matches the certificate given by the TLS server, the TLS client MUST = abort the handshake. LGTM, unless I hear any objections from WG, I will ask our authors to = implement this. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 00:50:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9044721F864A for ; Fri, 6 Apr 2012 00:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.714 X-Spam-Level: X-Spam-Status: No, score=0.714 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVfyCob5ePFN for ; Fri, 6 Apr 2012 00:50:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D44D521F8649 for ; Fri, 6 Apr 2012 00:50:33 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75] (unknown [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75]) by mail.nic.cz (Postfix) with ESMTPSA id 2C80713F871; Fri, 6 Apr 2012 09:50:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333698633; bh=/qmEIqHAG5UIH6CvfEsFa+Y1U2l8g2OG8WTwqSo1js8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=b6X2khvwjENwe5dUXohkA+auwMZf43q33SNqGzn2N7oFF5sIaxShvafh8fSYMaeXl MgFEkTotP6hKOEwj99EkTOaw4ttxLT8tXytlLaSHP/y/ADcW3PTCpfBfvs133yW3JY WzsXOjNQzRZouPwcppvcf+qRfD37jTMvgNMKJj3Y= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 6 Apr 2012 09:50:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list Subject: Re: [dane] 7: Extra vulnerability of #3 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 07:50:34 -0000 On 20. 3. 2012, at 14:54, Paul Hoffman wrote: > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >=20 >> 7. Section 8, 2nd para - usage #3 is particularly vulnerable here >> right? I think that'd be worth calling out, or am I wrong? Usage #2 is exactly same in this regard... and since he has control of MX records of the zone, he is also able to = receive emails for hostmaster@ and so Usage #0 and Usage #1 is = also vulnerable for domain-issued certificates. E.g. usage #3 is only fastest (and together with usage #2 cheapest), but = the difference is counted only in minutes. And we already say that: That administrator could probably get a certificate issued anyway, so this is not an additional threat. But I am open to hear any suggestions how to improve the text. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 00:53:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFDC21F84EC for ; Fri, 6 Apr 2012 00:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqBxRAi0UMip for ; Fri, 6 Apr 2012 00:53:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4221F848A for ; Fri, 6 Apr 2012 00:53:21 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 6253213F871; Fri, 6 Apr 2012 09:53:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333698800; bh=WGyDC05ndu+jSyLR9cim5/fh6NtVIvYeLMt2k8OcS54=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=M0j+kVNNMqUmWbz+mSUcmqDN0eDZ6O58rB7YCMGU1KrBD5KTIUyUIed5mXdcSkkyx WThEMH4IJ4FdMksW7kRYmIJQWkCpFTmc/sGSUe3C84Nxb/E8bK62kMIKAWSBFxd7BN R2Ba57+47UYZb2/1hRzBsXuFdVe9gkmq2YP5Hqcc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <000c01cd073b$36c35bd0$a44a1370$@augustcellars.com> Date: Fri, 6 Apr 2012 09:53:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201203210135.q2L1ZEWD001880@new.toad.com> <000c01cd073b$36c35bd0$a44a1370$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: 'dane list' Subject: Re: [dane] Security consideration "local policy" distrusting usages 2 and 3 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 07:53:22 -0000 +1 to what Jim said. On 21. 3. 2012, at 9:18, Jim Schaad wrote: > John, >=20 > The issue is one of explicitly known when a trust decision is being = made. > While many people argue that one does not know for Windows when this > decision is made as it gets farmed out to Microsoft, this is not true = for > all configurations and for all other operating systems. =20 >=20 > The statement does not say that you cannot trust it just because it is = in > the DNS records, it says that some people may not do so or may do so = only > under some circumstances. >=20 > This is not an issue for type 0 or 1 records as the trust decision is = made > elsewhere. >=20 > I guess it is no more of a back hand way of saying that some people = will not > trust it than DANE is a back handed way of saying that PKI is = untrustworthy > which is being said in this document. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> John Gilmore >> Sent: Tuesday, March 20, 2012 6:35 PM >> To: dane list; gnu@toad.com >> Subject: [dane] Security consideration "local policy" distrusting = usages 2 > and 3 >>=20 >> In the last paragraph of Section 8 of -18, we have this new text: >>=20 >> The client's full trust of a certificate retrieved from a TLSA = record >> with a certificate usage type of 2 or 3 may be a matter of local >> policy. While such trust is limited to the specific domain nane = for >> which the TLSA query was made, local policy may deny the trust or >> further restrict the conditions under which that trust is = permitted. >>=20 >> Text similar to this was proposed by Jim Schaad on March 4th. Ondrej >> responded LGTM ("Looks Good To Me"). I missed this proposed change = at >> that time. >>=20 >> I don't see why usage types 2 and 3 are specifically called out here = as >> untrustworthy. >>=20 >> It seems to me that local policy can override anything we say in an = RFC, >> anytime, anywhere. Local policy may break interoperability, of = course, > but >> that's usually intentional (e.g. the locals don't trust some = particular > domain >> name or key, so don't WANT to interoperate with it). We specify this = in >> Section 4: >>=20 >> o A TLSA RRset whose DNSSEC validation state is secure MUST be = used >> as a certificate association for TLS unless a local policy would >> prohibit the use of the specific certificate association in the >> secure TLSA RRset. >>=20 >> But this new graf in Section 8 isn't about local policy about = specific > names or >> keys. It seems like a back-handed attempt to discredit the security = of > keys >> that are certified only by TLSA records (rather than by a = certification > chain >> headed by one of the existing CA businesses' >> trust anchors). The suggestion is that it would be a good idea for > software >> that implements TLSA to be configurable to "deny the trust" >> of any certificate that arrives with usage types 2 or 3. If that is = the > intent, this >> text doesn't belong in the very document that specifies that we think = we >> HAVE defined a protocol that communicates such keys securely. >>=20 >> If we wouldn't include similar text about usage types 0 or 1, why do = we > now >> have such a statement exclusively about types 2 and 3? If we = recommend >> making software configurable to turn off specific usage types in = specific >> clients, this will make interoperability fail. >>=20 >> We currently have text in Section 6 that mandates that clients MUST >> implement all four usage types. This permits server operators to = choose > any >> usage type that fits their circumstances, relying on the fact that = any >> standards-conforming TLSA client can interoperate with their server. = I > don't >> see how the new suggestion to distrust types 2 and 3 is compatible = with > this >> MUST. >>=20 >> My proposal is to remove the paragraph. (If there is some reason to = keep >> and modify it, please explain why.) >>=20 >> John >>=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 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 00:55:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F05421F8610 for ; Fri, 6 Apr 2012 00:55:48 -0700 (PDT) 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=[AWL=1.207, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdASavNqbjdR for ; Fri, 6 Apr 2012 00:55:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 63EC121F85F4 for ; Fri, 6 Apr 2012 00:55:47 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75] (unknown [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75]) by mail.nic.cz (Postfix) with ESMTPSA id B361A13F871; Fri, 6 Apr 2012 09:55:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333698946; bh=2M3jbcOrdwmMUPQweBG0l8pUB5DJXZCoPSo/2hpGEzI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ilUgFr3Nw8EHMwfKytmUP479lIu5KjSmIW/+97UDn5igm9ta/DGFwJPvQ00BZvOUS KgI3RfEHJIfu5gjgry7hi6IEcnWmfug+W/tiY09FIq9WYMGeOmIiPN9ikeMCoVU+eG 8YeN0dTB9Tptiy2HApFgNfM4I6sEnkZ/LYfLliCo= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4F692974.3080607@cs.tcd.ie> Date: Fri, 6 Apr 2012 09:55:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43372D5C-104A-41F1-BAC3-091BBD30AB63@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <039A072B-931A-45F4-B646-6B581EF16800@vpnc.org> <201203210059.q2L0xaWD032433@new.toad.com> <4F692974.3080607@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list , Paul Hoffman Subject: Re: [dane] 3: SHA-384 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 07:55:48 -0000 I take it that this was resolved and we don't need code point for = sha-384. Thanks John for the nice argument. O. On 21. 3. 2012, at 2:05, Stephen Farrell wrote: >=20 >=20 > On 03/21/2012 12:59 AM, John Gilmore wrote: >>>> 3. In another context the fact that sha-384 is part of the US' = suite-B >>>> (see e.g. RFC 5430) was brought up recently. Should there be a >>>> code-point for sha-384? I don't care, but I don't recall if that = was >>>> considered in the WG discussion. >>=20 >> TLSA does not need a code point for sha-384. >=20 > FWIW, I've no problem with the argument below. >=20 > S >=20 > > The only use that TLSA >> makes of the specified hash function is for matching the hash in the >> TLSA record with the certificate or its SubjectPublicKeyInfo. This >> matching is independent of the use of hashes within the TLS protocol >> itself (where sha-384 is mandatory among products designed for US >> government TOP SECRET use under NSA's "Suite B" program). The >> presence of TLSA record(s) do not interfere with the use of sha-384 = in >> TLS itself. >>=20 >> A Suite B server operator who wishes to use TLSA to associate their >> domain name with a certificate or a public key, without using an >> unapproved hash function, need only supply the entire >> SubjectPublicKeyInfo, or the entire certificate, in their TLSA = record. >> They can simply avoid the use of hashes in their TLSA records. >> This option is fully supported by the draft as it stands, and >> provides better security than any hash they could have picked. >>=20 >> In addition, I suspect that NSA would, upon reflection, also approve >> the use of SHA-512 in cases where SHA-384 is not available, such as >> this one. (If they wouldn't, then we'd like to know why they trust >> SHA-384 but don't trust SHA-512!) >>=20 >> We do recommend in 2.1.3 that if the host operator uses a hash in the >> TLSA record, the record "SHOULD" use the same hash that was used in >> the signature in the certificate, to assist clients that support a >> small number of hash algorithms. This SHOULD does not come into play >> if the operator does not use a hash, as recommended above. Also, >> it's a SHOULD, not a MUST, and given the ready availability of free >> software that implements it, most clients that support any SHA-xxx >> algorithm will support all three SHA-256, -384, and -512 algorithms. >>=20 >> John >> _______________________________________________ >> 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 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 01:01:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3D21F85AD for ; Fri, 6 Apr 2012 01:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ax6-0bn6knS for ; Fri, 6 Apr 2012 01:01:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3965F21F8585 for ; Fri, 6 Apr 2012 01:01:43 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 036BB13F871; Fri, 6 Apr 2012 10:01:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333699302; bh=MiJdU1cReF0ZNuABPVK34o4QaiHhHKrjHTdrx+whdCQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gFD3pSX3B61y/wvfEHkgGBK/dAqAlv2SDIdI5tPCZ13AN+xslSo+PSs9BFHUCiVs/ VdOhuBWdNqNq0CNV2ZrPFA2doIYotBzLAG1AwiaVpikEdZGzsfscIZxnOFL+Arp9Z+ zNUZNjGDUSLHFu+5L8PpDYhNfaKQwc0PcEeq6deM= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 6 Apr 2012 10:01:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <95FDE649-1E26-4A2D-9D15-73CF5ACEDE27@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 08:01:44 -0000 Paul, are you and Jakob able to cook something into Security Considerations or do you need more guidance from the WG on the text? O. On 20. 3. 2012, at 23:24, Jim Fenton wrote: > But a given DANE client is likely to trust only one (or a small = number) > of DNSSEC validators, as compared with the 100+ root CAs that usually > need to be trusted. Or looking at it another way, compromise of a = given > DNSSEC validator is likely to impact a smaller number of clients than > compromise of a given root CA. >=20 > And a client has the choice whether to use an external DNSSEC = validator > at all, which isn't really practical with public CAs. >=20 > I would say that both of these factors mitigate the risk. On 20. 3. 2012, at 18:13, Paul Hoffman wrote: > On Mar 20, 2012, at 9:46 AM, Stephen Farrell wrote: >=20 >> It was probably a mistake for me to use disrepute >> here. (I had a separate comment on the editorial >> aspect I think.) Its a question about comparing >> the risk today for TLS clients vs. the risk for >> DANE clients using external DNSSEC validators. >>=20 >> It seems to me that a DANE client trusting an external >> DNSSEC validator is as vulnerable as a current TLS >> client trusting a set of CAs in that any CA or any >> external validator can assert any key for any domain. >>=20 >> If that's true, and if we're less likely to hear about >> DNSSEC validators being hacked (compared to public CA >> compromises) then a DANE client with an external >> validator could be worse off than a current TLS client >> depending on the current public CAs. >>=20 >> The counter-argument is probably that a random DNSSEC >> validator is a less interesting target than a public >> CA which may affect the probability of a problem >> occurring that affects a given DANE client. OTOH, >> public CAs ought to have more defenses compared to >> that random DNSSEC validator, and some external >> DNSSEC validators will be attractive targets, so >> its not clear to me how the overall risk for a >> client pans out, when comparing the status quo >> (today's TLS client) vs. a DANE client with an >> external DNSSEC validator. >>=20 >> But the impact on the client is the same, its >> vulnerable to being presented with the wrong key >> for any domain and accepting that. >>=20 >> So my question might be better phrased as: is the >> above correct, and if so, is text needed to call >> that out in the draft? >>=20 >=20 > I would say "yes", this seems like a reasonable security consideration = that isn't covered in the security considerations in the DNSSEC specs. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 6 01:11:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA98F21F863E for ; Fri, 6 Apr 2012 01:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw7QL1-zjulc for ; Fri, 6 Apr 2012 01:11:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AFBAE21F863C for ; Fri, 6 Apr 2012 01:11:18 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75] (unknown [IPv6:2001:1488:ac14:1400:7c88:7ef0:a905:2c75]) by mail.nic.cz (Postfix) with ESMTPSA id 0849E13F871; Fri, 6 Apr 2012 10:11:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333699878; bh=nWgC/FLN1dswykaUFVVAxKMZMlDF7Xaz8X4UtWvV74k=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SytH9P0qA8HFPPCdSlzDezQYQFLjkN+Beos7j3Bfcc44gDNQq8/Em0mR0mLodb7tk svYrChWzdPZhJzqMOUGsOQwq8IqbMNtPU7iHjQtNObAsV8lWxp/4lT/XQLB4V1L5xK fdBSC3MMHkUvDRUKEqRArNuRt4Va0j49IknFLDI0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 6 Apr 2012 10:11:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> To: Stephen Kent X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane list , Paul Hoffman Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 08:11:20 -0000 Stephen, did you meant this text: On 21. 3. 2012, at 19:34, Stephen Kent wrote: > What I would say is: >=20 > The public CA model upon which browsers and OS's depend is = fundamentally vulnerable, not because it is PKI-based, but because it = allows any of these CAs to issue any certificate, with no constraints. = Business models adopted by browser and OS vendors, and by the public = CAs, have allowed this model to be exploited, with predictable = consequences. Recent experiences with compromises of CAs or RAs have = lead to very serious security problems that undermine confidence in this = system. >=20 > DANE is envisioned as a preferable basis for binding public keys to = DNS names (a subset of what PKIs can do in general) because the entities = that vouch for the binding of public key data to DNS names are the = entities responsible to managing the DNS names in question. While the = resulting system still has residual security vulnerabilities, it = restricts the scope of assertions that can be made by any entity, = consistent with the naming scope imposed by the DNS hierarchy. As a = result, DANE embodies the security "principle of least privilege" that = is lacking in the current public CA model. as a general statement in the discussion or a kind of replacement for = paragraph in 1.1: This solution has gradually broken down because some CAs have become untrustworthy. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can compromise any other certificate that TLS uses by signing a replacement certificate that contains a bogus key. Several real-world occurrances that have exploited such CAs for subversion of major web sites (presumably to abet wiretapping and large-scale fraud) have brought TLS's CA model into disrepute. I don't think this is really an ideological statement, but I think it = could be worded little bit better to not stir emotions. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ietf@augustcellars.com Fri Apr 6 09:25:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1309B21F8592 for ; Fri, 6 Apr 2012 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qWZXDcJRz4d for ; Fri, 6 Apr 2012 09:25:42 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 330A021F851E for ; Fri, 6 Apr 2012 09:25:42 -0700 (PDT) Received: from Tobias (50-54-163-209.evrt.wa.frontiernet.net [50.54.163.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 609B638F1F; Fri, 6 Apr 2012 09:25:41 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= , "'Paul Hoffman'" References: <4F6877E7.5030905@cs.tcd.ie> <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> In-Reply-To: Date: Fri, 6 Apr 2012 09:24:46 -0700 Message-ID: <00a401cd1411$c9679220$5c36b660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLdEkJTdlG4Ptyjkg0KDRjvaKCa5QLQFdl7AyYJs8SUPkzFEA== Content-Language: en-us Cc: 'dane' Subject: Re: [dane] 2: Usage 0 clarity X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 16:25:43 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Friday, April 06, 2012 12:35 AM > To: Paul Hoffman > Cc: dane > Subject: Re: [dane] 2: Usage 0 clarity >=20 >=20 > On 20. 3. 2012, at 14:49, Paul Hoffman wrote: >=20 > > On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > > > >> 2. Is usage 0 clear enough? For example, a CA cert that's not a = trust > >> anchor will have a basicConstraints extension with cA set, but a > >> trust anchor need not have that, so should usage 0 mean "CA > >> certificate or trust anchor" or is it just worth noting that the > >> associated certificate in this usage can be either? >=20 >=20 > I have no strong opinion on this (or rather I am inclined to "CA = certificate or > trust anchor" because that's what I think we originally meant). >=20 > What the WG think? I am ambivalent about this in either direction. To say that it includes the trust anchor may cause problems if the full = certificate comparison is used as not all trust anchors are stored on = all machines in the certificate format. =20 To say that it cannot include the trust anchor may cause problems = because the server has no way to know which certificates I have chosen = for the trust anchor. I would say that 1. This SHOULD NOT be the certificate that the server is using as the = trust anchor as in that case the certificate use of 2 would be more = appropriate 2. This MAY be the certificate that the client is using as the TA = assuming that the client is using certificates as trust anchor = certificates. Jim >=20 > O. > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ietf@augustcellars.com Fri Apr 6 09:27:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D304F21F84F6 for ; Fri, 6 Apr 2012 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNHIq7smKPu9 for ; Fri, 6 Apr 2012 09:27:06 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6F621F84D3 for ; Fri, 6 Apr 2012 09:27:06 -0700 (PDT) Received: from Tobias (50-54-163-209.evrt.wa.frontiernet.net [50.54.163.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 374EA38F1C; Fri, 6 Apr 2012 09:27:06 -0700 (PDT) From: "Jim Schaad" To: =?utf-8?Q?'Ondrej_Sur=C3=BD'?= , "'Paul Hoffman'" References: <4F6877E7.5030905@cs.tcd.ie> <261E1F5D-DEEE-4453-8679-D5F3B00852E8@vpnc.org> <021001cd06aa$0d809530$2881bf90$@augustcellars.com> <640E0A57-81AF-4988-B059-3C3BF7CFFA87@nic.cz> In-Reply-To: <640E0A57-81AF-4988-B059-3C3BF7CFFA87@nic.cz> Date: Fri, 6 Apr 2012 09:26:13 -0700 Message-ID: <00a501cd1411$fbf995d0$f3ecc170$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLdEkJTdlG4Ptyjkg0KDRjvaKCa5QDqCZRkAkh4z4ECGEQc2AEiT+eclDqWunA= Content-Language: en-us Cc: 'dane list' Subject: Re: [dane] 6: No matching associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 16:27:06 -0000 +1 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Ondrej Sur=C3=BD > Sent: Friday, April 06, 2012 12:42 AM > To: Paul Hoffman > Cc: dane list > Subject: Re: [dane] 6: No matching associations >=20 > On 20. 3. 2012, at 16:39, Paul Hoffman wrote: >=20 > > On Mar 20, 2012, at 7:59 AM, Jim Schaad wrote: > > > >> Fair enough comment. > >> Suggested text > >> > >> If an application fails to match any certificate association, then > >> the TLS session is aborted or never started. > > > > I think that is OK, but would rather be clearer: > > > > During the TLS handshake, if none of the certificate associations = matches > the certificate given by the TLS server, the TLS client MUST abort the > handshake. >=20 > LGTM, unless I hear any objections from WG, I will ask our authors to > implement this. >=20 > O. > -- > Ondrej Sur > vedouc v zkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratore CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Fri Apr 6 10:22:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A063221F85C2 for ; Fri, 6 Apr 2012 10:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnraAaDB9JZY for ; Fri, 6 Apr 2012 10:22:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1605021F85B9 for ; Fri, 6 Apr 2012 10:22:17 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q36HMEQT047827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 6 Apr 2012 10:22:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Fri, 6 Apr 2012 10:22:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <348EB639-EDF3-48A7-BE61-24280AA3A5DC@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] 2: Usage 0 clarity X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:22:17 -0000 On Apr 6, 2012, at 12:34 AM, Ond=C5=99ej Sur=C3=BD wrote: > On 20. 3. 2012, at 14:49, Paul Hoffman wrote: >=20 >> On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >>=20 >>> 2. Is usage 0 clear enough? For example, a CA cert that's not a = trust >>> anchor will have a basicConstraints extension with cA set, but a = trust >>> anchor need not have that, so should usage 0 mean "CA certificate or >>> trust anchor" or is it just worth noting that the associated = certificate >>> in this usage can be either? >=20 >=20 > I have no strong opinion on this (or rather I am inclined to "CA = certificate or > trust anchor" because that's what I think we originally meant). >=20 > What the WG think? Zero people commented earlier, and so far only Jim has. So I think that = the WG doesn't care. Having said that, I disagree with part of Jim's analysis, but would want = to hear more from others. On Apr 6, 2012, at 9:24 AM, Jim Schaad wrote: > I am ambivalent about this in either direction. >=20 > To say that it includes the trust anchor may cause problems if the = full certificate comparison is used as not all trust anchors are stored = on all machines in the certificate format. =20 >=20 > To say that it cannot include the trust anchor may cause problems = because the server has no way to know which certificates I have chosen = for the trust anchor. >=20 > I would say that > 1. This SHOULD NOT be the certificate that the server is using as the = trust anchor as in that case the certificate use of 2 would be more = appropriate > 2. This MAY be the certificate that the client is using as the TA = assuming that the client is using certificates as trust anchor = certificates. I don't like #1 because it says that usage type 0 and type 2 cannot = overlap, but I don't think we need to make that restriction. I think #2 = is fine. However, to answer's Stephen's original question, I think we can clarify = simply by adding "Because this usage allows both trust anchors and CA = certificates, the certificate might or might not have the = basicConstraints extension is present.". --Paul Hoffman From ietf@augustcellars.com Fri Apr 6 10:33:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403F721F8601 for ; Fri, 6 Apr 2012 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDMcptoGUMtk for ; Fri, 6 Apr 2012 10:33:52 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5718021F85E6 for ; Fri, 6 Apr 2012 10:33:52 -0700 (PDT) Received: from Tobias (50-54-163-209.evrt.wa.frontiernet.net [50.54.163.209]) (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 02CC62CA1B; Fri, 6 Apr 2012 10:33:51 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'dane list'" References: <4F6877E7.5030905@cs.tcd.ie> <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> <348EB639-EDF3-48A7-BE61-24280AA3A5DC@vpnc.org> In-Reply-To: <348EB639-EDF3-48A7-BE61-24280AA3A5DC@vpnc.org> Date: Fri, 6 Apr 2012 10:32:58 -0700 Message-ID: <00a601cd141b$4f90e1e0$eeb2a5a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLdEkJTdlG4Ptyjkg0KDRjvaKCa5QLQFdl7AyYJs8QB2DvxfpQvnwfA Content-Language: en-us Subject: Re: [dane] 2: Usage 0 clarity X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:33:53 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of > Paul Hoffman > Sent: Friday, April 06, 2012 10:22 AM > To: dane list > Subject: Re: [dane] 2: Usage 0 clarity >=20 > On Apr 6, 2012, at 12:34 AM, Ondrej Sur wrote: >=20 > > On 20. 3. 2012, at 14:49, Paul Hoffman wrote: > > > >> On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: > >> > >>> 2. Is usage 0 clear enough? For example, a CA cert that's not a > >>> trust anchor will have a basicConstraints extension with cA set, = but > >>> a trust anchor need not have that, so should usage 0 mean "CA > >>> certificate or trust anchor" or is it just worth noting that the > >>> associated certificate in this usage can be either? > > > > > > I have no strong opinion on this (or rather I am inclined to "CA > > certificate or trust anchor" because that's what I think we = originally meant). > > > > What the WG think? >=20 >=20 > Zero people commented earlier, and so far only Jim has. So I think = that the > WG doesn't care. >=20 > Having said that, I disagree with part of Jim's analysis, but would = want to hear > more from others. >=20 > On Apr 6, 2012, at 9:24 AM, Jim Schaad wrote: >=20 > > I am ambivalent about this in either direction. > > > > To say that it includes the trust anchor may cause problems if the = full > certificate comparison is used as not all trust anchors are stored on = all > machines in the certificate format. > > > > To say that it cannot include the trust anchor may cause problems = because > the server has no way to know which certificates I have chosen for the = trust > anchor. > > > > I would say that > > 1. This SHOULD NOT be the certificate that the server is using as = the > > trust anchor as in that case the certificate use of 2 would be more > appropriate 2. This MAY be the certificate that the client is using = as the TA > assuming that the client is using certificates as trust anchor = certificates. >=20 > I don't like #1 because it says that usage type 0 and type 2 cannot = overlap, > but I don't think we need to make that restriction. I think #2 is = fine. >=20 > However, to answer's Stephen's original question, I think we can = clarify > simply by adding "Because this usage allows both trust anchors and CA > certificates, the certificate might or might not have the = basicConstraints > extension is present.". This does not give me any major heartache. And this is probably the = type of thing lots of implementation experience should get us a much = better idea of what works and what fails Jim >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Fri Apr 6 10:45:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8C421F85DF for ; Fri, 6 Apr 2012 10:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4kpqOIFnTGe for ; Fri, 6 Apr 2012 10:45:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35A21F85B9 for ; Fri, 6 Apr 2012 10:45:10 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q36Hj5hd048293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Apr 2012 10:45:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Paul Hoffman In-Reply-To: <95FDE649-1E26-4A2D-9D15-73CF5ACEDE27@nic.cz> Date: Fri, 6 Apr 2012 10:45:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <11B8FBA1-BC24-4F32-808E-1613CD33EB91@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <95FDE649-1E26-4A2D-9D15-73CF5ACEDE27@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1257) Cc: dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:45:10 -0000 On Apr 6, 2012, at 1:01 AM, Ond=C5=99ej Sur=C3=BD wrote: > are you and Jakob able to cook something into Security Considerations > or do you need more guidance from the WG on the text? Looking over the responses on this thread, we can answer Stephen's = concern with a new sub-section in the Security Considerations. --Paul Hoffman From ondrej.sury@nic.cz Fri Apr 6 11:15:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7F21F862F for ; Fri, 6 Apr 2012 11:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwLVO9xaF8Xk for ; Fri, 6 Apr 2012 11:14:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2421F84D1 for ; Fri, 6 Apr 2012 11:14:30 -0700 (PDT) Received: from [10.0.0.252] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id 3A34E13F749; Fri, 6 Apr 2012 20:14:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333736064; bh=ohvLaa/dv36I1jFNghNcXQ8kc4qT0hSHT7mGLDtzVAU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=p4oodjjNbV2cVgvlU7c3FnB1bg8Inp5PTZkxeduR7eZ7IW8ZmPTPUgGGuic/40g7B qczGzbl+t4jswXvA098M6Hg0tlTB5yqvAOVg9ZafSLyboDkTylW6NpyJl/hbThUvjs HJtoybxor4qfgNANa7TRSfVW+XMQaqfXdwmZl/tA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <00a601cd141b$4f90e1e0$eeb2a5a0$@augustcellars.com> Date: Fri, 6 Apr 2012 20:14:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F6877E7.5030905@cs.tcd.ie> <8BCF7F66-5767-45CB-A7B5-E15450568DA5@vpnc.org> <348EB639-EDF3-48A7-BE61-24280AA3A5DC@vpnc.org> <00a601cd141b$4f90e1e0$eeb2a5a0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: 'Paul Hoffman' , 'dane list' Subject: Re: [dane] 2: Usage 0 clarity X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 18:15:11 -0000 On 6. 4. 2012, at 19:32, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf = Of >> Paul Hoffman >> Sent: Friday, April 06, 2012 10:22 AM >> To: dane list >> Subject: Re: [dane] 2: Usage 0 clarity >>=20 >> On Apr 6, 2012, at 12:34 AM, Ondrej Sur wrote: >>=20 >>> On 20. 3. 2012, at 14:49, Paul Hoffman wrote: >>>=20 >>>> On Mar 20, 2012, at 5:28 AM, Stephen Farrell wrote: >>>>=20 >>>>> 2. Is usage 0 clear enough? For example, a CA cert that's not a >>>>> trust anchor will have a basicConstraints extension with cA set, = but >>>>> a trust anchor need not have that, so should usage 0 mean "CA >>>>> certificate or trust anchor" or is it just worth noting that the >>>>> associated certificate in this usage can be either? >>>=20 >>>=20 >>> I have no strong opinion on this (or rather I am inclined to "CA >>> certificate or trust anchor" because that's what I think we = originally meant). >>>=20 >>> What the WG think? >>=20 >>=20 >> Zero people commented earlier, and so far only Jim has. So I think = that the >> WG doesn't care. >>=20 >> Having said that, I disagree with part of Jim's analysis, but would = want to hear >> more from others. >>=20 >> On Apr 6, 2012, at 9:24 AM, Jim Schaad wrote: >>=20 >>> I am ambivalent about this in either direction. >>>=20 >>> To say that it includes the trust anchor may cause problems if the = full >> certificate comparison is used as not all trust anchors are stored on = all >> machines in the certificate format. >>>=20 >>> To say that it cannot include the trust anchor may cause problems = because >> the server has no way to know which certificates I have chosen for = the trust >> anchor. >>>=20 >>> I would say that >>> 1. This SHOULD NOT be the certificate that the server is using as = the >>> trust anchor as in that case the certificate use of 2 would be more >> appropriate 2. This MAY be the certificate that the client is using = as the TA >> assuming that the client is using certificates as trust anchor = certificates. >>=20 >> I don't like #1 because it says that usage type 0 and type 2 cannot = overlap, >> but I don't think we need to make that restriction. I think #2 is = fine. >>=20 >> However, to answer's Stephen's original question, I think we can = clarify >> simply by adding "Because this usage allows both trust anchors and CA >> certificates, the certificate might or might not have the = basicConstraints >> extension is present.". >=20 > This does not give me any major heartache. And this is probably the = type of thing lots of implementation experience should get us a much = better idea of what works and what fails Also works for me. (nit: remove last 'is') O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From kent@bbn.com Mon Apr 9 18:59:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2243511E8074 for ; Mon, 9 Apr 2012 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.394 X-Spam-Level: X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8xF0AU6WZet for ; Mon, 9 Apr 2012 18:59:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4683B11E8096 for ; Mon, 9 Apr 2012 18:59:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57555 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHPzR-0009FY-As; Mon, 09 Apr 2012 21:35:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> Date: Mon, 9 Apr 2012 21:08:20 -0400 To: =?iso-8859-1?Q?Ond=DEej_Sur=98?= From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: dane list , Paul Hoffman Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 01:59:38 -0000 At 10:11 AM +0200 4/6/12, Ond=DEej Sur=98 wrote: >Stephen, > >did you meant this text: > >On 21. 3. 2012, at 19:34, Stephen Kent wrote: > >> What I would say is: >> >> The public CA model upon which browsers and=20 >>OS's depend is fundamentally vulnerable, not=20 >>because it is PKI-based, but because it allows=20 >>any of these CAs to issue any certificate, with=20 >>no constraints. Business models adopted by=20 >>browser and OS vendors, and by the public CAs,=20 >>have allowed this model to be exploited, with=20 >>predictable consequences. Recent experiences=20 >>with compromises of CAs or RAs have lead to=20 >>very serious security problems that undermine=20 >>confidence in this system. >> >> DANE is envisioned as a preferable basis for=20 >>binding public keys to DNS names (a subset of=20 >>what PKIs can do in general) because the=20 >>entities that vouch for the binding of public=20 >>key data to DNS names are the entities=20 >>responsible to managing the DNS names in=20 >>question. While the resulting system still has=20 >>residual security vulnerabilities, it restricts=20 >>the scope of assertions that can be made by any=20 >>entity, consistent with the naming scope=20 >>imposed by the DNS hierarchy. As a result, DANE=20 >>embodies the security "principle of least=20 >>privilege" that is lacking in the current=20 >>public CA model. > > >as a general statement in the discussion or a=20 >kind of replacement for paragraph in 1.1: > > This solution has gradually broken down because some CAs have become > untrustworthy. A single trusted CA that betrays its trust, either > voluntarily or by providing less-than-vigorous protection for its > secrets and capabilities, can compromise any other certificate that > TLS uses by signing a replacement certificate that contains a bogus > key. Several real-world occurrances that have exploited such CAs for > subversion of major web sites (presumably to abet wiretapping and > large-scale fraud) have brought TLS's CA model into disrepute. > >I don't think this is really an ideological=20 >statement, but I think it could be worded little=20 >bit better to not stir emotions. > >O. I was responding to on-list comments re the=20 subject text. Ido find the wording of 1.1 to be=20 awkward and potentially vague. I think my text is=20 clear (but wordier :-)) and provides a technical=20 security rationale for why the DANE approach is=20 preferred over the current browser trust model.=20 (I prefer that wording to "TLS's CA model" since=20 I see no TLS specs that embody the model we're=20 discussing.) Steve From gnu@toad.com Tue Apr 10 16:32:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6131821F86A3 for ; Tue, 10 Apr 2012 16:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTrRdenESRgR for ; Tue, 10 Apr 2012 16:32:05 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id BA63921F86AB for ; Tue, 10 Apr 2012 16:32:05 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3ANW1cF002283; Tue, 10 Apr 2012 16:32:01 -0700 Message-Id: <201204102332.q3ANW1cF002283@new.toad.com> To: Stephen Kent In-reply-to: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> Comments: In-reply-to Stephen Kent message dated "Mon, 09 Apr 2012 21:08:20 -0400." Date: Tue, 10 Apr 2012 16:32:01 -0700 From: John Gilmore Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute: replacement text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 23:32:06 -0000 >[seeking a] replacement for paragraph in 1.1: > > This solution has gradually broken down because some CAs have become > untrustworthy. A single trusted CA that betrays its trust, either > voluntarily or by providing less-than-vigorous protection for its > secrets and capabilities, can compromise any other certificate that > TLS uses by signing a replacement certificate that contains a bogus > key. Several real-world occurrances that have exploited such CAs for > subversion of major web sites (presumably to abet wiretapping and > large-scale fraud) have brought TLS's CA model into disrepute. > >I don't think this is really an ideological >statement, but I think it could be worded little >bit better to not stir emotions. I agree. That was preliminary text that was part of my initial attempt to write an introduction describing what motivates the RFC. I'm happy to help revise it. > >On 21. 3. 2012, at 19:34, Stephen Kent wrote: > > > >> What I would say is: > >> > >> The public CA model upon which browsers and > >>OS's depend is fundamentally vulnerable, not > >>because it is PKI-based, but because it allows > >>any of these CAs to issue any certificate, with > >>no constraints. Business models adopted by > >>browser and OS vendors, and by the public CAs, > >>have allowed this model to be exploited, with > >>predictable consequences. Recent experiences > >>with compromises of CAs or RAs have lead to > >>very serious security problems that undermine > >>confidence in this system. > >> > >> DANE is envisioned as a preferable basis for > >>binding public keys to DNS names (a subset of > >>what PKIs can do in general) because the > >>entities that vouch for the binding of public > >>key data to DNS names are the entities > >>responsible to managing the DNS names in > >>question. While the resulting system still has > >>residual security vulnerabilities, it restricts > >>the scope of assertions that can be made by any > >>entity, consistent with the naming scope > >>imposed by the DNS hierarchy. As a result, DANE > >>embodies the security "principle of least > >>privilege" that is lacking in the current > >>public CA model. I am in agreement with Stephen. I've tried to adapt his text to fit directly as a replacement for the too-ideological paragraph from section 1.1: The public CA model upon which TLS has depended is fundamentally vulnerable, because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can compromise any other certificate that TLS uses, by signing a replacement certificate that contains a bogus key. Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the subversion of major web sites trusted by millions of users. Then follow that with the existing final paragraph from the draft (beginning "The DNS Security Extensions (DNSSEC) provides a similar model..."). This explains how DNSSEC restricts signing ability solely to subdomains. Then finish section 1.1 with this new paragraph, largely from Stephen: DANE [we may need to define the acronym here, since we only defined it in the title before now] offers the option to use the DNSSEC infrastructure to store and sign keys for use by TLS. DANE is envisioned as a preferable basis for binding public keys to DNS names, because the entities that vouch for the binding of public key data to DNS names are the same entities responsible for managing the DNS names in question. While the resulting system still has residual security vulnerabilities, it restricts the scope of assertions that can be made by any entity, consistent with the naming scope imposed by the DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model. The draft would then begin section 1.2 which describes how a TLS client uses DANE. Is this suitable? John From gnu@toad.com Tue Apr 10 16:44:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C211E80DE for ; Tue, 10 Apr 2012 16:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RODwF33MOmN for ; Tue, 10 Apr 2012 16:44:42 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF8A11E8081 for ; Tue, 10 Apr 2012 16:44:42 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3ANigcF002805; Tue, 10 Apr 2012 16:44:42 -0700 Message-Id: <201204102344.q3ANigcF002805@new.toad.com> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-reply-to: <309B64BC-3E42-428C-AC80-8E1D1C0E51F2@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> <309B64BC-3E42-428C-AC80-8E1D1C0E51F2@nic.cz> Comments: In-reply-to =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= message dated "Fri, 06 Apr 2012 09:40:58 +0200." Date: Tue, 10 Apr 2012 16:44:42 -0700 From: John Gilmore Cc: Paul Hoffman , dane list Subject: Re: [dane] 4: Length of certificate association data field X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 23:44:43 -0000 > > On Mar 20, 2012, at 7:55 AM, Jim Schaad wrote:> >> The length of the field is well known because it is every left in the TLSA>> RDATA record. The more interesting question is what happens if there are>> extra bytes on the end of the data block. This should probably be an error.>> But the length of the data field is computed from the TLSA RDATA record and>> not from the contents of the record.> > Agree. I'm pretty sure this is an error that would be caught in the software signing the zone. I don't see what we can say in 2.1.4 that would not just be confusing, but am open to suggestions. I suggest adding to the end of section 2.1.4 a new paragraph: This field occupies the entire RDATA field after the initial usage, selector, and matching type fields. It is an error for this field to contain more or fewer bytes than required by its matching type and selector; for example, if it is a SHA-256 hash, it must be exactly 32 bytes long; if it contains a SubjectPublicKeyInfo, it must not contain any extra bytes before or after the ASN.1 representation of the included key. John From gnu@toad.com Tue Apr 10 16:53:01 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE27D11E811A for ; Tue, 10 Apr 2012 16:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsVCezZ45cFl for ; Tue, 10 Apr 2012 16:53:01 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA311E810C for ; Tue, 10 Apr 2012 16:53:00 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3ANr0cF003136; Tue, 10 Apr 2012 16:53:00 -0700 Message-Id: <201204102353.q3ANr0cF003136@new.toad.com> To: Paul Hoffman In-reply-to: References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Sun, 01 Apr 2012 17:33:00 -0700." Date: Tue, 10 Apr 2012 16:53:00 -0700 From: John Gilmore Cc: dane list Subject: Re: [dane] AppsDir review: SHOULD on hash algs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 23:53:02 -0000 > >> Section 2.1.3: I don’t know understand why this is a SHOULD. Doesn’t it have to match exactly? > >> What’s an example of a situation where one could/should/would legitimately deviate from what this field says with a meaningful result? > > The person putting together the DNS record might not even know what's in the certificate. In general, the person putting together the DNS record does indeed have to know what's in the certificate. If they use selector 0, they have to have the certificate itself so they can insert its hash into the DNS record; if they use selector 1, they have to extract the SubjectPublicKeyInfo from the relevant certificate, and then hash it. If the TLSA record's matching type is a hash, the record SHOULD use the same hash algorithm that was used in the signature in the certificate. This will assist clients that support a small number of hash algorithms. If the committee agrees, we can downgrade this SHOULD to a mere suggestion, e.g.: If the TLSA record's matching type is a hash, using the same hash algorithm that was used in the signature in the certificate would assist interoperability with clients that only support a small number of hash algorithms. John From msk@cloudmark.com Tue Apr 10 16:57:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC64911E811A for ; Tue, 10 Apr 2012 16:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZccJk1xG2XE for ; Tue, 10 Apr 2012 16:57:40 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4975C11E810C for ; Tue, 10 Apr 2012 16:57:38 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.26]) by mail.cloudmark.com with bizsmtp id wPxT1i0010as01C01PxTH2; Tue, 10 Apr 2012 16:57:27 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=MpDQGhme c=1 sm=1 a=QMZKka45TBd+hNGtXG2bIg==:17 a=LvckAehuu68A:10 a=BtFvyzAUkOIA:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=4w8YScCqiEugkYLNazgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=zCR2B9A_00RZ5c6c:21 a=xftWnWqKpnqoPWei:21 a=QMZKka45TBd+hNGtXG2bIg==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::751c:35a8:71a2:8e8]) by exch-htcas902.corp.cloudmark.com ([fe80::54de:dc60:5f3e:334%10]) with mapi id 14.01.0355.002; Tue, 10 Apr 2012 16:57:27 -0700 From: "Murray S. Kucherawy" To: dane list Thread-Topic: [dane] AppsDir review: SHOULD on hash algs Thread-Index: AQHNF3USp1w3gfp0w0CvjucbvJYk0paUu96A Date: Tue, 10 Apr 2012 23:57:27 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280D29AD@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> <08A9ED70-1B27-4D36-9CE9-BFCF84E29892@vpnc.org> <201204102353.q3ANr0cF003136@new.toad.com> In-Reply-To: <201204102353.q3ANr0cF003136@new.toad.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334102247; bh=jDrcBLHFfoIol9EfAXCbsROgAdVgaxLMHUbTzya5tqg=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=C7SvtxzmzltDrdfgDOStliXwxSRDJZ7gCWHLzRgukfM5bcTFBY+WJtd9hVdh7gByG CnpUClvU3YWBj02HvLQpoYM0zMLD9iI17OKMvFj74qoH8J3uVZO8myEEpDW8ptGWh6 07Lniz+QJo2oq+W9x0jDmAahE11u0VhFjuUpd+2g= Subject: Re: [dane] AppsDir review: SHOULD on hash algs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 23:57:41 -0000 Hi John, > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of J= ohn Gilmore > Sent: Tuesday, April 10, 2012 4:53 PM > To: Paul Hoffman > Cc: dane list > Subject: Re: [dane] AppsDir review: SHOULD on hash algs >=20 > In general, the person putting together the DNS record does indeed have > to know what's in the certificate. If they use selector 0, they have > to have the certificate itself so they can insert its hash into the DNS > record; if they use selector 1, they have to extract the > SubjectPublicKeyInfo from the relevant certificate, and then hash it. >=20 > If the TLSA record's matching type is a hash, the record SHOULD use > the same hash algorithm that was used in the signature in the > certificate. This will assist clients that support a small number of > hash algorithms. >=20 > If the committee agrees, we can downgrade this SHOULD to a mere > suggestion, e.g.: >=20 > If the TLSA record's matching type is a hash, using the same hash > algorithm that was used in the signature in the certificate would > assist interoperability with clients that only support a small > number of hash algorithms. After Paul explained it, I thought it would be fine as a SHOULD once some t= ext was added to explain why the SHOULD was appropriate (e.g., when one wou= ld deviate from the normative statement). In particular, it meant the cons= umer of the data has to have the certificate's hash algorithm to make use o= f it anyway, so this is an interoperability improvement point; explaining t= hat by itself would satisfy my question. Your text would also be fine. -MSK From gnu@toad.com Tue Apr 10 17:00:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4840F11E8125 for ; Tue, 10 Apr 2012 17:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgWHBSEn4hrb for ; Tue, 10 Apr 2012 17:00:32 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id C871C11E810C for ; Tue, 10 Apr 2012 17:00:32 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3B00VcF003628; Tue, 10 Apr 2012 17:00:31 -0700 Message-Id: <201204110000.q3B00VcF003628@new.toad.com> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-reply-to: References: <201203210135.q2L1ZEWD001880@new.toad.com> <000c01cd073b$36c35bd0$a44a1370$@augustcellars.com> Comments: In-reply-to =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= message dated "Fri, 06 Apr 2012 09:53:20 +0200." Date: Tue, 10 Apr 2012 17:00:31 -0700 From: John Gilmore Cc: 'dane list' Subject: Re: [dane] Security consideration "local policy" distrusting usages 2 and 3 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:00:33 -0000 >>> In the last paragraph of Section 8 of -18, we have this new text: >>> >>> The client's full trust of a certificate retrieved from a TLSA record >>> with a certificate usage type of 2 or 3 may be a matter of local >>> policy. While such trust is limited to the specific domain nane for >>> which the TLSA query was made, local policy may deny the trust or >>> further restrict the conditions under which that trust is permitted. > >> I guess it is no more of a back hand way of saying that some people will not >> trust it than DANE is a back handed way of saying that PKI is untrustworthy >> which is being said in this document. Both DANE and the status-quo CA model are PKIs. Nobody is saying that PKI is untrustworthy. (And I've helped to revise the text you objected to, to be less inflammatory.) At the same time we should not be suggesting that keys which are ONLY certified by DANE, and not by a CA, are somehow untrustworthy, should not be trusted by software, or that clients should configure their software to refuse to honor them. I still believe that this paragraph should be removed from the draft. John From paul@nohats.ca Tue Apr 10 18:26:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6121F8638 for ; Tue, 10 Apr 2012 18:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmvB9u21hj74 for ; Tue, 10 Apr 2012 18:26:31 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6A98F21F8623 for ; Tue, 10 Apr 2012 18:26:29 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 230AB80331; Tue, 10 Apr 2012 21:26:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 1AD8A8032E; Tue, 10 Apr 2012 21:26:28 -0400 (EDT) Date: Tue, 10 Apr 2012 21:26:28 -0400 (EDT) From: Paul Wouters To: John Gilmore In-Reply-To: <201204102332.q3ANW1cF002283@new.toad.com> Message-ID: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <201204102332.q3ANW1cF002283@new.toad.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane list , Paul Hoffman Subject: Re: [dane] 5: PKI disrepute: replacement text X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 01:26:32 -0000 On Tue, 10 Apr 2012, John Gilmore wrote: > I am in agreement with Stephen. I've tried to adapt his text to fit > directly as a replacement for the too-ideological paragraph from > section 1.1: [...] > Then follow that with the existing final paragraph from the draft > (beginning "The DNS Security Extensions (DNSSEC) provides a similar > model..."). This explains how DNSSEC restricts signing ability solely > to subdomains. Then finish section 1.1 with this new paragraph, > largely from Stephen: [...] > The draft would then begin section 1.2 which describes how a TLS > client uses DANE. > > Is this suitable? I agree and like the suggested texts by John and Stephen. It also clearly states that DANE limits itself to validating a domain name. Paul From paul.hoffman@vpnc.org Tue Apr 10 20:19:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740BA11E8096 for ; Tue, 10 Apr 2012 20:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jcz4DfPsfJJ for ; Tue, 10 Apr 2012 20:19:43 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 039E411E8081 for ; Tue, 10 Apr 2012 20:19:42 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3B3JdAl003733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 20:19:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 20:19:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> To: =?iso-8859-1?Q?Ondrej_Sury=98?= X-Mailer: Apple Mail (2.1257) Cc: dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 03:19:43 -0000 Can we get a final wording for this so Jakob and I can turn in a new draft? --Paul Hoffman From paul.hoffman@vpnc.org Tue Apr 10 20:23:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FF911E8096 for ; Tue, 10 Apr 2012 20:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfhZDN6CBkKW for ; Tue, 10 Apr 2012 20:23:09 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9041811E8081 for ; Tue, 10 Apr 2012 20:23:09 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3B3N8gX003820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 10 Apr 2012 20:23:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <201204102344.q3ANigcF002805@new.toad.com> Date: Tue, 10 Apr 2012 20:23:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E02C12B-22CC-404F-8E6A-F20B4C6B3D8E@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> <309B64BC-3E42-428C-AC80-8E1D1C0E51F2@nic.cz> <201204102344.q3ANigcF002805@new.toad.com> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] 4: Length of certificate association data field X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 03:23:10 -0000 On Apr 10, 2012, at 4:44 PM, John Gilmore wrote: >>> On Mar 20, 2012, at 7:55 AM, Jim Schaad wrote:> >> The length of the = field is well known because it is every left in the TLSA>> RDATA record. = The more interesting question is what happens if there are>> extra = bytes on the end of the data block. This should probably be an error.>> = But the length of the data field is computed from the TLSA RDATA record = and>> not from the contents of the record.> > Agree. I'm pretty sure = this is an error that would be caught in the software signing the zone. = I don't see what we can say in 2.1.4 that would not just be confusing, = but am open to suggestions. >=20 > I suggest adding to the end of section 2.1.4 a new paragraph: >=20 > This field occupies the entire RDATA field after the initial usage, > selector, and matching type fields. It is an error for this field > to contain more or fewer bytes than required by its matching type > and selector; for example, if it is a SHA-256 hash, it must be > exactly 32 bytes long; if it contains a SubjectPublicKeyInfo, it > must not contain any extra bytes before or after the ASN.1 > representation of the included key. While this sentence it technically true, it is also probably not helpful = to implementers. It is true for every format that uses hashes, and yet = doesn't appear in many (or any) of those specifications. --Paul Hoffman From gnu@toad.com Tue Apr 10 23:19:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3974F21F86C3 for ; Tue, 10 Apr 2012 23:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfFRl3kYMMwn for ; Tue, 10 Apr 2012 23:19:22 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 6286D21F86C1 for ; Tue, 10 Apr 2012 23:19:21 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3B6JLcF020574; Tue, 10 Apr 2012 23:19:21 -0700 Message-Id: <201204110619.q3B6JLcF020574@new.toad.com> To: Paul Hoffman In-reply-to: <7E02C12B-22CC-404F-8E6A-F20B4C6B3D8E@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <6BB8878E-8CEE-48EE-8D4C-43C1A118A11B@vpnc.org> <020f01cd06a9$7f548e60$7dfdab20$@augustcellars.com> <309B64BC-3E42-428C-AC80-8E1D1C0E51F2@nic.cz> <201204102344.q3ANigcF002805@new.toad.com> <7E02C12B-22CC-404F-8E6A-F20B4C6B3D8E@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Tue, 10 Apr 2012 20:23:08 -0700." Date: Tue, 10 Apr 2012 23:19:21 -0700 From: John Gilmore Cc: dane list Subject: Re: [dane] 4: Length of certificate association data field X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 06:19:23 -0000 > > This field occupies the entire RDATA field after the initial usage, > > selector, and matching type fields. It is an error for this field > > to contain more or fewer bytes than required by its matching type > > and selector; for example, if it is a SHA-256 hash, it must be > > exactly 32 bytes long; if it contains a SubjectPublicKeyInfo, it > > must not contain any extra bytes before or after the ASN.1 > > representation of the included key. > > While this sentence it technically true, it is also probably not helpful to implementers. It is true for every format that uses hashes, and yet doesn't appear in many (or any) of those specifications. Perhaps the Area Director also noticed that trend, and in response is encouraging working groups to be more specific. I don't know. We could decide to ignore the AD's comment about this aspect of the draft. But I thought I'd take a stab at addressing it. As a programmer, I'm happy to see statements in a spec like "It is an error for this field to contain..." since it tells me whether I should be loose and allow sloppy stuff through here (Jon-Postel-style being liberal in what you accept), or whether I should validate everything here (because having extra ignored bytes is so useful in attacking protocols). Does anyone else have an opinion on whether we should suggest validation or liberality here? I'm not wedded to the wording; I'm happy if anybody takes a crack at it. John From warren@kumari.net Wed Apr 11 07:42:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48B011E80AA for ; Wed, 11 Apr 2012 07:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo62+4c2lmM1 for ; Wed, 11 Apr 2012 07:42:15 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5811E8080 for ; Wed, 11 Apr 2012 07:42:14 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4F84F1B402FA; Wed, 11 Apr 2012 10:42:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> Date: Wed, 11 Apr 2012 10:42:11 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 14:42:16 -0000 On Apr 10, 2012, at 11:19 PM, Paul Hoffman wrote: > Can we get a final wording for this so Jakob and I can turn in a new draft? We seem to have settled on the text in: http://www.ietf.org/mail-archive/web/dane/current/msg04605.html If the authors could incorporate this, that would be great... W > > --Paul Hoffman > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From paul.hoffman@vpnc.org Wed Apr 11 08:57:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DCE21F84DE for ; Wed, 11 Apr 2012 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBLRgWEmW+D6 for ; Wed, 11 Apr 2012 08:57:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65A21F84DC for ; Wed, 11 Apr 2012 08:57:36 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3BFvYMG033853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Apr 2012 08:57:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> Date: Wed, 11 Apr 2012 08:57:34 -0700 Content-Transfer-Encoding: 7bit Message-Id: <8883B1DC-CD1B-4FAD-B029-5285EA25790F@vpnc.org> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1257) Cc: dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 15:57:36 -0000 On Apr 11, 2012, at 7:42 AM, Warren Kumari wrote: > We seem to have settled on the text in: > http://www.ietf.org/mail-archive/web/dane/current/msg04605.html > > If the authors could incorporate this, that would be great... Done. 'Twill be in the next rev, which should be out soon. --Paul Hoffman From ietf@augustcellars.com Wed Apr 11 12:01:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0521F84F0 for ; Wed, 11 Apr 2012 12:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhqaoUDG8lUa for ; Wed, 11 Apr 2012 12:01:25 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B73721F853A for ; Wed, 11 Apr 2012 12:01:17 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 571FE2CA0D; Wed, 11 Apr 2012 12:01:16 -0700 (PDT) From: "Jim Schaad" To: "'John Gilmore'" , =?utf-8?Q?'Ondrej_Sur=C3=BD'?= References: <201203210135.q2L1ZEWD001880@new.toad.com> <000c01cd073b$36c35bd0$a44a1370$@augustcellars.com> <201204110000.q3B00VcF003628@new.toad.com> In-Reply-To: <201204110000.q3B00VcF003628@new.toad.com> Date: Wed, 11 Apr 2012 12:00:07 -0700 Message-ID: <01ef01cd1815$59c3b3b0$0d4b1b10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKn1pdPvpeUsO8CsMTfmemWvnmQoQI7q2VKAdAiPCgBxpkXBJSx6dpw Content-Language: en-us Cc: 'dane list' Subject: Re: [dane] Security consideration "local policy" distrusting usages 2 and 3 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:01:25 -0000 John, In my opinion this paragraph is no different than the one we no longer = (hopefully) need to put into documents which says choose you trust = anchors for PKI with care. If you don't have one that the entity on the = other end trusts then you will be unsuccessful. In this case we are establishing a new way to convey what the trust = anchor would be. We need to tell people that not everybody is going to = believe them. Jim > -----Original Message----- > From: John Gilmore [mailto:gnu@toad.com] > Sent: Tuesday, April 10, 2012 5:01 PM > To: Ondrej Sur=C3=BD > Cc: Jim Schaad; 'John Gilmore'; 'dane list' > Subject: Re: [dane] Security consideration "local policy" distrusting = usages 2 > and 3 >=20 > >>> In the last paragraph of Section 8 of -18, we have this new text: > >>> > >>> The client's full trust of a certificate retrieved from a TLSA = record > >>> with a certificate usage type of 2 or 3 may be a matter of local > >>> policy. While such trust is limited to the specific domain nane = for > >>> which the TLSA query was made, local policy may deny the trust = or > >>> further restrict the conditions under which that trust is = permitted. > > > >> I guess it is no more of a back hand way of saying that some people > >> will not trust it than DANE is a back handed way of saying that PKI > >> is untrustworthy which is being said in this document. >=20 > Both DANE and the status-quo CA model are PKIs. Nobody is saying that = PKI > is untrustworthy. (And I've helped to revise the text you objected = to, to be > less inflammatory.) >=20 > At the same time we should not be suggesting that keys which are ONLY > certified by DANE, and not by a CA, are somehow untrustworthy, should = not > be trusted by software, or that clients should configure their = software to > refuse to honor them. >=20 > I still believe that this paragraph should be removed from the draft. >=20 > John From mrex@sap.com Wed Apr 11 13:47:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112D211E80BB for ; Wed, 11 Apr 2012 13:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.615 X-Spam-Level: X-Spam-Status: No, score=-9.615 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMZ9ln9ZHwbz for ; Wed, 11 Apr 2012 13:47:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DE11211E8075 for ; Wed, 11 Apr 2012 13:47:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3BKlTL7008846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2012 22:47:29 +0200 (MEST) From: Martin Rex Message-Id: <201204112047.q3BKlS6U021707@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Wed, 11 Apr 2012 22:47:28 +0200 (MEST) In-Reply-To: from "=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=" at Apr 6, 12 09:34:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] 2: Usage 0 clarity X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:47:35 -0000 O. wrote: > >> >>> 2. Is usage 0 clear enough? For example, a CA cert that's not a trust >>> anchor will have a basicConstraints extension with cA set, but a trust >>> anchor need not have that, so should usage 0 mean "CA certificate or >>> trust anchor" or is it just worth noting that the associated certificate >>> in this usage can be either? > > I have no strong opinion on this (or rather I am inclined to > "CA certificate or trust anchor" because that's what I think we > originally meant). > > What the WG think? To me, that discussion about CA certs, their attributes and (an ALWAYS local concept of) trust anchors is pretty confusing -- and IMO unnecessary. This is about the text here, right? http://tools.ietf.org/html/draft-ietf-dane-protocol-18#section-2.1.1 0 -- Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that must be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS. This usage is sometimes referred to as "CA constraint" because it limits which CA can be used to issue certificates for a given service on a host. The target certificate MUST pass PKIX certification path validation and a CA certificate that matches the TLSA record MUST be included as part of a valid certification path. 1 -- Certificate usage 1 is used to specify an end entity certificate, or the public key of such a certificate, that must be matched with the end entity certificate given by the server in TLS. This usage is sometimes referred to as "service certificate constraint" because it limits which end entity certificate may be used by a given service on a host. The target certificate MUST pass PKIX certification path validation and MUST match the TLSA record. Since this is explicitly referencing TLS(!), I would find it much clearer if it would refer to the protocol bits of TLS that are meant to be used/affected, rather than about some fuzzy theoretical concepts of CAs and trust anchors -- details that should be left to PKIX (in its entirety for usage 0 and 1). The TLS PDU this is about is the "(Server) Certificate" handshake message described here: http://tools.ietf.org/html/rfc5246#section-7.4.2 [...] certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. As you can see, the TLS handshake message can contain ONLY 1 PATH, therefore the "that must be found in any of the PKIX certification paths" in -18 IMO does not make sense, there is exactly ONE path conveyed by TLS, and there is exactly ONE path that results from a successful PKIX certificate path validation. And DANE-protocol should better not try to discuss in section 2.1.1. the black magic art that some fancy TLS clients perform between parsing Server Certificate and completing PKIX certificate path validation. (for populating a UI with "I accept the risk, continue anyway", those details might be relevant, but IMO that should go into a seperate section, potentially into security considerations). Usage 1 always refers to the VERY FIRST cert in the Server's Certificate handshake message, "the sender certificate", which must always be present in that handshake message, even when the server is using a self-signed cert, and independent of whether that self-signed cert is an X.509v1, X.509v3 BC:cA=TRUE or X.509v3 BC:cA=FALSE cert. Usage 0 should refer to any other but_the first cert in that message, i.e. one of the certs _following_ the sender's cert. For Usage 0 the check of whether that cert is a valid CA cert or permissible TrustAnchor (i.e. has the correct attributes for that) will be provided by the PKIX path validation function. DANE does not (and IMHO SHOULD NOT) try to check certs attributes for usage 0, but leave this entirely up to the PKIX path validation function. Complication is created by TLS clients that perform a full-blown certificate path discovery for the very first certificate, the "sender's certificate", and use all other certs as mere "hints" for that discovery. A full-blown certificate path discovery might cause not only correct certs conveyed by the server to be substituted, but arbitrary stray certs, except for the "sender's certificate" itself, to be entirely ignored during the PKIX certificate path validation following the certificate path discovery. So it will be essential that the DANE implementation verifies that the cert (or SPKI) identified through TLSA usage 0 is part of the VALIDATED certification path, not just that the TLSA referenced cert was conveyed in the Server's Certificate handshake message (which by itself, for some fancy clients, can be entirely meaningless). The additional question, of whether to allow the specification of a trust anchor in TLSA usage 0, is even more difficult to answer. First of all, the question is misleading, because "trust anchor" is always a local notion, and potentially even a situation specific notion even though a lot of PKI software treats trust anchors as global&omnipotent and lumps all of them into one single store. Also, whether or not an implementation of TLS includes a self-signed rootCA as the final cert (n>1) in the Server's Certificate handshake message is an implementation detail of the TLS implemenation and may or may not be configurable. But as the excerpt quote from TLS above shows, the _receiver_ of the Certificate handshake message will usually _ignore_ such a self-signed RootCA cert at the end of the chain during certificate path validation. The trust anchor information used by the receiver will not necessarily match the self-signed RootCA cert in the server's PKI credential, and the receiver (client in our case) might additionally store&process trust anchor information in non-cert format internally, so that matching by cert or by cert-hash may not be possible for a TLSA record that identifies a trust anchor by cert or cert-hash. But it is even more complicated than that, because the peer/client might use entirely different certs as trust anchors than the server. A typical problem for usage 0 and differing notions of trust anchors is created by cross-certification. What some might be unaware of, this is actively used in today's TLS X.509 PKI! Most (if not all) of the public CAs in the TLS X.509 PKI have created 2048-bit RSA root certs by now. But these root certs are pre-configured as trust anchors only in new software installations or updates, and not known to old installations. In order to become acceptable to the old installed base as well, many CAs have created additonal cross-certs for their new 2048-bit roots, signed by their older 1024-bit roots. For best interop, one would configure the server with the forward chain to the old 1024-bit root, so that it sends the 2048-bit cross-cert in the Server's Certificate handshake message, and new clients would substitute that cross-cert with their new 2048-bit trust anchor during certificate path discovery or certificate path validation rather than verifying the server-supplied cross-cert with the old 1024-bit trust anchor. -Martin From internet-drafts@ietf.org Wed Apr 11 14:36:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4612221F84EA; Wed, 11 Apr 2012 14:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnF2JkUH42oS; Wed, 11 Apr 2012 14:36:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE421F84D4; Wed, 11 Apr 2012 14:36:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120411213647.6576.95653.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 14:36:47 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:36:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : The DNS-Based Authentication of Named Entities (DANE) Pr= otocol for Transport Layer Security (TLS) Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-19.txt Pages : 33 Date : 2012-04-11 Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-19.txt From mrex@sap.com Wed Apr 11 15:17:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461911E8087 for ; Wed, 11 Apr 2012 15:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.062 X-Spam-Level: X-Spam-Status: No, score=-10.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln5R5TV5LPUi for ; Wed, 11 Apr 2012 15:17:22 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6F11E8073 for ; Wed, 11 Apr 2012 15:17:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3BMHHTw024202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 00:17:17 +0200 (MEST) From: Martin Rex Message-Id: <201204112217.q3BMHGVg026737@fs4113.wdf.sap.corp> To: gnu@toad.com (John Gilmore) Date: Thu, 12 Apr 2012 00:17:16 +0200 (MEST) In-Reply-To: <201204102353.q3ANr0cF003136@new.toad.com> from "John Gilmore" at Apr 10, 12 04:53:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] AppsDir review: SHOULD on hash algs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:17:22 -0000 John Gilmore wrote: > > In general, the person putting together the DNS record does indeed > have to know what's in the certificate. If they use selector 0, they > have to have the certificate itself so they can insert its hash into > the DNS record; if they use selector 1, they have to extract the > SubjectPublicKeyInfo from the relevant certificate, and then hash it. > > If the TLSA record's matching type is a hash, the record SHOULD use > the same hash algorithm that was used in the signature in the > certificate. This will assist clients that support a small number of > hash algorithms. > > If the committee agrees, we can downgrade this SHOULD to a mere > suggestion, e.g.: > > If the TLSA record's matching type is a hash, using the same hash > algorithm that was used in the signature in the certificate would > assist interoperability with clients that only support a small > number of hash algorithms. The use of SHOULD would be confusing and inappropriate, because the vast majority of certs use a SHA1 based signatures (and the same applies to DNSSEC signatures) whereas dane-protocol does _not_ support SHA-1 at all (dane-protocol minimum is SHA-256) http://tools.ietf.org/html/draft-ietf-dane-protocol-19#section-7.4 -Martin From iesg-secretary@ietf.org Wed Apr 11 18:41:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D61711E811C; Wed, 11 Apr 2012 18:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sS4OHAIBcOyF; Wed, 11 Apr 2012 18:41:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC8421F845C; Wed, 11 Apr 2012 18:41:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 18:41:27 -0700 Cc: dane@ietf.org Subject: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@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, 12 Apr 2012 01:41:28 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. From kent@bbn.com Wed Apr 11 19:04:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8330111E811E for ; Wed, 11 Apr 2012 19:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdpQq2jdfTqe for ; Wed, 11 Apr 2012 19:04:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9C411E811B for ; Wed, 11 Apr 2012 19:04:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37796 helo=[10.5.32.50]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SI9OE-0009SG-6m; Wed, 11 Apr 2012 22:04:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> Date: Wed, 11 Apr 2012 20:56:51 -0400 To: Warren Kumari From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-877926239==_ma============" Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 02:04:23 -0000 --============_-877926239==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:42 AM -0400 4/11/12, Warren Kumari wrote: >On Apr 10, 2012, at 11:19 PM, Paul Hoffman wrote: > >> Can we get a final wording for this so Jakob and I can turn in a new draft? > >We seem to have settled on the text in: >http://www.ietf.org/mail-archive/web/dane/current/msg04605.html > >If the authors could incorporate this, that would be great... > >W > I have a couple of minor problems with some of the text John provided. ... A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can compromise any other certificate that TLS uses, by signing a replacement certificate that contains a bogus key. The key is not "bogus." It is the binding of the key to the name that is bogus. How about: Any of the CAs accepted as trust anchors can issue a certificate representing any web site. Thus a compromised CA can issue a certificate that claims to represent a targeted web site, essentially replacing the legitimate certificate for the web site (for affected users). Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the subversion of major web sites trusted by millions of users. The web sites may not have been subverted. What happened was that users were no longer able to verify that they were connecting to the web sites they indicated via the URLs that the users employed. Steve --============_-877926239==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dane] 5: PKI disrepute
At 10:42 AM -0400 4/11/12, Warren Kumari wrote:
On Apr 10, 2012, at 11:19 PM, Paul Hoffman wrote:

> Can we get a final wording for this so Jakob and I can turn in a new draft?

We seem to have settled on the text in:
http://www.ietf.org/mail-archive/web/dane/current/msg04605.html

If the authors could incorporate this, that would be great...

W

I have a couple of minor problems with some of the text John  provided.

  ... A single trusted CA that
    betrays its trust, either voluntarily or by providing
    less-than-vigorous protection for its secrets and capabilities,
    can compromise any other certificate that TLS uses, by signing a
    replacement certificate that contains a bogus key.

The key is not "bogus." It is the binding of the key to the name that is bogus.

How about:

Any of the CAs accepted as trust anchors can issue a certificate representing any web site. Thus a compromised CA can issue a certificate that claims to represent a targeted web site, essentially replacing the legitimate certificate for the web site (for affected users).

Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the subversion of major web sites trusted by millions of users.

The web sites may not have been subverted. What happened was that users were no longer able to verify that they were connecting to the web sites they indicated via the URLs that the users employed.

Steve

--============_-877926239==_ma============-- From msk@cloudmark.com Wed Apr 11 22:33:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70DF21F857D for ; Wed, 11 Apr 2012 22:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aeMPu0K0Uk4 for ; Wed, 11 Apr 2012 22:33:25 -0700 (PDT) Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB521F84BD for ; Wed, 11 Apr 2012 22:33:24 -0700 (PDT) Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id wtZU1i0010ZaKgw01tZULT; Wed, 11 Apr 2012 22:33:28 -0700 X-CMAE-Match: 0 X-CMAE-Score: 0.00 X-CMAE-Analysis: v=2.0 cv=SOLApZTH c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=ldJM1g7oyCcA:10 a=J_q9XQn0Ih0A:10 a=zutiEJmiVI4A:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=V414VzLUc4JeK3coFDAA:9 a=bfMNcBPRsPaULzfYC6oA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117 Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 22:33:14 -0700 From: "Murray S. Kucherawy" To: "ietf@ietf.org" Thread-Topic: Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard Thread-Index: AQHNGE1rp1BGkd3F6UKe39NN/3NRq5aWqosQ Date: Thu, 12 Apr 2012 05:33:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280E4B74@exch-mbx901.corp.cloudmark.com> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> In-Reply-To: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1334208808; bh=q+Uv/eLtDSMhYSV1Lo7wtTwjqr7hYY8SFHK2Mv2/POU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=bOkQvgPUOFJ4NFcdHGFhLMx3tBky60KBq3SHu5cKDm2oKmxfxDo11aUFLhQksQnbt 4q1A7qSYlS/h6Z7Eealowt23p0xUBeEEYwm4QHJKMUnJKFaFtSPp+VjmsJnokZjBqi e8dvoK4hZgRX/RhRqHlbiIxeXnjeBl6mbRZdPEms= Cc: "dane@ietf.org" Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 05:33:26 -0000 > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.o= rg] On Behalf Of The IESG > Sent: Wednesday, April 11, 2012 6:41 PM > To: IETF-Announce > Cc: dane@ietf.org > Subject: Last Call: (The DNS-Based > Authentication of Named Entities (DANE) Protocol for Transport Layer > Security (TLS)) to Proposed Standard >=20 > The IESG has received a request from the DNS-based Authentication of > Named Entities WG (dane) to consider the following document: > - 'The DNS-Based Authentication of Named Entities (DANE) Protocol for > Transport Layer Security (TLS)' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-04-25. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. I reviewed this for the Applications Area Directorate when it was -18. The= document was in good shape then, and they've fixed up all concerns I had i= n the -19 version so it's even better now. I support publication on the Standards Track. -MSK From sm@resistor.net Thu Apr 12 00:15:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB43811E80AA; Thu, 12 Apr 2012 00:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFpRoQzGyXNG; Thu, 12 Apr 2012 00:15:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66E11E8089; Thu, 12 Apr 2012 00:15:03 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3C7Eu1O024365; Thu, 12 Apr 2012 00:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334214901; i=@resistor.net; bh=q44PQ0yGG/Dga3rkp/kcrP8qERCyLICa1UDzyJiz2uE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Bh9o518Xh4szRNCLAtEpBshWq4HC5LVJXDgeWdK0yxaiu4DrQRX8diSA69hgMRISB xhyu0zyeRGCiLvwbUXxe0oMXHDWd/sjMCeJkDtyzxgwFA+/L/yrH5drDUrJ9wTNu/P eCv5QOQMQarsgxKVBN1sDL8W3Wt89Ii+LxcAG64c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334214901; i=@resistor.net; bh=q44PQ0yGG/Dga3rkp/kcrP8qERCyLICa1UDzyJiz2uE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=z24AkQnKcJtYFKzu/2vG02aoeZXGvO5eFi1uQH9uJBYa3rI9FFuTZpPo8uVXarvHP WKDqWDGXicirBr1nwycL8zXcwnSYKqZg41OdnU4s+i01Ug8swTcKdhmCKn/qpVHPkA sdDCe9BKKPWRGrXS2/kvrkShEG2ASTY5Y7Pr1szo= Message-Id: <6.2.5.6.2.20120411202530.085195c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 00:11:43 -0700 To: ietf@ietf.org From: SM In-Reply-To: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 07:15:05 -0000 At 18:41 11-04-2012, The IESG wrote: >The IESG has received a request from the DNS-based Authentication of >Named Entities WG (dane) to consider the following document: >- 'The DNS-Based Authentication of Named Entities (DANE) Protocol for > Transport Layer Security (TLS)' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2012-04-25. Exceptionally, comments may be In Section 1.2: "This document applies to both TLS [RFC5246]" Does this mean that DANE is not applicable for TLS 1.1? In Section 1.3: "A DNS query can return multiple certificate associations, such as in the case of a server is changing from one certificate to another." The sentence seems incorrect. In Section 2.1.1: "The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding." I suggest adding a reference to X.690. In Section 2.1.3: "If the TLSA record's matching type is a hash, having the record use the same hash algorithm that was used in the signature in the certificate (if possible) will assist clients that support a small number of hash algorithms." As a comment that does not argue for any change, having SHA-256 hash as the "lowest" hash excludes SHA-1, a widely deployed hash algorithm. I gather that the WG has made a tradeoff between perceived security and ease of deployment. In Section 3: 'For example, to request a TLSA resource record for an HTTP server running TLS on port 443 at "www.example.com", "_443._tcp.www.example.com" is used in the request. To request a TLSA resource record for an SMTP server running the STARTTLS protocol on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is used.' HTTPS for www.example.com is a straight-forward example. In the case of a SMTP server, it is not as easy. Once the target host is located, mail.example.com in this case, one might assume that the server would advertise that hostname or the domain name used to locate the target host as an identity. That's rarely the case due to issues outside the scope of DANE. It's easier not to use the STARTTLS protocol as an example. In Section 7.2, 7.3 and 7.4: "Applications to the registry can request specific values that have yet to be assigned." What is the meaning of "can request specific values" in that sentence? In Section 8.1: "If it is less likely that a user will hear about its trusted DNSSEC validators being hacked that it is of a public CA being compromised" I suggest using "compromised" instead of "hacked". Regards, -sm From dave@cridland.net Thu Apr 12 01:26:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6DD21F860E; Thu, 12 Apr 2012 01:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqEDSVUgkDRl; Thu, 12 Apr 2012 01:26:23 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5821F8603; Thu, 12 Apr 2012 01:26:23 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 42330116808F; Thu, 12 Apr 2012 09:26:17 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNDX8LS22Ujk; Thu, 12 Apr 2012 09:26:02 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 966BE116808D; Thu, 12 Apr 2012 09:26:01 +0100 (BST) References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> In-Reply-To: <6.2.5.6.2.20120411202530.085195c0@resistor.net> MIME-Version: 1.0 Message-Id: <6155.1334219161.556547@puncture> Date: Thu, 12 Apr 2012 09:26:01 +0100 From: Dave Cridland To: "dane@ietf.org" , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit X-Mailman-Approved-At: Thu, 12 Apr 2012 01:41:32 -0700 Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 08:26:24 -0000 On Thu Apr 12 08:11:43 2012, SM wrote: > In Section 1.3: > > "A DNS query can return multiple certificate associations, such > as in > the case of a server is changing from one certificate to > another." > > The sentence seems incorrect. > > No, this seems correct, in as much as multiple TLSA records can be returned. A forward reference to §A.4 would be handy here. > In Section 3: > > 'For example, to request a TLSA resource record for an HTTP server > running TLS on port 443 at "www.example.com", > "_443._tcp.www.example.com" is used in the request. To request a > TLSA resource record for an SMTP server running the STARTTLS > protocol > on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is > used.' > > HTTPS for www.example.com is a straight-forward example. In the > case of a SMTP server, it is not as easy. Once the target host is > located, mail.example.com in this case, one might assume that the > server would advertise that hostname or the domain name used to > locate the target host as an identity. That's rarely the case due > to issues outside the scope of DANE. It's easier not to use the > STARTTLS protocol as an example. To expand on this, it's not wholly clear what one might do for SRV (or MX) records in general. It's not clear whether a client needs to access records for every SRV returned. Moreover, protocols such as XMPP do allow a server to use a different certificate depending on the called domain, and existant servers do implement this - this means that acting upon TLSA records found against purely A/AAAA records pointed to in turn by SRV. It seems to me that, unfortunately, there is a requirement here to add a further case, by allowing TLSA records against the SRV-style name, such as: _xmpp-server._tcp.example.com IN TLSA 1 1 1 DEADBEEFCAFE The above comments about SRV are unfortunate, because I'm already concerned with the number of options available. In particular, given the relative ease of certificate/key rollover, I think the SubjectKeyInfo match could be removed. Moreover, I think it absolutely should be for CA certificates - it seems to broaden the attack surface (and moreover, broaden the opportunities for confusion and failure). In addition, it's not clear to me that having hashes in lieu of complete data is particularly helpful - I do appreciate that it removes a not inconsiderable number of octets from the wire, but I'd also note that if a full certificate is in DANE, then it's possible for a client to check revocation status without connecting to the service. This seems to me as potentially useful, and I'd note that although the certificates are indeed quite large, they ought to be readily cached as well. Touching on revocation leads on to a further comment - there's only very brief mention of how clients should handle revocation status checks, and it appears to suggest that a "type 2" certificate should not, or even must not, be checked. I'd suggest that at minimum, this ought to be clarified. In particular, the security considerations refer to type 2, but not type 3, certificates. Note, incidentally, that §8 refers to "type 2", but §2.1.1 refers to "[Certificate] usage 2" - consistency might be preferable here. As a final comment, I'd presonally like to see some comments about how, and when, extended validation information should be checked and trusted. It seems to me that such information should be ignored when handling type 2 or type 3 certificates; or at best it should be validated independantly using the traditional methods - that is, it should be treated as a type 0 or type 1 certificate for the purposes of extended validation. Oh, and one more nit, why not. I can't be the only person who notes that the certificate type is a bitfield of "Suppress 5280 validation" and "End Entity Cert" flags. I wonder if this might lead to risk if new cert types were assigned that did not match this? Is it worthwhile making a comment that it's explicitly not a bitfield? I may be being overly paranoid, here. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ondrej.sury@nic.cz Thu Apr 12 03:48:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391F721F85F6; Thu, 12 Apr 2012 03:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L93FSG73n24q; Thu, 12 Apr 2012 03:48:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 50E7C21F8589; Thu, 12 Apr 2012 03:48:52 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb] (unknown [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb]) by mail.nic.cz (Postfix) with ESMTPSA id 5DA4A1410B0; Thu, 12 Apr 2012 12:48:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334227731; bh=eXWEHRxqJcQ1awOeiEuPSkUZt8PpdULUiHy4VdVdWQI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eo461D0Zg3madPJKHRrk1eWw7KO+5ntpoyp5I6vISJBCvbrhXpEh7fGkCUv8S/qd9 bdmcOz0NFFGeisnwPShDRN8D98gYgUPvY3FURagCzFKnfR5E71lHXKRrlxbZnZKu9A O8vdAkCVdXfI7ZyOdcBWcGqZ5Q41ssjRF7X1Nds8= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6.2.5.6.2.20120411202530.085195c0@resistor.net> Date: Thu, 12 Apr 2012 12:48:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> To: SM X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 10:48:53 -0000 On 12. 4. 2012, at 9:11, SM wrote: > At 18:41 11-04-2012, The IESG wrote: >> The IESG has received a request from the DNS-based Authentication of >> Named Entities WG (dane) to consider the following document: >> - 'The DNS-Based Authentication of Named Entities (DANE) Protocol for >> Transport Layer Security (TLS)' >> as a Proposed Standard >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2012-04-25. Exceptionally, comments = may be >=20 > In Section 1.2: >=20 > "This document applies to both TLS [RFC5246]" >=20 > Does this mean that DANE is not applicable for TLS 1.1? RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make = references to obsoleted documents. As a side note, we don't say "to both TLS 1.2", = but just TLS. > In Section 1.3: >=20 > "A DNS query can return multiple certificate associations, such as in > the case of a server is changing from one certificate to another." >=20 > The sentence seems incorrect. Dave already commented on this. I also don't see anything wrong with = the sentence. > In Section 2.1.1: >=20 > "The certificate usages defined in this document explicitly only = apply > to PKIX-formatted certificates in DER encoding." >=20 > I suggest adding a reference to X.690. Seems reasonable. > In Section 2.1.3: >=20 > "If the TLSA record's matching type is a hash, having the record use > the same hash algorithm that was used in the signature in the > certificate (if possible) will assist clients that support a small > number of hash algorithms." >=20 > As a comment that does not argue for any change, having SHA-256 hash = as the "lowest" hash excludes SHA-1, a widely deployed hash algorithm. = I gather that the WG has made a tradeoff between perceived security and = ease of deployment. SHA-2 was first published 11 years ago and I don't really think that applications which will decide to implement DANE will not have support for SHA-2 family. The quoted sentence just says: Use closest available algorithm to help clients (e.g. please don't use SHA-3 if the certificate signature is = SHA-256). > In Section 3: >=20 > 'For example, to request a TLSA resource record for an HTTP server > running TLS on port 443 at "www.example.com", > "_443._tcp.www.example.com" is used in the request. To request a > TLSA resource record for an SMTP server running the STARTTLS = protocol > on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is > used.' >=20 > HTTPS for www.example.com is a straight-forward example. In the case = of a SMTP server, it is not as easy. Once the target host is located, = mail.example.com in this case, one might assume that the server would = advertise that hostname or the domain name used to locate the target = host as an identity. That's rarely the case due to issues outside the = scope of DANE. It's easier not to use the STARTTLS protocol as an = example. Here the rules from RFC3207 can be applied: The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are: - A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. Similar logic applies to DANE, but it's not the DANE which decides the name, but TLS capable client, which already know which name to expect. > In Section 7.2, 7.3 and 7.4: >=20 > "Applications to the registry can request specific values that have > yet to be assigned." >=20 > What is the meaning of "can request specific values" in that sentence? It's just a note, that we expect that future standards would be able to assign new values (f.e. new hash algorithms when SHA-3 is out). > In Section 8.1: >=20 > "If it is less likely that a user will hear about its trusted DNSSEC > validators being hacked that it is of a public CA being compromised" >=20 > I suggest using "compromised" instead of "hacked". lgtm O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Apr 12 04:03:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B321F84EE; Thu, 12 Apr 2012 04:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWWvLh9JLKSB; Thu, 12 Apr 2012 04:03:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2A27721F85E4; Thu, 12 Apr 2012 04:03:38 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb] (unknown [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb]) by mail.nic.cz (Postfix) with ESMTPSA id 78614140421; Thu, 12 Apr 2012 13:03:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334228617; bh=B1F1UxNHSh/Fy9ZJlF46Fljawyf9piaOa0xjjrc89Q0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qksfBUcdvanIbC+EAI2NgYG5re5P+bhNuqjdXxiIZZQ9kNLpUNlsHNCdR4Of8aeyC dcrhh/pFh5RbURf/1RqN8B/2nMmy8gASFphQr53CDOhLWMl6DoPgLozJzenik7skRy EbqtODKu5HCnfadowyQXOEId/Olw8ifbPBvSjmbg= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6155.1334219161.556547@puncture> Date: Thu, 12 Apr 2012 13:03:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> To: Dave Cridland X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF-Discussion , "dane@ietf.org" Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 11:03:39 -0000 On 12. 4. 2012, at 10:26, Dave Cridland wrote: >> In Section 3: >> 'For example, to request a TLSA resource record for an HTTP server >> running TLS on port 443 at "www.example.com", >> "_443._tcp.www.example.com" is used in the request. To request a >> TLSA resource record for an SMTP server running the STARTTLS = protocol >> on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is >> used.' >> HTTPS for www.example.com is a straight-forward example. In the case = of a SMTP server, it is not as easy. Once the target host is located, = mail.example.com in this case, one might assume that the server would = advertise that hostname or the domain name used to locate the target = host as an identity. That's rarely the case due to issues outside the = scope of DANE. It's easier not to use the STARTTLS protocol as an = example. >=20 > To expand on this, it's not wholly clear what one might do for SRV (or = MX) records in general. It's not clear whether a client needs to access = records for every SRV returned. Moreover, protocols such as XMPP do = allow a server to use a different certificate depending on the called = domain, and existant servers do implement this - this means that acting = upon TLSA records found against purely A/AAAA records pointed to in turn = by SRV. >=20 > It seems to me that, unfortunately, there is a requirement here to add = a further case, by allowing TLSA records against the SRV-style name, = such as: >=20 > _xmpp-server._tcp.example.com IN TLSA 1 1 1 DEADBEEFCAFE >=20 > The above comments about SRV are unfortunate, because I'm already = concerned with the number of options available. In particular, given the = relative ease of certificate/key rollover, I think the SubjectKeyInfo = match could be removed. Moreover, I think it absolutely should be for CA = certificates - it seems to broaden the attack surface (and moreover, = broaden the opportunities for confusion and failure). Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before = discussing SRV records further. We have left SRV records on purpose and we expect that this = will be solved in separate document (for each affected protocol). > In addition, it's not clear to me that having hashes in lieu of = complete data is particularly helpful - I do appreciate that it removes = a not inconsiderable number of octets from the wire, but I'd also note = that if a full certificate is in DANE, then it's possible for a client = to check revocation status without connecting to the service. This seems = to me as potentially useful, and I'd note that although the certificates = are indeed quite large, they ought to be readily cached as well. The hashes are very useful since any UDP DNS packet not able to fit into = MTU will cause truncation and reconnection to DNS server via TCP. So almost any full = certificate will cause two serialized connections anyway UDP and TCP. If you connect to = the service and to DNS server, you can make those connections in parallel, which = considerably speeds up this (because you will need that connection to the service anyway). > Touching on revocation leads on to a further comment - there's only = very brief mention of how clients should handle revocation status = checks, and it appears to suggest that a "type 2" certificate should = not, or even must not, be checked. I'd suggest that at minimum, this = ought to be clarified. In particular, the security considerations refer = to type 2, but not type 3, certificates. True, I think we need to expand Security Considerations for type 3 as = well, since PKIX validation is not performed for Type 3 at all. > Note, incidentally, that =C2=A78 refers to "type 2", but =C2=A72.1.1 = refers to "[Certificate] usage 2" - consistency might be preferable = here. Good catch. > As a final comment, I'd presonally like to see some comments about = how, and when, extended validation information should be checked and = trusted. It seems to me that such information should be ignored when = handling type 2 or type 3 certificates; or at best it should be = validated independantly using the traditional methods - that is, it = should be treated as a type 0 or type 1 certificate for the purposes of = extended validation. I think that Extended Validation is out of the scope of this document. = And if I am not mistaken the CA which are able to issue EV certificates are hardcoded in = the browsers. Thus I think that DANE-aware applications can use standard rules for EV = certificates. > Oh, and one more nit, why not. I can't be the only person who notes = that the certificate type is a bitfield of "Suppress 5280 validation" = and "End Entity Cert" flags. I wonder if this might lead to risk if new = cert types were assigned that did not match this? Is it worthwhile = making a comment that it's explicitly not a bitfield? I may be being = overly paranoid, here. I think you might be overly paranoid :), but on the other hand a simple = note would hurt either. I am leaving this up to our editors discretion. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From peter@palfrader.org Thu Apr 12 04:35:01 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7F821F84C5; Thu, 12 Apr 2012 04:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOLkCkyWpHep; Thu, 12 Apr 2012 04:35:01 -0700 (PDT) Received: from anguilla.debian.or.at (anguilla.debian.or.at [IPv6:2001:858:10f:6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 02DEE21F84C4; Thu, 12 Apr 2012 04:35:00 -0700 (PDT) Received: by anguilla.debian.or.at (Postfix, from userid 1002) id E793C10E829; Thu, 12 Apr 2012 13:34:59 +0200 (CEST) Date: Thu, 12 Apr 2012 13:34:59 +0200 From: Peter Palfrader To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20120412113459.GW17373@anguilla.noreply.org> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 11:35:02 -0000 On Thu, 12 Apr 2012, Ond=C5=99ej Sur=C3=BD wrote: > > In Section 1.3: > >=20 > > "A DNS query can return multiple certificate associations, such as in > > the case of a server is changing from one certificate to another." > >=20 > > The sentence seems incorrect. >=20 > Dave already commented on this. I also don't see anything wrong with the > sentence. It's probably a language nit, not a factual issue. Maybe the sentence would read better as follows: | A DNS query can return multiple certificate associations, such as in | the case of a server which is changing from one certificate to another." ^^^^^ Cheers, Peter --=20 | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/ From ondrej.sury@nic.cz Thu Apr 12 04:36:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA621F84C5; Thu, 12 Apr 2012 04:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiSSOeUTcDu0; Thu, 12 Apr 2012 04:36:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BE02921F84C4; Thu, 12 Apr 2012 04:36:52 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb] (unknown [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb]) by mail.nic.cz (Postfix) with ESMTPSA id 23D7F140429; Thu, 12 Apr 2012 13:36:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334230606; bh=gO1bRHHfF2Be4fUk0TpmTrn4e5OmZBENnFhsGYcPklQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TXCrYeWh+c1Yl6tkSpGsEU3bvw0J3CWDZCeGVvyRYclcPA9SoYPkrno/X+xYdxxpx m3abBSfNvVyeZxojIdQcZb8P+SQ82Yvno2ebasKlYu8WAZz+UKBlNlzbp4aFAwICNF m68QfRrheEtMGh79lmHnHYEHcsIO9kqjElYmAdDc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120412113459.GW17373@anguilla.noreply.org> Date: Thu, 12 Apr 2012 13:36:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E79427F-7FD2-4BF8-B8E8-4E4CA71510A7@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> <20120412113459.GW17373@anguilla.noreply.org> To: Peter Palfrader X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 11:36:53 -0000 On 12. 4. 2012, at 13:34, Peter Palfrader wrote: > On Thu, 12 Apr 2012, Ond=C5=99ej Sur=C3=BD wrote: >=20 >>> In Section 1.3: >>>=20 >>> "A DNS query can return multiple certificate associations, such as = in >>> the case of a server is changing from one certificate to another." >>>=20 >>> The sentence seems incorrect. >>=20 >> Dave already commented on this. I also don't see anything wrong with = the >> sentence. >=20 > It's probably a language nit, not a factual issue. Maybe the sentence > would read better as follows: >=20 > | A DNS query can return multiple certificate associations, such as in > | the case of a server which is changing from one certificate to = another." > ^^^^^ Ah, true. I am almost blind to these kind of issues after reading this document too many times. Thanks go to both of you. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From dave@cridland.net Thu Apr 12 05:18:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454121F861A; Thu, 12 Apr 2012 05:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY+bvV+NRUAp; Thu, 12 Apr 2012 05:18:53 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 39DED21F8604; Thu, 12 Apr 2012 05:18:53 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 46CFB116808F; Thu, 12 Apr 2012 13:18:49 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afu-dXQofdJa; Thu, 12 Apr 2012 13:18:44 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 0A8F8116808D; Thu, 12 Apr 2012 13:18:44 +0100 (BST) References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> In-Reply-To: <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> MIME-Version: 1.0 Message-Id: <6155.1334233124.001138@puncture> Date: Thu, 12 Apr 2012 13:18:43 +0100 From: Dave Cridland To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= , "dane@ietf.org" , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8Bit X-Mailman-Approved-At: Thu, 12 Apr 2012 05:25:00 -0700 Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 12:18:54 -0000 On Thu Apr 12 12:03:37 2012, OndÅ™ej Surý wrote: > Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before > discussing SRV records > further. We have left SRV records on purpose and we expect that > this will be solved in > separate document (for each affected protocol). > > Foolish me, I must have missed the reference to that ticket in the draft. Really, if this is out of scope, declare it as such - but then don't use SMTP either, given that's very close in spirit to SRV. But certainly for XMPP, DANE is currently insufficient, which is a real shame. > The hashes are very useful since any UDP DNS packet not able to fit > into MTU will cause > truncation and reconnection to DNS server via TCP. So almost any > full certificate will > cause two serialized connections anyway UDP and TCP. If you > connect to the service and > to DNS server, you can make those connections in parallel, which > considerably speeds up > this (because you will need that connection to the service anyway). Yes, I do follow; perhaps I'm expecting this to be swallowed during the DNS phase rather than the service connection phase anyway. Also, I thought - possibly erroneously - that at least some operating systems were using TCP for the connection to the resolver anyway, which'd lessen this effect. In any case, I'm not going to demand that hashes are outlawed, I'm mostly moaning about the number of permutations here - testing all these is going to drive me spotty. > > As a final comment, I'd presonally like to see some comments > about how, and when, extended validation information should be > checked and trusted. It seems to me that such information should > be ignored when handling type 2 or type 3 certificates; or at best > it should be validated independantly using the traditional methods > - that is, it should be treated as a type 0 or type 1 certificate > for the purposes of extended validation. > > I think that Extended Validation is out of the scope of this > document. And if I am not > mistaken the CA which are able to issue EV certificates are > hardcoded in the browsers. > Thus I think that DANE-aware applications can use standard rules > for EV certificates. I think this needs calling out. EV seems like a very good argument for the existence of CAs in a DANE world; I think it would be beneficial to touch on the subject if possible. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From trac+dane@trac.tools.ietf.org Thu Apr 12 05:32:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763A421F853C for ; Thu, 12 Apr 2012 05:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkPm4zcOOZ6K for ; Thu, 12 Apr 2012 05:32:29 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8D21F849B for ; Thu, 12 Apr 2012 05:32:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIJCE-0000eb-0E; Thu, 12 Apr 2012 08:32:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, ondrej.sury@nic.cz X-Trac-Project: dane Date: Thu, 12 Apr 2012 12:32:17 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/39 Message-ID: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, ondrej.sury@nic.cz, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120412123229.D4E8D21F849B@ietfa.amsl.com> Resent-Date: Thu, 12 Apr 2012 05:32:29 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:32:30 -0000 #39: Address interaction between EV certs and DANE On 12. 4. 2012, at 10:26, Dave Cridland wrote: > > > As a final comment, I'd presonally like to see some comments about how, and when, > > > extended validation information should be checked and trusted. It seems to me that such > > > information should be ignored when handling type 2 or type 3 certificates; or at best it > > > should be validated independantly using the traditional methods - that is, it should be > > > treated as a type 0 or type 1 certificate for the purposes of extended validation. On Thu Apr 12 12:03:37 2012, OndÅ™ej Surý wrote: > > I think that Extended Validation is out of the scope of this document. And if I am not > > mistaken the CA which are able to issue EV certificates are hardcoded in the browsers. > > Thus I think that DANE-aware applications can use standard rules for EV certificates. On 12. 4. 2012, at 14:18, Dave Cridland wrote: > I think this needs calling out. EV seems like a very good argument for the existence of CAs in > a DANE world; I think it would be beneficial to touch on the subject if possible. So I am opening issue for EV certs. Does WG have any opinion how to address this? -- ---------------------------+---------------------------------------- Reporter: ondrej.sury@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ---------------------------+---------------------------------------- Ticket URL: dane From ondrej.sury@nic.cz Thu Apr 12 05:33:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A704421F865A; Thu, 12 Apr 2012 05:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eQwkSIdY7Ub; Thu, 12 Apr 2012 05:33:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CC5CE21F862F; Thu, 12 Apr 2012 05:33:23 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb] (unknown [IPv6:2001:1488:ac14:1400:de3:3a2e:898e:dddb]) by mail.nic.cz (Postfix) with ESMTPSA id 27FBE140421; Thu, 12 Apr 2012 14:33:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334234003; bh=N9sb2MvbZMy3t18F7mvvIR4barc7W+y/FGsrk0c9LJA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N9N9HeAOwDyXFuydiSHgONjcAdv5MI+fahJ5e/1E3FHPb55pNsVAx7hA1fBvmqO+V 9gsMTnGv+FBSH3MWuvzpuEe+TAgyom2npczoxjQvi0zZqSizVB6t9YjnlefyKwd7al FwIZJ8+aBOU4i8FCIp1ZatH4+sNOyOS87HGO++aQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6155.1334233124.001138@puncture> Date: Thu, 12 Apr 2012 14:33:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99E176A1-AC49-480F-93A4-0997179E7772@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> <6155.1334233124.001138@puncture> To: Dave Cridland , xmpp@ietf.org X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: IETF-Discussion , "dane@ietf.org list" Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 12:33:24 -0000 On 12. 4. 2012, at 14:18, Dave Cridland wrote: > On Thu Apr 12 12:03:37 2012, Ond=C5=99ej Sur=C3=BD wrote: >> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before = discussing SRV records >> further. We have left SRV records on purpose and we expect that this = will be solved in >> separate document (for each affected protocol). > Foolish me, I must have missed the reference to that ticket in the = draft. >=20 > Really, if this is out of scope, declare it as such - but then don't = use SMTP either, given that's very close in spirit to SRV. >=20 > But certainly for XMPP, DANE is currently insufficient, which is a = real shame. We would certainly welcome new document defining interaction of XMPP and = DANE. But I think that this needs to be crafted in the XMPP working group. >> > As a final comment, I'd presonally like to see some comments about = how, and when, extended validation information should be checked and = trusted. It seems to me that such information should be ignored when = handling type 2 or type 3 certificates; or at best it should be = validated independantly using the traditional methods - that is, it = should be treated as a type 0 or type 1 certificate for the purposes of = extended validation. >> I think that Extended Validation is out of the scope of this = document. And if I am not >> mistaken the CA which are able to issue EV certificates are hardcoded = in the browsers. >> Thus I think that DANE-aware applications can use standard rules for = EV certificates. >=20 > I think this needs calling out. EV seems like a very good argument for = the existence of CAs in a DANE world; I think it would be beneficial to = touch on the subject if possible. Alright point taken. I have opened = http://trac.tools.ietf.org/wg/dane/trac/ticket/39 O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From stpeter@stpeter.im Thu Apr 12 05:35:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7DA21F8587; Thu, 12 Apr 2012 05:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLH-j6UlB16q; Thu, 12 Apr 2012 05:35:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBEB21F8572; Thu, 12 Apr 2012 05:35:10 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7810A40058; Thu, 12 Apr 2012 06:49:03 -0600 (MDT) Message-ID: <4F86CBF5.20809@stpeter.im> Date: Thu, 12 Apr 2012 06:35:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> <70B6EFCD-62B6-46C2-A0ED-38DF80FE9C6F@nic.cz> <6155.1334233124.001138@puncture> <99E176A1-AC49-480F-93A4-0997179E7772@nic.cz> In-Reply-To: <99E176A1-AC49-480F-93A4-0997179E7772@nic.cz> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "dane@ietf.org list" , xmpp@ietf.org, Dave Cridland Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 12:35:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/12/12 6:33 AM, OndÅ™ej Surý wrote: > > On 12. 4. 2012, at 14:18, Dave Cridland wrote: > >> On Thu Apr 12 12:03:37 2012, OndÅ™ej Surý wrote: >>> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 >>> before discussing SRV records further. We have left SRV >>> records on purpose and we expect that this will be solved in >>> separate document (for each affected protocol). >> Foolish me, I must have missed the reference to that ticket in >> the draft. >> >> Really, if this is out of scope, declare it as such - but then >> don't use SMTP either, given that's very close in spirit to SRV. >> >> But certainly for XMPP, DANE is currently insufficient, which is >> a real shame. > > We would certainly welcome new document defining interaction of > XMPP and DANE. But I think that this needs to be crafted in the > XMPP working group. We had a long discussion about this in the DANE WG. Matt Miller and I volunteered to write a document about this, but other folks are welcome to beat us to it if they please. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Gy/UACgkQNL8k5A2w/vxtQACdHKlwz1UOSs/G3dxO+rxdHJBu DgwAoJMMl59ahGahNzWgL9iNAGFRAnDA =R3AD -----END PGP SIGNATURE----- From sm@resistor.net Thu Apr 12 08:35:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F5521F8683 for ; Thu, 12 Apr 2012 08:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yj1-IZwQCzm8 for ; Thu, 12 Apr 2012 08:35:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5B21F8606 for ; Thu, 12 Apr 2012 08:35:24 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3CFZJtb020951 for ; Thu, 12 Apr 2012 08:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334244924; i=@resistor.net; bh=LSGIO6Tay9c0kSKQqWsLdVGmxYwuZqysYXIGVx/fqUk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=fD0MDcXTHyEm/a0WezvTw0+x8RgIiyW+jQLEOVPVEGIXv3rbc44WqV+rQMnfCqjmF k1niWSWUS350gvJ9Zkta+ZrBjcLJe6xw4cqbgR+QfPeYIW/vN/1ixfmlKzFU9lkyMq 1fIJjSYZ1qw1RhS2vQfa4kJwjRPlU2sKfRt4ldaU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334244924; i=@resistor.net; bh=LSGIO6Tay9c0kSKQqWsLdVGmxYwuZqysYXIGVx/fqUk=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=DmXctcb+u+Hglwi5bUrNl30nbKTl1hXt834lZIgsj9fwB0z6enqwwOrWaT8k9tOne LIpWcFNdC8zs4o7v9Ai1NZbw89/TKe0hk77ot8FJDPMwDhBciB70aES0E76cQGBAdB O1A7+ioDxrSLeZZGaQpmugyXHwFlzZe5o1qDSz0s= Message-Id: <6.2.5.6.2.20120412074829.0ae6afd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 08:35:17 -0700 To: dane@ietf.org From: SM In-Reply-To: <6155.1334219161.556547@puncture> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 15:35:29 -0000 At 01:26 12-04-2012, Dave Cridland wrote: >On Thu Apr 12 08:11:43 2012, SM wrote: >No, this seems correct, in as much as multiple TLSA records can be >returned. A forward reference to =A7A.4 would be handy here. Suggested text: A DNS query can return multiple certificate associations, such as in the case of a certificate rollover. I would add a forward reference as suggested by Dave. Regards, -sm =20 From stpeter@stpeter.im Thu Apr 12 08:57:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8467421F85F9 for ; Thu, 12 Apr 2012 08:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omeMAyDjKKEJ for ; Thu, 12 Apr 2012 08:57:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E04B21F85BD for ; Thu, 12 Apr 2012 08:57:27 -0700 (PDT) Received: from dhcp-64-101-72-235.cisco.com (unknown [64.101.72.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B3BE40058; Thu, 12 Apr 2012 10:11:21 -0600 (MDT) Message-ID: <4F86FB65.901@stpeter.im> Date: Thu, 12 Apr 2012 09:57:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: SM References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> <6.2.5.6.2.20120412074829.0ae6afd8@resistor.net> In-Reply-To: <6.2.5.6.2.20120412074829.0ae6afd8@resistor.net> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 15:57:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/12/12 9:35 AM, SM wrote: > At 01:26 12-04-2012, Dave Cridland wrote: >> On Thu Apr 12 08:11:43 2012, SM wrote: No, this seems correct, in >> as much as multiple TLSA records can be returned. A forward >> reference to §A.4 would be handy here. > > Suggested text: > > A DNS query can return multiple certificate associations, such as > in the case of a certificate rollover. > > I would add a forward reference as suggested by Dave. +1. It's really important to make this clear because rollover will be critical for ops. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+G+2UACgkQNL8k5A2w/vzQhACfZvDWGVuqhcnS8//B8dp1oYws loAAoNEWStk5GTVkbQDEphKdJcQTnE12 =c2H4 -----END PGP SIGNATURE----- From gnu@toad.com Thu Apr 12 10:30:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F5E21F86B2 for ; Thu, 12 Apr 2012 10:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeemXT0ppJEt for ; Thu, 12 Apr 2012 10:30:37 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id ACDFC21F854F for ; Thu, 12 Apr 2012 10:30:35 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3CHUZcF021835; Thu, 12 Apr 2012 10:30:35 -0700 Message-Id: <201204121730.q3CHUZcF021835@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Thu, 12 Apr 2012 10:30:35 -0700 From: John Gilmore Subject: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:30:38 -0000 Typo: s/certifcate/certificate/ Section 7.1: s/will be submitted/has been submitted/ . I'm surprised that we don't have an assigned value for the TLSA rrtype yet. Section 7.3: value 3, "Domain-issued certificate" has an extra space misaligning its [Reference] value. Section 8 and 8.1 have serious problems that deserve a whole separate email message. Section 8: The last paragraph should be removed, because it unnecessarily disparages the security of the protocol defined by this RFC. Section 8.1: This newly inserted section needs serious work. It was inappropriate to insert this inflammatory section into the document immediately before Last Call, with little mailing list discussion beforehand. Appendix A.1 is totally focused on CA-based examples, and provides no guidance to users who want to deploy non-CA-based DANE. Nor does it provide any guidance for domain administrators who are not sure whether they want CA-based DANE or non-CA-based DANE. I had written and submitted text about this, but none of it made it into the document. The appendix is written as if there is not even an option in DANE to avoid using CAs. One might reasonably come to the conclusion that committee members associated with CAs are deliberately slanting the readers of the document toward their business model. This is not appropriate in an RFC. Appendix C: Is missing examples for usage type 3. John From sm@resistor.net Thu Apr 12 10:49:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6718D21F85B4 for ; Thu, 12 Apr 2012 10:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZo4n90CiZvQ for ; Thu, 12 Apr 2012 10:49:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB84821F85B1 for ; Thu, 12 Apr 2012 10:49:32 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3CHnRw3021933; Thu, 12 Apr 2012 10:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334252972; i=@resistor.net; bh=5nW97oMrAUkOaJpduZRdgad9eIEfgVKD5h4cDHdUeiQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Pu4ilIeeEpSn9rNiJxfYLvkasxBMm6FM/NiVcgJ2EL35rxOsYdVEcVJCSkt2TUgxh TeVFgmGPKhs0EIjFssSxNSjL9Q7yqStxeTOS95LiTVzSdAfcFrFinYXO6/ntvyzozz CMzuxYdtxJnHNLCvCq0t22BSQg5B+jqytOFo5w/s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334252972; i=@resistor.net; bh=5nW97oMrAUkOaJpduZRdgad9eIEfgVKD5h4cDHdUeiQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=swF1GSH8L35Znsy4yFec5/6slQ3O4ADXvQO9s+3nGpJu799UTOmxJOlHG+bMZMyow sjGoQGoFmZ0rR6W90DcP+7crFgepoFPyWJf90J++Zc6avb78QzCZRW2MQvz4wTogIm 7kw64peeexSnpyLOZ3iHtFrxDYOTYFXtja/O37A8= Message-Id: <6.2.5.6.2.20120412104202.09ab2338@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 10:48:49 -0700 To: John Gilmore From: SM In-Reply-To: <201204121730.q3CHUZcF021835@new.toad.com> References: <201204121730.q3CHUZcF021835@new.toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 17:49:33 -0000 At 10:30 12-04-2012, John Gilmore wrote: >Section 7.1: s/will be submitted/has been submitted/ . I'm surprised >that we don't have an assigned value for the TLSA rrtype yet. It's sometimes easier to add the assigned value on publication of a document as a RFC. The request for the TLSA RRTYPE has already been accepted. Regards, -sm From gnu@toad.com Thu Apr 12 12:03:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555BF21F858E for ; Thu, 12 Apr 2012 12:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.503 X-Spam-Level: * X-Spam-Status: No, score=1.503 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_20=-0.74, RCVD_IN_NJABL_RELAY=2.696, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+PXvzT5yqeh for ; Thu, 12 Apr 2012 12:03:57 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 4F49421F858D for ; Thu, 12 Apr 2012 12:03:57 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3CJ3ucF026698; Thu, 12 Apr 2012 12:03:56 -0700 Message-Id: <201204121903.q3CJ3ucF026698@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Thu, 12 Apr 2012 12:03:56 -0700 From: John Gilmore Subject: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:03:58 -0000 The last graf of section 8, and the whole of section 8.1, seem designed to prop up CA-based businesses, by fragmenting and disparaging the security of the DANE protocol that the RFC proposes. Our job as a committee was to design something that would be MORE secure than CA-based TLS. If the committee truly believes that it can't tell whether DANE for TLS will be more secure or less secure than CA-based TLS (which is what draft-19 now says in brand-new text inserted in Section 8.1), then IETF should avoid standardizing DANE for TLS, and disband the committee as incompetent. Instead, many on the committee have proposed that DANE for TLS become a Proposed Standard. That means that we *do* think that it will produce better security than the status quo. Therefore, we should remove the sections from the document that inappropriately bash the security of DANE for TLS. And we should remove the suggestion that because certain mandatory-to-implement TLSA records don't happen to support CA-based business models, implementors should provide local options to reject those TLSA records. The newly inserted Section 8.1 needs serious work. It was inappropriate to insert this inflammatory section into the document immediately before Last Call, with little mailing list discussion beforehand. Again, it is an inappropriate attack on non-CA-based DANE. I would be happy to work with the committee on text for this Internet-Draft (or Proposed Standard RFC) that would contrast the security of DANE-for-TLS with the security of the status-quo-ante TLS, either for a single secure website, or for the Internet as a whole, or both. The text that's in Section 8.1 is not accurate, and is slanted to inappropriately favor particular market participants. If the committee is interested in a "quick fix" so we can rush the RFC into print, I would be happy with removing the entire misleading section 8.1, and removing the MUST-undermining last paragraph of section 8. Now for the details: Section 8, last paragraph: The last paragraph should be removed, because it is designed to fragment the market for DANE for TLS by encouraging implementers to "locally" disable the mandatory-to-implement certificate usage types 2 and 3. It was inserted without discussion in draft-18 and was objected to at that point, but has been retained in "last call" draft-19. It is part of the design of DANE that if it is widely implemented among clients, then TLS servers can rely solely on keys stored in their DNS zone, avoiding the use of CAs. Section 6 of the draft uses a MUST to require implementation of DANE's certificate usage types 2 and 3, which provide non-CA-based key certification, but this paragraph of small print deliberatly seeks to take away what the large print grants, undermining that MUST by encouraging a "local policy" of denying these usage types. (A local policy to "deny the trust" of these keys is equivalent to not implementing them at all.) I claim that this paragraph is not motivated by actual security concerns, but by competitive business concerns. Certifying Authority-based businesses want usage types 2 and 3 to become unusable in some significant percentage of clients, because if that came about, every TLS server would continue to be required to pay some CA-based business money every year for a certificate. If usage types 2 and 3 are as widely implemented as usage types 0 and 1, then TLS servers would be free to stop paying CAs annually. This paragraph and Section 8.1 are the CAs' weapons in that market struggle. They are welcome to compete in the security market, but it is not the job of IETF RFCs to help them retain their oligopoly in that market. I sent an email yesterday about this concern, before draft-19: https://www.ietf.org/mail-archive/web/dane/current/msg04609.html I raised the details of my objections in -18 in an earlier message here: https://www.ietf.org/mail-archive/web/dane/current/msg04565.html Section 8.1, entire section: The whole section compares apples to oranges by comparing "a DNSSEC validator" not with "a certificate-chain constructor and validator" but with unspecified single CAs. To compare apples to apples, it would compare an unspecified single CA with an unspecified single domain administrator. It claims to be "Comparing DANE to Public CAs", but it doesn't even attempt to do that. Instead it cherry-picks the most problematic parts of DANE security in misleading comparisons. It doesn't even note that DANE is designed to increase the security of CA usage for users who want them, while also offering high security to users who for any reason want to avoid CAs. If the intent of the section is to discuss the effect of DANE on the security of the whole Internet, then a system-level look at both the status quo's and DANE's security is required, not a patchwork comparison of individual elements of that security. If the intent is merely to discuss the effect of DANE on the security of an individual service that uses TLS (such as a single secure web site), then a system-level look at that individual service is required. Section 8.1 has not provided either one; it makes unsupported assertions about one element of CA-based TLS, while making other unsupported assertions about a different element of DANE-based TLS. The 1st graf of 8.1 makes little sense to me. It claims that a DANE client using an external DNSSEC validator is "as vulnerable as" a TLS client of today. It states a tautology by saying that any client that relies on any external source of trust can be fooled by relying on an untrustworthy source. But then it bootstraps that into misleadingly saying that DANE is "as vulnerable" as current TLS. This is wrong, because a TLS client of today is vulnerable to compromise from hundreds of trusted entities, most or all of which the client has no contractual relationship with, and most or all of which were never explicitly configured or examined by the user of the client. A DANE client using an exernal DNSSEC validator is vulnerable to compromise from a single trusted entity, that validator, plus another small number of trusted entities which provide domain name service for the domains that the client accesses. There are no pre-configured external DNSSEC validators in TLS client software, as there are with trust anchors, so any exernal DNSSEC validator would have to be configured manually by the user of the client, requiring explicit action to configure it insecurely. Also, the client's user probably has a contract or other close relationship (such as being in the same corporation) with an entity that provides it with an external DNSSEC validator, so the user can more easily monitor its trustworthiness. For example, the user's ISP might provide external DNSSEC validation, as they today provide recursive DNS service, and most users have a contract with their ISP. But the whole graf is mostly irrelevant, because external DNSSEC validators running on other peoples' machines are only expected to be used by a small fraction of the DANE clients. The second graf makes an unsupported assumption ("If it is less likely that a user will hear about...") to produce a scare quote ("could be worse off than a current TLS client"). Similarly, the 3rd graf seems to be unsupported by facts. It says "Current public CAs are assumed to have better defenses than current DNSSEC validators", but I don't think that there are any current DNSSEC validators to compare current public CAs to. "Better defenses" is ipso facto a misleading phrase unless it specifies against what threat model it is defending. Furthermore, some current public CAs have been proven to have poor defenses, since they have issued invalid certificates used in mass man-in-the-middle attacks against the population of entire countries. Since some current public CAs are known to be untrustworthy, it's hard to support saying that "current public CAs" in general are assumed to have good defenses. It then goes on to say that "this perception" can't be proven one way or the other. Barrooms, not RFCs, are the place for such poorly supported statements. The first two grafs discuss "external DNSSEC validators", but the third and final graf slyly shifts the ground to "DNSSEC validators" in general, without making this change obvious. And, again validators are only a small part of the DANE ecosystem, but this section doesn't go into any other part, while claiming to compare the totality of DANE's security. I believe that today's "internal" DNSSEC validators are considered as trustworthy as today's "internal" certificate-chain constructors and validators as used today in TLS. These are both cryptographic libraries that have undergone substantial testing and widespread deployment over a period of many years. I believe that if the RFC is going to make statements about the relative security DANE and of CA-based TLS, we should clearly state that many well-qualified security experts and network administrators have serious concerns about the security of CA-based TLS. I would be happy to provide citations for some such statements, that the RFC could reference as informative. We should also state that the only reason for the continued widespread use of CA-based TLS is that there is no credible alternative ready for mass market use. (The role of this committee is to produce such an alternative -- not to undermine its new alternative.) The draft currently states in Section 1.1 that the actual security in practice of traditional TLS CAs has been demonstrated to vary widely among different CAs, from completely trustworthy to completely untrustworthy. We all know that more than a few CAs have had their trust anchors removed from popular TLS software due to public breaches. A few other CAs who suffered breaches required specific software patches in mass market TLS software such as browsers, because their certificates were too widely used to allow their trust anchors to be removed due to a single breach that issued a small number of invalid certificates. We all fervently hope that that CA won't allow another breach to occur, but such a history does not give us great confidence. I believe it is too early to say anything about the actual security in practice of TLSA-protected domain names, since there is no operational history to guide us. We don't even have an RRTYPE for TLSA yet! It is *designed* to be secure, but so was CA-based TLS designed to be secure, and yet CA-based TLS has not always been secure. We have designed DANE to be MORE secure than CA-based TLS, for specified reasons. Only time will tell. The conclusion of section 8.1 "Thus, it is difficult to foresee which system has a higher risk." is invalid. As Steve Kent pointed out, and as our document now states, DANE for TLS incorporates the principle of least privilege, which fixes the largest vulnerability in CA-based TLS. John Gilmore From paul@nohats.ca Thu Apr 12 12:21:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D771921F8667; Thu, 12 Apr 2012 12:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yirJ4344X0F1; Thu, 12 Apr 2012 12:21:40 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3D91521F864D; Thu, 12 Apr 2012 12:21:39 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 9C5C880335; Thu, 12 Apr 2012 15:21:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 958EE80331; Thu, 12 Apr 2012 15:21:38 -0400 (EDT) Date: Thu, 12 Apr 2012 15:21:38 -0400 (EDT) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> Message-ID: References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 19:21:42 -0000 On Thu, 12 Apr 2012, OndÅ™ej Surý wrote: >> As a comment that does not argue for any change, having SHA-256 hash as the "lowest" hash excludes SHA-1, a widely deployed hash algorithm. I gather that the WG has made a tradeoff between perceived security and ease of deployment. > > SHA-2 was first published 11 years ago and I don't really think that > applications which will decide to implement DANE will not have support > for SHA-2 family. Using SHA1 at this point is actually more of a risk then using SHA2. If you want to run your OS or device in FIPS mode, you may not use SHA1 for anything. I am seeing a lot of breakage in fips mode where apps just assume a sha1 call never fails. That's long past us now. Don't count on sha1 being available. Paul From gnu@toad.com Thu Apr 12 12:23:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A23821F858D for ; Thu, 12 Apr 2012 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEMxysrgS8C3 for ; Thu, 12 Apr 2012 12:23:25 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id C25F621F8693 for ; Thu, 12 Apr 2012 12:23:25 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3CJNPcF027743; Thu, 12 Apr 2012 12:23:25 -0700 Message-Id: <201204121923.q3CJNPcF027743@new.toad.com> To: "dane issue tracker" In-reply-to: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> References: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> Comments: In-reply-to "dane issue tracker" message dated "Thu, 12 Apr 2012 12:32:17 -0000." Date: Thu, 12 Apr 2012 12:23:25 -0700 From: John Gilmore Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org Subject: Re: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 19:23:26 -0000 > So I am opening issue for EV certs. Does WG have any opinion how to address this? Is there some RFC or standards-track Internet-Draft for EV certs? Wikipedia suggests that it's an ad-hoc non-standard created by some CA vendors and web browser makers. It's apparently issued by the "CA/Browser Forum", an unincorporated entity that doesn't even offer an EV certificate on its own secure web site (https://www.cabforum.org). The Forum recently announced a Working Group designed to reform itself into an org that offers wider participation, "a more open and public process", etc. If it's not an IETF standard, I suggest that we ignore it. To the IETF, a cert is a cert is a cert, and the RFCs on certs are careful not to specify much about the exact contents of a cert, or how clients should handle all the fiddly little bits attached to them. DANE should do the same. John From gnu@toad.com Thu Apr 12 12:30:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4021F865C; Thu, 12 Apr 2012 12:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.32 X-Spam-Level: X-Spam-Status: No, score=0.32 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o19DXUVC7pn7; Thu, 12 Apr 2012 12:30:06 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id C878F21F8653; Thu, 12 Apr 2012 12:30:05 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3CJU1cF028070; Thu, 12 Apr 2012 12:30:01 -0700 Message-Id: <201204121930.q3CJU1cF028070@new.toad.com> To: Dave Cridland In-reply-to: <6155.1334219161.556547@puncture> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <6155.1334219161.556547@puncture> Comments: In-reply-to Dave Cridland message dated "Thu, 12 Apr 2012 09:26:01 +0100." Date: Thu, 12 Apr 2012 12:30:01 -0700 From: John Gilmore Cc: IETF-Discussion , "dane@ietf.org" Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 19:30:06 -0000 > On Thu Apr 12 08:11:43 2012, SM wrote: > > In Section 1.3: > > > > "A DNS query can return multiple certificate associations, such > > as in > > the case of a server is changing from one certificate to > > another." > > > > The sentence seems incorrect. > > > No, this seems correct, in as much as multiple TLSA records can be > returned. A forward reference to §A.4 would be handy here. I think he was referring to the grammar. Shouldn't it say: "A DNS query can return multiple certificate associations, such as in the case of a server that is changing from one certificate to another." ["that" inserted.] John From gnu@toad.com Thu Apr 12 12:36:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CFF21F86D1 for ; Thu, 12 Apr 2012 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzebGPBU4MnS for ; Thu, 12 Apr 2012 12:36:58 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7095321F86CB for ; Thu, 12 Apr 2012 12:36:58 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3CJavcF028350; Thu, 12 Apr 2012 12:36:57 -0700 Message-Id: <201204121936.q3CJavcF028350@new.toad.com> To: SM , dane@ietf.org, gnu@toad.com In-reply-to: <6.2.5.6.2.20120411202530.085195c0@resistor.net> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> Comments: In-reply-to SM message dated "Thu, 12 Apr 2012 00:11:43 -0700." Date: Thu, 12 Apr 2012 12:36:57 -0700 From: John Gilmore Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 19:36:59 -0000 > HTTPS for www.example.com is a straight-forward example. In the case > of a SMTP server, it is not as easy. Once the target host is > located, mail.example.com in this case, one might assume that the > server would advertise that hostname or the domain name used to > locate the target host as an identity. That's rarely the case due to > issues outside the scope of DANE. It's easier not to use the > STARTTLS protocol as an example. Could you give us an example of why that's rarely the case? I for one am planning to use DANE to secure STARTTLS on my own domain (toad.com), and I'd like to know why you think that won't work. The draft is for all protocols that layer on top of TLS. (Do we even have a list of such protocols? Or the IETF-standardized subset of them? We all know about https and STARTTLS; what else?) If there are specific deployment issues that would make it not work for some of those protocols, we should either fork a separate document for those protocols (as we have done for e.g. IPSEC), or we should address the deployment issues somewhere in the draft. John From mrex@sap.com Thu Apr 12 13:27:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176CD21F863F for ; Thu, 12 Apr 2012 13:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsCfT3UTHLFF for ; Thu, 12 Apr 2012 13:27:56 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB2821F8633 for ; Thu, 12 Apr 2012 13:27:56 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3CKRsRo004468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 22:27:54 +0200 (MEST) From: Martin Rex Message-Id: <201204122027.q3CKRsx4011651@fs4113.wdf.sap.corp> To: sm@resistor.net (SM) Date: Thu, 12 Apr 2012 22:27:54 +0200 (MEST) In-Reply-To: <6.2.5.6.2.20120412074829.0ae6afd8@resistor.net> from "SM" at Apr 12, 12 08:35:17 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:27:57 -0000 SM wrote: > > At 01:26 12-04-2012, Dave Cridland wrote: > >On Thu Apr 12 08:11:43 2012, SM wrote: > >No, this seems correct, in as much as multiple TLSA records can be > >returned. A forward reference to §A.4 would be handy here. > > Suggested text: > > A DNS query can return multiple certificate associations, such as in > the case of a certificate rollover. > > I would add a forward reference as suggested by Dave. For completeness, in TLS the type of the public key and the key exchange algorithm of the ciphersuite are entangled, so a server that wants to offer ciphersuites with different kind of key exchange algorithms, e.g. traditional RSA plus newer ECDSA ciphersuites, would have to use two distinct server certificates for this. Add to this cert hashes with different Algorithms and concurrent rollover to all server certs and you quickly get into the low 2-digit numbers of TLSA records... -Martin From gnu@toad.com Thu Apr 12 13:32:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3832D21F86D9 for ; Thu, 12 Apr 2012 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.178 X-Spam-Level: * X-Spam-Status: No, score=1.178 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_05=-1.11, RCVD_IN_NJABL_RELAY=2.696, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47iwqT5kRSVT for ; Thu, 12 Apr 2012 13:32:36 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id BE9B321F86E4 for ; Thu, 12 Apr 2012 13:32:36 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3CKWWcF031380; Thu, 12 Apr 2012 13:32:32 -0700 Message-Id: <201204122032.q3CKWWcF031380@new.toad.com> To: Stephen Kent In-reply-to: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> Comments: In-reply-to Stephen Kent message dated "Wed, 11 Apr 2012 20:56:51 -0400." Date: Thu, 12 Apr 2012 13:32:32 -0700 From: John Gilmore Cc: Paul Hoffman , dane list Subject: Re: [dane] 5: PKI disrepute X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 20:32:38 -0000 > I have a couple of minor problems with some of the text John provided. OK. > The key is not "bogus." It is the binding of the key to the name that is bogus. I agree that "bogus key" was shorthand. Yes, the binding is not appropriate. Yes, the key is valid in the sense that it has the proper bits set to operate with the encryption algorithm. But the key *is* bogus, false, insecure, inappropriate, malevolent, untrustworthy... because its private key is known to the attacker, not to the true owner of the site. But we haven't mentioned the attacker, and shouldn't; this is an introduction. The draft also uses the term "bogus keys" earlier in the introduction, in a context where it's clear what makes them false ("If secret keys are revealed, or if public keys can be replaced by bogus keys, these systems provide little or no security.") > Recent experiences with compromises of CAs or their trusted partners > have lead to very serious security problems, such as the subversion > of major web sites trusted by millions of users. > > The web sites may not have been subverted. What happened was that > users were no longer able to verify that they were connecting to the > web sites they indicated via the URLs that the users employed. I presume you were quoting the first sentence and commenting on it in the second. You're being way too technical here. The web sites were subverted in the strong sense that many users' interactions and credentials (login names and passwords) were recorded by the man-in-the-middle and then used against the interests of those users. I believe that some governments used those credentials by changing the account passwords or deleting the accounts from the service, so the relevant activists could no longer communicate, but just now I'm having trouble finding a public reference that supports that belief. The users were indeed "connecting to the web sites they indicated via the URLs that the users employed". Users could even verify that they were talking to the intended web site. The problem was that that connection was being observed in the clear by a malevolent third party who acted as a man in the middle of their encrypted connection. See for example: https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1/rapport-fox-it-operation-black-tulip-v1-0.pdf https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https https://www.freedom-to-tinker.com/blog/sjs/web-browsers-and-comodo-disclose-successful-certificate-authority-attack-perhaps-iran http://www.thetechherald.com/articles/CAs-respond-to-EFF-report-on-problems-with-SSL-certificates/13265/ http://www.zdnet.com.au/eff-finds-evidence-of-more-cas-breached-339325136.htm http://www.appfail.com/read/304/Comodo-SSL-Certificate-Authority-Breach/ http://www.metafilter.com/106990/DigiNotar-SSL-certificate-compromise http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity http://files.cloudprivacy.net/ssl-mitm.pdf https://www.f-secure.com/weblog/archives/00002231.html http://www.wired.com/threatlevel/2011/03/comodo-compromise/ http://news.techworld.com/security/3336205/trustwave-issued-digital-certificate-allowing-ssl-spying/ John From stephen.farrell@cs.tcd.ie Thu Apr 12 13:37:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18821F84C5 for ; Thu, 12 Apr 2012 13:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.809 X-Spam-Level: X-Spam-Status: No, score=-101.809 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Liu-da2ao8fF for ; Thu, 12 Apr 2012 13:37:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B502D21F84FB for ; Thu, 12 Apr 2012 13:37:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A853617147C; Thu, 12 Apr 2012 21:37:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334263033; bh=/+Ph0lWMBBkIyO qUt7VOWs1Hnn8g0eFB1LWJqcjSXkM=; b=qRObApKmYua5klLFrEEHyo5JNkomMj OvS18rEBUApp/hQAc2hv3Pl7alXzQ41772N92b2uYJ6SakHmpOyFa8/D1tTx5z09 1+mscUX1uT7GHQybh9z1bdAz5YOuqpgTCyQJaTA8YuIH945CzptaOQEq6rhtiA6d J9GeYhQTsiIpj+DHxzONejOg27sQhQ3cx5KWW2ET5zVGeXrQS5X5A0KJy9Ulbkom mHfMFgu4ksqKELE+cmbou5XKMqmvFXFy1cmP66WgeHZXFT5HAoFwGqo35snd9tQt buSDe6E8B2K4Rypsmj1AGSxNtu/U7vBvYxAkpSJ8yHeFLk4IBqm+VJ7Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iddlz4BphGg4; Thu, 12 Apr 2012 21:37:13 +0100 (IST) Received: from [10.87.48.3] (unknown [86.45.63.74]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E7A90171474; Thu, 12 Apr 2012 21:37:12 +0100 (IST) Message-ID: <4F873CF8.8030805@cs.tcd.ie> Date: Thu, 12 Apr 2012 21:37:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <201204121903.q3CJ3ucF026698@new.toad.com> In-Reply-To: <201204121903.q3CJ3ucF026698@new.toad.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Inappropriate Section 8 of draft-ietf-dane-protocol-19.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:37:19 -0000 So I think that section 8.1 was added as a result of some discussion arising from my AD review. A couple of things wrt that and John's mail: - The WG should feel entirely free to do what's right, don't treat this text specially bacause it came about as a result of an AD review. - The comment that gave rise to this was only about comparing a current-PKI client against a DANE client that uses an external DNSSEC validator. There are certainly better ways to use DANE than that, but I think the external validator is a interesting point of comparison that does show that there are non-obvious trade-offs here. It could well be 8.1 isn't clear enough that its only the external validator case that being compared. - I also agree that 8.1 isn't all encompassing nor a full analysis. But then it doesn't have to be to be useful. - Fixing/improving stuff like this at IETF LC seems like a fine thing. (I just hope it doesn't take too many mails:-) S. On 04/12/2012 08:03 PM, John Gilmore wrote: > The last graf of section 8, and the whole of section 8.1, seem > designed to prop up CA-based businesses, by fragmenting and > disparaging the security of the DANE protocol that the RFC proposes. > > Our job as a committee was to design something that would be MORE > secure than CA-based TLS. If the committee truly believes that it > can't tell whether DANE for TLS will be more secure or less secure > than CA-based TLS (which is what draft-19 now says in brand-new text > inserted in Section 8.1), then IETF should avoid standardizing DANE > for TLS, and disband the committee as incompetent. > > Instead, many on the committee have proposed that DANE for TLS become > a Proposed Standard. That means that we *do* think that it will > produce better security than the status quo. Therefore, we should > remove the sections from the document that inappropriately bash the > security of DANE for TLS. And we should remove the suggestion that > because certain mandatory-to-implement TLSA records don't happen to > support CA-based business models, implementors should provide local > options to reject those TLSA records. > > The newly inserted Section 8.1 needs serious work. It was > inappropriate to insert this inflammatory section into the document > immediately before Last Call, with little mailing list discussion > beforehand. Again, it is an inappropriate attack on non-CA-based > DANE. > > I would be happy to work with the committee on text for this > Internet-Draft (or Proposed Standard RFC) that would contrast the > security of DANE-for-TLS with the security of the status-quo-ante TLS, > either for a single secure website, or for the Internet as a whole, or > both. The text that's in Section 8.1 is not accurate, and is slanted > to inappropriately favor particular market participants. If the > committee is interested in a "quick fix" so we can rush the RFC into > print, I would be happy with removing the entire misleading section > 8.1, and removing the MUST-undermining last paragraph of section 8. > > Now for the details: > > Section 8, last paragraph: > > The last paragraph should be removed, because it is designed to > fragment the market for DANE for TLS by encouraging implementers to > "locally" disable the mandatory-to-implement certificate usage types 2 > and 3. It was inserted without discussion in draft-18 and was > objected to at that point, but has been retained in "last call" > draft-19. > > It is part of the design of DANE that if it is widely implemented > among clients, then TLS servers can rely solely on keys stored in > their DNS zone, avoiding the use of CAs. Section 6 of the draft uses > a MUST to require implementation of DANE's certificate usage types 2 > and 3, which provide non-CA-based key certification, but this > paragraph of small print deliberatly seeks to take away what the large > print grants, undermining that MUST by encouraging a "local policy" of > denying these usage types. (A local policy to "deny the trust" of > these keys is equivalent to not implementing them at all.) > > I claim that this paragraph is not motivated by actual security > concerns, but by competitive business concerns. Certifying > Authority-based businesses want usage types 2 and 3 to become unusable > in some significant percentage of clients, because if that came about, > every TLS server would continue to be required to pay some CA-based > business money every year for a certificate. If usage types 2 and 3 > are as widely implemented as usage types 0 and 1, then TLS servers > would be free to stop paying CAs annually. This paragraph and Section > 8.1 are the CAs' weapons in that market struggle. They are welcome > to compete in the security market, but it is not the job of IETF RFCs > to help them retain their oligopoly in that market. > > I sent an email yesterday about this concern, before draft-19: > > https://www.ietf.org/mail-archive/web/dane/current/msg04609.html > > I raised the details of my objections in -18 in an earlier message here: > > https://www.ietf.org/mail-archive/web/dane/current/msg04565.html > > Section 8.1, entire section: > > The whole section compares apples to oranges by comparing "a DNSSEC > validator" not with "a certificate-chain constructor and validator" > but with unspecified single CAs. To compare apples to apples, it > would compare an unspecified single CA with an unspecified single > domain administrator. > > It claims to be "Comparing DANE to Public CAs", but it doesn't even > attempt to do that. Instead it cherry-picks the most problematic > parts of DANE security in misleading comparisons. It doesn't even note > that DANE is designed to increase the security of CA usage for users > who want them, while also offering high security to users who for any > reason want to avoid CAs. > > If the intent of the section is to discuss the effect of DANE on the > security of the whole Internet, then a system-level look at both the > status quo's and DANE's security is required, not a patchwork > comparison of individual elements of that security. If the intent is > merely to discuss the effect of DANE on the security of an individual > service that uses TLS (such as a single secure web site), then a > system-level look at that individual service is required. Section 8.1 > has not provided either one; it makes unsupported assertions about one > element of CA-based TLS, while making other unsupported assertions > about a different element of DANE-based TLS. > > The 1st graf of 8.1 makes little sense to me. It claims that a DANE > client using an external DNSSEC validator is "as vulnerable as" a TLS > client of today. It states a tautology by saying that any client that > relies on any external source of trust can be fooled by relying on an > untrustworthy source. But then it bootstraps that into misleadingly > saying that DANE is "as vulnerable" as current TLS. This is wrong, > because a TLS client of today is vulnerable to compromise from > hundreds of trusted entities, most or all of which the client has no > contractual relationship with, and most or all of which were never > explicitly configured or examined by the user of the client. A DANE > client using an exernal DNSSEC validator is vulnerable to compromise > from a single trusted entity, that validator, plus another small > number of trusted entities which provide domain name service for the > domains that the client accesses. There are no pre-configured > external DNSSEC validators in TLS client software, as there are with > trust anchors, so any exernal DNSSEC validator would have to be > configured manually by the user of the client, requiring explicit > action to configure it insecurely. Also, the client's user probably > has a contract or other close relationship (such as being in the same > corporation) with an entity that provides it with an external DNSSEC > validator, so the user can more easily monitor its trustworthiness. > For example, the user's ISP might provide external DNSSEC validation, > as they today provide recursive DNS service, and most users have a > contract with their ISP. But the whole graf is mostly irrelevant, > because external DNSSEC validators running on other peoples' machines > are only expected to be used by a small fraction of the DANE clients. > > The second graf makes an unsupported assumption ("If it is less likely > that a user will hear about...") to produce a scare quote ("could be > worse off than a current TLS client"). > > Similarly, the 3rd graf seems to be unsupported by facts. It says > "Current public CAs are assumed to have better defenses than current > DNSSEC validators", but I don't think that there are any current > DNSSEC validators to compare current public CAs to. "Better defenses" > is ipso facto a misleading phrase unless it specifies against what > threat model it is defending. Furthermore, some current public CAs > have been proven to have poor defenses, since they have issued invalid > certificates used in mass man-in-the-middle attacks against the > population of entire countries. Since some current public CAs are > known to be untrustworthy, it's hard to support saying that "current > public CAs" in general are assumed to have good defenses. It then > goes on to say that "this perception" can't be proven one way or the > other. Barrooms, not RFCs, are the place for such poorly supported > statements. > > The first two grafs discuss "external DNSSEC validators", but the > third and final graf slyly shifts the ground to "DNSSEC validators" in > general, without making this change obvious. And, again > validators are only a small part of the DANE ecosystem, but this > section doesn't go into any other part, while claiming to compare > the totality of DANE's security. > > I believe that today's "internal" DNSSEC validators are considered as > trustworthy as today's "internal" certificate-chain constructors and > validators as used today in TLS. These are both cryptographic libraries > that have undergone substantial testing and widespread deployment over > a period of many years. > > I believe that if the RFC is going to make statements about the > relative security DANE and of CA-based TLS, we should clearly state > that many well-qualified security experts and network administrators > have serious concerns about the security of CA-based TLS. I would be > happy to provide citations for some such statements, that the RFC > could reference as informative. We should also state that the only > reason for the continued widespread use of CA-based TLS is that there > is no credible alternative ready for mass market use. (The role of > this committee is to produce such an alternative -- not to undermine > its new alternative.) > > The draft currently states in Section 1.1 that the actual security in > practice of traditional TLS CAs has been demonstrated to vary widely > among different CAs, from completely trustworthy to completely > untrustworthy. We all know that more than a few CAs have had their > trust anchors removed from popular TLS software due to public > breaches. A few other CAs who suffered breaches required specific > software patches in mass market TLS software such as browsers, because > their certificates were too widely used to allow their trust anchors > to be removed due to a single breach that issued a small number of > invalid certificates. We all fervently hope that that CA won't allow > another breach to occur, but such a history does not give us great > confidence. > > I believe it is too early to say anything about the actual security in > practice of TLSA-protected domain names, since there is no operational > history to guide us. We don't even have an RRTYPE for TLSA yet! It > is *designed* to be secure, but so was CA-based TLS designed to be > secure, and yet CA-based TLS has not always been secure. We have > designed DANE to be MORE secure than CA-based TLS, for specified > reasons. Only time will tell. > > The conclusion of section 8.1 "Thus, it is difficult to foresee which > system has a higher risk." is invalid. As Steve Kent pointed out, and > as our document now states, DANE for TLS incorporates the principle of > least privilege, which fixes the largest vulnerability in CA-based > TLS. > > John Gilmore > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From tom@ritter.vg Thu Apr 12 13:43:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98E321F86BB for ; Thu, 12 Apr 2012 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBoIxxDzGoEI for ; Thu, 12 Apr 2012 13:43:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B93221F86B6 for ; Thu, 12 Apr 2012 13:43:08 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3693388obb.31 for ; Thu, 12 Apr 2012 13:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Qlo+brEmR5nHrN0/rFMppPDZRkW/1VR1JLaQIVU/Xpo=; b=dNLEZ8+tBDZizn8zdw/cB0KDIrG0IxSqV6eYdaYdfHHgXBC3Ec2UYLOWwI/AAvVtxf uLsqw1DPJWFG6WZQUVnt6HgS2SyV2VRq/lTxnqTdWUCxfG9LJoZQ47klSTHYZATCF0Sp CpiBREOlZGuQkMde7pyqIXBS1w9NrIWF6bNME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Qlo+brEmR5nHrN0/rFMppPDZRkW/1VR1JLaQIVU/Xpo=; b=kBuOlRSqh3TJkPvlO10GSlBBrrx0DVcV3l9NR/lnSSpFC54YsK/cOR7qeFvj6EJIzD SljMd3J2y1OhyWozOg17qeODNAnwpBXdxe5bwv4eOOruC9FRSndwmh8YxKx9TrtRdcWN 2AYTtRoqWKO6mOdIXa4h+qGbG+ZCCM1JW93nXcmnfN4anEDJ8qTzylRDZn5rAHup1oIT +BLP+V3LOSDta6JTg5ufELzNgSNWAgQG/b6U82HFU+bqxFXT8LyyQx5sPIz2WWahYcPA Ki0eGjtgmHNDhIv23rgUcX/QejvLj5zy/pLJnuymI6LJj5VnxbzJ9bGvmISR7xi+bZQt /SrA== Received: by 10.182.36.3 with SMTP id m3mr5092197obj.8.1334263388561; Thu, 12 Apr 2012 13:43:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.116.41 with HTTP; Thu, 12 Apr 2012 13:42:48 -0700 (PDT) In-Reply-To: <201204121923.q3CJNPcF027743@new.toad.com> References: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> <201204121923.q3CJNPcF027743@new.toad.com> From: Tom Ritter Date: Thu, 12 Apr 2012 16:42:48 -0400 Message-ID: To: John Gilmore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm8VU/R+OSiwO2dxaq9EuENQDIdBqmN6bAvIoZqCurwl+a2EOF4HxO71ciu5WTLkKG+wQ9Y Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org, dane issue tracker Subject: Re: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 20:43:09 -0000 On 12 April 2012 15:23, John Gilmore wrote: > If it's not an IETF standard, I suggest that we ignore it. =A0To the > IETF, a cert is a cert is a cert, and the RFCs on certs are careful > not to specify much about the exact contents of a cert, or how clients > should handle all the fiddly little bits attached to them. =A0DANE should > do the same. There's also Organization-Validated certs which would have to be handled specially too. I think browsers should not provide the O or EV indicators to a self-signed cert that asserts itself as Organization-Validated or EV. I kind of think the standard should have some non-specific, non-requirement security note saying a client should not afford high security indicators (such as an EV indicator) to a self-signed certificate - but I don't think any specific wording trying to cover all the bases is appropriate. I just worry someone implementing the standard might forget about EV certs (as most of us did) which would lead to a bug. A security note would serve as a sufficient reminder. -tom From cloos@jhcloos.com Thu Apr 12 13:50:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD95521F8710 for ; Thu, 12 Apr 2012 13:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TEReA6i8C+a for ; Thu, 12 Apr 2012 13:50:28 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 4010021F8707 for ; Thu, 12 Apr 2012 13:50:28 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 35EF740209; Thu, 12 Apr 2012 20:50:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1334263827; bh=hu+Ge/aO+WrGL5lis655DXAgeyq9o2L6/E8uAY/rGLY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=p/MCkYNqS5b8Brlmq4z7Y/c0RVZNCiJgCDOwqSzYRhj/Td0Z9TVEyVl9gifX+dJ00 i6SutVCkMqmLDSAdvPtscV240IWUZdWWbiPxNaRMNDOvEMb1NNYIkgAjwuICr+BifM DjrdspERpbB3CsSbfq0Fa9+y7ESt5CMyreHVhukQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id EAD4836004B; Thu, 12 Apr 2012 20:49:41 +0000 (UTC) From: James Cloos To: SM In-Reply-To: <6.2.5.6.2.20120412104202.09ab2338@resistor.net> (sm@resistor.net's message of "Thu, 12 Apr 2012 10:48:49 -0700") References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 12 Apr 2012 16:49:41 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 20:50:29 -0000 >>>>> "S" == SM writes: S> It's sometimes easier to add the assigned value on publication of S> a document as a RFC. The request for the TLSA RRTYPE has already S> been accepted. Nonetheless, we need to get the number asap to ensure that the existing software is updated in time. I can take *months* for such updates to percolate into the published by distributions and therefor in active use. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From sm@resistor.net Thu Apr 12 14:05:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DE121F8739 for ; Thu, 12 Apr 2012 14:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkiu-3Xz2-4o for ; Thu, 12 Apr 2012 14:05:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5F21F8738 for ; Thu, 12 Apr 2012 14:05:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3CL5WOH004783; Thu, 12 Apr 2012 14:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334264737; i=@resistor.net; bh=mXVbCfXCG7FhNN/XC4s4uE6J2QiMN6rAFMPScRgizOI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2V4qqMpF1bbkjYmRCGEaylmYddEEjzoJgjjXyPc0WmhCnNJdfGZmmWD4UK2Abnyp5 WjP/IhNTfEtVtnMerXrNJWJO7qM1FwGPn9xopHvXiOY1Inl0wg1abx48l/v/dtV7I4 FuJ9VuRO86z25FTDo+c+c8hmqAl/ST4Dx8G+geUY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334264737; i=@resistor.net; bh=mXVbCfXCG7FhNN/XC4s4uE6J2QiMN6rAFMPScRgizOI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ys6SXWKx6N7WtO6DRohSuTPzr5fQVYivAwGHqt2msbEs+dwEVGUMP07tLdmresfDY opCNeTEamqZD/Wb89yVKx2IZs16KlWC+N/nDhreS+KchubXVWRlTswe9QlAu5WcWl5 6AvLsdIHwhXQ4qBsCvPftBya1vhgZCFEQ16Iruek= Message-Id: <6.2.5.6.2.20120412134139.09b62898@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 14:04:35 -0700 To: John Gilmore From: SM In-Reply-To: <201204121936.q3CJavcF028350@new.toad.com> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <201204121936.q3CJavcF028350@new.toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 21:05:40 -0000 Hi John, At 12:36 12-04-2012, John Gilmore wrote: >Could you give us an example of why that's rarely the case? I for one >am planning to use DANE to secure STARTTLS on my own domain >(toad.com), and I'd like to know why you think that won't work. I am not saying that it won't work for your own domain. I'll use ietf.org as a hypothetical example: ;; QUESTION SECTION: ;ietf.org. IN MX ;; ANSWER SECTION: ietf.org. 1800 IN MX 0 mail.ietf.org. The SMTP server running on that host identifies itself as "ietfa.amsl.com". In my opinion (which is generally wrong), it's common not to find an association which is the end point, in this case mail.ietf.org, or the domain name (ietf.org). Doing a WAG test on SMTP servers advertising STARTTLS as an extension would show that. As I do not have any data to support my argument right now it can easily be dropped. >The draft is for all protocols that layer on top of TLS. (Do we even >have a list of such protocols? Or the IETF-standardized subset of >them? We all know about https and STARTTLS; what else?) If there are >specific deployment issues that would make it not work for some of >those protocols, we should either fork a separate document for those >protocols (as we have done for e.g. IPSEC), or we should address the >deployment issues somewhere in the draft. RFC 6125 covers some of the application protocols that use TLS as a security layer. HTTP(S) is the exception. Most fairly common application-related protocols would use some discovery mechanism. This raises the question of Issue #28. I'll comment in reply to another message about possible deployment issues. One alternative is to fork other documents. You would probably want to do this outside this working group to avoid turf wars, etc. There may be deployment issues specifically related to DANE. The working group could discuss about that in another RFC to keep draft-ietf-dane-protocol "clean". As there will probably be various schools of thought on how this should be done, I prefer to stay out of the discussion. Regards, -sm From cloos@jhcloos.com Thu Apr 12 14:12:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408E021F870E for ; Thu, 12 Apr 2012 14:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8Ay5N0f0JJs for ; Thu, 12 Apr 2012 14:12:17 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5411F21F86A6 for ; Thu, 12 Apr 2012 14:12:10 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 0E68B40209; Thu, 12 Apr 2012 21:11:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1334265130; bh=VnQJw1u1GbBVCdbEohW/CNEFjuHHwre5jUENAenZ8LM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=OlBbqgDVasnDSJOyTnwTjMwtfjvi8V81ZznmU2AVPXtJ12Iut7iuP/niCjJpjhzGR u40U7E3hQiTIGdMElvnn90L/nUdOnVrGBJCuq6/LRJwH+nmr/TD0gvvD5zvKVGzAsB C5AZm8ZQhcrX/KF5rabiNpoKgfUfpLpbcoG5igp8= Received: by carbon.jhcloos.org (Postfix, from userid 500) id E217C36004B; Thu, 12 Apr 2012 21:10:56 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <201204121936.q3CJavcF028350@new.toad.com> (John Gilmore's message of "Thu, 12 Apr 2012 12:36:57 -0700") References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <201204121936.q3CJavcF028350@new.toad.com> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 12 Apr 2012 17:10:56 -0400 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 21:12:18 -0000 >>>>> "JG" == John Gilmore writes: JG> (Do we even have a list of such protocols? Or the IETF-standardized JG> subset of them? We all know about https and STARTTLS; what else?) No, we do not have a complete list. Postgresql is a good example. The other dbms may support tls, too. And we shouldn't ignore http's version of starttls; there may not be much support in "web" endpoints, but there are ipp endpoints which regularly do so and would benefit from TLSA. *Any* tcp, sctp, udp or dccp protocol (at least) can use tls and/or dtls; defining starttls semantics also is straightforward for just about any new or existing protocol. TLSA RRs can help accelerate the transition from unencrypted to d?tls sockets for almost everything. (Which is another reason to dump the anti type-2/3 slant in §8.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From mrex@sap.com Thu Apr 12 14:35:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA1821F877B; Thu, 12 Apr 2012 14:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.078 X-Spam-Level: X-Spam-Status: No, score=-10.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hEMghoxTk49; Thu, 12 Apr 2012 14:35:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C058421F877A; Thu, 12 Apr 2012 14:35:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3CLZdFC015720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 23:35:39 +0200 (MEST) From: Martin Rex Message-Id: <201204122135.q3CLZY5A015636@fs4113.wdf.sap.corp> To: sm@resistor.net (SM) Date: Thu, 12 Apr 2012 23:35:34 +0200 (MEST) In-Reply-To: <6.2.5.6.2.20120411202530.085195c0@resistor.net> from "SM" at Apr 12, 12 00:11:43 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:35:41 -0000 SM wrote: > > In Section 8.1: > > "If it is less likely that a user will hear about its trusted DNSSEC > validators being hacked that it is of a public CA being compromised" > > I suggest using "compromised" instead of "hacked". Similar to what John complains about, comparing trusted DNSSEC validators to public CAs is comparing apples and oranges. The equivalent of a trusted DNSSEC validator in the PKIX world would be an SCVP server/service! The compromise of the DNSSEC zone data for DANE is probably equivalent to the compromise of an organizational CA signed by a public CA with name constraints to that DNS zone. The compromise of an unconstrained public CA in the PKIX world would be equivalent to a compromise of the root DNSSEC zone data in the DANE world. -Martin From sm@resistor.net Thu Apr 12 14:44:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17CF21F8681 for ; Thu, 12 Apr 2012 14:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCcIrNXW2WD3 for ; Thu, 12 Apr 2012 14:44:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5921F865F for ; Thu, 12 Apr 2012 14:44:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3CLi0hh026458; Thu, 12 Apr 2012 14:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334267045; i=@resistor.net; bh=C4qVv+mrQY+izn5kMseTU6FuauSSCDmLco4OroB4FnE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yuhsiKF5Ini3nkFzaw8QlyJ6xdv7UJq+SjRDolssuq/5oL3cKEObLPBqmBpmXQOFF /6NPdzBVfGcHIuUtloZ1Igtn/5rtWcvcEVj4Xb8NjZ2DjvgYZc/mGRbwTGkD/B7Spa zlziqEO584r0xxRPqE3p8EHQ23yyA49Mvjy+pCJU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334267045; i=@resistor.net; bh=C4qVv+mrQY+izn5kMseTU6FuauSSCDmLco4OroB4FnE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OJSivssE+QNnXnXCPsAhh4iES+kdB0Ce0FZmDr8Z0e7pf4cDSOkCsrFlHE/DRmSs0 yHKYO5XamOTvTqLni3G8DxlHc3TPyPLUIRlGfxTRim1z6sxZ6gfOODINiQ1fHlw7WD /UP+YPc1VVxOGzoYPFdCvGkXnDIVs4cz16/WeeHU= Message-Id: <6.2.5.6.2.20120412141224.09b64f08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 14:18:17 -0700 To: James Cloos From: SM In-Reply-To: References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 21:44:08 -0000 Hi James, At 13:49 12-04-2012, James Cloos wrote: >Nonetheless, we need to get the number asap to ensure that the >existing software is updated in time. > >I can take *months* for such updates to percolate into the published by >distributions and therefor in active use. It's unlikely that it will take months to assign the number. You could talk to the WG chairs and see whether they can help out if there is such an urgency. Regards, -sm From ajs@anvilwalrusden.com Thu Apr 12 14:58:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4997021F8744 for ; Thu, 12 Apr 2012 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqLeWvB9S8ql for ; Thu, 12 Apr 2012 14:58:57 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B6B6A21F8731 for ; Thu, 12 Apr 2012 14:58:57 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0AE511ECB41C for ; Thu, 12 Apr 2012 21:58:56 +0000 (UTC) Date: Thu, 12 Apr 2012 17:58:55 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120412215855.GQ40367@mail.yitter.info> References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> 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] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 21:58:58 -0000 On Thu, Apr 12, 2012 at 04:49:41PM -0400, James Cloos wrote: > Nonetheless, we need to get the number asap to ensure that the > existing software is updated in time. > > I can take *months* for such updates to percolate into the published by > distributions and therefor in active use. The expert already reported back. We're waiting for IANA. A -- Andrew Sullivan ajs@anvilwalrusden.com From fneves@registro.br Thu Apr 12 14:59:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A576C21F8731 for ; Thu, 12 Apr 2012 14:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyCsXGWfnYVx for ; Thu, 12 Apr 2012 14:59:22 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 19EE221F8723 for ; Thu, 12 Apr 2012 14:59:22 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 6D5ADE04FC; Thu, 12 Apr 2012 18:59:21 -0300 (BRT) Date: Thu, 12 Apr 2012 18:59:21 -0300 From: Frederico A C Neves To: John Gilmore Message-ID: <20120412215921.GP74554@registro.br> References: <201204121730.q3CHUZcF021835@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204121730.q3CHUZcF021835@new.toad.com> Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 21:59:22 -0000 John, On Thu, Apr 12, 2012 at 10:30:35AM -0700, John Gilmore wrote: > Typo: s/certifcate/certificate/ > > Section 7.1: s/will be submitted/has been submitted/ . I'm surprised > that we don't have an assigned value for the TLSA rrtype yet. Regarding the 6195 allocation process this is already done. http://www.ietf.org/mail-archive/web/dnsext/current/msg12420.html In our recommendation to IANA, based on a criteria the current experts are following, I've suggested 52 as the value for TLSA, but they have not yet returned with the actual allocation. Take this with handful of sault as they could assign a different value if they like. Fred From cloos@jhcloos.com Thu Apr 12 15:16:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C31121F87A2 for ; Thu, 12 Apr 2012 15:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUMXH+wR+5Kz for ; Thu, 12 Apr 2012 15:16:54 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6F21F879F for ; Thu, 12 Apr 2012 15:16:53 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id AF6674024F; Thu, 12 Apr 2012 22:16:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1334269011; bh=fha/3ckmiYVueefVPvsAgmhSIKrkJS7r0mXIOYBxC4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=WLcrZdBKjnYtf61vDyP+BflNMM05ka0g29gmYupYGdYzqhRif9iPoko4TpsvWj1ap tuTH7OV2WrdUHE2pH/GVB4vA1LYY6SudWIdUsgO1IkVw4KtWX24N9EggCZiqhzUOCH rgXgxXDVy9KFp+/XitZKEnF/SMfvBdZ+0MVZGp7w= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 0074B36004B; Thu, 12 Apr 2012 22:16:08 +0000 (UTC) From: James Cloos To: SM In-Reply-To: <6.2.5.6.2.20120412141224.09b64f08@resistor.net> (sm@resistor.net's message of "Thu, 12 Apr 2012 14:18:17 -0700") References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> <6.2.5.6.2.20120412141224.09b64f08@resistor.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 12 Apr 2012 18:16:08 -0400 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 22:16:54 -0000 >>>>> "S" == SM writes: >> It can take *months* for such updates to percolate into the published by >> distributions and therefor in active use. S> It's unlikely that it will take months to assign the number. You S> could talk to the WG chairs and see whether they can help out if there S> is such an urgency. I suppose I was inadvertently ambiguous. The delay I wrote about is from when a change is commited to a software repository until it is included in a published release and then included in a distribution. Authoritative dns server releases are infrequent; if dane misses this springs release cycle there is no expectation that the next releases will be out before late fall or even next year. And there is no guarantee that any of the distributions will accept a patch for whichever version(s) they ship to fix the tlsa rr value. Especially for their "stable" series. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From sm@resistor.net Thu Apr 12 15:43:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BF521F866D; Thu, 12 Apr 2012 15:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pACaZXgpRvxM; Thu, 12 Apr 2012 15:43:54 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DE821F865E; Thu, 12 Apr 2012 15:43:54 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3CMhlef002452; Thu, 12 Apr 2012 15:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334270633; i=@resistor.net; bh=8SXbJccz4oyvlGQwx1M+mHBt6lNxo6PDIQeSsrf/Oc0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZvKXG9i/wd5N1EYZyt/xeN/MO1jx0kPx6QGZlFcXHCdmKjuwSd8bPOUkbLniE1jB7 W6TI0netFDSFOp/fDXIRuNphF9ZPbZEMkYkTnSL8IFCCD3dU3XPdXs6TVt8PvEWaO4 1Cs2Ue6Zy6yoQYPUz37Hmg+Fz1o4rm2gZI/IIUbU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334270633; i=@resistor.net; bh=8SXbJccz4oyvlGQwx1M+mHBt6lNxo6PDIQeSsrf/Oc0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tE1nYbLaJO8nW78B/lgj76phqLqdBQkWdprmkM9e7I4geYJIPlLCs2ahH+hflXqEm kgzYu4BnLUFNsHhhBVf0RSm+NeojDOHQtQ9KxGdFhfN7Brysmgp90TtMfJOM6uhgYo KqyLwN0mOhX1c7HrSoXciSYe61/zp3KbWeVlDs9s= Message-Id: <6.2.5.6.2.20120412141846.0a880cf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Apr 2012 15:30:19 -0700 To: Ondrej =?iso-8859-1?Q?Sur=FD?= From: SM In-Reply-To: <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 22:43:55 -0000 At 03:48 12-04-2012, Ond ej Sur=FD wrote: >RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make references >to obsoleted documents. As a side note, we don't say "to both TLS 1.2",= but >just TLS. Not really. On an unrelated note,=20 draft-ietf-mile-rfc6046-bis-09 should reference=20 RFC 4346 normatively instead of the informative=20 reference. The was a discussion about a protocol=20 where the argument was MUST implement TLS 1.1 and SHOULD implement TLS 1.1. >SHA-2 was first published 11 years ago and I don't really think that >applications which will decide to implement DANE will not have support >for SHA-2 family. The date of publication of a specification=20 doesn't materially affect what's available out there. >The quoted sentence just says: Use closest available algorithm to help >clients (e.g. please don't use SHA-3 if the certificate signature is= SHA-256). I'm ok with SHA-2 btw. >Here the rules from RFC3207 can be applied: > > The decision of whether or not to believe the authenticity of the > other party in a TLS negotiation is a local matter. However, some > general rules for the decisions are: > > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. > >Similar logic applies to DANE, but it's not the DANE which decides the >name, but TLS capable client, which already know which name to expect. I have read the rules from RFC 3207. You could=20 use the above the declare the issue as out of=20 scope. However, if you take that path, it's=20 better to drop the example as well. >It's just a note, that we expect that future standards would be able >to assign new values (f.e. new hash algorithms when SHA-3 is out). This is IANA paperwork. You don't really have to=20 fix it. Someone reading that text literally=20 might presume that you can request a "specific"=20 value. It seems to me that the objective is not=20 about having to deal with applications for lucky numbers. This draft faces problems which are similar to=20 what RFC 6125 tried to tackle. RFC 6125 does not=20 fix the Application protocols mess. There was a=20 mention of deployment on the DANE mailing=20 list. DANE is conditional on DNSSEC=20 deployment. It is conditional on applications=20 using it. Although it's not up to the working=20 group to tackle all that, you'll end up with half=20 a solution as long as you don't tackle issues relating to RFC 6125. Section 1 of the draft is well-written. There=20 were some comments by other participants about Section 8. For example: "Current public CAs are assumed to have better defenses than current DNSSEC validators, but that perception cannot be proven one way or another. Similarly, if DNSSEC validation becomes more common after the release of this document, it cannot be predicted whether or not that will increase the level of security of DNSSEC validators more or less than the security of public CAs. Thus, it is difficult to foresee which system has a higher risk." I would not make the assumption mentions in the=20 first sentence of that paragraph. I don't mind=20 if the working group decides that it is appropriate to make that assumption. Parts of Section 8.2 about DNS caching could be=20 moved outside the Security Consideration=20 section. It is more useful as guidance for=20 application implementations of the protocol. Regards, -sm=20 From trac+dane@trac.tools.ietf.org Thu Apr 12 17:20:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55E321F872B for ; Thu, 12 Apr 2012 17:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaCAgwVvlxPh for ; Thu, 12 Apr 2012 17:20:46 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 558FD21F872A for ; Thu, 12 Apr 2012 17:20:45 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SIUFi-0008PX-TB; Thu, 12 Apr 2012 20:20:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org X-Trac-Project: dane Date: Fri, 13 Apr 2012 00:20:38 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/40 Message-ID: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120413002045.558FD21F872A@ietfa.amsl.com> Resent-Date: Thu, 12 Apr 2012 17:20:45 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: [dane] #40: Which TLS versions? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 00:20:46 -0000 #40: Which TLS versions? The draft currently only references TLS 1.2. Should we also add references to 1.1? To 1.0? -- ----------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: - | Keywords: ----------------------------+---------------------------------------- Ticket URL: dane From marka@isc.org Thu Apr 12 17:47:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8621F853D for ; Thu, 12 Apr 2012 17:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCKFUMC9B8FN for ; Thu, 12 Apr 2012 17:47:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 52A4021F853B for ; Thu, 12 Apr 2012 17:47:34 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2FC41C9422; Fri, 13 Apr 2012 00:47:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e400:548e:fd23:2876]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C8D63216C31; Fri, 13 Apr 2012 00:47:16 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8C3EA1FA8165; Fri, 13 Apr 2012 10:47:11 +1000 (EST) To: James Cloos From: Mark Andrews References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> <6.2.5.6.2.20120412141224.09b64f08@resistor.net> In-reply-to: Your message of "Thu, 12 Apr 2012 18:16:08 -0400." Date: Fri, 13 Apr 2012 10:47:10 +1000 Message-Id: <20120413004711.8C3EA1FA8165@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 00:47:37 -0000 In message , James Cloos writes: > >>>>> "S" == SM writes: > > >> It can take *months* for such updates to percolate into the published by > >> distributions and therefor in active use. > > S> It's unlikely that it will take months to assign the number. You > S> could talk to the WG chairs and see whether they can help out if there > S> is such an urgency. > > I suppose I was inadvertently ambiguous. The delay I wrote about is > from when a change is commited to a software repository until it is > included in a published release and then included in a distribution. > > Authoritative dns server releases are infrequent; if dane misses this > springs release cycle there is no expectation that the next releases > will be out before late fall or even next year. And there is no > guarantee that any of the distributions will accept a patch for > whichever version(s) they ship to fix the tlsa rr value. Especially for > their "stable" series. You can use TLSA records the moment the number is publish in *existing* authoritative servers provided they support RFC 3597 (Published September 2003). I can do the conversion between TLSA presentation format and RFC 3597 format in my head. The hardest part is counting the number of octets in the record. It's a trival awk program to covert the rdata if the record is all on one line. { len=0; for (i=4; i <= NF; i++) { len += length($i); } len /= 2; len += 3; printf "\\# %d %02x%02x%02x", len, $1, $2, $3; for (i=4; i <= NF; i++) { printf "%s", $i; } printf "\n"; } It's a little more complicated if you want to support multi-line records. Adjust if you want to handle owner, ttl, class and type fields. Mark > -JimC > -- > James Cloos OpenPGP: 1024D/ED7DAEA6 > > > _______________________________________________ > 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 marka@isc.org Thu Apr 12 17:58:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300B921F84FB for ; Thu, 12 Apr 2012 17:58:25 -0700 (PDT) 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=[AWL=-0.596, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9otsI1oHeqR for ; Thu, 12 Apr 2012 17:58:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id AE6BB21F84CD for ; Thu, 12 Apr 2012 17:58:24 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id E05735F98B1; Fri, 13 Apr 2012 00:58:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:e400:548e:fd23:2876]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 21128216C31; Fri, 13 Apr 2012 00:58:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A93D41FA834E; Fri, 13 Apr 2012 10:58:04 +1000 (EST) From: Mark Andrews References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> <6.2.5.6.2.20120412141224.09b64f08@resistor.net> <20120413004711.8C3EA1FA8165@drugs.dv.isc.org> In-reply-to: Your message of "Fri, 13 Apr 2012 10:47:10 +1000." <20120413004711.8C3EA1FA8165@drugs.dv.isc.org> Date: Fri, 13 Apr 2012 10:58:04 +1000 Message-Id: <20120413005804.A93D41FA834E@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 00:58:25 -0000 We should recommend that tools that convert certificates to TLSA records "SHOULD" support emitting the record in RFC 3597 format in addition to TLSA presentation format. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mrex@sap.com Thu Apr 12 18:00:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443F821F8539 for ; Thu, 12 Apr 2012 18:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfsanl6F573P for ; Thu, 12 Apr 2012 18:00:55 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1A68721F84FB for ; Thu, 12 Apr 2012 18:00:54 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3D10rbp001500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 03:00:54 +0200 (MEST) From: Martin Rex Message-Id: <201204130100.q3D10rWM027163@fs4113.wdf.sap.corp> To: tom@ritter.vg (Tom Ritter) Date: Fri, 13 Apr 2012 03:00:52 +0200 (MEST) In-Reply-To: from "Tom Ritter" at Apr 12, 12 04:42:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: draft-ietf-dane-protocol@tools.ietf.org, trac+dane@trac.tools.ietf.org, dane@ietf.org Subject: Re: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:00:56 -0000 Tom Ritter wrote: > > On 12 April 2012 15:23, John Gilmore wrote: > > If it's not an IETF standard, I suggest that we ignore it.  To the > > IETF, a cert is a cert is a cert, and the RFCs on certs are careful > > not to specify much about the exact contents of a cert, or how clients > > should handle all the fiddly little bits attached to them.  DANE should > > do the same. > > There's also Organization-Validated certs which would have to be > handled specially too. I think browsers should not provide the O or EV > indicators to a self-signed cert that asserts itself as > Organization-Validated or EV. > > I kind of think the standard should have some non-specific, > non-requirement security note saying a client should not afford high > security indicators (such as an EV indicator) to a self-signed > certificate - but I don't think any specific wording trying to cover > all the bases is appropriate. I just worry someone implementing the > standard might forget about EV certs (as most of us did) which would > lead to a bug. A security note would serve as a sufficient reminder. I believe you're confusing things. The three things (AFAIK) defined by the CABForum Domain Validation (DV), Organization Validation (OV) and Extended Validation (EV) for certificates are only relevant to the color of some part of the browser UI chrome, but they're entirely irrelevant to server endpoint identification performed according to rfc2818 or rfc6125. The only thing that rfc2818 and rfc6125 look at is the DNSName, and that is present in all three kinds of certs. Additionally vetted attributes could provide additional clue to a human user who actually looks at them and compares them to his intent, but they're invisble to TLS clients implementing rfc2818 or rfc6125. An approach of "DV+DANE" as minimum and OV or EV fine without DANE would primarily hike the prices for TLS-enabling your server, an outcome that I do not consider desirable. -Martin From tom@ritter.vg Thu Apr 12 18:24:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D092B21F8638 for ; Thu, 12 Apr 2012 18:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2FLaXkKYsB7 for ; Thu, 12 Apr 2012 18:24:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32CB021F8541 for ; Thu, 12 Apr 2012 18:24:03 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4010762obb.31 for ; Thu, 12 Apr 2012 18:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=prx9CydkCHK2khLsK2/E+KQk5xXAw2PricIyQ6Ne2hk=; b=jpkumC7N28boTeErOHRrqRmPk2sNlj5Tye2AJUqLR4vVUDmHonYC00BDEgcb4uHYjL BluPBpjUOxeWLh/xUtB17URqXgWA6M6oKa1SwoIm3j0978C2bHdrE9cqvYzl3UArmvGq +qZD80Arq/pmxyaiVwSPDAaMiekQqgJksa0zE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=prx9CydkCHK2khLsK2/E+KQk5xXAw2PricIyQ6Ne2hk=; b=Ng1aNYMdRZSgzCj7QAoxHzFqadzrfVlfWzHx4z8egzBqi9dsMcCHe0Y1MccBQbFvFN sulJrdAqp8MJTWIKScm5Rz5jhjLhT+ajn4m+QZjoNSUbfpVvdXUfFkLdCukX8OyJYd6m yo3wjhapVNeD/9hz7yMro6pph0vTLE1F+VJKA5tSCsHYdTNgz0c+WH7RPfvbtInwffOf tOmmOAfun8fuV21Lu2riiOaZEKKwiw8JxG/VaxkyaRjeBQ5w1CtqJ18kSlYA6NyjLsac oxGtgxDewRyoiiKXlBtuwjFeZDw46B5Eh4V/mQVLx7CfivnGQnho68lr84v4n+gR34d6 oh0w== Received: by 10.60.8.129 with SMTP id r1mr419181oea.28.1334280242573; Thu, 12 Apr 2012 18:24:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.116.41 with HTTP; Thu, 12 Apr 2012 18:23:42 -0700 (PDT) In-Reply-To: <201204130100.q3D10rWM027163@fs4113.wdf.sap.corp> References: <201204130100.q3D10rWM027163@fs4113.wdf.sap.corp> From: Tom Ritter Date: Thu, 12 Apr 2012 21:23:42 -0400 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQny6i7myml23PqKKCBFImx7e0a0trwrOaDe5Y+rPkt1mXeghXaoPwgndB915cVzMvSbNaLF Cc: draft-ietf-dane-protocol@tools.ietf.org, trac+dane@trac.tools.ietf.org, dane@ietf.org Subject: Re: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 01:24:04 -0000 On 12 April 2012 21:00, Martin Rex wrote: > The three things (AFAIK) defined by the CABForum > Domain Validation (DV), Organization Validation (OV) and > Extended Validation (EV) for certificates are only relevant > to the color of some part of the browser UI chrome, but > they're entirely irrelevant to server endpoint identification > performed according to rfc2818 or rfc6125. Correct. > An approach of "DV+DANE" as minimum and OV or EV fine without DANE > would primarily hike the prices for TLS-enabling your server, an outcome > that I do not consider desirable. The main reason I support DANE is so DV+DANE is not the minimum, and we can eliminate the horrible chrome for self-signed certificate - so we're on the same page there. Here's what I'm trying to avoid: - if ( certificateChainsToValidTrustAnchor() ) { + if ( certificateChainsToValidTrustAnchor() || certificateIsValidThroughDANE() ) { // 200 lines of random code if ( certificateIsEV() ) { showGreenBar(); } else if ( certificateIsOV() ) { showOrganizationIndicator(); } } This patch makes a self-signed cert with the appropriate EV bits set get the bright green browser UI. I think a security note would remind implementers to double check this case, just like we have security notes for implementers in the TLS spec. -tom From paul@nohats.ca Thu Apr 12 18:51:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49F121F873C for ; Thu, 12 Apr 2012 18:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBBKNfaPLNU5 for ; Thu, 12 Apr 2012 18:51:17 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 06EF221F8738 for ; Thu, 12 Apr 2012 18:51:16 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id CC8EB80335; Thu, 12 Apr 2012 21:51:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id BDFF980331; Thu, 12 Apr 2012 21:51:15 -0400 (EDT) Date: Thu, 12 Apr 2012 21:51:15 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20120413005804.A93D41FA834E@drugs.dv.isc.org> Message-ID: References: <201204121730.q3CHUZcF021835@new.toad.com> <6.2.5.6.2.20120412104202.09ab2338@resistor.net> <6.2.5.6.2.20120412141224.09b64f08@resistor.net> <20120413004711.8C3EA1FA8165@drugs.dv.isc.org> <20120413005804.A93D41FA834E@drugs.dv.isc.org> User-Agent: Alpine 2.02 (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] draft-ietf-dane-protocol-19.txt typos and minor fixes X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 01:51:18 -0000 On Fri, 13 Apr 2012, Mark Andrews wrote: > We should recommend that tools that convert certificates to TLSA > records "SHOULD" support emitting the record in RFC 3597 format in > addition to TLSA presentation format. That's what "dane" and "swede" do. For dane I used --draft and --rfc to make the difference. Paul From mrex@sap.com Thu Apr 12 20:59:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B27321F8744; Thu, 12 Apr 2012 20:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.055 X-Spam-Level: X-Spam-Status: No, score=-10.055 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lvrkMOTLEpR; Thu, 12 Apr 2012 20:59:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E46B21F86F4; Thu, 12 Apr 2012 20:59:50 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3D3xm1E010086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 05:59:48 +0200 (MEST) From: Martin Rex Message-Id: <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> To: ned+ietf@mauve.mrochek.com Date: Fri, 13 Apr 2012 05:59:47 +0200 (MEST) In-Reply-To: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> from "ned+ietf@mauve.mrochek.com" at Apr 12, 12 02:03:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:59:51 -0000 ned+ietf@mauve.mrochek.com wrote: > >>> >>> In Section 1.2: >>> >>> "This document applies to both TLS [RFC5246]" >>> >>> Does this mean that DANE is not applicable for TLS 1.1? >> >> RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make references >> to obsoleted documents. As a side note, we don't say "to both TLS 1.2", but >> just TLS. > > I have no involvement with DANE or the rest of this debate, but I wanted to > point out that this simply isn't true. IDNits warnings to the contrary > notwithstanding, references to obsoleted specifications are not only allowed, > but in some cases absolutely required. Since the question keeps coming up again and again and again... I firmly believe all three Obsoletion markers in the meta-data of rfc5246 to be factually incorrect, so I filed an errata for this. https://www.ietf.org/mail-archive/web/tls/current/msg08595.html -Martin From ondrej.sury@nic.cz Fri Apr 13 00:20:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AD821F8661 for ; Fri, 13 Apr 2012 00:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdgyBiQAuXlV for ; Fri, 13 Apr 2012 00:20:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9B09921F865E for ; Fri, 13 Apr 2012 00:20:02 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:539:b40e:dbdc:8d26] (unknown [IPv6:2001:1488:ac14:1400:539:b40e:dbdc:8d26]) by mail.nic.cz (Postfix) with ESMTPSA id 8186513FCDE; Fri, 13 Apr 2012 09:20:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334301601; bh=1ZRuzk7O3SwzHkfdHdkWoX7iPb9JAnBLpFkqyhkIV2U=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=x3GLBp+XMiFd9yRTAFUDO9D11MDowxz/EavNHtOlD7lhO9U1TClIiorFbhnAG8BRA M1/4FJ1C0LMMOt+Bvw0S4lYPqg87/YjlHhQy+GNzObIx2rzjCDzFlmraMQGnngdDZF k1idGfB76iwoKeHW5WFrZK3psjb/xICPvNh3SN0U= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6.2.5.6.2.20120412134139.09b62898@resistor.net> Date: Fri, 13 Apr 2012 09:20:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <201204121936.q3CJavcF028350@new.toad.com> <6.2.5.6.2.20120412134139.09b62898@resistor.net> To: SM X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 07:20:05 -0000 On 12. 4. 2012, at 23:04, SM wrote: > Hi John, > At 12:36 12-04-2012, John Gilmore wrote: >> Could you give us an example of why that's rarely the case? I for = one >> am planning to use DANE to secure STARTTLS on my own domain >> (toad.com), and I'd like to know why you think that won't work. >=20 > I am not saying that it won't work for your own domain. >=20 > I'll use ietf.org as a hypothetical example: >=20 > ;; QUESTION SECTION: > ;ietf.org. IN MX >=20 > ;; ANSWER SECTION: > ietf.org. 1800 IN MX 0 mail.ietf.org. >=20 > The SMTP server running on that host identifies itself as = "ietfa.amsl.com". In my opinion (which is generally wrong), it's common = not to find an association which is the end point, in this case = mail.ietf.org, or the domain name (ietf.org). Doing a WAG test on SMTP = servers advertising STARTTLS as an extension would show that. As I do = not have any data to support my argument right now it can easily be = dropped. Could you please point us to the document saying that we should care = about HELO/EHLO identification in SMTP? The login here is simple: - The client connects to mail.ietf.org, hence it expects certificate = with CN (or subjAltName) containing mail.ietf.org (or at least *.ietf.org). And I don't think = this is different from normal TLS operation. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Fri Apr 13 01:21:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9620621F8491 for ; Fri, 13 Apr 2012 01:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gkx1kJk6UTGG for ; Fri, 13 Apr 2012 01:21:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C3AF621F847D for ; Fri, 13 Apr 2012 01:20:51 -0700 (PDT) Received: from [IPv6:2001:718:1e03:aed1:504f:57e5:63da:7589] (unknown [IPv6:2001:718:1e03:aed1:504f:57e5:63da:7589]) by mail.nic.cz (Postfix) with ESMTPSA id B6ED413FCDE; Fri, 13 Apr 2012 10:20:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334305250; bh=fOskWxOg+aT45dNqa0NWA1ZOeDkUDb7HZ4guAAPai1Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aEDvA60yzTbwT6RHF2ICauvmIJazduSq8dXOlH1ZMGZfSR1j0eZK+r82PqA5L4ZXm TlmE8vlCirIrsrbWXSPXe2wy6Jrr8g0ndaY6n3RkhMGROWCG7fb1Qt6Pl9uCMvSaGX xW9/c/0NZbR6muHVVod3dnU6Tnpto0lRpKLNulgQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> Date: Fri, 13 Apr 2012 10:20:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42410993-08AD-4538-922E-6215F64C5B68@nic.cz> References: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> To: dane issue tracker X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: draft-ietf-dane-protocol@tools.ietf.org, paul.hoffman@vpnc.org, dane@ietf.org Subject: Re: [dane] #40: Which TLS versions? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 08:21:12 -0000 As I understand the discussion in the list, we can probably add = reference TLS 1.0 and TLS 1.1 since there is not a normative reference which we = can use to reference just a 'TLS' (which would include all valid TLS = versions). O. On 13. 4. 2012, at 2:20, dane issue tracker wrote: > #40: Which TLS versions? >=20 > The draft currently only references TLS 1.2. Should we also add = references > to 1.1? To 1.0? >=20 > --=20 > ----------------------------+---------------------------------------- > Reporter: paul.hoffman@=E2=80=A6 | Owner: = draft-ietf-dane-protocol@=E2=80=A6 > Type: defect | Status: new > Priority: minor | Milestone: > Component: protocol | Version: > Severity: - | Keywords: > ----------------------------+---------------------------------------- >=20 > Ticket URL: > dane >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From sm@resistor.net Fri Apr 13 01:54:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE91F21F85D7 for ; Fri, 13 Apr 2012 01:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCLngQfWUwZD for ; Fri, 13 Apr 2012 01:54:09 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 568FF21F8616 for ; Fri, 13 Apr 2012 01:54:09 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3D8rtoM015796; Fri, 13 Apr 2012 01:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334307248; i=@resistor.net; bh=7BLbuHvJkaPBiDSjCjk9zzTNyGAH3gjedR84Si2ALZ8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cJnjA41plwRIyXxNSgGFJt4HZhxNWhmgizmedfR0tMm/dQV3Zj2sGjbD1tAz/TjoA rUj4hMCaw+TuUXsa31KLAAQEXGotit8b5bm4bgExg5C6rTLogAJoSOcyHaRHtVYG1V N7f5dLSMchj5byeysGUmqynmq3ITsKWjc1At3WBw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1334307248; i=@resistor.net; bh=7BLbuHvJkaPBiDSjCjk9zzTNyGAH3gjedR84Si2ALZ8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K/5jYRJNwjSdMODuSInfr/QOp8Z3c//Eogh0gOWVWnknEyGOzDAfblpuWByxG2pAe ner7aAGDkY/0W9hLchF7/b5ioxXnrNG2bgGFDCmrk/G+fJCndO5tanFmEQcwwThRyQ 2FaZiZYI4NoZ9LJ0YseX8f4cjAOcSvD6SzGgChLU= Message-Id: <6.2.5.6.2.20120413014516.0a880cf8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Apr 2012 01:53:29 -0700 To: Ondrej =?iso-8859-1?Q?Sur=FD?= From: SM In-Reply-To: <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <201204121936.q3CJavcF028350@new.toad.com> <6.2.5.6.2.20120412134139.09b62898@resistor.net> <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 08:54:13 -0000 At 00:20 13-04-2012, Ondrej Sur=FD wrote: >Could you please point us to the document saying=20 >that we should care about HELO/EHLO >identification in SMTP? There is nothing in the draft saying that the=20 working group should care about EHLO. The=20 comment was sent to John Gilmore as an=20 explanation and copied to the mailing list as a FYI. Thanks for the explanation. Regards, -sm=20 From ondrej.sury@nic.cz Fri Apr 13 02:04:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE9F21F867B for ; Fri, 13 Apr 2012 02:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+NR1ppdMB-w for ; Fri, 13 Apr 2012 02:04:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2108B21F867A for ; Fri, 13 Apr 2012 02:04:10 -0700 (PDT) Received: from [IPv6:2001:718:1e03:aed1:504f:57e5:63da:7589] (unknown [IPv6:2001:718:1e03:aed1:504f:57e5:63da:7589]) by mail.nic.cz (Postfix) with ESMTPSA id 7024614045A; Fri, 13 Apr 2012 11:04:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334307849; bh=55O3kPEW+k6/RsufpsILmlmmPYefv7ebZZyXFlJLkI0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Sc2TsL90Gfm+YSFLF4OQjFradudLrTVeBuDO67HfRPMGMlQIb/31AGEyC+abTaWiG WsNqklwDzWJVIQxHqIbw4ZdXsNl9nyZBePavWea4OPGPzo6jKbI9gqPsnoG1A6QI47 imeivpaRCVM+4/abx04cjdGQucNSZ/851P5VM0xw= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <6.2.5.6.2.20120413014516.0a880cf8@resistor.net> Date: Fri, 13 Apr 2012 11:04:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E08F6EE-BBC3-463B-BAE2-D12E49C5C4D5@nic.cz> References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <201204121936.q3CJavcF028350@new.toad.com> <6.2.5.6.2.20120412134139.09b62898@resistor.net> <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz> <6.2.5.6.2.20120413014516.0a880cf8@resistor.net> To: SM X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 09:04:10 -0000 On 13. 4. 2012, at 10:53, SM wrote: > At 00:20 13-04-2012, Ondrej Sur=C3=BD wrote: >> Could you please point us to the document saying that we should care = about HELO/EHLO >> identification in SMTP? >=20 > There is nothing in the draft saying that the working group should = care about EHLO. The comment was sent to John Gilmore as an explanation = and copied to the mailing list as a FYI. Ok. In that case, I might have misunderstood you. On the other hand, you are probably right that there are cases where the = DNS name the client connects to doesn't match the name in the = certificate, f.e. all Google Apps mailservers: ;; ANSWER SECTION: sury.org. 901 IN MX 30 = aspmx5.googlemail.com. sury.org. 901 IN MX 10 aspmx.l.google.com. sury.org. 901 IN MX 20 = alt1.aspmx.l.google.com. sury.org. 901 IN MX 20 = alt2.aspmx.l.google.com. sury.org. 901 IN MX 30 = aspmx2.googlemail.com. sury.org. 901 IN MX 30 = aspmx3.googlemail.com. sury.org. 901 IN MX 30 = aspmx4.googlemail.com. return certificate with CN=3Dmx.google.com: subject=3D/C=3DUS/ST=3DCalifornia/L=3DMountain View/O=3DGoogle = Inc/CN=3Dmx.google.com This will have to be fixed before they can deploy DANE. Anyway it should be quite easy to add altSubjectName into this = certificate. Ondrej -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From marka@isc.org Fri Apr 13 05:20:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1B21F873D for ; Fri, 13 Apr 2012 05:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgjdafzws1St for ; Fri, 13 Apr 2012 05:20:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 15B0321F86E2 for ; Fri, 13 Apr 2012 05:20:03 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1FB63C9423; Fri, 13 Apr 2012 12:19:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:8847:303f:ae80:6a7d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B7A32216C31; Fri, 13 Apr 2012 12:19:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 03F911FB09D0; Fri, 13 Apr 2012 22:19:42 +1000 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <201204121936.q3CJavcF028350@new.toad.com> <6.2.5.6.2.20120412134139.09b62898@resistor.net> <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz> In-reply-to: Your message of "Fri, 13 Apr 2012 09:20:01 +0200." <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz> Date: Fri, 13 Apr 2012 22:19:42 +1000 Message-Id: <20120413121943.03F911FB09D0@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 12:20:03 -0000 In message <9560CD4C-62E6-4DA6-85FC-E6D84FD7DF5C@nic.cz>, =?utf-8?Q?Ond=C5=99ej_S ur=C3=BD?= writes: > > On 12. 4. 2012, at 23:04, SM wrote: > > > Hi John, > > At 12:36 12-04-2012, John Gilmore wrote: > >> Could you give us an example of why that's rarely the case? I for one > >> am planning to use DANE to secure STARTTLS on my own domain > >> (toad.com), and I'd like to know why you think that won't work. > > > > I am not saying that it won't work for your own domain. > > > > I'll use ietf.org as a hypothetical example: > > > > ;; QUESTION SECTION: > > ;ietf.org. IN MX > > > > ;; ANSWER SECTION: > > ietf.org. 1800 IN MX 0 mail.ietf.org. > > > > The SMTP server running on that host identifies itself as > "ietfa.amsl.com". In my opinion (which is generally wrong), it's common > not to find an association which is the end point, in this case > mail.ietf.org, or the domain name (ietf.org). Doing a WAG test on SMTP > servers advertising STARTTLS as an extension would show that. As I do > not have any data to support my argument right now it can easily be > dropped. > > > Could you please point us to the document saying that we should care > about HELO/EHLO identification in SMTP? The argument being made is that the HELO/EHLO identification will match the certificate being presented and that there is a long history of mismatches being accepted at the HELO/EHLO level and if we try to STARTTLS for general MTA to MTA transactions there will be lots of breakage. The argument also being made is that if we, the ietf, can't configure our servers to present the correct name on HELO/EHLO how can we expect the rest of the world to get it right. > The login here is simple: > > - The client connects to mail.ietf.org, hence it expects certificate with > CN (or subjAltName) containing mail.ietf.org (or at least *.ietf.org). > And I don't think this is different from normal TLS operation. I agree this is how it should be. > O. > -- > OndÅ™ej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > 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 ned.freed@mrochek.com Thu Apr 12 14:08:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F7D21F8723 for ; Thu, 12 Apr 2012 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhtzpNfDfYYp for ; Thu, 12 Apr 2012 14:08:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3421F8744 for ; Thu, 12 Apr 2012 14:08:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE8FJHFLZK00M2HF@mauve.mrochek.com> for dane@ietf.org; Thu, 12 Apr 2012 14:08:50 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Thu, 12 Apr 2012 14:08:48 -0700 (PDT) Message-id: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> Date: Thu, 12 Apr 2012 14:03:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 12 Apr 2012 12:48:51 +0200" <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8 References: <20120412014127.26637.56232.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120411202530.085195c0@resistor.net> <8BC264E2-4666-4702-818B-FD774EBDF7A1@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailman-Approved-At: Fri, 13 Apr 2012 08:01:51 -0700 Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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 Apr 2012 21:08:54 -0000 > On 12. 4. 2012, at 9:11, SM wrote: > > At 18:41 11-04-2012, The IESG wrote: > >> The IESG has received a request from the DNS-based Authentication of > >> Named Entities WG (dane) to consider the following document: > >> - 'The DNS-Based Authentication of Named Entities (DANE) Protocol for > >> Transport Layer Security (TLS)' > >> as a Proposed Standard > >> > >> The IESG plans to make a decision in the next few weeks, and solicits > >> final comments on this action. Please send substantive comments to the > >> ietf@ietf.org mailing lists by 2012-04-25. Exceptionally, comments may be > > > > In Section 1.2: > > > > "This document applies to both TLS [RFC5246]" > > > > Does this mean that DANE is not applicable for TLS 1.1? > RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make references > to obsoleted documents. As a side note, we don't say "to both TLS 1.2", but > just TLS. I have no involvement with DANE or the rest of this debate, but I wanted to point out that this simply isn't true. IDNits warnings to the contrary notwithstanding, references to obsoleted specifications are not only allowed, but in some cases absolutely required. It all depends on what the reference is for. If you're making a normative reference to some protocol element that's supposed to interoperate with current versions, you need to reference the latest version. If, however, as in this case, you're talking about interoperating with multiple versions of TLS, you really need to reference the specifications you intend to support. Because otherwise readers are going to assume that you only mean TLS 1.2 here, irrespective of whether or not you omit the specific version in prose. Ned From ned.freed@mrochek.com Fri Apr 13 00:27:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1D21F846C for ; Fri, 13 Apr 2012 00:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEy2hd+xIy+7 for ; Fri, 13 Apr 2012 00:27:13 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 62F2221F844C for ; Fri, 13 Apr 2012 00:27:13 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE9151YIC0007PVR@mauve.mrochek.com> for dane@ietf.org; Fri, 13 Apr 2012 00:27:08 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OE0NBOM18G00ZUIL@mauve.mrochek.com>; Fri, 13 Apr 2012 00:27:06 -0700 (PDT) Message-id: <01OE9150IMNI00ZUIL@mauve.mrochek.com> Date: Fri, 13 Apr 2012 00:24:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Apr 2012 05:59:47 +0200 (MEST)" <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <"ned+ietf@mauve.mrochek.com"@Apr> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> To: Martin Rex X-Mailman-Approved-At: Fri, 13 Apr 2012 08:01:52 -0700 Cc: ned+ietf@mauve.mrochek.com, ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 07:27:14 -0000 > ned+ietf@mauve.mrochek.com wrote: > > > >>> > >>> In Section 1.2: > >>> > >>> "This document applies to both TLS [RFC5246]" > >>> > >>> Does this mean that DANE is not applicable for TLS 1.1? > >> > >> RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make references > >> to obsoleted documents. As a side note, we don't say "to both TLS 1.2", but > >> just TLS. > > > > I have no involvement with DANE or the rest of this debate, but I wanted to > > point out that this simply isn't true. IDNits warnings to the contrary > > notwithstanding, references to obsoleted specifications are not only allowed, > > but in some cases absolutely required. > Since the question keeps coming up again and again and again... > I firmly believe all three Obsoletion markers in the meta-data > of rfc5246 to be factually incorrect, so I filed an errata for this. > https://www.ietf.org/mail-archive/web/tls/current/msg08595.html An entirely reasonable position to take IMO, but even if it weren't it doesn't mean references to obsolete specifications aren't allowed. Ned From ogud@ogud.com Fri Apr 13 14:36:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4F511E8135 for ; Fri, 13 Apr 2012 14:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikwv7eMzV6c4 for ; Fri, 13 Apr 2012 14:36:18 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF3F11E8134 for ; Fri, 13 Apr 2012 14:36:17 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q3DLaGma087830 for ; Fri, 13 Apr 2012 17:36:16 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F889C4E.3050001@ogud.com> Date: Fri, 13 Apr 2012 17:36:14 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> In-Reply-To: <20120412215921.GP74554@registro.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 21:36:19 -0000 IANA has just published the allocation in http://www.iana.org/assignments/dns-parameters Feel free to start releasing code using this allocation! Olafur On 12/04/2012 17:59, Frederico A C Neves wrote: > John, > > On Thu, Apr 12, 2012 at 10:30:35AM -0700, John Gilmore wrote: >> Typo: s/certifcate/certificate/ >> >> Section 7.1: s/will be submitted/has been submitted/ . I'm surprised >> that we don't have an assigned value for the TLSA rrtype yet. > > Regarding the 6195 allocation process this is already done. > > http://www.ietf.org/mail-archive/web/dnsext/current/msg12420.html > > In our recommendation to IANA, based on a criteria the current experts > are following, I've suggested 52 as the value for TLSA, but they have > not yet returned with the actual allocation. Take this with handful of > sault as they could assign a different value if they like. > > Fred > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > > From warren@kumari.net Fri Apr 13 16:49:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06E411E813B for ; Fri, 13 Apr 2012 16:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWE1Pm3f0hSo for ; Fri, 13 Apr 2012 16:49:02 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94111E8138 for ; Fri, 13 Apr 2012 16:49:01 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 08B5C1B40394; Fri, 13 Apr 2012 19:49:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <4F889C4E.3050001@ogud.com> Date: Fri, 13 Apr 2012 19:48:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <154F6FD7-0860-4140-A00E-E87705A53C9A@kumari.net> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 13 Apr 2012 23:49:03 -0000 Thank you, Olafur=85 W On Apr 13, 2012, at 5:36 PM, Olafur Gudmundsson wrote: >=20 > IANA has just published the allocation in > http://www.iana.org/assignments/dns-parameters >=20 > Feel free to start releasing code using this allocation! >=20 > Olafur >=20 >=20 > On 12/04/2012 17:59, Frederico A C Neves wrote: >> John, >>=20 >> On Thu, Apr 12, 2012 at 10:30:35AM -0700, John Gilmore wrote: >>> Typo: s/certifcate/certificate/ >>>=20 >>> Section 7.1: s/will be submitted/has been submitted/ . I'm = surprised >>> that we don't have an assigned value for the TLSA rrtype yet. >>=20 >> Regarding the 6195 allocation process this is already done. >>=20 >> http://www.ietf.org/mail-archive/web/dnsext/current/msg12420.html >>=20 >> In our recommendation to IANA, based on a criteria the current = experts >> are following, I've suggested 52 as the value for TLSA, but they have >> not yet returned with the actual allocation. Take this with handful = of >> sault as they could assign a different value if they like. >>=20 >> Fred >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >>=20 >>=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul.hoffman@vpnc.org Fri Apr 13 18:14:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F311E8106 for ; Fri, 13 Apr 2012 18:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYvsQjuqbbv7 for ; Fri, 13 Apr 2012 18:14:09 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7311E8105 for ; Fri, 13 Apr 2012 18:14:08 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3E1E6RK036742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 13 Apr 2012 18:14:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F889C4E.3050001@ogud.com> Date: Fri, 13 Apr 2012 18:14:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 01:14:10 -0000 On Apr 13, 2012, at 2:36 PM, Olafur Gudmundsson wrote: > IANA has just published the allocation in > http://www.iana.org/assignments/dns-parameters >=20 > Feel free to start releasing code using this allocation! The document is in IETF Last Call and getting active discussion. After = IETF Last Call, the IESG will consider the specification. *** THE TECHNICAL PART OF THE SPECIFICATION CAN CHANGE BETWEEN NOW AND = WHEN IT IS SENT TO THE RFC EDITOR. *** It would be irresponsible to start releasing code at this point in time. = It would be wonderful to start releasing code after the IESG has passed = the document on to the RFC Editor. --Paul Hoffman From bmanning@karoshi.com Sat Apr 14 00:07:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3013C21F865C for ; Sat, 14 Apr 2012 00:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O6q5I2bPYLf for ; Sat, 14 Apr 2012 00:07:55 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2926221F86A6 for ; Sat, 14 Apr 2012 00:07:36 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com. (8.12.8/8.12.8) with ESMTP id q3AGfW2K002945 for ; Tue, 10 Apr 2012 16:41:33 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q3AGfWAc002944 for dane@ietf.org; Tue, 10 Apr 2012 16:41:32 GMT Date: Tue, 10 Apr 2012 16:41:31 +0000 From: bmanning@vacation.karoshi.com To: dane@ietf.org Message-ID: <20120410164131.GA2938@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [dane] antique signer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 07:07:56 -0000 dnssec-signzone -o bar.scan.net bar.scan.net dnssec-signzone: warning: bar.scan.net:17: unknown RR type 'TLSA' dnssec-signzone: fatal: failed loading zone from 'bar.scan.net': unknown class/type sadness. /bill From marka@isc.org Sat Apr 14 00:59:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A63A21F84E7 for ; Sat, 14 Apr 2012 00:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oZvEQI43xOZ for ; Sat, 14 Apr 2012 00:59:47 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 157D421F84AF for ; Sat, 14 Apr 2012 00:59:47 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F33725F984C; Sat, 14 Apr 2012 07:59:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:619b:7a0d:7f38:b821]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BB20F216C31; Sat, 14 Apr 2012 07:59:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 06DD01FB61F4; Sat, 14 Apr 2012 17:59:22 +1000 (EST) To: bmanning@vacation.karoshi.com From: Mark Andrews References: <20120410164131.GA2938@vacation.karoshi.com.> In-reply-to: Your message of "Tue, 10 Apr 2012 16:41:31 GMT." <20120410164131.GA2938@vacation.karoshi.com.> Date: Sat, 14 Apr 2012 17:59:21 +1000 Message-Id: <20120414075922.06DD01FB61F4@drugs.dv.isc.org> Cc: dane@ietf.org Subject: Re: [dane] antique signer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 07:59:48 -0000 In message <20120410164131.GA2938@vacation.karoshi.com.>, bmanning@vacation.karos hi.com writes: > > dnssec-signzone -o bar.scan.net bar.scan.net > dnssec-signzone: warning: bar.scan.net:17: unknown RR type 'TLSA' > dnssec-signzone: fatal: failed loading zone from 'bar.scan.net': unknown class/ > type And the purpose of this was what? To show that someone hasn't added type specific code for TLSA records withing 24 hours of the type being assigned despite there being no need for that type specific code to be written to actually use TLSA records? % dnssec-signzone -S -o example.net junk dnssec-signzone: warning: junk:1: no TTL specified; using SOA MINTTL instead Fetching ZSK 26127/RSASHA1 from key repository. Fetching KSK 61969/RSASHA1 from key repository. Verifying the zone using the following algorithms: RSASHA1. Zone signing complete: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked junk.signed % cat junk @ SOA . . 0 0 0 0 0 @ NS @ @ TYPE52 \# 11 00 00 00 1234567890abcdef % Of course it isn't that hard to add support for TLSA but like all things the changes will need to be reviewed. You could have just submitted patches instead of waiting for someone else to do it. It's not like you don't have the skill to do it. % cat junk @ SOA . . 0 0 0 0 0 @ NS @ @ TLSA 0 0 0 1234567890abcdef % dnssec-keygen example.net Generating key pair..............++++++ ..............++++++ Kexample.net.+005+26127 [drugs:~/git/bind9] marka% dnssec-keygen -f KSK example.net Generating key pair...........................................................................................................................................................................................................................+++ ...............................................................................+++ Kexample.net.+005+61969 % bin/dnssec/dnssec-signzone -S -o example.net junk dnssec-signzone: warning: junk:1: no TTL specified; using SOA MINTTL instead Fetching ZSK 26127/RSASHA1 from key repository. Fetching KSK 61969/RSASHA1 from key repository. Verifying the zone using the following algorithms: RSASHA1. Zone signing complete: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked junk.signed % Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ahu@xs.powerdns.com Sat Apr 14 02:26:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ECE21F85FB for ; Sat, 14 Apr 2012 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAGDafobE6Dg for ; Sat, 14 Apr 2012 02:26:14 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8CB21F8603 for ; Sat, 14 Apr 2012 02:26:14 -0700 (PDT) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1SIzFD-0005p9-Nh; Sat, 14 Apr 2012 11:26:11 +0200 Date: Sat, 14 Apr 2012 11:26:11 +0200 From: bert hubert To: Olafur Gudmundsson Message-ID: <20120414092611.GB21444@xs.powerdns.com> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F889C4E.3050001@ogud.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dane@ietf.org Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 09:26:15 -0000 On Fri, Apr 13, 2012 at 05:36:14PM -0400, Olafur Gudmundsson wrote: > > IANA has just published the allocation in > http://www.iana.org/assignments/dns-parameters > > Feel free to start releasing code using this allocation! Snapshot 2567 of the PowerDNS Authoriative Server, which is identical to 3.1-RC2 except for the move to the IANA code for TLSA, can be found on http://powerdnssec.org/downloads/ - as deb/rpm for intel/amd64, plus tar.gz. Paul H, I hear your worry that the RFC Editor might change things, but I consider the chance of the wire or zone format changing to be very small. I hope we can put this to rest before we release 3.1-final. 3.1 is slated to host >1 million DNSSEC domains pretty soon, it would be very cool if we could get these 1 million domains to be DANE-capable. 3.2 is not predicted to happen within 6 months of 3.1. Bert -- PowerDNS Website: http://www.powerdns.com/ PowerDNS Community Website: http://wiki.powerdns.com/ PowerDNS is supported and developed by Netherlabs: http://www.netherlabs.nl From bmanning@karoshi.com Sat Apr 14 03:10:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9621F84FD for ; Sat, 14 Apr 2012 03:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO9aVCeP33+N for ; Sat, 14 Apr 2012 03:10:45 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4819A21F84F1 for ; Sat, 14 Apr 2012 03:10:45 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id q3EAAiVm003190; Sat, 14 Apr 2012 10:10:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id q3EAAh0p003189; Sat, 14 Apr 2012 10:10:43 GMT Date: Sat, 14 Apr 2012 10:10:43 +0000 From: bmanning@vacation.karoshi.com To: Mark Andrews Message-ID: <20120414101043.GB3134@vacation.karoshi.com.> References: <20120410164131.GA2938@vacation.karoshi.com.> <20120414075922.06DD01FB61F4@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120414075922.06DD01FB61F4@drugs.dv.isc.org> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dane@ietf.org Subject: Re: [dane] antique signer? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 10:10:46 -0000 On Sat, Apr 14, 2012 at 05:59:21PM +1000, Mark Andrews wrote: > > In message <20120410164131.GA2938@vacation.karoshi.com.>, bmanning@vacation.karos > hi.com writes: > > > > dnssec-signzone -o bar.scan.net bar.scan.net > > dnssec-signzone: warning: bar.scan.net:17: unknown RR type 'TLSA' > > dnssec-signzone: fatal: failed loading zone from 'bar.scan.net': unknown class/ > > type > > And the purpose of this was what? To show that someone hasn't added > type specific code for TLSA records withing 24 hours of the type > being assigned despite there being no need for that type specific > code to be written to actually use TLSA records? > [elided] > > Of course it isn't that hard to add support for TLSA but like all > things the changes will need to be reviewed. You could have just > submitted patches instead of waiting for someone else to do it. It's > not like you don't have the skill to do it. > > Mark I run -two- (and occasionally more) trees of code, mine and and ISCs. This was a gentle nudge to ISC that yes, there are folks who still use their signing code. In my tree, it works just fine thanks. But then again, my tree has A6, BITSTRING, and DISCOVER support too. And there is quite a bit of code excised that has no purposed for me. I stopped submitting patches about 15 years ago when Paul asked me to. /bill From ogud@ogud.com Sat Apr 14 05:32:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4804221F84FD for ; Sat, 14 Apr 2012 05:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 432yom0OUP6h for ; Sat, 14 Apr 2012 05:32:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9CD21F84F1 for ; Sat, 14 Apr 2012 05:32:11 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q3ECWAHo093223 for ; Sat, 14 Apr 2012 08:32:10 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F896E48.10204@ogud.com> Date: Sat, 14 Apr 2012 08:32:08 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> In-Reply-To: <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 12:32:17 -0000 On 13/04/2012 21:14, Paul Hoffman wrote: > On Apr 13, 2012, at 2:36 PM, Olafur Gudmundsson wrote: > >> IANA has just published the allocation in >> http://www.iana.org/assignments/dns-parameters >> >> Feel free to start releasing code using this allocation! > > The document is in IETF Last Call and getting active discussion. After IETF Last Call, the IESG will consider the specification. > > *** THE TECHNICAL PART OF THE SPECIFICATION CAN CHANGE BETWEEN NOW AND WHEN IT IS SENT TO THE RFC EDITOR. *** > > It would be irresponsible to start releasing code at this point in time. It would be wonderful to start releasing code after the IESG has passed the document on to the RFC Editor. > Paul, It is safe to release code handles the TLSA DNS record in DNS software or translates to and from TLSA record. Writing code that translates CERT's into TLSA records can proceed. Writing code that processes and interprets TLSA records should wait. I would be surprised if the wire format of TLSA will change now. Yes there is a possibility that a type of certificate support be added/deleted, but that will not affect DNS side that much. DNS infrastructure software changes slowly thus getting an opportunity to get TLSA into releases between now and when the RFC is published can only help the long term DANE deployment as there will be some support for in the beginning. Bert, ship it. Olafur From paul.hoffman@vpnc.org Sat Apr 14 08:12:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2244321F84E1 for ; Sat, 14 Apr 2012 08:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM7zOeugxGnm for ; Sat, 14 Apr 2012 08:12:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B4FEC21F84DD for ; Sat, 14 Apr 2012 08:12:41 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3EFCdPP056577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 14 Apr 2012 08:12:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <20120414092611.GB21444@xs.powerdns.com> Date: Sat, 14 Apr 2012 08:12:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80EAA5EE-8410-459D-9D53-2E949C891891@vpnc.org> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <20120414092611.GB21444@xs.powerdns.com> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 15:12:57 -0000 On Apr 14, 2012, at 2:26 AM, bert hubert wrote: > Paul H, I hear your worry that the RFC Editor might change things, but = I > consider the chance of the wire or zone format changing to be very = small. You hear wrong. There is no chance that the RFC Editor will change = things that would affect the protocol. There is a very real chance the = IETF consensus process or the IESG will. > I hope we can put this to rest before we release 3.1-final. 3.1 is = slated to > host >1 million DNSSEC domains pretty soon, it would be very cool if = we > could get these 1 million domains to be DANE-capable. The IETF process goes at its own pace, for better or worse. --Paul Hoffman From paul.hoffman@vpnc.org Sat Apr 14 08:20:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42A921F85C5 for ; Sat, 14 Apr 2012 08:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7lX8tLxuKWD for ; Sat, 14 Apr 2012 08:20:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1326421F85C4 for ; Sat, 14 Apr 2012 08:20:11 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3EFKA9G056712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 14 Apr 2012 08:20:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F896E48.10204@ogud.com> Date: Sat, 14 Apr 2012 08:20:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> To: dane list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 15:20:11 -0000 On Apr 14, 2012, at 5:32 AM, Olafur Gudmundsson wrote: > It is safe to release code handles the TLSA DNS record in DNS software = or translates to and from TLSA record. > Writing code that translates CERT's into TLSA records can proceed. We disagree on both counts. > Writing code that processes and interprets TLSA records should wait. Correct. If you knew that, maybe you could have been a tad more clear in = your earlier message. > I would be surprised if the wire format of TLSA will change now. You are not the developer of software that has to deal with a change = between now and RFC approval. Your recommendation was to people who will = seriously damaged by a change, whereas all that would happen to you = would be surprise. > Yes there is a possibility that a type of certificate support be = added/deleted, but that will not affect DNS side that much. You are ignoring the infrastructure code that signs the records and = focusing on the server software that publishes them.=20 > DNS infrastructure software changes slowly thus getting an opportunity > to get TLSA into releases between now and when the RFC is published > can only help the long term DANE deployment as there will be some > support for in the beginning. "can only help" if you ignore the chance that what is being put into the = software is wrong. Also, to be clear, I didn't say "when the RFC is published", I said = "when the IESG sends it to the RFC Editor". The latter is way sooner = than the former. --Paul Hoffman From gnu@toad.com Sat Apr 14 17:04:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817A521F865A for ; Sat, 14 Apr 2012 17:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_50=0.001, RCVD_IN_NJABL_RELAY=2.696, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su9OgN1N++Jc for ; Sat, 14 Apr 2012 17:04:09 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5029921F8658 for ; Sat, 14 Apr 2012 17:03:54 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3F03kcF030283; Sat, 14 Apr 2012 17:03:46 -0700 Message-Id: <201204150003.q3F03kcF030283@new.toad.com> To: Stephen Kent , Paul Hoffman , dane list , John Gilmore In-reply-to: <201204122032.q3CKWWcF031380@new.toad.com> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> <201204122032.q3CKWWcF031380@new.toad.com> Comments: In-reply-to John Gilmore message dated "Thu, 12 Apr 2012 13:32:32 -0700." Date: Sat, 14 Apr 2012 17:03:46 -0700 From: John Gilmore Subject: Re: [dane] subverted websites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 15 Apr 2012 00:04:10 -0000 > > Recent experiences with compromises of CAs or their trusted partners > > have lead to very serious security problems, such as the subversion > > of major web sites trusted by millions of users. > > > > The web sites may not have been subverted. What happened was that > > users were no longer able to verify that they were connecting to the > > web sites they indicated via the URLs that the users employed. > > ... The web sites were subverted in > the strong sense that many users' interactions and credentials (login > names and passwords) were recorded by the man-in-the-middle and then > used against the interests of those users. I believe that some > governments used those credentials by changing the account passwords > or deleting the accounts from the service, so the relevant activists > could no longer communicate, but just now I'm having trouble finding a > public reference that supports that belief. EFF staffers helped me find the reference. A Javascript injection attack was done by the Tunisian Internet Agency in January 2011, during the "Arab Spring". This attack captured login and password information when Gmail, Yahoo, and Facebook users logged in from Tunisia. The government (or someone!) then logged into those accounts, possibly downloaded information from them, and deleted the accounts so that the users no longer had access to their accounts. They also apparently used information from the accounts to locate and arrest or detain the users, who were reporting on the government shooting unarmed citizens. See: https://www.eff.org/deeplinks/2011/01/eff-calls-immediate-action-defend-tunisian http://www.thetechherald.com/articles/Tunisian-government-harvesting-usernames-and-passwords/12429/ http://www.techdirt.com/articles/20110126/04453512834/how-facebook-dealt-with-tunisian-government-trying-to-steal-every-users-passwords.shtml http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-of-how-facebook-responded-to-tunisian-hacks/70044/ This attack was NOT done on sites accessed via SSL/TLS; it was done on plaintext accesses to the sites. At that time, more than a year ago, most major sites still didn't offer TLS-protected access to their sites by default, and many didn't offer it at all. (This incident pushed Facebook into forcing TLS access all across Tunisia, and improving their TLS capacity worldwide. Other companies such as Google also vastly improved their TLS support after seeing this kind of attack. Google also "pinned" a key in their Chrome browser, which helped them to detect the later Iranian MITM attack that used a bogus certificate signed by DigiNotar.) So, the statement that I drafted: Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the subversion of major web sites trusted by millions of users. is not supported by the Tunisian incident, which was unencrypted. However, subsequent attacks throughout 2011 did include attacks on the TLS CA infrastructure. See the dozen or so references in my earlier message: https://www.ietf.org/mail-archive/web/dane/current/msg04643.html many of which describe the same few incidents from different angles. Also note an independent Syrian MITM attack. This Syrian attack injected an invalid certificate that caused browsers to pop up certificate warnings, relying on users to click right through them: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook In summary, we have seen three successful country-sponsored MITM attacks (Tunisia in plaintext in January, Syria with a bogus cert in May, Iran with a trusted-but-bogus cert in July and August). We have seen another successful attempt to create bogus certificates that would be useful in a country-sponsored MITM attack (Comodo). We have also seen some "subordinate root" certificates, useful for the same purposes, issued to companies that make MITM equipment or that deploy it against their own employees (Trustwave acknowledged issuing one such cert, and commenters said "this is a common industry practice"). We don't yet have a smoking gun of an inappropriately issued cert that produced a documented series of account breakins or deletions. Nor even a documented series of government plaintext recordings of SSL-protected traffic, since documenting wiretapping is usually much harder than documenting account cancellations. However, we strongly suspect that Iran was wiretapping SSL-protected traffic, since their attempt to MITM Chrome in Iran is how they were first caught, and since about 300,000 people, mostly in Iran, used the same trusted-but-bogus "*.google.com" cert to access the DigiNotar OSCP server from August 4 thru the cert's revocation on August 29). So here's the current paragraph from Section 1 of draft-19: The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can compromise any other certificate that TLS uses, by signing a replacement certificate that contains a bogus key. Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the subversion of major web sites trusted by millions of users. I propose modifying the last sentence to say: Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the governments of multiple countries attempting to wiretap and/or subvert major TLS-protected web sites trusted by millions of users. Steve, does this make you happy? If not, please make more suggestions about how to finish editing this introduction. If the RFC should include informational references to some of the more technical or reputable analyses of these incidents, please select those references from among the ones I've provided (or others), and add their [foobar] citations after that new final sentence. John From pieter.lexis@os3.nl Mon Apr 16 03:11:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B621F8746 for ; Mon, 16 Apr 2012 03:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2O2wZkpsoJK for ; Mon, 16 Apr 2012 03:11:28 -0700 (PDT) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 7A21021F8745 for ; Mon, 16 Apr 2012 03:11:28 -0700 (PDT) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id BA9E917AA0E for ; Mon, 16 Apr 2012 12:11:25 +0200 (CEST) Received: from [IPv6:2001:610:158:1020:224:beff:fe39:69b9] (unknown [IPv6:2001:610:158:1020:224:beff:fe39:69b9]) by smtp.os3.nl (Postfix) with ESMTPSA id 6CC3117AA0D for ; Mon, 16 Apr 2012 12:11:25 +0200 (CEST) Message-ID: <4F8BF04C.4070105@os3.nl> Date: Mon, 16 Apr 2012 12:11:24 +0200 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> <201204122032.q3CKWWcF031380@new.toad.com> <201204150003.q3F03kcF030283@new.toad.com> In-Reply-To: <201204150003.q3F03kcF030283@new.toad.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dane] subverted websites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 10:11:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi John, On 04/15/2012 02:03 AM, John Gilmore wrote: > I propose modifying the last sentence to say: > > Recent experiences with compromises of CAs or their trusted > partners have lead to very serious security problems, such as the > governments of multiple countries attempting to wiretap and/or > subvert major TLS-protected web sites trusted by millions of > users. I fully agree with the rationale behind this proposed text. I do, however, believe that a political statement (about governments) does not belong in the document. I propose changing it to: Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as wiretapping and/or subvertion of major TLS-protected web sites trusted by millions of users. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPi/BHAAoJELPqGO5ebd4jQmEP/R0cMXSSvos7m8OQ2OkKUl+6 AR2zjOMmFutpHWvBJu022y/VU8ZOGZtia/KSB1n8nzAqi1Xpsa8vq4w/++4IZArv sh3tEKx5+Z+X/2q6z2+sWxsJS/F8q3x7gYWGA8K7w25J6hV5abcWSXnatvVfEc10 UYPiAxurnL9W4UhmGV2kM4ZFA7QUpUlqeQC98nMMlJm6RAkfwZ5ugUjL1KPFNuTN ws2BVYk0aDF+MV+jy4qbXhunftMq5U2e9Xcn2zT37ro1PCcbvLoaHUAuff9yCDnY ewCnQ7PiEL+ciV0Ige/3xIa2ou/ATOhY/OVaZa1+lnmxL26FCZOHRTaEOKiDRGNP W3wHb0Lf0ytcXUlYb8oKzi9r34Dcfge0BjVtLpsjkLZF8cMHqnyzR2kfsS5Ps1FA FUWHxDgdqUvsIUUk+Zsq5qGX10u8J2RgLNAxYAM62EuGG4Sv9yawwZfy1QVeEO7r fbWZtiVSfLOm+9CU07VNoTdzXFDhLJQFbTdGO4kETk7zFgwCTzvm8SnOoF/Xx7UB MCuCkN5WI5Oh67P5JkOMEMukH20q3WM5ZkwaIEI1LZ1CeokMWN0o/HA4BcERqP54 eYUgK/tvwilEr8fuxaUt17bRe2Ho9GOxrvA8h3cQQZarIegqowJkS+ZY8GVeoggT Gel6ENra24Xuz2o5uIi0 =4Q2+ -----END PGP SIGNATURE----- From ogud@ogud.com Mon Apr 16 08:43:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D742811E8083 for ; Mon, 16 Apr 2012 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1Y66JL4ynIF for ; Mon, 16 Apr 2012 08:43:46 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id BFD1621F8722 for ; Mon, 16 Apr 2012 08:43:34 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q3GFhWDJ010103 for ; Mon, 16 Apr 2012 11:43:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F8C3E23.4050201@ogud.com> Date: Mon, 16 Apr 2012 11:43:31 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> In-Reply-To: <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 15:43:48 -0000 On 14/04/2012 11:20, Paul Hoffman wrote: > On Apr 14, 2012, at 5:32 AM, Olafur Gudmundsson wrote: > >> It is safe to release code handles the TLSA DNS record in DNS software or translates to and from TLSA record. >> Writing code that translates CERT's into TLSA records can proceed. > > We disagree on both counts. Nothing new. > >> Writing code that processes and interprets TLSA records should wait. > > Correct. If you knew that, maybe you could have been a tad more clear in your earlier message. > Yes if that had stopped Process Orthodoxy jerk reaction from you. >> I would be surprised if the wire format of TLSA will change now. > > You are not the developer of software that has to deal with a change between now and RFC approval. Your recommendation was to people who will seriously damaged by a change, whereas all that would happen to you would be surprise. > If the DNS wire format for the DNS record that DANE needs changes, I will argue that a new RRtype needs to be allocated. The TLSA record is a simple thing, the interpretation of the TLSA record is the complicated part of DANE. >> Yes there is a possibility that a type of certificate support be added/deleted, but that will not affect DNS side that much. > > You are ignoring the infrastructure code that signs the records and focusing on the server software that publishes them. > DNSSEC signing is on wire-format DNS records, what developers can now do is to translate between presentation and wire formats ===> this enables DNSSEC signing. >> DNS infrastructure software changes slowly thus getting an opportunity >> to get TLSA into releases between now and when the RFC is published >> can only help the long term DANE deployment as there will be some >> support for in the beginning. > > "can only help" if you ignore the chance that what is being put into the software is wrong. > I have asked this question few times in the past: "Is the TLSA part of the DANE spec ready ?" Until recently the answer was always "we think so but we are not sure". This was a reasonable approach, thus if the TLSA was not ready when the early allocation request was made, why not just wait for IANA allocation after IESG approval? The whole point of early allocation was to enable early NATIVE support of the TLSA record in the DNS infrastructure!!! Your attitude on this list seems to be to spread FUD and derail early TLSA support. > Also, to be clear, I didn't say "when the RFC is published", I said "when the IESG sends it to the RFC Editor". The latter is way sooner than the former. > Fair enough, RFC publication takes place about 2 months after IESG approval, and how long it takes IESG to process a document is random. Olafur From hallam@gmail.com Mon Apr 16 09:05:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BBF21F8656 for ; Mon, 16 Apr 2012 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvfGQ4UGgle9 for ; Mon, 16 Apr 2012 09:05:35 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20C21F8655 for ; Mon, 16 Apr 2012 09:05:11 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2889044ggm.31 for ; Mon, 16 Apr 2012 09:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=95e/y4kaID93aQQMBt2XEak/iRwpS2YNDc1ojm6dj1A=; b=nbhrMKgZ4RKCKTYpAW6722q/pZ6oZUfSLgP1BQgsU+aXDaLOjfQRHN+9mVYEvpE/fJ BbBPnal3WiU8+IMYgJNA7LFrM5+eX0/MNf3pIoPh/MAdXuWelOzpk+EvicscfBJs02t2 KAIFQ555Gcd/osLsPqgboglQ0DOGwAoMlZT2C2ug6TA7uljLK23IF34nsTF2DaIj/Yzd isCe+0ctpIsLqF/n0hEEYrX/P8FwFH80HTAu3j3KjKucqVs9fjw9LRQGztXMMMVjrsaX bN/X9Bly2ovB409DzMHZuh/joSGtom1X0lz1LhPWXdfShwxW75H8CYMHj3uKs1SVoqW4 H90w== MIME-Version: 1.0 Received: by 10.60.28.33 with SMTP id y1mr16529680oeg.62.1334592311455; Mon, 16 Apr 2012 09:05:11 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Mon, 16 Apr 2012 09:05:11 -0700 (PDT) In-Reply-To: <201204121923.q3CJNPcF027743@new.toad.com> References: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> <201204121923.q3CJNPcF027743@new.toad.com> Date: Mon, 16 Apr 2012 12:05:11 -0400 Message-ID: From: Phillip Hallam-Baker To: John Gilmore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-dane-protocol@tools.ietf.org, dane@ietf.org, dane issue tracker Subject: Re: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:05:37 -0000 CABForum was formed because the IETF PKIX list had previously declined to become involved in defining Certification Policies and the ABA is limited in scope to the US. The PKIX WG did write an RFC on how to document a Certification policy but actual policies themselves are out of scope. As an unincorporated entity, the CABForum did not qualify for an EV cert. It seems likely that the new forum will. In fact that might well be one of the best reasons to decide on an incorporation route than one of the other options. CABForum is not alone in being a standards body with an 'interesting' incorporation status. Issuing certificates to the IETF involved some interesting discussions. Until recently, CABForum did not do protocol specification work because there was no IPR policy in place and this is a pre-condition for that type of work. The aspect of CABForum work that is more likely to be relevant to DANE is the BR requirements which are the base level requirements for any issue of a CA SSL cert. On Thu, Apr 12, 2012 at 3:23 PM, John Gilmore wrote: >> So I am opening issue for EV certs. Does WG have any opinion how to addr= ess this? > > Is there some RFC or standards-track Internet-Draft for EV certs? > > Wikipedia suggests that it's an ad-hoc non-standard created by some CA > vendors and web browser makers. =A0It's apparently issued by the > "CA/Browser Forum", an unincorporated entity that doesn't even offer > an EV certificate on its own secure web site > (https://www.cabforum.org). =A0The Forum recently announced a Working > Group designed to reform itself into an org that offers wider > participation, "a more open and public process", etc. > > If it's not an IETF standard, I suggest that we ignore it. =A0To the > IETF, a cert is a cert is a cert, and the RFCs on certs are careful > not to specify much about the exact contents of a cert, or how clients > should handle all the fiddly little bits attached to them. =A0DANE should > do the same. > > =A0 =A0 =A0 =A0John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 Website: http://hallambaker.com/ From ajs@anvilwalrusden.com Mon Apr 16 09:40:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7869511E80AC for ; Mon, 16 Apr 2012 09:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toMk+p5uEDli for ; Mon, 16 Apr 2012 09:40:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6511E80AB for ; Mon, 16 Apr 2012 09:40:22 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 004AD1ECB41D; Mon, 16 Apr 2012 16:40:21 +0000 (UTC) Date: Mon, 16 Apr 2012 12:40:20 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120416164009.GE49880@mail.yitter.info> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8C3E23.4050201@ogud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 16:40:23 -0000 Hi there, On Mon, Apr 16, 2012 at 11:43:31AM -0400, Olafur Gudmundsson wrote: > > If the DNS wire format for the DNS record that DANE needs changes, > I will argue that a new RRtype needs to be allocated. I'm not sure I agree with this. The reference in the RRTYPE Registry is neither to a draft nor to an RFC, but to "Kumari". That means that the wire format is going to be whatever Warren says it is until such time as the reference is stabilized. We adopted this flexibility for expert assignment of RRTYPEs in order to permit early assignment even in cases where we expected the wire format to be less than perfectly stable. The side effect of this has to be that those shipping code ought to be extremely wary of shipping anything without a stable reference. Experimental features -- and they're necessarily experimental until the reference is stable -- ought to be treated as such. So, if I were shipping code, I would not ship a version with TLSA turned on until I was sure what the wire format would be. And I couldn't be sure of that until there was a document in the reference that specified it in writing. > The TLSA record is a simple thing, the interpretation of the TLSA > record is the complicated part of DANE. The other complicated part of DANE is getting it through the IESG. > I have asked this question few times in the past: > "Is the TLSA part of the DANE spec ready ?" > Until recently the answer was always "we think so but we are not sure". > This was a reasonable approach, thus if the TLSA was not ready when > the early allocation request was made, why not just wait for IANA > allocation after IESG approval? Well, one reason is so that people could deploy experimental code today, with the understanding that, at any moment, the wire format of RRTYPE 52 could change. We have reason to suppose it is stable, but until the RFC is published, we cannot be sure. That is _always_ true -- it's true for this case, and it's also true for all the other non-RFC references in the registry. Last I checked, none of us had an unerring ability to predict the future, and I'd hate for people to interpret "code point in the registry" as some sort of promise about what will happen when a document goes to the IESG. Nobody can make those promises. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From kent@bbn.com Mon Apr 16 11:02:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3236221F8644 for ; Mon, 16 Apr 2012 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5Ud4kGCAKgk for ; Mon, 16 Apr 2012 11:02:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB421F8638 for ; Mon, 16 Apr 2012 11:02:39 -0700 (PDT) Received: from dhcp89-089-239.bbn.com ([128.89.89.239]:49182) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SJqFk-000DGg-Qi; Mon, 16 Apr 2012 14:02:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201204150003.q3F03kcF030283@new.toad.com> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> <201204122032.q3CKWWcF031380@new.toad.com> <201204150003.q3F03kcF030283@new.toad.com> Date: Mon, 16 Apr 2012 13:07:58 -0400 To: John Gilmore From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-877523140==_ma============" Cc: Paul Hoffman , dane list Subject: Re: [dane] subverted websites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 18:02:48 -0000 --============_-877523140==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" John, I like the revised final sentence. I do think we could be a bit more precise in the earlier text. How about: The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can undermine the secruity offered by any certificates employed with TLS. This problem arises because a compromised CA can issue a replacement certificate that contains a bogus key (i.e., a key not corresponding to the entity identified in the certificate). Recent experiences with compromises of CAs or their trusted partners have lead to very serious security problems, such as the governments of multiple countries attempting to wiretap and/or subvert major TLS-protected web sites trusted by millions of users. --============_-877523140==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dane] subverted websites
John,

I like the revised final sentence.  I do think we could be a bit more precise
in the earlier text. How about:


   The public CA model upon which TLS has depended is fundamentally
   vulnerable because it allows any of these CAs to issue a certificate
   for any domain name.  A single trusted CA that betrays its trust,
   either voluntarily or by providing less-than-vigorous protection for
   its secrets and capabilities, can undermine the secruity offered
by any certificates employed with TLS. This problem arises because a
compromised CA can issue a replacement certificate that contains a
   bogus key (i.e., a key not corresponding to the entity identified in the
certificate). Recent experiences with compromises of CAs or their
   trusted partners have lead to very serious security problems, such
   as the governments of multiple countries attempting to wiretap and/or
   subvert major TLS-protected web sites trusted by millions of users.

--============_-877523140==_ma============-- From ajs@anvilwalrusden.com Mon Apr 16 11:46:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA81A11E809D for ; Mon, 16 Apr 2012 11:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VSDvVKH1Cez for ; Mon, 16 Apr 2012 11:46:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 30FB611E809A for ; Mon, 16 Apr 2012 11:46:12 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9465B1ECB41D for ; Mon, 16 Apr 2012 18:46:11 +0000 (UTC) Date: Mon, 16 Apr 2012 14:46:09 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120416184601.GI49880@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dane] Possible ambiguity in -19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 18:46:12 -0000 Hi all, I was trying to draw a diagram of TLS using DANE and TLSA the other day, and I realised that there's a small ambiguity in -19. It is not clear from the text whether the client initiating the TLS connection needs to perform the TLSA lookup before the TLS negotiation starts, or once the certificate is presented by the server. The answer is, I believe, that it's up to the client. It might be nice to add a sentence to this effect, however. (This is a pretty minor addition and could be done any time, I think.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ogud@ogud.com Mon Apr 16 12:24:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4121F86CB for ; Mon, 16 Apr 2012 12:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIdGg8CWN7Yj for ; Mon, 16 Apr 2012 12:24:26 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2221F86C3 for ; Mon, 16 Apr 2012 12:24:26 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q3GJOOuZ011745 for ; Mon, 16 Apr 2012 15:24:24 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F8C71E6.1010103@ogud.com> Date: Mon, 16 Apr 2012 15:24:22 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> In-Reply-To: <20120416164009.GE49880@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 19:24:27 -0000 On 16/04/2012 12:40, Andrew Sullivan wrote: > Hi there, > > On Mon, Apr 16, 2012 at 11:43:31AM -0400, Olafur Gudmundsson wrote: > >> >> If the DNS wire format for the DNS record that DANE needs changes, >> I will argue that a new RRtype needs to be allocated. > > I'm not sure I agree with this. > > The reference in the RRTYPE Registry is neither to a draft nor to an > RFC, but to "Kumari". That means that the wire format is going to be > whatever Warren says it is until such time as the reference is > stabilized. We adopted this flexibility for expert assignment of But the application in this case referenced a particular version of an Internet draft: ---- E. Description of the proposed RR type. A description of tge RR type is in draft-ietf-dane-protocol-18.txt, Section 2 The TLSA Resource Record ( http://tools.ietf.org/id/draft-ietf-dane-protocol-18.txt ) ---- Version 18 of the draft says format is (my notation): oct, oct, oct, Hex_n where the value n depends on one of last 8 bit integer field. If a theoretical future version says: short, int, oct, Hex_32 I would consider that breach of good faith by the applicant to insist on using the allocated type code. If there are changes in the registries that are created by the ID that is fine. Type codes are cheap, interoperability problems are not. > RRTYPEs in order to permit early assignment even in cases where we > expected the wire format to be less than perfectly stable. The side > effect of this has to be that those shipping code ought to be > extremely wary of shipping anything without a stable reference. > Experimental features -- and they're necessarily experimental until > the reference is stable -- ought to be treated as such. There is code range for experimentations, see RFC6195 section 2.3 0x0F01 - 0x0FFF Private Use Andrew I hate to correct you, the whole point of early allocation was to avoid having to publish an standards track RFC in order to get an RR type code. There is no requirement to even publish anything about the record processing anywhere, much less as an RFC. But if you expect the type code to be in wide use you have a heavier burden of acting a responsible manner. > > So, if I were shipping code, I would not ship a version with TLSA > turned on until I was sure what the wire format would be. And I > couldn't be sure of that until there was a document in the reference > that specified it in writing. This is the crux of the matter, when is the expert review allocation process RR spec stable? I argue at the time of expert application. You and Paul argue that the record can be tinkered with after that (at least) if it references an Internet draft. > >> The TLSA record is a simple thing, the interpretation of the TLSA >> record is the complicated part of DANE. > > The other complicated part of DANE is getting it through the IESG. > out of scope for this discussion. >> I have asked this question few times in the past: >> "Is the TLSA part of the DANE spec ready ?" >> Until recently the answer was always "we think so but we are not sure". >> This was a reasonable approach, thus if the TLSA was not ready when >> the early allocation request was made, why not just wait for IANA >> allocation after IESG approval? > > Well, one reason is so that people could deploy experimental code > today, with the understanding that, at any moment, the wire format of > RRTYPE 52 could change. what is wrong with using 0xf?? values for that ? all you need to do is to send a email to the wg mailing list saying "I want to do an experiment and we will use code X here is my format." the private RRtype either contains version number or you roll the code each time there are wire format changes. In this case only consenting implementations are at risk. > We have reason to suppose it is stable, but > until the RFC is published, we cannot be sure. That is _always_ true > -- it's true for this case, and it's also true for all the other > non-RFC references in the registry. Last I checked, none of us had an > unerring ability to predict the future, and I'd hate for people to > interpret "code point in the registry" as some sort of promise about > what will happen when a document goes to the IESG. Nobody can make > those promises. > For people that feel like this I say: "IETF standards track documents SHOULD NOT use the DNS early allocation process" Furthermore I will say: If a simple building block like DNS record format needs to change during IESG review, the whole WG effort is suspect and it should be sent to back to the drawing board. Olafur From ajs@anvilwalrusden.com Mon Apr 16 12:59:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C221921F86E8; Mon, 16 Apr 2012 12:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn46Qw5XJqkO; Mon, 16 Apr 2012 12:59:37 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7221F86E4; Mon, 16 Apr 2012 12:59:37 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 563481ECB420; Mon, 16 Apr 2012 19:59:36 +0000 (UTC) Date: Mon, 16 Apr 2012 15:59:34 -0400 From: Andrew Sullivan To: dane@ietf.org, dnsext@ietf.org Message-ID: <20120416195934.GM49880@mail.yitter.info> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8C71E6.1010103@ogud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 19:59:37 -0000 This is really a discussion about an issue for the DNSEXT WG, so it's cc:d there. Follow ups should go there, too, unless they're linked tightly to the DANE issue. I didn't adjust the Followup header because in my experience that never works. On Mon, Apr 16, 2012 at 03:24:22PM -0400, Olafur Gudmundsson wrote: > But the application in this case referenced a particular version of an > Internet draft: Yes. This is why some people have objected to the difficulty of getting the approved templates. The template as in the application is not necessarily what was approved. I think in this case it is, but as we see the registry does not actually preserve the link. > If there are changes in the registries that are created by the ID > that is fine. > Type codes are cheap, interoperability problems are not. Yes. Which is rather a good reason to hesitate to ship code that doesn't have a stable refernence in the registry, if you ask me. > There is code range for experimentations, see RFC6195 section 2.3 > 0x0F01 - 0x0FFF Private Use Yes, I'm perfectly aware of that. The complaint has been that people want to be able to ship things with what they regard as minor differences without having to go through the DNS mafia again. Like it or not (I'm in the "not" camp), people are engineering around our community's intransigence. > Andrew I hate to correct you, the whole point of early allocation > was to avoid having to publish an standards track RFC in order to > get > an RR type code. That could be better achieved by "specification required". Expert review allows us to allocate a type code without any guarantee that the wire format will remain stable. There is exactly one way to guarantee that such a wire format will remain stable, and that is to publish something in an archival series. We have a way to do that: publish an RFC. Requiring conformance with RRTYPE application templates or anything else is nonsense, because the references aren't stable. This is in fact a much more serious example of the same fight we had when we tried to be clever with the registry in the registry-fixes attempt some time ago. (In that case, I happened to think we were right, but the objection rested on the same foundation: if you want a stable reference, put it in an RFC.) > what is wrong with using 0xf?? values for that ? > > all you need to do is to send a email to the wg mailing list saying > "I want to do an experiment and we will use code X here is my format." > the private RRtype either contains version number or you roll the > code each time there are wire format changes. In this case only > consenting implementations are at risk. Nothing, of course. I have no idea why people even want RRTYPE assignments prior to publishing an RFC with the specification, but people do. > If a simple building block like DNS record format needs to change > during IESG review, the whole WG effort is suspect and it should be > sent to back to the drawing board. I fully agree. But it is one thing to say, "This sure hadn't better change. If it does, something is really wrong," and quite another to say, "This can't possibly change." Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From gnu@toad.com Mon Apr 16 13:13:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9525C21F873D for ; Mon, 16 Apr 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0+Y0O6cex-O for ; Mon, 16 Apr 2012 13:13:04 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD221F873C for ; Mon, 16 Apr 2012 13:12:42 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3GKCacF028743; Mon, 16 Apr 2012 13:12:36 -0700 Message-Id: <201204162012.q3GKCacF028743@new.toad.com> To: Stephen Kent In-reply-to: References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> <201204122032.q3CKWWcF031380@new.toad.com> <201204150003.q3F03kcF030283@new.toad.com> Comments: In-reply-to Stephen Kent message dated "Mon, 16 Apr 2012 13:07:58 -0400." Date: Mon, 16 Apr 2012 13:12:36 -0700 From: John Gilmore Cc: dane list , Paul Hoffman Subject: Re: [dane] subverted websites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 20:13:04 -0000 > The public CA model upon which TLS has depended is fundamentally > vulnerable because it allows any of these CAs to issue a certificate > for any domain name. A single trusted CA that betrays its trust, > either voluntarily or by providing less-than-vigorous protection for > its secrets and capabilities, can undermine the secruity offered > by any certificates employed with TLS. This problem arises because a > compromised CA can issue a replacement certificate that contains a > bogus key (i.e., a key not corresponding to the entity identified in the > certificate). Recent experiences with compromises of CAs or their > trusted partners have lead to very serious security problems, such > as the governments of multiple countries attempting to wiretap and/or > subvert major TLS-protected web sites trusted by millions of users. I agree with this text, with a minor typo fix (s/secruity/security/). John From paul@nohats.ca Mon Apr 16 13:20:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0406011E8091 for ; Mon, 16 Apr 2012 13:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Jgf5vBiC7G8 for ; Mon, 16 Apr 2012 13:20:28 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7B511E808C for ; Mon, 16 Apr 2012 13:20:28 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id EF8F080348; Mon, 16 Apr 2012 16:20:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id E27B58033B; Mon, 16 Apr 2012 16:20:26 -0400 (EDT) Date: Mon, 16 Apr 2012 16:20:26 -0400 (EDT) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20120416184601.GI49880@mail.yitter.info> Message-ID: References: <20120416184601.GI49880@mail.yitter.info> User-Agent: Alpine 2.02 (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] Possible ambiguity in -19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 20:20:29 -0000 On Mon, 16 Apr 2012, Andrew Sullivan wrote: > I was trying to draw a diagram of TLS using DANE and TLSA the other > day, and I realised that there's a small ambiguity in -19. > > It is not clear from the text whether the client initiating the TLS > connection needs to perform the TLSA lookup before the TLS negotiation > starts, or once the certificate is presented by the server. > > The answer is, I believe, that it's up to the client. Yes. A client might fire of TLSA and HASTLS requests while it already attempts to initiate to port 443. I would hope the browser would do some caching of these records (and lack of these records!) to reduce the number of failed port 443 attempts. But in light of how browsers do pre-emptive look-ups of all DNS entries in links to the current page, it could also request TLSA and HASTLS and actually already know before it needs to connect to the remote server whether or not it can do TLS. Of course the same applies if the links it found were https:// instead of http:// but I believe the idea of HASTLS was that it would override any presented http:// to https:// if such a HASTLS record would be found (and validated) and was stating it did not run a service on port 80. Paul From paul.hoffman@vpnc.org Mon Apr 16 14:37:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28821F85B9 for ; Mon, 16 Apr 2012 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td2Wjg2BN7xo for ; Mon, 16 Apr 2012 14:37:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AF63521F85B4 for ; Mon, 16 Apr 2012 14:37:47 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3GLbgK8045012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Apr 2012 14:37:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120416184601.GI49880@mail.yitter.info> Date: Mon, 16 Apr 2012 14:37:42 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7C44E8D7-8577-47DC-ADAD-AD2EB6D6E5BF@vpnc.org> References: <20120416184601.GI49880@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: dane@ietf.org Subject: Re: [dane] Possible ambiguity in -19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 21:37:48 -0000 On Apr 16, 2012, at 11:46 AM, Andrew Sullivan wrote: > I was trying to draw a diagram of TLS using DANE and TLSA the other > day, and I realised that there's a small ambiguity in -19. > > It is not clear from the text whether the client initiating the TLS > connection needs to perform the TLSA lookup before the TLS negotiation > starts, or once the certificate is presented by the server. > > The answer is, I believe, that it's up to the client. It might be > nice to add a sentence to this effect, however. (This is a pretty > minor addition and could be done any time, I think.) Arrgh. I thought we had done that in an earlier version, but we didn't. Proposal to add at the end of Section 4: The application can perform the TLSA lookup before initiating the TLS handshake, or do it during the TLS handshake: the choice is up to the client. --Paul Hoffman From ondrej.sury@nic.cz Mon Apr 16 16:12:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924C611E80D1 for ; Mon, 16 Apr 2012 16:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f98fKNumH4yX for ; Mon, 16 Apr 2012 16:12:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 49DFA11E807F for ; Mon, 16 Apr 2012 16:12:06 -0700 (PDT) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id A52B313F871; Tue, 17 Apr 2012 01:12:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334617924; bh=kYqXoU14nBRIcHYgjyvnRYa2eNChLZucPD3RwQlWrvk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XEj7Um2Qw73NEjqFfOxkXmqOzL4ZtME7HyDHae6iZl1xplPBbsK7VMZU4AJ+oKab6 PtggChBvU+uBTqDvbHvKk4s42/lIXxOZqZTQrpq9YKyyb3uzejA5TTre9JCSPgEjrY U0OJZOrED1pUWUvKdTinzzwqlriof7inpj8SumDs= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <7C44E8D7-8577-47DC-ADAD-AD2EB6D6E5BF@vpnc.org> Date: Tue, 17 Apr 2012 01:12:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61CD4DFA-51DF-4971-9F1F-8CD2462AA519@nic.cz> References: <20120416184601.GI49880@mail.yitter.info> <7C44E8D7-8577-47DC-ADAD-AD2EB6D6E5BF@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] Possible ambiguity in -19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 23:12:08 -0000 On 16. 4. 2012, at 23:37, Paul Hoffman wrote: > On Apr 16, 2012, at 11:46 AM, Andrew Sullivan wrote: >=20 >> I was trying to draw a diagram of TLS using DANE and TLSA the other >> day, and I realised that there's a small ambiguity in -19. >>=20 >> It is not clear from the text whether the client initiating the TLS >> connection needs to perform the TLSA lookup before the TLS = negotiation >> starts, or once the certificate is presented by the server. >>=20 >> The answer is, I believe, that it's up to the client. It might be >> nice to add a sentence to this effect, however. (This is a pretty >> minor addition and could be done any time, I think.) >=20 >=20 > Arrgh. I thought we had done that in an earlier version, but we = didn't. >=20 > Proposal to add at the end of Section 4: >=20 > The application can perform the TLSA lookup before initiating the > TLS handshake, or do it during the TLS handshake: the choice is > up to the client. lgtm -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Mon Apr 16 16:12:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE7411E807F for ; Mon, 16 Apr 2012 16:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr2vJAPrp3VN for ; Mon, 16 Apr 2012 16:12:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3762811E80E7 for ; Mon, 16 Apr 2012 16:12:20 -0700 (PDT) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 5BD4814048B; Tue, 17 Apr 2012 01:12:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334617939; bh=od0st2HPStozK7MNBdPmQ2vvRkjj/rTXaoCz+vdOscU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jUL3W011Y9jJ908Dq4s2R+w2hvOtidF5DHcsDl2HfNCH++SxR62SMkSvsCv6KKb+K fI5OooDHCYCRrY/KnP+DUFuln6rNax8NyoGoAhibVjM4ukf/tRDL1K0ODd69C+tOLQ cbKW1z+mHTSCv2FfuzaTjWl3I8Hgy33HDryeb9Z0= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <201204162012.q3GKCacF028743@new.toad.com> Date: Tue, 17 Apr 2012 01:12:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5156D83B-9709-4794-AFE5-CC4EA08356E5@nic.cz> References: <4F6877E7.5030905@cs.tcd.ie> <6FB529D2-A755-4F18-A3B7-5F1C39626033@vpnc.org> <4F68B481.9090204@cs.tcd.ie> <4F69038C.10507@bluepopcorn.net> <4F690B56.1070504@cs.tcd.ie> <06DABCE3-EE5D-45FE-9A23-7FDB6F99DA51@vpnc.org> <2DA79198-EE29-45BE-A6FC-5BF6471588ED@kumari.net> <201204122032.q3CKWWcF031380@new.toad.com> <201204150003.q3F03kcF030283@new.toad.com> <201204162012.q3GKCacF028743@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Paul Hoffman , dane list Subject: Re: [dane] subverted websites X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 23:12:20 -0000 On 16. 4. 2012, at 22:12, John Gilmore wrote: >> The public CA model upon which TLS has depended is fundamentally >> vulnerable because it allows any of these CAs to issue a = certificate >> for any domain name. A single trusted CA that betrays its trust, >> either voluntarily or by providing less-than-vigorous protection = for >> its secrets and capabilities, can undermine the secruity offered >> by any certificates employed with TLS. This problem arises because a >> compromised CA can issue a replacement certificate that contains a >> bogus key (i.e., a key not corresponding to the entity identified = in the >> certificate). Recent experiences with compromises of CAs or their >> trusted partners have lead to very serious security problems, such >> as the governments of multiple countries attempting to wiretap = and/or >> subvert major TLS-protected web sites trusted by millions of = users. >=20 > I agree with this text, with a minor typo fix (s/secruity/security/). Also works for me. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Mon Apr 16 16:17:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606221F8537; Mon, 16 Apr 2012 16:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hTTHCToZHG5; Mon, 16 Apr 2012 16:17:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB621F8539; Mon, 16 Apr 2012 16:17:40 -0700 (PDT) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id C11CD14048B; Tue, 17 Apr 2012 01:17:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1334618259; bh=bbI+4UMjSTjAWhZBegLqPdOJXRW0tHif70DUJd2ntvI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References; b=cvga2WnPjrHahppkZuej8NkaKGAH8rX2LX6viVTuEzzz0sEQnHyxaATZYzUoLlxgN jKFrm0hb5Dsxl/IdU5pNwb3987VWVbTykRC/y9E4NDQMbrCXBMIabuBwodqPQW6Ksj kSdCkVpqC8nOQUOVjtWhjkg09sONo29T3oyUjuhg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120416195934.GM49880@mail.yitter.info> Date: Tue, 17 Apr 2012 01:17:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A893CEE-7AA3-403D-BFD6-61F5D69D3802@nic.cz> References: <201204121730.q3CHUZcF021835@new.toad.com> <20120412215921.GP74554@registro.br> <4F889C4E.3050001@ogud.com> <8A01597C-D02E-4279-B755-E12CC6137EA2@vpnc.org> <4F896E48.10204@ogud.com> <811782ED-AF00-4D84-9341-1FCB3DFACE0E@vpnc.org> <4F8C3E23.4050201@ogud.com> <20120416164009.GE49880@mail.yitter.info> <4F8C71E6.1010103@ogud.com> <20120416195934.GM49880@mail.yitter.info> X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dane] TLSA == RRtype 52 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Apr 2012 23:17:41 -0000 On 16. 4. 2012, at 21:59, Andrew Sullivan wrote: > This is really a discussion about an issue for the DNSEXT WG, so it's > cc:d there. Follow ups should go there, too, unless they're linked > tightly to the DANE issue. I didn't adjust the Followup header > because in my experience that never works. Yes, please keep the further discussion off this list. And everybody please cool down before responding, or rather do not respond here at = all. Feel free to do whatever you want, but please be aware, that we have not reached the RFC status yet. So same rules applies as when you were using "experimental" allocations in your code. E.g. if you have tools which used TYPE655xx, then feel free to use TYPE52, but clearly mark that as experimental feature, which can change. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ietf@augustcellars.com Wed Apr 18 18:12:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161E821F8455 for ; Wed, 18 Apr 2012 18:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGdZtO4THvJL for ; Wed, 18 Apr 2012 18:12:36 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A423421F8445 for ; Wed, 18 Apr 2012 18:12:36 -0700 (PDT) Received: from Tobias (50-54-163-224.evrt.wa.frontiernet.net [50.54.163.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 43B122C9F7; Wed, 18 Apr 2012 18:12:36 -0700 (PDT) From: "Jim Schaad" To: "'Adam Langley'" , References: In-Reply-To: Date: Wed, 18 Apr 2012 18:11:41 -0700 Message-ID: <024b01cd1dc9$61299700$237cc500$@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: AQGRp3jjGu7gCmCGYD/SJjgigRFB9JcYQqkg Content-Language: en-us Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:12:41 -0000 Adam, In another context I am looking at using a dane serialization, however one of the things that I don't have a good handle on at the moment is the size of the serialized chain. I realize that this is highly dependent on things like the type of key and number of keys. However did you develop any metrics on the size of chains based on what you did? Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Adam Langley > Sent: Tuesday, June 28, 2011 11:23 AM > To: dane@ietf.org > Subject: [dane] Draft for serializing DNSSEC chains > > As promised. (This is also the format that Chrome is using for it's DNSSEC > stapled certificate support.) > > http://tools.ietf.org/html/draft-agl-dane-serializechain-00 > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From Jeff.Hodges@KingsMountain.com Fri Apr 20 10:50:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3512D21F869E for ; Fri, 20 Apr 2012 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.751 X-Spam-Level: X-Spam-Status: No, score=-99.751 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CcM3AbGPR8F for ; Fri, 20 Apr 2012 10:50:27 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 634B221F869D for ; Fri, 20 Apr 2012 10:50:27 -0700 (PDT) Received: (qmail 9530 invoked by uid 0); 20 Apr 2012 17:50:27 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 20 Apr 2012 17:50:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Ccc54xKg0M/6zoN3gSTgYZT8ChPcoN6chu54dublxQg=; b=U9UiQxlnUXqBR6UF586vlMZgfwsGQGpX1OUBnpovLamzhp2D8rgcjAAZ2NX5kRYgBFL10yw80InSDfh0TeVhkNKRlCgr7JSHivz7iyjt2pV/bJAilwY8JN8l0VAVYPit; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SLHyT-0001QE-MN for dane@ietf.org; Fri, 20 Apr 2012 11:50:25 -0600 Message-ID: <4F91A1DD.3060900@KingsMountain.com> Date: Fri, 20 Apr 2012 10:50:21 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 17:50:28 -0000 Howdy, Various specs are going to have need to refer to the DANE protocol specification a well as describe the notion of domain names that map to TLSA records describing certificate associations. In working on such language in draft-ietf-websec-strict-transport-sec, here's the terms I'm using at this time and their (contextual) meaning.. DANE protocol The protocol specified in draft-ietf-dane-protocol (RFC# tbd). trusted certificate association A certificate association specified in a TLSA record obtained via an error-free lookup in the Secure DNS. Note that at this time, neither of the above precise terms are defined in draft-ietf-dane-protocol-19, although the title of the spec is essentially "DANE protocol", and the term "certificate association" (as-is, as well as further variously qualified) is used throughout the spec. You can view this as a comment on draft-ietf-dane-protocol-19 if you like -- i.e., the spec could perhaps more explicitly provide guidance as to how it and its mechanism should be referred to. HTH, =JeffH From paul.hoffman@vpnc.org Fri Apr 20 13:57:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225D021F85E1 for ; Fri, 20 Apr 2012 13:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIs6TfqNFghu for ; Fri, 20 Apr 2012 13:57:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 759D321F85DB for ; Fri, 20 Apr 2012 13:57:30 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3KKvSu2053578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Apr 2012 13:57:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F91A1DD.3060900@KingsMountain.com> Date: Fri, 20 Apr 2012 13:57:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F91A1DD.3060900@KingsMountain.com> To: IETF DANE WG list X-Mailer: Apple Mail (2.1257) Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 20:57:31 -0000 On Apr 20, 2012, at 10:50 AM, =3DJeffH wrote: > Various specs are going to have need to refer to the DANE protocol = specification a well as describe the notion of domain names that map to = TLSA records describing certificate associations. >=20 > In working on such language in draft-ietf-websec-strict-transport-sec, = here's the terms I'm using at this time and their (contextual) meaning.. >=20 >=20 > DANE protocol > The protocol specified in draft-ietf-dane-protocol (RFC# tbd). There is an issue here that we haven't dealt with, which is that "DANE = protocol" doesn't really make sense because we might be adding = additional protocols for certificate associations for things other than = TLS. For your doc, you should be saying "TLSA protocol", not "DANE = protocol" because HSTS is specific to TLS. (More below.) > trusted certificate association > A certificate association specified in a TLSA record obtained via an > error-free lookup in the Secure DNS. >=20 >=20 We use the term "usable certificate association" in section 4. For your = spec, how about: trusted certificate association A certificate association specified in a TLSA record that is determined to be usable in the TLSA spec. > Note that at this time, neither of the above precise terms are defined = in draft-ietf-dane-protocol-19, although the title of the spec is = essentially "DANE protocol", and the term "certificate association" = (as-is, as well as further variously qualified) is used throughout the = spec. >=20 > You can view this as a comment on draft-ietf-dane-protocol-19 if you = like -- i.e., the spec could perhaps more explicitly provide guidance as = to how it and its mechanism should be referred to. Good point. Proposal for our spec: The protocol in this document can generally be referred to as the "TLSA = protocol". Do others like this? --Paul Hoffman From Jeff.Hodges@KingsMountain.com Fri Apr 20 15:34:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937CB11E8088 for ; Fri, 20 Apr 2012 15:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.123 X-Spam-Level: X-Spam-Status: No, score=-100.123 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu47aqFBxnlq for ; Fri, 20 Apr 2012 15:34:45 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id E24A811E8086 for ; Fri, 20 Apr 2012 15:34:44 -0700 (PDT) Received: (qmail 32058 invoked by uid 0); 20 Apr 2012 22:34:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 20 Apr 2012 22:34:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Rq/2gqXuVZ5p+6bmEbT2fHDtr+5sgfXoitXoSn19jzM=; b=2KenwPp24qatcqVwuUNVMcRChXpCubh2XzHjuz55aKKcY/qXWXZOUgF5Ako4WvNgbo1f4oL7/AJJSJtigTTH1aulTfFvEmlRolelPiPw8XhrpWMJIbTlo7HYMpdQzSGd; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SLMPb-0005r0-Ue for dane@ietf.org; Fri, 20 Apr 2012 16:34:43 -0600 Message-ID: <4F91E481.8070801@KingsMountain.com> Date: Fri, 20 Apr 2012 15:34:41 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2012 22:34:45 -0000 > On Apr 20, 2012, at 10:50 AM, =JeffH wrote: > >> Various specs are going to have need to refer to the DANE protocol >> specification a well as describe the notion of domain names that map to >> TLSA records describing certificate associations. >> >> In working on such language in draft-ietf-websec-strict-transport-sec, >> here's the terms I'm using at this time and their (contextual) meaning.. >> >> >> DANE protocol >> The protocol specified in draft-ietf-dane-protocol (RFC# tbd). > > There is an issue here that we haven't dealt with, which is that "DANE > protocol" doesn't really make sense because we might be adding additional > protocols for certificate associations for things other than TLS. Yep. "DANE" is a working group name. But, I was working from the specification name per the present spec. > ... > Proposal for [-dane-protocol] spec: > > The protocol in this document can generally be referred to as the "TLSA > protocol". So as a practical matter, if we wish to refer to this particular spec as defining the "TLSA protocol", then perhaps the spec title should reflect that such that the RFC Index is searchable for that "TLSA" term. > We use the term "usable certificate association" in section 4. For your > spec, how about: > > trusted certificate association > A certificate association specified in a TLSA record > that is determined to be usable in the TLSA spec. > In that case, I'd be inclined to just use "usable cert association" rather than redefine it with the qualifier "trusted" (ie, if that's not what the -dane-protocol spec defines). Also, it would be helpful if the term "usable certificate association" is explicitly defined in a clearly referenceable manner in -dane-protocol. This could be done by making that final para of section 4 a titled subsection, e.g.. 4.1 Usable Certificate Association but since I notice that section 4 is entitled "Use of TLSA Records in TLS" it should perhaps be.. 4.1 Usable TLS Certificate Association Or/and perhaps explicit definitions such as this could be explicitly added to section "1.4. Terminology". And the HSTS spec should perhaps use "usable TLS certificate association". HTH, =JeffH From paul.hoffman@vpnc.org Sat Apr 21 13:38:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5031D21F8649 for ; Sat, 21 Apr 2012 13:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juZ0ThjVq8+C for ; Sat, 21 Apr 2012 13:38:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9C021F8646 for ; Sat, 21 Apr 2012 13:38:41 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3LKccQh099110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2012 13:38:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F91E481.8070801@KingsMountain.com> Date: Sat, 21 Apr 2012 13:38:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EE3D72F-1093-4C76-80BC-7F1C5CDAE003@vpnc.org> References: <4F91E481.8070801@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 20:38:42 -0000 On Apr 20, 2012, at 3:34 PM, =3DJeffH wrote: > > On Apr 20, 2012, at 10:50 AM, =3DJeffH wrote: > > > >> Various specs are going to have need to refer to the DANE protocol > >> specification a well as describe the notion of domain names that = map to > >> TLSA records describing certificate associations. > >> > >> In working on such language in = draft-ietf-websec-strict-transport-sec, > >> here's the terms I'm using at this time and their (contextual) = meaning.. > >> > >> > >> DANE protocol > >> The protocol specified in draft-ietf-dane-protocol (RFC# tbd). > > > > There is an issue here that we haven't dealt with, which is that = "DANE > > protocol" doesn't really make sense because we might be adding = additional > > protocols for certificate associations for things other than TLS. >=20 > Yep. "DANE" is a working group name. But, I was working from the = specification name per the present spec. >=20 > > ... > > Proposal for [-dane-protocol] spec: > > > > The protocol in this document can generally be referred to as the = "TLSA > > protocol". >=20 > So as a practical matter, if we wish to refer to this particular spec = as defining the "TLSA protocol", then perhaps the spec title should = reflect that such that the RFC Index is searchable for that "TLSA" term. The WG already decided against that (unfortunately). > > We use the term "usable certificate association" in section 4. For = your > > spec, how about: > > > > trusted certificate association > > A certificate association specified in a TLSA record > > that is determined to be usable in the TLSA spec. > > >=20 > In that case, I'd be inclined to just use "usable cert association" = rather than redefine it with the qualifier "trusted" (ie, if that's not = what the -dane-protocol spec defines). >=20 > Also, it would be helpful if the term "usable certificate association" = is explicitly defined in a clearly referenceable manner in = -dane-protocol. >=20 > This could be done by making that final para of section 4 a titled = subsection, e.g.. >=20 > 4.1 Usable Certificate Association >=20 > but since I notice that section 4 is entitled "Use of TLSA Records in = TLS" it should perhaps be.. >=20 > 4.1 Usable TLS Certificate Association I like the former. > Or/and perhaps explicit definitions such as this could be explicitly = added to section "1.4. Terminology". The definition of what is "usable" goes on for many paragraphs, so that = doesn't seem so great. > And the HSTS spec should perhaps use "usable TLS certificate = association". Yes. --Paul Hoffman From gnu@toad.com Sat Apr 21 18:53:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9B821F84D8 for ; Sat, 21 Apr 2012 18:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.428 X-Spam-Level: X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KapNC0sYdeG for ; Sat, 21 Apr 2012 18:53:11 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id A2EC621F84D5 for ; Sat, 21 Apr 2012 18:53:11 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3M1rBcF028072; Sat, 21 Apr 2012 18:53:11 -0700 Message-Id: <201204220153.q3M1rBcF028072@new.toad.com> To: Paul Hoffman In-reply-to: <0EE3D72F-1093-4C76-80BC-7F1C5CDAE003@vpnc.org> References: <4F91E481.8070801@KingsMountain.com> <0EE3D72F-1093-4C76-80BC-7F1C5CDAE003@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Sat, 21 Apr 2012 13:38:38 -0700." Date: Sat, 21 Apr 2012 18:53:11 -0700 From: John Gilmore Cc: IETF DANE WG list Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Apr 2012 01:53:12 -0000 I tried bearding this lion several times, too. It's painful to have a spec that we have no short name for. My latest suggestion is that we call it the "DANE TLS" protocol. I still find the whole "certificate association" undefined term puzzling. Maybe somebody else can take a stab at defining it. Or maybe the WG really likes having undefined terms at the heart of its protocol. A "certificate association" seems to be defined as "whatever is in a TLSA record" but to me that's rather circular. I would prefer that we just called it a TLSA record if that's all it's going to be. John From paul.hoffman@vpnc.org Sun Apr 22 07:29:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7D21F85A0 for ; Sun, 22 Apr 2012 07:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJE95UnmYcus for ; Sun, 22 Apr 2012 07:29:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F084A21F859F for ; Sun, 22 Apr 2012 07:29:13 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3MET8SQ026969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Apr 2012 07:29:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201204220153.q3M1rBcF028072@new.toad.com> Date: Sun, 22 Apr 2012 07:29:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3EE97749-34D7-4CC0-834A-ECBC7EB99336@vpnc.org> References: <4F91E481.8070801@KingsMountain.com> <0EE3D72F-1093-4C76-80BC-7F1C5CDAE003@vpnc.org> <201204220153.q3M1rBcF028072@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Apr 2012 14:29:14 -0000 On Apr 21, 2012, at 6:53 PM, John Gilmore wrote: > I tried bearding this lion several times, too. It's painful to have a > spec that we have no short name for. My latest suggestion is that we > call it the "DANE TLS" protocol. Just noting that this is not what you suggested the last time, I = believe. > I still find the whole "certificate association" undefined term = puzzling. In what way is it "undefined"? > Maybe somebody else can take a stab at defining it. =20 The draft says: A certificate association is formed from a piece of information identifying a certificate and the domain name where the data is found. The combination of a trust anchor and a domain name can also be a certificate association. > Or maybe the WG > really likes having undefined terms at the heart of its protocol. The fact that you don't like the definition that is given in the draft = says something about what you "really like"; it doesn't reflect anything = about the WG. > A "certificate association" seems to be defined as "whatever is in a=20= > TLSA record" but to me that's rather circular. =20 The definition above does not contain those terms, nor even that idea. > I would prefer that we > just called it a TLSA record if that's all it's going to be. So far, the WG has not agreed that that is all it is going to be. You = can propose that, but it would be a new definition. --Paul Hoffman From alangley@gmail.com Mon Apr 23 09:52:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498221F85F9 for ; Mon, 23 Apr 2012 09:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdPNzZCHjrag for ; Mon, 23 Apr 2012 09:52:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBBC21F85EF for ; Mon, 23 Apr 2012 09:52:53 -0700 (PDT) Received: by iazz13 with SMTP id z13so20636925iaz.31 for ; Mon, 23 Apr 2012 09:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fhh676mJMXTAAfzHgRTI9Io8E65kP5zAay/5LQ5VFck=; b=gVA7Gr7tHzx2oWcQBKnV7Yis9HcvIoEBEIfjmzJOks7jMfqPb/7U7LVyo17lhNfEf2 qGI9JhtU20B5zUPOg6MTYHd2LAoqxmheIp59c+cPDgpERDE+fq1e+RhIwDPX7y54dyE1 GwLISUwerl8nMTA2tcj8n5n62XDwUHuywuTYEcmMXnsC2YWz9akTC7tWcLv4hVaOYisM XL98mP0P1Mjf7woQm/NWiNtUXxCS6rerNf/m18nIMUCBC0XscVLLPjm5KSWUvTzXLUSo SXsD3ZHFl/jhkcHWeCrTubqC0Meka5II7vTCBuXh+sLJWrNFafHQw6nL27S1dodk6TH2 8Rjw== MIME-Version: 1.0 Received: by 10.50.202.105 with SMTP id kh9mr7174990igc.68.1335199973059; Mon, 23 Apr 2012 09:52:53 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.42.76.7 with HTTP; Mon, 23 Apr 2012 09:52:52 -0700 (PDT) In-Reply-To: <024b01cd1dc9$61299700$237cc500$@augustcellars.com> References: <024b01cd1dc9$61299700$237cc500$@augustcellars.com> Date: Mon, 23 Apr 2012 12:52:52 -0400 X-Google-Sender-Auth: JxFByDicpbHmBSs4KqqylcSA2JA Message-ID: From: Adam Langley To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Draft for serializing DNSSEC chains X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:52:54 -0000 On Wed, Apr 18, 2012 at 9:11 PM, Jim Schaad wrote: > In another context I am looking at using a dane serialization, however on= e > of the things that I don't have a good handle on at the moment is the siz= e > of the serialized chain. =C2=A0I realize that this is highly dependent on= things > like the type of key and number of keys. =C2=A0However did you develop an= y > metrics on the size of chains based on what you did? I think the answer is that it's larger than I would like. ~2KB is about the minimum that you can hope for assuming that you're not a TLD yourself. I think you best bet is to grab the (somewhat rough) tools [1] and play around. [1] https://github.com/agl/dnssec-tls-tools Cheers AGL From stpeter@stpeter.im Mon Apr 23 14:30:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B4621E800F; Mon, 23 Apr 2012 14:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr+HjJNRepJ6; Mon, 23 Apr 2012 14:30:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B11B011E808C; Mon, 23 Apr 2012 14:30:52 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7825C40058; Mon, 23 Apr 2012 15:45:22 -0600 (MDT) Message-ID: <4F95CA0B.8050202@stpeter.im> Date: Mon, 23 Apr 2012 15:30:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Apr 2012 21:30:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a supplemental AppsDir review of draft-ietf-dane-protocol (for background on AppsDir, please see ). Although Murray Kucherawy has already reviewed this I-D on behalf of the AppsDir, folks in the Applications Area realize that wide deployment of the TLSA Resource Record might have a significant impact on applications, so we are performing additional reviews. Please treat these comments just as you would any other Last Call feedback. Document: draft-ietf-dane-protocol Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)" Reviewer: Peter Saint-Andre Review Date: 2012-04-23 IETF Last Call Date: 2012-04-25 IESG Telechat: not yet scheduled Summary: This draft is almost ready for publication as an Standards Track RFC but has a few issues that should be fixed before publication. Major Issue: This document does not mention that TLSA records cannot be used directly in application protocols that depend on SRV (or NAPTR or similar technologies). Although I realize that the DANE WG decided, after much discussion, that the interaction between TLSA records and SRV records is out of scope for this specification (and I do not mean to reopen that discussion now), it would be very helpful for this specification to reflect the results of that discussion. Although I make specific suggestions regarding text under the Minor Issues below, in general I think this document needs to be clearer about the assumptions it has made in this regard; in fact, it seems to me that an explicit applicability statement is warranted to avoid confusion of the kind that Dave Cridland experienced (see his Last Call comments). Absent such an applicability statement, it would be good to state up front something that currently is not made explicit until the first sentence of the Security Considerations: The security of the DNS RRtype described in this document relies on the security of DNSSEC as used by the client requesting A/AAAA and TLSA records. The import of "and" in that sentence is significant, and needs to be highlighted earlier in the specification. Minor Issues: 1. In Section 1.2, these sentences might involve a slight oversimplication: A TLS client begins a connection by exchanging messages with a TLS server. It looks up the server's name using the DNS to get an Internet Protocol (IP) address associated with the name. It then begins a connection to a client-chosen port at that address, and sends an initial message there. 1a. The second sentence might be construed as requiring only one step (look up the name, get an IP address), whereas we know that sometimes multiple steps are involved (think SRV). I'd be more comfortable if we added a clause at the end along the lines of "sometimes via multiple steps". 1b. The term "client-chosen port" makes it sound as if the client can choose any port it pleases when connecting to the TLS server. Yet typically the port is derived from a URI, "hardcoded" into the application protocol (sometimes as a fallback), or discovered via the DNS (again, think SRV). We needn't reflect those alternatives in the text, but at the least "appropriate" is better than "client-chosen". 2. In Section 1.3, it is said that "This document only applies to PKIX [RFC5280] certificates, not certificates of other formats." Does this mean that a new RR type would need to be defined to handle other formats (e.g., PGP as in RFC 6091), or only that documents defining how to use TLSA records with those other formats would need to define new values for the Certificate Usage field? Please clarify. 3. In Section 1.3, the following paragraph is true only for application protocols that do not make use of SRV or similar technologies: This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be be protected by DNSSEC. Because the certificate association was retrieved based on a DNS query, the domain name in the query is by definition associated with the certificate. For example, in the case of XMPP the application client might discover through a DNS SRV lookup that the XMPP service for example.com is actually provided at im.example.net. In this case, the domain name in the certificate presented by the TLS server (im.example.net) is not the same as the certificate discovered via the DNS TLSA lookup (example.com), so we can't simply stipulate that "the domain name in the query is by definition associated with the certificate". Here again that applicability statement would be helpful, because this document assumes that you're connecting to the IP address that you discover by means of DNS A/AAAA lookup on the domain name contained in the prefixed DNS domain name defined in Section 3. (As noted, this is made explicit in the first sentence of the Security Considerations.) 4. In Section 2.2, the term "whitespace" is underspecified. Does that include, say, any Unicode space separator (Unicode General Category Zs) or also line separators (Unicode General Category Zl) or only certain code points in the ASCII range? Further, is the whitespace significant in the examples from Section 2.3? 5. To those of us accustomed to SRV records, at first glance the prefixed DNS domain name format defined in Section 3 looks strange: why not _http._tcp.www.example.com instead of _443._tcp.www.example.com? But when we take off our SRV-colored glasses and realize that DANE assumes a DNS A/AAAA lookup on the domain name, it all makes sense. Perhaps it would be helpful to mention the reasoning behind the port number (instead of application name) here? 6. In section 4, no mention is made of the application service that the TLS expects to encounter at the TLS server: The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query. Yet surely the application protocol can matter here, no? In particular, given that 443 is the one true port, we know that folks might run non-HTTP applications over that port (for evil reasons, of course). Does DANE elide over the application protocol because we simply assume that the "right" service is being served over any particular port? What about service providers that wish to restrict the usage of a certificate to a particular application service type (cf. RFC 6125)? Or do we assume that it is enough to differentiate among application services based on the underlying transport (as seems to be the case in the text on "Multiple Ports" in Section 5)? IMHO we have a bit of a muddle here. 7. The paragraph about SSL proxies in Section 8 says that "the TLS client will get a certificate association from the DNS that will not match the certificate that the SSL proxy uses with the client"; however, if the SSL proxy is working in concert with an external DNS validator, is it possible to mimic the behavior of current SSL proxies? Nits: 1. In Section 1.1, I suggest changing "using encryption" to "using channel encryption" (since TLS uses connection-oriented encryption methods, not object encryption). 2. Section 1.1, uses the term "subdomain" in the sentence "This prevents an untrustworthy signer from compromising anyone's keys except those in their own subdomains." The term "subdomain" is not always well understood. I suggest explicitly citing Section 3.1 of RFC 1034 here. 3. In Section 1.3, the phrase "the domain name where the data is found" makes it sound as if DANE applies only to application protocols that involve data retrieval, whereas we know it can be used also for technologies that involve communication (email, IM, etc.). I suggest "the domain name for the relevant application service" or somesuch. 4. In Section 1.3, I suggest changing "server" (which might be confused with the TLS server itself) to "service" or "application service" in this sentence: "A DNS query can return multiple certificate associations, such as in the case of a server is changing from one certificate to another." Typo: "have lead" should be "have led". Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VygoACgkQNL8k5A2w/vxyDwCfTTdHCQ1Vo/gHdumTbLGD8gP+ xJwAn0SQ1CkXK3t/38rWE881tc6ZbySt =ZnZX -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Apr 24 09:20:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98821E8034; Tue, 24 Apr 2012 09:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlEa22j8zlfR; Tue, 24 Apr 2012 09:20:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E51F421E8027; Tue, 24 Apr 2012 09:19:56 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 21B1C40058; Tue, 24 Apr 2012 10:34:29 -0600 (MDT) Message-ID: <4F96D2AB.6090509@stpeter.im> Date: Tue, 24 Apr 2012 10:19:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4F96D157.7020504@isode.com> <4F96D21A.7080006@isode.com> In-Reply-To: <4F96D21A.7080006@isode.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Apr 2012 16:20:05 -0000 On 4/24/12 10:17 AM, Alexey Melnikov wrote: > On 24/04/2012 17:14, Alexey Melnikov wrote: >> Document: draft-ietf-dane-protocol >> Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol >> for Transport Layer Security (TLS)" >> Reviewer: Peter Saint-Andre > And now I even pretend to be Peter ;-). Heh. :) Alexey, overnight I realized that this document doesn't say anything about internationalized domain names (in fact, it doesn't cite any documents about the definition of "DNS domain name"). So I think at the least it needs to provide a citation, e.g. to Section 2.2 of RFC 6125. Peter -- Peter Saint-Andre https://stpeter.im/ From alexey.melnikov@isode.com Tue Apr 24 09:14:01 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0543821F87D8; Tue, 24 Apr 2012 09:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijVfdIg0D9MY; Tue, 24 Apr 2012 09:14:00 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id E644921F87C6; Tue, 24 Apr 2012 09:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335284038; d=isode.com; s=selector; i=@isode.com; bh=tuK+87IdECyx8g1ceSSw87kIOH54xvLgX2zRQoz7GuM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=awuhaqwUM+WUlTXuD7TVYmc4P40mXUjdGP4m5lUoDpG+zwnFwkIlJXWPIxAcUuGDwpjqLU AumbpMDW1TAB6WT58ZDiY+uo1ILrIqybL+9GDJjdZchx27hZS0M2o87pG9LlXYM0SCEdoF L5+P9oPa5YdMeXjIZQGTzqJZgQDEZT4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Apr 2012 17:13:58 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F96D157.7020504@isode.com> Date: Tue, 24 Apr 2012 17:14:15 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2012 10:00:28 -0700 Subject: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Apr 2012 16:14:01 -0000 This is a supplemental AppsDir review of draft-ietf-dane-protocol (for background on AppsDir, please see ). Although Murray Kucherawy has already reviewed this I-D on behalf of the AppsDir, folks in the Applications Area realize that wide deployment of the TLSA Resource Record might have a significant impact on applications, so we are performing additional reviews. Please treat these comments just as you would any other Last Call feedback. Document: draft-ietf-dane-protocol Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)" Reviewer: Peter Saint-Andre Review Date: 2012-04-24 IETF Last Call Date: 2012-04-25 IESG Telechat: not yet scheduled Summary: This draft is almost ready for publication as an Standards Track RFC but has a few issues that should be fixed before publication. Major Issue: none, although a) I am agreeing with Peter Saint-Andre's major issue and b) I would like to see a reply to my minor issues Minor Issues: 2.2. TLSA RR Presentation Format The presentation format of the RDATA portion is as follows: Presentation for what purpose? In management UIs? Is this a required presentation format for DNS tools that can retrieve and update TLSA records? [...] o The certificate association data field MUST be represented as a string of hexadecimal characters. Whitespace is allowed within the string of hexadecimal characters. Please define what you mean by whitespace here? CR & LFs allowed? Examples in the Section 2.3 seem to suggest that. 3. Domain Names for TLS Certificate Associations 2. The protocol name of the transport on which a TLS-based service is assumed to exist is prepended with an underscore character ("_") to become the second left-most label in the prepared domain name. The transport names defined for this protocol are "tcp", "udp" and "sctp". DCCP? Should there be a registry? 4. Use of TLSA Records in TLS Section 2.1 of this document defines the mandatory matching rules for the data from the TLSA certificate associations and the certificates received from the TLS server. The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query. So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec? Nits: 4. Use of TLSA Records in TLS If a TLSA record has usage type 2 for the certifcate, the typo: certificate corresponding TLS server SHOULD send the certificate that is referenced just like it currently sends intermediate certificates. If an application receives zero usable certificate associations from a DNS request or from its cache, it processes TLS in the normal fashion without any input from the TLSA records. Just to double check: if TLS client receives some TLSA records, but none of them are usable, is this considered to be the above case? If an application receives one or more usable certificate associations, it attempts to match each certificate association with the TLS server's end entity certificate until a successful match is found. During the TLS handshake, if none of the certificate associations matches the certificate given by the TLS server, the TLS client MUST abort the handshake. From alexey.melnikov@isode.com Tue Apr 24 09:17:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CB621F87C7; Tue, 24 Apr 2012 09:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HoZQB5qw0pS; Tue, 24 Apr 2012 09:17:15 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id F24DB21F87AD; Tue, 24 Apr 2012 09:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335284233; d=isode.com; s=selector; i=@isode.com; bh=sN7LUjIo85qtxOah+S/acw6ya4/AiEw+VHGaswzrK98=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qO5UZhmivK4hlBrqV0VdxxVj9XOrXWdE6a7BcxIa3qDXdpra3qII9bg1PDyx+us2eAr8Oj +p3KthTsbwEIUMVrosh4OR3FO6NnmKvXmSO/HCDdUtKLEA837hVOMJ164xWnR+XMiKJ6kc /K0dKpIPFa6Bg7zb59EqC6US+9mn5PI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 24 Apr 2012 17:17:13 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F96D21A.7080006@isode.com> Date: Tue, 24 Apr 2012 17:17:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org References: <4F96D157.7020504@isode.com> In-Reply-To: <4F96D157.7020504@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2012 10:00:29 -0700 Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Apr 2012 16:17:16 -0000 On 24/04/2012 17:14, Alexey Melnikov wrote: > Document: draft-ietf-dane-protocol > Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol > for Transport Layer Security (TLS)" > Reviewer: Peter Saint-Andre And now I even pretend to be Peter ;-). > Review Date: 2012-04-24 > IETF Last Call Date: 2012-04-25 > IESG Telechat: not yet scheduled From Jeff.Hodges@KingsMountain.com Tue Apr 24 15:23:30 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E001D21F8633 for ; Tue, 24 Apr 2012 15:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxrN6pzvBG67 for ; Tue, 24 Apr 2012 15:23:30 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 04B1521F862F for ; Tue, 24 Apr 2012 15:23:29 -0700 (PDT) Received: (qmail 29038 invoked by uid 0); 24 Apr 2012 22:23:26 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 24 Apr 2012 22:23:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=PCnnySLteKKUFiyEe5zLNWnqhPPTwjNboC5FZ/SWGUg=; b=Uk2DRvmd73F8PGBZbrLufugIuEio2SiKiRBu71qgfXVPLazod8oRqpOPklywU2z/gSXFiwcOwvtn7cYp+uVmWGW3Elu6Wbiag4nacLkfn1uFUl0K8W0yqgFh3mlPCnb1; Received: from 70-88-131-174-washingtondc.hfc.comcastbusiness.net ([70.88.131.174] helo=[10.128.214.186]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SMo8r-0006jJ-Qw; Tue, 24 Apr 2012 16:23:26 -0600 Message-ID: <4F9727DB.5060601@KingsMountain.com> Date: Tue, 24 Apr 2012 15:23:23 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list , IETF Discussion List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.88.131.174 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] Last Call: - Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 24 Apr 2012 22:23:31 -0000 [ these are excerpts from a current thread on dane@ that I'm now denoting as an IETF-wide Last Call comment ] Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700: > > On Apr 20, 2012, at 10:50 AM, =JeffH wrote: > >> Various specs are going to have need to refer to the DANE protocol >> specification a well as describe the notion of domain names that map to >> TLSA records describing certificate associations. >> >> In working on such language in draft-ietf-websec-strict-transport-sec, >> here's the terms I'm using at this time and their (contextual) meaning.. >> >> DANE protocol >> The protocol specified in draft-ietf-dane-protocol (RFC# tbd). >> > > There is an issue here that we haven't dealt with, which is that "DANE > protocol" doesn't really make sense because we might be adding additional > protocols for certificate associations for things other than TLS. For your > doc, you should be saying "TLSA protocol", not "DANE protocol" because HSTS > is specific to TLS. (More below.) After further perusal of draft-ietf-dane-protocol-19, if I understand correctly, the term "DANE" (and its expansion) names a class of Secure DNS-based cert/key-to-domain-name associations, and protocols for particular instances will nominally be assigned their own names, where a case-in-point is the "TLSA Protocol", yes=? i.e. we could define another separate spec for mapping Foo protocol's keys/certs to DNS RRs, and call 'em FOOA, and then in following this naming approach, refer to the protocol of using them while establishing Foo connections as the "FOOA protocol", yes? Paul Hoffman further explained on Sat, 21 Apr 2012 13:38:38 -0700: > > On Apr 20, 2012, at 3:34 PM, =JeffH wrote: >> >> Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700: >> >> > On Apr 20, 2012, at 10:50 AM, =JeffH wrote: >> > >> > There is an issue here that we haven't dealt with, which is that "DANE >> > protocol" doesn't really make sense because we might be adding additional >> > protocols for certificate associations for things other than TLS. >> >> Yep. "DANE" is a working group name. But, I was working from the >> specification name per the present spec. >> >> > ... >> > Proposal for [-dane-protocol] spec: >> > >> > The protocol in this document can generally be referred to as the "TLSA >> > protocol". >> >> So as a practical matter, if we wish to refer to this particular spec as >> defining the "TLSA protocol", then perhaps the spec title should reflect >> that such that the RFC Index is searchable for that "TLSA" term. > > The WG already decided against that (unfortunately). I agree it is unfortunate and respectfully suggest that this decision be revisited. Many (most?) people have been referring to the protocol being worked on by the working group (which is now draft-ietf-dane-protocol) as "the DANE protocol" or simply "DANE" for as long as the WG has been formed, /plus/, the present title of spec is.. The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS) I think it will just continue to unnecessarily sow confusion if the term "TLSA" doesn't somehow get into the spec title and thus into the various RFC indexes (whether or not the suggested statement above explicitly naming the protocol "TLSA protocol" is added to the spec (I think it should be added)). Ways to accomplish addressing the spec title issue could be.. TLSA: The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS) ..or.. The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS): TLSA HTH, =JeffH From marka@isc.org Wed Apr 25 01:31:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB05021F8620; Wed, 25 Apr 2012 01:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUsFHnoU96Cj; Wed, 25 Apr 2012 01:31:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 98D0A21F85FC; Wed, 25 Apr 2012 01:31:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 760FB5F9915; Wed, 25 Apr 2012 08:31:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d0ee:8b9f:40c6:edea]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6FDE6216C31; Wed, 25 Apr 2012 08:31:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B12E11FE9A17; Wed, 25 Apr 2012 18:30:59 +1000 (EST) To: Alexey Melnikov From: Mark Andrews References: <4F96D157.7020504@isode.com> In-reply-to: Your message of "Tue, 24 Apr 2012 17:14:15 +0100." <4F96D157.7020504@isode.com> Date: Wed, 25 Apr 2012 18:30:59 +1000 Message-Id: <20120425083059.B12E11FE9A17@drugs.dv.isc.org> Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 08:31:24 -0000 In message <4F96D157.7020504@isode.com>, Alexey Melnikov writes: > This is a supplemental AppsDir review of draft-ietf-dane-protocol (for > background on AppsDir, please see > ). > > Although Murray Kucherawy has already reviewed this I-D on behalf of > the AppsDir, folks in the Applications Area realize that wide > deployment of the TLSA Resource Record might have a significant impact > on applications, so we are performing additional reviews. Please treat > these comments just as you would any other Last Call feedback. > > Document: draft-ietf-dane-protocol > Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol > for Transport Layer Security (TLS)" > Reviewer: Peter Saint-Andre > Review Date: 2012-04-24 > IETF Last Call Date: 2012-04-25 > IESG Telechat: not yet scheduled > > > Summary: This draft is almost ready for publication as an Standards > Track RFC but has a few issues that should be fixed before publication. > > > Major Issue: none, although a) I am agreeing with Peter Saint-Andre's > major issue and b) I would like to see a reply to my minor issues > > Minor Issues: > > 2.2. TLSA RR Presentation Format > > The presentation format of the RDATA portion is as follows: > > Presentation for what purpose? In management UIs? Is this a required > presentation format for DNS tools that can retrieve and update TLSA records? DNS management tools could get away with using RFC 3597. > [...] > > o The certificate association data field MUST be represented as a > string of hexadecimal characters. Whitespace is allowed within > the string of hexadecimal characters. > > Please define what you mean by whitespace here? CR & LFs allowed? > Examples in the Section 2.3 seem to suggest that. They are allowed. See RFC 1035, Section 5.1. ( ) Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses. > 3. Domain Names for TLS Certificate Associations > > 2. The protocol name of the transport on which a TLS-based service > is assumed to exist is prepended with an underscore character > ("_") to become the second left-most label in the prepared domain > name. The transport names defined for this protocol are "tcp", > "udp" and "sctp". > > DCCP? Should there be a registry? > > 4. Use of TLSA Records in TLS > > Section 2.1 of this document defines the mandatory matching rules for > the data from the TLSA certificate associations and the certificates > received from the TLS server. > > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. > > So this will not work for any type of DNS indirection mechanism, such as > MX, SRV, etc? Or does DNS retrieval of such records also requires DNSSec? NAPTR, SRV, MX, CNAME, DNAME all potentially change/define the expected name. Whether they do or not is protocol specific not record specific. If the record changes/defines the expected name then the record should be signed or one is vulnerable to DNS based attacks. NAPTR, SRV, MX, CNAME, DNAME can be encountered when trying to determine the TLSA's lookup name. CNAME and DNAME can also be encountered as part of the TLSA lookup itself. In the case the CNAME / DNAME MUST be signed or you can't trust the TLSA. > Nits: > > 4. Use of TLSA Records in TLS > > If a TLSA record has usage type 2 for the certifcate, the > > typo: certificate > > corresponding TLS server SHOULD send the certificate that is > referenced just like it currently sends intermediate certificates. > > > If an application receives zero usable certificate associations from > a DNS request or from its cache, it processes TLS in the normal > fashion without any input from the TLSA records. > > Just to double check: if TLS client receives some TLSA records, but none > of them are usable, is this considered to be the above case? > > If an application > receives one or more usable certificate associations, it attempts to > match each certificate association with the TLS server's end entity > certificate until a successful match is found. During the TLS > handshake, if none of the certificate associations matches the > certificate given by the TLS server, the TLS client MUST abort the > handshake. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Wed Apr 25 05:48:08 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2021F86AA; Wed, 25 Apr 2012 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff0QcKdh1D4n; Wed, 25 Apr 2012 05:48:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA2FC21F86A3; Wed, 25 Apr 2012 05:48:07 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so51135obb.31 for ; Wed, 25 Apr 2012 05:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5gfLO1xtmClin1IgXjbWyRvPg1R6nGuzrh6U+PaqP9M=; b=fGlrnPIFBhtvY8ei0kWs9rLEESSQJdZTluqeX9Fw4QCrZoYjOmt0i9BGQuzukcnMoK ybPmCORbApEdeVPqhMi/6X2A5KlddDxXX8EaqyP0hYJIJIOTRRtfstrxxzd/NjZPcwbi jr0qwRV+tjRXkC7VEq5dJ41tyimRbfL6weeW1YWW14O52YPeD/88oGXMVDO6NRJS1ZgQ WfBiUbw3jZE7Ytk3Tt8Xt3AYNUC4Lj7TUjINmqIgJI2NjPpy3GZBBLJI1A9p0LK/1sCL +KYFR/v1OSMvr9MCFW5lXi1UTi7pMsLvpu469hPYCWxSkXJU2BCaYm5RSyasXVqv/o6F H3kg== MIME-Version: 1.0 Received: by 10.182.51.9 with SMTP id g9mr2917347obo.56.1335358087415; Wed, 25 Apr 2012 05:48:07 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Wed, 25 Apr 2012 05:48:07 -0700 (PDT) In-Reply-To: <4F9727DB.5060601@KingsMountain.com> References: <4F9727DB.5060601@KingsMountain.com> Date: Wed, 25 Apr 2012 08:48:07 -0400 Message-ID: From: Phillip Hallam-Baker To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion List , IETF DANE WG list Subject: Re: [dane] Last Call: - Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 12:48:09 -0000 +1 The name should reflect the final product, not the path taken to get there. If people were to use these records then they would see them in the DNS zone and see them listed as TLSA and look for an RFC with that name. Only the people who were involved in the group would know that DANE and TLSA are the same thing. On Tue, Apr 24, 2012 at 6:23 PM, =3DJeffH w= rote: > [ these are excerpts from a current thread on dane@ that I'm now denoting= as > an IETF-wide Last Call comment ] > > Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700: >> >> On Apr 20, 2012, at 10:50 AM, =3DJeffH wrote: >> >>> Various specs are going to have need to refer to the DANE protocol >>> specification a well as describe the notion of domain names that map to >>> TLSA records describing certificate associations. >>> >>> In working on such language in draft-ietf-websec-strict-transport-sec, >>> here's the terms I'm using at this time and their (contextual) meaning.= . >>> >>> DANE protocol >>> =A0 The protocol specified in draft-ietf-dane-protocol (RFC# tbd). >>> >> >> There is an issue here that we haven't dealt with, which is that "DANE >> protocol" doesn't really make sense because we might be adding additiona= l >> protocols for certificate associations for things other than TLS. For yo= ur >> doc, you should be saying "TLSA protocol", not "DANE protocol" because >> HSTS >> is specific to TLS. (More below.) > > > After further perusal of draft-ietf-dane-protocol-19, if I understand > correctly, the term "DANE" (and its expansion) names a class of Secure > DNS-based cert/key-to-domain-name associations, and protocols for particu= lar > instances will nominally be assigned their own names, where a case-in-poi= nt > is the "TLSA Protocol", yes=3D? > > i.e. we could define another separate spec for mapping Foo protocol's > keys/certs to DNS RRs, and call 'em FOOA, and then in following this nami= ng > approach, refer to the protocol of using them while establishing Foo > connections as the "FOOA protocol", yes? > > > > Paul Hoffman further explained on Sat, 21 Apr 2012 13:38:38 -0700: >> >> On Apr 20, 2012, at 3:34 PM, =3DJeffH wrote: >>> >>> Paul Hoffman replied on Fri, 20 Apr 2012 13:57:28 -0700: >>> >>> > On Apr 20, 2012, at 10:50 AM, =3DJeffH wrote: >>> > >>> > There is an issue here that we haven't dealt with, which is that "DAN= E >>> > protocol" doesn't really make sense because we might be adding >>> > additional >>> > protocols for certificate associations for things other than TLS. >>> >>> Yep. "DANE" is a working group name. But, I was working from the >>> specification name per the present spec. >>> >>> > ... >>> > Proposal for [-dane-protocol] spec: >>> > >>> > The protocol in this document can generally be referred to as the "TL= SA >>> > protocol". >>> >>> So as a practical matter, if we wish to refer to this particular spec a= s >>> defining the "TLSA protocol", then perhaps the spec title should reflec= t >>> that such that the RFC Index is searchable for that "TLSA" term. >> >> The WG already decided against that (unfortunately). > > > I agree it is unfortunate and respectfully suggest that this decision be > revisited. > > Many (most?) people have been referring to the protocol being worked on b= y > the working group (which is now draft-ietf-dane-protocol) as "the DANE > protocol" or simply "DANE" for as long as the WG has been formed, /plus/, > the present title of spec is.. > > =A0The DNS-Based Authentication of Named Entities (DANE) Protocol for > =A0Transport Layer Security (TLS) > > > I think it will just continue to unnecessarily sow confusion if the term > "TLSA" doesn't somehow get into the spec title and thus into the various = RFC > indexes (whether or not the suggested statement above explicitly naming t= he > protocol "TLSA protocol" is added to the spec (I think it should be added= )). > > > Ways to accomplish addressing the spec title issue could be.. > > =A0TLSA: The DNS-Based Authentication of Named Entities (DANE) Protocol f= or > =A0Transport Layer Security (TLS) > > > ..or.. > > =A0The DNS-Based Authentication of Named Entities (DANE) Protocol for > =A0Transport Layer Security (TLS): TLSA > > > HTH, > > =3DJeffH > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Apr 25 06:52:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4E021F86D3; Wed, 25 Apr 2012 06:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw-Om30m8Jy2; Wed, 25 Apr 2012 06:52:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE23D21F86D0; Wed, 25 Apr 2012 06:52:39 -0700 (PDT) Received: by yenm5 with SMTP id m5so111093yen.31 for ; Wed, 25 Apr 2012 06:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gmADjTnB38xWmc4JBympn8e/3omp1h/Qfb8X6sjCrr0=; b=GPnBY0g2pK3NlOlsF7dpD/F3NCml6f1Znqn3kI1vk+b2Fh7adrrRA/Rcse2g4va4Ws aYg5L6kH1sd2gNdULq2hKW1HCWFF2pjtSMvcm/ql+hwpx9SDWCXhgkXZsdVELXgMO/tx J/ivqASR6wCJegwPDNV+HD8cBIcSP46VUyB1eVH7chgwnQirJ3WrUBImP/dykW6RVqhI +eBDvK5EOSr3e4OOBC4G2f9TALktIWJhJZhlHBvpt2wit8Ejei6StMmfhW6SbjQXbYMK 3QpLn583I3KjCWI5HQ8Pdta/HQ0KL7UdU/TumlCcHO0OsDVark4OV5ZMnwODJnrdQqJp oinQ== MIME-Version: 1.0 Received: by 10.60.27.7 with SMTP id p7mr3559386oeg.56.1335361959474; Wed, 25 Apr 2012 06:52:39 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Wed, 25 Apr 2012 06:52:39 -0700 (PDT) In-Reply-To: <01OE9150IMNI00ZUIL@mauve.mrochek.com> References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> Date: Wed, 25 Apr 2012 09:52:39 -0400 Message-ID: From: Phillip Hallam-Baker To: ietf@ietf.org, dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 13:52:41 -0000 I have raised these comments in the WG numerous times, I am raising them here as I do not believe that anyone is going to implement the specification as currently described. As currently written, the specification attempts to mandate client behavior when DANE records are encountered in ways that are outside the scope of interoperability. While the objective of the authors is to mandate certain behavior they consider necessary for security reasons, what they end up doing is attempting to substitute their own judgement for that of the security experts who advise the client providers. Client providers already ignore significant parts of the PKIX specification because they do not meet their performance criteria. In particular virtually all browsers treat inability to obtain OCSP certificate status as being equivalent to 'good'. This is a terrible security design, one that every CA would like to see change. But it is also a fact that we have been trying to get this changed for ten years without success. The browser providers do not hard fail on OCSP because doing so would require them to wait for the OCSP response within the TLS handshake and this is considered an unacceptable performance degradation. I do not like this situation, but I can either play Canute and tell the tide to turn or I can consider it to be a fact and try to work round it. DANE attempts to fix PKI with another mandate that is certain to be ignored. In this case the mandate is to establish a critical dependency on the DNSSEC trust chain despite the easily observed fact that less than 97% of DNS resolvers will pass anything other than A/AAAA and CNAME records. Section 4 of the draft mandates a client hardfail if the DNSSEC trust chain cannot be obtained. This is essential if the client is going to use DNSSEC to establish certificate constraints just as certificate revocation is an essential part of the PKIX model. But no browser provider can expect to succeed with a product that simply stops working when the user tries to surf the Web from a coffee shop. Since the coffee shop problem is not intentional we might imagine that it will eventually go away. But this puts DANE in a deployment deadlock bind. Nobody is going to fix their coffee shop routers until there is a need to and that need won't exist until the coffee shop routers are fixed. It is not just coffee shops that are the problem either. It might seem really easy to put an SSL cert on a server and keep it up to date but IETF participants represent the 1% of network admins. We all know from experience how successful protocols that require two sets of records to be kept in sync are. A protocol that requires a network admin to remember to update their DNS with each cert change or suffer a hardfail is going to have a very high administrative error rate. Rather than mandating hardfail or any particular client behavior, the specification should simply state that the client MUST conclude that the DANE status of the certificate is invalid and then leave the client to decide on what course of action to take. This will depend on the circumstances of the particular user and the client provider's assessment of the reliability of the DANE data and might range from do nothing to send a security policy violation notification somewhere to hardfail. Contrary to the assumptions of the specification authors, hard fail is not the best option. It is not even the best option in the case that the users are dissidents. To understand the logic of the dissident case it is important to have a change of perspective. The objective of the authorities is not to intimidate a single protester, it is to intimidate a whole country. Being a protester carries inevitable risks. No security protocol is going to eliminate those risks for the individual. What is important is to minimize the risk for the population as a whole. The Google cert pinning code did not provide much direct protection to the Iranian dissidents because it only covered one site. But it proved critical in exposing the Diginotar situation because it provided the first evidence of the breach. Had the client been designed slightly differently the breach might have become evident earlier. The coffee shop issue is unintended but there are also parties that are going to intentionally sabotage any infrastructure that looks like DANE. We are not in the 1990s any longer, people in authority no longer expect OSI to replace the Internet. The result is that it is much harder to get away with no infrastructure. At present there is no point in blocking DNSSEC records. But you can be sure that Iran, Russia and China will be doing so the minute any client started to make use of DANE. These countries can (and will) make use of a client hard fail to ensure that people don't use browsers that might be used for 'information terrorism' or freedom of speech as the rest of us call it. And don't think that out own governments necessarily mean what they say. In public Thatcher was a stalwart champion of freedom. In private she was begging Gorbachev to send in the tanks to stop the fall of the Berlin wall. Her own foundation has materials that report this exchange: http://www.margaretthatcher.org/document/112006 The last thing I want to do is to hand the authorities another tool that can be used to selectively shut down the network at the critical moment in a crisis. Completely shutting off the Internet is one thing, it probably worked in our favor in Egypt as the 101st keyboarders lost their Internet connection and were forced to find out what was going on in the streets. It was a visceral sign of panic on the part of the regime. DANE is really a form of security policy information and so far there is no case where we have succeeded in applying raw security policy information at the client end. DKIM policies are a success because they are filtered and interpreted by the anti-spam services. There is a huge infrastructure in place that is working to apply the data from the DKIM records intelligently and equally importantly provides feedback to publishers of inconsistent records. DANE is proposed on the basis of a mistaken interpretation of how DKIM security policies work in practice and the result is a protocol that is deeply flawed and likely to fail. It would be a pity if the lack of success of a group that has steadfastly worked to ignore and discourage outside advice became a precedent to avoid future security policy efforts. Security policy is a very powerful tool, one that we can and must use if we are going to make the insecure Internet secure. But the DANE approach is too dogmatic to succeed. From ajs@anvilwalrusden.com Wed Apr 25 08:15:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8A21F875A; Wed, 25 Apr 2012 08:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhYfwqC2nLeG; Wed, 25 Apr 2012 08:15:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28F21F8736; Wed, 25 Apr 2012 08:15:21 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9DE791ECB41C; Wed, 25 Apr 2012 15:15:20 +0000 (UTC) Date: Wed, 25 Apr 2012 11:15:18 -0400 From: Andrew Sullivan To: ietf@ietf.org Message-ID: <20120425151518.GC60024@mail.yitter.info> References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.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) Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 15:15:22 -0000 On Wed, Apr 25, 2012 at 09:52:39AM -0400, Phillip Hallam-Baker wrote: > dependency on the DNSSEC trust chain despite the easily observed fact > that less than 97% of DNS resolvers will pass anything other than > A/AAAA and CNAME records. I'm having a hard time understanding that sentence. Could you clarify, please: A. Fewer than 97% of DNS resolvers can pass anything other than A/AAAA and CNAME, which means something more than 3% of resolvers pass only A/AAAA and CNAME. This is what I _think_ you mean, which means that n% > broken resolvers > 3%, right? If so, I'd like a citation, though it doesn't sound wrong to me. That we'd have something on the order of 3% of the software deployed everywhere on the Internet be broken ought to be completely unsurprising. B. 97% of the DNS resolvers is the most that has ever been observed working according to specification, and the number may be much lower. This is the rhetorical point I think might be read in. In this case, I think a citation is in order. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul@nohats.ca Wed Apr 25 08:48:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DE621F871E; Wed, 25 Apr 2012 08:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVD1YSVSmElu; Wed, 25 Apr 2012 08:47:54 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 955AD21F865D; Wed, 25 Apr 2012 08:47:54 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id AABCB8036B; Wed, 25 Apr 2012 11:47:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id A0FC68033B; Wed, 25 Apr 2012 11:47:53 -0400 (EDT) Date: Wed, 25 Apr 2012 11:47:53 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 15:48:01 -0000 On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote: > The browser providers do not hard fail on OCSP because doing so would > require them to wait for the OCSP response within the TLS handshake > and this is considered an unacceptable performance degradation. And with the current ocsp.entrust.net issue, that would be a two day performance degradation? There is also the privacy issue. But all of this is off-topic. > Section 4 of the draft mandates a client hardfail if the DNSSEC trust > chain cannot be obtained. This is essential if the client is going to > use DNSSEC to establish certificate constraints just as certificate > revocation is an essential part of the PKIX model. But no browser > provider can expect to succeed with a product that simply stops > working when the user tries to surf the Web from a coffee shop. hotspot detection for temporal DNS failure/spoofing mode is what browsers need to support/implement. It is no different then the fix they needed when we opened our browser at a coffee shop and all tabs destroyed themselves reloading into hotspot login pages. > Since the coffee shop problem is not intentional we might imagine that > it will eventually go away. But this puts DANE in a deployment > deadlock bind. Nobody is going to fix their coffee shop routers until > there is a need to and that need won't exist until the coffee shop > routers are fixed. I suggest you run with dnssec-trigger software for a while and then come back to this assertion. We do not need coffeeshops to fix anything, we need better DNSSEC integration on our laptops and phones. > Rather than mandating hardfail or any particular client behavior, the > specification should simply state that the client MUST conclude that > the DANE status of the certificate is invalid and then leave the > client to decide on what course of action to take. This will depend on > the circumstances of the particular user and the client provider's > assessment of the reliability of the DANE data and might range from do > nothing to send a security policy violation notification somewhere to > hardfail. In all IETF protocols, there is the "local policy overrides", yet we don't add it specifically to every MUST in the protocol documents. Additionally, the browser can fail the connection and terminate the TLS and provide the user some feedback with a local policy override, and then the brower complies to both the hard fail requirement, and your 'too big too fail' argument. > Contrary to the assumptions of the specification authors, hard fail is > not the best option. It is not even the best option in the case that > the users are dissidents. Tell that to the chrome users in Iraq that are still alive and not in jail getting tortured. If anyone is going to sacrifice the one for the many, I sure as hell hope it won't be protocol designers. > But you can be sure that Iran, > Russia and China will be doing so the minute any client started to > make use of DANE. These countries can (and will) make use of a client > hard fail to ensure that people don't use browsers that might be used > for 'information terrorism' or freedom of speech as the rest of us > call it. Sure. Any data can be blocked. You work around the block with tunneling and then use the actual DANE information for your own protection and safety within the tunnel. Suggesting the block means you might as well not add security in case there is no block, or you can break through it, is wrong. > But the DANE approach is too dogmatic to succeed. All your arguments against dane are equally valid/invalid for OCSP with hard fail, which you seem to be a proponent of. I fail to see the consistency in your reasoning. Paul From Jeff.Hodges@KingsMountain.com Wed Apr 25 09:52:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0506521F86A8 for ; Wed, 25 Apr 2012 09:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPv9K7auMMDQ for ; Wed, 25 Apr 2012 09:52:44 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 3E06E21F863F for ; Wed, 25 Apr 2012 09:52:44 -0700 (PDT) Received: (qmail 24159 invoked by uid 0); 25 Apr 2012 16:52:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 25 Apr 2012 16:52:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=u061eoDjvV9IaoiyFgHSpVA8kvu0eS+NXcZefQxTQ84=; b=5MCqlsJ6BEfvU1vknhliJkTrC3CmYy81FFfivu9ex0FXagMHT2c8ppFCO71Qg6BPCfRwNv9i+uO0/hZRB8cuS5t/IbOzSsxQl0HEhRSDagU3k4bu/AhJ/7zLkoORHrnL; Received: from 70-88-131-174-washingtondc.hfc.comcastbusiness.net ([70.88.131.174] helo=[10.128.214.186]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SN5SN-0002v7-Rw; Wed, 25 Apr 2012 10:52:43 -0600 Message-ID: <4F982BDA.2040003@KingsMountain.com> Date: Wed, 25 Apr 2012 09:52:42 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list , Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.88.131.174 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 16:52:45 -0000 Paul Hoffman replied: >>> We use the term "usable certificate association" in section 4. For your >>> spec, how about: >>> >>> trusted certificate association >>> A certificate association specified in a >>> TLSA record that is determined to be usable in the TLSA spec. >>> >> >> In that case, I'd be inclined to just use "usable cert association" rather >> than redefine it with the qualifier "trusted" (ie, if that's not what the >> -dane-protocol spec defines). >> >> Also, it would be helpful if the term "usable certificate association" is >> explicitly defined in a clearly referenceable manner in -dane-protocol. >> >> This could be done by making that final para of section 4 a titled >> subsection, e.g.. >> >> 4.1 Usable Certificate Association >> >> but since I notice that section 4 is entitled "Use of TLSA Records in TLS" >> it should perhaps be.. >> >> 4.1 Usable TLS Certificate Association > > I like the former. Actually, in re-reading section 4 of -dane-protocol I wouldn't turn that last para into a subsection -- because as you note.. > The definition of what is "usable" goes on for many paragraphs.. Rather, I'd be inclined to add something akin to this to "1.4. Terminology".. Usable TLS Certificate Association A TLS certificate association that has passed all the tests specified in Section 4 "Use of TLSA Records in TLS". there's some other terminological issues I'll send in another msg as a Last Call comment. HTH, =JeffH From Jeff.Hodges@KingsMountain.com Wed Apr 25 11:28:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77CE21F88BD for ; Wed, 25 Apr 2012 11:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxYxhYQpFD7K for ; Wed, 25 Apr 2012 11:28:26 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id EF07F21F8849 for ; Wed, 25 Apr 2012 11:28:25 -0700 (PDT) Received: (qmail 10282 invoked by uid 0); 25 Apr 2012 18:28:24 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 25 Apr 2012 18:28:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=fwSAQeJZHzlk1NArmZ06N5COksn8KWOVl0OoOE/53b0=; b=yr09zILKcQgTLA84bnnrC9ty88lQoKYK7+35huuLwK1oAY030jCbpzCXscczVsyLjQdDhI66Ptma4dPIsJCPsNTp34RHNMMBLjvllDHlJQ30pcWmLYtJFpnvFExkLF92; Received: from 70-88-131-174-washingtondc.hfc.comcastbusiness.net ([70.88.131.174] helo=[10.128.214.186]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SN6wy-0005vY-E5; Wed, 25 Apr 2012 12:28:24 -0600 Message-ID: <4F984246.6060401@KingsMountain.com> Date: Wed, 25 Apr 2012 11:28:22 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF DANE WG list , IETF Discussion List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.88.131.174 authed with jeff.hodges+kingsmountain.com} Subject: Re: [dane] Last Call: X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 18:28:27 -0000 Some additional modest last call comments on draft-ietf-dane-protocol-19... terminological issues --------------------- The "usage" notion has at least five term/phrase variations used in the spec. I found this quite confusing. Here's the variations I find.. usage = usage type = certificate usage = certificate usage type = TLSA Usages I suggest settling on one or two phrases for most all occurances. I suggest using "certificate usage type" in (almost) all cases, and "usage type" perhaps in cases where the bare term "usage" is presently used. To help out, here's an updated TLSA RDATA Wire Format diagram.. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Usage Type | Selector | Matching Type | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / / Certificate Association Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Separately, the term "TLSA certificate association" is used in a few places, and should probably be "TLS certificate association" for consistency. I also found the term "TLSA association" used on pages 22 & 23, which ought to be "TLS certificate association", yes? Section 8.1 introduces the somewhat ambiguous term "DANE client", which is contrasted with "common TLS clients" and "current TLS client". Perhaps "TLSA-aware TLS client" is more appropriate here than "DANE client", especially if this protocol is referred to as the "TLSA protocol"? editorial items --------------- > 1.1. Background of the Problem [ I'd entitle this section "Background and Motivation" ] last para: > DNS-Based Authentication of Named Entities (DANE) offers the option > to use the DNSSEC infrastructure to store and sign keys and > certificates that are used by TLS. If in fact the term "DANE" (and its expansion) names a class of Secure DNS-based cert/key-to-domain-name associations, and protocols for particular instances will nominally be assigned their own names, where a case-in-point is the "TLSA Protocol", then.. s/TLS/security protocols/ ..in the above-quoted sentence. > 1.2 Securing the Association with a Server's Certificate which association is this section title referring to? (it's ambiguous) Suggested more precise section title: "Securing the Association of Domain Name and TLS Server Certificate" > Currently, the client must extract the domain name from the > certificate and must successfully validate the certificate, including > chaining to a trust anchor. I found the above description unnecessarily imprecise, though recognizing the desire to provide only a brief overview here. A suggested modest rewrite: Currently, the client must extract the domain name from the certificate and validate it [RFC6125], and must also successfully validate the certificate, including chaining to a CA's trust anchor [RFC5280]. However, as explained above in Section 1.1, essentially any CA may have issued the certificate for the domain name. > 2. The TLSA Resource Record > > The TLSA DNS resource record (RR) is used to associate a certificate > with the domain name where the record is found. suggested clarification.. The TLSA DNS resource record (RR) is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLS certificate association". Otherwise, "TLS certificate association" is only tacitly defined. > 2.1.1. The Certificate Usage Field > > > A one-octet value, called "certificate usage" or just "usage", > specifies the provided association that will be used to match the > target certificate from the TLS handshake. In the above, as well as two more instances in the paragraphs following the above, I suggest.. s/target certificate/presented certificate/ ..to be more consistent with RFC6125. > 2.1.4. The Certificate Association Data Field > > > The "certificate association data" to be matched. This field > contains the data to be matched. The 2nd sentence "This field contains the data to be matched." is redundant. > 5. TLSA and DANE Use Cases and Requirements > . > . > . > Combination -- Multiple TLSA records can be published for a given > host name, thus enabling the client to construct multiple TLSA > certificate associations that reflect different DANE assertions. > No support is provided to combine two TLSA certificate > associations in a single operation. > > Roll-over -- TLSA records are processed in the normal manner within > the scope of DNS protocol, including the TTL expiration of the > records. This ensures that clients will not latch onto assertions > made by expired TLSA records, and will be able to transition from > using one DANE public key or certificate usage type to another. suggested rewrite eliminating the not-defined-in-RFC6394 terms "DANE assertion" and "DANE public key"... Combination -- Multiple TLSA records can be published for a given host name, thus enabling the client to construct multiple different TLS certificate associations. No support is provided to combine two TLS certificate associations in a single operation. Roll-over -- TLSA records are processed in the normal manner within the scope of DNS protocol, including the TTL expiration of the records. This ensures that clients will not latch onto assertions made by expired TLSA records, and will be able to transition from using one TLSA-asserted public key or certificate usage type to another. > 7.2. TLSA Usages > > > This document creates a new registry, "Certificate Usages for TLSA > Resource Records". suggested modest revision for terminological consistency: 7.2. TLSA Certificate Usage Types This document creates a new registry, "TLSA Resource Record Certificate Usage Types" HTH, =JeffH From hallam@gmail.com Wed Apr 25 11:33:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85D21F8832; Wed, 25 Apr 2012 11:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdTn+wpKN67k; Wed, 25 Apr 2012 11:33:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBBF921F8777; Wed, 25 Apr 2012 11:33:06 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so453983obb.31 for ; Wed, 25 Apr 2012 11:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0otew4pt2U6oa5pR9G3xYnQTQJrawPIgkFgS/NuXYo8=; b=HoZSN7KXYJdO8J6+ww5b9PIwTjCTZwNtLoNxSoDL5YJ521TliK6U//a7xefAi4vdB/ QJpfzSGBAIZ7u/TQKhYQQRZXOXdSbrLEcgbuYo3XOAOGj2j1KbODWyTl+H3SepjZ9ML6 /10y46fEbGM6XwXSbrY39qLlvGBcvf337w+LUHTiwbBvj+V5wSOBJ3/vLGoGUZ+WGxMh ij2p45RifXWkDvrD6FnNJsQFVtS0Wl9J4SsAqo5R2AfuB2UQ7tGkI8FmUWJm6TI/81yZ OyskHFXDxEf/TzTKQjVWAxhuS5aL9dln/b2D3a4fJsAIabUH/46Zy61TgJUL6PBDcwyf l7WA== MIME-Version: 1.0 Received: by 10.182.245.17 with SMTP id xk17mr4944512obc.66.1335378786471; Wed, 25 Apr 2012 11:33:06 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Wed, 25 Apr 2012 11:33:06 -0700 (PDT) In-Reply-To: <20120425151518.GC60024@mail.yitter.info> References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> <20120425151518.GC60024@mail.yitter.info> Date: Wed, 25 Apr 2012 14:33:06 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 18:33:09 -0000 On Wed, Apr 25, 2012 at 11:15 AM, Andrew Sullivan wrote: > On Wed, Apr 25, 2012 at 09:52:39AM -0400, Phillip Hallam-Baker wrote: > >> dependency on the DNSSEC trust chain despite the easily observed fact >> that less than 97% of DNS resolvers will pass anything other than >> A/AAAA and CNAME records. > > I'm having a hard time understanding that sentence. =A0Could you > clarify, please: > > A. =A0Fewer than 97% of DNS resolvers can pass anything other than > A/AAAA and CNAME, which means something more than 3% of resolvers pass > only A/AAAA and CNAME. > > =A0 =A0This is what I _think_ you mean, which means that n% > broken > =A0 =A0resolvers > 3%, right? =A0If so, I'd like a citation, though it > =A0 =A0doesn't sound wrong to me. =A0That we'd have something on the orde= r > =A0 =A0of 3% of the software deployed everywhere on the Internet be > =A0 =A0broken ought to be completely unsurprising. That was what two independent studies that were input to the CABForum revocation Workshop found. One was by Comodo, the other I am not sure what the citability status would be. The Comodo study was obtained by hooking the OCSP validation call in a very large number of browsers for over a week. I will see if it could be submitted as a draft as such studies can be useful. > B. =A097% of the DNS resolvers is the most that has ever been observed > working according to specification, and the number may be much lower. > > =A0 =A0This is the rhetorical point I think might be read in. =A0In this > =A0 =A0case, I think a citation is in order. Unfortunately this is also the case since we were merely looking for support for TXT records. So I would expect to see an even higher rate of stripping for DNSSEC records. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Apr 25 11:53:21 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5054821F87FE; Wed, 25 Apr 2012 11:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhnCFzBihdB2; Wed, 25 Apr 2012 11:53:20 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44A4121F87AA; Wed, 25 Apr 2012 11:53:20 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so477470obb.31 for ; Wed, 25 Apr 2012 11:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qVXzI6yKKa11+fOtNsM177l4NplNvxiezXJ7A4RXF2s=; b=GckeEscdQcN5GpLKAG8MvnxDJ6/pq1+YeU158SS+HyLdL3zsloYo5ogK6FHK+RP6EQ oajZ1/49T1RBt07Lm0g1eRDToKIgoSfxxn+l1V/DwhN3++5u5eS68BVSjlyjnYSkC84x jtdfM7tlwOMArZ+Z/AABrnihGweaGN2Q3D7hPCp96gZBlSlcekGMO7ovUaIs0sJT0MzN rUugSWmKP0FMTSq6lhOrW3uN476TXoCnWjDYuLEHY7pa8VkxVxLrb9ZHTPvJ0j7KIhvE XkNMMadr1tga2Fy7UF+OFdbj+SrSUloUa9GACZYRAfMOSz0tn4j/VQcahmKQwBeIjD6g a8Bw== MIME-Version: 1.0 Received: by 10.182.245.17 with SMTP id xk17mr5029956obc.66.1335379999916; Wed, 25 Apr 2012 11:53:19 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Wed, 25 Apr 2012 11:53:19 -0700 (PDT) In-Reply-To: References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> Date: Wed, 25 Apr 2012 14:53:19 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 25 Apr 2012 18:53:21 -0000 On Wed, Apr 25, 2012 at 11:47 AM, Paul Wouters wrote: > On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote: >> Rather than mandating hardfail or any particular client behavior, the >> specification should simply state that the client MUST conclude that >> the DANE status of the certificate is invalid and then leave the >> client to decide on what course of action to take. This will depend on >> the circumstances of the particular user and the client provider's >> assessment of the reliability of the DANE data and might range from do >> nothing to send a security policy violation notification somewhere to >> hardfail. > > > In all IETF protocols, there is the "local policy overrides", yet we > don't add it specifically to every MUST in the protocol documents. > Additionally, the browser can fail the connection and terminate the TLS > and provide the user some feedback with a local policy override, and > then the brower complies to both the hard fail requirement, and your > 'too big too fail' argument. So you are saying that this MUST does not matter because MUSTs can always be overridden? My view is that the correct approach in this case is to use a SHOULD. That is also what it says in 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. I think that 'causing harm' needs to be considered very narrowly here as it seems pretty clear that the original context is talking about harm to network operations. If we think that local security policy is going to override then we really have no choice but to use a SHOULD if we are taking 2119 literally. >> Contrary to the assumptions of the specification authors, hard fail is >> not the best option. It is not even the best option in the case that >> the users are dissidents. > > Tell that to the chrome users in Iraq that are still alive and not in > jail getting tortured. If anyone is going to sacrifice the one for the > many, I sure as hell hope it won't be protocol designers. That is unfair on many levels, not least because 1) the Chrome guys were the people who found the issue and 2) this was not a case where revocation could have helped since the CA had no idea which certs had been issued. As I explained in the following discussion, what was most important was to detect and report the security policy anomaly even if it was not going to be sufficiently reliable to hard fail on. Of course what would be the best case would be an Internet that didn't have such a high degree of inherent unreliability. But that is not an option at present. Proposing to mandate behavior in the expectation of being ignored is irresponsible. > Sure. Any data can be blocked. You work around the block with tunneling > and then use the actual DANE information for your own protection and > safety within the tunnel. Suggesting the block means you might as well > not add security in case there is no block, or you can break through it, > is wrong. No, it means that you cannot address this particular problem with a reductionist approach. We have already deployed a technology that provides a partial fix to this problem. >> But the DANE approach is too dogmatic to succeed. > > > All your arguments against dane are equally valid/invalid for OCSP with > hard fail, which you seem to be a proponent of. I fail to see the > consistency in your reasoning. That is true. What I am arguing here is to not build a second infrastructure that is going to fail in exactly the same way that OCSP is failing. If you subscribe to the right key you will have my omnibroker proposal which proposes a way to use both DANE and OCSP without the current failure modes. Otherwise I can send you the PDF. -- Website: http://hallambaker.com/ From sm@resistor.net Wed Apr 25 19:10:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CE421E80C5 for ; Wed, 25 Apr 2012 19:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXx58+8LJ3ut for ; Wed, 25 Apr 2012 19:10:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BDD21E8043 for ; Wed, 25 Apr 2012 19:10:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3Q2AZoR010077; Wed, 25 Apr 2012 19:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335406240; i=@resistor.net; bh=3tOyb4tftJlGsE4ghEvAGCtBX5q+FopnYj3wsClGH54=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=XI8KTKvJ1vS9DkdOPyltydr2xz/8hyXSSRR5567LDhWoxMwF/zJFOxyjLvITAFv9+ cP0afVExlLb40NmbFqGe8wTNM3fz3cnAGUEhZcVyysQVfIBSrv2PGDTi70HkX4R1ld 9OHOK+O+nRKTEPXtRgwY5k3/iZ6XXtOrgCybebRQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335406240; i=@resistor.net; bh=3tOyb4tftJlGsE4ghEvAGCtBX5q+FopnYj3wsClGH54=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ccBRCsrOm7oeeZXxn9w01BaDtqGnjlIpTmKfXFUgSxGOBT0FzuOrpRn7XimhDMUAh jy73nGot9E2Mk5YUZ6CW0rz90mLQSRZ7fNY0widEJMhyt3PmMW5ijAmQxJIv7UFoGk mpFPNltjyKPUC0kZKxSnQwyh++W5jv6HTDzIC5QE= Message-Id: <6.2.5.6.2.20120425181422.0b3ac320@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 25 Apr 2012 19:09:01 -0700 To: Phillip Hallam-Baker From: SM In-Reply-To: References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2012 02:10:43 -0000 Hi Philip, At 06:52 25-04-2012, Phillip Hallam-Baker wrote: >Client providers already ignore significant parts of the PKIX >specification because they do not meet their performance criteria. In >particular virtually all browsers treat inability to obtain OCSP >certificate status as being equivalent to 'good'. This is a terrible >security design, one that every CA would like to see change. But it is >also a fact that we have been trying to get this changed for ten years >without success. Paul Wouters already commented on the ocsp.entrust.net issue. It is not the first time there is a (DNS) issue with ocsp.entrust.net. This leads you to the same path as "turn off IPv6". >Section 4 of the draft mandates a client hardfail if the DNSSEC trust >chain cannot be obtained. This is essential if the client is going to >use DNSSEC to establish certificate constraints just as certificate >revocation is an essential part of the PKIX model. But no browser >provider can expect to succeed with a product that simply stops >working when the user tries to surf the Web from a coffee shop. Yes. If a basic assumption fails, in this case DNSSEC, the specification turns into a tower of cards. >Rather than mandating hardfail or any particular client behavior, the >specification should simply state that the client MUST conclude that >the DANE status of the certificate is invalid and then leave the >client to decide on what course of action to take. This will depend on >the circumstances of the particular user and the client provider's >assessment of the reliability of the DANE data and might range from do >nothing to send a security policy violation notification somewhere to >hardfail. That would be a SHOULD then. I am not arguing for that btw. >The coffee shop issue is unintended but there are also parties that >are going to intentionally sabotage any infrastructure that looks like >DANE. We are not in the 1990s any longer, people in authority no >longer expect OSI to replace the Internet. The result is that it is >much harder to get away with no infrastructure. At present there is no >point in blocking DNSSEC records. But you can be sure that Iran, We could always have Negative Trust Anchors instead of "blocking" DNSSEC records. >DANE is really a form of security policy information and so far there >is no case where we have succeeded in applying raw security policy >information at the client end. DKIM policies are a success because >they are filtered and interpreted by the anti-spam services. There is >a huge infrastructure in place that is working to apply the data from >the DKIM records intelligently and equally importantly provides >feedback to publishers of inconsistent records. The above sounds like what the RFCs say. The reality is different. Regards, -sm P.S. local policy can also mean "if you break stuff, don't blame the specification". From hallam@gmail.com Thu Apr 26 07:10:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3670C21E8087 for ; Thu, 26 Apr 2012 07:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+nE574YZx3Y for ; Thu, 26 Apr 2012 07:10:19 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32CF721E8055 for ; Thu, 26 Apr 2012 07:10:19 -0700 (PDT) Received: by qcsq13 with SMTP id q13so822938qcs.31 for ; Thu, 26 Apr 2012 07:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tvE4G/9Do8ZTDvDl/bWx/9q0CQWAToa7LGAG92JXQJs=; b=rQfcqZz2YttQ5qfON1Uzm6bIZJqE9Ra6gW5KsigSrnjcFVWdGHS2VLBCEkJITBuowO VI+2RKi8nKvHg8Z5vrs+Z/Zukg9rIVuMn/AQLafDab9azhsZvz6Tcen/n2pNvNCYLMG6 /yrT1Uo3mZfuuhYAxs7S93Kza8mCxVYEGAhB1KM5agM/fjA3UGfXqH16ucDJisPnByBP g9ZR22/4KqlTrxlOibqDpDW5Dx1NaOa9bFocnSgE20pCd7+8B0K2/MbdnEG1IYJRqEJ9 tT/R/Jc3WlYb3HB4N7I4Q18gNNZ+nZv18AgN7x42HdoYoZ6q+pVS3qmqfNXEudZGmIce yXoQ== MIME-Version: 1.0 Received: by 10.60.27.7 with SMTP id p7mr4521718oeg.56.1335449418564; Thu, 26 Apr 2012 07:10:18 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Thu, 26 Apr 2012 07:10:18 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120425181422.0b3ac320@resistor.net> References: <01OE8FJG30ZM00ZUIL@mauve.mrochek.com> <201204130359.q3D3xlG0007556@fs4113.wdf.sap.corp> <01OE9150IMNI00ZUIL@mauve.mrochek.com> <6.2.5.6.2.20120425181422.0b3ac320@resistor.net> Date: Thu, 26 Apr 2012 10:10:18 -0400 Message-ID: From: Phillip Hallam-Baker To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dane@ietf.org Subject: Re: [dane] Last Call: (The DNS-Based X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2012 14:10:20 -0000 On Wed, Apr 25, 2012 at 10:09 PM, SM wrote: > Hi Philip, > > Paul Wouters already commented on the ocsp.entrust.net issue. =A0It is no= t the > first time there is a (DNS) issue with ocsp.entrust.net. =A0This leads yo= u to > the same path as "turn off IPv6". It has led the browser providers to do that. I think that rather than sit round griping at folk not doing what we might want, we have to work on making the protocol a win-win. > If a basic assumption fails, in this case DNSSEC, the specification turns > into a tower of cards. Not quite, it is highly unlikely that any new discovery or metadata protocol is going to be 100% at the client side unless it is a protocol that is purpose designed to provide umpteen different ways of getting round local loop lossage. When I started to design a protocol that would make DANE viable I soon realized that getting round local loop lossage is a separate problem that should be addressed separately and generically. In other words, don't just try to make DANE work in the local loop, make OCSP work as well and make it extensible so that it can be used for many other things in the future. > P.S. local policy can also mean "if you break stuff, don't blame the > specification". I really dislike the fact that a lot of the Internet specification has turned into folklore. There is what is written down and then there are the additional rules that are not written down anywhere or if they are are written poorly. Things like how to connect to the Internet from a captive portal (hotel, coffee shop), how to traverse NAT, etc. etc. The problem with the current approach is that someone wants to do something, they get told 'no' and so they do it anyway but in a way that nobody else can then build on top of because its badly documented and makes no allowance for extension. Things like grabbing the unprefixed TXT record for anti-spam alone. --=20 Website: http://hallambaker.com/ From warren@kumari.net Thu Apr 26 09:48:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADBE21E804E for ; Thu, 26 Apr 2012 09:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB42TjGsubee for ; Thu, 26 Apr 2012 09:48:40 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id AF1C121E801E for ; Thu, 26 Apr 2012 09:48:40 -0700 (PDT) Received: from [172.26.43.188] (unknown [72.14.228.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 7186D1B4030F; Thu, 26 Apr 2012 12:48:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <201204220153.q3M1rBcF028072@new.toad.com> Date: Thu, 26 Apr 2012 12:48:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9B46E85A-BE52-465E-8D7B-7E525D67A47F@kumari.net> References: <4F91E481.8070801@KingsMountain.com> <0EE3D72F-1093-4C76-80BC-7F1C5CDAE003@vpnc.org> <201204220153.q3M1rBcF028072@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Referring to the DANE protocol and DANE-denoted certificate associations X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2012 16:48:41 -0000 On Apr 21, 2012, at 9:53 PM, John Gilmore wrote: > I tried bearding this lion several times, too. It's painful to have a > spec that we have no short name for. My latest suggestion is that we > call it the "DANE TLS" protocol. >=20 This sounds like a good option and makes things clearer. Let's refer to = it as this=85 W > I still find the whole "certificate association" undefined term = puzzling. > Maybe somebody else can take a stab at defining it. Or maybe the WG > really likes having undefined terms at the heart of its protocol. > A "certificate association" seems to be defined as "whatever is in a=20= > TLSA record" but to me that's rather circular. I would prefer that we > just called it a TLSA record if that's all it's going to be. >=20 > John > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul.hoffman@vpnc.org Thu Apr 26 14:29:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8FB11E8099 for ; Thu, 26 Apr 2012 14:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XiIVCAncnDd for ; Thu, 26 Apr 2012 14:29:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 633C811E8098 for ; Thu, 26 Apr 2012 14:29:22 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3QLTK0W045838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Apr 2012 14:29:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: multipart/alternative; boundary="Apple-Mail=_4E35434F-4A67-4688-B684-26BA7D0E33C9" Date: Thu, 26 Apr 2012 14:29:20 -0700 References: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> To: IETF DANE WG list Message-Id: <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Fwd: SecDir Review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2012 21:29:23 -0000 --Apple-Mail=_4E35434F-4A67-4688-B684-26BA7D0E33C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > Resent-From: catherine.meadows@nrl.navy.mil > From: Catherine Meadows > Subject: SecDir Review of draft-ietf-dane-protocol-19 > Date: April 26, 2012 1:08:48 PM PDT > To: draft-ietf-dane-protocol.all@tools.ietf.org, iesg@ietf.org, = secdir@ietf.org > Cc: Catherine Meadows >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 >=20 > This draft gives the specification of a method for DNS-based = authentication of named entities (that is public key certificates) for > TLS. The draft is written in response to a perception of the risk = involved in the current use of multiple Certificate Authorities (CAs) > to issue certificates. Because CAs are large, they make inviting = targets, and because different CAs may be sign the same certificate, > compromise of even one CA could allow it to issue a replacement = certificate with a bogus key that would replace the legitimate = certificate > signed by the honest CAs. This has led to some incidents involving > compromise of major web sites involving millions of users. >=20 > Another approach is to make use of the DNS infrastructure instead of = public CAs: keys are associated with domain names, and can only be = signed > with a key associated with the parent of the domain name. The keys = would be managed by the same entities that manage the domain name. > This has the advantage that an untrustworthy signer can only = compromise keys in its own subdomains, so the advantage of to an = attacker > of compromising a single CA is lessened. =20 >=20 > This document describes a TLSA Resource Record that is used to = associate a certificate with the domain name where the record is found = and > specifies its use in TLS. This requires changes to the client = software so that clients are able to interpret the records, but no = change to the server software. >=20 > The security considerations section is thorough and well-thought out. = It consists of three parts. The first part describes security risks not = necessarily (to my knowledge) related > to the choice of DNS domains rather than CAs, and describes possible = mitigations. The second gives a comparison of the > security issues involved in relying on DNS domains rather than CAs; = the authors make it clear that this is not an open-and-shut case either > way, and that much is still unknown. The third describes, and = suggests mitigations against, some security risks that are specific to = DNS, having to do with attacks based on deliberate mis-association > of TLSA records and DNS names. >=20 > I only have a couple of minor questions. First, the authors = contrast the number of certificates signed by the CAs and by the DNS = domains. However, it would > appear that as get closer to the root of the domain name tree, number = of certificates would get large, and that some domains, such as .com, = would > be more likely to have certificates that are attractive to attackers = than others. However, I don't know how large CAs get by comparison; if = there are some > figures available, that would help. Secondly, it appears that all the = risks described in the first part of the security considerations apply = equally as well to the > current CA-based system as well, except that the risks attributed to = rogue DNS administrators would > instead be attributed to rogue CA's. If that is so, it would be good = to have a sentence saying so. On the other hand, if some of the risks = apply only to the new > system and not the current one, it would be good to know about these = too. =20 >=20 > Finally, a nit: what are the A/AAAA records referred to in the first = part of the security considerations section? I could not find a = definition in the document. >=20 > Cathy Meadows >=20 >=20 > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil >=20 --Paul Hoffman --Apple-Mail=_4E35434F-4A67-4688-B684-26BA7D0E33C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Catherine Meadows <catherine.meadows@nrl.navy.= mil>
Subject: SecDir Review of = draft-ietf-dane-protocol-19
Date: April 26, 2012 1:08:48 PM PDT
Cc: Catherine Meadows = <catherine.meadows@nrl.navy.= mil>

I = have reviewed this document as part of the security = directorate's
ongoing effort to review all IETF documents being = processed by the
IESG.  These comments were written primarily = for the benefit of the
security area directors.  Document = editors and WG chairs should treat
these comments just like any other = last call comments.


This draft gives the = specification of a method for DNS-based authentication of named entities = (that is public key certificates) for
TLS.  The draft is = written in response to a perception of the risk involved in the current = use of multiple Certificate Authorities (CAs)
to issue = certificates.  Because CAs are large, they make inviting targets, = and because different CAs may be sign the same = certificate,
compromise of even one CA could allow it to issue = a replacement certificate with a bogus key that would replace the = legitimate certificate
signed by the honest CAs.  This = has led to some incidents involving
compromise of major web = sites involving millions of users.

Another = approach is  to make use of the DNS infrastructure instead of = public CAs: keys are associated with domain names, and can only be = signed
with a key associated with the parent of the domain = name.  The keys would be managed by the same entities that manage = the domain name.
This has the advantage that an untrustworthy = signer can only compromise keys in its own subdomains, so the advantage = of to an attacker
of compromising a single CA is lessened. =  

This document describes a TLSA Resource = Record  that is used to associate a certificate with the domain = name where the record is found and
specifies its use in TLS. =  This requires changes to the client software so that clients are = able to interpret the records, but no change to the server = software.

The security considerations section = is thorough and well-thought out.  It consists of three parts. =  The first part describes security risks not necessarily (to my = knowledge) related
to the choice of DNS domains rather = than CAs, and describes possible mitigations.  The second gives a = comparison of the
security issues involved in relying on DNS = domains rather than CAs; the authors make it clear that this is not an = open-and-shut case either
way, and that much is still unknown. =  The third describes, and suggests mitigations against, some = security risks that are specific to DNS, having to do with attacks based = on deliberate mis-association
of TLSA records and DNS = names.

 I only  have a couple of = minor questions.  First,  the authors contrast the number of = certificates signed by the  CAs and by the DNS domains. =  However, it would
appear that as get closer to the root = of the domain name tree, number of certificates would get large, and = that some domains, such as .com, would
be more likely to have = certificates that are attractive to attackers than others. =  However, I don't know how large CAs get by comparison; if there = are some
figures available, that would help.  Secondly, = it appears that all the risks described in the first part of the = security considerations apply equally as well to the
current = CA-based system as well, except that the risks attributed to rogue DNS = administrators would
instead be attributed to rogue CA's. =   If that is so, it would be good to have a sentence saying so. =  On the other hand, if some of the risks apply only to the = new
system and not the current one, it would be good to know = about these too.  

Finally, a nit: what = are the A/AAAA records referred to in the first part of the security = considerations section?  I could not find a definition in the = document.

Cathy = Meadows


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil


--Paul = Hoffman

= --Apple-Mail=_4E35434F-4A67-4688-B684-26BA7D0E33C9-- From paul@nohats.ca Thu Apr 26 15:51:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7C011E8088 for ; Thu, 26 Apr 2012 15:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZESy9HEOGz6 for ; Thu, 26 Apr 2012 15:51:46 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1C721F86B3 for ; Thu, 26 Apr 2012 15:51:45 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id DB5AD8036B; Thu, 26 Apr 2012 18:51:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id CFA2E8033B; Thu, 26 Apr 2012 18:51:44 -0400 (EDT) Date: Thu, 26 Apr 2012 18:51:44 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> Message-ID: References: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Cc: IETF DANE WG list Subject: Re: [dane] Fwd: SecDir Review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 26 Apr 2012 22:51:46 -0000 On Thu, 26 Apr 2012, Paul Hoffman wrote: >  I only  have a couple of minor questions.  First,  the authors contrast the number of certificates > signed by the  CAs and by the DNS domains.  However, it would > appear that as get closer to the root of the domain name tree, number of certificates would get > large, and that some domains, such as .com, would > be more likely to have certificates that are attractive to attackers than others.  However, I don't > know how large CAs get by comparison; if there are some > figures available, that would help. A straight count comparison is not very meaningful. If the com zone is compromised, modified NS records, in combination with a single compromised CA would result in all TLS being compromised. This is the same as .com being compromised, and modifying DS records. In both cases the real devestating compromise is the .com zone NS records. What is however a fair new risk is the compromise of a registrar that can update DS records of their registrants. It is a true concern, and such compromise would almost be equal to a CA compromise, but there is an important difference. A CA compromise can be used in a localised targeted attack, but can remain hidden, as we saw in the Iran/chrome case. A compromised registrar attack however, changes the DNS view globally, and anyone monitoring their own domains would instantly be aware of this compromise. >  Secondly, it appears that all the risks described in the first > part of the security considerations apply equally as well to the > current CA-based system as well, except that the risks attributed to rogue DNS administrators would > instead be attributed to rogue CA's. But again, the scope is very different. a rogue DNS admin can change their own domain contents. A rogue CA van vouch for other people's domains. Paul From marka@isc.org Thu Apr 26 18:13:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427C421E80CF for ; Thu, 26 Apr 2012 18:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y+hJoK05xDI for ; Thu, 26 Apr 2012 18:13:19 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id A024621E80A1 for ; Thu, 26 Apr 2012 18:13:19 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 342405F99D6; Fri, 27 Apr 2012 01:13:04 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1bb:3389:e4ab:bf96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 40E67216C31; Fri, 27 Apr 2012 01:13:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 477CA200AF19; Fri, 27 Apr 2012 11:12:57 +1000 (EST) To: Paul Hoffman From: Mark Andrews References: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> In-reply-to: Your message of "Thu, 26 Apr 2012 14:29:20 MST." <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> Date: Fri, 27 Apr 2012 11:12:56 +1000 Message-Id: <20120427011257.477CA200AF19@drugs.dv.isc.org> Cc: IETF DANE WG list Subject: Re: [dane] Fwd: SecDir Review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2012 01:13:20 -0000 Using A/AAAA to refer to A and AAAA records is bad. Additionally the first paragraph did not make sense. Old: The security of the DNS RRtype described in this document relies on the security of DNSSEC as used by the client requesting A/AAAA and TLSA records. A DNS administrator who goes rogue and changes both the A/AAAA and TLSA records for a domain name can cause the user to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate. That administrator could probably get a certificate issued by some CA anyway, so this is not an additional threat. If the authentication mechanism for adding or changing TLSA data in a zone is weaker than the authentication mechanism for changing the A/AAAA records, a man-in-the-middle who can redirect traffic to their site may be able to impersonate the attacked host in TLS if they can use the weaker authentication mechanism. A better design for authenticating DNS would be to have the same level of authentication used for all DNS additions and changes for a particular domain name. New: The security of the DNS RRtype described in this document relies on the client using DNSSEC to verify that the TLSA record has not been altered. A DNS administrator who goes rogue and changes the A, AAAA and TLSA records for a domain name can cause the user to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate. That administrator could probably get a certificate issued by some CA anyway, so this is not an additional threat. If the authentication mechanism for adding or changing TLSA data in a zone is weaker than the authentication mechanism for changing the A and AAAA records, a man-in-the-middle who can redirect traffic to their site may be able to impersonate the attacked host in TLS if they can use the weaker authentication mechanism. A better design for authenticating DNS would be to have the same level of authentication used for all DNS additions and changes for a particular domain name. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Fri Apr 27 04:07:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0621421F8613 for ; Fri, 27 Apr 2012 04:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9X0FSHJ5Oyb for ; Fri, 27 Apr 2012 04:07:24 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 51BFB21F85D4 for ; Fri, 27 Apr 2012 04:07:19 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54986) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SNj1A-0004YB-QA (Exim 4.72) (return-path ); Fri, 27 Apr 2012 12:07:16 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SNj1A-00080c-2C (Exim 4.67) (return-path ); Fri, 27 Apr 2012 12:07:16 +0100 Date: Fri, 27 Apr 2012 12:07:16 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Fwd: SecDir Review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2012 11:07:25 -0000 Paul Wouters wrote: > > What is however a fair new risk is the compromise of a registrar that > can update DS records of their registrants. It is a true concern, and > such compromise would almost be equal to a CA compromise, but there > is an important difference. A CA compromise can be used in a localised > targeted attack, but can remain hidden, as we saw in the Iran/chrome > case. > > A compromised registrar attack however, changes the DNS view globally, > and anyone monitoring their own domains would instantly be aware of > this compromise. The other difference is that a registrar has a contractual relationship with its customers who will be affected if the registrar is compromised. Domain registrants can increase their security by careful choice of registrar. The victims of a compromised CA typically have no relationship with the CA. You can't meaningfully increase your security by carefully choosing which CA to buy a certificate from. So DNSSEC has stronger legal and economic backups to its technical security mechanisms. Tony. -- f.anthony.n.finch http://dotat.at/ West Bailey: Northerly 4 or 5, becoming variable 3 or 4, then southwesterly 4 or 5, occasionally 6 later. Rough becoming moderate. Fair. Good. From hallam@gmail.com Fri Apr 27 04:50:52 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98B521F866D for ; Fri, 27 Apr 2012 04:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Y1T6AACd+P for ; Fri, 27 Apr 2012 04:50:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 955A621F87DC for ; Fri, 27 Apr 2012 04:50:51 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1108036obb.31 for ; Fri, 27 Apr 2012 04:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PXGH2LHJYw19MZKard4YFTt+O8ae4hOZ4m0NkBXc7xE=; b=EBPT4SzH57IZ+h5+ggJ7yWX8PdgPAjeO2TDDIx9ZWiJcHSa0VpIxgOvx2w4ZUKdJ3K g+3QwjsJMtabcZiS0EqhVq3cPIApHKLWyIubRDGxpd9Ed9DfFNqY8UjHXkoln7H1cmef bimdHKykyNBiSLgmlYnSi2oFHXG1u6h32OZwUviGwc3MRLaUG5tjSFfYEhyfZwKzQd7B aGZIID+1d9XXs/eHokzMBYUzAeJ8dGvQesjqhpTPuYMDHR38ZdbYaJblQvMfGYvOlhx/ URSCKnz9wRw4w7MOjMTkT8tzY1p+0ViYA96v2q4o9AKzRg5gHSNF0YQMtPvIhWENtl4j iHSA== MIME-Version: 1.0 Received: by 10.182.51.9 with SMTP id g9mr13636048obo.56.1335527450944; Fri, 27 Apr 2012 04:50:50 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 27 Apr 2012 04:50:50 -0700 (PDT) In-Reply-To: References: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.org> Date: Fri, 27 Apr 2012 07:50:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , IETF DANE WG list Subject: Re: [dane] Fwd: SecDir Review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2012 11:50:52 -0000 A rogue DNS registrar can change anything in the system that is not nailed down. That is a fact of the current system and domain hijacking is a daily event. therpf.com has just recovered from a domain hijacking. It is not directly relevant to DANE but had the EFF 'sovereign keys' proposal been deployed the attacker could have permanently disabled the site's ability to use SSL. Any practical scheme has to balance risks rather than pretend that some can be ignored by declaring them out of scope. There are controls in the DNS system that can be used to 'lock' domains. But we have no information on how they are implemented, what the security policy is or whether an audit exists for that part of the system. And nobody accepts liability if those controls fail. On Thu, Apr 26, 2012 at 6:51 PM, Paul Wouters wrote: > On Thu, 26 Apr 2012, Paul Hoffman wrote: > >> =A0I only =A0have a couple of minor questions. =A0First, =A0the authors = contrast >> the number of certificates >> signed by the =A0CAs and by the DNS domains. =A0However, it would >> appear that as get closer to the root of the domain name tree, number of >> certificates would get >> large, and that some domains, such as .com, would >> be more likely to have certificates that are attractive to attackers tha= n >> others. =A0However, I don't >> know how large CAs get by comparison; if there are some >> figures available, that would help. > > > A straight count comparison is not very meaningful. =A0If the com zone is > compromised, modified NS records, in combination with a single compromise= d > CA would result in all TLS being compromised. This is the same as .com > being compromised, and modifying DS records. In both cases the real > devestating compromise is the .com zone NS records. > > What is however a fair new risk is the compromise of a registrar that > can update DS records of their registrants. It is a true concern, and > such compromise would almost be equal to a CA compromise, but there > is an important difference. A CA compromise can be used in a localised > targeted attack, but can remain hidden, as we saw in the Iran/chrome > case. > > A compromised registrar attack however, changes the DNS view globally, > and anyone monitoring their own domains would instantly be aware of > this compromise. > > >> =A0Secondly, it appears that all the risks described in the first >> part of the security considerations apply equally as well to the >> current CA-based system as well, except that the risks attributed to rog= ue >> DNS administrators would >> instead be attributed to rogue CA's. > > > But again, the scope is very different. a rogue DNS admin can change thei= r > own domain contents. A rogue CA van vouch for other people's domains. > > Paul > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 Website: http://hallambaker.com/ From ajs@anvilwalrusden.com Fri Apr 27 09:28:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CC421F86D4 for ; Fri, 27 Apr 2012 09:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCk6ZuqJu+Kt for ; Fri, 27 Apr 2012 09:28:36 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6C92B21F868A for ; Fri, 27 Apr 2012 09:28:36 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 90E501ECB420 for ; Fri, 27 Apr 2012 16:28:35 +0000 (UTC) Date: Fri, 27 Apr 2012 12:28:33 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20120427162829.GF67831@mail.yitter.info> References: <5846D07A-1A16-4F27-A0C6-D206115DE1F3@nrl.navy.mil> <83E01EF7-4559-45DE-9F25-E7361D23E198@vpnc.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] Fwd: SecDir Review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2012 16:28:37 -0000 On Fri, Apr 27, 2012 at 07:50:50AM -0400, Phillip Hallam-Baker wrote: > > There are controls in the DNS system that can be used to 'lock' > domains. If this is supposed to be the (near-) TLD-regisrtars' ability to put various restrictions on the registration, then they're no help for most of the "hijack" cases, and can't possibly be. In EPP, in fact, they're not called "LOCK", but are instead various prohibitions (clientUpdateProhibited, clientTransferProhibited, clientDeleteProhibited, and maybe clientRenewProhibited; there are server-side versions of these too). The repository sponsor (which we usually call a registrar) can, of course, modify these settings. So, if the domain name registrant's account with a registrar is subverted, the settings can of course be removed and then the changes can happen. (Off topic: There doesn't seem to be any practical way to fix this. I continue to believe that there could be a market for very secure domain name registration service, but I suspect it's mostly out of hope rather than evidence.) With all of that in mind, I fail to see what the TLSA document is supposed to say more about this topic. It already says that if you can get hold of the registration, then you hold the keys. The point in using DANE/TLSA is that that's _already the case_ with the traditional CA market; so this opens no new attack, and closes one (since the CA doesn't have to be involved). I thought the draft was clear about this. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From paul.hoffman@vpnc.org Fri Apr 27 11:01:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D1721F86E8; Fri, 27 Apr 2012 11:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR4Gmt9HI-Yk; Fri, 27 Apr 2012 11:01:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9688921F8687; Fri, 27 Apr 2012 11:01:23 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3RI1M5F089778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 11:01:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F95CA0B.8050202@stpeter.im> Date: Fri, 27 Apr 2012 11:01:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> References: <4F95CA0B.8050202@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2012 18:01:24 -0000 On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote: > Major Issue: >=20 > This document does not mention that TLSA records cannot be used > directly in application protocols that depend on SRV (or NAPTR or > similar technologies). Although I realize that the DANE WG decided, > after much discussion, that the interaction between TLSA records and > SRV records is out of scope for this specification (and I do not mean > to reopen that discussion now), it would be very helpful for this > specification to reflect the results of that discussion. Although I > make specific suggestions regarding text under the Minor Issues below, > in general I think this document needs to be clearer about the > assumptions it has made in this regard; in fact, it seems to me that > an explicit applicability statement is warranted to avoid confusion of > the kind that Dave Cridland experienced (see his Last Call comments). Now covered in section 1.3, and includes a note that this document might = be updated in the future to cover such things. (Note: it would be grand = if an XMPPer would start work on this soon so we still have momentum.) > 5. To those of us accustomed to SRV records, at first glance the > prefixed DNS domain name format defined in Section 3 looks strange: > why not _http._tcp.www.example.com instead of > _443._tcp.www.example.com? But when we take off our SRV-colored > glasses and realize that DANE assumes a DNS A/AAAA lookup on the > domain name, it all makes sense. Perhaps it would be helpful to > mention the reasoning behind the port number (instead of application > name) here? I would rather not try to summarize the debate in the spec, given that = the result (numbers) are completely clear. > 6. In section 4, no mention is made of the application service that > the TLS expects to encounter at the TLS server: >=20 > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. >=20 > Yet surely the application protocol can matter here, no? No. > In > particular, given that 443 is the one true port, we know that folks > might run non-HTTP applications over that port (for evil reasons, of > course). Sure. But... > Does DANE elide over the application protocol because we > simply assume that the "right" service is being served over any > particular port? Yes, that's the only sane way to do things currently. (The TLS WG is = discussing adopting a protocol that would complicate this, but that's a = long way off, I suspect.) > What about service providers that wish to restrict > the usage of a certificate to a particular application service type > (cf. RFC 6125)? I'm not sure how this is relevant. There is only one application = protocol that can be running on 443 after TLS is established. > Or do we assume that it is enough to differentiate > among application services based on the underlying transport (as seems > to be the case in the text on "Multiple Ports" in Section 5)? Yes. > IMHO we > have a bit of a muddle here. I don't see it. > 7. The paragraph about SSL proxies in Section 8 says that "the TLS > client will get a certificate association from the DNS that will not > match the certificate that the SSL proxy uses with the client"; > however, if the SSL proxy is working in concert with an external DNS > validator, is it possible to mimic the behavior of current SSL = proxies? Maybe, but they are undefined. --Paul Hoffman From warren@kumari.net Fri Apr 27 12:52:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACAC11E8086; Fri, 27 Apr 2012 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1F1ENbLyKmE; Fri, 27 Apr 2012 12:52:42 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE1711E8083; Fri, 27 Apr 2012 12:52:40 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E248C1B40316; Fri, 27 Apr 2012 15:52:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> Date: Fri, 27 Apr 2012 15:52:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9934BC7B-3193-44D1-870A-69A6F6A1612C@kumari.net> References: <4F95CA0B.8050202@stpeter.im> <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , iesg@ietf.org, dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 27 Apr 2012 19:52:48 -0000 On Apr 27, 2012, at 2:01 PM, Paul Hoffman wrote: > On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote: >=20 >> Major Issue: >>=20 >> This document does not mention that TLSA records cannot be used >> directly in application protocols that depend on SRV (or NAPTR or >> similar technologies). Although I realize that the DANE WG decided, >> after much discussion, that the interaction between TLSA records and >> SRV records is out of scope for this specification (and I do not mean >> to reopen that discussion now), it would be very helpful for this >> specification to reflect the results of that discussion. Although I >> make specific suggestions regarding text under the Minor Issues = below, >> in general I think this document needs to be clearer about the >> assumptions it has made in this regard; in fact, it seems to me that >> an explicit applicability statement is warranted to avoid confusion = of >> the kind that Dave Cridland experienced (see his Last Call comments). >=20 > Now covered in section 1.3, and includes a note that this document = might be updated in the future to cover such things. (Note: it would be = grand if an XMPPer would start work on this soon so we still have = momentum.) Yes -- we decided to take the "instead of boiling the ocean / being all = things to all people" approach with the initial doc to instead publish = this and then have "How to do DANE with protocol foo" documents... This = does mean that we want need these docs.=20 They should be fairly simple to write -- submissions gratefully accepted = :-) W >=20 >> 5. To those of us accustomed to SRV records, at first glance the >> prefixed DNS domain name format defined in Section 3 looks strange: >> why not _http._tcp.www.example.com instead of >> _443._tcp.www.example.com? But when we take off our SRV-colored >> glasses and realize that DANE assumes a DNS A/AAAA lookup on the >> domain name, it all makes sense. Perhaps it would be helpful to >> mention the reasoning behind the port number (instead of application >> name) here? >=20 > I would rather not try to summarize the debate in the spec, given that = the result (numbers) are completely clear. >=20 >> 6. In section 4, no mention is made of the application service that >> the TLS expects to encounter at the TLS server: >>=20 >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. >>=20 >> Yet surely the application protocol can matter here, no? >=20 > No. >=20 >> In >> particular, given that 443 is the one true port, we know that folks >> might run non-HTTP applications over that port (for evil reasons, of >> course). >=20 > Sure. But... >=20 >> Does DANE elide over the application protocol because we >> simply assume that the "right" service is being served over any >> particular port? >=20 > Yes, that's the only sane way to do things currently. (The TLS WG is = discussing adopting a protocol that would complicate this, but that's a = long way off, I suspect.) >=20 >> What about service providers that wish to restrict >> the usage of a certificate to a particular application service type >> (cf. RFC 6125)? >=20 > I'm not sure how this is relevant. There is only one application = protocol that can be running on 443 after TLS is established. >=20 >> Or do we assume that it is enough to differentiate >> among application services based on the underlying transport (as = seems >> to be the case in the text on "Multiple Ports" in Section 5)? >=20 > Yes. >=20 >> IMHO we >> have a bit of a muddle here. >=20 > I don't see it. >=20 >> 7. The paragraph about SSL proxies in Section 8 says that "the TLS >> client will get a certificate association from the DNS that will not >> match the certificate that the SSL proxy uses with the client"; >> however, if the SSL proxy is working in concert with an external DNS >> validator, is it possible to mimic the behavior of current SSL = proxies? >=20 > Maybe, but they are undefined. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From paul.hoffman@vpnc.org Fri Apr 27 17:09:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599D821E802B; Fri, 27 Apr 2012 17:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZysItmHjQLA; Fri, 27 Apr 2012 17:09:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A62DF21E8027; Fri, 27 Apr 2012 17:09:56 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3S09pbD001221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2012 17:09:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F96D157.7020504@isode.com> Date: Fri, 27 Apr 2012 17:09:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> References: <4F96D157.7020504@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1257) Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 00:09:57 -0000 On Apr 24, 2012, at 9:14 AM, Alexey Melnikov wrote: > Major Issue: none, although a) I am agreeing with Peter Saint-Andre's = major issue and b) I would like to see a reply to my minor issues Here you go. > Minor Issues: >=20 > 2.2. TLSA RR Presentation Format >=20 > The presentation format of the RDATA portion is as follows: >=20 > Presentation for what purpose? In management UIs? Is this a required = presentation format for DNS tools that can retrieve and update TLSA = records? Added a pointer to RFC 1035. > [...] >=20 > o The certificate association data field MUST be represented as a > string of hexadecimal characters. Whitespace is allowed within > the string of hexadecimal characters. >=20 > Please define what you mean by whitespace here? CR & LFs allowed? > Examples in the Section 2.3 seem to suggest that. Should be covered by the (new) reference to RFC 1035. > 3. Domain Names for TLS Certificate Associations >=20 > 2. The protocol name of the transport on which a TLS-based service > is assumed to exist is prepended with an underscore character > ("_") to become the second left-most label in the prepared = domain > name. The transport names defined for this protocol are "tcp", > "udp" and "sctp". >=20 > DCCP? No. > Should there be a registry? Seems like overkill for how rarely new popular transports get added. = Such a transport is going to need to have an RFC for this anyway. > 4. Use of TLSA Records in TLS >=20 > Section 2.1 of this document defines the mandatory matching rules = for > the data from the TLSA certificate associations and the certificates > received from the TLS server. >=20 > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. >=20 > So this will not work for any type of DNS indirection mechanism, such = as MX, SRV, etc? Correct. > Or does DNS retrieval of such records also requires DNSSec? Undefined, as the draft says. --Paul Hoffman From paul@nohats.ca Sat Apr 28 06:57:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7BD21F8687; Sat, 28 Apr 2012 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxDyzfeA6MFg; Sat, 28 Apr 2012 06:57:02 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 48F8421F8686; Sat, 28 Apr 2012 06:57:01 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 5D8328036B; Sat, 28 Apr 2012 09:57:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 4F9DA80358; Sat, 28 Apr 2012 09:57:00 -0400 (EDT) Date: Sat, 28 Apr 2012 09:57:00 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexey Melnikov , iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 13:57:02 -0000 On Fri, 27 Apr 2012, Paul Hoffman wrote: >> 4. Use of TLSA Records in TLS >> >> Section 2.1 of this document defines the mandatory matching rules for >> the data from the TLSA certificate associations and the certificates >> received from the TLS server. >> >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. >> >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc? > > Correct. I'm a little confused here. If I have: example.com IN MX 5 mail.example.com mail.example.com IN TLSA [....] That should still work right? When you do the lookup for mail.example.com's A or AAAA record, you also lookup the TLSA/HASTLS record for _25._tcp.mail.example.com ? If mail.example.com is a CNAME, I understand there are some indirections at play (though it might be technically incorrect to point an MX to a CNAME) Paul From alexey.melnikov@isode.com Sat Apr 28 15:44:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0ED521F8618; Sat, 28 Apr 2012 15:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KjEXLWGbUFa; Sat, 28 Apr 2012 15:44:02 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C38A021F8611; Sat, 28 Apr 2012 15:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335653040; d=isode.com; s=selector; i=@isode.com; bh=LMKtB8vPwjd1IriNbxnuKgE7HOalzIB8hOs8GTOA764=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=BV8cq6qO6m6z0P2DbxqLBhd67rrrSRnopeC3o/XognStmlmk4eVyW15ReKIdhw9QXlHnhv BT0chmhC9JbfTIZw3EaJ455eFwXFZgi0x0NeIIhqZFE2mzfUMxZGBkOVOsx0ARsPLVedov 8As8KNzYb7NmHJ3NMy7z34Tt0qNnUbs=; Received: from [188.29.41.183] (188.29.41.183.threembb.co.uk [188.29.41.183]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 28 Apr 2012 23:43:59 +0100 References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> In-Reply-To: <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> Message-Id: <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Sat, 28 Apr 2012 23:40:59 +0100 To: Paul Hoffman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 22:44:02 -0000 Hi Paul, On 28 Apr 2012, at 01:09, Paul Hoffman wrote: > On Apr 24, 2012, at 9:14 AM, Alexey Melnikov wrote: >=20 >> Major Issue: none, although a) I am agreeing with Peter Saint-Andre's maj= or issue and b) I would like to see a reply to my minor issues >=20 > Here you go. >=20 >> Minor Issues: >>=20 >> 2.2. TLSA RR Presentation Format >>=20 >> The presentation format of the RDATA portion is as follows: >>=20 >> Presentation for what purpose? In management UIs? Is this a required pres= entation format for DNS tools that can retrieve and update TLSA records? >=20 > Added a pointer to RFC 1035. >=20 >> [...] >>=20 >> o The certificate association data field MUST be represented as a >> string of hexadecimal characters. Whitespace is allowed within >> the string of hexadecimal characters. >>=20 >> Please define what you mean by whitespace here? CR & LFs allowed? >> Examples in the Section 2.3 seem to suggest that. >=20 > Should be covered by the (new) reference to RFC 1035. We shall see ;) >=20 >> 3. Domain Names for TLS Certificate Associations >>=20 >> 2. The protocol name of the transport on which a TLS-based service >> is assumed to exist is prepended with an underscore character >> ("_") to become the second left-most label in the prepared domain >> name. The transport names defined for this protocol are "tcp", >> "udp" and "sctp". >>=20 >> DCCP? >=20 > No. Why not? >=20 >> Should there be a registry? >=20 > Seems like overkill for how rarely new popular transports get added. Such a= transport is going to need to have an RFC for this anyway. I don't see a point though, unless the new transport doesn't use ports. But anyway, I am sure that you can just piggyback on an existing registry. >=20 >> 4. Use of TLSA Records in TLS >>=20 >> Section 2.1 of this document defines the mandatory matching rules for >> the data from the TLSA certificate associations and the certificates >> received from the TLS server. >>=20 >> The TLS session that is to be set up MUST be for the specific port >> number and transport name that was given in the TLSA query. >>=20 >> So this will not work for any type of DNS indirection mechanism, such as M= X, SRV, etc? >=20 > Correct. How? >=20 >> Or does DNS retrieval of such records also requires DNSSec? >=20 > Undefined, as the draft says. >=20 Best Regards, Alexey From paul.hoffman@vpnc.org Sat Apr 28 16:55:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722821F860B; Sat, 28 Apr 2012 16:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5GDRyebCKcD; Sat, 28 Apr 2012 16:55:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6D421F8607; Sat, 28 Apr 2012 16:55:11 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3SNt9Wr045896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Apr 2012 16:55:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> Date: Sat, 28 Apr 2012 16:55:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1257) Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 23:55:12 -0000 On Apr 28, 2012, at 3:40 PM, Alexey Melnikov wrote: >>> DCCP? >>=20 >> No. >=20 > Why not? Because DCCP is a thinly-used protocol that nearly no one in this WG has = experience with. What's the chance we will get inclusion of it correct? = It would be better to have someone write a DCCP-specific update that = covers the topic well. >>> So this will not work for any type of DNS indirection mechanism, = such as MX, SRV, etc? >>=20 >> Correct. >=20 > How? How will it not work? Quite well, I expect. :-) This was discussed extensively on the list, and the WG decided that = indirection mechanisms need to define the relationship between the name = used in the lookup and certificate association from DANE TLS. There is = text about this in the document, and more going in the next draft at the = request of Peter St. Andre. The experience with RFC 6125 pretty much = assures that any generic solution will not be interoperable and might = cause security problems based on false matches, and we wanted to avoid = that. --Paul Hoffman From cloos@jhcloos.com Sat Apr 28 17:22:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C2521F85BD; Sat, 28 Apr 2012 17:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPBkAgsjz9l1; Sat, 28 Apr 2012 17:22:02 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE2921F84EC; Sat, 28 Apr 2012 17:22:02 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 87987401BD; Sun, 29 Apr 2012 00:21:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335658920; bh=J4OSoBvus2+aaauV27ERSEFgFjujuTxPu956MK11cvQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=lnLn/6qdTROtMLNKwnsoFDBaxVqGEofOT6liaYSjGlR8sGDHvVtdSYVfXGiS/eHJf gcP9veI7+CduSux+Me3euRi4/pdRZisYYJJ5v43JR9KpCGCuo4YCLKqZpolERrxCXZ LFmSdQoXqxhd34RhGbNrF+yuPWjGSJMyuD2Z7foM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id E93F636004C; Sun, 29 Apr 2012 00:19:22 +0000 (UTC) From: James Cloos To: Paul Hoffman In-Reply-To: <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> (Paul Hoffman's message of "Sat, 28 Apr 2012 16:55:09 -0700") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 28 Apr 2012 20:19:22 -0400 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain Cc: Alexey Melnikov , "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 00:22:03 -0000 >>>>> "PH" == Paul Hoffman writes: PH> Because DCCP is a thinly-used protocol that nearly no one in this WG PH> has experience with. What's the chance we will get inclusion of it PH> correct? It would be better to have someone write a DCCP-specific PH> update that covers the topic well. What is there to get wrong? For SRV, rfc-2782 says: Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive. and that is the type of language TLSA should use for the proto. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From alexey.melnikov@isode.com Sun Apr 29 03:42:20 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A6121F8542; Sun, 29 Apr 2012 03:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRx5JK9IOrJh; Sun, 29 Apr 2012 03:42:19 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34421F8540; Sun, 29 Apr 2012 03:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335696136; d=isode.com; s=selector; i=@isode.com; bh=W2sohSlhAlyC8znkLMjJ/30Y/6EGJiPJ9bh3fjtDTYc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WnC0407p677VY2pjm9gkqfqE04S6uVS9aWwbgfVpL1HtvW7m9E/3TsbTn832g4e3ifIYMZ /A2pY3nzWZ/75ZArwg/xZFhhVx89mLHi4fy5oA+4BIbWxRVtOZ17S1qJfnC7t9i79LFVeY E8SMrRCbW6c8ZyvgBtDCjCy5S7tk2rI=; Received: from [188.29.134.82] (188.29.134.82.threembb.co.uk [188.29.134.82]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Apr 2012 11:42:16 +0100 References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> In-Reply-To: <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> Message-Id: <16165BCD-33C7-4B37-A3C8-89260CA4A934@isode.com> X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Sun, 29 Apr 2012 11:42:15 +0100 To: Paul Hoffman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 10:42:20 -0000 On 29 Apr 2012, at 00:55, Paul Hoffman wrote: > On Apr 28, 2012, at 3:40 PM, Alexey Melnikov wrote: >=20 >>>> DCCP? >>>=20 >>> No. >>=20 >> Why not? >=20 > Because DCCP is a thinly-used protocol that nearly no one in this WG has e= xperience with. What's the chance we will get inclusion of it correct? It wo= uld be better to have someone write a DCCP-specific update that covers the t= opic well. I think this requires inserting 2 words. But Transport ADs will get on your c= ase if they care. >=20 >>>> So this will not work for any type of DNS indirection mechanism, such a= s MX, SRV, etc? >>>=20 >>> Correct. >>=20 >> How? >=20 > How will it not work? Quite well, I expect. :-) Sorry, missed "not" in my own earlier email ;). >=20 > This was discussed extensively on the list, and the WG decided that indire= ction mechanisms need to define the relationship between the name used in th= e lookup and certificate association from DANE TLS. There is text about this= in the document, and more going in the next draft at the request of Peter S= t. Andre. The experience with RFC 6125 pretty much assures that any generic s= olution will not be interoperable and might cause security problems based on= false matches, and we wanted to avoid that. From paul.hoffman@vpnc.org Sun Apr 29 06:58:54 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D221F84EB; Sun, 29 Apr 2012 06:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epE4oE+GCbcc; Sun, 29 Apr 2012 06:58:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2921F84E7; Sun, 29 Apr 2012 06:58:53 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3TDwopa065921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Apr 2012 06:58:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <16165BCD-33C7-4B37-A3C8-89260CA4A934@isode.com> Date: Sun, 29 Apr 2012 06:58:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0876ADD6-999C-43E3-9EFB-31F256CCCD3A@vpnc.org> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <243C7ECF-1936-43AC-9F1C-C2E7401BB700@isode.com> <6B0B9F1C-1ADB-4965-9632-C902245DB0E5@vpnc.org> <16165BCD-33C7-4B37-A3C8-89260CA4A934@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1257) Cc: "iesg@ietf.org" , "apps-discuss@ietf.org" , "dane@ietf.org" Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 13:58:54 -0000 On Apr 29, 2012, at 3:42 AM, Alexey Melnikov wrote: > On 29 Apr 2012, at 00:55, Paul Hoffman wrote: >=20 >> On Apr 28, 2012, at 3:40 PM, Alexey Melnikov wrote: >>=20 >>>>> DCCP? >>>>=20 >>>> No. >>>=20 >>> Why not? >>=20 >> Because DCCP is a thinly-used protocol that nearly no one in this WG = has experience with. What's the chance we will get inclusion of it = correct? It would be better to have someone write a DCCP-specific update = that covers the topic well. >=20 > I think this requires inserting 2 words. But Transport ADs will get on = your case if they care. If the Transport ADs care and are willing to say "the spec doesn't need = to know anything about DCCP, just add it", I suspect the WG would be = happy to add it. (We're happy to hear from them now, before we do the = final draft before IESG review, of course.) --Paul Hoffman From gnu@toad.com Sun Apr 29 16:09:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11B321F8496; Sun, 29 Apr 2012 16:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.404 X-Spam-Level: X-Spam-Status: No, score=0.404 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaJYJ8KB6kPB; Sun, 29 Apr 2012 16:09:16 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id DCDCE21F85DB; Sun, 29 Apr 2012 16:09:15 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3TN9BcF027057; Sun, 29 Apr 2012 16:09:11 -0700 Message-Id: <201204292309.q3TN9BcF027057@new.toad.com> To: Paul Wouters In-reply-to: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> Comments: In-reply-to Paul Wouters message dated "Sat, 28 Apr 2012 09:57:00 -0400." Date: Sun, 29 Apr 2012 16:09:11 -0700 From: John Gilmore Cc: Alexey Melnikov , dane@ietf.org, Paul Hoffman , "apps-discuss@ietf.org" , iesg@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 23:09:16 -0000 > >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc? TLSA is expected to work with TLS-based services reached via MX records, as well as with services that use TLS which are reached via SRV records. There has been a lot of confused and/or confusing discussion that started from this unclear question. ("This will not work...?" -- what is "this"? And why in specific do you think it will or won't work?) I suggest that to eliminate the confusion, we start over with a clearer question. Give us a concrete example and ask if it will work. If the draft doesn't already answer the question, we can fix the draft so it will. So, for example, to secure STARTTLS in SMTP, you'd use: toad.com. MX 150 new.toad.com. _25._tcp.new.toad.com. TLSA ...(a key or certificate for new.toad.com)... new.toad.com. A 209.237.225.253 new.toad.com. AAAA 2607:f3a0:17::2 John PS: While I think our document should be readable by people without deep knowledge (and thus I've contributed a bunch of introductory text), I'm dismayed to see IETF "Director" reviews that betray ignorance of very basic concepts around the Domain Name System, such as presentation formats of resource records, or A and AAAA records. From paul.hoffman@vpnc.org Sun Apr 29 16:28:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0770B21F85C9; Sun, 29 Apr 2012 16:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqzHtNUYcPLb; Sun, 29 Apr 2012 16:28:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDE421F85B1; Sun, 29 Apr 2012 16:28:22 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3TNSIvW080743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Apr 2012 16:28:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201204292309.q3TN9BcF027057@new.toad.com> Date: Sun, 29 Apr 2012 16:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1257) Cc: Alexey Melnikov , Paul Wouters , iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 23:28:23 -0000 On Apr 29, 2012, at 4:09 PM, John Gilmore wrote: >>>> So this will not work for any type of DNS indirection mechanism, = such as MX, SRV, etc? >=20 > TLSA is expected to work with TLS-based services reached via MX > records, as well as with services that use TLS which are reached via > SRV records. You may have missed the earlier discussion of this topic, and the fact = that the topic was closed with a result different than what you say = here. Please see . If the WG chairs think that Jakob and I have not reflected the WG = consensus from that issue in the document, we are happy to update the = document yet again. --Paul Hoffman From internet-drafts@ietf.org Sun Apr 29 16:40:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603B321F85CC; Sun, 29 Apr 2012 16:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akHR57nPCh6G; Sun, 29 Apr 2012 16:40:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E0F21F85A3; Sun, 29 Apr 2012 16:40:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120429234044.31904.88606.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 16:40:44 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-20.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 23:40:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Ent= ities Working Group of the IETF. Title : The DNS-Based Authentication of Named Entities (DANE) Tr= ansport Layer Security (TLS) Protocol: TLSA Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-20.txt Pages : 34 Date : 2012-04-29 Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dane-protocol-20.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ From paul.hoffman@vpnc.org Sun Apr 29 16:45:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B5A21F85D5 for ; Sun, 29 Apr 2012 16:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpZ6TTf2AKNc for ; Sun, 29 Apr 2012 16:45:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D467221F85D4 for ; Sun, 29 Apr 2012 16:45:25 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3TNjOPT081193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 29 Apr 2012 16:45:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Apr 2012 16:45:24 -0700 Message-Id: <6CC342E4-035B-4C4A-B4DD-912FDA1B73D0@vpnc.org> To: IETF DANE WG list Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [dane] Draft -20 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 23:45:26 -0000 Greetings again. Jakob and I have made the editorial and substantiative = changes requested in IETF Last Call. If the WG Chairs think we caught = everything, we request that they pass this along to the AD so the = document can be considered by the IESG. If we missed anything, we can = make more changes. We also request that the WG chairs close out issues #39 and #40 on the = tracker. We didn't do #40 because there was no resolution; let us know = if we should have done something different. --Paul Hoffman From marka@isc.org Sun Apr 29 16:58:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D9E21F85D7; Sun, 29 Apr 2012 16:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28nlu-NodNHH; Sun, 29 Apr 2012 16:58:24 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC721F85D5; Sun, 29 Apr 2012 16:58:24 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F413E5F9BE5; Sun, 29 Apr 2012 23:58:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b5d8:f629:ce61:7da7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DAB2D216C31; Sun, 29 Apr 2012 23:58:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B8FB32036A98; Mon, 30 Apr 2012 09:58:01 +1000 (EST) To: John Gilmore From: Mark Andrews References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> In-reply-to: Your message of "Sun, 29 Apr 2012 16:09:11 MST." <201204292309.q3TN9BcF027057@new.toad.com> Date: Mon, 30 Apr 2012 09:58:01 +1000 Message-Id: <20120429235801.B8FB32036A98@drugs.dv.isc.org> Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 29 Apr 2012 23:58:25 -0000 In message <201204292309.q3TN9BcF027057@new.toad.com>, John Gilmore writes: > > >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc? > > TLSA is expected to work with TLS-based services reached via MX > records, as well as with services that use TLS which are reached via > SRV records. > > There has been a lot of confused and/or confusing discussion that > started from this unclear question. ("This will not work...?" -- what > is "this"? And why in specific do you think it will or won't work?) > > I suggest that to eliminate the confusion, we start over with a > clearer question. Give us a concrete example and ask if it will work. > If the draft doesn't already answer the question, we can fix the draft > so it will. > > So, for example, to secure STARTTLS in SMTP, you'd use: > > toad.com. MX 150 new.toad.com. > _25._tcp.new.toad.com. TLSA ...(a key or certificate for new.toad.com)... > new.toad.com. A 209.237.225.253 > new.toad.com. AAAA 2607:f3a0:17::2 > > John Part of the problem is that there is at least two models "STARTTLS in SMTP" and "HTTPS". With "STARTTLS in SMTP" the MX record (implicit or explicit) defines the expected certificate name. With "HTTPS" the user input/href defines the expected certificate name even if you encounter a CNAME record. Add a CNAME to your example and it become decidedly less clear which name to expect in the certificate (mail.toad.com or new.toad.com or either). i.e. does the CNAME change the expected certificate name or not? We have don't have a clear answer to this in the current RFCs a far as I am aware. toad.com. MX 150 mail.toad.com. mail.toad.com. CNAME new.toad.com. new.toad.com. A 209.237.225.253 new.toad.com. AAAA 2607:f3a0:17::2 Which TLSA record does the client MTA lookup? _25._tcp.mail.toad.com. TLSA ...(a key or certificate for mail.toad.com)... or _25._tcp.new.toad.com. TLSA ...(a key or certificate for new.toad.com)... Then there are CNAMEs when looking up the TLSA record itself. _25._tcp.new.toad.com. CNAME cane.toad.com. cane.toad.com TLSA ..... Mark > PS: While I think our document should be readable by people without > deep knowledge (and thus I've contributed a bunch of introductory > text), I'm dismayed to see IETF "Director" reviews that betray > ignorance of very basic concepts around the Domain Name System, > such as presentation formats of resource records, or A and AAAA records. > _______________________________________________ > 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 gnu@toad.com Sun Apr 29 20:16:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2621F84A0; Sun, 29 Apr 2012 20:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.384 X-Spam-Level: X-Spam-Status: No, score=0.384 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugckGaNNeJro; Sun, 29 Apr 2012 20:16:16 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) by ietfa.amsl.com (Postfix) with ESMTP id 01D4921F847C; Sun, 29 Apr 2012 20:16:15 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id q3U3GFcF002018; Sun, 29 Apr 2012 20:16:15 -0700 Message-Id: <201204300316.q3U3GFcF002018@new.toad.com> To: Paul Hoffman In-reply-to: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> Comments: In-reply-to Paul Hoffman message dated "Sun, 29 Apr 2012 16:28:18 -0700." Date: Sun, 29 Apr 2012 20:16:15 -0700 From: John Gilmore Cc: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 03:16:17 -0000 [Does this discussion really need to be cc'd to apps-discuss and iesg? I am keeping the distribution as it was, but I suggest cutting it back to just "dane". --gnu] > > TLSA is expected to work with TLS-based services reached via MX > > records, as well as with services that use TLS which are reached via > > SRV records. > > You may have missed the earlier discussion of this topic, and the fact that the topic was closed with a result different than what you say here. Please see . I looked at Ticket 28 and it is not clear to me what the resolution is. Its resolution was: "use the first name that has a TLSA record, unless there is a protocol specific exception" I don't know what that means in the context of MX nor SRV. Does that mean that SRV will work, that SRV will fail, or does it mean something else entirely? If it means something else entirely, then it does not contradict my statement that TLSA is expected to work with SRV. It is not clear to me what is the "first name" in the above statement, nor what other names are potentially in line behind it. The phrase "first name that has a TLSA record" seems to imply iteration through a series of names until a TLSA record is found. I could imagine that it means, in the context of MX for example, if mail is sent to gnu@example.com and example.com has an MX to mailserver.example.com, then you would look for TLSA records "first" at example.com and "second" at mailserver.example.com and "third" at nowhere else (you'd decide that there are no TLSA records). But this is not actually specified anywhere in the ticket. So I looked in Draft 20, and I don't see anything that says "MX and SRV WILL NOT work with TLSA". Nor do I see anything that says "MX and SRV WILL work with TLSA". I don't even see a statement that clients should "use the first name that has a TLSA record" as recorded in ticket 28. Section 4, "Use of TLSA Records in TLS" just says to look in Section 2.1 for the "mandatory matching rules". But Section 2.1 mentions nothing about matching NAMES; it is all about matching certificates, hashes, and keys. Section 3, "Domain Names for TLSA Certificate Associations", step 3, just says "The domain name is appended" without saying WHICH domain name is appended. So the draft is unclear. In the absence of any explicit statement, I apply my experience. First, MX and SRV appear to me to be different issues. There seems to be a consensus among recent discussions on the mailing list that MX should work without trouble. Numerous people have posted example sets of DNS records that the posters believe would work, and there were no counterexamples other than some byplay about CNAMEs. There is even an example TLSA record for SMTP email delivery in Draft 20. There is an issue about what name should be in the TLS server's end-user certificate when using a service that has DNS records that provide one or more domain names of servers which handle that service. In what follows I call the original name the "service name", e.g. "example.com", and the names of servers who provide that service the "server names", e.g. mailserver.example.com. Does the TLS client demand a certificate that includes the service's name, or the server's name? (Or perhaps it accepts either one, or perhaps requires that both be included in the certificate)? Every working TLS implmentation has already solved this issue. It doesn't relate to TLSA records or the DANE protocol at all. If the certificate provided by the server doesn't include the name(s) that the client is expecting to validate, TLS will not work. I do not personally know whether MX clients expect to see the service's domain name in the certificate, or the server's. But I know that many mail servers currently use STARTTLS and it is widely interoperable with many clients, so the answer is easy to come by. DANE does introduce an additional issue about what name should be looked up in the DNS when seeking a TLSA record. Does the client look for a TLSA record at _port._tcp.service.name or at _port._tcp.server.name? Or does it look at both of them, and if so, in what order? The draft does not specify this, perhaps as a result of an inability to decide, which was codified in the inscrutable resolution of Ticket 28. However, draft 20 does provide an illuminating example in the last sentence of section 3: To request a TLSA resource record for an SMTP server running the STARTTLS protocol on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is used. This example does not match what Ticket 28 seems to say, since it provides no iteration, nor is the name of the SMTP server likely to come to the implementer's mind as the "first name". If it turns out that in the absence of specifying this, there is a diversity of client implementations, then at worst, when using a protocol that uses SRV, a server administrator could provide TLSA records at both the service name and the server name. This reasoning is why I stated that TLSA is expected to work with services that use MX and SRV records. I'm happy for someone to clarify why this won't work, or to refute some other part of my chain of reasoning. > If the WG chairs think that Jakob and I have not reflected the WG > consensus from that issue in the document, we are happy to update > the document yet again. I am not a chair, but I don't think Draft 20 is clear about this. I'd alter section 3, step 3, and add a paragraph below it: 3. A domain name is appended to the result of step 2 to produce a prefixed domain name. When a client is making domain name queries in search of TLSA records, it should form a name by appending the first domain name provided to it, and make its first query. If it does not find a TLSA record there, it should form a name from the server name which it is in the process of contacting (for example, the name of one of the servers supplied in MX or SRV records), and seek a TLSA record from that server name. This seems to faithfully reproduce the clear-as-mud description in Ticket #28. However, this results in some semantic confusion, because the prefixed domain name includes a port number for a specific server, yet a suffix that is not related to that server. For example, we'd first look up _25._tcp.example.com while negotiating TLS to deliver mail on port 25 to mailserver.example.com for gnu@example.com. But there may be some completely different service running on port 25 of HOST "example.com", if example.com actually has an IP address. (This is even more confusing for SRV records, which can specify arbitrary port numbers, which might be more likely to be reused for different protocols on different machines.) Also, if there were four MX records for a domain, the client should not look up a TLSA record for the main domain, then look up a TLSA record for the first MX server, then look up a TLSA record for the second MX server. These lookups happen only in a context of trying to negotiate TLS with a *specific* server. When trying to negotiate TLS with the first server, it should not be looking for TLSA records that relate to the second server; it should restrict itself to only looking up the particular server's name that it is talking to (and/or the name of the original main domain). I would be much happier if someone who actually knew what the alleged consensus is would write this update. John From stpeter@stpeter.im Sun Apr 29 22:34:09 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A4021F856A; Sun, 29 Apr 2012 22:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMox+qqvNnuU; Sun, 29 Apr 2012 22:34:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7338D21F8562; Sun, 29 Apr 2012 22:34:08 -0700 (PDT) Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6109740058; Sun, 29 Apr 2012 23:48:58 -0600 (MDT) Message-ID: <4F9E244E.9030007@stpeter.im> Date: Sun, 29 Apr 2012 22:34:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Warren Kumari References: <4F95CA0B.8050202@stpeter.im> <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> <9934BC7B-3193-44D1-870A-69A6F6A1612C@kumari.net> In-Reply-To: <9934BC7B-3193-44D1-870A-69A6F6A1612C@kumari.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org, Paul Hoffman , "apps-discuss@ietf.org" , iesg@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 05:34:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/27/12 12:52 PM, Warren Kumari wrote: > > On Apr 27, 2012, at 2:01 PM, Paul Hoffman wrote: > >> On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote: >> >>> Major Issue: >>> >>> This document does not mention that TLSA records cannot be >>> used directly in application protocols that depend on SRV (or >>> NAPTR or similar technologies). Although I realize that the >>> DANE WG decided, after much discussion, that the interaction >>> between TLSA records and SRV records is out of scope for this >>> specification (and I do not mean to reopen that discussion >>> now), it would be very helpful for this specification to >>> reflect the results of that discussion. Although I make >>> specific suggestions regarding text under the Minor Issues >>> below, in general I think this document needs to be clearer >>> about the assumptions it has made in this regard; in fact, it >>> seems to me that an explicit applicability statement is >>> warranted to avoid confusion of the kind that Dave Cridland >>> experienced (see his Last Call comments). >> >> Now covered in section 1.3, and includes a note that this >> document might be updated in the future to cover such things. >> (Note: it would be grand if an XMPPer would start work on this >> soon so we still have momentum.) > > Yes -- we decided to take the "instead of boiling the ocean / being > all things to all people" approach with the initial doc to instead > publish this and then have "How to do DANE with protocol foo" > documents... This does mean that we want need these docs. They > should be fairly simple to write -- submissions gratefully accepted > :-) Yes, Matt Miller and I plan to work on that one soonish. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eJE4ACgkQNL8k5A2w/vwsfwCgzyk68CMXNjIn5arQvx8eon1+ rhcAnjsgaTZMzGW0zxejGjocHVug3Gkt =Upye -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Apr 29 22:42:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEDE21F85D4; Sun, 29 Apr 2012 22:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxazDOoYum46; Sun, 29 Apr 2012 22:42:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C186A21F85C2; Sun, 29 Apr 2012 22:42:50 -0700 (PDT) Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7221340058; Sun, 29 Apr 2012 23:57:36 -0600 (MDT) Message-ID: <4F9E2652.2050804@stpeter.im> Date: Sun, 29 Apr 2012 22:42:42 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4F95CA0B.8050202@stpeter.im> <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> In-Reply-To: <24B5BD30-385D-4780-AD42-A4D1271DFA83@vpnc.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 05:42:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/27/12 11:01 AM, Paul Hoffman wrote: > On Apr 23, 2012, at 2:30 PM, Peter Saint-Andre wrote: > >> Major Issue: >> >> This document does not mention that TLSA records cannot be used >> directly in application protocols that depend on SRV (or NAPTR or >> similar technologies). Although I realize that the DANE WG >> decided, after much discussion, that the interaction between >> TLSA records and SRV records is out of scope for this >> specification (and I do not mean to reopen that discussion now), >> it would be very helpful for this specification to reflect the >> results of that discussion. Although I make specific suggestions >> regarding text under the Minor Issues below, in general I think >> this document needs to be clearer about the assumptions it has >> made in this regard; in fact, it seems to me that an explicit >> applicability statement is warranted to avoid confusion of the >> kind that Dave Cridland experienced (see his Last Call >> comments). > > Now covered in section 1.3, and includes a note that this document > might be updated in the future to cover such things. Thanks. > (Note: it would be grand if an XMPPer would start work on this soon > so we still have momentum.) Yep, it's on my list. :) >> 5. To those of us accustomed to SRV records, at first glance the >> prefixed DNS domain name format defined in Section 3 looks >> strange: why not _http._tcp.www.example.com instead of >> _443._tcp.www.example.com? But when we take off our SRV-colored >> glasses and realize that DANE assumes a DNS A/AAAA lookup on the >> domain name, it all makes sense. Perhaps it would be helpful to >> mention the reasoning behind the port number (instead of >> application name) here? > > I would rather not try to summarize the debate in the spec, given > that the result (numbers) are completely clear. > >> 6. In section 4, no mention is made of the application service >> that the TLS expects to encounter at the TLS server: >> >> The TLS session that is to be set up MUST be for the specific >> port number and transport name that was given in the TLSA query. >> >> Yet surely the application protocol can matter here, no? > > No. > >> In particular, given that 443 is the one true port, we know that >> folks might run non-HTTP applications over that port (for evil >> reasons, of course). > > Sure. But... > >> Does DANE elide over the application protocol because we simply >> assume that the "right" service is being served over any >> particular port? > > Yes, that's the only sane way to do things currently. (The TLS WG > is discussing adopting a protocol that would complicate this, but > that's a long way off, I suspect.) > >> What about service providers that wish to restrict the usage of >> a certificate to a particular application service type (cf. RFC >> 6125)? > > I'm not sure how this is relevant. There is only one application > protocol that can be running on 443 after TLS is established. > >> Or do we assume that it is enough to differentiate among >> application services based on the underlying transport (as seems >> to be the case in the text on "Multiple Ports" in Section 5)? > > Yes. > >> IMHO we have a bit of a muddle here. > > I don't see it. OK, your reasoning makes sense to me -- at least your reasoning for not including more text in the document at this time. >> 7. The paragraph about SSL proxies in Section 8 says that "the >> TLS client will get a certificate association from the DNS that >> will not match the certificate that the SSL proxy uses with the >> client"; however, if the SSL proxy is working in concert with an >> external DNS validator, is it possible to mimic the behavior of >> current SSL proxies? > > Maybe, but they are undefined. Right, and it's not the job of this document to define them. One more issue is nagging at me: there is no definition or citation for "domain name" in Section 3. In particular, there is no indication of whether internationalized domain names are allowed (and, if so, in what format). I think it would good to make this clear by saying that a domain name can be either a "traditional domain name" (RFC 1034) or an "internationalized domain name" (RFC 5890); for the latter I think it would be best to say that the IDN's internationalized labels are represented only as A-labels. IMHO a short paragraph on this matter would be appropriate in Section 3 or in a new section entitled "Internationalization Considerations". Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eJlIACgkQNL8k5A2w/vyyegCfbbR/3uhm7/N8ipyZKHejRMk5 aa8An09szH1LJO1WyJZVlHCTfnbt8ObN =7Mx5 -----END PGP SIGNATURE----- From ned.freed@mrochek.com Sun Apr 29 22:59:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63FD21F84E7; Sun, 29 Apr 2012 22:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5pDhHS21UGN; Sun, 29 Apr 2012 22:59:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8321F8534; Sun, 29 Apr 2012 22:59:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEWP14NLOW000T1E@mauve.mrochek.com>; Sun, 29 Apr 2012 22:59:24 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Sun, 29 Apr 2012 22:59:19 -0700 (PDT) Message-id: <01OEWP11R5NK0006TF@mauve.mrochek.com> Date: Sun, 29 Apr 2012 22:42:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Apr 2012 09:58:01 +1000" <20120429235801.B8FB32036A98@drugs.dv.isc.org> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> To: Mark Andrews Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 05:59:37 -0000 > In message <201204292309.q3TN9BcF027057@new.toad.com>, John Gilmore writes: > > > >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc? > > > > TLSA is expected to work with TLS-based services reached via MX > > records, as well as with services that use TLS which are reached via > > SRV records. > > > > There has been a lot of confused and/or confusing discussion that > > started from this unclear question. ("This will not work...?" -- what > > is "this"? And why in specific do you think it will or won't work?) > > > > I suggest that to eliminate the confusion, we start over with a > > clearer question. Give us a concrete example and ask if it will work. > > If the draft doesn't already answer the question, we can fix the draft > > so it will. > > > > So, for example, to secure STARTTLS in SMTP, you'd use: > > > > toad.com. MX 150 new.toad.com. > > _25._tcp.new.toad.com. TLSA ...(a key or certificate for new.toad.com)... > > new.toad.com. A 209.237.225.253 > > new.toad.com. AAAA 2607:f3a0:17::2 > > > > John > Part of the problem is that there is at least two models "STARTTLS > in SMTP" and "HTTPS". With "STARTTLS in SMTP" the MX record (implicit > or explicit) defines the expected certificate name. With "HTTPS" > the user input/href defines the expected certificate name even if you > encounter a CNAME record. > Add a CNAME to your example and it become decidedly less clear which > name to expect in the certificate (mail.toad.com or new.toad.com > or either). i.e. does the CNAME change the expected certificate > name or not? We have don't have a clear answer to this in the > current RFCs a far as I am aware. > toad.com. MX 150 mail.toad.com. > mail.toad.com. CNAME new.toad.com. > new.toad.com. A 209.237.225.253 > new.toad.com. AAAA 2607:f3a0:17::2 > Which TLSA record does the client MTA lookup? I'm taking no position on TLSA here, but FWIW, it actually isn't clear what host the client should connect to in this case, or that this is not in fact a DNS configuration error. RFC 974 recommended that CNAMEs not be allowed as MX targets. (See the section on "Minor Special Issues" for details.) I believe RFC 2821 was silent on the issue, but the current specification, RFC 5321, has this to say: When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3 [38]. My understanding of the reasoning behind this is that we would prefer to ban CNAMEs in the context for the reasons given in RFC 2181, but since a lot of software uses A/AAAA record resolvers that support aliasing that cannot be disabled, this is where things ended up. Also FWIW, what existing software that suports STARTTLS seems do is check the domain in the certificate against the host name in the MX record that was used to connect to the current host. At least that's been my experience. Ned From sm@resistor.net Mon Apr 30 01:31:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EC621F85FF; Mon, 30 Apr 2012 01:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41kCQ6Qez58g; Mon, 30 Apr 2012 01:31:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C0421F85FC; Mon, 30 Apr 2012 01:31:38 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3U8VUJx004957; Mon, 30 Apr 2012 01:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335774697; i=@resistor.net; bh=MocHO4x/Y4rKq/WuI2W2voROHgFbfzjiscGyuI2ghqA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oHaTZfq1ovJfZnK0UvP76Ov4cym9BHffhDMgU8nkabBfL8cuHlxdaSrnBsy5+E6bp 9j9760JAwpwfrqfO+jpm2t+qtVKhFyVipR/cAeNmN7deed2xvJwT0qfhoZF5HFR2pp 3Ida45IgAq4flGmP2EH3sxAvWYk4m3lf4USeAfa8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1335774697; i=@resistor.net; bh=MocHO4x/Y4rKq/WuI2W2voROHgFbfzjiscGyuI2ghqA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DlcTxdZ9Rcs4yoyPnFRUYy9aWBL11uZoXEyYePOPT89f3XKsUj0gG8LNFYtfI5SqU kO3e5kKktwYVE5Zw3q0H+1W2BAfY2RfuzAFSG6KCzNGdFQGQdmSmQqtZ08PMa+Mct/ wNtf9BI4/laJJd/0wwwLK8lJQSg6LatU+0QKgupw= Message-Id: <6.2.5.6.2.20120429224742.08c3b1f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 30 Apr 2012 01:23:25 -0700 To: Mark Andrews From: SM In-Reply-To: <20120429235801.B8FB32036A98@drugs.dv.isc.org> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 08:31:39 -0000 At 16:58 29-04-2012, Mark Andrews wrote: >Part of the problem is that there is at least two models "STARTTLS Yes. >Add a CNAME to your example and it become decidedly less clear which >name to expect in the certificate (mail.toad.com or new.toad.com >or either). i.e. does the CNAME change the expected certificate >name or not? We have don't have a clear answer to this in the >current RFCs a far as I am aware. Section 5.1 of RFC 5321 mentions that MX RRs with a CNAME in the R.H.S is out of scope. It seems that the main question here is about DNS indirection. Paul Hoffman clarified that ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05419.html ). Section 2 of -20 mentions that: 'The TLSA DNS resource record (RR) is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a "TLS certificate association".' Section 3 mentions that: 'Unless there is a protocol-specific specification that is different than this one, TLSA resource records are stored at a prefixed DNS domain name.' Given that HTTPS and STARTTLS is mentioned in the document by example, it looks like the specification should be applicable as-is for these protocols. Using www.apple.com as an example for HTTPS: ;; QUESTION SECTION: ;www.apple.com. IN A ;; ANSWER SECTION: www.apple.com. 1800 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 18278 IN CNAME e3191.c.akamaiedge.net. e3191.c.akamaiedge.net. 20 IN A 184.30.253.15 I assume that the TLS-based service is at e3191.c.akamaiedge.net. As there is a CN-ID (the back-compatibility clause in RFC 6125) of www.apple.com, it should be possible to derive a certification association. Using universalmusic.com and microsoft.com as examples for STARTTLS: ;; QUESTION SECTION: ;universalmusic.com. IN MX ;; ANSWER SECTION: universalmusic.com. 3600 IN MX 10 mail.global.frontbridge.com. ;; QUESTION SECTION: ;microsoft.com. IN MX ;; ANSWER SECTION: microsoft.com. 3600 IN MX 10 mail.messaging.microsoft.com. It is not possible to come up with a certificate association in the second case. My reading of prepared DNS domain name in Section 3 of draft-ietf-dane-protocol-20 is that it is akin to derived domains in RFC 6125. I encourage the authors of that RFC to correct me as I might be doing an egregious extrapolation of the intent of the text. There is a note in Section 1.3 of the draft as follows: "Note that this document does not cover how to associate certificates with domain names for application protocols that depend on SRV, NAPTR, and similar DNS resource records; it is expected that later updates to this document might cover methods for making those associations." I don't see much difference between SRV and MX in terms of locating a service through DNS. In Section 8: "A DNS administrator who goes rogue and changes both the A, AAAA, and/or TLSA records for a domain name can cause the user to go to an unauthorized server that will appear authorized, unless the client performs PKIX certification path validation and rejects the certificate." Does the above also cover a change in CNAME? BTW, there are a few typos (certifcate). Regards, -sm From cloos@jhcloos.com Mon Apr 30 01:50:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFFF21F8582; Mon, 30 Apr 2012 01:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TztYYZcSHTFN; Mon, 30 Apr 2012 01:50:20 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id E575221F85CF; Mon, 30 Apr 2012 01:50:18 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 042E34017D; Mon, 30 Apr 2012 08:49:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335775817; bh=N3tlGOuCkENQlFc/ShmDXF4+jrmYKypcXMuhN2L2WBc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VsOXTpSUNJOh8ZUleAPyu1ivXPcxRU1PGUe5F4GBLt9a4zsn59AvbsiCyc0sSY1Um Y7lIAJ6eZZtfRF97fHH34dI1uy2B7OnbEK++2vcll8V5PuMkZMRAlRPbIf4I/ZfbMP 8n/PMZjuzj71t6IX2EsLz24J3FQngbL0oDZTG5oU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C0EE136004C; Mon, 30 Apr 2012 08:40:33 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <201204300316.q3U3GFcF002018@new.toad.com> (John Gilmore's message of "Sun, 29 Apr 2012 20:16:15 -0700") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 30 Apr 2012 04:40:33 -0400 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , Paul Hoffman , iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 08:50:22 -0000 John's post exactly illustrates why I've been advocating always doing TLSA lookups for the port and name for which the client is making an A/AAAA or PTR lookup¹. Ie, from the results of the NAPTR, SRV and/or MX. Except only for cases which /explicitly/ specify different behaviour. :) RFC 3923 says that XMPP -- the oft-cited counter example -- requires certs to have subjectAltName values which look like email addresses, rather than like host names. XMPP, therefore, isn't actually relevant to draft-ietf-dane-protocol, but rather to the forthcoming draft about public key data for TLS client certs. The exceptions should be few and far-between. And they should require their own rfc referencing and modifying TLSA for their own needs. 1] If an address rather than a name is supplied, one must choose between doing a PTR to get a name and a TLSA on that name to get the cert info, or doing a TLSA on the address. Either way, one shoudl expect the cert to have a CN and/or subjectAltName which matches the name returned by the PTR lookup. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paf@frobbit.se Sun Apr 29 18:16:51 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FFD21F8554; Sun, 29 Apr 2012 18:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Su7eW-2yPnvU; Sun, 29 Apr 2012 18:16:50 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40C21F850C; Sun, 29 Apr 2012 18:16:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id D469713ACFFEE; Mon, 30 Apr 2012 03:16:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c47jGgzrV2UB; Mon, 30 Apr 2012 03:16:47 +0200 (CEST) Received: from [192.165.72.14] (unknown [192.165.72.14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 8A95313ACFFE1; Mon, 30 Apr 2012 03:16:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120429235801.B8FB32036A98@drugs.dv.isc.org> Date: Mon, 30 Apr 2012 03:16:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Mon, 30 Apr 2012 01:56:48 -0700 Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 01:16:51 -0000 On 30 apr 2012, at 01:58, Mark Andrews wrote: > toad.com. MX 150 mail.toad.com. > mail.toad.com. CNAME new.toad.com. Mark, I must admit I do not remember what your personal view is on = MX->CNAME chains, but I am a strong believer in that this is something = that is not accepted. Yes, I know for example sendmail and possibly = other implementations do handle MX->CNAME constructions, but = recommendations are to not construct the namespace like this. MX target = should be an address record. Just like NS targets. Patrik From sm@elandsys.com Sun Apr 29 18:38:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC05E21F85D7; Sun, 29 Apr 2012 18:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN5K53C714wW; Sun, 29 Apr 2012 18:38:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA13721F852E; Sun, 29 Apr 2012 18:38:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.53]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3U1cLYF026135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2012 18:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1335749913; i=@elandsys.com; bh=zgo69XtG4V4R/YzY5Evwa3vP/dQF6X/78lLw7mfFFDc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pPeowLic8MMFEF88s/viD8Sk5m2QtHNc37hKPTnGynYpZmZsfFXoIpaHQRmVra6RK sL+oEU429FgVBowXN4UDUNe5bny6nEoHMtOpCFRzp1U/l8GyfXQtwHwf4JJKnQGoCD U/lTbqLPQw8frdX46/6jSAErmi1DXpMDTsOIekbE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1335749913; i=@elandsys.com; bh=zgo69XtG4V4R/YzY5Evwa3vP/dQF6X/78lLw7mfFFDc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bVHcg6LrYBcHDNTDWTiCVKDLvSCHannH6usUkVuOHWPAzJ/qo0e4UV4CEIgKFTsEO TU5mu22Bbg4KTJpOSYpwSISeeSrQoMqYSGwek0E7LEtSwIrElt7Pc8MVKEJ8cN//vr lIxHkTdbQEqiYVqgoYSmllDs27q79klaHeamHluo= Message-Id: <6.2.5.6.2.20120429170402.096d3a20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 29 Apr 2012 18:33:50 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <201204292309.q3TN9BcF027057@new.toad.com> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 30 Apr 2012 01:56:48 -0700 Cc: dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 01:38:39 -0000 At 16:09 29-04-2012, John Gilmore wrote: >text), I'm dismayed to see IETF "Director" reviews that betray >ignorance of very basic concepts around the Domain Name System, >such as presentation formats of resource records, or A and AAAA records. Application Area Directorate reviews are informal; they do not bear more weight than a comment submitted by an individual during a Last Call. The reviewer who commented on draft-ietf-dane-protocol-19 on behalf of the Applications Area Directorate must have understood the concepts around the Domain Name System as STD 13 is a normative reference in the draft. That does not mean that the reviews should be considered as flawless. The reviews are posted to apps-discuss@ietf.org, which is open to everyone, so that anyone can read and discuss about them. Regards, S. Moonesamy From fanf2@hermes.cam.ac.uk Mon Apr 30 03:44:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2C821F85B5; Mon, 30 Apr 2012 03:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2f1Wh6R52LJ; Mon, 30 Apr 2012 03:44:15 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8A59F21F85AF; Mon, 30 Apr 2012 03:44:15 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38316) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SOo5T-0003sA-EA (Exim 4.72) (return-path ); Mon, 30 Apr 2012 11:44:11 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOo5T-0008Qp-An (Exim 4.67) (return-path ); Mon, 30 Apr 2012 11:44:11 +0100 Date: Mon, 30 Apr 2012 11:44:11 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John Gilmore In-Reply-To: <201204300316.q3U3GFcF002018@new.toad.com> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 10:44:16 -0000 John Gilmore wrote: > > I do not personally know whether MX clients expect to see the > service's domain name in the certificate, or the server's. But I know > that many mail servers currently use STARTTLS and it is widely > interoperable with many clients, so the answer is easy to come by. There is currently no certificate verification on inter-domain SMTP. Most MXs present unverifiable certificates. http://www.imc.org/ietf-smtp/mail-archive/msg05366.html In order to add authenticated TLS to SMTP we need some extra signalling so that an MX can say, "not only am I offering STARTTLS, but also I promise to present a valid certificate!" > DANE does introduce an additional issue about what name should be > looked up in the DNS when seeking a TLSA record. Does the client look > for a TLSA record at _port._tcp.service.name or at > _port._tcp.server.name? I believe the consensus (at least for SMTP) is for the latter. Otherwise it becomes really hard to support virtual domains, expecially since a single transaction can transfer a message to recipients at multiple domains. More generally, RFC 6125 describes the framework for what identity should be authenticated by a certificate. Tony. -- f.anthony.n.finch http://dotat.at/ Hebrides, Bailey, Fair Isle, Faeroes: Northeast 5 or 6, becoming variable 4. Moderate. Occasional rain then fair. Moderate or good. From mrex@sap.com Mon Apr 30 06:53:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F48521F8639; Mon, 30 Apr 2012 06:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzd5hM6kDGea; Mon, 30 Apr 2012 06:53:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87E21F8638; Mon, 30 Apr 2012 06:53:39 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3UDrc55017981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 15:53:38 +0200 (MEST) From: Martin Rex Message-Id: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> To: gnu@toad.com (John Gilmore) Date: Mon, 30 Apr 2012 15:53:37 +0200 (MEST) In-Reply-To: <201204292309.q3TN9BcF027057@new.toad.com> from "John Gilmore" at Apr 29, 12 04:09:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 13:53:41 -0000 John Gilmore wrote: > > >> So this will not work for any type of DNS indirection mechanism, such as MX, SRV, etc? In many protocols, those indirections create a security problem. So each and every such protocol should be forced to resolve that security problem itself. > > So, for example, to secure STARTTLS in SMTP, you'd use: > > toad.com. MX 150 new.toad.com. > _25._tcp.new.toad.com. TLSA ...(a key or certificate for new.toad.com)... > new.toad.com. A 209.237.225.253 > new.toad.com. AAAA 2607:f3a0:17::2 When trying to deliver mail to @toad.com, the only secure question to ask is whether the server is authorized to process Email for @toad.com. For certificates issued from the traditional PKIX world, that would require a "toad.com" DNSName SAN. The only reasonable TLSA lookup would be _25._tcp.toad.com TLSA .... and DANE only checks the DNSSEC properties of that TLSA lookup. The security properties of any MX, CNAME, A or AAAA lookups during connection establishment with that server are irrelevant for DANE (and invisible to PKIX). -Martin From warren@kumari.net Mon Apr 30 07:15:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4220121F864F; Mon, 30 Apr 2012 07:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR0X6M7eXSRS; Mon, 30 Apr 2012 07:15:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 309CB21F864B; Mon, 30 Apr 2012 07:15:41 -0700 (PDT) Received: from dhcp-172-29-46-50.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id B4CD21B40305; Mon, 30 Apr 2012 10:15:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Mon, 30 Apr 2012 10:15:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <512A3C9F-B4F2-4C31-9341-7B8C82D6C006@kumari.net> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 14:15:42 -0000 On Apr 29, 2012, at 7:28 PM, Paul Hoffman wrote: > On Apr 29, 2012, at 4:09 PM, John Gilmore wrote: >=20 >>>>> So this will not work for any type of DNS indirection mechanism, = such as MX, SRV, etc? >>=20 >> TLSA is expected to work with TLS-based services reached via MX >> records, as well as with services that use TLS which are reached via >> SRV records. >=20 > You may have missed the earlier discussion of this topic, and the fact = that the topic was closed with a result different than what you say = here. Please see . >=20 > If the WG chairs think that Jakob and I have not reflected the WG = consensus from that issue in the document, Nope -- the chairs believe that WG consensus has been captured and = reflected in the document=85 The XMPP people have already agreed to do the initial work for the XMPP = protocol, and others can leverage their work after it is finished. Different protocols have different expectations / requirements, and so = we will need differnt means of dealing with them ("How to do DANE with = protocol foo" type documents=85) W > we are happy to update the document yet again. >=20 > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From stpeter@stpeter.im Mon Apr 30 07:22:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E285B21F8642; Mon, 30 Apr 2012 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQDTV-9PiwmF; Mon, 30 Apr 2012 07:22:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6D21F8634; Mon, 30 Apr 2012 07:22:56 -0700 (PDT) Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 147B740058; Mon, 30 Apr 2012 08:37:47 -0600 (MDT) Message-ID: <4F9EA03D.2040505@stpeter.im> Date: Mon, 30 Apr 2012 07:22:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: James Cloos References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 14:22:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/30/12 1:40 AM, James Cloos wrote: > John's post exactly illustrates why I've been advocating always > doing TLSA lookups for the port and name for which the client is > making an A/AAAA or PTR lookup¹. Ie, from the results of the > NAPTR, SRV and/or MX. > > Except only for cases which /explicitly/ specify different > behaviour. :) > > RFC 3923 says that XMPP -- the oft-cited counter example -- > requires certs to have subjectAltName values which look like email > addresses, rather than like host names. XMPP, therefore, isn't > actually relevant to draft-ietf-dane-protocol, but rather to the > forthcoming draft about public key data for TLS client certs. That's because RFC 3923 is about client-to-client (end-to-end) encryption, so the certificates used in that context contain subjectAltName values of the form user@host. See Section 13.7.1.2.1 of RFC 6120 for the most up-to-date XMPP-specific rules about server certificates (where the subjectAltName values are domain names). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+eoD0ACgkQNL8k5A2w/vxI8ACeOSL3ghOL7tD9D2M3MBNY0ksS tdQAn2lUP6FvVjQipsvqRKLH5qXUJvPA =xFXj -----END PGP SIGNATURE----- From trac+dane@trac.tools.ietf.org Mon Apr 30 07:30:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195FD21F8638 for ; Mon, 30 Apr 2012 07:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZfl5pJe-5Kw for ; Mon, 30 Apr 2012 07:30:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC621F8637 for ; Mon, 30 Apr 2012 07:30:37 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOrcR-0002RP-JJ; Mon, 30 Apr 2012 10:30:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Mon, 30 Apr 2012 14:30:27 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/39#comment:1 Message-ID: <072.a6577e3fb5d778702ad540cc9f7888ec@trac.tools.ietf.org> References: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <057.b2cbd82edb77d04b59f3651a922b098b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120430143037.8FAC621F8637@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 07:30:37 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #39: Address interaction between EV certs and DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 14:30:38 -0000 #39: Address interaction between EV certs and DANE Changes (by warren@…): * status: new => closed * resolution: => wontfix Comment: Having not seen any comments from the WG on how to address this, I'm closing it... -- ---------------------------+----------------------------------------- Reporter: ondrej.sury@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | ---------------------------+----------------------------------------- Ticket URL: dane From trac+dane@trac.tools.ietf.org Mon Apr 30 07:31:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF69121F84D6 for ; Mon, 30 Apr 2012 07:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtsYvhUkRkhY for ; Mon, 30 Apr 2012 07:31:27 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1D50421F845C for ; Mon, 30 Apr 2012 07:31:27 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOrdN-0000Wp-Lp; Mon, 30 Apr 2012 10:31:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Mon, 30 Apr 2012 14:31:25 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/40#comment:1 Message-ID: <075.795771e7a6cef62fc8adea9aef8e36ad@trac.tools.ietf.org> References: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120430143127.1D50421F845C@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 07:31:27 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #40: Which TLS versions? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 14:31:27 -0000 #40: Which TLS versions? Changes (by warren@…): * status: new => closed * resolution: => wontfix Comment: Having not seen any supporting consensus, closing. -- ----------------------------+----------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | ----------------------------+----------------------------------------- Ticket URL: dane From fanf2@hermes.cam.ac.uk Mon Apr 30 07:32:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23A21F864B; Mon, 30 Apr 2012 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg9Is943xM1j; Mon, 30 Apr 2012 07:32:23 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEAF21F8630; Mon, 30 Apr 2012 07:32:23 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60940) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SOreG-00015i-El (Exim 4.72) (return-path ); Mon, 30 Apr 2012 15:32:20 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOreG-0006Di-HP (Exim 4.67) (return-path ); Mon, 30 Apr 2012 15:32:20 +0100 Date: Mon, 30 Apr 2012 15:32:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> Message-ID: References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 14:32:24 -0000 Martin Rex wrote: > > When trying to deliver mail to @toad.com, the only secure > question to ask is whether the server is authorized to process > Email for @toad.com. For certificates issued from the traditional > PKIX world, that would require a "toad.com" DNSName SAN. That is not the only answer if the MX lookup is secured with DNSSEC. > The security properties of any MX, CNAME, A or AAAA lookups during > connection establishment with that server are irrelevant for DANE > (and invisible to PKIX). RFC 6125 allows for secure name indirections. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Southwesterly 4 or 5, increasing 6 or 7 for a time. Moderate or rough. Occasional rain. Moderate or good. From warren@kumari.net Mon Apr 30 07:33:19 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EDF21F84F1 for ; Mon, 30 Apr 2012 07:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCLnIyvrJ8cr for ; Mon, 30 Apr 2012 07:33:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1470B21F845C for ; Mon, 30 Apr 2012 07:33:19 -0700 (PDT) Received: from dhcp-172-29-46-50.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 9E8D91B402FF; Mon, 30 Apr 2012 10:33:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <6CC342E4-035B-4C4A-B4DD-912FDA1B73D0@vpnc.org> Date: Mon, 30 Apr 2012 10:33:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1139238B-DA5A-433D-B87F-0BC3D938B9CD@kumari.net> References: <6CC342E4-035B-4C4A-B4DD-912FDA1B73D0@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1257) Cc: IETF DANE WG list Subject: Re: [dane] Draft -20 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 14:33:19 -0000 On Apr 29, 2012, at 7:45 PM, Paul Hoffman wrote: > Greetings again. Jakob and I have made the editorial and = substantiative changes requested in IETF Last Call. If the WG Chairs = think we caught everything, we request that they pass this along to the = AD so the document can be considered by the IESG. If we missed anything, = we can make more changes. >=20 Believe we have caught everything well enough=85. Adding AD to the CC = line. > We also request that the WG chairs close out issues #39 and #40 on the = tracker. We didn't do #40 because there was no resolution; let us know = if we should have done something different. >=20 Closed. W > --Paul Hoffman >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From mamille2@cisco.com Mon Apr 30 07:36:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B2021F84EA; Mon, 30 Apr 2012 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yoi4PD9fpRs; Mon, 30 Apr 2012 07:36:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B35CA21F84D0; Mon, 30 Apr 2012 07:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6377; q=dns/txt; s=iport; t=1335796573; x=1337006173; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=b2mkUjuXeHXwOAgQl/kEi/gH9qZgnJaitdJsjcNtgvw=; b=IyTkyReyO9P8MnDrlOztK/Mh8Bjr9gYfPTKi3rJ0vrnN95DzO5b6Lpyt Egq+JrGyHEufVZAHdSf8CACtCPqlrnnUDgDv0i9bH1qzwBXbo51K4JW7C PLPpohrXedcjkOVOzv01Q8lHQovOvPUY8ToLQ35We4p3AJjSNpJWQXmao 0=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL2ink+rRDoJ/2dsb2JhbABEr0aDAIEHggkBAQEDAQEBAQ8BWwsFCwtGAiUwBhMih2YEAQuaE59cBJA/YwSIZIYThweOWYFpgweBPQ X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="sig'?p7s'?scan'208";a="42797888" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 14:36:13 +0000 Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3UEaCrN006240; Mon, 30 Apr 2012 14:36:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-60-1007096773" From: Matt Miller In-Reply-To: Date: Mon, 30 Apr 2012 08:36:22 -0600 Message-Id: <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> To: James Cloos Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 14:36:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-60-1007096773 Content-Type: multipart/signed; boundary=Apple-Mail-59-1007096763; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-59-1007096763 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 30, 2012, at 02:40, James Cloos wrote: > John's post exactly illustrates why I've been advocating always doing > TLSA lookups for the port and name for which the client is making an > A/AAAA or PTR lookup=B9. Ie, from the results of the NAPTR, SRV = and/or MX. >=20 > Except only for cases which /explicitly/ specify different behaviour. = :) >=20 > RFC 3923 says that XMPP -- the oft-cited counter example -- requires > certs to have subjectAltName values which look like email addresses, > rather than like host names. XMPP, therefore, isn't actually relevant > to draft-ietf-dane-protocol, but rather to the forthcoming draft about > public key data for TLS client certs. >=20 You are correct that RFC 3923 not relevant to the current discussion; it = only covers end-to-end object encryption (read: between clients), not = TLS. However, 6120 does talk about server certificate expectations with = regards to TLS; the xmppAddr looks like a host name then. See RFC 6120, = sections 13.7.1.2 and 13.7.2.1 more details. > The exceptions should be few and far-between. And they should require > their own rfc referencing and modifying TLSA for their own needs. >=20 > 1] If an address rather than a name is supplied, one must choose = between > doing a PTR to get a name and a TLSA on that name to get the cert > info, or doing a TLSA on the address. Either way, one shoudl = expect > the cert to have a CN and/or subjectAltName which matches the name > returned by the PTR lookup. >=20 For XMPP, this is not true, and why Peter and I are working on an = XMPP-specific proposal. > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-59-1007096763 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE0MzYy MlowIwYJKoZIhvcNAQkEMRYEFLOlXEEkB9Nef/cryf2Y7Ok1nqtmMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCbxigd7AcGMcJMAV1lqdafDexBbe4iC7S5wjFmQ4xExRscfEC330B6zIg1 dHBEwQ5915yf1PmOwdCkCzv3bBjDI+j3LTxnCVr9cBvon2cnn9NsiHKC59wbAoo39foNq38clmrH bFpZAabjTL7H3Uvy42G4s/9uggyuucPAUTgiLRlAg3xPL1cbEySVitAPn6MSNsoVBxoxb2zldPVy ZH9hm4KLaEmwRrRCxdt3tp6SR6hiuA+pc33XYulq5cnv1iu+ktWllSR5kZqgjLyvrPH/nP+xukbJ Urk1/WDFTGBIIUMOJSU9nqihgYAYJB3bfQ4q3iR8jX42YzwHhR1exaBqAAAAAAAA --Apple-Mail-59-1007096763-- --Apple-Mail-60-1007096773 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPnqNmAAoJEJq6Ou0cgrSPd8QH/i+u14fDZDnmiA5vkmMimymi LwS8qcSLgsS9+brN04XJjq0VpSlXPy5ibqqMSOzCd2G5Qkp3d+9G2FUWKbcDBaBY 4x31cfqy5hrmv7CNk2lKboIYGYxFWQp5uj4x7H535H2AUDvHHhJtUR8STvMw/1d+ oErCBHgK70g9iXN3dboLLqjTLSzP/sma38a9uNgsQ+LYaT34ltBPkXKahuMLOIqh 4zjJp0rNnERin2mGnOz9XiURysDJx/As3VItdotKsBIt2rj8NmO5S+4UZwv4lvnk 4qzMoJUz+1s4WDO3hA2Hv9zkWkOSavcTBoQAhQQnjRml0x96Sy4XepITtkC3DW4= =kp/M -----END PGP SIGNATURE----- --Apple-Mail-60-1007096773-- From mrex@sap.com Mon Apr 30 07:46:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6026121F8541; Mon, 30 Apr 2012 07:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv0tXitsS3wC; Mon, 30 Apr 2012 07:46:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59A7E21F84D6; Mon, 30 Apr 2012 07:46:21 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UEkIsH008428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 16:46:18 +0200 (MEST) From: Martin Rex Message-Id: <201204301446.q3UEkH2G010394@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Mon, 30 Apr 2012 16:46:17 +0200 (MEST) In-Reply-To: from "Tony Finch" at Apr 30, 12 03:32:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 14:46:22 -0000 Tony Finch wrote: > > Martin Rex wrote: > > > > When trying to deliver mail to @toad.com, the only secure > > question to ask is whether the server is authorized to process > > Email for @toad.com. For certificates issued from the traditional > > PKIX world, that would require a "toad.com" DNSName SAN. > > That is not the only answer if the MX lookup is secured with DNSSEC. Think of DANE as something that works (or is supposed to work) similar to PKIX. How and whether other parts of the software perform fancy indirections through DNS or otherwise, and how and whether those are secure, is not visible to the DANE module (neither to PKIX) and should therefore not be relevant for either. Doing otherwise is calling for _real_ trouble. DNS allows for some pretty fancy indirections, and trying to ensure that *ALL* of those are secure (in particular since they happen in software modules completely distinct from DANE) and trying to describe the resulting implications (and dangers) to DNS admins is IMHO bound to fail badly. > > > The security properties of any MX, CNAME, A or AAAA lookups during > > connection establishment with that server are irrelevant for DANE > > (and invisible to PKIX). > > RFC 6125 allows for secure name indirections. Which _secure_ name indirections are you thinking of? -Martin From fanf2@hermes.cam.ac.uk Mon Apr 30 07:52:49 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5258721F865C; Mon, 30 Apr 2012 07:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltE+WgCORSAH; Mon, 30 Apr 2012 07:52:47 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6B21F8657; Mon, 30 Apr 2012 07:52:45 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34716) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SOrxy-00069A-Wo (Exim 4.72) (return-path ); Mon, 30 Apr 2012 15:52:42 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOrxy-0001Qg-54 (Exim 4.67) (return-path ); Mon, 30 Apr 2012 15:52:42 +0100 Date: Mon, 30 Apr 2012 15:52:42 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201204301446.q3UEkH2G010394@fs4113.wdf.sap.corp> Message-ID: References: <201204301446.q3UEkH2G010394@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 14:52:49 -0000 Martin Rex wrote: > > > The security properties of any MX, CNAME, A or AAAA lookups during > > > connection establishment with that server are irrelevant for DANE > > > (and invisible to PKIX). > > > > RFC 6125 allows for secure name indirections. > > Which _secure_ name indirections are you thinking of? RFC 6125 says: The client might need to extract the source domain and application service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., parsing the fully qualified DNS domain name out of the "host" component (or its equivalent) of a URI or deriving the application service type from the scheme of a URI) or information that is derived in a manner not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection or association that provides both mutual authentication and integrity checking). Tony. -- f.anthony.n.finch http://dotat.at/ North Bailey, Fair Isle, Faeroes: Variable 3 or 4, becoming southwesterly 5 later in north Bailey and Faeroes. Slight or moderate. Occasional rain. Moderate or good. From trac+dane@trac.tools.ietf.org Mon Apr 30 07:56:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F5E21F864F for ; Mon, 30 Apr 2012 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu9AJglcraEb for ; Mon, 30 Apr 2012 07:56:38 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4541B21F867A for ; Mon, 30 Apr 2012 07:56:38 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SOs1e-0005sz-Os; Mon, 30 Apr 2012 10:56:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net X-Trac-Project: dane Date: Mon, 30 Apr 2012 14:56:30 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/40#comment:2 Message-ID: <075.0e6265d75848da0de6d5494e3e2fdfd6@trac.tools.ietf.org> References: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <060.c512838b50d3d0882ffbacb222f73486@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dane-protocol@tools.ietf.org, warren@kumari.net, dane@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120430145638.4541B21F867A@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 07:56:38 -0700 (PDT) Resent-From: trac+dane@trac.tools.ietf.org Cc: dane@ietf.org Subject: Re: [dane] #40: Which TLS versions? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 14:56:38 -0000 #40: Which TLS versions? Comment (by warren@…): Whoops. I had too many tabs open and though I was editing #39. Correct resolution for this is: Updated in -20 with: Although the references in this paragraph are to TLS and DTLS version 1.2, the DANE TLSA protocol can also be used with earlier versions of TLS and DTLS. -- ----------------------------+----------------------------------------- Reporter: paul.hoffman@… | Owner: draft-ietf-dane-protocol@… Type: defect | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: - | Resolution: wontfix Keywords: | ----------------------------+----------------------------------------- Ticket URL: dane From mrex@sap.com Mon Apr 30 08:37:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E1221F868A; Mon, 30 Apr 2012 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9JeGHdVEwfE; Mon, 30 Apr 2012 08:37:23 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A14DA21F85A5; Mon, 30 Apr 2012 08:37:22 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UFbK3F015000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 17:37:20 +0200 (MEST) From: Martin Rex Message-Id: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Mon, 30 Apr 2012 17:37:19 +0200 (MEST) In-Reply-To: from "Tony Finch" at Apr 30, 12 03:52:42 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:37:24 -0000 Tony Finch wrote: > > Martin Rex wrote: > > > > > The security properties of any MX, CNAME, A or AAAA lookups during > > > > connection establishment with that server are irrelevant for DANE > > > > (and invisible to PKIX). > > > > > > RFC 6125 allows for secure name indirections. > > > > Which _secure_ name indirections are you thinking of? > > RFC 6125 says: > > The client might need to extract the source domain and application > service type from the input(s) it has received. The extracted data > MUST include only information that can be securely parsed out of the > inputs (e.g., parsing the fully qualified DNS domain name out of the > "host" component (or its equivalent) of a URI or deriving the > application service type from the scheme of a URI) or information > that is derived in a manner not subject to subversion by network > attackers (e.g., pulling the data from a delegated domain that is > explicitly established via client or system configuration, resolving > the data via [DNSSEC], or obtaining the data from a third-party > domain mapping service in which a human user has explicitly placed > trust and with which the client communicates over a connection or > association that provides both mutual authentication and integrity > checking). One should not confuse DNSSEC protection of DNS records (which provide only data integrity and data origin authentication) with the concept of a secure directory service providing name translations. Sprinkling security equally across all DNS records also seems like a bad idea. I think it would be much more sensible to limit the security-relevant DNS records (and indirections allowed for them) to _very_ few records, and preferably all _new_ records, because DNSSEC-less zones will be with us for many years to come, and I believe it would be a really bad idea to change the sensitivity of existing DNS records underneath DNS registrar's feet. For TLSA records it would be OK if DNS software (and DNS servers) performed some plausibility checks, e.g. warn prominently if TLSA records are present in a Zone but no DNSSEC is active for the zone. Something which does not make sense for any of the traditional DNS records. Looking at the example from a previous post: > > ;; QUESTION SECTION: > ;universalmusic.com. IN MX > > ;; ANSWER SECTION: > universalmusic.com. 3600 IN MX 10 mail.global.frontbridge.com. For regular DANE, it is sufficient if (but also necessary that) the DNS-Domain "universalmusic.com" has DNSSEC active in order to securely provide a TLSA record for _25._tcp.universalmusic.com. and simultaneously independent from the DNSSEC status of frontbridge.com. If you want to allow DNS-based indirection, and in particular on existing DNS records, then you would have to enforce that *ALL* domains that are traversed during all possible DNS indirections have DNSSEC active and that all lookups are verified, and require that the SMTP-software aborts if DNSSEC verification of one of the indirections fails or is not possible, and it may be difficult to impossible for the DNS-Software (maintenance tools and DNS-Server) to help you maintaining consistency across all those possible indirections, and close to impossible for the DNS admins to understand the implications. -Martin From cloos@jhcloos.com Mon Apr 30 08:52:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21A21F86F0; Mon, 30 Apr 2012 08:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDh4UeO5296w; Mon, 30 Apr 2012 08:52:25 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCF21F867E; Mon, 30 Apr 2012 08:52:25 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 0403C4017D; Mon, 30 Apr 2012 15:52:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335801145; bh=ws9CoPfw/V+c+vTaT/FiWgGvmeaTOUrMAfKnXlY0yn0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pQnQuTFZtDbCcs6riDLaces6NsBe45lJmepRgjt/hJOp0RL6mujNmtvbBgT+fTqxG cfagd1l57ZG6UGjDbz2xYsJVi3un9jJZyEcD4zf/A02NZVwCjHs5GuAL4QlJbEl5NQ TUL8PlWMyXZ+lBzYLjDl0vNEvYhHOvfKibHJasTc= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8CA1036004C; Mon, 30 Apr 2012 15:51:26 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> ("Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=22's?= message of "Mon, 30 Apr 2012 03:16:41 +0200") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 30 Apr 2012 11:51:26 -0400 Message-ID: Lines: 21 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , Paul Hoffman , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 15:52:26 -0000 >>>>> "PF" == Patrik Fältström writes: PF> On 30 apr 2012, at 01:58, Mark Andrews wrote: >> toad.com. MX 150 mail.toad.com. >> mail.toad.com. CNAME new.toad.com. PF> Mark, I must admit I do not remember what your personal view is on PF> MX -> CNAME chains, but I am a strong believer in that this is PF> something that is not accepted. There is no technical reason to avoid it. The SMTP app does an MX lookup and receives a name. It then does an A and/or AAAA lookup on that name to get an address. If that name is handled by way of a CNAME RR, the resolving DNS server transparently follows it; the SMTP app doesn't see the CNAME RR, and therefor cannot be harmed by its existance. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From fanf2@hermes.cam.ac.uk Mon Apr 30 09:27:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67FA21F873A; Mon, 30 Apr 2012 09:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8BT0QOOpsZF; Mon, 30 Apr 2012 09:27:46 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8696521F8790; Mon, 30 Apr 2012 09:27:46 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44516) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1SOtRw-0007hL-WK (Exim 4.72) (return-path ); Mon, 30 Apr 2012 17:27:44 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOtRv-0000xl-PH (Exim 4.67) (return-path ); Mon, 30 Apr 2012 17:27:43 +0100 Date: Mon, 30 Apr 2012 17:27:43 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> Message-ID: References: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 16:27:47 -0000 Martin Rex wrote: > > If you want to allow DNS-based indirection, and in particular on existing > DNS records, then you would have to enforce that *ALL* domains that > are traversed during all possible DNS indirections have DNSSEC active > and that all lookups are verified, Right. > and require that the SMTP-software aborts if DNSSEC verification of one > of the indirections fails or is not possible, Yes if you get a "bogus" result; if it's just insecure then it should fall back to insecure SMTP (perhaps with unauthenticated TLS) as at present. > and it may be difficult to impossible for the DNS-Software (maintenance > tools and DNS-Server) to help you maintaining consistency across all > those possible indirections, and close to impossible for the DNS admins > to understand the implications. That's an argument for putting the TLSA record alongside the server host name, so that a certificate update only needs to be reflected in the DNS in one place rather than at all the innumerable virtual domains hosted by that server. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet: Cyclonic, becoming easterly or northeasterly for a time, 6 to gale 8, decreasing 4 or 5 later in east Sole. Moderate or rough, occasionally very rough in Sole. Rain or showers. Moderate or good. From ned.freed@mrochek.com Mon Apr 30 09:30:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2647321F873E; Mon, 30 Apr 2012 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVcGoLF8R4mc; Mon, 30 Apr 2012 09:30:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68221F873A; Mon, 30 Apr 2012 09:30:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXB2JD5F4000I1H@mauve.mrochek.com>; Mon, 30 Apr 2012 09:30:27 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 09:30:23 -0700 (PDT) Message-id: <01OEXB2GEMB20006TF@mauve.mrochek.com> Date: Mon, 30 Apr 2012 09:27:38 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Apr 2012 11:51:26 -0400" References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> To: James Cloos Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 16:30:37 -0000 > >>>>> "PF" == Patrik Fältström writes: > PF> On 30 apr 2012, at 01:58, Mark Andrews wrote: > >> toad.com. MX 150 mail.toad.com. > >> mail.toad.com. CNAME new.toad.com. > PF> Mark, I must admit I do not remember what your personal view is on > PF> MX -> CNAME chains, but I am a strong believer in that this is > PF> something that is not accepted. > There is no technical reason to avoid it. The SMTP app does an MX > lookup and receives a name. It then does an A and/or AAAA lookup > on that name to get an address. If that name is handled by way of > a CNAME RR, the resolving DNS server transparently follows it; the > SMTP app doesn't see the CNAME RR, and therefor cannot be harmed > by its existance. That's incorrect. See my previous post on this topic for specifics. Ned From cloos@jhcloos.com Mon Apr 30 09:44:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3067D21F87FA; Mon, 30 Apr 2012 09:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77C06oq1Cimv; Mon, 30 Apr 2012 09:44:03 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4784721F87EA; Mon, 30 Apr 2012 09:44:03 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 554CD403F4; Mon, 30 Apr 2012 16:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335804242; bh=84xPvztEu4e0pLxdhQA91UGRTWdOwJkh5DqOmUmWgXo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mLrr+7pkf9O5kly6hzhNwgDIPXaELI1H4q6P0cJAakXgklxD1rGb4jX/bz3K8hNa1 xwd2CLQxHHC6940lBSdBGE9kZM87vfLYrpr8YsvupQLdhp63u5Sf18fV8nEHAqZDqE zAAmpnXSPw7Rd4RZa2GK3ngSOwUGjB0DRRqEDnCY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id ED1B736004E; Mon, 30 Apr 2012 16:21:22 +0000 (UTC) From: James Cloos To: Tony Finch In-Reply-To: (Tony Finch's message of "Mon, 30 Apr 2012 11:44:11 +0100") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 30 Apr 2012 12:21:22 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120430:dot@dotat.at::zgBYzam/g4mzI3Jm:0000cugBo X-Hashcash: 1:30:120430:gnu@toad.com::AK6UM9Hcm68vMDto:0000rBkPd X-Hashcash: 1:30:120430:"apps-discuss\@ietf.org"::/CpsRFiBryqvhn91:000000000000000000000000000000000000U780Z X-Hashcash: 1:30:120430:apps-discuss@ietf.org::gMISTRgFuZNBzs4h:000000000000000000000000000000000000000z4NRU X-Hashcash: 1:30:120430:dane@ietf.org::ZdXh3t1RAq9GAL2e:000u6Zis X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::kZ4VP82EXrQKrSC7:000000000000000000000000000000000000000Bsvo/ X-Hashcash: 1:30:120430:iesg@ietf.org::IlFrQJDJy69dxzYo:000GGDl4 X-Hashcash: 1:30:120430:alexey.melnikov@isode.com::FE4ouJZeiGJbz3B7:000000000000000000000000000000000002nL7q X-Hashcash: 1:30:120430:paul@nohats.ca::6/JbCxxLzc7H2Viy:00y6GFZ Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Alexey Melnikov , Paul Wouters Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 16:44:06 -0000 >>>>> "TF" == Tony Finch writes: TF> There is currently no certificate verification on inter-domain SMTP. TF> Most MXs present unverifiable certificates. Some MTAs can be configured for it. I currently get valid certs on incoming mail from a number of sites, including debian, python, gnumonks, google, ozlabs, cisco, cacert, several universites and a few others. But it is certainly true that most MXs do not bother to verify, even when the same org's outgoing MTA's certs are verifiable. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Mon Apr 30 10:32:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5221F8858; Mon, 30 Apr 2012 10:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btuc+a3DS4hW; Mon, 30 Apr 2012 10:32:12 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0E821F8855; Mon, 30 Apr 2012 10:32:12 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 346CC40019; Mon, 30 Apr 2012 17:31:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335807131; bh=y7Cs798dAKZIYFmbZvsdnilceK9g9QQNHBJw7Lyepak=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=F+ucqmxLoX4TCkxpU8ewF+/bQ4Sa5MoPgWsY6W56HCF7JLl0SVM6H+eKJ/KfuBxFN F0habNCJhhHg8wi0uB3AeUelQRDQaaaW2FZGT8nK+kum/iGenZ3JEWJUcIaFBW3lwm n9OUNNt0TqewzJT1D4h5zH6WTe1uz/wt4VRv9upY= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 9D6BE36004C; Mon, 30 Apr 2012 17:02:13 +0000 (UTC) From: James Cloos To: Ned Freed In-Reply-To: <01OEXB2GEMB20006TF@mauve.mrochek.com> (Ned Freed's message of "Mon, 30 Apr 2012 09:27:38 -0700 (PDT)") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 30 Apr 2012 13:02:13 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120430:ned.freed@mrochek.com::KLCC3ay+vqGiMAXR:000000000000000000000000000000000000000FJGbK X-Hashcash: 1:30:120430:dane@ietf.org::cxlE2hLXcqvG7D+2:000KzwbQ X-Hashcash: 1:30:120430:marka@isc.org::jO5khq0IPdAdApqh:000BDPh2 X-Hashcash: 1:30:120430:"apps-discuss\@ietf.org"::Xc5rQKet4TaWlnGQ:0000000000000000000000000000000000006TPxi X-Hashcash: 1:30:120430:apps-discuss@ietf.org::wynJwWQtdvO128rz:000000000000000000000000000000000000000GlSmJ X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::9ojnXlzsGVOmIGQn:000000000000000000000000000000000000000MCfd/ X-Hashcash: 1:30:120430:iesg@ietf.org::N/TqAy45Db1kYAJj:000pQ1/i X-Hashcash: 1:30:120430:paul@nohats.ca::agg5g5OXKeNiZiPA:00VE/s9 Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 17:32:13 -0000 >>>>> "NF" == Ned Freed writes: NF> That's incorrect. See my previous post on this topic for specifics. I don't see any previous post from you??? To which list was it posted? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Mon Apr 30 10:33:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD91321F8858; Mon, 30 Apr 2012 10:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi2kj3rmaH-z; Mon, 30 Apr 2012 10:33:56 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10D21F8855; Mon, 30 Apr 2012 10:33:56 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id CB1AA40019; Mon, 30 Apr 2012 17:33:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335807235; bh=5hdMHKV376JhSw5UNgj4tyrKSOugySCXCHvAgZif1W4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=K160azMJt8gxtSm4pqCRUS2Xbr5K5Gzg4HQ9PTR8ifDaKjt/vp9mivKEnfNXMZZS2 +OYPd9m9lxFgo0rqyA3MC+c6O1qxuGSyxMtbRQqGI+xdOAlFsHhpFw3uhNRX39Hl3T MJdqe9SKTBsEtnj0dTx7rdiTj4jVz3GuQCfGP1v4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id D861436004C; Mon, 30 Apr 2012 17:15:12 +0000 (UTC) From: James Cloos To: In-Reply-To: <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> (Matt Miller's message of "Mon, 30 Apr 2012 08:36:22 -0600") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 30 Apr 2012 13:15:12 -0400 Message-ID: Lines: 33 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120430:dane@ietf.org::59idNfa5W+yUYlmU:00090FCS X-Hashcash: 1:30:120430:mamille2@cisco.com::Iw6p1yGhderflihh:0000000000000000000000000000000000000000004PyGe X-Hashcash: 1:30:120430:stpeter@stpeter.im::FiX853q1723FdyGP:000000000000000000000000000000000000000000i+hh6 X-Hashcash: 1:30:120430:apps-discuss@ietf.org::k04pOjngJV2+/SRa:000000000000000000000000000000000000000bpk6d X-Hashcash: 1:30:120430:gnu@toad.com::XiWO0BG8Z9qqYrd2:00003fq7p X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::NNBgxQisdQgYm7SP:000000000000000000000000000000000000000aAAjd X-Hashcash: 1:30:120430:iesg@ietf.org::kf7oTx//in5Goqlz:0003NJ8S X-Hashcash: 1:30:120430:paul@nohats.ca::mWDgxs0QWwPqYuGH:00KNTNE Cc: apps-discuss@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 17:33:57 -0000 Thanks to Peter and Matt for the references to rfc 6120. My prior presumptions about how XMPP uses TLS were based solely on posts here. Having now read through 6210, though, I see nothing which contraindicates doing TLSA lookups based on the serv*er* name. The XMPP app receives a URI. From that it extracts a name to use in a SRV lookup. From the SRV RRs it gets a set of hostname+port tuples. It then does an A/AAAA lookup on each of the hostnames. When it does echo A/AAAA lookup it also can do a TLSA lookup using the hostname+port and the protocol name which it previously used to construct the SRV lookup. It doesn't matter that it will look in the cert for the name in the original URI and not for the resulting hostname. It still is reasonable to expect the cert association to be found parallel to the ip address. Each dns lookup needs to dnsec-verify, of course, but the association is provable (to the extent that *anything* crypto can be /proven/). Everything just works. Some might argue that having to add TLSA RRs for each server is a hassle, but they already have to add the certs to each server, and automation to keep everything in sync is not hard. XMPP doesn't even need its own rfc for DANE, TLSA and 6120 already cover everything it needs. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From mrex@sap.com Mon Apr 30 10:43:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70D321F86FC; Mon, 30 Apr 2012 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2v8GSbBHJ46; Mon, 30 Apr 2012 10:43:17 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BA3CD21F87BE; Mon, 30 Apr 2012 10:43:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UHhE87026290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 19:43:14 +0200 (MEST) From: Martin Rex Message-Id: <201204301743.q3UHhDUH020670@fs4113.wdf.sap.corp> To: dot@dotat.at (Tony Finch) Date: Mon, 30 Apr 2012 19:43:13 +0200 (MEST) In-Reply-To: from "Tony Finch" at Apr 30, 12 05:27:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:43:22 -0000 Tony Finch wrote: > > Martin Rex wrote: > > > > If you want to allow DNS-based indirection, and in particular on existing > > DNS records, then you would have to enforce that *ALL* domains that > > are traversed during all possible DNS indirections have DNSSEC active > > and that all lookups are verified, > > Right. > > > and require that the SMTP-software aborts if DNSSEC verification of one > > of the indirections fails or is not possible, > > Yes if you get a "bogus" result; if it's just insecure then it should fall > back to insecure SMTP (perhaps with unauthenticated TLS) as at present. Current security with SMTP is completely fubar (.. beyond repair). First, the SMTP server endpoint identification should be fixed so that it can be used with both/either (1) PKIX names or (2) DANE. I believe that it would be a very bad idea to continue ignoring the lack of authentication in SMTP with STARTTLS or by embracing a scheme that is much more complex than what is used for HTTPS by adding all conceivable DNS transformations into the picture, because neither users nor admins will understand it anymore. When writing a program for Unix that needs to be setuid for a privileged operation, then it is extremely sensible to limit the euid to that one privileged operation only, and carefully check the inputs to that privileged operation, rather than running with elevated privileges all the time and use all sorts of fancy features from various complex application libraries. > > > and it may be difficult to impossible for the DNS-Software (maintenance > > tools and DNS-Server) to help you maintaining consistency across all > > those possible indirections, and close to impossible for the DNS admins > > to understand the implications. > > That's an argument for putting the TLSA record alongside the server host > name, so that a certificate update only needs to be reflected in the DNS > in one place rather than at all the innumerable virtual domains hosted by > that server. DNSSEC seems to create a lot of confusion. The existance of DNS signatures does not make data any more trustworthy above plain DNS. It is still the _same_ data, and usually maintained with the _same_ admin procedures and the same amount of errors in it. A goole search result is _not_ any more trustworthy when done through https:// instead of http://, just less susceptible to third parties modifying the results when it is transfered between google and your browser. The links to which google is pointing are going to be the exact same (I assume... :). -Martin From mamille2@cisco.com Mon Apr 30 10:46:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD221F8691; Mon, 30 Apr 2012 10:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKGt4e-0dOpT; Mon, 30 Apr 2012 10:46:22 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AEAFF21F864C; Mon, 30 Apr 2012 10:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6413; q=dns/txt; s=iport; t=1335807982; x=1337017582; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=u1M7LPEdLbOb/UqhQk8luFjDa5tLkILx/8vurNfFhSY=; b=eQ05VLivdn/oHoiZNAvCGGFbXT+pO3Cu3PDvOzom1ITtyoB01Kr/243j 1yqk9DbY9T0U5WJk2jghCSNX98ph/RXNcEaJ1bT+qbPt+8e96DOzyJMt7 d1zhzRkU8bmrYe8ly9VuweevFUntXsvevsmWvZGkEiJTgUBm1wfCtWEnv A=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHTPnk+rRDoG/2dsb2JhbABEr1CDAIEHggkBAQEDARIBZgULC0YCVQYTIodmBAGaQZ9+kD9jBIhkhhOHB45ZgWmDBw X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="sig'?p7s'?scan'208";a="42827147" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 30 Apr 2012 17:46:22 +0000 Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3UHjemi013550; Mon, 30 Apr 2012 17:46:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-77-1018504897" From: Matt Miller In-Reply-To: Date: Mon, 30 Apr 2012 11:46:30 -0600 Message-Id: <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> To: James Cloos Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: apps-discuss@ietf.org, dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 17:46:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-77-1018504897 Content-Type: multipart/signed; boundary=Apple-Mail-76-1018504894; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-76-1018504894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 30, 2012, at 11:15, James Cloos wrote: > Thanks to Peter and Matt for the references to rfc 6120. >=20 > My prior presumptions about how XMPP uses TLS were based solely on = posts > here. Having now read through 6210, though, I see nothing which > contraindicates doing TLSA lookups based on the serv*er* name. >=20 > The XMPP app receives a URI. =46rom that it extracts a name to use in = a > SRV lookup. =46rom the SRV RRs it gets a set of hostname+port tuples. > It then does an A/AAAA lookup on each of the hostnames. >=20 > When it does echo A/AAAA lookup it also can do a TLSA lookup using the > hostname+port and the protocol name which it previously used to > construct the SRV lookup. >=20 > It doesn't matter that it will look in the cert for the name in the > original URI and not for the resulting hostname. It still is = reasonable > to expect the cert association to be found parallel to the ip address. >=20 > Each dns lookup needs to dnsec-verify, of course, but the association > is provable (to the extent that *anything* crypto can be /proven/). >=20 > Everything just works. >=20 > Some might argue that having to add TLSA RRs for each server is a > hassle, but they already have to add the certs to each server, and > automation to keep everything in sync is not hard. >=20 > XMPP doesn't even need its own rfc for DANE, TLSA and 6120 already > cover everything it needs. I think there might still need to be some explicitness on what name to = expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). Maybe that doesn't need to be its own document. I am working on a = proposal for improving XMPP federation, and a section in that document = might be sufficient...Probably (-: - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-76-1018504894 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE3NDYz MFowIwYJKoZIhvcNAQkEMRYEFEraCZxbtX9t6Tpmv/2bYAPZZIowMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCNCH/HlMWuv4VjJFjmL1WLTVp2BzfEKgYk3JhLBRdGWvLqnZyoWA7/7TFr m4sXoBeGvgfpz2LkcJDTfp5NaG1DAciLQwnyXmw+NCpoTC4eCI+ONV2F1Z3PHxiYd0dFxCmulOxg HryUgelx9vbvV0xZrdba2zlUP7HKps0QsK+cFdggoOPeQMQOdYs7AzmMtl81IrPunc1INFZAQ9fg FY4wYm7L4YrzFvcokKQOjXvYuxSYfl/n1RTVLsCXabsNgNKv747N7oTS8KvrggxCLMge8rm6V7D2 +UnRFVlFMuAeuSOIQuEMxFdHn6iJJA6szo3cY2EiQJDIcGt9C/KqscqBAAAAAAAA --Apple-Mail-76-1018504894-- --Apple-Mail-77-1018504897 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPns/2AAoJEJq6Ou0cgrSP6a4IAMNTcBeCmx+qpgDM84n48vxK b2iXgwcxvkqXdXHyJC5kXgVXQcTtD4dszF2g+Ez03HpSKjb5os50KD4w5/pac29K a9nNd9m1V56gDrptVnAQFjn7sTHWZlIGEy3ivVz54BFHxO23ln4VXXWP9mJUZzmC qc/80uldlQwHs1G4XQhZw+CpS0yG6JmDkw2QNCoEbgI6nzC8BtHDpcc2JGk6CiZv v9bN0jgIigJIv0mrCnssfesd7ygLz0Tf/l9GO9+2pHIfEDGpPD6zbuyjugu6n64f eAGPGsbLYvFGBUjTgdMzow+GUySpzgp/KbEq6NIXLcCYlAyLD3etzh63TKRtb7s= =BSfe -----END PGP SIGNATURE----- --Apple-Mail-77-1018504897-- From paul.hoffman@vpnc.org Mon Apr 30 11:37:23 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263E21F891B; Mon, 30 Apr 2012 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6VzHJoMKmRz; Mon, 30 Apr 2012 11:37:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5BE21F8910; Mon, 30 Apr 2012 11:37:22 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3UIbGcr015909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Apr 2012 11:37:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> Date: Mon, 30 Apr 2012 11:37:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 18:37:23 -0000 On Apr 30, 2012, at 10:46 AM, Matt Miller wrote: > I think there might still need to be some explicitness on what name to = expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). Yes. > Maybe that doesn't need to be its own document. =20 Are you serious!?!?! After the amount of confusing and disagreement we = have seen in the past few months on this topic, a stand-alone document = that can be referred to easily is exactly what we need. > I am working on a proposal for improving XMPP federation, and a = section in that document might be sufficient...Probably (-: I'm skeptical, to say the least. --Paul Hoffman From mamille2@cisco.com Mon Apr 30 11:52:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0150921F88E5; Mon, 30 Apr 2012 11:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enw+76H7Y2Tq; Mon, 30 Apr 2012 11:52:52 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5D21F8476; Mon, 30 Apr 2012 11:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5717; q=dns/txt; s=iport; t=1335811972; x=1337021572; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=BnspdV8hLc24MYyPNQQgMtTe4eVX3FUp1+aOWkmDExo=; b=YPEf0rTvFeyHmzpgX+R8a0cjuRk7f5vX/+nLcrZb6dnvMGdE5gmThW32 Pp8n3rtKyHJSl1MkAHyeU8yXlHsKgbLEiVtBHMpowf+/EVcGbrayxQSPk QElLiiA/z7VpUAzbCc88p0NaIoNGzHH+VxXAnR5XP0OGMHJcjwFM/0x/T Y=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPXenk+rRDoI/2dsb2JhbABEr1ODAIEHggkBAQEDARIBZgULIyMLAlUGEyKHZgQBmkGgApA/YwSIZIYThweOWYFpgwc X-IronPort-AV: E=Sophos;i="4.75,505,1330905600"; d="sig'?p7s'?scan'208";a="42745738" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 30 Apr 2012 18:52:52 +0000 Received: from dhcp-64-101-72-220.cisco.com (dhcp-64-101-72-220.cisco.com [64.101.72.220]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3UIqpDh029149; Mon, 30 Apr 2012 18:52:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-81-1022493794" From: Matt Miller In-Reply-To: <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> Date: Mon, 30 Apr 2012 12:52:59 -0600 Message-Id: <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> To: Paul Hoffman Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: XMPP Working Group , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: [dane] Documenting DANE for XMPP (WAS: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 18:52:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-81-1022493794 Content-Type: multipart/signed; boundary=Apple-Mail-80-1022493784; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-80-1022493784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 30, 2012, at 12:37, Paul Hoffman wrote: > On Apr 30, 2012, at 10:46 AM, Matt Miller wrote: >=20 >> I think there might still need to be some explicitness on what name = to expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). >=20 > Yes. >=20 >> Maybe that doesn't need to be its own document. =20 >=20 > Are you serious!?!?! After the amount of confusing and disagreement we = have seen in the past few months on this topic, a stand-alone document = that can be referred to easily is exactly what we need. >=20 The preference of having a single document came from the XMPP WG. I = personally am not sure it's the best idea, but I also don't have = anything written up yet. I'm more than willing to fight hard to = separate, but I also need to see what it looks like with the rest of = XMPP federation stuff. >> I am working on a proposal for improving XMPP federation, and a = section in that document might be sufficient...Probably (-: >=20 > I'm skeptical, to say the least. I did say "might" and "probably" (-: - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-80-1022493784 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQzMDE4NTI1 OVowIwYJKoZIhvcNAQkEMRYEFKYtQhbUbQq6VO9BjRW4o7U+td2dMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBZGZTwnJyeiCvy128Fhymh/a1dXYE0WsyKMgQDMbJJzOhqHPWT9fQDFNN9 uohWmQT+9SgKhgvlqcpT0siUmqjGd/uNGEk0b+wJLQXsI/uKLxqQBZn9E/rsPVNMdX36jcOley4m bSOHhDby3Gf9nUWu5RqClnR392iLZbtfqS0dx6mekIW+1leNCjBhDsrJjH2PLMY4NxXj2Sh1E/Nr Crpnn7OItQ6TsK5MBsk5IhbKXhaXye2Lh/QDJNHrLLeE8kdR7xli9MDDlje8V7GhyjOUqoh079ef nZEBKJfGfd96TE7BV8K96aG1dkBNNFk9q5fJ2z7r7qhVII+lkiWqIoIhAAAAAAAA --Apple-Mail-80-1022493784-- --Apple-Mail-81-1022493794 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPnt+LAAoJEJq6Ou0cgrSP31gH/iDRqgPeVdEKhIPCTpMweHxF XtNVctZbkegNAO0ZkXlcFvjIJF1BXkBrSAXFPpsMawAmoQ7cmwQlaJP/kWscN7m5 IU57kdFBa4EkGYvW1SMd4zdbsuR/BAu2NryxaQRXWkoLhdaTJGN2+DksID5LFG8Z WJJvIAJ/GmIZI3s24/qBDYWtfAgT7REcogHzHcJbjdg86B/Cl08VOAIe5sNDfPWk HV4QBxdCCBCLnl3q0aGIYcOLZ4nOPHO0AudykZfBhfg4YhGctlrRcgXR8C7AVlc/ DkvKaT49AJo3c6G6j+4JhzcX4XEtHJIEL4H+xQxdNzZzWsWZIStB0MRrTyhocBk= =rOzu -----END PGP SIGNATURE----- --Apple-Mail-81-1022493794-- From dave@cridland.net Mon Apr 30 12:56:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D5521F8702; Mon, 30 Apr 2012 12:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBYIdwPkctme; Mon, 30 Apr 2012 12:56:29 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id D719C21F8691; Mon, 30 Apr 2012 12:56:28 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B066B116808F; Mon, 30 Apr 2012 20:56:22 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuQUhqcIfGQV; Mon, 30 Apr 2012 20:56:19 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 1EB81116808D; Mon, 30 Apr 2012 20:56:19 +0100 (BST) References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <327.1335815779.111245@puncture> Date: Mon, 30 Apr 2012 20:56:19 +0100 From: Dave Cridland To: James Cloos , General discussion of application-layer protocols , The IESG , "dane@ietf.org" Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 19:56:29 -0000 On Mon Apr 30 18:15:12 2012, James Cloos wrote: > Each dns lookup needs to dnsec-verify, of course, but the > association > is provable (to the extent that *anything* crypto can be /proven/). One of the rather jolly things posited by those in the XMPP community looking at DANE and similar was that one might solve what's quite a tricky problem for larger XMPP services - that of maintaining a cert for every domain they host. For some services (Google is oft-cited here) this is vast numbers, and I recall one XSF meeting (in San Diego) where the problems of TLS in such an environment where discussed at length. DANE/TLSA currently makes this more complex by requiring secure name redirections throughout the chain; unfortunately, whilst this does indeed work in theory, it also provides limited benefit. In particular, it adds little more than using a perfectly ordinary certificate with the server's hostname in does - plus you need to ensure that the certificate either contains the right domain/XMPP SANs, or else you've used Usage 2/3 TLSA (AKA "Please ignore your PKI policy"). Unfortunately, this only works to authenticate the called server - the caller cannot use DANE/TLSA to authenticate itself, instead it still must present a certificate which identifies itself as the domain. Now one could, I suppose, present a certificate which matched a host, and then the callee could perform SRV on the asserted domain, and try each record in turn until it found a combination where the hostname of the SRV matched a hostname present in the certificate. This is, as far as I can tell, secure, although exhaustively searching just fills me with horror, and this doesn't use TLSA yet - including *that* in the mix is even more fun, since it requires a TLSA record fetch per SRV record returned - and all the time we're effectively ignoring the port. I feel sure there's something nasty lurking there, although I can't think what. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From fanf2@hermes.cam.ac.uk Mon Apr 30 13:28:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F27221E8090; Mon, 30 Apr 2012 13:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h2UhLlX2SVn; Mon, 30 Apr 2012 13:28:06 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41421E804E; Mon, 30 Apr 2012 13:28:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:60055) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SOxCW-0007R8-pt (Exim 4.72) (return-path ); Mon, 30 Apr 2012 21:28:04 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SOxCW-0001fm-2O (Exim 4.67) (return-path ); Mon, 30 Apr 2012 21:28:04 +0100 Date: Mon, 30 Apr 2012 21:28:04 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland In-Reply-To: <327.1335815779.111245@puncture> Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <327.1335815779.111245@puncture> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: General discussion of application-layer protocols , "dane@ietf.org" Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 20:28:07 -0000 Dave Cridland wrote: > > DANE/TLSA currently makes this more complex by requiring secure name > redirections throughout the chain; unfortunately, whilst this does indeed work > in theory, it also provides limited benefit. > > In particular, it adds little more than using a perfectly ordinary certificate > with the server's hostname in does - plus you need to ensure that the > certificate either contains the right domain/XMPP SANs, or else you've used > Usage 2/3 TLSA (AKA "Please ignore your PKI policy"). Would it make sense to define an alternative virtual-hosting-friendly authentication scheme that relies on DNSSEC and matches the cert against the hostname instead of the server domain? I think something along those lines will be required for SMTP so that clients know they can expect a valid server certificate. > Unfortunately, this only works to authenticate the called server - the caller > cannot use DANE/TLSA to authenticate itself, instead it still must present a > certificate which identifies itself as the domain. > > Now one could, I suppose, present a certificate which matched a host, and then > the callee could perform SRV on the asserted domain, and try each record in > turn until it found a combination where the hostname of the SRV matched a > hostname present in the certificate. > > This is, as far as I can tell, secure, although exhaustively searching just > fills me with horror, and this doesn't use TLSA yet - including *that* in the > mix is even more fun, since it requires a TLSA record fetch per SRV record > returned - and all the time we're effectively ignoring the port. I feel sure > there's something nasty lurking there, although I can't think what. Surely it isn't that bad: client presents certificate and asserts a domain; server concurrently looks up SRV of domain and TLSA of all the host names in the certificate; server checks that at least one SRV target host name appears in the certificate and has a TLSA that matches. The "exhausive" search is not much of a search and is not at all taxing, and you can recommend that deployments arrange that there is one name in the certificate to minimize the TLSA lookup cost. Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire: Variable 3 or 4, becoming northerly 5 later in North Utsire. Slight, occasionally moderate. Fog patches developing. Moderate or good, occasionally very poor. From ned.freed@mrochek.com Mon Apr 30 13:43:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF521E809E; Mon, 30 Apr 2012 13:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTFb3VP3Ac2s; Mon, 30 Apr 2012 13:43:36 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 09A2621E8019; Mon, 30 Apr 2012 13:43:36 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXJW7XW74000S3A@mauve.mrochek.com>; Mon, 30 Apr 2012 13:43:27 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 13:43:21 -0700 (PDT) Message-id: <01OEXJW3QF0G0006TF@mauve.mrochek.com> Date: Mon, 30 Apr 2012 13:41:32 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Apr 2012 13:02:13 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> To: James Cloos Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 20:43:36 -0000 > >>>>> "NF" == Ned Freed writes: > NF> That's incorrect. See my previous post on this topic for specifics. > I don't see any previous post from you??? > To which list was it posted? apps-discuss. Id: <01OEWP11R5NK0006TF@mauve.mrochek.com> Ned From stephen.farrell@cs.tcd.ie Mon Apr 30 13:50:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1D221F86E0; Mon, 30 Apr 2012 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYGlCC0Qrldj; Mon, 30 Apr 2012 13:50:14 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7A121F86F0; Mon, 30 Apr 2012 13:50:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0B55D1714F1; Mon, 30 Apr 2012 21:50:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335819007; bh=VDF80Kei/vfe2A dVDhHczPUO8Y/bQaY2u7S+67hm5SI=; b=FR8vGtMbu3/U1sC94RKntLXKHM4X8X 6uywDXb1MwsLlRTTnZBm2rymxrnm/DJX90uifpUs5Lh5ON8ZQOSEsaWWYx1GPKsx 8W0j1vaT47UqDn2mlfBj6OtTE9omTTMeU7BJAZZLkM7AvNQfunCUSS+v9YP4zwBF EcktYNtB5CS68afRIix1+/LvGuaSFP48eW2f0sLtw2YC0XGnvWX21/c4tL6XieV2 e/ZeM69vk96QGlynJiqzArfUt3M37H3aHuZuMJdbZGaKktxzulT+dPbdi/KwMwOB bhEtLi6blrPBuGm3Tge99NnbLiLvYj4tT8xMH7JovuhY3PKKhLSdxMhA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cYROGUcHc9oJ; Mon, 30 Apr 2012 21:50:07 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.25.92]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2AE49171476; Mon, 30 Apr 2012 21:50:03 +0100 (IST) Message-ID: <4F9EFAFB.5050709@cs.tcd.ie> Date: Mon, 30 Apr 2012 21:50:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Ned Freed References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> In-Reply-To: <01OEXJW3QF0G0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 20:50:16 -0000 Folks, I think we may be wandering from the appsdir review of the DANE draft. If we are, please reduce the cc list to one list, either apps-discuss (with a different subject probably), or DANE, or if this is still relevant to the concluded IETF LC for DANE, then DANE+IESG or ietf@ietf.org is in fact fine. I intend checking -20 of the DANE draft vs. IETF LC comments received now and putting it on an IESG telechat if all's well, so if there remain substantive concerns about progressing *that document*, you need to make those clear. (For example, how XMPP uses DANE is not a substantive concern for the DANE draft IMO, but if you want to, you can make that argument.) If your mail is about some other thing then please reduce the cc list and set the subject appropriately. Thanks, Stephen. On 04/30/2012 09:41 PM, Ned Freed wrote: >>>>>>> "NF" == Ned Freed writes: > >> NF> That's incorrect. See my previous post on this topic for specifics. > >> I don't see any previous post from you??? > >> To which list was it posted? > > apps-discuss. Id: <01OEWP11R5NK0006TF@mauve.mrochek.com> > > Ned > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From rbarnes@bbn.com Mon Apr 30 14:47:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018EB21E80C3; Mon, 30 Apr 2012 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.444 X-Spam-Level: X-Spam-Status: No, score=-106.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlulIcSspzH8; Mon, 30 Apr 2012 14:47:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C321E80C0; Mon, 30 Apr 2012 14:47:41 -0700 (PDT) Received: from [128.89.253.186] (port=60199) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SOyRA-000Fm9-JB; Mon, 30 Apr 2012 17:47:16 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> Date: Mon, 30 Apr 2012 17:48:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> To: Matt Miller X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org Discuss" , Paul Hoffman , XMPP Working Group , IETF DANE WG list Subject: Re: [dane] Documenting DANE for XMPP (WAS: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 21:47:43 -0000 +1 to documenting the use of DANE with XMPP +1 also to incorporating this discussion in a broader DNA / "server = federation" document On Apr 30, 2012, at 2:52 PM, Matt Miller wrote: >=20 > On Apr 30, 2012, at 12:37, Paul Hoffman wrote: >=20 >> On Apr 30, 2012, at 10:46 AM, Matt Miller wrote: >>=20 >>> I think there might still need to be some explicitness on what name = to expect to match on regardless of where the certificate is found, = especially with multi-domain XMPP servers (e.g. a server = "im.shakespeare.lit" that services domains "capulet.shakespeare.lit" and = "denmark.shakespeare.lit"). >>=20 >> Yes. >>=20 >>> Maybe that doesn't need to be its own document. =20 >>=20 >> Are you serious!?!?! After the amount of confusing and disagreement = we have seen in the past few months on this topic, a stand-alone = document that can be referred to easily is exactly what we need. >>=20 >=20 > The preference of having a single document came from the XMPP WG. I = personally am not sure it's the best idea, but I also don't have = anything written up yet. I'm more than willing to fight hard to = separate, but I also need to see what it looks like with the rest of = XMPP federation stuff. >=20 >>> I am working on a proposal for improving XMPP federation, and a = section in that document might be sufficient...Probably (-: >>=20 >> I'm skeptical, to say the least. >=20 > I did say "might" and "probably" (-: >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ned.freed@mrochek.com Mon Apr 30 15:11:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7D321E80AD; Mon, 30 Apr 2012 15:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+5sI8VbUNda; Mon, 30 Apr 2012 15:11:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4C621E80A1; Mon, 30 Apr 2012 15:11:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXMZ6W0B4000NG3@mauve.mrochek.com>; Mon, 30 Apr 2012 15:11:22 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 15:11:16 -0700 (PDT) Message-id: <01OEXMZ1FWDW0006TF@mauve.mrochek.com> Date: Mon, 30 Apr 2012 15:07:16 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Apr 2012 21:50:03 +0100" <4F9EFAFB.5050709@cs.tcd.ie> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> To: Stephen Farrell Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 22:11:35 -0000 > I think we may be wandering from the appsdir review of the > DANE draft. If we are, please reduce the cc list to one list, > either apps-discuss (with a different subject probably), or > DANE, or if this is still relevant to the concluded IETF LC > for DANE, then DANE+IESG or ietf@ietf.org is in fact fine. I strongly disagree. This is all in response to the apps area review of a DANE WG document and in that context it is entirely appropriate to be cc'ing both the apps area list and the dane list. Indeed, if you fail to do so, your comments will fail to be read by one constituency or another. It is not reasonable to expect everyone on the apps area list to subscribe to the DANE list for this or vice versa. And yes, this means that some folks will get multiple copies. Life is hard someitmes; deal with it. Ned From stephen.farrell@cs.tcd.ie Mon Apr 30 15:20:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694D721E80CD; Mon, 30 Apr 2012 15:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.864 X-Spam-Level: X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLrdYRi1b6db; Mon, 30 Apr 2012 15:20:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD521E80A1; Mon, 30 Apr 2012 15:20:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7FEB1714F1; Mon, 30 Apr 2012 23:20:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335824443; bh=S4ZIVIAUyc0xQ7 7bIS4PF+Qo0UjQMb06Iri85WFwMQc=; b=gySL946DsvxG7E/8E22UFPTXBvgAid Pdzk0THnFRiq4Nq00Ki2po49J0es16Gik2sedAzpuIe74rBWfH/UmpNj34lAEtra U4F3cBb5ppQmo4qIAeMZFuXqj/Nx2iK66sLZuBmodZXCXfTgZ82+U32mBOFy0p0E ZD3OYsG7Ahx/YkuIl3xKnyiA/GzqBtxBaLvfxb0hQMeadarIdYFxiHqRnAfKGkIl AikLT8+wWsgK3PdmQoWr8UytvrtlnBjB+tHDr6G1W4d9I/3px/p+OdGOQ2XeY73s pwG5o+Xi0OckU0fJNtjgCVDQzrk5sw7LgaR9n0SYgOl/v81VIOI0xAsg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hCTFJD3WJvbq; Mon, 30 Apr 2012 23:20:43 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.25.92]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 630FB171476; Mon, 30 Apr 2012 23:20:41 +0100 (IST) Message-ID: <4F9F1039.8000402@cs.tcd.ie> Date: Mon, 30 Apr 2012 23:20:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Ned Freed References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> In-Reply-To: <01OEXMZ1FWDW0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, Paul Wouters , Paul Hoffman , "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 22:20:47 -0000 On 04/30/2012 11:07 PM, Ned Freed wrote: > >> I think we may be wandering from the appsdir review of the >> DANE draft. If we are, please reduce the cc list to one list, >> either apps-discuss (with a different subject probably), or >> DANE, or if this is still relevant to the concluded IETF LC >> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine. > > I strongly disagree. This is all in response to the apps area review of a DANE > WG document and in that context it is entirely appropriate to be cc'ing both > the apps area list and the dane list. Indeed, if you fail to do so, your > comments will fail to be read by one constituency or another. It is not > reasonable to expect everyone on the apps area list to subscribe to the DANE > list for this or vice versa. Fair enough. However, I don't see what potential changes to the DANE document are being discussed in a bunch of this mail. I do see people talking about tricky issues with CNAMEs and XMPP etc. (Changing the subject when appropriate would also be good.) If people seriously want that kind of text in the DANE document then they'd presumably start proposing something specific or else be yelling that DANE needs to be held up for a bit, and I'm not seeing any of that (in most of the thread). > And yes, this means that some folks will get multiple copies. Life is hard > someitmes; deal with it. Dealing with lots of mail is fine - even I've gotten used to it:-) Finding the relevant bits of the thread when its wandered off into how to do XMPP's DNA thing better is harder, hence my mail. S. > > Ned From stpeter@stpeter.im Mon Apr 30 15:24:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8321E80DC; Mon, 30 Apr 2012 15:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUGhfoqq0Cxh; Mon, 30 Apr 2012 15:24:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59021E80DB; Mon, 30 Apr 2012 15:24:38 -0700 (PDT) Received: from [10.154.131.165] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1A6C340058; Mon, 30 Apr 2012 16:39:28 -0600 (MDT) Message-ID: <4F9F1122.7080603@stpeter.im> Date: Mon, 30 Apr 2012 15:24:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <201204300316.q3U3GFcF002018@new.toad.com> <6F57A596-7B58-423E-B2A1-9C3103B9E688@cisco.com> <7CBBA998-7681-4885-A5E9-387F32DCE990@cisco.com> <7584CC56-4202-45B5-81CD-BF77872D61D1@vpnc.org> <708C6B7F-A6E7-4DF5-9A77-7718791B7CE6@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list , Paul Hoffman , XMPP Working Group Subject: Re: [dane] [xmpp] Documenting DANE for XMPP (WAS: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 22:24:39 -0000 [ - apps-discuss ] On 4/30/12 2:48 PM, Richard L. Barnes wrote: > +1 to documenting the use of DANE with XMPP > > +1 also to incorporating this discussion in a broader DNA / "server federation" document I agree with Paul that it would be nice to have a standalone DANE+XMPP document available that other folks can point to when working on DANE+FOO specs, but I also agree with Matt about the desirability of having one document about XMPP federation that developers can reference. For now I think Matt and I will work on a separate DANE+XMPP spec and then fold that in later when all the other federation pieces are complete. Peter -- Peter Saint-Andre https://stpeter.im/ From ned.freed@mrochek.com Mon Apr 30 15:47:10 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707AF21E80E4; Mon, 30 Apr 2012 15:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z6+WNilC24b; Mon, 30 Apr 2012 15:47:10 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EC82921E80E2; Mon, 30 Apr 2012 15:47:09 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXO8GJRSG000T76@mauve.mrochek.com>; Mon, 30 Apr 2012 15:47:04 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 15:46:59 -0700 (PDT) Message-id: <01OEXO8DBSKY0006TF@mauve.mrochek.com> Date: Mon, 30 Apr 2012 15:41:57 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Apr 2012 23:20:41 +0100" <4F9F1039.8000402@cs.tcd.ie> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> To: Stephen Farrell Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 22:47:10 -0000 > On 04/30/2012 11:07 PM, Ned Freed wrote: > > > >> I think we may be wandering from the appsdir review of the > >> DANE draft. If we are, please reduce the cc list to one list, > >> either apps-discuss (with a different subject probably), or > >> DANE, or if this is still relevant to the concluded IETF LC > >> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine. > > > > I strongly disagree. This is all in response to the apps area review of a DANE > > WG document and in that context it is entirely appropriate to be cc'ing both > > the apps area list and the dane list. Indeed, if you fail to do so, your > > comments will fail to be read by one constituency or another. It is not > > reasonable to expect everyone on the apps area list to subscribe to the DANE > > list for this or vice versa. > Fair enough. However, I don't see what potential changes to the > DANE document are being discussed in a bunch of this mail. I do > see people talking about tricky issues with CNAMEs and XMPP > etc. (Changing the subject when appropriate would also be > good.) If people seriously want that kind of text in the DANE > document then they'd presumably start proposing something specific > or else be yelling that DANE needs to be held up for a bit, and > I'm not seeing any of that (in most of the thread). Again, I'm not taking any position on the interaction of TLSA records and services that use SRV or SRV-like mechanisms. That said, I think most of the comments are essentially saying that not discussing how TLSA records would interact with such services at all - even if that discussion is simply to say that those services need to specify how they are going to use TLSA records - is a mistake. And I have to say that is a pretty compelling argument. > > And yes, this means that some folks will get multiple copies. Life is hard > > someitmes; deal with it. > Dealing with lots of mail is fine - even I've gotten used to > it:-) Finding the relevant bits of the thread when its wandered > off into how to do XMPP's DNA thing better is harder, hence > my mail. Don't you think it might be appropriate to discuss how specific services actually do this sort of stuff in reaching a decision as to how TLSA records should work in these contexts? Ned From cloos@jhcloos.com Mon Apr 30 16:00:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6A21E810C; Mon, 30 Apr 2012 16:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F10R98pwapKX; Mon, 30 Apr 2012 16:00:35 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFF921E810B; Mon, 30 Apr 2012 16:00:35 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 0D0BD40019; Mon, 30 Apr 2012 23:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1335826834; bh=Nt41BhkKLmVno2o99PRoswmVJnFPplHRqXLexhGgbMo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=cvGAG44kJQk0xGm+SNB676IAKqvQVLabOKjXDFZzRiquKLGLrCthfMw42YbSKE9CF JHGLMtEPPt1WIAfw2A8DOWE7yvuYC3Owose2Xe1Pn5dT7UO5ju0uqO5oiBHc+JNtHe ZT9yCAXL4TAp1EyUi467IhFfxxVvgoqm2g2P1Pnk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C1E5D360048; Mon, 30 Apr 2012 22:36:01 +0000 (UTC) From: James Cloos To: Ned Freed In-Reply-To: <01OEXJW3QF0G0006TF@mauve.mrochek.com> (Ned Freed's message of "Mon, 30 Apr 2012 13:41:32 -0700 (PDT)") References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 30 Apr 2012 18:36:01 -0400 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:120430:ned.freed@mrochek.com::wrAT0vhLRP2UURkk:000000000000000000000000000000000000000h9Bkv X-Hashcash: 1:30:120430:dane@ietf.org::75n2YagWNEUF1SUe:0005gMAI X-Hashcash: 1:30:120430:marka@isc.org::jqoUzg6QxVjQZ8SF:000T9DL8 X-Hashcash: 1:30:120430:"apps-discuss\@ietf.org"::CLkq6Ma/vk6TnMPf:000000000000000000000000000000000000Fm2Qy X-Hashcash: 1:30:120430:apps-discuss@ietf.org::iTJbkBlAa5FfE4Im:000000000000000000000000000000000000000VXqJH X-Hashcash: 1:30:120430:paul.hoffman@vpnc.org::u9yh2i88AgXOxV1q:000000000000000000000000000000000000000o17nr X-Hashcash: 1:30:120430:iesg@ietf.org::cjfbOZsC9QjC3goZ:000KfHMB X-Hashcash: 1:30:120430:paul@nohats.ca::nMEGmj5K/R92y2lW:003RURy Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 23:00:36 -0000 >>>>> "NF" == Ned Freed writes: NF> apps-discuss. Id: <01OEWP11R5NK0006TF@mauve.mrochek.com> Thanks. I found it in my backup and remember reading (most of) it. You reference rfc 2181 §10.3 which explains that: [MX lookups cause] "additional section processing" in which address records associated with the value of the record sought are appended to the answer.... And that: Additional section processing does not include CNAME records, That indeed makes pointing an MX RR at a CNAME RR a poor choice. Thanks. I'd forgotten to consider additional processing in my earlier note. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From stephen.farrell@cs.tcd.ie Mon Apr 30 16:11:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51E121E8048; Mon, 30 Apr 2012 16:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.806 X-Spam-Level: X-Spam-Status: No, score=-101.806 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3bmRm8eocXa; Mon, 30 Apr 2012 16:11:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E0F6C21F866D; Mon, 30 Apr 2012 16:11:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5659E1714F2; Tue, 1 May 2012 00:11:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1335827506; bh=SpTvX22rre+gzp TETaZPtKEzLIsqXYJu98usO0yEqYM=; b=Q1fTp6rOrO0PVDEcjDc3+hA+tQtbZA NkekirDhn7MisHKkkba3eV+svxousmj4aXkNQqHUMtYaL2/dl/m1X+2iVv5oYVoi yPEEmO4jJRxypCXdn7w2orWDMHJ2gztI7s8/NCqfEF5ikoW7b7uTVeGF1313geZy 3CIlrR3P1xslvT/aw3KSb7QssOVex26xHbAwStIuQpoQefTuijg/FePtVTB68xvC URSNDYF1W4ZLK0w31S5Gq3nNtQRgh/B6EO06WirAa8As208SWGNKkgyf/lhU+DVN ggGsmACjZX/hJLpnVQXPVZubSawb3n/arJMS20ruSHwrCQv0cp6kk0MQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id i3vmsko36WQ5; Tue, 1 May 2012 00:11:46 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.25.92]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1B39B1714F1; Tue, 1 May 2012 00:11:46 +0100 (IST) Message-ID: <4F9F1C31.50602@cs.tcd.ie> Date: Tue, 01 May 2012 00:11:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: Ned Freed References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> In-Reply-To: <01OEXO8DBSKY0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, Paul Wouters , Paul Hoffman , "apps-discuss@ietf.org" , dane@ietf.org Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 23:11:49 -0000 On 04/30/2012 11:41 PM, Ned Freed wrote: > > >> On 04/30/2012 11:07 PM, Ned Freed wrote: >>> >>>> I think we may be wandering from the appsdir review of the >>>> DANE draft. If we are, please reduce the cc list to one list, >>>> either apps-discuss (with a different subject probably), or >>>> DANE, or if this is still relevant to the concluded IETF LC >>>> for DANE, then DANE+IESG or ietf@ietf.org is in fact fine. >>> >>> I strongly disagree. This is all in response to the apps area review of a DANE >>> WG document and in that context it is entirely appropriate to be cc'ing both >>> the apps area list and the dane list. Indeed, if you fail to do so, your >>> comments will fail to be read by one constituency or another. It is not >>> reasonable to expect everyone on the apps area list to subscribe to the DANE >>> list for this or vice versa. > >> Fair enough. However, I don't see what potential changes to the >> DANE document are being discussed in a bunch of this mail. I do >> see people talking about tricky issues with CNAMEs and XMPP >> etc. (Changing the subject when appropriate would also be >> good.) If people seriously want that kind of text in the DANE >> document then they'd presumably start proposing something specific >> or else be yelling that DANE needs to be held up for a bit, and >> I'm not seeing any of that (in most of the thread). > > Again, I'm not taking any position on the interaction of TLSA records and > services that use SRV or SRV-like mechanisms. That said, I think most of the > comments are essentially saying that not discussing how TLSA records would > interact with such services at all - even if that discussion is simply to say > that those services need to specify how they are going to use TLSA records - > is a mistake. And I have to say that is a pretty compelling argument. Could well be. What changes to the text in 1.3 of -20 do you think are needed if any? " Note that this document does not cover how to associate certificates with domain names for application protocols that depend on SRV, NAPTR, and similar DNS resource records; it is expected that later updates to this document might cover methods for making those associations." The authors and a WG chair figure they've handled the IETF LC comments already. I need to figure out if they have and this thread is not helping me at least. (Given that I already know this is a tricky area.) >>> And yes, this means that some folks will get multiple copies. Life is hard >>> someitmes; deal with it. > >> Dealing with lots of mail is fine - even I've gotten used to >> it:-) Finding the relevant bits of the thread when its wandered >> off into how to do XMPP's DNA thing better is harder, hence >> my mail. > > Don't you think it might be appropriate to discuss how specific services > actually do this sort of stuff in reaching a decision as to how TLSA records > should work in these contexts? I do. I'm suggesting that the discussion, while useful in general, has perhaps wandered and is no longer necessarily useful for figuring out what this draft needs to say. S. > > Ned From fanf2@hermes.cam.ac.uk Mon Apr 30 16:47:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208CC21E80A8; Mon, 30 Apr 2012 16:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CBaw+QTyS2M; Mon, 30 Apr 2012 16:47:44 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id D56D821E8041; Mon, 30 Apr 2012 16:47:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43404) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SP0JM-0001DV-RQ (Exim 4.72) (return-path ); Tue, 01 May 2012 00:47:20 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SP0JM-0002Qr-Es (Exim 4.67) (return-path ); Tue, 01 May 2012 00:47:20 +0100 Date: Tue, 1 May 2012 00:47:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: James Cloos In-Reply-To: Message-ID: References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1082916895-1335829640=:17365" Sender: Tony Finch Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 30 Apr 2012 23:47:45 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-1082916895-1335829640=:17365 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE James Cloos wrote: > > You reference rfc 2181 =A710.3 which explains that: > > [MX lookups cause] "additional section processing" in > which address records associated with the value of the > record sought are appended to the answer.... > > And that: > > Additional section processing does not include CNAME records, > > That indeed makes pointing an MX RR at a CNAME RR a poor choice. However an MTA cannot rely on additional section processing because additional RRsets can be silently omitted - see RFC 1034 section 4.3.2 point 6 and RFC 2181 section 9. So an MTA has to look up any address records that are missing from the MX answer, which means CNAMEs don't cause problems unless the MTA makes a special effort to forbid them. Tony. --=20 f.anthony.n.finch http://dotat.at/ Humber, Thames, Dover: Northeast 5 to 7, becoming variable 3 or 4. Moderate= , occasionally rough. Thundery rain or showers, fog patches. Moderate or good= , occasionally very poor. --1870870024-1082916895-1335829640=:17365-- From marka@isc.org Mon Apr 30 17:15:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FC121F8748; Mon, 30 Apr 2012 17:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RiQMeuL+wH3; Mon, 30 Apr 2012 17:15:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC621F8734; Mon, 30 Apr 2012 17:15:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2AF345F9C33; Tue, 1 May 2012 00:14:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4c27:d59:8c27:a78b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3203F216C31; Tue, 1 May 2012 00:14:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C44672043D0C; Tue, 1 May 2012 10:14:40 +1000 (EST) To: mrex@sap.com From: Mark Andrews References: <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> In-reply-to: Your message of "Mon, 30 Apr 2012 17:37:19 +0200." <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp> Date: Tue, 01 May 2012 10:14:39 +1000 Message-Id: <20120501001440.C44672043D0C@drugs.dv.isc.org> Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 00:15:15 -0000 In message <201204301537.q3UFbJic013190@fs4113.wdf.sap.corp>, Martin Rex writes: > Tony Finch wrote: > > > > Martin Rex wrote: > > > > > > > The security properties of any MX, CNAME, A or AAAA lookups during > > > > > connection establishment with that server are irrelevant for DANE > > > > > (and invisible to PKIX). > > > > > > > > RFC 6125 allows for secure name indirections. > > > > > > Which _secure_ name indirections are you thinking of? > > > > RFC 6125 says: > > > > The client might need to extract the source domain and application > > service type from the input(s) it has received. The extracted data > > MUST include only information that can be securely parsed out of the > > inputs (e.g., parsing the fully qualified DNS domain name out of the > > "host" component (or its equivalent) of a URI or deriving the > > application service type from the scheme of a URI) or information > > that is derived in a manner not subject to subversion by network > > attackers (e.g., pulling the data from a delegated domain that is > > explicitly established via client or system configuration, resolving > > the data via [DNSSEC], or obtaining the data from a third-party > > domain mapping service in which a human user has explicitly placed > > trust and with which the client communicates over a connection or > > association that provides both mutual authentication and integrity > > checking). > > > One should not confuse DNSSEC protection of DNS records (which provide > only data integrity and data origin authentication) with the concept > of a secure directory service providing name translations. When you add a CNAME you are asserting that the canonical name for the owner of the CNAME is the target of the CNAME. CNAME does NOT mean "hosted at" which is how HTTP{S} treat CNAME. CNAME *really* should change the expect name of any CERT, unfortunately nobody asked for a "hosted at" record for HTTP{S} and the closest fit in the existing records was CNAME. > Sprinkling security equally across all DNS records also seems like > a bad idea. I think it would be much more sensible to limit the > security-relevant DNS records (and indirections allowed for them) > to _very_ few records, and preferably all _new_ records, because > DNSSEC-less zones will be with us for many years to come, and > > I believe it would be a really bad idea to change the sensitivity > of existing DNS records underneath DNS registrar's feet. All the records registrars handle require and always have required protection from unauthorised updates. DNSSEC has not changed that. If your registrar is not performing that service properly pick a different registrar. The world is assuming that all registrars are providing data protection for the records being added. > For TLSA records it would be OK if DNS software (and DNS servers) > performed some plausibility checks, e.g. warn prominently if TLSA > records are present in a Zone but no DNSSEC is active for the zone. > Something which does not make sense for any of the traditional > DNS records. The TLSA record is just ignored if it is insecure. Note it can be signed yet still be insecure as far as the client is concerned. > Looking at the example from a previous post: > > > > > ;; QUESTION SECTION: > > ;universalmusic.com. IN MX > > > > ;; ANSWER SECTION: > > universalmusic.com. 3600 IN MX 10 mail.global.frontbridge.com. > > For regular DANE, it is sufficient if (but also necessary that) > the DNS-Domain "universalmusic.com" has DNSSEC active in order to > securely provide a TLSA record for > > _25._tcp.universalmusic.com. > > and simultaneously independent from the DNSSEC status of frontbridge.com. And for STARTTLS you only need universalmusic.com MX record to be secure and that mail.global.frontbridge.com have a CERT issued in that name. If you want to prevent downgrade attacks then you need either a "Secure MX" record or _25._tcp.mail.global.frontbridge.com to be signed with the appropriate TLSA record. > If you want to allow DNS-based indirection, and in particular on existing > DNS records, then you would have to enforce that *ALL* domains that > are traversed during all possible DNS indirections have DNSSEC active > and that all lookups are verified, and require that the SMTP-software > aborts if DNSSEC verification of one of the indirections fails or > is not possible, and it may be difficult to impossible for the DNS-Software > (maintenance tools and DNS-Server) to help you maintaining consistency > across all those possible indirections, and close to impossible for the > DNS admins to understand the implications. If a site cares about the security of the email being sent to it then it signs its zones and adds relevent TLSA records to prevent downgrade attacks or if email is being handled by a third party that the relevent zones operated by the third party are signed. Moving to "Secure MX" records would provide the signaling and indirection with just one record. You just don't have implict "Secure MX" records, just implict MX records. Mark > -Martin > _______________________________________________ > 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 ned.freed@mrochek.com Mon Apr 30 19:11:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C26921F870A; Mon, 30 Apr 2012 19:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIKAE21-UAV0; Mon, 30 Apr 2012 19:11:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8521F8705; Mon, 30 Apr 2012 19:11:40 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEXVD10R1S000OJX@mauve.mrochek.com>; Mon, 30 Apr 2012 19:11:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 19:11:30 -0700 (PDT) Message-id: <01OEXVCY097U0006TF@mauve.mrochek.com> Date: Mon, 30 Apr 2012 18:52:50 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 May 2012 00:11:45 +0100" <4F9F1C31.50602@cs.tcd.ie> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> To: Stephen Farrell Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 02:11:41 -0000 > > Again, I'm not taking any position on the interaction of TLSA records and > > services that use SRV or SRV-like mechanisms. That said, I think most of the > > comments are essentially saying that not discussing how TLSA records would > > interact with such services at all - even if that discussion is simply to say > > that those services need to specify how they are going to use TLSA records - > > is a mistake. And I have to say that is a pretty compelling argument. > Could well be. What changes to the text in 1.3 of -20 do you think > are needed if any? > " Note that this document does not cover how to associate > certificates with domain names for application protocols that depend > on SRV, NAPTR, and similar DNS resource records; it is expected that > later updates to this document might cover methods for making those > associations." Well, to be blunt, I think that by trying to avoid solving the problem now while not giving up control over future solutions this ends up being unacceptable to everyone. What if a service comes along that uses SRV records and wants to specify how TLSA records are used to secure them? According to this text, it can't - the clear implication here is that this has to be done by revising the DANE specification itself. And what about existing services like email where it is arguably the case that simply using TLSA records to secure the A/AAAA targets MX records is sufficient? A very short "secure email transport" specification could be writte that refers to the DANE specification, but this would also seem to forbid that. I would much rather see a note that simply refers to future specification work being needed, not specifically to a DANE revision being needed. But even this may not be acceptable for all I know. It may turn out that using DANE to secure the terminal A/AAAA records (modulo CNAMEs) is actually an acceptable default for SRV/MX/NATPR-based services. I could easily be wrong, but it seems to me that this is what all this additional discussion is about. Ned From i.grok@comcast.net Mon Apr 30 19:14:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783E121F8713 for ; Mon, 30 Apr 2012 19:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6HKmPLgSN1l for ; Mon, 30 Apr 2012 19:14:24 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id C604621F8705 for ; Mon, 30 Apr 2012 19:14:23 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id 4R4i1j0051c6gX853SEP4W; Tue, 01 May 2012 02:14:23 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta23.westchester.pa.mail.comcast.net with comcast id 4SEN1j01400PQ6U3jSEPD1; Tue, 01 May 2012 02:14:24 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q412EHXi025527 for ; Mon, 30 Apr 2012 22:14:17 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q412EHvH025526 for dane@ietf.org; Mon, 30 Apr 2012 22:14:17 -0400 Date: Mon, 30 Apr 2012 22:14:17 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120501021417.GA23877@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <6CC342E4-035B-4C4A-B4DD-912FDA1B73D0@vpnc.org> <1139238B-DA5A-433D-B87F-0BC3D938B9CD@kumari.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <1139238B-DA5A-433D-B87F-0BC3D938B9CD@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Draft -20 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 02:14:24 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 30, 2012 at 10:33:18AM -0400, Warren Kumari wrote: > On Apr 29, 2012, at 7:45 PM, Paul Hoffman wrote: >=20 > > Greetings again. Jakob and I have made the editorial and > > substantiative changes requested in IETF Last Call. If the WG Chairs > > think we caught everything, we request that they pass this along to > > the AD so the document can be considered by the IESG. If we missed > > anything, we can make more changes. > >=20 >=20 > Believe we have caught everything well enough=E2=80=A6. Adding AD to the = CC line. I don't see any edits that address the concern about section 8.1 mixing up CAs and validators. --=20 Scott Schmit --7AUc2qLy4jB3hD7Z Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTAxMDIxNDE3WjAjBgkqhkiG9w0BCQQxFgQUB3c50hcS 0TNHEXDVSIdrA4E7SgkweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAqBxjzWJQ yp/sLIDn5qWH69sXMBGqIxqpmcZFK0KRqPp+lYQ7OtHz/I7r1/Zc2OR0q7HcgLOKYGtBTBg4 oAl4ovtFXffAMZBRydG2/JIUKsTjPFa1JDD4ymXqYpLv+MaAk5DDcdXpaje8tTIE2yD0lKbI annvTVHK93xMo5DbesUy5ji/kJRU60Zv+EOjB4g1jMkqcRXPcHpvMeYjR3APS2sv7oJaAZJu Tvt/t/H9RSsUvsnLLBsnez7U0f6Ei/BsgrpOdWmahc0duoKOiw8g3grqZxrEtSFZAPYXuYg9 +4jXxslH68NyNMHsdV2N1UBjXky27BBWcB72eRfirJKCYg== --7AUc2qLy4jB3hD7Z-- From stpeter@stpeter.im Mon Apr 30 19:17:01 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF8821E80CD; Mon, 30 Apr 2012 19:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03X8RkeCnelA; Mon, 30 Apr 2012 19:17:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5521E80C5; Mon, 30 Apr 2012 19:17:00 -0700 (PDT) Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 620BC40058; Mon, 30 Apr 2012 20:31:53 -0600 (MDT) Message-ID: <4F9F479A.10501@stpeter.im> Date: Mon, 30 Apr 2012 19:16:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ned Freed References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> In-Reply-To: <01OEXVCY097U0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 02:17:02 -0000 On 4/30/12 6:52 PM, Ned Freed wrote: > >>> Again, I'm not taking any position on the interaction of TLSA records and >>> services that use SRV or SRV-like mechanisms. That said, I think most of the >>> comments are essentially saying that not discussing how TLSA records would >>> interact with such services at all - even if that discussion is simply to say >>> that those services need to specify how they are going to use TLSA records - >>> is a mistake. And I have to say that is a pretty compelling argument. > >> Could well be. What changes to the text in 1.3 of -20 do you think >> are needed if any? > >> " Note that this document does not cover how to associate >> certificates with domain names for application protocols that depend >> on SRV, NAPTR, and similar DNS resource records; it is expected that >> later updates to this document might cover methods for making those >> associations." > > Well, to be blunt, I think that by trying to avoid solving the problem now > while not giving up control over future solutions this ends up being > unacceptable to everyone. > > What if a service comes along that uses SRV records and wants to specify how > TLSA records are used to secure them? According to this text, it can't - the > clear implication here is that this has to be done by revising the DANE > specification itself. > > And what about existing services like email where it is arguably the case that > simply using TLSA records to secure the A/AAAA targets MX records is > sufficient? A very short "secure email transport" specification could > be writte that refers to the DANE specification, but this would also seem > to forbid that. > > I would much rather see a note that simply refers to future specification work > being needed, not specifically to a DANE revision being needed. I had the same concern but then I realized that "later updates to this document might cover methods for making those associations" could be construed as referring to add-on documents that would officially update the DANE-RFC-to-be, not as saying that such changes would need to be made in the single DANEbis document that would cover all possible uses of the TLSA RR. Peter -- Peter Saint-Andre https://stpeter.im/ From i.grok@comcast.net Mon Apr 30 19:19:29 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8205D21E812D for ; Mon, 30 Apr 2012 19:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-av+uKPIYbv for ; Mon, 30 Apr 2012 19:19:28 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id A2C7321E80F3 for ; Mon, 30 Apr 2012 19:19:28 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta09.emeryville.ca.mail.comcast.net with comcast id 4SAc1j0031afHeLA9SKUsL; Tue, 01 May 2012 02:19:28 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta17.emeryville.ca.mail.comcast.net with comcast id 4SKS1j01A00PQ6U8dSKT2p; Tue, 01 May 2012 02:19:28 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q412JQMA025548 for ; Mon, 30 Apr 2012 22:19:26 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q412JQVB025547 for dane@ietf.org; Mon, 30 Apr 2012 22:19:26 -0400 Date: Mon, 30 Apr 2012 22:19:26 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120501021926.GB23877@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="xgyAXRrhYN0wYx8y" Content-Disposition: inline In-Reply-To: <01OEXVCY097U0006TF@mauve.mrochek.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 02:19:29 -0000 --xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 30, 2012 at 06:52:50PM -0700, Ned Freed wrote: > > Could well be. What changes to the text in 1.3 of -20 do you think > > are needed if any? >=20 > > " Note that this document does not cover how to associate > > certificates with domain names for application protocols that depend > > on SRV, NAPTR, and similar DNS resource records; it is expected that > > later updates to this document might cover methods for making those > > associations." >=20 > Well, to be blunt, I think that by trying to avoid solving the problem now > while not giving up control over future solutions this ends up being > unacceptable to everyone.=20 Maybe I'm off-base, but I interpreted that as "a later RFC marked as Updates: ", not "a later RFC that obsoletes + rewrites this one." --=20 Scott Schmit --xgyAXRrhYN0wYx8y Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTAxMDIxOTI2WjAjBgkqhkiG9w0BCQQxFgQUAbmnveBj ck+r4yLhAEkT7RLkoZUweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAEctvPVwW AVIJ3RTzjAgPtlPbzggJNp6CJZirhu3scF9i5dLc4qI4a1kMGTaOnlSu/ssJ7JD4WsMCxIcT 0OE2MYLdTBVlF2PnES6xXikhw8Oy1nFTScwFUkK6XwxbwsOA+np+03rRkVPilyY4f6d2pSnP XXIGYKONpFmCp3r1Cr0vr829Ca19mvDov3o2J6iMcQpR8zSzsqvd/+X6/75k38lhf4Eu/ejd P9w1bpEUCCRVa7fVAbnbFH3YdFxiMxP/GbnYuui5CPbcudvVi/NG1F+yvFA7XfWpqVvO4jbK W1HPThhZzcGcEwnIbAq8i71SrwS2bTLsOGUVH3Gwui5S7w== --xgyAXRrhYN0wYx8y-- From paul.hoffman@vpnc.org Mon Apr 30 19:30:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D9921E80BE; Mon, 30 Apr 2012 19:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4yCNV9Hzx4J; Mon, 30 Apr 2012 19:30:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A98421E80BA; Mon, 30 Apr 2012 19:30:52 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q412UoU9029360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Apr 2012 19:30:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F9F479A.10501@stpeter.im> Date: Mon, 30 Apr 2012 19:30:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD409C0-F932-4198-B98F-55295AA56B93@vpnc.org> References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> To: Ned Freed X-Mailer: Apple Mail (2.1257) Cc: "iesg@ietf.org IESG" , "apps-discuss@ietf.org Discuss" , IETF DANE WG list Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 02:30:53 -0000 On Apr 30, 2012, at 7:16 PM, Peter Saint-Andre wrote: > On 4/30/12 6:52 PM, Ned Freed wrote: >>=20 >>>> Again, I'm not taking any position on the interaction of TLSA = records and >>>> services that use SRV or SRV-like mechanisms. That said, I think = most of the >>>> comments are essentially saying that not discussing how TLSA = records would >>>> interact with such services at all - even if that discussion is = simply to say >>>> that those services need to specify how they are going to use TLSA = records - >>>> is a mistake. And I have to say that is a pretty compelling = argument. >>=20 >>> Could well be. What changes to the text in 1.3 of -20 do you think >>> are needed if any? >>=20 >>> " Note that this document does not cover how to = associate >>> certificates with domain names for application protocols that = depend >>> on SRV, NAPTR, and similar DNS resource records; it is expected = that >>> later updates to this document might cover methods for making = those >>> associations." >>=20 >> Well, to be blunt, I think that by trying to avoid solving the = problem now >> while not giving up control over future solutions this ends up being >> unacceptable to everyone.=20 >>=20 >> What if a service comes along that uses SRV records and wants to = specify how >> TLSA records are used to secure them? According to this text, it = can't - the >> clear implication here is that this has to be done by revising the = DANE >> specification itself. >>=20 >> And what about existing services like email where it is arguably the = case that >> simply using TLSA records to secure the A/AAAA targets MX records is >> sufficient? A very short "secure email transport" specification could >> be writte that refers to the DANE specification, but this would also = seem >> to forbid that. >>=20 >> I would much rather see a note that simply refers to future = specification work >> being needed, not specifically to a DANE revision being needed. >=20 > I had the same concern but then I realized that "later updates to this > document might cover methods for making those associations" could be > construed as referring to add-on documents that would officially = update > the DANE-RFC-to-be, not as saying that such changes would need to be > made in the single DANEbis document that would cover all possible uses > of the TLSA RR. Peter's interpretation is certainly the one we intended: that is why I = used "updates" not "replacements" in the sentence quoted above. Ned: if you have a better wording for the sentence, I strongly suspect = the WG would be happy with such a clarification. --Paul Hoffman From stpeter@stpeter.im Mon Apr 30 19:44:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8101B21E8144; Mon, 30 Apr 2012 19:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NicXfsc6+TBG; Mon, 30 Apr 2012 19:44:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 372E021E80BA; Mon, 30 Apr 2012 19:44:01 -0700 (PDT) Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F2A8440058; Mon, 30 Apr 2012 20:58:53 -0600 (MDT) Message-ID: <4F9F4DEE.1090309@stpeter.im> Date: Mon, 30 Apr 2012 19:43:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , dane@ietf.org, iesg@ietf.org References: <4F95CA0B.8050202@stpeter.im> In-Reply-To: <4F95CA0B.8050202@stpeter.im> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 02:44:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've reviewed version -20. Herewith a bit of follow-up. On 4/23/12 2:30 PM, Peter Saint-Andre wrote: > This is a supplemental AppsDir review of draft-ietf-dane-protocol > (for background on AppsDir, please see > ). > > > Although Murray Kucherawy has already reviewed this I-D on behalf of > the AppsDir, folks in the Applications Area realize that wide > deployment of the TLSA Resource Record might have a significant > impact on applications, so we are performing additional reviews. > Please treat these comments just as you would any other Last Call > feedback. > > Document: draft-ietf-dane-protocol Title: "The DNS-Based > Authentication of Named Entities (DANE) Protocol for Transport > Layer Security (TLS)" Reviewer: Peter Saint-Andre Review Date: > 2012-04-23 IETF Last Call Date: 2012-04-25 IESG Telechat: not yet > scheduled > > Summary: This draft is almost ready for publication as an Standards > Track RFC but has a few issues that should be fixed before > publication. > > Major Issue: > > This document does not mention that TLSA records cannot be used > directly in application protocols that depend on SRV (or NAPTR or > similar technologies). Although I realize that the DANE WG decided, > after much discussion, that the interaction between TLSA records > and SRV records is out of scope for this specification (and I do > not mean to reopen that discussion now), it would be very helpful > for this specification to reflect the results of that discussion. > Although I make specific suggestions regarding text under the Minor > Issues below, in general I think this document needs to be clearer > about the assumptions it has made in this regard; in fact, it seems > to me that an explicit applicability statement is warranted to > avoid confusion of the kind that Dave Cridland experienced (see his > Last Call comments). Absent such an applicability statement, it > would be good to state up front something that currently is not > made explicit until the first sentence of the Security > Considerations: > > The security of the DNS RRtype described in this document relies on > the security of DNSSEC as used by the client requesting A/AAAA and > TLSA records. > > The import of "and" in that sentence is significant, and needs to > be highlighted earlier in the specification. The new text in Section 1.3 addresses my concern. > Minor Issues: > > 1. In Section 1.2, these sentences might involve a slight > oversimplication: > > A TLS client begins a connection by exchanging messages with a TLS > server. It looks up the server's name using the DNS to get an > Internet Protocol (IP) address associated with the name. It then > begins a connection to a client-chosen port at that address, and > sends an initial message there. > > 1a. The second sentence might be construed as requiring only one > step (look up the name, get an IP address), whereas we know that > sometimes multiple steps are involved (think SRV). I'd be more > comfortable if we added a clause at the end along the lines of > "sometimes via multiple steps". > > 1b. The term "client-chosen port" makes it sound as if the client > can choose any port it pleases when connecting to the TLS server. > Yet typically the port is derived from a URI, "hardcoded" into the > application protocol (sometimes as a fallback), or discovered via > the DNS (again, think SRV). We needn't reflect those alternatives > in the text, but at the least "appropriate" is better than > "client-chosen". The change from "client-chosen port" to "client-define port" is mystifying to me. Even assuming that "client-defined" was meant, it's not clear to me what a client-defined port is, and I see no effective difference between the old text and the new text. > 2. In Section 1.3, it is said that "This document only applies to > PKIX [RFC5280] certificates, not certificates of other formats." > Does this mean that a new RR type would need to be defined to > handle other formats (e.g., PGP as in RFC 6091), or only that > documents defining how to use TLSA records with those other > formats would need to define new values for the Certificate Usage > field? Please clarify. The new text reads: This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. Later updates to this document might specify how to use certificates in other formats. That doesn't make it clear what would be needed to specify how to use certificates in other formats (new RR type or new values for the Certificate Usage field?). I still think it would be better to make that clear so folks who update this document in the future know what to do. > 3. In Section 1.3, the following paragraph is true only for > application protocols that do not make use of SRV or similar > technologies: > > This document defines a secure method to associate the certificate > that is obtained from the TLS server with a domain name using DNS; > the DNS information needs to be be protected by DNSSEC. Because > the certificate association was retrieved based on a DNS query, the > domain name in the query is by definition associated with the > certificate. > > For example, in the case of XMPP the application client might > discover through a DNS SRV lookup that the XMPP service for > example.com is actually provided at im.example.net. In this case, > the domain name in the certificate presented by the TLS server > (im.example.net) is not the same as the certificate discovered via > the DNS TLSA lookup (example.com), so we can't simply stipulate > that "the domain name in the query is by definition associated > with the certificate". Here again that applicability statement > would be helpful, because this document assumes that you're > connecting to the IP address that you discover by means of DNS > A/AAAA lookup on the domain name contained in the prefixed DNS > domain name defined in Section 3. (As noted, this is made explicit > in the first sentence of the Security Considerations.) This is OK, per the new statement in Section 1.3. > 4. In Section 2.2, the term "whitespace" is underspecified. Does > that include, say, any Unicode space separator (Unicode General > Category Zs) or also line separators (Unicode General Category Zl) > or only certain code points in the ASCII range? Further, is the > whitespace significant in the examples from Section 2.3? I see no change in -20 to clarify this matter. > 5. To those of us accustomed to SRV records, at first glance the > prefixed DNS domain name format defined in Section 3 looks strange: > why not _http._tcp.www.example.com instead of > _443._tcp.www.example.com? But when we take off our SRV-colored > glasses and realize that DANE assumes a DNS A/AAAA lookup on the > domain name, it all makes sense. Perhaps it would be helpful to > mention the reasoning behind the port number (instead of > application name) here? This is OK to me now. > 6. In section 4, no mention is made of the application service that > the TLS expects to encounter at the TLS server: > > The TLS session that is to be set up MUST be for the specific port > number and transport name that was given in the TLSA query. > > Yet surely the application protocol can matter here, no? In > particular, given that 443 is the one true port, we know that folks > might run non-HTTP applications over that port (for evil reasons, > of course). Does DANE elide over the application protocol because > we simply assume that the "right" service is being served over any > particular port? What about service providers that wish to restrict > the usage of a certificate to a particular application service type > (cf. RFC 6125)? Or do we assume that it is enough to differentiate > among application services based on the underlying transport (as > seems to be the case in the text on "Multiple Ports" in Section 5)? > IMHO we have a bit of a muddle here. Paul explained this in a previous message. I think it's OK. > 7. The paragraph about SSL proxies in Section 8 says that "the TLS > client will get a certificate association from the DNS that will > not match the certificate that the SSL proxy uses with the client"; > however, if the SSL proxy is working in concert with an external > DNS validator, is it possible to mimic the behavior of current SSL > proxies? As Paul pointed out, the behavior of SSL proxies is undefined in any spec, and it's not the job of this spec to define them. OK with me. > Nits: > > 1. In Section 1.1, I suggest changing "using encryption" to "using > channel encryption" (since TLS uses connection-oriented encryption > methods, not object encryption). Done, thanks. > 2. Section 1.1, uses the term "subdomain" in the sentence "This > prevents an untrustworthy signer from compromising anyone's keys > except those in their own subdomains." The term "subdomain" is not > always well understood. I suggest explicitly citing Section 3.1 > of RFC 1034 here. Unchanged, but it's probably OK as-is. > 3. In Section 1.3, the phrase "the domain name where the data is > found" makes it sound as if DANE applies only to application > protocols that involve data retrieval, whereas we know it can be > used also for technologies that involve communication (email, IM, > etc.). I suggest "the domain name for the relevant application > service" or somesuch. The modified text looks good to me ("the domain name where the server application runs"). > 4. In Section 1.3, I suggest changing "server" (which might be > confused with the TLS server itself) to "service" or "application > service" in this sentence: "A DNS query can return multiple > certificate associations, such as in the case of a server is > changing from one certificate to another." Unchanged, but I think that's OK. In a follow-up email message, I also noted: ### One more issue is nagging at me: there is no definition or citation for "domain name" in Section 3. In particular, there is no indication of whether internationalized domain names are allowed (and, if so, in what format). I think it would good to make this clear by saying that a domain name can be either a "traditional domain name" (RFC 1034) or an "internationalized domain name" (RFC 5890); for the latter I think it would be best to say that the IDN's internationalized labels are represented only as A-labels. IMHO a short paragraph on this matter would be appropriate in Section 3 or in a new section entitled "Internationalization Considerations". ### I still think that this document needs to say something about IDNs. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+fTe4ACgkQNL8k5A2w/vyJiACgpyfjFCeKpB2KWq9KN01MKl91 sYcAoJcpNcbenV3yvknbhi14vWNy1T49 =iPW1 -----END PGP SIGNATURE----- From i.grok@comcast.net Mon Apr 30 21:01:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7685621E80E7 for ; Mon, 30 Apr 2012 21:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e64Fx41vTpjZ for ; Mon, 30 Apr 2012 21:01:40 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7BF21E809A for ; Mon, 30 Apr 2012 21:01:40 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4TmS1j0020ldTLk55U1ftp; Tue, 01 May 2012 04:01:39 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta04.westchester.pa.mail.comcast.net with comcast id 4U1f1j01G00PQ6U3QU1fe0; Tue, 01 May 2012 04:01:39 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.3) with ESMTP id q4141coQ026160 for ; Tue, 1 May 2012 00:01:38 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q4141cbD026159 for dane@ietf.org; Tue, 1 May 2012 00:01:38 -0400 Date: Tue, 1 May 2012 00:01:38 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120501040138.GA25922@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <4F9F4DEE.1090309@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 04:01:41 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 30, 2012 at 07:43:58PM -0700, Peter Saint-Andre wrote: > On 4/23/12 2:30 PM, Peter Saint-Andre wrote: > > 2. In Section 1.3, it is said that "This document only applies to=20 > > PKIX [RFC5280] certificates, not certificates of other formats."=20 > > Does this mean that a new RR type would need to be defined to=20 > > handle other formats (e.g., PGP as in RFC 6091), or only that=20 > > documents defining how to use TLSA records with those other > > formats would need to define new values for the Certificate Usage > > field? Please clarify. >=20 > The new text reads: >=20 > This document only applies to PKIX [RFC5280] certificates, not > certificates of other formats. Later updates to this document > might > specify how to use certificates in other formats. >=20 > That doesn't make it clear what would be needed to specify how to use > certificates in other formats (new RR type or new values for the > Certificate Usage field?). I still think it would be better to make > that clear so folks who update this document in the future know what > to do. It seems to me that this is addressed by this paragraph in 2.1.1: "The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values." > > 4. In Section 2.2, the term "whitespace" is underspecified. Does=20 > > that include, say, any Unicode space separator (Unicode General=20 > > Category Zs) or also line separators (Unicode General Category Zl)=20 > > or only certain code points in the ASCII range? Further, is the=20 > > whitespace significant in the examples from Section 2.3? >=20 > I see no change in -20 to clarify this matter. RFC 1035 (normative reference of RFC 4034, which is a normative reference of this draft), section 5 defines the format for zone files ("Master files" in RFC 1035). That RFC predates Unicode and IDN, and doesn't appear to be updated by any RFC spelling out use of Unicode in zone files. Based on that, I'd say that zone files are still ASCII-only (and a quick web search seems to confirm that that is the case, though I don't see any harm in adhering to the robustness principle here). At any rate, the definition of the TLSA presentation format and examples in this draft seem consistent with RFC 1035 and the definition for other RR types. > In a follow-up email message, I also noted: >=20 > ### >=20 > One more issue is nagging at me: there is no definition or citation > for "domain name" in Section 3. In particular, there is no indication > of whether internationalized domain names are allowed (and, if so, in > what format). I think it would good to make this clear by saying that > a domain name can be either a "traditional domain name" (RFC 1034) or > an "internationalized domain name" (RFC 5890); for the latter I think > it would be best to say that the IDN's internationalized labels are > represented only as A-labels. IMHO a short paragraph on this matter > would be appropriate in Section 3 or in a new section entitled > "Internationalization Considerations". >=20 > ### >=20 > I still think that this document needs to say something about IDNs. IDNs were defined in such a way that IDN-ignorant software will work correctly, so I don't see why spelling out the interaction with IDNs for DANE is necessary. Drafts governing the presentation, use, and consumption of IDNs explain how to do so with TLSA RRs just as well as for any other RR type. --=20 Scott Schmit --lrZ03NoBR/3+SXJZ Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNTAxMDQwMTM4WjAjBgkqhkiG9w0BCQQxFgQUa3Ehh5Vx 2nLK/LGpY4DulISoNkYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEASFMc6KXn wyiNQusOeMsiyEIXtkNhnBiNPj8WptTxSix0m7befiqvn5wWK3xdnUmNpZiNB/+D5UUT/GQk 6m8TbCGnhXOMhGz/ZhwJoubDQUJ48D7h477FUjL7QaLWHBTdIyP1/6D+PJnBhhdTSHofDQ5g Trufbk27GN5UjbZZAFkziOrbvNytQeE9Xk2N77wailPdWydtPvbgkJXSQc9mY3qwX5de0Znb NpEALjZFN/Yv44LJFiitphLnam8JZyvZJo6mu4I27ZPnTysxBlzsA/dAY8bp1Q0SYT0Zm3vj dgnBfQEIRelxBdoPsS3RKTUZkiGbZcnrVzyDgDXEvooLWg== --lrZ03NoBR/3+SXJZ-- From stpeter@stpeter.im Mon Apr 30 21:10:34 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0737D21F873E for ; Mon, 30 Apr 2012 21:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NOOsJDDmeRq for ; Mon, 30 Apr 2012 21:10:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9121F873D for ; Mon, 30 Apr 2012 21:10:33 -0700 (PDT) Received: from [107.16.139.250] (unknown [209.116.57.2]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 664F040058 for ; Mon, 30 Apr 2012 22:25:25 -0600 (MDT) Message-ID: <4F9F6236.3050303@stpeter.im> Date: Mon, 30 Apr 2012 21:10:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: dane@ietf.org References: <4F95CA0B.8050202@stpeter.im> <4F9F4DEE.1090309@stpeter.im> <20120501040138.GA25922@odin.ulthar.us> In-Reply-To: <20120501040138.GA25922@odin.ulthar.us> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 04:10:34 -0000 On 4/30/12 9:01 PM, Scott Schmit wrote: > On Mon, Apr 30, 2012 at 07:43:58PM -0700, Peter Saint-Andre wrote: >> On 4/23/12 2:30 PM, Peter Saint-Andre wrote: >>> 2. In Section 1.3, it is said that "This document only applies to >>> PKIX [RFC5280] certificates, not certificates of other formats." >>> Does this mean that a new RR type would need to be defined to >>> handle other formats (e.g., PGP as in RFC 6091), or only that >>> documents defining how to use TLSA records with those other >>> formats would need to define new values for the Certificate Usage >>> field? Please clarify. >> >> The new text reads: >> >> This document only applies to PKIX [RFC5280] certificates, not >> certificates of other formats. Later updates to this document >> might >> specify how to use certificates in other formats. >> >> That doesn't make it clear what would be needed to specify how to use >> certificates in other formats (new RR type or new values for the >> Certificate Usage field?). I still think it would be better to make >> that clear so folks who update this document in the future know what >> to do. > > It seems to me that this is addressed by this paragraph in 2.1.1: > > "The certificate usages defined in this document explicitly only apply > to PKIX-formatted certificates in DER encoding [X.690]. If TLS > allows other formats later, or if extensions to this RRtype are made > that accept other formats for certificates, those certificates will > need their own certificate usage values." Right, I missed that. Carry on. >>> 4. In Section 2.2, the term "whitespace" is underspecified. Does >>> that include, say, any Unicode space separator (Unicode General >>> Category Zs) or also line separators (Unicode General Category Zl) >>> or only certain code points in the ASCII range? Further, is the >>> whitespace significant in the examples from Section 2.3? >> >> I see no change in -20 to clarify this matter. > > RFC 1035 (normative reference of RFC 4034, which is a normative > reference of this draft), section 5 defines the format for zone files > ("Master files" in RFC 1035). That RFC predates Unicode and IDN, and > doesn't appear to be updated by any RFC spelling out use of Unicode in > zone files. > > Based on that, I'd say that zone files are still ASCII-only (and a quick > web search seems to confirm that that is the case, though I don't see > any harm in adhering to the robustness principle here). At any rate, > the definition of the TLSA presentation format and examples in this > draft seem consistent with RFC 1035 and the definition for other RR > types. Does whitespace include tab, linefeed, etc., or only SP (ASCII 20)? It really ought to be easy to clarify the matter. Just saying "whitespace" is less than clear, IMHO. >> In a follow-up email message, I also noted: >> >> ### >> >> One more issue is nagging at me: there is no definition or citation >> for "domain name" in Section 3. In particular, there is no indication >> of whether internationalized domain names are allowed (and, if so, in >> what format). I think it would good to make this clear by saying that >> a domain name can be either a "traditional domain name" (RFC 1034) or >> an "internationalized domain name" (RFC 5890); for the latter I think >> it would be best to say that the IDN's internationalized labels are >> represented only as A-labels. IMHO a short paragraph on this matter >> would be appropriate in Section 3 or in a new section entitled >> "Internationalization Considerations". >> >> ### >> >> I still think that this document needs to say something about IDNs. > > IDNs were defined in such a way that IDN-ignorant software will work > correctly, so I don't see why spelling out the interaction with IDNs > for DANE is necessary. Drafts governing the presentation, use, and > consumption of IDNs explain how to do so with TLSA RRs just as well as > for any other RR type. So it ought to be easy to say "IDNs are covered if they consist only of A-labels". Peter -- Peter Saint-Andre https://stpeter.im/ From jakob@kirei.se Mon Apr 30 23:05:38 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FDE21F873C for ; Mon, 30 Apr 2012 23:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V96JQI+BLzeL for ; Mon, 30 Apr 2012 23:05:37 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id F0CCD21F86E4 for ; Mon, 30 Apr 2012 23:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=20IQ4a32d3TEc5gZjOtxDge0R+7mYI2ZHAkCazR+DhU=; b=1eHwebah3oWMrgJQ+uvSUODD7P4t06AmCTwtliDkR9CbSKiyxLAOJiDC4jHpO+o0+C2qXahPZReDT 9Kdf+Hl35RW78+bOvp1YDrm0BRa3auVNQMl3ynMgfdmmeBF9J/NmDr4g25G09EletdKex9iNxnWnmL 9K9+G1IyiU1m6wFY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 1 May 2012 08:05:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> Date: Tue, 1 May 2012 08:05:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D005ED4-61DE-4CFF-8136-8AD5E30F66DB@kirei.se> References: <201204301353.q3UDrb2I007118@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: apps-discuss@ietf.org, dane@ietf.org, paul.hoffman@vpnc.org, iesg@ietf.org, alexey.melnikov@isode.com, paul@nohats.ca Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 06:05:38 -0000 On 30 apr 2012, at 15:53, Martin Rex wrote: > When trying to deliver mail to @toad.com, the only secure > question to ask is whether the server is authorized to process > Email for @toad.com. For certificates issued from the traditional > PKIX world, that would require a "toad.com" DNSName SAN. That would require large hosting provider, e.g. Google Apps, to update = their SMTP TLS certificates each and every time they added or removed a = customer. In my book, that would not scale. I believe we should focus on = securing the transport, not building a TLS-based application = authorization system. jakob From ned.freed@mrochek.com Mon Apr 30 23:34:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48821F86B4; Mon, 30 Apr 2012 23:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwtc91ZqC13c; Mon, 30 Apr 2012 23:34:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C3BA521F85E1; Mon, 30 Apr 2012 23:34:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OEY4K8KHJK000UX2@mauve.mrochek.com>; Mon, 30 Apr 2012 23:34:41 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OENEYWYFI80006TF@mauve.mrochek.com>; Mon, 30 Apr 2012 23:34:38 -0700 (PDT) Message-id: <01OEY4K69WQE0006TF@mauve.mrochek.com> Date: Mon, 30 Apr 2012 23:30:42 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 30 Apr 2012 19:16:58 -0700" <4F9F479A.10501@stpeter.im> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4F96D157.7020504@isode.com> <21AF6AE7-8BFB-457F-BB2D-39DA16206A8C@vpnc.org> <201204292309.q3TN9BcF027057@new.toad.com> <20120429235801.B8FB32036A98@drugs.dv.isc.org> <21E89A0F-05A8-4EF4-8F44-EA0D58F8F0E3@frobbit.se> <01OEXB2GEMB20006TF@mauve.mrochek.com> <01OEXJW3QF0G0006TF@mauve.mrochek.com> <4F9EFAFB.5050709@cs.tcd.ie> <01OEXMZ1FWDW0006TF@mauve.mrochek.com> <4F9F1039.8000402@cs.tcd.ie> <01OEXO8DBSKY0006TF@mauve.mrochek.com> <4F9F1C31.50602@cs.tcd.ie> <01OEXVCY097U0006TF@mauve.mrochek.com> <4F9F479A.10501@stpeter.im> To: Peter Saint-Andre Cc: Ned Freed , "apps-discuss@ietf.org" , dane@ietf.org, Paul Hoffman , iesg@ietf.org, Paul Wouters Subject: Re: [dane] [apps-discuss] AppsDir review of draft-ietf-dane-protocol-19 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2012 06:34:47 -0000 > On 4/30/12 6:52 PM, Ned Freed wrote: > > > >>> Again, I'm not taking any position on the interaction of TLSA records and > >>> services that use SRV or SRV-like mechanisms. That said, I think most of the > >>> comments are essentially saying that not discussing how TLSA records would > >>> interact with such services at all - even if that discussion is simply to say > >>> that those services need to specify how they are going to use TLSA records - > >>> is a mistake. And I have to say that is a pretty compelling argument. > > > >> Could well be. What changes to the text in 1.3 of -20 do you think > >> are needed if any? > > > >> " Note that this document does not cover how to associate > >> certificates with domain names for application protocols that depend > >> on SRV, NAPTR, and similar DNS resource records; it is expected that > >> later updates to this document might cover methods for making those > >> associations." > > > > Well, to be blunt, I think that by trying to avoid solving the problem now > > while not giving up control over future solutions this ends up being > > unacceptable to everyone. > > > > What if a service comes along that uses SRV records and wants to specify how > > TLSA records are used to secure them? According to this text, it can't - the > > clear implication here is that this has to be done by revising the DANE > > specification itself. > > > > And what about existing services like email where it is arguably the case that > > simply using TLSA records to secure the A/AAAA targets MX records is > > sufficient? A very short "secure email transport" specification could > > be writte that refers to the DANE specification, but this would also seem > > to forbid that. > > > > I would much rather see a note that simply refers to future specification work > > being needed, not specifically to a DANE revision being needed. > I had the same concern but then I realized that "later updates to this > document might cover methods for making those associations" could be > construed as referring to add-on documents that would officially update > the DANE-RFC-to-be, not as saying that such changes would need to be > made in the single DANEbis document that would cover all possible uses > of the TLSA RR. That doesn't fix the problem. Anything that says "updates RFC FOO" is effectively the same as a DANEbis spec. What I want is for other specification to be able define how to use TLSA records to secure protocols that use more elaborate DNS record mechanisms *without* having to update DANE. Ned