From coyo@darkdna.net Tue Oct 1 16:00:31 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77AE1F0EE6 for ; Tue, 1 Oct 2013 16:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 2uEK5DqzBEjA for ; Tue, 1 Oct 2013 16:00:21 -0700 (PDT) Received: from ryujin.darkdna.net (ryujin.darkdna.net [69.164.196.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1F21F9C12 for ; Tue, 1 Oct 2013 15:59:59 -0700 (PDT) Received: from localhost (otohime.ddna [172.16.0.13]) by ryujin.darkdna.net (Postfix) with ESMTP id 3cqGCJ3D7pz4w3D for ; Tue, 1 Oct 2013 17:59:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at darkdna.net Received: from ryujin.darkdna.net ([172.16.0.1]) by localhost (otohime.darkdna.net [172.16.0.13]) (amavisd-new, port 10026) with LMTP id a9c6wDE0cdEY for ; Tue, 1 Oct 2013 17:59:54 -0500 (CDT) Received: from smtp-auth.darkdna.net (smtp-auth.darkdna.net [2600:3c00::2:f123]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coyo@darkdna.net) by ryujin.darkdna.net (Postfix) with ESMTPSA id 3c qGCG2Xblz4vyk for ; Tue, 1 Oct 2013 17:59:53 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkdna.net; s=mail; t=1380668394; bh=aLVuymxsgUiI6txp/R1bQ92kGqSI8NqhByin/OKT2lM=; h=Date:From:To:Subject:References:In-Reply-To; b=NZlSNYcNwzrNJc6M5XNkqBK/O2VR4x//XGzjHLWsQMvZEQTjGTVYgEHpIlrty2j28 uBKN3qQFe02XhwhVrDC3PHkwoOD7Wn36APWTwPjsLYH23+BI3DUYJ1HRNEUnvO0J2i I/WAAHoOiPgMJrfcV64ozTQEel9mBeSFqGnDVAbk= Message-ID: <524B53E2.1040205@darkdna.net> Date: Tue, 01 Oct 2013 17:59:46 -0500 From: Alex Maurin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dane@ietf.org References: <7039763.53681380486188849.JavaMail.www@wwinf3715> In-Reply-To: <7039763.53681380486188849.JavaMail.www@wwinf3715> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Bootstrapping IPSec from DNSSSEC/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: Tue, 01 Oct 2013 23:00:32 -0000 On 9/29/2013 3:23 PM, david.lloyd@fsmail.net wrote: > There's not much to it... Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other. The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way. Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails. I think the same. DNSSEC, especially combined with DANE, makes a lot of things begin to look like nails. A nice example, when combined with PGP-DNS and IPsec, would be trivial VoIP encryption. > In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE). I am going to see if I can get those to work. > > > For the other things that were talked about: > > Mobile devices and NATs - It is true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios. If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup) > > Reverse DNS being poorly supported by iSPs - To be honest, this is less of a problem for me as I only have an internal deployment, so I can do that I like (in-addr.arpa is ultimately just a convention, anyone could run a reverse DNS system that actually works properly). Most of my ip addresses are not routable from the public internet anyway. It did lead me to the somewhat more philosophical question of what it means to "own" an ipaddress if I can't associate my public keys with a secure central registry... Where did you get a silly idea like that? Obviously ICANN and the largest carriers own them. If we based IP ownership on SHA-3-512 hashes of PGP certs, however... but I doubt anyone would go along with that. > So I think that the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment. This sort of thinking makes me reconsider the concept of community petnaming. From wjhns1@hardakers.net Thu Oct 3 13:49:22 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBB21F9A90 for ; Thu, 3 Oct 2013 13:49:18 -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 e6OcM-YQSsm4 for ; Thu, 3 Oct 2013 13:49:09 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061621F8C3E for ; Thu, 3 Oct 2013 13:31:28 -0700 (PDT) Received: from localhost (50-1-19-31.dsl.dynamic.sonic.net [50.1.19.31]) by mail.hardakers.net (Postfix) with ESMTPSA id B6ECF23B28; Thu, 3 Oct 2013 13:31:26 -0700 (PDT) From: Wes Hardaker To: Warren Kumari References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> Date: Thu, 03 Oct 2013 13:31:24 -0700 In-Reply-To: (Warren Kumari's message of "Thu, 19 Sep 2013 16:18:39 -0400") Message-ID: <0lpprmumeb.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "dane@ietf.org list" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 20:49:22 -0000 Warren Kumari writes: Looks like a good start and thanks for writing it Olafur! But it's not ready for publication without some cleanup. Too many standard-things are missing, such as acronym expansion and I'd feel guilty passing it to the RFCEditors without us having caught such things. Nits: 1) handle any case use in the input> The expectation is that by using ^^^^^^ ?????? 2) my alternate suggested should descriptions (I like the acronyms themselves): +-------+----------+-------------------------------------+-----------+ | Value | Acronym | Short Description | Reference | +-------+----------+-------------------------------------+-----------+ | 0 | PKIX-TA | PKIX Validated CA Reference | [RFC6698] | | 1 | PKIX-EE | PKIX Validated End-Entity Reference | [RFC6698] | | 2 | DANE-TA | Validation TA Reference | [RFC6698] | | 3 | DANE-EE | Domain-issued certificate Reference | [RFC6698] | | 4-254 | | Unassigned | | | 255 | PrivCert | Reserved for Private Use | [RFC6698] | +-------+----------+-------------------------------------+-------------+ Table 1: TLSA Certificate Usages 3) intro text (1 sentence?) to sections needed and expansion of other acronyms earlier in the document (PKIX, EE, ) 4) ideally space align the section 3 records inserted one space here v _666._tcp.first.example. TLSA PKIX-CA CERT SHA2-512 {blob} _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} 5) security considerations There is definitely something to consider if someone publishes both name records along with number records, and the client only parses number records. What happens with this: _666._tcp.first.example. TLSA 3 1 1 {blob} _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} Something needs to be said for that case; what would an existing implementation do? drop both? take one? Either way, it should be discussed/mentioned. -- Wes Hardaker Parsons From viktor1dane@dukhovni.org Thu Oct 3 14:11:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EBA21F8EDF for ; Thu, 3 Oct 2013 14:11:01 -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 FCqgVfPvl74k for ; Thu, 3 Oct 2013 14:10:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B828621E8092 for ; Thu, 3 Oct 2013 13:58:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0A65F2AB0D1; Thu, 3 Oct 2013 20:58:29 +0000 (UTC) Date: Thu, 3 Oct 2013 20:58:29 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131003205829.GP483@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <0lpprmumeb.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lpprmumeb.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 21:11:02 -0000 On Thu, Oct 03, 2013 at 01:31:24PM -0700, Wes Hardaker wrote: > 5) security considerations > > There is definitely something to consider if someone publishes both > name records along with number records, and the client only parses > number records. What happens with this: > > _666._tcp.first.example. TLSA 3 1 1 {blob} > _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} > > Something needs to be said for that case; what would an existing > implementation do? drop both? take one? Either way, it should be > discussed/mentioned. I'm confused I thought these were just user friendly names... The wire format of the DNS TLSA record is surely unchanged. In which case it is impossible to publish the second form, it is just an input format in documentation (and perhaps source form zone files in supporting DNS servers), but not a wire format. -- Viktor. From warren@kumari.net Thu Oct 3 14:26:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCC211E8110 for ; Thu, 3 Oct 2013 14:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.951 X-Spam-Level: X-Spam-Status: No, score=-100.951 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, USER_IN_WHITELIST=-100, 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 CsgzGIYW1umw for ; Thu, 3 Oct 2013 14:26:09 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A49421E80D2 for ; Thu, 3 Oct 2013 14:15:42 -0700 (PDT) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id 920041B40198; Thu, 3 Oct 2013 17:15:41 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <0lpprmumeb.fsf@wjh.hardakers.net> Date: Thu, 3 Oct 2013 17:15:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <440584CB-0AA2-4736-873A-341CC9772EA4@kumari.net> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <0lpprmumeb.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org list" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 03 Oct 2013 21:26:33 -0000 On Oct 3, 2013, at 4:31 PM, Wes Hardaker wrote: > Warren Kumari writes: >=20 > Looks like a good start and thanks for writing it Olafur! But it's = not > ready for publication without some cleanup. Too many standard-things > are missing, such as acronym expansion and I'd feel guilty passing it > to the RFCEditors without us having caught such things. >=20 > Nits: >=20 > 1) > handle any case use in the input> The expectation is that by using > ^^^^^^ > ?????? >=20 > 2) my alternate suggested should descriptions (I like the acronyms = themselves): >=20 > = +-------+----------+-------------------------------------+-----------+ > | Value | Acronym | Short Description | = Reference | > = +-------+----------+-------------------------------------+-----------+ > | 0 | PKIX-TA | PKIX Validated CA Reference | = [RFC6698] | > | 1 | PKIX-EE | PKIX Validated End-Entity Reference | = [RFC6698] | > | 2 | DANE-TA | Validation TA Reference | = [RFC6698] | > | 3 | DANE-EE | Domain-issued certificate Reference | = [RFC6698] | > | 4-254 | | Unassigned | = | > | 255 | PrivCert | Reserved for Private Use | = [RFC6698] | > = +-------+----------+-------------------------------------+-------------+ >=20 > Table 1: TLSA Certificate Usages >=20 > 3) intro text (1 sentence?) to sections needed and expansion of other > acronyms earlier in the document (PKIX, EE, ) >=20 > 4) ideally space align the section 3 records >=20 > inserted one space here > v > _666._tcp.first.example. TLSA PKIX-CA CERT SHA2-512 {blob} > _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} >=20 > 5) security considerations >=20 > There is definitely something to consider if someone publishes both > name records along with number records, and the client only parses > number records. What happens with this: >=20 > _666._tcp.first.example. TLSA 3 1 1 {blob} > _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} >=20 > Something needs to be said for that case; what would an existing > implementation do? drop both? take one? Either way, it should be > discussed/mentioned. >=20 Um, I'm a little confused (or you are, but probably it is me=85) I'm not quite sure what you are menacing by client here. =20 If it is something like a stub resolver / application, it doesn't really = see either of the above -- it just gets a big bag-o-bits. If you are talking about someone putting this in a zone file, whatever = eats the zone file would continue to do what it does with any other = record. Example: example TYPE16 "foo" example TXT "bar" These are two text records, one with content "foo" and one with content = "bar" If someone does: _666._tcp.first.example. TLSA 3 1 1 {blob} _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} it is the same as if they had entered: _666._tcp.first.example. TLSA 3 1 1 {blob} _666._tcp.first.example. TLSA 2 1 1 {blob} (or, if they have the same usage / selector / selector / match and = {blob} then it is the same as if they had just entered the info twice). If whatever eats the zone file is too old to understand the new enums / = names, then it will continue to do what it does now with unknown = garbage: _666._tcp TLSA COOKIEMONSTER BARNIE FRED 1234=85 wkumari@vimes:~/tmp$ named-checkzone example.com example.com dns_rdata_fromtext: example.com:26: near 'COOKIEMONSTER': not a valid = number example.com: file does not end with newline zone example.com/IN: loading from master file example.com failed: not a = valid number zone example.com/IN: not loaded due to errors. I suspect that I'm missing something / we are talking past each other=85 W > --=20 > Wes Hardaker > Parsons >=20 -- "Let's just say that if complete and utter chaos was lightning, he'd be = the sort to stand on a hilltop in a thunderstorm wearing wet copper = armour and shouting 'All gods are bastards'." -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of = Magic) From wjhns1@hardakers.net Sat Oct 5 07:47:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D11C21F8426 for ; Sat, 5 Oct 2013 07:47:51 -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 8tw+5a8gcjHx for ; Sat, 5 Oct 2013 07:47:50 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFC121F841D for ; Sat, 5 Oct 2013 07:47:50 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:2064:1a0a:ca0e:91c]) by mail.hardakers.net (Postfix) with ESMTPSA id 8A0442C5CA; Sat, 5 Oct 2013 07:47:47 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <0lpprmumeb.fsf@wjh.hardakers.net> <20131003205829.GP483@mournblade.imrryr.org> Date: Sat, 05 Oct 2013 07:47:47 -0700 In-Reply-To: <20131003205829.GP483@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 3 Oct 2013 20:58:29 +0000") Message-ID: <0ly567rcz0.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2013 14:47:51 -0000 Viktor Dukhovni writes: >> _666._tcp.first.example. TLSA 3 1 1 {blob} >> _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} >> >> Something needs to be said for that case; what would an existing >> implementation do? drop both? take one? Either way, it should be >> discussed/mentioned. > > I'm confused I thought these were just user friendly names... The > wire format of the DNS TLSA record is surely unchanged. In which > case it is impossible to publish the second form, it is just an > input format in documentation (and perhaps source form zone files > in supporting DNS servers), but not a wire format. I did actually mean to respond to that and say such, because I realized that shortly afterward. Sorry. (though the zone file is still affected, I don't know of any software that does partial reads of zone files and only takes the records it can understand) -- Wes Hardaker Parsons From wjhns1@hardakers.net Sat Oct 5 07:48:58 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0022F21F8443 for ; Sat, 5 Oct 2013 07:48:57 -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 t5skRqJqicch for ; Sat, 5 Oct 2013 07:48:57 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 918B021F8427 for ; Sat, 5 Oct 2013 07:48:57 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:2064:1a0a:ca0e:91c]) by mail.hardakers.net (Postfix) with ESMTPSA id EA1E52C5CA; Sat, 5 Oct 2013 07:48:56 -0700 (PDT) From: Wes Hardaker To: Warren Kumari References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <0lpprmumeb.fsf@wjh.hardakers.net> <440584CB-0AA2-4736-873A-341CC9772EA4@kumari.net> Date: Sat, 05 Oct 2013 07:48:56 -0700 In-Reply-To: <440584CB-0AA2-4736-873A-341CC9772EA4@kumari.net> (Warren Kumari's message of "Thu, 3 Oct 2013 17:15:40 -0400") Message-ID: <0ltxgvrcx3.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "dane@ietf.org list" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2013 14:48:58 -0000 Warren Kumari writes: > Um, I'm a little confused (or you are, but probably it is me=E2=80=A6) Nope, it was me. See my response to Viktor. --=20 Wes Hardaker Parsons From warren@kumari.net Sat Oct 5 16:35:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEB521F9DB8 for ; Sat, 5 Oct 2013 16:35:40 -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 uMxk-J6AdWUc for ; Sat, 5 Oct 2013 16:35:35 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFAA21F9DA3 for ; Sat, 5 Oct 2013 16:35:35 -0700 (PDT) Received: from dhcp-220-73.meetings.nanog.org (dhcp-220-73.meetings.nanog.org [199.187.220.73]) by vimes.kumari.net (Postfix) with ESMTPSA id 65F781B401D5; Sat, 5 Oct 2013 19:35:34 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: Date: Sat, 5 Oct 2013 16:35:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 05 Oct 2013 23:35:40 -0000 On Sep 19, 2013, at 1:18 PM, Warren Kumari wrote: > Dear DANE WG, >=20 > This starts a Working Group Last Call for = draft-ietf-dane-registry-acronym. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ >=20 > Please review this (really short) draft to see if you think it is = ready for publication > and comments to the list, clearly stating your view. >=20 > This WGLC ends Thu 03-Oct-2013. =85 and we are done! We judge that there is consensus on this document. We appreciate = everyone's feedback and comments, and have asked the author to please = incorporate the suggestions and rev' the doc. We will give folk a few = days to object if their comments were misunderstood, and will then make = it the IESG's problem :-) Thanks again to Olafur for writing this. W >=20 > Thanks, > Warren Kumari > (as DANE WG co-chair) >=20 > On Sep 19, 2013, at 4:12 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >>=20 >> Title : Adding acronyms to simplify DANE conversations >> Author(s) : Olafur Gudmundsson >> Filename : draft-ietf-dane-registry-acronyms-00.txt >> Pages : 5 >> Date : 2013-09-19 >>=20 >> Abstract: >> Experience has show that people get confused using the three numeric >> fields the TLSA record. This document specifies descriptive = acronyms >> for the three numeric fields in the TLSA records. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > -- > For every complex problem, there is a solution that is simple, neat, = and wrong. > -- H. L. Mencken >=20 >=20 >=20 >=20 -- "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 From warren@kumari.net Sat Oct 5 17:01:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486D821F9DD6 for ; Sat, 5 Oct 2013 17:01:07 -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 1W-6JBkW0Z9L for ; Sat, 5 Oct 2013 17:01:02 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601A021F88DD for ; Sat, 5 Oct 2013 17:00:59 -0700 (PDT) Received: from dhcp-220-73.meetings.nanog.org (dhcp-220-73.meetings.nanog.org [199.187.220.73]) by vimes.kumari.net (Postfix) with ESMTPSA id 7FC6E1B40379; Sat, 5 Oct 2013 20:00:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: Date: Sat, 5 Oct 2013 17:00:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71EE5C0A-9955-448A-8FB7-4DCA6BE43EDB@kumari.net> References: To: "dane@ietf.org list" , "draft-dukhovni-dane-ops@tools.ietf.org" X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 Oct 2013 00:01:07 -0000 On Sep 19, 2013, at 4:21 PM, Warren Kumari wrote: > Dear DANE WG, >=20 > Please disregard the previous mail where I accidentally tried to start = a WGLC. Wrong button... >=20 > This starts a Call for Adoption for draft-dukhovni-dane-ops. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-dukhovni-dane-ops/ >=20 > Please review this draft to see if you think it is suitable for = adoption by DANE, > and comments to the list, clearly stating your view. >=20 > Please also indicate if you are willing to contribute text, review, = etc. >=20 > We polled the room in Berlin and there was very good support for = adopting this.=20 > Here is a link to the slides to jog your memory (presented by Wes = Hardaker): = http://www.ietf.org/proceedings/87/slides/slides-87-dane-1.pdf >=20 > This call for adoption ends Thu 03-Oct-2013. =85and we see consensus for adopting this document.=20 Author, could you please resubmit as draft-ietf-dane-ops-00? Also, can you please confirm that you are not personally aware of any = IPR that applies to draft-dukhovni-dane-ops? If so, has this IPR been = disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, = and 5378 for more details.) W >=20 > Thanks, > Warren Kumari > (as DANE WG co-chair) >=20 > P.S: Yes, I did just acknowledge that I am over tired / distracted and = shouldn't be sitting in front of a machine anymore=85 > And yet I'm still poking at things. What could possibly go wrong?!=20 >=20 > -- > Some people are like Slinkies......Not really good for anything but = they still bring a smile to your face when you push them down the = stairs. >=20 >=20 >=20 -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and = he'll be warm for the rest of his life." -- Terry Pratchett From viktor1dane@dukhovni.org Sat Oct 5 20:02:06 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58CD21F999C for ; Sat, 5 Oct 2013 20:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORHwuoKyhHhS for ; Sat, 5 Oct 2013 20:02:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8621F964C for ; Sat, 5 Oct 2013 20:01:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 844E42AB0DC; Sun, 6 Oct 2013 03:01:46 +0000 (UTC) Date: Sun, 6 Oct 2013 03:01:46 +0000 From: Viktor Dukhovni To: Warren Kumari Message-ID: <20131006030146.GY483@mournblade.imrryr.org> References: <71EE5C0A-9955-448A-8FB7-4DCA6BE43EDB@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71EE5C0A-9955-448A-8FB7-4DCA6BE43EDB@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dane@ietf.org Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 Oct 2013 03:02:06 -0000 On Sat, Oct 05, 2013 at 05:00:57PM -0700, Warren Kumari wrote: > Author, could you please resubmit as draft-ietf-dane-ops-00? Thanks, will do. > Also, can you please confirm that you are not personally aware > of any IPR that applies to draft-dukhovni-dane-ops? If so, has > this IPR been disclosed in compliance with IETF IPR rules? (See > RFCs 3979, 4879, 3669, and 5378 for more details.) No IPR that I'm aware of. Not too surprising for an ops document. -- Viktor. From ietf@augustcellars.com Sun Oct 6 14:40:13 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57D11E8141 for ; Sun, 6 Oct 2013 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMJIVJwDYbxE for ; Sun, 6 Oct 2013 14:40:07 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3E11E8137 for ; Sun, 6 Oct 2013 14:40:05 -0700 (PDT) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 7AC092C9E7 for ; Sun, 6 Oct 2013 14:40:05 -0700 (PDT) From: "Jim Schaad" To: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 6 Oct 2013 14:38:50 -0700 Message-ID: <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ39s23NI8MTM4J4gsDf6CIX3S72AH+2eVVmIXMaBA= Content-Language: en-us Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 Oct 2013 21:40:13 -0000 Sorry for being late on getting this in. 1. I do not understand the reasoning behind the 2119 language in the introduction. How would one test this in a protocol fashion? The document states that it does not change DANE in anyway, but there are requirement language statements that can be made? This should be stated in natural language not requirement language. Section 1.1 can them be removed in its entirety. It is expected that DANE parsers in applications and DNS software will adopt these acronyms for parsing and display purposes, however there are no requirements that they do so. 2. In section 2, it states that the references should be both RFC 6698 and this document, however that is not the way that the tables starting in section 2.1 are laid out. They only use RFC 6698 as a reference document. 3 s/input>/input./ 4. I don't think that this phrase "fewer bad TLSA records" is very helpful. What is meant by a bad TLSA record? Is this just ones where the fields were put out of order or does it include ones where the certificate is incorrectly hashed? If the goal is to avoid issues with the certificates and what is extracted, then doing something about what goes into the blob would make sense as well. I would agree that specifying how this would be done is out of scope, but noting it as an issue would be reasonable. 5. As I have stated before, I am not a fan of using DANE-TA for value 2. To me this loses the fact that there will be PKIX processing that occurs with this section. I would strongly recommend that this become PKIX-TA. The use of PKIX-TA for the value of 0 never made any sense since there is not trust anchor decision that is associated with the certificate in this record. The only two records currently that have a trust anchor, as oppose to a constraint, component are 2 and 3. 6. The note component at the end of section 2.1 should be deleted. 7. In section 3, the descriptive text and the example records do not match in very significant ways. Jim From marka@isc.org Sun Oct 6 15:18:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A66721E80CB for ; Sun, 6 Oct 2013 15:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE7fkciuGiY0 for ; Sun, 6 Oct 2013 15:18:25 -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 5341521E80D2 for ; Sun, 6 Oct 2013 15:18:24 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 54C57C941E; Sun, 6 Oct 2013 22:18:10 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381097903; bh=e2we0reNgbjWDwRjlSBKKezrYhi5x9l8MTmNvvLbBqk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Xx4LWOKq7SzGUIzNCdVjnEAX6ixnQCGDtiPdumxhGZlgXTPMmcEfLJ/8T9wHPlsvP nRh8GXNTy3YtbMYPC41CureHpA5Z/dplonGeyk2gRWaUUcxH/RjiqSm1+gX7SbJSS4 Wh6UbRFnus/GQMgrtH3s2RpWs0knZ4cA/rNlo/Ik= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sun, 6 Oct 2013 22:18:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 51C37160470; Sun, 6 Oct 2013 22:21:43 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 2332516043C; Sun, 6 Oct 2013 22:21:43 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DF85F7DE9A4; Sun, 6 Oct 2013 16:45:59 +1100 (EST) To: Wes Hardaker From: Mark Andrews References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <0lpprmumeb.fsf@wjh.hardakers.net> <20131003205829.GP483@mournblade.imrryr.org> <0ly567rcz0.fsf@wjh.hardakers.net> In-reply-to: Your message of "Sat, 05 Oct 2013 07:47:47 -0700." <0ly567rcz0.fsf@wjh.hardakers.net> Date: Sun, 06 Oct 2013 16:45:59 +1100 Message-Id: <20131006054559.DF85F7DE9A4@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 06 Oct 2013 22:18:30 -0000 In message <0ly567rcz0.fsf@wjh.hardakers.net>, Wes Hardaker writes: > Viktor Dukhovni writes: > > >> _666._tcp.first.example. TLSA 3 1 1 {blob} > >> _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} > >> > >> Something needs to be said for that case; what would an existing > >> implementation do? drop both? take one? Either way, it should be > >> discussed/mentioned. > > > > I'm confused I thought these were just user friendly names... The > > wire format of the DNS TLSA record is surely unchanged. In which > > case it is impossible to publish the second form, it is just an > > input format in documentation (and perhaps source form zone files > > in supporting DNS servers), but not a wire format. > > I did actually mean to respond to that and say such, because I realized > that shortly afterward. Sorry. > > (though the zone file is still affected, I don't know of any software > that does partial reads of zone files and only takes the records it can under > stand) Any server that does a partial read is not rfc compliant. > -- > Wes Hardaker > Parsons > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From viktor1dane@dukhovni.org Sun Oct 6 15:47:54 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288EE21E80E4 for ; Sun, 6 Oct 2013 15:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9ZPDs9ObdwL5 for ; Sun, 6 Oct 2013 15:47:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B38D421E80E1 for ; Sun, 6 Oct 2013 15:47:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6C39C2AAD93; Sun, 6 Oct 2013 22:47:42 +0000 (UTC) Date: Sun, 6 Oct 2013 22:47:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131006224742.GA483@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 22:47:54 -0000 On Sun, Oct 06, 2013 at 02:38:50PM -0700, Jim Schaad wrote: > 5. As I have stated before, I am not a fan of using DANE-TA for value 2. > To me this loses the fact that there will be PKIX processing that occurs > with this section. I would strongly recommend that this become PKIX-TA. I think that would confuse almost everyone. The "PKI" part of PKIX carries inappropriate in this context mental baggage. Yes, any trust-anchor implies validating certificate chains, performing name on the leaf, ... Thus the mechanics of validating usage 2 associations are very similar to the mechanics of doing the same with an a-priori configured public CA trust anchor. Alas, when one hears PKIX, the associated mental baggage includes the full panoply of public CAs and not does evoke the decentralized DANE model. Thus "TA" is IMHO already sufficient to imply all the relevant technical features, without evoking unwanted mental associations. > The use of PKIX-TA for the value of 0 never made any sense since there is > not trust anchor decision that is associated with the certificate in this > record. The only two records currently that have a trust anchor, as oppose > to a constraint, component are 2 and 3. Here, I've already agreed with you upthread, I think PKIX-CA is better here (Paul Hoffman disagreed, but frankly I am not sure how his response applies to the question at hand). -- Viktor. From kent@bbn.com Mon Oct 7 06:42:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C161821E818D for ; Mon, 7 Oct 2013 06:42:57 -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 eyOTSzQ6QVdd for ; Mon, 7 Oct 2013 06:42:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB621E80AB for ; Mon, 7 Oct 2013 06:42:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40844 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VTB5G-000GOy-B9; Mon, 07 Oct 2013 09:42:50 -0400 Message-ID: <5252BA5A.2040209@bbn.com> Date: Mon, 07 Oct 2013 09:42:50 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dane@ietf.org References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <20131006224742.GA483@mournblade.imrryr.org> In-Reply-To: <20131006224742.GA483@mournblade.imrryr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 13:42:57 -0000 Viktor, > On Sun, Oct 06, 2013 at 02:38:50PM -0700, Jim Schaad wrote: > >> 5. As I have stated before, I am not a fan of using DANE-TA for value 2. >> To me this loses the fact that there will be PKIX processing that occurs >> with this section. I would strongly recommend that this become PKIX-TA. > I think that would confuse almost everyone. The "PKI" part of PKIX > carries inappropriate in this context mental baggage. > > Yes, any trust-anchor implies validating certificate chains, > performing name on the leaf, ... Thus the mechanics of validating > usage 2 associations are very similar to the mechanics of doing > the same with an a-priori configured public CA trust anchor. Alas, > when one hears PKIX, the associated mental baggage includes the > full panoply of public CAs and not does evoke the decentralized > DANE model. no for everyone :-). PKIX RFCs do not address the public TA/CA model in browsers to which you refer. So the mental baggage to which you refer is an example of an inappropriate-sized carry on (to run that metaphor into the ground). Steve From viktor1dane@dukhovni.org Mon Oct 7 07:52:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB5E11E80EC for ; Mon, 7 Oct 2013 07:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 s+qZpP3GkMHy for ; Mon, 7 Oct 2013 07:52:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 064AE21F9B21 for ; Mon, 7 Oct 2013 07:52:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EB62C2AAD93; Mon, 7 Oct 2013 14:52:33 +0000 (UTC) Date: Mon, 7 Oct 2013 14:52:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131007145233.GE483@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <20131006224742.GA483@mournblade.imrryr.org> <5252BA5A.2040209@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5252BA5A.2040209@bbn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:52:45 -0000 On Mon, Oct 07, 2013 at 09:42:50AM -0400, Stephen Kent wrote: > Viktor, > >>To me this loses the fact that there will be PKIX processing that occurs > >>with this section. I would strongly recommend that this become PKIX-TA. > > > >I think that would confuse almost everyone. The "PKI" part of PKIX > >carries inappropriate in this context mental baggage. > > So the mental baggage to which you refer is an example of an > inappropriate-sized carry on (to run that metaphor into the ground). Yes, but I still think many will find PKIX-TA confusing as a description of usage 2. It is easier to roughly divide the usages into - 0/1 (PKIX, that is public CA verified, DNSSEC constrained) and - 2/3 (DANE, that is DNSSEC verified) though I freely admit that indeed the PKIX specification is silent on the origin of the TA, and technically quite suitable to usage 2. Indeed many of the implementation flaws I pointed out some months back this spring, (in then extant DANE implementations), were related to failure to properly verify usage 2 chains (it was a common error to simply check that the peer's chain contained the associated TA certificate without checking that the TA actually authenticates a valid chain leading to the EE certificate). So perhaps the bottom line is that no matter which acronyms we adopt, confusion will reign until we have ample implementation guidance (and even then of course some will remain perpetually confused). I originally had implementation notes in the DANE ops draft, but decided to focus just on operational issues, in the end. Perhaps there should be a separate document with guidance and warnings for implementation developers. -- Viktor. From ietf@augustcellars.com Mon Oct 7 08:21:31 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016CC21E80A1 for ; Mon, 7 Oct 2013 08:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 QkkLMzzGDt70 for ; Mon, 7 Oct 2013 08:21:26 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4150A11E8100 for ; Mon, 7 Oct 2013 08:21:26 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (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 EC2F238F22 for ; Mon, 7 Oct 2013 08:21:25 -0700 (PDT) From: "Jim Schaad" To: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <20131006224742.GA483@mournblade.imrryr.org> In-Reply-To: <20131006224742.GA483@mournblade.imrryr.org> Date: Mon, 7 Oct 2013 08:20:10 -0700 Message-ID: <02e201cec370$b6d9e5d0$248db170$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ39s23NI8MTM4J4gsDf6CIX3S72AH+2eVVAfb+EFAB9eBQg5hnlTgQ Content-Language: en-us Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 15:21:31 -0000 So, while I have sure that I have the details partly wrong, consider the case of people doing a PGP certificate set here. They could/would use DANE-EE in the event that the key ring was self-signed. This is the key to be matched and trusted. However they would not use DANE-TA in the event that a key ring that was self-signed was to be used to validate a second key wrong. In this case there is a root of trust (i.e. a TA) and then a second level signed PGP key which is used in the TLS session to do the appropriate things. This allows for the TLS key to be rotated more frequently. But there is no PKIX validation in this case and thus the use of DANE-TA, which seems logical, is wrong. Jim > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Viktor Dukhovni > Sent: Sunday, October 06, 2013 3:48 PM > To: dane@ietf.org > Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym > > On Sun, Oct 06, 2013 at 02:38:50PM -0700, Jim Schaad wrote: > > > 5. As I have stated before, I am not a fan of using DANE-TA for value 2. > > To me this loses the fact that there will be PKIX processing that > > occurs with this section. I would strongly recommend that this become > PKIX-TA. > > I think that would confuse almost everyone. The "PKI" part of PKIX carries > inappropriate in this context mental baggage. > > Yes, any trust-anchor implies validating certificate chains, performing name > on the leaf, ... Thus the mechanics of validating usage 2 associations are > very similar to the mechanics of doing the same with an a-priori configured > public CA trust anchor. Alas, when one hears PKIX, the associated mental > baggage includes the full panoply of public CAs and not does evoke the > decentralized DANE model. > > Thus "TA" is IMHO already sufficient to imply all the relevant technical > features, without evoking unwanted mental associations. > > > The use of PKIX-TA for the value of 0 never made any sense since there > > is not trust anchor decision that is associated with the certificate > > in this record. The only two records currently that have a trust > > anchor, as oppose to a constraint, component are 2 and 3. > > Here, I've already agreed with you upthread, I think PKIX-CA is better here > (Paul Hoffman disagreed, but frankly I am not sure how his response applies > to the question at hand). > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From viktor1dane@dukhovni.org Mon Oct 7 08:57:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCD121E81CC for ; Mon, 7 Oct 2013 08:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKzdPIW-KPAo for ; Mon, 7 Oct 2013 08:57:19 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC921E81DB for ; Mon, 7 Oct 2013 08:56:48 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A9E12AAF85; Mon, 7 Oct 2013 15:56:42 +0000 (UTC) Date: Mon, 7 Oct 2013 15:56:42 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131007155642.GH483@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <20131006224742.GA483@mournblade.imrryr.org> <02e201cec370$b6d9e5d0$248db170$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02e201cec370$b6d9e5d0$248db170$@augustcellars.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:57:25 -0000 On Mon, Oct 07, 2013 at 08:20:10AM -0700, Jim Schaad wrote: > However they would not use DANE-TA in the event that a key ring that was > self-signed was to be used to validate a second key wrong. [ Typo for "ring" as "rong" auto-corrected to "wrong". "Damn you auto-connect!" Oops, sorry: "Damn you auto-corrupt!" Oh, never mind... ] > In this case > there is a root of trust (i.e. a TA) and then a second level signed PGP key > which is used in the TLS session to do the appropriate things. This allows > for the TLS key to be rotated more frequently. But there is no PKIX > validation in this case and thus the use of DANE-TA, which seems logical, is > wrong. The DANE usages defined thus far are for TLS with X.509v3 certificates. These may be self-signed, issued by a private self-signed TA, or issued by a public CA. I don't see where hypothetical PGP certificates fit in. -- Viktor. From ietf@augustcellars.com Mon Oct 7 13:42:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8F11E8163 for ; Mon, 7 Oct 2013 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Epu9trousre for ; Mon, 7 Oct 2013 13:42:27 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id F046D11E8136 for ; Mon, 7 Oct 2013 13:42:16 -0700 (PDT) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 B9BDA2CA24 for ; Mon, 7 Oct 2013 13:42:15 -0700 (PDT) From: "Jim Schaad" To: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> <20131006224742.GA483@mournblade.imrryr.org> <02e201cec370$b6d9e5d0$248db170$@augustcellars.com> <20131007155642.GH483@mournblade.imrryr.org> In-Reply-To: <20131007155642.GH483@mournblade.imrryr.org> Date: Mon, 7 Oct 2013 13:41:00 -0700 Message-ID: <033d01cec39d$88c1d810$9a458830$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ39s23NI8MTM4J4gsDf6CIX3S72AH+2eVVAfb+EFAB9eBQgwH1o+FvAXKczpKYTK1aAA== Content-Language: en-us Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 07 Oct 2013 20:42:34 -0000 > -----Original Message----- > From: dane-bounces@ietf.org [mailto:dane-bounces@ietf.org] On Behalf Of > Viktor Dukhovni > Sent: Monday, October 07, 2013 8:57 AM > To: dane@ietf.org > Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym > > On Mon, Oct 07, 2013 at 08:20:10AM -0700, Jim Schaad wrote: > > > However they would not use DANE-TA in the event that a key ring that > > was self-signed was to be used to validate a second key wrong. > > [ Typo for "ring" as "rong" auto-corrected to "wrong". > > "Damn you auto-connect!" > Oops, sorry: "Damn you auto-corrupt!" > Oh, never mind... ] > > > In this case > > there is a root of trust (i.e. a TA) and then a second level signed > > PGP key which is used in the TLS session to do the appropriate things. > > This allows for the TLS key to be rotated more frequently. But there > > is no PKIX validation in this case and thus the use of DANE-TA, which > > seems logical, is wrong. > > The DANE usages defined thus far are for TLS with X.509v3 certificates. > These may be self-signed, issued by a private self-signed TA, or issued by a > public CA. > > I don't see where hypothetical PGP certificates fit in. It was an attempt to point out that trust anchors could be done for more than just PKIX certificates, but it apparently did not succeed. The issue is that if you have a PGP trust anchor and a PKIX trust anchor they should probably not have the same descriptive name (and hence value) since the side semantics are not the same. Jim > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From wjhns1@hardakers.net Tue Oct 8 07:45:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5551821E8097 for ; Tue, 8 Oct 2013 07:45:55 -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 DMX9DtYObaA2 for ; Tue, 8 Oct 2013 07:45:55 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF87921E80A7 for ; Tue, 8 Oct 2013 07:45:53 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:e890:9708:3d45:a29d]) by mail.hardakers.net (Postfix) with ESMTPSA id 6F7652CD6D; Tue, 8 Oct 2013 07:45:51 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <71EE5C0A-9955-448A-8FB7-4DCA6BE43EDB@kumari.net> <20131006030146.GY483@mournblade.imrryr.org> Date: Tue, 08 Oct 2013 07:45:51 -0700 In-Reply-To: <20131006030146.GY483@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 6 Oct 2013 03:01:46 +0000") Message-ID: <0lmwmjn7mo.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: dane@ietf.org Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 08 Oct 2013 14:45:55 -0000 Viktor Dukhovni writes: >> Author, could you please resubmit as draft-ietf-dane-ops-00? > > Thanks, will do. Just submitted, FYI. >> Also, can you please confirm that you are not personally aware >> of any IPR that applies to draft-dukhovni-dane-ops? If so, has >> this IPR been disclosed in compliance with IETF IPR rules? (See >> RFCs 3979, 4879, 3669, and 5378 for more details.) > > No IPR that I'm aware of. Not too surprising for an ops document. None here either. -- Wes Hardaker Parsons From internet-drafts@ietf.org Tue Oct 8 08:37:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9903F21E81C6; Tue, 8 Oct 2013 08:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21vHiPBqO2Mn; Tue, 8 Oct 2013 08:37:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2300E21E81ED; Tue, 8 Oct 2013 08:37:32 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008153731.25649.54783.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 08:37:31 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-00.txt 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: Tue, 08 Oct 2013 15:37:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : DANE TLSA implementation and operational guidance Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-00.txt Pages : 18 Date : 2013-10-08 Abstract: This memo provides operational guidance to server operators to help ensure that clients will be able to authenticate a server's certificate chain via published TLSA records. Guidance is also provided to clients for selecting reliable TLSA record parameters to use for server authentication. Finally, guidance is given to protocol designers who wish to make use of TLSA records to secure protocols using a TLS and TLSA combination. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-ops-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Oct 8 13:15:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0B21F9BAB; Tue, 8 Oct 2013 13:15:05 -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.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG0fI5h321tr; Tue, 8 Oct 2013 13:15:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8452421F9BC2; Tue, 8 Oct 2013 13:15:02 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131008201502.28645.13763.idtracker@ietfa.amsl.com> Date: Tue, 08 Oct 2013 13:15:02 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-00.txt 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: Tue, 08 Oct 2013 20:15:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-00.txt Pages : 17 Date : 2013-10-08 Abstract: This memo describes a protocol for opportunistic TLS security based on the DANE TLSA DNS record. The protocol is downgrade resistant when the SMTP client supports DANE TLSA and the server domain publishes TLSA records for its MX hosts. This enables an incremental transition of the Internet email backbone (MTA to MTA SMTP traffic) to TLS encrypted and authenticated delivery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From warren@kumari.net Tue Oct 8 13:15:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866BB21F9BD0 for ; Tue, 8 Oct 2013 13:15: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 MRnGgMC-9DYz for ; Tue, 8 Oct 2013 13:15:03 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751D621F9B4B for ; Tue, 8 Oct 2013 13:14:58 -0700 (PDT) Received: from dhcp-220-73.meetings.nanog.org (dhcp-220-73.meetings.nanog.org [199.187.220.73]) by vimes.kumari.net (Postfix) with ESMTPSA id B12811B40365; Tue, 8 Oct 2013 16:14:56 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Oct 2013 13:14:56 -0700 Message-Id: To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dane] Adopting draft-ietf-dane-smtp-with-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: Tue, 08 Oct 2013 20:15:09 -0000 Dear DANE, During the Berlin meeting it was proposed that draft-ietf-dane-smtp be = merged with draft-dukhovni-smtp-opportunistic-tls. There was very strong = support for doing so. It appears that the author of draft-ietf-dane-smtp does not have = sufficient free cycles to continue working on this, and so we will be = adopting the other draft. We thank everyone involved for all of their hard work on this, = especially the authors. W -- Some people are like Slinkies......Not really good for anything but they = still bring a smile to your face when you push them down the stairs. From ogud@ogud.com Wed Oct 16 13:29:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0507D11E82E7 for ; Wed, 16 Oct 2013 13:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, 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 CG9UTSzAE0J4 for ; Wed, 16 Oct 2013 13:29:42 -0700 (PDT) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2B11E82D7 for ; Wed, 16 Oct 2013 13:29:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5B9E550116; Wed, 16 Oct 2013 16:29:42 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1C75B500FF; Wed, 16 Oct 2013 16:29:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: Date: Wed, 16 Oct 2013 16:29:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> To: James Cloos X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org list" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 20:29:47 -0000 James,=20 Thanks for the edits I applied them,=20 PKIX-CA vs TA I'm not sure what the consensus of the WG was and ask = chairs to rule on that.=20 Olafur On Sep 19, 2013, at 6:00 PM, James Cloos wrote: > PKIX-TA looks better than PKIX-CA; CA makes it look like it has to be = an > association to a root cert. >=20 > It would be nice to have a better short description for type 3 than > Domain-issued certificate, notwithstanding the existance of that = string > in rfc 6698. DANE isn't about issuing certs, but rather about > establishing trust paths to them. But I cannot come up with an > alternative....=20 >=20 > Nits: >=20 > The paragraph: "It is expected that DANE parser's in applications and > DNS software MAY adopt parsing the acronyms for each field, installed > base MAY NOT get updated." could use better grammar. Perhaps: >=20 > s/each field, installed base/each field, but the installed base/ >=20 > And perhaps /MAY NOT/may not/. Unlike the first MAY, the may not = isn't > really a 2119. (The Nits link agrees.) >=20 > In the xml, I'd do: >=20 > s(CA constraint)(CA constraint) >=20 > it should look better in the output. >=20 > -JimC > --=20 > James Cloos OpenPGP: 1024D/ED7DAEA6 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ogud@ogud.com Wed Oct 16 13:30:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46611E82DD for ; Wed, 16 Oct 2013 13:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 5GcIE-NFbq3e for ; Wed, 16 Oct 2013 13:29:55 -0700 (PDT) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id D4BD111E820B for ; Wed, 16 Oct 2013 13:29:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 88338500C2; Wed, 16 Oct 2013 16:29:55 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 38FD45010D; Wed, 16 Oct 2013 16:29:55 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <0lpprmumeb.fsf@wjh.hardakers.net> Date: Wed, 16 Oct 2013 16:29:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A37555D-1C64-4FB5-8AD6-98F3DA2528F5@ogud.com> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <0lpprmumeb.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org list" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 20:30:00 -0000 On Oct 3, 2013, at 4:31 PM, Wes Hardaker wrote: > Warren Kumari writes: >=20 > Looks like a good start and thanks for writing it Olafur! But it's = not > ready for publication without some cleanup. Too many standard-things > are missing, such as acronym expansion and I'd feel guilty passing it > to the RFCEditors without us having caught such things. >=20 > Nits: >=20 > 1) > handle any case use in the input> The expectation is that by using > ^^^^^^ > ?????? Fixed >=20 > 2) my alternate suggested should descriptions (I like the acronyms = themselves): >=20 > = +-------+----------+-------------------------------------+-----------+ > | Value | Acronym | Short Description | = Reference | > = +-------+----------+-------------------------------------+-----------+ > | 0 | PKIX-TA | PKIX Validated CA Reference | = [RFC6698] | > | 1 | PKIX-EE | PKIX Validated End-Entity Reference | = [RFC6698] | > | 2 | DANE-TA | Validation TA Reference | = [RFC6698] | > | 3 | DANE-EE | Domain-issued certificate Reference | = [RFC6698] | > | 4-254 | | Unassigned | = | > | 255 | PrivCert | Reserved for Private Use | = [RFC6698] | > = +-------+----------+-------------------------------------+-------------+ >=20 I ask chairs to rule if your rewording has traction=20 I like it but there were no voices of support and this changes the registry more than the one column that I set out to add.=20 > Table 1: TLSA Certificate Usages >=20 > 3) intro text (1 sentence?) to sections needed and expansion of other > acronyms earlier in the document (PKIX, EE, ) >=20 No=20 > 4) ideally space align the section 3 records >=20 > inserted one space here > v > _666._tcp.first.example. TLSA PKIX-CA CERT SHA2-512 {blob} > _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} fixed.=20 >=20 > 5) security considerations >=20 > There is definitely something to consider if someone publishes both > name records along with number records, and the client only parses > number records. What happens with this: >=20 > _666._tcp.first.example. TLSA 3 1 1 {blob} > _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} This is impossible as the DNS wire fomat is numbers.=20 >=20 > Something needs to be said for that case; what would an existing > implementation do? drop both? take one? Either way, it should be > discussed/mentioned. >=20 > --=20 > Wes Hardaker > Parsons > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ogud@ogud.com Wed Oct 16 13:41:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6541921F9C9B for ; Wed, 16 Oct 2013 13:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, 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 iRsgKYVwHUDw for ; Wed, 16 Oct 2013 13:41:20 -0700 (PDT) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6A21F9C6B for ; Wed, 16 Oct 2013 13:41:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id AA3AD500C2; Wed, 16 Oct 2013 16:41:16 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8005F50116; Wed, 16 Oct 2013 16:41:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> Date: Wed, 16 Oct 2013 16:41:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <309DDDEA-6A01-4A68-AFCE-9B6A1B2CE874@ogud.com> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <024c01cec2dc$72b596e0$5820c4a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1510) Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 16 Oct 2013 20:41:24 -0000 On Oct 6, 2013, at 5:38 PM, Jim Schaad wrote: > Sorry for being late on getting this in. >=20 > 1. I do not understand the reasoning behind the 2119 language in the > introduction. How would one test this in a protocol fashion? The = document > states that it does not change DANE in anyway, but there are = requirement > language statements that can be made? This should be stated in = natural > language not requirement language. Section 1.1 can them be removed in = its > entirety. >=20 There two instances of MAY and MAY NOT I reworded them and removed section 1.1 > It is expected that DANE parsers in applications and DNS software will = adopt > these acronyms for parsing and display purposes, however there are no > requirements that they do so. >=20 > 2. In section 2, it states that the references should be both RFC = 6698 and > this document, however that is not the way that the tables starting in > section 2.1 are laid out. They only use RFC 6698 as a reference = document. >=20 There are two different set of references=20 a) the references for the Registry itself=20 b) the references for each allocation in the registry.=20 This document only applies to the first one=20 and that is what I said.=20 > 3 s/input>/input./ >=20 Fixed > 4. I don't think that this phrase "fewer bad TLSA records" is very = helpful. > What is meant by a bad TLSA record? Is this just ones where the = fields were > put out of order or does it include ones where the certificate is > incorrectly hashed? If the goal is to avoid issues with the = certificates > and what is extracted, then doing something about what goes into the = blob > would make sense as well. I would agree that specifying how this = would be > done is out of scope, but noting it as an issue would be reasonable. >=20 I agree and removed that sentence.=20 > 5. As I have stated before, I am not a fan of using DANE-TA for value = 2. > To me this loses the fact that there will be PKIX processing that = occurs > with this section. I would strongly recommend that this become = PKIX-TA. > The use of PKIX-TA for the value of 0 never made any sense since there = is > not trust anchor decision that is associated with the certificate in = this > record. The only two records currently that have a trust anchor, as = oppose > to a constraint, component are 2 and 3.=20 I leave a call on that to the wise chairs :-)=20 I do not care personally=20 >=20 > 6. The note component at the end of section 2.1 should be deleted. Gone >=20 > 7. In section 3, the descriptive text and the example records do not = match > in very significant ways. >=20 I must be dense, there is not supposed to be any correlation between the two paragraphs in section 3 they are supposed to be separate examples.=20= thanks for good comments.=20 Olafur > Jim >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From internet-drafts@ietf.org Fri Oct 18 11:57:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAE121F9DF6; Fri, 18 Oct 2013 11:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSK-SC6+KdDb; Fri, 18 Oct 2013 11:57:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6431211E8116; Fri, 18 Oct 2013 11:57:53 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018185753.4122.27929.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 11:57:53 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-registry-acronyms-01.txt 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, 18 Oct 2013 18:57:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Adding acronyms to simplify DANE conversations Author(s) : Olafur Gudmundsson Filename : draft-ietf-dane-registry-acronyms-01.txt Pages : 5 Date : 2013-10-18 Abstract: Experience has show that people get confused using the three numeric fields the TLSA record. This document specifies descriptive acronyms for the three numeric fields in the TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-registry-acronyms-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ogud@ogud.com Fri Oct 18 12:01:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E2611E8330 for ; Fri, 18 Oct 2013 12:00:58 -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 kq3GveLdGVOR for ; Fri, 18 Oct 2013 12:00:51 -0700 (PDT) Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF6311E82C5 for ; Fri, 18 Oct 2013 12:00:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 3BCA01A0615 for ; Fri, 18 Oct 2013 15:00:36 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id E738A1A0643 for ; Fri, 18 Oct 2013 15:00:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20131018185753.4122.27929.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 15:00:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15675903-239C-46AE-B3C9-90E8775F97D5@ogud.com> References: <20131018185753.4122.27929.idtracker@ietfa.amsl.com> To: " list" X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:01:02 -0000 This version should address all the comments received and accepted = during the WGLC.=20 There is one issue that is uncertain in my mind i.e.=20 PKIX-CA vs PKIX-TA I kept the draft using PKIX-CA=20 pending chairs or WG telling me otherwise.=20 Olafur On Oct 18, 2013, at 2:57 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >=20 > Title : Adding acronyms to simplify DANE conversations > Author(s) : Olafur Gudmundsson > Filename : draft-ietf-dane-registry-acronyms-01.txt > Pages : 5 > Date : 2013-10-18 >=20 > Abstract: > Experience has show that people get confused using the three numeric > fields the TLSA record. This document specifies descriptive = acronyms > for the three numeric fields in the TLSA records. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-registry-acronyms-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From pieter.lexis@os3.nl Fri Oct 18 13:09:08 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DB611E817B for ; Fri, 18 Oct 2013 13:09:07 -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 nyiiUClb87tF for ; Fri, 18 Oct 2013 13:09:07 -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 36D8311E81F2 for ; Fri, 18 Oct 2013 13:09:05 -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 1E60717B97D for ; Fri, 18 Oct 2013 22:09:04 +0200 (CEST) Received: from [10.116.31.83] (unknown [188.207.64.18]) by smtp.os3.nl (Postfix) with ESMTPSA id E2F9517B657 for ; Fri, 18 Oct 2013 22:08:58 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <15675903-239C-46AE-B3C9-90E8775F97D5@ogud.com> References: <20131018185753.4122.27929.idtracker@ietfa.amsl.com> <15675903-239C-46AE-B3C9-90E8775F97D5@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Pieter Lexis Date: Fri, 18 Oct 2013 22:08:48 +0200 To: " list" Message-ID: Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:09:08 -0000 Hi, Small nit in section 1: "column with acronym for each" => "column with an acronym for each" -- Pieter Olafur Gudmundsson wrote: >This version should address all the comments received and accepted >during the WGLC. >There is one issue that is uncertain in my mind i.e. > PKIX-CA vs PKIX-TA > I kept the draft using PKIX-CA >pending chairs or WG telling me otherwise. > > Olafur > > >On Oct 18, 2013, at 2:57 PM, internet-drafts@ietf.org wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> This draft is a work item of the DNS-based Authentication of Named >Entities Working Group of the IETF. >> >> Title : Adding acronyms to simplify DANE conversations >> Author(s) : Olafur Gudmundsson >> Filename : draft-ietf-dane-registry-acronyms-01.txt >> Pages : 5 >> Date : 2013-10-18 >> >> Abstract: >> Experience has show that people get confused using the three >numeric >> fields the TLSA record. This document specifies descriptive >acronyms >> for the three numeric fields in the TLSA records. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-registry-acronyms-01 >> >> >> Please note that it may take a couple of minutes from the time of >submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From internet-drafts@ietf.org Sun Oct 20 21:48:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18D11E84A8; Sun, 20 Oct 2013 21:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apBIA9h+pOnF; Sun, 20 Oct 2013 21:48:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB90711E84A9; Sun, 20 Oct 2013 21:48:36 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021044836.8679.59953.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:48:36 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-01.txt 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, 21 Oct 2013 04:48:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-01.txt Pages : 19 Date : 2013-10-20 Abstract: This memo describes a protocol for opportunistic TLS security based on the DANE TLSA DNS record. The protocol is downgrade resistant when the SMTP client supports DANE TLSA and the server domain publishes TLSA records for its MX hosts. This enables an incremental transition of the Internet email backbone (MTA to MTA SMTP traffic) to TLS encrypted and authenticated delivery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smtp-with-dane-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 15:19:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756D511E877B; Mon, 21 Oct 2013 15:19:24 -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.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X2y7GKDDlaj; Mon, 21 Oct 2013 15:19:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CD811E878A; Mon, 21 Oct 2013 15:19:12 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021221911.32548.96865.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:19:11 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-01.txt 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, 21 Oct 2013 22:19:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : DANE TLSA implementation and operational guidance Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-01.txt Pages : 19 Date : 2013-10-21 Abstract: This memo provides operational guidance to server operators to help ensure that clients will be able to authenticate a server's certificate chain via published TLSA records. Guidance is also provided to clients for selecting reliable TLSA record parameters and how to use them for server authentication. Finally, guidance is given to protocol designers who wish to make use of TLSA records when securing protocols using a TLS and TLSA combination. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-ops-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-ops-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 15:19:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F2C11E8783; Mon, 21 Oct 2013 15:19:43 -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.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3YLjeXBHQBm; Mon, 21 Oct 2013 15:19:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBDE11E8793; Mon, 21 Oct 2013 15:19:32 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021221932.32482.68614.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:19:32 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-02.txt 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, 21 Oct 2013 22:19:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Author(s) : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-02.txt Pages : 18 Date : 2013-10-21 Abstract: This memo describes a protocol for opportunistic TLS security based on the DANE TLSA DNS record. The protocol is downgrade resistant when the SMTP client supports DANE TLSA and the server domain publishes TLSA records for its MX hosts. This enables an incremental transition of the Internet email backbone (MTA to MTA SMTP traffic) to TLS encrypted and authenticated delivery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smtp-with-dane-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scottr.nist@gmail.com Tue Oct 22 10:57:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5B11E81C1 for ; Tue, 22 Oct 2013 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYPI4S7eilgh for ; Tue, 22 Oct 2013 10:56:46 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 349F611E8108 for ; Tue, 22 Oct 2013 10:56:37 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Oct 2013 13:56:25 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 22 Oct 2013 13:56:35 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id r9MHuPE7006013 for ; Tue, 22 Oct 2013 13:56:25 -0400 From: Scott Rose Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Oct 2013 13:56:25 -0400 Message-ID: To: MIME-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-NIST-MailScanner-Information: Subject: [dane] Proposed DMARC component to signal SMIME policy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 22 Oct 2013 17:57:03 -0000 A few of us here at NIST have a proposal to float by the group: We submitted an Internet-Draft on using a new DNS RRType to signal that = all email coming from the domain will be signed (proposed type is called = SMIMELOCK). So that when a client receives an email that lacks a SMIME = signature from a domain with the SMIMELOCK RR, it could be marked as = suspect. The draft is at: https://datatracker.ietf.org/doc/draft-srose-smimelock/ However, we got to thinking that it might be better to include this as = part of the DMARC RDATA instead of a new RRType. Basically, the new = component could be: dmarc-smime =3D "smime" *WSP "=3D" *WSP ("all" / "partial" / "none") Where: "all" means all email originating from this domain contains a SMIME = signature "partial" means some email originating from this domain contain a SMIME = signature (used for incremental deployment as an example). "none" means this domain does not issue SMIME certs. Though the draft only has "all", we consider having other options for = the SMIMELOCK value might be useful. It's something that the community = should decide. As we see it, the pro of having it in the DMARC RR is = that it reduces the number of queries a client needs to make, and gets = it deployed quicker (no need to wait for DNS implementations to be able = to understand the new RRType). The downside of this is (we admit) that = is it "mission creep" of DMARC to now look at the contents of the = message (at least for a SMIME sig) instead of just the header. =20 So a question to the group: Is there enough interest to continue this = idea and start a more formal write-up? Or, as stated above, the DMARC = RR is not the quite right place for a domain to make this sort of = statement on SMIME use? Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From viktor1dane@dukhovni.org Tue Oct 22 11:21:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B69F21F9A6A for ; Tue, 22 Oct 2013 11:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 g6y+vLS0dPw1 for ; Tue, 22 Oct 2013 11:21:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 418EF21F9D0F for ; Tue, 22 Oct 2013 11:21:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A43AD2AAF85; Tue, 22 Oct 2013 18:21:33 +0000 (UTC) Date: Tue, 22 Oct 2013 18:21:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20131022182133.GJ2976@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Proposed DMARC component to signal SMIME policy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 18:21:45 -0000 On Tue, Oct 22, 2013 at 01:56:25PM -0400, Scott Rose wrote: > We submitted an Internet-Draft on using a new DNS RRType to signal > that all email coming from the domain will be signed (proposed type > is called SMIMELOCK). So that when a client receives an email that > lacks a SMIME signature from a domain with the SMIMELOCK RR, it > could be marked as suspect. The draft is at: > https://datatracker.ietf.org/doc/draft-srose-smimelock/ Since the intended target of this record is the MUA, how do you propose to deal with "saved" email (that is email that did not "just arrive")? What happens when a message is first retrieved by the MUA from an IMAP server long after it is delivered to the mailbox? Does the policy apply to the: - Envelope sender domain? - RFC2822.From domain? - RFC2822.Sender domain? - DKIM signer domain? What is the interaction with "Resent-From" and/or "Resent-Sender"? What is the treatment of mail sent to a public list (and modified by the list adding a footer, ...)? I think the value of this effort will be marginal at best. There are I think too many corner cases to make the "all" value practically reliable. There's not much point in "partial" or "none". Problem areas: Outsourced email marketing, Outsourced Benefits providers, Public mailing lists, Resent mail, Stored mail, ... -- Viktor. From lutz@iks-jena.de Wed Oct 23 01:23:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73B621E8083 for ; Wed, 23 Oct 2013 01:23:49 -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 89K56HoN7Ngc for ; Wed, 23 Oct 2013 01:23:48 -0700 (PDT) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1621E8082 for ; Wed, 23 Oct 2013 01:23:47 -0700 (PDT) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.3/8.14.1) with ESMTP id r9N8NhF8011786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Oct 2013 10:23:45 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id r9N8NhK9026637 for dane@ietf.org; Wed, 23 Oct 2013 10:23:43 +0200 Date: Wed, 23 Oct 2013 10:23:43 +0200 From: Lutz Donnerhacke To: dane@ietf.org Message-ID: <20131023082343.GA26247@belenus.iks-jena.de> References: <20131022182133.GJ2976@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131022182133.GJ2976@mournblade.imrryr.org> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [dane] Proposed DMARC component to signal SMIME policy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 08:23:50 -0000 On Tue, Oct 22, 2013 at 06:21:33PM +0000, Viktor Dukhovni wrote: > I think the value of this effort will be marginal at best. There > are I think too many corner cases to make the "all" value practically > reliable. There's not much point in "partial" or "none". Yep. Let me add different cryptographic systems to this list. How about OpenPGP messages? How about Mixmaster or any other system which might become relevant in the future? From scottr.nist@gmail.com Wed Oct 23 11:32:05 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB83C11E81E9 for ; Wed, 23 Oct 2013 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zo7qrXpEKi7 for ; Wed, 23 Oct 2013 11:31:59 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id EF24511E814F for ; Wed, 23 Oct 2013 11:31:58 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 14:31:45 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 23 Oct 2013 14:31:57 -0400 Received: from h222244.nist.gov (h222244.nist.gov [129.6.222.244]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id r9NIVlob011518 for ; Wed, 23 Oct 2013 14:31:47 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1283) From: Scott Rose In-Reply-To: <20131022182133.GJ2976@mournblade.imrryr.org> Date: Wed, 23 Oct 2013 14:31:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20131022182133.GJ2976@mournblade.imrryr.org> To: X-Mailer: Apple Mail (2.1283) X-NIST-MailScanner-Information: Subject: Re: [dane] Proposed DMARC component to signal SMIME policy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 18:32:05 -0000 On Oct 22, 2013, at 2:21 PM, Viktor Dukhovni wrote: > On Tue, Oct 22, 2013 at 01:56:25PM -0400, Scott Rose wrote: >=20 >> We submitted an Internet-Draft on using a new DNS RRType to signal >> that all email coming from the domain will be signed (proposed type >> is called SMIMELOCK). So that when a client receives an email that >> lacks a SMIME signature from a domain with the SMIMELOCK RR, it >> could be marked as suspect. The draft is at: >> https://datatracker.ietf.org/doc/draft-srose-smimelock/ >=20 > Since the intended target of this record is the MUA, how do you > propose to deal with "saved" email (that is email that did not > "just arrive")? What happens when a message is first retrieved by > the MUA from an IMAP server long after it is delivered to the > mailbox? >=20 > Does the policy apply to the: >=20 > - Envelope sender domain? >=20 > - RFC2822.=46rom domain? >=20 > - RFC2822.Sender domain? >=20 > - DKIM signer domain? >=20 > What is the interaction with "Resent-From" and/or "Resent-Sender"? >=20 > What is the treatment of mail sent to a public list (and modified > by the list adding a footer, ...)? >=20 Admittedly we're still working on it. I envision it mostly being used = for domains that do transactional email, where one person sends it. It = would only be used on receipt of mail, so no check should be done on = saved mail. =20 The policy would apply (most likely) to the RFC2822 =46rom domain, since = that is the entity likely to be the one vouching for the message by the = signature. =20 > I think the value of this effort will be marginal at best. There > are I think too many corner cases to make the "all" value practically > reliable. There's not much point in "partial" or "none". >=20 "Partial" is only useful in advertising a interim state before going to = "all". "none" doesn't mean much, but could be interpreted as the domain = does not issue mail certs, so any signatures seen are from certs issued = someone else (not the domain holder). How the MUA interprets that is = local policy. > Problem areas: >=20 > Outsourced email marketing, > Outsourced Benefits providers, > Public mailing lists, > Resent mail, > Stored mail, > ... >=20 Admittedly, outsourced marketing is a problem. The main driver is = entities (mostly governments, but others as well) are looking for a way = to signal that all outgoing mail from a given domain will be signed. = G2G and G2C are our main targets.=20 Scott > --=20 > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From scottr.nist@gmail.com Wed Oct 23 12:21:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D1011E836F for ; Wed, 23 Oct 2013 12:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZBfmGBmjKnV for ; Wed, 23 Oct 2013 12:20:57 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 16DBE11E83BB for ; Wed, 23 Oct 2013 12:20:56 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 15:20:36 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 23 Oct 2013 15:20:48 -0400 Received: from h222244.nist.gov (h222244.nist.gov [129.6.222.244]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id r9NJKeu1015140 for ; Wed, 23 Oct 2013 15:20:40 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1283) From: Scott Rose In-Reply-To: <20131023082343.GA26247@belenus.iks-jena.de> Date: Wed, 23 Oct 2013 15:20:40 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <52F5F653-4D60-4D0A-B7B3-F7599127B98D@gmail.com> References: <20131022182133.GJ2976@mournblade.imrryr.org> <20131023082343.GA26247@belenus.iks-jena.de> To: X-Mailer: Apple Mail (2.1283) X-NIST-MailScanner-Information: Subject: Re: [dane] Proposed DMARC component to signal SMIME policy X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 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, 23 Oct 2013 19:21:03 -0000 On Oct 23, 2013, at 4:23 AM, Lutz Donnerhacke wrote: > On Tue, Oct 22, 2013 at 06:21:33PM +0000, Viktor Dukhovni wrote: >> I think the value of this effort will be marginal at best. There >> are I think too many corner cases to make the "all" value practically >> reliable. There's not much point in "partial" or "none". >=20 > Yep. Let me add different cryptographic systems to this list. How = about > OpenPGP messages? How about Mixmaster or any other system which might = become > relevant in the future? Definitely not objectionable. Perhaps instead of "smime=3D" changed to = "signed=3D" ? That makes it technology neutral. =20 Scott > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane