Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316B03A6C97 for ; Mon, 31 Jan 2011 16:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.153 X-Spam-Level: X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-eXBzIpAerd for ; Mon, 31 Jan 2011 16:42:17 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2FA623A6C95 for ; Mon, 31 Jan 2011 16:42:17 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p110jQQc004955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Feb 2011 01:45:31 +0100 (MET) From: Martin Rex Message-Id: <201102010045.p110jQgd009839@fs4113.wdf.sap.corp> To: keyassure@ietf.org Date: Tue, 1 Feb 2011 01:45:26 +0100 (MET) In-Reply-To: <4D445A57.90301@cs.tcd.ie> from "Stephen Farrell" at Jan 29, 11 06:20:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:42:18 -0000 Stephen Farrell wrote: > > I think I'd go for some form of #2, done in any reasonable way. I also find some form of #2 the most appealing. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE34F3A6AEE for ; Mon, 31 Jan 2011 12:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3Ly6XmsWjbB for ; Mon, 31 Jan 2011 12:27:05 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EA1C93A6C72 for ; Mon, 31 Jan 2011 12:27:04 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 402FE1ECB430; Mon, 31 Jan 2011 20:30:19 +0000 (UTC) Date: Mon, 31 Jan 2011 15:30:17 -0500 From: Andrew Sullivan To: Paul Wouters Message-ID: <20110131203017.GC1281@shinkuro.com> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> <20110131163846.GE44270@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:27:07 -0000 On Mon, Jan 31, 2011 at 02:25:38PM -0500, Paul Wouters wrote: > There are those who believe some method of obtaining cryptographicly > relevant material along with the A/AAAA record, meta-RR or EDNS) is > extremely useful. I agree that it is extremely useful. Unfortunately, previous efforts to cause automatic combinations to come out of the DNS have not proven successful. In particular, > I'd be interested in knowing more about these old attempts. Do you have > a good set of google keywords for me? the most obvious example has been the repeated attempts to get A and AAAA records in a single query. Rather vexingly, I can't point you to archives any more because the person who controls the old namedroppers archives has apparently taken them offline (or at least, had last time I checked). > >> (It is a conceivably different requirement to get the A and AAAA to >> come along with a new kind of record, but it's certainly not >> assignment by espert review.) > > This did not entirely parse, but I guess I would not object to getting Sorry. The expert review process for RRTYPE assignment explictly excludes any special server-side processing from scope. That will emphatically be required any time returning one RR automatically entails returning some other RR. Something that is important to remember here is the effect of caches. If you have some record (say, an A record) that could be in cache, and then you are asked for a different RRTYPE that would entail returning the A record at the same time, what do you do with the TTLs? What happens at the cache if you have the existing cached A and have to go get something else? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B1F3A6C46 for ; Mon, 31 Jan 2011 12:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGQuheWz8+kP for ; Mon, 31 Jan 2011 12:02:09 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id 876753A6C36 for ; Mon, 31 Jan 2011 12:02:07 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p0VK5G3s022244; Mon, 31 Jan 2011 12:05:16 -0800 Message-Id: <201101312005.p0VK5G3s022244@new.toad.com> To: Simon Josefsson In-reply-to: <87hbcpf2pw.fsf@latte.josefsson.org> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> <87hbcpf2pw.fsf@latte.josefsson.org> Comments: In-reply-to Simon Josefsson message dated "Mon, 31 Jan 2011 17:38:19 +0100." Date: Mon, 31 Jan 2011 12:05:15 -0800 From: John Gilmore Cc: keyassure@ietf.org Subject: [keyassure] Don't modify DNS server algorithms X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 20:02:10 -0000 > > People seem to forget that at some not too far distant point in the > > future, we want these records to come along with our A record lookup. > > Having them not at the same RRlabel is going to make that next to > > impossible. > > Why? > > Compare how DNSSEC modified DNS to ship other records along with A > record lookups, and those records aren't always on the same RRlabel as > the query. So I don't immediately see why it would be next to > impossible to do something similar. DNSSEC was a revision of the DNS protocols themselves. DANE is a revision of other protocols (like TLS or IPSEC) to use information pulled from the DNS. Don't forget that the DNS is the glue that binds the Internet to humans. Armchair protocol designers can make DNS implementations arbitrary complicated and buggy (and there was too much of that in DNSSEC, which is why it took a decade). It's quite amazing that it scaled up to still work in 2011. Its 1983 design (RFC 881-883) by Paul Mockapetris and Jon Postel handled hundreds -- hundreds! -- of hostnames, replacing a flat file (the "hosts table") that was updated weekly and distributed to every machine on the ARPAnet via FTP. They note: In the long run the Internet will become too complex and change too fast to keep a master table of all the hosts. At some point the master table will be reduced to simply the entries for the domain servers for the top level domains. By this time all normal translation of host names into addresses should take place by consulting domain servers. DNS has managed to survive for almost 30 years, coping with the gentle administration of SRI, the cluelessness of Network Solutions, the avarice of SAIC, the nepotism of ICANN, and the sewage of domain speculators. DNSSEC severely challenged it, and we still don't know if DNSSEC will scale up to full-Internet size while providing the high performance and high reliability that the world is used to. Adding more complications risks the whole house of cards. What DNS really needs is a multi-decade complete redesign from the ground up. When it was designed, distributed databases did not exist -- because there were no networks to distribute them on. A new design on database principles, without centralized control, like the routing system or the USENET, could eliminate a bunch of parasites and power-seekers and permit the DNS to survive for the next hundred years. Anyone who designs a simple new protocol on the theory that we'll have to modify the algorithms in all the DNS servers is pushing their luck. (And vastly delaying the widespread implementation of their protocol.) If that's what's going down in this committee, be very prepared to justify exactly why you can't do what you need to do by just defining a record type or two, like everybody else does. And make sure that the "improvement" you think you're making to the DNS is sufficiently general that it will improve the next dozen protocols, rather than just your own. John Gilmore (who implemented the original KEY and SIG records in BIND) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE103A6C61 for ; Mon, 31 Jan 2011 11:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoSbBT4GoHUX for ; Mon, 31 Jan 2011 11:22:24 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 501A33A6C57 for ; Mon, 31 Jan 2011 11:22:24 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id E082DC4FE; Mon, 31 Jan 2011 14:25:38 -0500 (EST) Date: Mon, 31 Jan 2011 14:25:38 -0500 (EST) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20110131163846.GE44270@shinkuro.com> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> <20110131163846.GE44270@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:22:25 -0000 On Mon, 31 Jan 2011, Andrew Sullivan wrote: > On Mon, Jan 31, 2011 at 11:22:37AM -0500, Paul Wouters wrote: >> People seem to forget that at some not too far distant point in the future, >> we want these records to come along with our A record lookup. > > I apologise for being a little (!) disengaged, but was there a plan > for getting records to "come along" with an A record lookup that did > not involve special server side processing? Sorry, I should not have used "we" here. There are those who believe some method of obtaining cryptographicly relevant material along with the A/AAAA record, meta-RR or EDNS) is extremely useful. This includes anonymized circuits, such as "tor" that have a very latent setup cost. > Because getting things to > "come along" with A record lookups involves reformatting the Internet, > or at least the DNS, and previous efforts in that rut have not been > notable for their success. I'd be interested in knowing more about these old attempts. Do you have a good set of google keywords for me? > (It is a conceivably different requirement to get the A and AAAA to > come along with a new kind of record, but it's certainly not > assignment by espert review.) This did not entirely parse, but I guess I would not object to getting an A/AAAA record along with TLSA, though then we also have to look at HASTLS, and what to do when the A/AAAA does not exist. But I guess this is getting of-topic for the discussion of "under one domain name or not", apart from the "it's a good and simple design that works for (AFAIK) all cases, and will make any future changes easier". Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965353A6844 for ; Mon, 31 Jan 2011 09:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.162 X-Spam-Level: * X-Spam-Status: No, score=1.162 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_40=-0.185, HELO_EQ_BLUEYON=1.4, MIME_8BIT_HEADER=0.3, MIME_BASE64_BLANKS=0.041] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5RhMjJ+Pni3 for ; Mon, 31 Jan 2011 09:10:53 -0800 (PST) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by core3.amsl.com (Postfix) with ESMTP id ACA883A67F0 for ; Mon, 31 Jan 2011 09:10:53 -0800 (PST) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out3.blueyonder.co.uk with smtp (Exim 4.52) id 1PjxKI-0000gm-J8; Mon, 31 Jan 2011 17:14:06 +0000 Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out5.blueyonder.co.uk with smtp (Exim 4.72) (envelope-from ) id 1PjxK3-00035t-IH; Mon, 31 Jan 2011 17:13:51 +0000 Message-ID: <34F77FE870D148EDA1C24C0FACC0A18D@local> From: "George Barwood" To: "Paul Wouters" , =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net><4D46DAEA.5040606@nic.cz> Date: Mon, 31 Jan 2011 17:14:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 17:10:56 -0000 PlBlb3BsZSBzZWVtIHRvIGZvcmdldCB0aGF0IGF0IHNvbWUgbm90IHRvbyBmYXIgZGlzdGFudCBw b2ludCBpbiB0aGUgZnV0dXJlLA0KPndlIHdhbnQgdGhlc2UgcmVjb3JkcyB0byBjb21lIGFsb25n IHdpdGggb3VyIEEgcmVjb3JkIGxvb2t1cC4gSGF2aW5nIHRoZW0NCj5ub3QgYXQgdGhlIHNhbWUg UlJsYWJlbCBpcyBnb2luZyB0byBtYWtlIHRoYXQgbmV4dCB0byBpbXBvc3NpYmxlLiBUaGUNCj4q LmZvby53d3cueGVsZXJhbmNlLmNvbSBjb25zdHJ1Y3RzIGFsbCBjb3VsZCBzaWduaWZ5IGEgem9u ZSBjdXQsIHNvIHRoZXkNCj53b3VsZCBhbGwgZ2V0IGRyb3BwZWQgYXMgb3V0LW9mLWJhaWxpd2lj ay4NCg0KTm8gLSBpbiBETlMgdGhlIHRydXN0IGlzIGhlaXJhcmNoaWNhbCwgc28gdGhlIHJlY29y ZHMgYXJlIG5vdCBvdXQtb2YtYmFpbGl3aWNrLg0KDQpCZXNpZGVzIGluIHRoaXMgY29udGV4dCB0 aGV5IHdpbGwgYmUgc2lnbmVkIGFuZCBvZiBjb3Vyc2Ugc2lnbmVkIGRhdGEgY2FuIGFsd2F5cyBi ZSBhY2NlcHRlZA0KKCBhZnRlciBjaGVja2luZyB0aGUgc2lnbmF0dXJlcyApIHJlZ2FyZGxlc3Mg b2YgYmFpbGl3aWNrLg0KDQpUaGVyZSBtYXkgYmUgcHJvYmxlbXMgd2l0aCByZXNwb25zZSBzaXpl IHRob3VnaCAtIHVubGVzcyBUQ1AgaXMgdXNlZC4NCg0K Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758233A6C3A for ; Mon, 31 Jan 2011 08:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAY7QYeoEJ7a for ; Mon, 31 Jan 2011 08:35:33 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B5D703A67F0 for ; Mon, 31 Jan 2011 08:35:33 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EEB3D1ECB424 for ; Mon, 31 Jan 2011 16:38:47 +0000 (UTC) Date: Mon, 31 Jan 2011 11:38:46 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110131163846.GE44270@shinkuro.com> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:35:34 -0000 On Mon, Jan 31, 2011 at 11:22:37AM -0500, Paul Wouters wrote: > People seem to forget that at some not too far distant point in the future, > we want these records to come along with our A record lookup. I apologise for being a little (!) disengaged, but was there a plan for getting records to "come along" with an A record lookup that did not involve special server side processing? Because getting things to "come along" with A record lookups involves reformatting the Internet, or at least the DNS, and previous efforts in that rut have not been notable for their success. (It is a conceivably different requirement to get the A and AAAA to come along with a new kind of record, but it's certainly not assignment by espert review.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9EF3A6AE5 for ; Mon, 31 Jan 2011 08:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qwi7QeChlJz8 for ; Mon, 31 Jan 2011 08:35:11 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 71E333A67F0 for ; Mon, 31 Jan 2011 08:35:10 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0VGcJ4l003784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Jan 2011 17:38:21 +0100 From: Simon Josefsson To: Paul Wouters References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110131:ondrej.sury@nic.cz::Rr2NhKdlxHEkJLMe:75pZ X-Hashcash: 1:22:110131:paul@xelerance.com::4AsSmk502WxhxvAA:Bsks X-Hashcash: 1:22:110131:keyassure@ietf.org::juRlll9S+HnJh7bi:MrYm Date: Mon, 31 Jan 2011 17:38:19 +0100 In-Reply-To: (Paul Wouters's message of "Mon, 31 Jan 2011 11:22:37 -0500 (EST)") Message-ID: <87hbcpf2pw.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:35:12 -0000 Paul Wouters writes: > People seem to forget that at some not too far distant point in the > future, we want these records to come along with our A record lookup. > Having them not at the same RRlabel is going to make that next to > impossible. Why? Compare how DNSSEC modified DNS to ship other records along with A record lookups, and those records aren't always on the same RRlabel as the query. So I don't immediately see why it would be next to impossible to do something similar. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A1F3A6C37 for ; Mon, 31 Jan 2011 08:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiDu6AnDBbLH for ; Mon, 31 Jan 2011 08:26:38 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 56E3B3A6827 for ; Mon, 31 Jan 2011 08:26:37 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0VGTksi003257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Jan 2011 17:29:48 +0100 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110131:ondrej.sury@nic.cz::i4gdBos2Br/HgvrG:1lq3 X-Hashcash: 1:22:110131:keyassure@ietf.org::xJk4x2cGAeYjno9J:VVT1 Date: Mon, 31 Jan 2011 17:29:46 +0100 In-Reply-To: <4D46DAEA.5040606@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej_Sur=FD?= =?iso-8859-2?Q?=22's?= message of "Mon, 31 Jan 2011 16:53:14 +0100") Message-ID: <87lj21f345.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:26:40 -0000 Ond=F8ej Sur=FD writes: > Combination of 1. and 2.: > 5. Prefacing the host name with a service name and a port number: > (_110._pop.mail.example.com). > > 6. Same as 5, but with a protocol selector: > (f.e. tcp_110._pop.mail.example.com) I dislike any solution that uses service names (the "_pop"), because I haven't seen any explanation what purpose it would serve. Is there a use case for it? > And this is an idea I got while reading the archive: > 7. Prefacing the host name with a service name and a port number with > fallback on every level, ie. all those are valid and looked up and > used in this order: > _110._pop.mail.example.com IN TLSA > _pop.mail.example.com IN TLSA > mail.example.com IN TLSA > > That way we can have quite good flexibility while not making things > too complicated (ie. I am able to specify separate certificate for > important service running on _443.http.www.example.com and having > www.example.com IN TLSA for all other certificates at > the host name). This adds roundtrips unless implementations do queries in parallel, and the latter creates some extra network packets. Network traffic is cheap, so I kind of like it. However I fear some implementations will skip the (_443.www.example.com,IN,TLS) query and go directly for the (www.example.com,IN,TLS) which kind of destroys the flexibility. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CE43A67B4 for ; Mon, 31 Jan 2011 08:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH-06w6jp4fT for ; Mon, 31 Jan 2011 08:19:24 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id B5A6A3A679F for ; Mon, 31 Jan 2011 08:19:24 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B17D1BF8B; Mon, 31 Jan 2011 11:22:37 -0500 (EST) Date: Mon, 31 Jan 2011 11:22:37 -0500 (EST) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <4D46DAEA.5040606@nic.cz> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 16:19:26 -0000 On Mon, 31 Jan 2011, Ondřej Surý wrote: > So to summary new suggestions which popped up on the list. > > Combination of 1. and 2.: > 5. Prefacing the host name with a service name and a port number: > (_110._pop.mail.example.com). > > 6. Same as 5, but with a protocol selector: > (f.e. tcp_110._pop.mail.example.com) > > And this is an idea I got while reading the archive: > 7. Prefacing the host name with a service name and a port number with > fallback on every level, ie. all those are valid and looked up and used in > this order: > _110._pop.mail.example.com IN TLSA > _pop.mail.example.com IN TLSA > mail.example.com IN TLSA > > That way we can have quite good flexibility while not making things too > complicated (ie. I am able to specify separate certificate for important > service running on _443.http.www.example.com and having www.example.com IN > TLSA for all other certificates at the host name). People seem to forget that at some not too far distant point in the future, we want these records to come along with our A record lookup. Having them not at the same RRlabel is going to make that next to impossible. The *.foo.www.xelerance.com constructs all could signify a zone cut, so they would all get dropped as out-of-bailiwick. Adding NSEC/NSEC3 for those would really just move the problem of locating the right TLSA for the right port to the issue of locating the right NSEC/NSEC3 for the lack of a certain *._*.www.example.com record. If you have two widely different security requirements, why are they on the same FQDN? They can be on the same host with different FQDNs. As previously listed examples of super secure website and snakeoil cert for monitoring, you can simple add "monitoring.www.example.com" FQDN, put its TLSA cert there and avoid this issue completely. I still strongly believe in the simple TLSA case without port or protocol specifiers and SRV like sub zones. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2543A6C3E for ; Mon, 31 Jan 2011 07:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXeoaB5lbEle for ; Mon, 31 Jan 2011 07:50:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 9752C3A6C3B for ; Mon, 31 Jan 2011 07:50:03 -0800 (PST) Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id CAE9873423F for ; Mon, 31 Jan 2011 16:53:15 +0100 (CET) Message-ID: <4D46DAEA.5040606@nic.cz> Date: Mon, 31 Jan 2011 16:53:14 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 15:50:14 -0000 On 17.1.2011 21:46, Warren Kumari wrote: > I was hoping that would be able to stick to one open item at a time but > the discussions on #17 (Should the first doc be TLS only or try be > everything to everyone?) has wrapped directly to this issue, so: > > I'm opening up Issue #1 (Deal with multiple TLS-based services under one > domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) > [ Dons frock, flaps hands, twirls the incense burner three times to the > left, presses button to make water squirt out of daisy add releases the > 12 doves -- now it is official ] > ----- > Description: > How to deal with multiple TLS-based services running under one domain > name, such as a POP, IMAP, and SMTP server all running on mail.example.com. > > Suggestions so far include: > 1. Prefacing the host name with a service name (_pop.mail.example.com) > 2. Prefacing the host name with a port number (_110.mail.example.com) > 3. Returning a set of records that contain port numbers in the response. > 4. SRV / ESRV So to summary new suggestions which popped up on the list. Combination of 1. and 2.: 5. Prefacing the host name with a service name and a port number: (_110._pop.mail.example.com). 6. Same as 5, but with a protocol selector: (f.e. tcp_110._pop.mail.example.com) And this is an idea I got while reading the archive: 7. Prefacing the host name with a service name and a port number with fallback on every level, ie. all those are valid and looked up and used in this order: _110._pop.mail.example.com IN TLSA _pop.mail.example.com IN TLSA mail.example.com IN TLSA That way we can have quite good flexibility while not making things too complicated (ie. I am able to specify separate certificate for important service running on _443.http.www.example.com and having www.example.com IN TLSA for all other certificates at the host name). 8. Same as 7. but with a protocol selector Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1A33A6B58 for ; Sun, 30 Jan 2011 14:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKlpyYWXQa9U for ; Sun, 30 Jan 2011 14:54:13 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1BED93A6B3A for ; Sun, 30 Jan 2011 14:54:12 -0800 (PST) Received: by wyf23 with SMTP id 23so5162666wyf.31 for ; Sun, 30 Jan 2011 14:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ov8dkS/TFxhNFNo0DvI8PzyQ7mKXKLw5q6cTOiZjFDY=; b=Qxu3FcOEjyGGClZsqeZBjfAkJSM2bBbbg0TurXk5BO6JDviHFkPgPgkezp7ZyVOm1A E4ggF2v//+iH0FEgJmj6fYk9XzSz9Q0gK8+rZjR8qOEDVxCAxWwfnEv8w9EVjbRuP4Yf MdKCtu7RqNJv91KtDVJEK4PAov/x5d5U9+tzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rJH+dxX+UGnhf9GCGD3w8aHMKBpKOffRfqIGgND3FbClqXTn7Lk3oeZra3rDf5FtB6 4hvdIMXK1oSlPuGlyHAphoCJloNVF+kDL8WaiXu65ue4LwPee/qmlRFLJCeLQ6ZzFmjh oruKik4YKwBdEzcnUt5Q4TcfbJsvlm4XbQ+/E= MIME-Version: 1.0 Received: by 10.227.138.15 with SMTP id y15mr5315808wbt.186.1296428245227; Sun, 30 Jan 2011 14:57:25 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Sun, 30 Jan 2011 14:57:25 -0800 (PST) In-Reply-To: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> <8762t6kskw.fsf@latte.josefsson.org> Date: Sun, 30 Jan 2011 14:57:25 -0800 X-Google-Sender-Auth: PdRs6tNxB-7MAG7yhuYKhp_lVmM Message-ID: From: Zack Weinberg To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 22:54:14 -0000 On Sun, Jan 30, 2011 at 1:22 PM, Paul Wouters wrote: > On Sun, 30 Jan 2011, Simon Josefsson wrote: > >> Good example. =C2=A0This is even more common than my earlier examples, s= o I >> even more strongly believe that any solution that doesn't permit >> different certs on different ports/protocols won't fly. > > Note that option 1 DOES permit different certs on different ports and > protocols. It is only the lookup that is different, and option 2 only > protects again a compromised server exchanging different security zone > certificates on the same server onto different services. I don't think > this really buys you anything on a compromised server. Yes. I advocate option 2 not for security reasons, but because it will make life easier for the client (which does not have to sort through many certs, it just has to say which one it needs) and cut down on response size. zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518E63A6B31 for ; Sun, 30 Jan 2011 13:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.752 X-Spam-Level: X-Spam-Status: No, score=-101.752 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTYYVgTn1Pa9 for ; Sun, 30 Jan 2011 13:52:05 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5574C3A6872 for ; Sun, 30 Jan 2011 13:52:05 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0ULtGVZ028997 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 30 Jan 2011 14:55:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D45DE44.9080601@vpnc.org> Date: Sun, 30 Jan 2011 13:55:16 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> <8762t6kskw.fsf@latte.josefsson.org> <87r5bujd1r.fsf@latte.josefsson.org> In-Reply-To: <87r5bujd1r.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 21:52:06 -0000 On 1/30/11 1:29 PM, Simon Josefsson wrote: > Paul Wouters writes: > >> On Sun, 30 Jan 2011, Simon Josefsson wrote: >> >>> Good example. This is even more common than my earlier examples, so I >>> even more strongly believe that any solution that doesn't permit >>> different certs on different ports/protocols won't fly. >> >> Note that option 1 DOES permit different certs on different ports and >> protocols. It is only the lookup that is different, and option 2 only >> protects again a compromised server exchanging different security zone >> certificates on the same server onto different services. I don't think >> this really buys you anything on a compromised server. > > If you don't see the problem, think about this scenario -- if I have one > important service running on port 443 on, say, www.cacert.org, with the > private key safely stored on a HSM, and I also have one weak and > important web interface running on port 4711 for some monitoring > purpose, with a snake oil cert, and I create TLSA records to cover both > certificates and put them in the DNS, it means that anyone stealing the > snake oil private key can masquerade as www.cacert.org if clients only > validate the TLSA records. Warren did a bad job of stating #1. It is not "all records are the same", but instead "each record says what port it is for". There is no difference in security properties between #1 and #2: it is all about preference for how the record is requested and its format. #1 has a simpler request (no port number) but an additional part of the response (includes the port number); #1 has an additional part of the request (includes the port number) but a simpler response (no port number). That's all. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34EFD3A6B31 for ; Sun, 30 Jan 2011 13:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.008 X-Spam-Level: X-Spam-Status: No, score=-103.008 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CdpsT2VOkPf for ; Sun, 30 Jan 2011 13:29:02 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 61A433A6B2C for ; Sun, 30 Jan 2011 13:29:02 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0ULW9PI007069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 30 Jan 2011 22:32:11 +0100 From: Simon Josefsson To: Paul Wouters References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> <8762t6kskw.fsf@latte.josefsson.org> <87r5bujd1r.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110130:keyassure@ietf.org::Xl8uIfe+Xp59QdWd:1qKE X-Hashcash: 1:22:110130:paul@xelerance.com::rRY86qB2PgrFOAnI:1jKN Date: Sun, 30 Jan 2011 22:32:09 +0100 In-Reply-To: <87r5bujd1r.fsf@latte.josefsson.org> (Simon Josefsson's message of "Sun, 30 Jan 2011 22:29:20 +0100") Message-ID: <87ipx6jcx2.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 21:29:04 -0000 Simon Josefsson writes: > Paul Wouters writes: > >> On Sun, 30 Jan 2011, Simon Josefsson wrote: >> >>> Good example. This is even more common than my earlier examples, so I >>> even more strongly believe that any solution that doesn't permit >>> different certs on different ports/protocols won't fly. >> >> Note that option 1 DOES permit different certs on different ports and >> protocols. It is only the lookup that is different, and option 2 only >> protects again a compromised server exchanging different security zone >> certificates on the same server onto different services. I don't think >> this really buys you anything on a compromised server. > > If you don't see the problem, think about this scenario -- if I have one > important service running on port 443 on, say, www.cacert.org, with the > private key safely stored on a HSM, and I also have one weak and > important web interface running on port 4711 for some monitoring ^^ That should be 'UNimportant', of course... /Simon > purpose, with a snake oil cert, and I create TLSA records to cover both > certificates and put them in the DNS, it means that anyone stealing the > snake oil private key can masquerade as www.cacert.org if clients only > validate the TLSA records. > > /Simon > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02BB13A6AF1 for ; Sun, 30 Jan 2011 13:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.016 X-Spam-Level: X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cqTwKQs5Gni for ; Sun, 30 Jan 2011 13:26:18 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 0BACC3A67F7 for ; Sun, 30 Jan 2011 13:26:17 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0ULTKQj006852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 30 Jan 2011 22:29:22 +0100 From: Simon Josefsson To: Paul Wouters References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> <8762t6kskw.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110130:zack.weinberg@sv.cmu.edu::YQCYGs1gciXFmwud:3mVB X-Hashcash: 1:22:110130:paul@xelerance.com::mkiZNdkurKPvOr6i:6ESK X-Hashcash: 1:22:110130:keyassure@ietf.org::9YvqM1WJevsBlNhR:UQrE Date: Sun, 30 Jan 2011 22:29:20 +0100 In-Reply-To: (Paul Wouters's message of "Sun, 30 Jan 2011 16:22:56 -0500 (EST)") Message-ID: <87r5bujd1r.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 21:26:20 -0000 Paul Wouters writes: > On Sun, 30 Jan 2011, Simon Josefsson wrote: > >> Good example. This is even more common than my earlier examples, so I >> even more strongly believe that any solution that doesn't permit >> different certs on different ports/protocols won't fly. > > Note that option 1 DOES permit different certs on different ports and > protocols. It is only the lookup that is different, and option 2 only > protects again a compromised server exchanging different security zone > certificates on the same server onto different services. I don't think > this really buys you anything on a compromised server. If you don't see the problem, think about this scenario -- if I have one important service running on port 443 on, say, www.cacert.org, with the private key safely stored on a HSM, and I also have one weak and important web interface running on port 4711 for some monitoring purpose, with a snake oil cert, and I create TLSA records to cover both certificates and put them in the DNS, it means that anyone stealing the snake oil private key can masquerade as www.cacert.org if clients only validate the TLSA records. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B193A6AF1 for ; Sun, 30 Jan 2011 13:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIH77-3LPHAg for ; Sun, 30 Jan 2011 13:19:45 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E94F23A6872 for ; Sun, 30 Jan 2011 13:19:44 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id CB5BEC4FE; Sun, 30 Jan 2011 16:22:56 -0500 (EST) Date: Sun, 30 Jan 2011 16:22:56 -0500 (EST) From: Paul Wouters To: Simon Josefsson In-Reply-To: <8762t6kskw.fsf@latte.josefsson.org> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> <8762t6kskw.fsf@latte.josefsson.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 21:19:46 -0000 On Sun, 30 Jan 2011, Simon Josefsson wrote: > Good example. This is even more common than my earlier examples, so I > even more strongly believe that any solution that doesn't permit > different certs on different ports/protocols won't fly. Note that option 1 DOES permit different certs on different ports and protocols. It is only the lookup that is different, and option 2 only protects again a compromised server exchanging different security zone certificates on the same server onto different services. I don't think this really buys you anything on a compromised server. Another case could be where an IP/hostname is presenting different certs for different ports, where the ports are forwarded to separate hosts. But again, if the portforwarded host or one of the port forwarded hosts is compromised, I doubt this protection will buy you much. (If it would, the attacker would block it and their own bogus cert and hope for foolush users) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019AF3A687C for ; Sun, 30 Jan 2011 13:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J2x7eN9-IUg for ; Sun, 30 Jan 2011 13:05:39 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 1F5A13A67F7 for ; Sun, 30 Jan 2011 13:05:37 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0UL8W6N005851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 30 Jan 2011 22:08:38 +0100 From: Simon Josefsson To: Zack Weinberg References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110130:zack.weinberg@sv.cmu.edu::Jaaeqyx65YZvDvmV:0mmI X-Hashcash: 1:22:110130:keyassure@ietf.org::ceLu/2EQky9TwK1K:TwGS Date: Sun, 30 Jan 2011 22:08:31 +0100 In-Reply-To: (Zack Weinberg's message of "Sun, 30 Jan 2011 11:30:49 -0800") Message-ID: <8762t6kskw.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 21:05:40 -0000 Zack Weinberg writes: > I like the idea of a port-selection prefix on the domain name. I can > speak only to the Web perspective, but it is fairly common to run two > separate HTTP(S) servers on different ports; when this is done, the > browser treats them as disjoint security principals for most purposes, > so administrators may want to use separate certificates for them. > Thus, some means of associating two or more certs with the same domain > is desirable even if the machine is exclusively "a web server". Good example. This is even more common than my earlier examples, so I even more strongly believe that any solution that doesn't permit different certs on different ports/protocols won't fly. > I am _opposed_ to any scheme that ties deployment of TLSA to > deployment of service-discovery records; I like service discovery in > principle, but I don't want to add to the administrative burden of > deploying TLSA, especially for protocols that currently work without > service discovery, like HTTP. +1 I think tying TLSA to SRV is a good way to never see TLSA used in the real world. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B402F3A67F7 for ; Sun, 30 Jan 2011 12:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sXSepwiNSbF for ; Sun, 30 Jan 2011 12:37:22 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C76663A67EB for ; Sun, 30 Jan 2011 12:37:21 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 317AABF8B; Sun, 30 Jan 2011 15:40:32 -0500 (EST) Date: Sun, 30 Jan 2011 15:40:31 -0500 (EST) From: Paul Wouters To: Zack Weinberg In-Reply-To: Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 20:37:22 -0000 On Sun, 30 Jan 2011, Zack Weinberg wrote: > I prefer a port-selection prefix to returning multiple TLSA records > for a lookup on the bare domain name because that keeps DNS response > sizes down and means the client doesn't have to sort out which one it > needs. the client needs to understand that anyway, in case you are rolling a cert, and you briefly have to have two TLSA records. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D0F3A6853 for ; Sun, 30 Jan 2011 11:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1o67JC70u1J for ; Sun, 30 Jan 2011 11:27:40 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 507303A6842 for ; Sun, 30 Jan 2011 11:27:40 -0800 (PST) Received: by wwa36 with SMTP id 36so5605712wwa.13 for ; Sun, 30 Jan 2011 11:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=rnX1LdPX8s3ARQBTvle5zpPweK3sOWoxJEM3gp54pfc=; b=Dv3VLWCgr8FG3OjJyJ5dxnDqQj+4/j4hy5Am7ocxH1IBEUzRLDnczKnRLLxKjq/iZz LQP19sHLkzkD2D33Oev5jZHS9WOx8p5RLgCZi9uUVuVUDPKGec3LFaGk+TPiuWbfZgxJ I0Go+ZDZUyGIZdlbVqFrYX0fjGDgZMq3fVHTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=RLA9FiFYrgZXYJum88HBFJ9sWHZ3kcYuw4DeobICUwhmtg/FYfrCUR5Fg2LV8TSvKz vtuedoMMZPl+r3BS/9hgXXoC5upHsjdNXfiVp2NvwK8W86drd8nfLOyJyhdfLTOtNMiu sZoO6cGzaUTR8am+10ghjSkzE0kRFWJ+4oH58= MIME-Version: 1.0 Received: by 10.227.20.84 with SMTP id e20mr5259347wbb.70.1296415849900; Sun, 30 Jan 2011 11:30:49 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Sun, 30 Jan 2011 11:30:49 -0800 (PST) In-Reply-To: <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> Date: Sun, 30 Jan 2011 11:30:49 -0800 X-Google-Sender-Auth: B5xiV34nuPk3OLLsNcDBRt6Ftl4 Message-ID: From: Zack Weinberg To: "keyassure@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 19:27:41 -0000 On Sun, Jan 30, 2011 at 1:54 AM, Jakob Schlyter wrote: > 28 jan 2011 kl. 18:22 skrev Simon Josefsson : > >> Paul asked me to clarify my preference and if TLS is the only supported >> protocol I prefer this approach: >> >> _110.mail.example.com >> >> where _110 is the port number. > > If we're going to do a port selector, I'd prefer the scheme above and I believe > we can omit the protocol selector and safely assume that the same key > association is used for all protocols listening on a single port. (This is not a response to Jakob specifically.) I like the idea of a port-selection prefix on the domain name. I can speak only to the Web perspective, but it is fairly common to run two separate HTTP(S) servers on different ports; when this is done, the browser treats them as disjoint security principals for most purposes, so administrators may want to use separate certificates for them. Thus, some means of associating two or more certs with the same domain is desirable even if the machine is exclusively "a web server". I prefer a port-selection prefix to returning multiple TLSA records for a lookup on the bare domain name because that keeps DNS response sizes down and means the client doesn't have to sort out which one it needs. I do not think it is useful to include the protocol in the prefix as well as the port. I have no opinion as to whether it is useful to include the transport name (TCP, UDP, SCTP, etc). I am _opposed_ to any scheme that ties deployment of TLSA to deployment of service-discovery records; I like service discovery in principle, but I don't want to add to the administrative burden of deploying TLSA, especially for protocols that currently work without service discovery, like HTTP. (For protocols that already do use SRV or MX or whatever, like SMTP, it is of course desirable for TLSA to play well with those schemes, but I don't think I'm qualified to figure out how that needs to work.) zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F073A6923 for ; Sun, 30 Jan 2011 01:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 375gWbQxscks for ; Sun, 30 Jan 2011 01:46:50 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 7A7963A691E for ; Sun, 30 Jan 2011 01:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:references:in-reply-to:mime-version:content-transfer-encoding: content-type:message-id:cc:x-mailer:from:subject:date:to; bh=GA8G3bJW36kLXS/6oe6yI4LOBB+Dv28tiadleXRrDs0=; b=ivPy1PeyzUgq6BabtcWNRne7X5DYLKBRuXL5puZSPFFCkACsWpC8KRJfEm7yi1mu+QZz1lpJMuOcr mqFDeZrBBFj5IcI93DmlhcogbjYRC4+qFGMAAt+2tbrKYtTdmEeNO7be+xoL+B3LZiUjvm5FATDrFR ae+rjF9P1vpB9bBQ= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 30 Jan 2011 10:49:58 +0100 (CET) References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> In-Reply-To: <87fwsdgczm.fsf@latte.josefsson.org> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4FF7840A-D279-4377-BFB0-BA73A613029E@kirei.se> X-Mailer: iPad Mail (8C148) From: Jakob Schlyter Date: Sun, 30 Jan 2011 10:54:16 +0100 To: Simon Josefsson Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 09:46:51 -0000 28 jan 2011 kl. 18:22 skrev Simon Josefsson : > Paul asked me to clarify my preference and if TLS is the only supported > protocol I prefer this approach: >=20 > _110.mail.example.com >=20 > where _110 is the port number. If we're going to do a port selector, I'd prefer the scheme above and I beli= eve we can omit the protocol selector and safely assume that the same key as= sociation is used for all protocols listening on a single port.=20 Jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29DA3A6915 for ; Sun, 30 Jan 2011 01:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exhiEqBnNeVP for ; Sun, 30 Jan 2011 01:33:12 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by core3.amsl.com (Postfix) with ESMTP id C78673A68EE for ; Sun, 30 Jan 2011 01:33:11 -0800 (PST) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh03-2.mail.saunalahti.fi (Postfix) with SMTP id 0E70FEBB57; Sun, 30 Jan 2011 11:36:21 +0200 (EET) Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A0386C06C48; Sun, 30 Jan 2011 11:36:21 +0200 Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id D9F6E27D82; Sun, 30 Jan 2011 11:36:10 +0200 (EET) Date: Sun, 30 Jan 2011 11:34:57 +0200 From: Ilari Liusvaara To: Simon Josefsson Message-ID: <20110130093457.GA30597@LK-Perkele-VI.localdomain> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87fwsdgczm.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87fwsdgczm.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 09:33:12 -0000 On Fri, Jan 28, 2011 at 06:22:05PM +0100, Simon Josefsson wrote: > > Paul asked me to clarify my preference and if TLS is the only supported > protocol I prefer this approach: > > _110.mail.example.com > > where _110 is the port number. > > If DTLS and TLS are the only supported protocols I would prefer this > approach: > > tcp_110.mail.example.com (TLS) > udp_110.mail.example.com (DTLS) Note that TLS can be carried over SCTP as well as TCP (there's even an Standards Track RFC about that). Now, SCTP is not commonly used (oft-cited reason is PAT, which will hopefully go away with IPv6). -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497AA3A67C3 for ; Sat, 29 Jan 2011 10:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fja9Kf4sXSb8 for ; Sat, 29 Jan 2011 10:17:07 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 31B793A67C2 for ; Sat, 29 Jan 2011 10:17:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C51C03E4087; Sat, 29 Jan 2011 18:20:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1296325213; bh=af8PIwCwq+OkH4 v5YoTv7RtmIdVLSOMZb+4/7TVgAr8=; b=STjhRLUtVv4Sbai2MKQJeVfK5qU+hL +ilabEbly2LkUIDGb++Nd3Q/Tya5nT2n5zUgEnbXMMUHt0unnA2nmHz98Hip/2fx bIAeepIzXtgJx3PJSoSuZdhLVO0fRbnUasRiWR7V5oKEKOsAz/vM4wvUwlvUkjGB +RepUdHMYoArr+bp53BxXLUGt+Wd1gdTGzZ6yMAQ2wTHUEKa9woo6QNl5Ab7spd6 6Op4JPrkE7mFR42YsnyXpYzhNp6iaGfhYTcyB7D8l56C/YbXZd3zJDUV7ZqfivgA qXmGSUrSVnIstPRYqcgfoKJaooEUyEumpikPA7SEuhAdU1ainS5MHGHw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id FjE6ampzlNoy; Sat, 29 Jan 2011 18:20:13 +0000 (GMT) Received: from [10.87.48.5] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6E3573E4082; Sat, 29 Jan 2011 18:20:09 +0000 (GMT) Message-ID: <4D445A57.90301@cs.tcd.ie> Date: Sat, 29 Jan 2011 18:20:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <87zkqlsbgp.fsf@latte.josefsson.org> <4D42D11D.3060907@nic.cz> <87bp31hzb5.fsf@latte.josefsson.org> In-Reply-To: <87bp31hzb5.fsf@latte.josefsson.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 18:17:08 -0000 I think I'd go for some form of #2, done in any reasonable way. One additional reason for that is that there could be multiple, differently trusted, services on the same host (e.g. a web service doing foo on port 80, with a foo-admin service on port 81 or something). Not including the service info in the DANE protocol somewhere could allow for foo to spoof as foo-admin in some cases. I've no idea if there are things actually deployed like that now but I do recall systems like that some years ago. S. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD94B3A6835 for ; Sat, 29 Jan 2011 08:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOFTZBHXFhtP for ; Sat, 29 Jan 2011 08:48:41 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 438C73A6838 for ; Sat, 29 Jan 2011 08:48:41 -0800 (PST) Received: by yie19 with SMTP id 19so1661136yie.31 for ; Sat, 29 Jan 2011 08:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R2BpfQ0gyPSOHSHNWbSXDmGzWalR1EJb4a3pazdmAK0=; b=shFj2A8MDTDGBCUaSEejUxmbBLcGmqiYlI1fCZ1Y7+h60Mzmc0zek5/EJcEQsNcO48 qqYHBFtog9OsykoqxZKes3p8CKaMLqWNL8C5INJom/CgHSuK4dOq7aSNt6LtEK04jXwu 9gHDWJkF6RpfaVLyWDy2kptwDkLTDVRFNTKaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dwkVNRm5i9WgfQhM1iX+VVXW6Hg/HiXvY7kbqq0GkCb8Mio8oGvTvVV/02ZWsRaE+k U3wX5HNwGrI0AaO5CW5nWtvPwZ4qra3quYwyy/tRKwgEpNPL/MaAJr0pxUdJ/l1ldyRj WTDr5c9oQlivhswo4DVckJaXarDIqm3ses17M= MIME-Version: 1.0 Received: by 10.100.167.5 with SMTP id p5mr1396646ane.222.1296319908360; Sat, 29 Jan 2011 08:51:48 -0800 (PST) Received: by 10.100.109.16 with HTTP; Sat, 29 Jan 2011 08:51:48 -0800 (PST) In-Reply-To: <4D443110.3040408@vpnc.org> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <753BF64B-0D41-4C51-B3EE-D6BC4781F93C@insensate.co.uk> <4D443110.3040408@vpnc.org> Date: Sat, 29 Jan 2011 11:51:48 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e6434658a73116049afeff1c Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 16:48:42 -0000 --0016e6434658a73116049afeff1c Content-Type: text/plain; charset=ISO-8859-1 Is NAPTR really poorly understood, or just poorly designed? Putting REs into the DNS makes me feel really uncomfortable. Might as well have javascript in there. Human administrators can manage NAPTR records if they understand what they are doing. Managing them automatically looks likely to me to be impossible. So NAPTR can possibly be made to work as a means of achieving the original goal of enabling resolution of URNs. It is not what I would want to use for service discovery. SRV and URI appear to me to be much closer to what we need here. On Sat, Jan 29, 2011 at 10:24 AM, Paul Hoffman wrote: > On 1/29/11 4:03 AM, Lawrence Conroy wrote: > >> On 28 Jan 2011, at 18:22, James Cloos wrote: >> >>> "WK" == Warren Kumari writes: >>>>>>>> >>>>>>> >>> WK> Ondrej and I would like to call #1 (and #17) soon, but would like to >>> WK> get a little clarification / restatement of folks views... >>> >>> WK> When looking up TLSA records, would folk prefer querying for: >>> >>> WK> 1: Just a hostname (mail.example.com) and pick from the returned >>> WK> records. >>> >>> We should recommend doing an NAPTR lookup on the hostname and using its >>> results to choose what A,AAAA,SRV,TLSA,etc RRs to look for. >>> >>> -JimC >>> >> >> To which I reply: >> If you're going to recommend NAPTR, then WHAT kind of NAPTR? >> unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ... >> If you're going to hunt A/AAAA as well as SRV and others I *guess* UNAPTR. >> I'm really not sure using UNAPTR is doing anyone a favour, but if you >> must, you need to spell it out. >> all the best, >> > > ...or don't do this at all. If we want to make certificate associations > widely deployed, requiring that it be tied to a protocol that is poorly > understood and barely deployed seems like a bad idea. > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e6434658a73116049afeff1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is NAPTR really poorly understood, or just poorly designed?

<= div>Putting REs into the DNS makes me feel really uncomfortable. Might as w= ell have javascript in there.

Human administrators= can manage NAPTR records if they understand what they are doing. Managing = them automatically looks likely to me to be impossible.

So NAPTR can possibly be made to work as a means of ach= ieving the original goal of enabling resolution of URNs. It is not what I w= ould want to use for service discovery.


SRV and URI appear to me to be much closer to what we need here.
=


On Sat, Jan 29, 201= 1 at 10:24 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 1/29/11 4:03 AM, Lawre= nce Conroy wrote:
On 28 Jan 2011, at 18:22, James Cloos wrote:
"WK" =3D=3D Warren Kumari<warren@kumari.net> =A0writes:

WK> =A0Ondrej and I would like to call #1 (and #17) soon, but would like= to
WK> =A0get a little clarification / restatement of folks views...

WK> =A0When looking up TLSA records, would folk prefer querying for:

WK> =A01: Just a hostname (mail.example.com) and pick from the returned
WK> =A0records.

We should recommend doing an NAPTR lookup on the hostname and using its
results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.

-JimC

To which I reply:
=A0 If you're going to recommend NAPTR, then WHAT kind of NAPTR?
unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ...
If you're going to hunt A/AAAA as well as SRV and others I *guess* UNAP= TR.
I'm really not sure using UNAPTR is doing anyone a favour, but if you m= ust, you need to spell it out.
all the best,

...or don't do this at all. If we want to make certificate associations= widely deployed, requiring that it be tied to a protocol that is poorly un= derstood and barely deployed seems like a bad idea.

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e6434658a73116049afeff1c-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6553A67D8 for ; Sat, 29 Jan 2011 07:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.448 X-Spam-Level: X-Spam-Status: No, score=-101.448 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWRiCAVlGzwC for ; Sat, 29 Jan 2011 07:20:52 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B66543A677E for ; Sat, 29 Jan 2011 07:20:52 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0TFO1JE067797 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 29 Jan 2011 08:24:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D443110.3040408@vpnc.org> Date: Sat, 29 Jan 2011 07:24:00 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <753BF64B-0D41-4C51-B3EE-D6BC4781F93C@insensate.co.uk> In-Reply-To: <753BF64B-0D41-4C51-B3EE-D6BC4781F93C@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 15:20:53 -0000 On 1/29/11 4:03 AM, Lawrence Conroy wrote: > On 28 Jan 2011, at 18:22, James Cloos wrote: >>>>>>> "WK" == Warren Kumari writes: >> >> WK> Ondrej and I would like to call #1 (and #17) soon, but would like to >> WK> get a little clarification / restatement of folks views... >> >> WK> When looking up TLSA records, would folk prefer querying for: >> >> WK> 1: Just a hostname (mail.example.com) and pick from the returned >> WK> records. >> >> We should recommend doing an NAPTR lookup on the hostname and using its >> results to choose what A,AAAA,SRV,TLSA,etc RRs to look for. >> >> -JimC > > To which I reply: > If you're going to recommend NAPTR, then WHAT kind of NAPTR? > unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ... > If you're going to hunt A/AAAA as well as SRV and others I *guess* UNAPTR. > I'm really not sure using UNAPTR is doing anyone a favour, but if you must, you need to spell it out. > all the best, ...or don't do this at all. If we want to make certificate associations widely deployed, requiring that it be tied to a protocol that is poorly understood and barely deployed seems like a bad idea. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DD93A679C for ; Sat, 29 Jan 2011 04:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+b5zCc6YJi9 for ; Sat, 29 Jan 2011 04:00:47 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id C53F43A677C for ; Sat, 29 Jan 2011 04:00:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id AC9E0B75BD; Sat, 29 Jan 2011 12:03:53 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (shade.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHi4OjIvb6jg; Sat, 29 Jan 2011 12:03:52 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E1B65B75B2; Sat, 29 Jan 2011 12:03:52 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Sat, 29 Jan 2011 12:03:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <753BF64B-0D41-4C51-B3EE-D6BC4781F93C@insensate.co.uk> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> To: James Cloos X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 12:00:48 -0000 On 28 Jan 2011, at 18:22, James Cloos wrote: >>>>>> "WK" =3D=3D Warren Kumari writes: >=20 > WK> Ondrej and I would like to call #1 (and #17) soon, but would like = to > WK> get a little clarification / restatement of folks views... >=20 > WK> When looking up TLSA records, would folk prefer querying for: >=20 > WK> 1: Just a hostname (mail.example.com) and pick from the returned > WK> records. >=20 > We should recommend doing an NAPTR lookup on the hostname and using = its > results to choose what A,AAAA,SRV,TLSA,etc RRs to look for. >=20 > -JimC To which I reply: If you're going to recommend NAPTR, then WHAT kind of NAPTR? unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ... If you're going to hunt A/AAAA as well as SRV and others I *guess* = UNAPTR. I'm really not sure using UNAPTR is doing anyone a favour, but if you = must, you need to spell it out. all the best, Lawrence= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342C23A6869 for ; Fri, 28 Jan 2011 10:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.033 X-Spam-Level: X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXtzJwcP06tR for ; Fri, 28 Jan 2011 10:54:01 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id DE1E43A6911 for ; Fri, 28 Jan 2011 10:54:00 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0SIv1l9007430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 19:57:02 +0100 From: Simon Josefsson To: Warren Kumari References: <4D42EF85.30004@nic.cz> <87bp31gcvr.fsf@latte.josefsson.org> <4D43079A.20005@vpnc.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110128:paul.hoffman@vpnc.org::6avKjhOEPpT+fNqI:07BE X-Hashcash: 1:22:110128:keyassure@ietf.org::DBv5T7FmKKaRFTvm:6LBS X-Hashcash: 1:22:110128:warren@kumari.net::ENqpCAXi/PSELI/P:DL1A Date: Fri, 28 Jan 2011 19:57:01 +0100 In-Reply-To: (Warren Kumari's message of "Fri, 28 Jan 2011 13:26:34 -0500") Message-ID: <874o8sg8le.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Call for consensus on #17 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:54:02 -0000 Warren Kumari writes: > On Jan 28, 2011, at 1:14 PM, Paul Hoffman wrote: > >> On 1/28/11 9:24 AM, Simon Josefsson wrote: >>> Ond=F8ej Sur=FD writes: >>> >>>> Hi all, >>>> >>>> upon discussion with my fellow co-chair I hereby call for >>>> consensus on >>>> issue #17. >>>> >>>> The consensus would be that the initial document >>>> (draft-ietf-dane-protocol) would support only TLS. >>> >>> Does this exclude DTLS? > > No... Good catch though! > > Apologies for not being clearer -- the document uses the term TLS to > refer to both TLS and DTLS, and we have fallen into doing the same > thing. Just checking. I don't think DTLS is important, but it is easy to support if we support TLS already. However supporting both TLS and DTLS has consequences for naming. Port 1234 over TCP does not necessarily run the same service as port 1234 over UDP. Thus my preferred naming scheme would then be: _1234._tcp.mail.example.com _1234._udp.mail.example.com /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E303A694A for ; Fri, 28 Jan 2011 10:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTAyiQBLqO8y for ; Fri, 28 Jan 2011 10:27:00 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by core3.amsl.com (Postfix) with ESMTP id 2E0683A67D1 for ; Fri, 28 Jan 2011 10:27:00 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id ADFC940120; Fri, 28 Jan 2011 18:29:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296239376; bh=Noffb2veI+4r4biCgvDvs8tQeptkLk/8c2vyiPASKHg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=HUq2HGUSeeWsO9a9aXQnsTPXVwEx/tucICI6GVLbwTvNMNkNTtWOSJJjR6xVrdgp8 1ArrXtLn31V1xUi3SCu8oRUIey79fgVi4d+pamGMaMNYcm141xKvIEy48OOlgvkICo 6IRVSvveu/RrhnN9z4nqUIFSnDEaiZc1n0lb5T5U= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id CD1C436002B; Fri, 28 Jan 2011 18:22:48 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> (Warren Kumari's message of "Thu, 27 Jan 2011 12:14:02 -0500") References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2011 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 28 Jan 2011 13:22:48 -0500 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110128:keyassure@ietf.org::65jJ2wS9BX6ZuM+O:000000000000000000000000000000000000000000jtKFZ X-Hashcash: 1:30:110128:warren@kumari.net::U2y0Ae6rP6Uf+IXl:0000000000000000000000000000000000000000000apiy2 Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:28:00 -0000 >>>>> "WK" == Warren Kumari writes: WK> Ondrej and I would like to call #1 (and #17) soon, but would like to WK> get a little clarification / restatement of folks views... WK> When looking up TLSA records, would folk prefer querying for: WK> 1: Just a hostname (mail.example.com) and pick from the returned WK> records. We should recommend doing an NAPTR lookup on the hostname and using its results to choose what A,AAAA,SRV,TLSA,etc RRs to look for. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDED13A694C for ; Fri, 28 Jan 2011 10:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnN+FmeOKWdd for ; Fri, 28 Jan 2011 10:23:30 -0800 (PST) Received: from vimes.kumari.net (unknown [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 9E95E3A694A for ; Fri, 28 Jan 2011 10:23:30 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1AEC91B40CC1; Fri, 28 Jan 2011 13:26:36 -0500 (EST) Message-Id: From: Warren Kumari To: Paul Hoffman In-Reply-To: <4D43079A.20005@vpnc.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 Jan 2011 13:26:34 -0500 References: <4D42EF85.30004@nic.cz> <87bp31gcvr.fsf@latte.josefsson.org> <4D43079A.20005@vpnc.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #17 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:23:31 -0000 On Jan 28, 2011, at 1:14 PM, Paul Hoffman wrote: > On 1/28/11 9:24 AM, Simon Josefsson wrote: >> Ond=F8ej Sur=FD writes: >> >>> Hi all, >>> >>> upon discussion with my fellow co-chair I hereby call for =20 >>> consensus on >>> issue #17. >>> >>> The consensus would be that the initial document >>> (draft-ietf-dane-protocol) would support only TLS. >> >> Does this exclude DTLS? No... Good catch though! Apologies for not being clearer -- the document uses the term TLS to =20 refer to both TLS and DTLS, and we have fallen into doing the same =20 thing. I have a procmail rule that I pass outgoing mail through that does =20 'sed/exmaple.com/example.com' on outgoing mail, perhaps I should add =20 's/TLS/TLS\/DTLS/' :-) >> DTLS is not the same protocol as TLS. > > DTLS is clearly and completely covered in every WG draft so far. If =20= > it is not clear, let the authors know; that would be an error on our =20= > part. Nope, I believe it is perfectly clear in the doc (clear enough that I =20= automatically see the implied DTLS) W > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19013A68EF for ; Fri, 28 Jan 2011 10:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.82 X-Spam-Level: X-Spam-Status: No, score=-100.82 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-Y8zmNWcT-g for ; Fri, 28 Jan 2011 10:11:44 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 402333A6882 for ; Fri, 28 Jan 2011 10:11:44 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0SIEo6B026357 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Jan 2011 11:14:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D43079A.20005@vpnc.org> Date: Fri, 28 Jan 2011 10:14:50 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D42EF85.30004@nic.cz> <87bp31gcvr.fsf@latte.josefsson.org> In-Reply-To: <87bp31gcvr.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Call for consensus on #17 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:11:44 -0000 On 1/28/11 9:24 AM, Simon Josefsson wrote: > Ondøej Surý writes: > >> Hi all, >> >> upon discussion with my fellow co-chair I hereby call for consensus on >> issue #17. >> >> The consensus would be that the initial document >> (draft-ietf-dane-protocol) would support only TLS. > > Does this exclude DTLS? DTLS is not the same protocol as TLS. DTLS is clearly and completely covered in every WG draft so far. If it is not clear, let the authors know; that would be an error on our part. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85663A6901 for ; Fri, 28 Jan 2011 09:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfMS9KnB6+90 for ; Fri, 28 Jan 2011 09:27:52 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E9D343A684A for ; Fri, 28 Jan 2011 09:27:51 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0SHUvvT024513 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Jan 2011 10:30:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D42FD51.4090701@vpnc.org> Date: Fri, 28 Jan 2011 09:30:57 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> In-Reply-To: <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:27:53 -0000 On 1/27/11 9:14 AM, Warren Kumari wrote: > Ondrej and I would like to call #1 (and #17) soon, but would like to get > a little clarification / restatement of folks views... > > When looking up TLSA records, would folk prefer querying for: > > 1: Just a hostname (mail.example.com) and pick from the returned records. > > 2: Looking up a name prefixed with a port (_443.www.example.com) or port > and proto (_443._tcp.www.example.com). > An application could optimize beyond this, but this defines what is > required to look up. I prefer #1, but think #2 is OK. If we go with #2, I prefer that we keep the semantics close to SRV, and not combine port and transport type into a single label. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F68D3A67F4 for ; Fri, 28 Jan 2011 09:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdLnGuknjhGy for ; Fri, 28 Jan 2011 09:21:25 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 8ACBE3A67C2 for ; Fri, 28 Jan 2011 09:21:24 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0SHOO7e002431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 18:24:26 +0100 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <4D42EF85.30004@nic.cz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110128:keyassure@ietf.org::mYVJpRWD3geUnicp:1X9d X-Hashcash: 1:22:110128:ondrej.sury@nic.cz::2sOwXimahub9P0mK:FXRN Date: Fri, 28 Jan 2011 18:24:24 +0100 In-Reply-To: <4D42EF85.30004@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej_Sur=FD=22?= =?iso-8859-2?Q?'s?= message of "Fri, 28 Jan 2011 17:32:05 +0100") Message-ID: <87bp31gcvr.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #17 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:21:26 -0000 Ond=F8ej Sur=FD writes: > Hi all, > > upon discussion with my fellow co-chair I hereby call for consensus on > issue #17. > > The consensus would be that the initial document > (draft-ietf-dane-protocol) would support only TLS. Does this exclude DTLS? DTLS is not the same protocol as TLS. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA853A6914 for ; Fri, 28 Jan 2011 09:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIh2NcPNnNE8 for ; Fri, 28 Jan 2011 09:19:05 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id F0D823A68D2 for ; Fri, 28 Jan 2011 09:19:04 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0SHM5gg002380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 18:22:06 +0100 From: Simon Josefsson To: Warren Kumari References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110128:keyassure@ietf.org::evNz9VNsd8J83rj1:5DKh X-Hashcash: 1:22:110128:warren@kumari.net::WPS8h6PKQLMj/OhU:89PI Date: Fri, 28 Jan 2011 18:22:05 +0100 In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> (Warren Kumari's message of "Mon, 17 Jan 2011 15:46:10 -0500") Message-ID: <87fwsdgczm.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:19:06 -0000 Warren Kumari writes: > I was hoping that would be able to stick to one open item at a time > but the discussions on #17 (Should the first doc be TLS only or try be > everything to everyone?) has wrapped directly to this issue, so: > > I'm opening up Issue #1 (Deal with multiple TLS-based services under > one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) > [ Dons frock, flaps hands, twirls the incense burner three times to > the left, presses button to make water squirt out of daisy add > releases the 12 doves -- now it is official ] > ----- > Description: > How to deal with multiple TLS-based services running under one domain > name, such as a POP, IMAP, and SMTP server all running on > mail.example.com. > > Suggestions so far include: > Prefacing the host name with a service name (_pop.mail.example.com) > Prefacing the host name with a port number (_110.mail.example.com) > Returning a set of records that contain port numbers in the response. > SRV / ESRV > > ----- Paul asked me to clarify my preference and if TLS is the only supported protocol I prefer this approach: _110.mail.example.com where _110 is the port number. If DTLS and TLS are the only supported protocols I would prefer this approach: tcp_110.mail.example.com (TLS) udp_110.mail.example.com (DTLS) /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663983A68FF for ; Fri, 28 Jan 2011 08:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVXTfxirmf2J for ; Fri, 28 Jan 2011 08:29:01 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 0FD533A68F9 for ; Fri, 28 Jan 2011 08:29:00 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id DD532734338 for ; Fri, 28 Jan 2011 17:32:05 +0100 (CET) Message-ID: <4D42EF85.30004@nic.cz> Date: Fri, 28 Jan 2011 17:32:05 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] Call for consensus on #17 (Was: Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:29:02 -0000 Hi all, upon discussion with my fellow co-chair I hereby call for consensus on issue #17. The consensus would be that the initial document (draft-ietf-dane-protocol) would support only TLS. If there is ever need to expand it will be worked on in different I-Ds referencing draft-ietf-dane-protocol and either expanding TLSA or specifying their on RR Type (similar SSHFP or IPSECKEY). Regards, Ondrej P.S.: As a side note the Issue #17 is only on TLS-only or not. Let's not get to X.509/HTTP/etc. discussions in this issue again. If you feel this needs to be discussed, drop us a note and we will open a separate issue in the tracker. Thanks. On 16.1.2011 04:15, Warren Kumari wrote: > Buoyed by actual progress on getting the first issue resolved, I'm > proposing that we jump right into... the 17th issue. > > Issue #17: Should draft-ietf-dane-protocol support TLS only or be > more ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17): > > Description: ------- Please note: This is not the "what all protocols > can / do we want to support" issue. That will be a separate (and > probably lively!) discussion. > > The current version of draft-ietf-dane-protocol is titled "Using > Secure DNS to Associate Certificates with Domain Names For TLS" and > first goal / milestone is "First WG draft of standards-track protocol > for using DNS to associate hosts with keys for TLS and DTLS". > > What I would like us to discuss is: Should *this* document simply > specify how to support TLS and future protocols can be supported by > saying "TLSA, but interpret field Foo to contain Bar" (or "Similar to > TLSA, but this different RR, formatted like Baz"). Note that some > other protocols already have similar RRtypes; for example SSH already > has SSHFP. > > The other alternative would be to make *this* document be much more > generic and able to support arbitrary key bindings. ------ > > Getting consensus on this issue soon would be good, as it affects how > the document is written... -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660493A6856 for ; Fri, 28 Jan 2011 06:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz9xkh23lW+A for ; Fri, 28 Jan 2011 06:31:38 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 259573A6826 for ; Fri, 28 Jan 2011 06:31:37 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0SEYdPY023803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 15:34:40 +0100 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <87zkqlsbgp.fsf@latte.josefsson.org> <4D42D11D.3060907@nic.cz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110128:keyassure@ietf.org::0+wui+ZSFoCe/q2k:8UG2 X-Hashcash: 1:22:110128:ondrej.sury@nic.cz::DLZVVsQXbmu5e93w:8SE9 Date: Fri, 28 Jan 2011 15:34:38 +0100 In-Reply-To: <4D42D11D.3060907@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej_Sur=FD?= =?iso-8859-2?Q?=22's?= message of "Fri, 28 Jan 2011 15:22:21 +0100") Message-ID: <87bp31hzb5.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:31:39 -0000 Ond=F8ej Sur=FD writes: > On 28.1.2011 09:01, Simon Josefsson wrote: >> Paul Wouters writes: >> >>> On Thu, 27 Jan 2011, Warren Kumari wrote: >>> >>>> Ondrej and I would like to call #1 (and #17) soon, but would like to >>>> get a little clarification / restatement of folks views... >>>> >>>> When looking up TLSA records, would folk prefer querying for: >>>> >>>> 1: Just a hostname (mail.example.com) and pick from the returned recor= ds. >>>> >>>> 2: Looking up a name prefixed with a port (_443.www.example.com) or >>>> port and proto (_443._tcp.www.example.com). >>>> An application could optimize beyond this, but this defines what is >>>> required to look up. >>> >>> I prefer 1, because in the majority of cases there is just one certifia= te, >>> as people tend to use different hostnames for different services >>> (mail.example.com, www.example.com) >> >> I disagree, it is common to have multiple services with different >> certificates/key on one host -- many people access their mail server >> through SMTP (port 25), submission (port 587), webmail (https) and >> possibly other ways (I access e-mail over SSH which can use certificates >> as well). > > Simon, > > would honoring SRVNames attribute in cert (for Type 1/2) fix that? > Ie. have multiple records for mail.example.net, but each with > different SRVNames attribute inside the cert? Yes, although it some disadvantages. Consider this (just an illustration, replace DANE with whatever RR name we end up with and the hash with whatever data is needed to confirm the certificate data, and imagine the DNSSEC records around the RRset): mail.example.net. IN DANE 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 mail.example.net. IN DANE 62cdb7020ff920e5aa642c3d4066950dd1f01f4d mail.example.net. IN DANE aef3a7835277a28da831005c2ae3b919e2076a62 mail.example.net. IN DANE 088e16a1019277b15d58faf0541e11910eb756f6 A client that wants to contact port 443 would need to establish the TLS session and extract the peer's certificate and hash it and compare it to all the hashes in the RR. Only the one succeeding should be further validated for the SubjectAltName attribute. Compare instead the following records: tcp_443.mail.example.net. IN DANE 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33 tcp_25.mail.example.net. IN DANE 62cdb7020ff920e5aa642c3d4066950dd1f01f4d tcp_587.mail.example.net. IN DANE aef3a7835277a28da831005c2ae3b919e2076a62 tcp_143.mail.example.net. IN DANE 088e16a1019277b15d58faf0541e11910eb756f6 The client connecting to mail.example.net on port 25 could look up tcp_25.mail.example.net and directly compare that hash with the server certificate. Another disadvantage is that this approach requires validation of SAN's which in turns require ASN.1 and X.509 processing. With the my preferred approach, to get trust in a server's certificate, all that is needed is to hash the certificate and compare with what's in the DNS RR. > That of course doesn't work for Type 3/4 (CA cert) and for bare keys. Right. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0983A689D for ; Fri, 28 Jan 2011 06:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9xB-6VDQb4i for ; Fri, 28 Jan 2011 06:19:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 5C0023A689B for ; Fri, 28 Jan 2011 06:19:16 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id DC4DE73444F for ; Fri, 28 Jan 2011 15:22:21 +0100 (CET) Message-ID: <4D42D11D.3060907@nic.cz> Date: Fri, 28 Jan 2011 15:22:21 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <87zkqlsbgp.fsf@latte.josefsson.org> In-Reply-To: <87zkqlsbgp.fsf@latte.josefsson.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:19:18 -0000 On 28.1.2011 09:01, Simon Josefsson wrote: > Paul Wouters writes: > >> On Thu, 27 Jan 2011, Warren Kumari wrote: >> >>> Ondrej and I would like to call #1 (and #17) soon, but would like to >>> get a little clarification / restatement of folks views... >>> >>> When looking up TLSA records, would folk prefer querying for: >>> >>> 1: Just a hostname (mail.example.com) and pick from the returned records. >>> >>> 2: Looking up a name prefixed with a port (_443.www.example.com) or >>> port and proto (_443._tcp.www.example.com). >>> An application could optimize beyond this, but this defines what is >>> required to look up. >> >> I prefer 1, because in the majority of cases there is just one certifiate, >> as people tend to use different hostnames for different services >> (mail.example.com, www.example.com) > > I disagree, it is common to have multiple services with different > certificates/key on one host -- many people access their mail server > through SMTP (port 25), submission (port 587), webmail (https) and > possibly other ways (I access e-mail over SSH which can use certificates > as well). Simon, would honoring SRVNames attribute in cert (for Type 1/2) fix that? Ie. have multiple records for mail.example.net, but each with different SRVNames attribute inside the cert? That of course doesn't work for Type 3/4 (CA cert) and for bare keys. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDBD3A688C for ; Fri, 28 Jan 2011 05:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed7hP3J8aE3V for ; Fri, 28 Jan 2011 05:24:51 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8E26E3A6893 for ; Fri, 28 Jan 2011 05:24:50 -0800 (PST) Received: by gwb20 with SMTP id 20so1222656gwb.31 for ; Fri, 28 Jan 2011 05:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hXjpsW9NvmOb2pomDTm4olys6heIBBplCcqo9+3+Um8=; b=UVmLOvGexD3mh5cxs5QGhWKaNrflZZn9Mt+vi8pHAHj8ApkvmFWVddTqJHyVR6QczG CvVwkvz5P4AUsbcELCk0Wo3mN8EK90zaoRPM7lGvSOa0p5fTYxPdtPF9uccyrzUvbIQY 581Z+CQwGVzBdZX3MNxPQCX8/h2TlEcHiCc68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XZ897s6VQOpdNiIRYQxObaPkKyJ74X3VnV2lH4smkDxvWzHppgemN/gUgLx7L9OlMo jRSWUA/B2vTPHW77+wmLhIuOUTPxjc3/ucS/BSCRUPxkIy+c3PIWS9+OppToyVticy68 KDCRQHQK4xNAo3RjdM5tE6bJbJYjqDliKQE6g= MIME-Version: 1.0 Received: by 10.100.167.5 with SMTP id p5mr409353ane.222.1296221276367; Fri, 28 Jan 2011 05:27:56 -0800 (PST) Received: by 10.100.109.16 with HTTP; Fri, 28 Jan 2011 05:27:56 -0800 (PST) In-Reply-To: <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> Date: Fri, 28 Jan 2011 08:27:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=0016e6434658ba6c70049ae808d2 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 13:24:53 -0000 --0016e6434658ba6c70049ae808d2 Content-Type: text/plain; charset=ISO-8859-1 It is not a question of prefer, it is a question of what you can get the DNS infrastructure to do if you are not going to attempt to change the rules or change DNSSEC. DNS has wildcards and alias records (CNAME, DNAME) and they make a difference. The short version of the story is that if you are going to respect those constraints: 1) A prefix can only be applied to a canonical name stem 2) It has to be possible to distinguish prefixed names from wildcarded records. The other constraint is that early adopters of DNS keying are almost certainly going to be completely new applications (Web Services, other new protocols) rather than Web sites. And those new applications are likely to specify use of an extended discovery mechanism (SRV, URI, NAPTR, etc) so that they get fault tolerance. If DANE wants to be relevant to early adopters that can form a critical mass, it is probably going to have to work with the discovery mechanism used by those Web services. The scheme I describe in ESRV mk II combines extended discovery with discovery of attributes relative to extended discovery (e.g. keys). *Phase 1:* At the start of the discovery process the query domain name is not canonical, therefore an unprefixed query is made. So if we are looking for the _http._tcp service, the query would be example.com ? GSRV As aliases must map to canonical names (no chains of aliases are allowed) the result of this initial query will be either a canonical name or name not found. If you are going to make an unprefixed query in the initial case to obtain the canonical name, you might as well put that query to work. In many cases a site is not going to require the ability to specify service attributes at any level of detail finer than the domain. If that is the case, you might as well specify the information in the first phase. In some cases a one size all solution is not going to be acceptable and the general record will advise that additional information is available for specific protocols (if manageably small) or should be requested in all cases. *Phase Two:* In phase two we have a canonical name to query on and can use prefixes. At this point we only have a service prefix, we do not have a host or port. If the domain contains a wildcard record for GSRV, there is going to be a risk of crosstalk. To avoid this we either have to be able to flag wildcard results somehow, or we should use a different RR for prefixed results. _http._srv.canonical.example.com ? ESRV Again we may be able to give the data required in this instance, or phase one may have told us to use an extended discovery mechanism such as SRV and we may want to specify additional data that is specific to the host. So the phase two response MAY indicate that discovery should continue to obtain host/port specific data . *Phase Three* We can now obtain host specific data: _http._srv._80.canonical.example.com ? ESRV This design may appear somewhat heavy for web browsing. But the main objective in the design is to support Web Services. And in Web Services we generally care more about fault tolerance than shaving a few ms of connection times. To use this approach in a Web Browsing context we would want to hand the task of performing the iterative descent to the recursive resolver so that the results can be cached and reused. On Thu, Jan 27, 2011 at 12:14 PM, Warren Kumari wrote: > Ondrej and I would like to call #1 (and #17) soon, but would like to get a > little clarification / restatement of folks views... > > When looking up TLSA records, would folk prefer querying for: > > 1: Just a hostname (mail.example.com) and pick from the returned records. > > 2: Looking up a name prefixed with a port (_443.www.example.com) or port > and proto (_443._tcp.www.example.com). > An application could optimize beyond this, but this defines what is > required to look up. > > W > > > > > On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote: > > [ Apologies to those who who may already have seen this data.] >> >> Adam Langley (who works on Chrome) has some numbers on actual DNS latency >> as seen by users of Chrome. >> >> ----- >> An experiment was conducted to help understand real world DNS latency and >> how it would affect things like TLSA.... >> >> A DNS lookup was made for RR type 13172 (taken from /dev/urandom). >> >> This data was collected from some Chrome users who opted into statistics >> gathering. >> The experiment was only enabled for Linux users and only in development >> versions of Chrome. Therefore, keep in mind that Linux users tend to have >> better network connections in general and the types of users who install >> development versions also tend to have better networks. >> >> 15,216 lookups were measured by 64-bit users and 9,516 by 32-bit users. >> For the 64-bit users: >> >> 51.3% of lookups finished in 0ms (i.e. a local cache, either the one >> within Chrome or a cache on the same LAN.) Afterwards, the curve trails off >> very slowly: >> >> 67.3% < 10ms >> 72.8% < 20ms >> 82% < 50ms >> 86.5 < 100ms >> 93% < 200ms >> 96.5 < 500ms >> 97.5 < 1000ms >> >> 0.56% of lookups didn't complete within 10 seconds (we don't have >> histogram buckets over 10 seconds). >> >> For the 32-bit users the curve is similar, but shifted to the right: >> >> 68.5% < 50ms >> 79% < 100ms >> 94% < 500ms >> >> 1.4% >= 10 seconds. >> >> ------ >> >> I think that these number are really interesting, and should be kept in >> mind when we are discussing the solutions that involve multiple DNS round >> trips... >> >> W >> >> >> On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote: >> >> I was hoping that would be able to stick to one open item at a time but >>> the discussions on #17 (Should the first doc be TLS only or try be >>> everything to everyone?) has wrapped directly to this issue, so: >>> >>> I'm opening up Issue #1 (Deal with multiple TLS-based services under one >>> domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) >>> [ Dons frock, flaps hands, twirls the incense burner three times to the >>> left, presses button to make water squirt out of daisy add releases the 12 >>> doves -- now it is official ] >>> ----- >>> Description: >>> How to deal with multiple TLS-based services running under one domain >>> name, such as a POP, IMAP, and SMTP server all running on >>> mail.example.com. >>> >>> Suggestions so far include: >>> Prefacing the host name with a service name (_pop.mail.example.com) >>> Prefacing the host name with a port number (_110.mail.example.com) >>> Returning a set of records that contain port numbers in the response. >>> SRV / ESRV >>> >>> ----- >>> >>> >>> >>> W >>> _______________________________________________ >>> keyassure mailing list >>> keyassure@ietf.org >>> https://www.ietf.org/mailman/listinfo/keyassure >>> >> >> > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e6434658ba6c70049ae808d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is not a question of prefer, it is a question of what you can get the DN= S infrastructure to do if you are not going to attempt to change the rules = or change DNSSEC.


DNS has wildcards and a= lias records (CNAME, DNAME) and they make a difference. The short version o= f the story is that if you are going to respect those constraints:

1) A prefix can only be applied to a canonical name ste= m=A0

2) It has to be possible to distinguish prefi= xed names from wildcarded records.

The other constraint is that= early adopters of DNS keying are almost certainly going to be completely n= ew applications (Web Services, other new protocols) rather than Web sites. = And those new applications are likely to specify use of an extended discove= ry mechanism (SRV, URI, NAPTR, etc) so that they get fault tolerance.

If DANE wants to be relevant to early adopters that can= form a critical mass, it is probably going to have to work with the discov= ery mechanism used by those Web services.


The scheme I describe in ESRV mk II combines extended discovery = with discovery of attributes relative to extended discovery (e.g. keys).

Phase 1:

At the star= t of the discovery process the query domain name is not canonical, therefor= e an unprefixed query is made. So if we are looking for the _http._tcp serv= ice, the query would be

example.com ? GSRV

As aliases must map to canonical names (no chains o= f aliases are allowed) the result of this initial query will be either a ca= nonical name or name not found.

If you are going to make an unprefixed query in the ini= tial case to obtain the canonical name, you might as well put that query to= work.

In many cases a site is not going to requir= e the ability to specify service attributes at any level of detail finer th= an the domain. If that is the case, you might as well specify the informati= on in the first phase.

In some cases a one size all solution is not going to b= e acceptable and the general record will advise that additional information= is available for specific protocols (if manageably small) or should be req= uested in all cases.


Phase Two:

In phase two we have a canonical name to query on and can use prefixes. = At this point we only have a service prefix, we do not have a host or port.=

If the domain contains a wildcard record for GSRV, ther= e is going to be a risk of crosstalk. To avoid this we either have to be ab= le to flag wildcard results somehow, or we should use a different RR for pr= efixed results.


Again we may be = able to give the data required in this instance, or phase one may have told= us to use an extended discovery mechanism such as SRV and we may want to s= pecify additional data that is specific to the host.

So the phase two response MAY indicate that discovery s= hould continue to obtain host/port specific data .

Phase Three

We can now obtain host specifi= c data:

_http._srv._80.canonical.example.com ? ESRV



This design may appear somewhat heavy for web browsing. Bu= t the main objective in the design is to support Web Services. And in Web S= ervices we generally care more about fault tolerance than shaving a few ms = of connection times.

To use this approach in a Web Browsing context we would= want to hand the task of performing the iterative descent to the recursive= resolver so that the results can be cached and reused.



On Thu, Jan 27, 2011 at = 12:14 PM, Warren Kumari <warren@kumari.net> wrote:
Ondrej and I would like to call #1 (and #17) soon, but would like to get a = little clarification / restatement of folks views...

When looking up TLSA records, would folk prefer querying for:

1: Just a hostname (m= ail.example.com) and pick from the returned records.

2: Looking up a name prefixed with a port (_443.www.example.com) or port and proto (_443.= _tcp.www.example.c= om).
An application could optimize beyond this, but this defines what is require= d to look up.

W




On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote:

[ Apologies to those who who may already have seen this data.]

Adam Langley (who works on Chrome) has some numbers on actual DNS latency a= s seen by users of Chrome.

-----
An experiment was conducted to help understand real world DNS latency and h= ow it would affect things like TLSA....

A DNS lookup was made for RR type 13172 (taken from /dev/urandom).

This data was collected from some Chrome users who opted into statistics ga= thering.
The experiment was only enabled for Linux users and only in development ver= sions of Chrome. Therefore, keep in mind that Linux users tend to have bett= er network connections in general and the types of users who install develo= pment versions also tend to have better networks.

15,216 lookups were measured by 64-bit users and 9,516 by 32-bit users. For= the 64-bit users:

51.3% of lookups finished in 0ms (i.e. a local cache, either the one within= Chrome or a cache on the same LAN.) Afterwards, the curve trails off very = slowly:

67.3% < 10ms
72.8% < 20ms
82% < 50ms
86.5 < 100ms
93% < 200ms
96.5 < 500ms
97.5 < 1000ms

0.56% of lookups didn't complete within 10 seconds (we don't have h= istogram buckets over 10 seconds).

For the 32-bit users the curve is similar, but shifted to the right:

68.5% < 50ms
79% < 100ms
94% < 500ms

1.4% >=3D 10 seconds.

------

I think that these number are really interesting, and should be kept in min= d when we are discussing the solutions that involve multiple DNS round trip= s...

W


On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote:

I was hoping that would be able to stick to one open item at a time but the= discussions on #17 (Should the first doc be TLS only or try be everything = to everyone?) has wrapped directly to this issue, so:

I'm opening up Issue #1 (Deal with multiple TLS-based services under on= e domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) [ Dons frock, flaps hands, twirls the incense burner three times to the lef= t, =A0presses button to make water squirt out of daisy add releases the 12 = doves -- now it is official ]
-----
Description:
How to deal with multiple TLS-based services running under one domain name,= such as a POP, IMAP, and SMTP server all running on mail.example.com.

Suggestions so far include:
Prefacing the host name with a service name (_pop.mail.example.com)
Prefacing the host name with a port number (_110.mail.example.com)
Returning a set of records that contain port numbers in the response.
SRV / ESRV

-----



W
_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure


_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e6434658ba6c70049ae808d2-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156773A6AAA for ; Fri, 28 Jan 2011 00:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98c0bF7LLi9W for ; Fri, 28 Jan 2011 00:12:27 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 687103A693F for ; Fri, 28 Jan 2011 00:12:27 -0800 (PST) Received: by wyf23 with SMTP id 23so3026573wyf.31 for ; Fri, 28 Jan 2011 00:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zi1VQooz4w4W1AE27s+6c6SOKqHjEONxTPLBWati24Q=; b=ayescNJPfWciu0COa3Ydq0jREDbK7Mkj8ZmJRRsSSd0J8IRE0SSfekUKaqskR26kN5 tC0TDO4nrs82TcI3VHEV/8Y+i9mGZMZKHwvK31Uc66dvBnZaORulYbAZY3m4XxZoiS3p WVSkT02uKI41UF2NlgTjKQEbBREBXy70m474E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rUjP+wkO7IzfAV6vEMrAKsQWnTgxOdn7UYStGvuOqa+ICXo9ICOiM/3cHNiovSN16z 6LuldWGS+hc50aIE/gqcJYC71JrOoUjsa9RUKuAbkYdqEPM3Kq+kn9+zJ0klWTlQXs7N hEeFFWgPRUFEhWq/rQA5cguu42w2PFKx48iG4= Received: by 10.227.69.203 with SMTP id a11mr2304852wbj.71.1296202532340; Fri, 28 Jan 2011 00:15:32 -0800 (PST) Received: from [10.0.0.6] ([109.67.13.102]) by mx.google.com with ESMTPS id o6sm825091wbo.3.2011.01.28.00.15.29 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 00:15:31 -0800 (PST) Message-ID: <4D427B1F.8020802@gmail.com> Date: Fri, 28 Jan 2011 10:15:27 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mrex@sap.com References: <201101280105.p0S15bFF001830@fs4113.wdf.sap.corp> In-Reply-To: <201101280105.p0S15bFF001830@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 08:12:29 -0000 Hi Martin, I completely agree. Just a note on terminology: I am confused by the terms "context sensitive" and "context free" in this setting; I think a better distinction would be between "informative" versus "restrictive" attributes. But we probably just need to spell out the individual properties, as you did in your mail. Thanks, Yaron On 01/28/2011 03:05 AM, Martin Rex wrote: > Yaron Sheffer wrote: >> >> I am fine with the idea of a limited trust anchor, relevant only for >> that specific host name. > > I think that notion of "valid for only the specific hostname" > that was used for retrieving this cert or cert hash through TLSA > under DNSSEC protection has always been silently assumed -- and > needs to / is going to be spelled out. > >> >> I am very suspicious of the "code reuse" argument. > > Me2. :) > >> I agree with you that a set of rules is needed (I assume you mean >> RP-side rules), so that the RP is not fooled into trusting unverified >> pieces of the cert. But that would only add complexity to the already >> complex cert processing code, and might end up undermining its security. >> This would not be a good thing. > > Personally, I think there is actually _nothing_ besides the public key > that can be trusted in a cert purely identified by DANE (TLSA) and > authenticated through DNSSEC. > > What should be described is which particular usage restrictions contained > in the cert should be honoured, that are _not_ sensitive to a > particular context. Any name-related attributes in a certificate > are highly context sensitive and need to be entirely ignored. > > (Mostly) context-free attributes would be > - KeyUsage > - Validity > and _maybe_ "ExtendedKeyUsage" > > -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8ED3A6BE7 for ; Thu, 27 Jan 2011 23:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.044 X-Spam-Level: X-Spam-Status: No, score=-103.044 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuYSDD4eqnGM for ; Thu, 27 Jan 2011 23:59:04 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 261A83A6BDA for ; Thu, 27 Jan 2011 23:59:03 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0S81wFJ002214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Jan 2011 09:02:00 +0100 From: Simon Josefsson To: Paul Wouters References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110128:paul@xelerance.com::JsfP15r2OKrQnJ9C:1235 X-Hashcash: 1:22:110128:warren@kumari.net::XZWJAOfRCqEFBqsT:asbS X-Hashcash: 1:22:110128:keyassure@ietf.org::jX8hhm2BrNOH3XyW:mf1W Date: Fri, 28 Jan 2011 09:01:58 +0100 In-Reply-To: (Paul Wouters's message of "Fri, 28 Jan 2011 00:14:51 -0500 (EST)") Message-ID: <87zkqlsbgp.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 07:59:06 -0000 Paul Wouters writes: > On Thu, 27 Jan 2011, Warren Kumari wrote: > >> Ondrej and I would like to call #1 (and #17) soon, but would like to >> get a little clarification / restatement of folks views... >> >> When looking up TLSA records, would folk prefer querying for: >> >> 1: Just a hostname (mail.example.com) and pick from the returned records. >> >> 2: Looking up a name prefixed with a port (_443.www.example.com) or >> port and proto (_443._tcp.www.example.com). >> An application could optimize beyond this, but this defines what is >> required to look up. > > I prefer 1, because in the majority of cases there is just one certifiate, > as people tend to use different hostnames for different services > (mail.example.com, www.example.com) I disagree, it is common to have multiple services with different certificates/key on one host -- many people access their mail server through SMTP (port 25), submission (port 587), webmail (https) and possibly other ways (I access e-mail over SSH which can use certificates as well). See my earlier post about this with real-world examples: http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html > The approach without the port and transport service modifiers are simpler and > less prone to errors. It is a good way to create a lot of frustration with sysadmins. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28B03A6910 for ; Thu, 27 Jan 2011 21:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INz+zaf3RahO for ; Thu, 27 Jan 2011 21:11:48 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 873503A6AA9 for ; Thu, 27 Jan 2011 21:11:48 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1296BC522; Fri, 28 Jan 2011 00:14:52 -0500 (EST) Date: Fri, 28 Jan 2011 00:14:51 -0500 (EST) From: Paul Wouters To: Warren Kumari In-Reply-To: <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 05:11:49 -0000 On Thu, 27 Jan 2011, Warren Kumari wrote: > Ondrej and I would like to call #1 (and #17) soon, but would like to get a > little clarification / restatement of folks views... > > When looking up TLSA records, would folk prefer querying for: > > 1: Just a hostname (mail.example.com) and pick from the returned records. > > 2: Looking up a name prefixed with a port (_443.www.example.com) or port and > proto (_443._tcp.www.example.com). > An application could optimize beyond this, but this defines what is required > to look up. I prefer 1, because in the majority of cases there is just one certifiate, as people tend to use different hostnames for different services (mail.example.com, www.example.com) In the cases people use the apex for all services, it would still likely not exceed two TLSA records (mail/smtp/pop/imap and https) Where people have very different security expectations per service, they will likely even use separate physical servers neccessitating different FQDNs. The approach without the port and transport service modifiers are simpler and less prone to errors. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AF03A6BD4 for ; Thu, 27 Jan 2011 20:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj6QOlqfnK4t for ; Thu, 27 Jan 2011 20:14:07 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 07CD53A6BD1 for ; Thu, 27 Jan 2011 20:14:06 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1296188230!25972332!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 26231 invoked from network); 28 Jan 2011 04:17:11 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-9.tower-153.messagelabs.com with SMTP; 28 Jan 2011 04:17:11 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 27 Jan 2011 23:16:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] Using trust anchor language Thread-Index: Acu+PSbNVbzruKt9TXuUcrO4OUEUjwAY7Kkg References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org><4D4182E6.1000908@vpnc.org> From: "Carl Wallace" To: "Paul Wouters" Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 04:14:07 -0000 > You might not want to do that though, and rely on DNSSEC to provide the > name, and possibly re-use the same cert for multiple domains without > needing to use wildcards or a long list of subjectAltnames. >=20 > Paul Is there no concern for backwards compatibility at all? Should folks who do not use the DANE validation approach have no means to determine if a certificate is valid and appropriate for a given site? Should folks have to learn to accept any name in a certificate validated via DANE while checking for proper names when DANE is not used? =20 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321A53A6B83 for ; Thu, 27 Jan 2011 19:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOI+q7xmBxTR for ; Thu, 27 Jan 2011 19:46:02 -0800 (PST) Received: from vimes.kumari.net (unknown [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id B0C7D3A68B8 for ; Thu, 27 Jan 2011 19:46:02 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 35A641B411F4; Thu, 27 Jan 2011 12:14:04 -0500 (EST) Message-Id: <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> From: Warren Kumari To: Warren Kumari In-Reply-To: <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Jan 2011 12:14:02 -0500 References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 03:46:04 -0000 Ondrej and I would like to call #1 (and #17) soon, but would like to get a little clarification / restatement of folks views... When looking up TLSA records, would folk prefer querying for: 1: Just a hostname (mail.example.com) and pick from the returned records. 2: Looking up a name prefixed with a port (_443.www.example.com) or port and proto (_443._tcp.www.example.com). An application could optimize beyond this, but this defines what is required to look up. W On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote: > [ Apologies to those who who may already have seen this data.] > > Adam Langley (who works on Chrome) has some numbers on actual DNS > latency as seen by users of Chrome. > > ----- > An experiment was conducted to help understand real world DNS > latency and how it would affect things like TLSA.... > > A DNS lookup was made for RR type 13172 (taken from /dev/urandom). > > This data was collected from some Chrome users who opted into > statistics gathering. > The experiment was only enabled for Linux users and only in > development versions of Chrome. Therefore, keep in mind that Linux > users tend to have better network connections in general and the > types of users who install development versions also tend to have > better networks. > > 15,216 lookups were measured by 64-bit users and 9,516 by 32-bit > users. For the 64-bit users: > > 51.3% of lookups finished in 0ms (i.e. a local cache, either the one > within Chrome or a cache on the same LAN.) Afterwards, the curve > trails off very slowly: > > 67.3% < 10ms > 72.8% < 20ms > 82% < 50ms > 86.5 < 100ms > 93% < 200ms > 96.5 < 500ms > 97.5 < 1000ms > > 0.56% of lookups didn't complete within 10 seconds (we don't have > histogram buckets over 10 seconds). > > For the 32-bit users the curve is similar, but shifted to the right: > > 68.5% < 50ms > 79% < 100ms > 94% < 500ms > > 1.4% >= 10 seconds. > > ------ > > I think that these number are really interesting, and should be kept > in mind when we are discussing the solutions that involve multiple > DNS round trips... > > W > > > On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote: > >> I was hoping that would be able to stick to one open item at a time >> but the discussions on #17 (Should the first doc be TLS only or try >> be everything to everyone?) has wrapped directly to this issue, so: >> >> I'm opening up Issue #1 (Deal with multiple TLS-based services >> under one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1) >> ) >> [ Dons frock, flaps hands, twirls the incense burner three times to >> the left, presses button to make water squirt out of daisy add >> releases the 12 doves -- now it is official ] >> ----- >> Description: >> How to deal with multiple TLS-based services running under one >> domain name, such as a POP, IMAP, and SMTP server all running on >> mail.example.com. >> >> Suggestions so far include: >> Prefacing the host name with a service name (_pop.mail.example.com) >> Prefacing the host name with a port number (_110.mail.example.com) >> Returning a set of records that contain port numbers in the response. >> SRV / ESRV >> >> ----- >> >> >> >> W >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2FF3A6B85 for ; Thu, 27 Jan 2011 19:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.476 X-Spam-Level: X-Spam-Status: No, score=-101.476 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS8HzQjSOFIM for ; Thu, 27 Jan 2011 19:11:03 -0800 (PST) Received: from vimes.kumari.net (unknown [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 406603A6B7A for ; Thu, 27 Jan 2011 19:11:03 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 4D8D91B4120E; Thu, 27 Jan 2011 16:18:16 -0500 (EST) Message-Id: <8D9C2C86-FCF4-4BEB-8F3C-56B19CDD0739@kumari.net> From: Warren Kumari To: Warren Kumari In-Reply-To: <3C237029-F48F-4838-90A2-860A1D6BFE9C@kumari.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Jan 2011 16:18:14 -0500 References: <201101242244.p0OMid74025819@fs4113.wdf.sap.corp> <3C237029-F48F-4838-90A2-860A1D6BFE9C@kumari.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 03:11:04 -0000 Hi all, I just wanted to clarify that this was not intended to be a reprimand towards Steve, Martin (or anyone else) -- I was just trying to make sure that we got clear consensus on the original question, but that may not have been clear from my tone. Apologies, W On Jan 24, 2011, at 6:35 PM, Warren Kumari wrote: > While this is an interesting thread (and demonstrates the need for > this), I was wondering if we could try and return to the original > question.... > > For a while it looked like we were getting somewhere on that, but I > think that we have drifted sufficiently off course that a gentle > nudge is in order... > > So, . > > W > > On Jan 24, 2011, at 5:44 PM, Martin Rex wrote: > >> Stephen Kent wrote: >>> >>>> The original design behind SSL was the real world. An extremely >>>> weak server endpoint identification was considered good enough, >>>> which is why hardly anyone appears to have security concerns >>>> about a TLS X.509 PKI with a set of ~60 independent TAs that >>>> bootstrap trust to like ~600 seperately operated, omnipotent CAs, >>>> providing server admins a choice of functionally equivalent >>>> server certs over a very broad price range. >>> >>> I don't think I agree with your characterization of the "original >>> design" rationale. Long ago there were many fewer TAs in browsers, >>> and the power shifted between CAs and browser vendors over time. I >>> served as CTO for a major CA in the mid-90's, so I recall what >>> things >>> were like then. >> >> Netscape 3.01 (~1996) already had 16 independent rootCA certs. >> (just looked at it -- yup, I still got one of those around). >> >> I remember that around year 2000, >> >> Thawte sold regular server certs a USD 100 and wildcard certs at >> USD 400, >> and if you paid for 2 years in advance, you could get a server cert >> with 2 years lifetime. >> >> while VeriSign wanted USD 700 for a regular server cert and didn't >> offer any wildcard certs at all. >> >> >> So both, the multiple independent rootCA certs and the widely varying >> prices are really pretty old stuff. >> >> -Martin >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > -- > The plural of anecdote is not evidence. > -- Bill Lockyer, California Attorney General > > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFC43A69F5 for ; Thu, 27 Jan 2011 17:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n19wr2vi-d3L for ; Thu, 27 Jan 2011 17:02:53 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 1DDCD3A6A0D for ; Thu, 27 Jan 2011 17:02:52 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0S15dFD024263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jan 2011 02:05:39 +0100 (MET) From: Martin Rex Message-Id: <201101280105.p0S15bFF001830@fs4113.wdf.sap.corp> To: yaronf.ietf@gmail.com (Yaron Sheffer) Date: Fri, 28 Jan 2011 02:05:37 +0100 (MET) In-Reply-To: <4D42003C.8060904@gmail.com> from "Yaron Sheffer" at Jan 28, 11 01:31:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 01:02:54 -0000 Yaron Sheffer wrote: > > I am fine with the idea of a limited trust anchor, relevant only for > that specific host name. I think that notion of "valid for only the specific hostname" that was used for retrieving this cert or cert hash through TLSA under DNSSEC protection has always been silently assumed -- and needs to / is going to be spelled out. > > I am very suspicious of the "code reuse" argument. Me2. :) > I agree with you that a set of rules is needed (I assume you mean > RP-side rules), so that the RP is not fooled into trusting unverified > pieces of the cert. But that would only add complexity to the already > complex cert processing code, and might end up undermining its security. > This would not be a good thing. Personally, I think there is actually _nothing_ besides the public key that can be trusted in a cert purely identified by DANE (TLSA) and authenticated through DNSSEC. What should be described is which particular usage restrictions contained in the cert should be honoured, that are _not_ sensitive to a particular context. Any name-related attributes in a certificate are highly context sensitive and need to be entirely ignored. (Mostly) context-free attributes would be - KeyUsage - Validity and _maybe_ "ExtendedKeyUsage" -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94F03A68AA for ; Thu, 27 Jan 2011 15:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNvrOWi74Rl1 for ; Thu, 27 Jan 2011 15:28:11 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 85A553A69D6 for ; Thu, 27 Jan 2011 15:28:08 -0800 (PST) Received: by wyf23 with SMTP id 23so2713282wyf.31 for ; Thu, 27 Jan 2011 15:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6jpoC9RChQqm2D0+8TazGEsb+OteodqUhRXMPU+X//c=; b=QgP3vMyBnAeCTCoR95cBZvy0qF3DDsmmV4jrryGresveOyh3d6YcduNLU0M83uAkNR c1clrUYShauN+rEhkqHYHSr4EI6VYLm1qq6QONzJeugRJCpefVPduwGTGM+ytHumqbc6 86ShlMlR+ZvJKOkUDtAO3aAX2rqtvAMMs0MrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TvXEKXD68f51oUHuh/7sTAcL3fyYuCKGd0eepQldQPkSluM74UvR3tiNK92FAxf7UX jNV9M/go9A5u6unHzXC1KUrIHbYS3s4nehejAsxB8XUNctN7PR+CTXkvqRYJZhwiGpxd vzlIpjmF8JrZiHkwJnkuE/dU2y/TUt2kjJsK0= Received: by 10.227.161.13 with SMTP id p13mr1857138wbx.164.1296171072627; Thu, 27 Jan 2011 15:31:12 -0800 (PST) Received: from [10.0.0.6] ([109.67.13.102]) by mx.google.com with ESMTPS id w25sm1153855wbd.11.2011.01.27.15.31.10 (version=SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 15:31:12 -0800 (PST) Message-ID: <4D42003C.8060904@gmail.com> Date: Fri, 28 Jan 2011 01:31:08 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephen Kent References: <4D411362.9000407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 23:28:13 -0000 Hi Steve, I am fine with the idea of a limited trust anchor, relevant only for that specific host name. I am very suspicious of the "code reuse" argument. I agree with you that a set of rules is needed (I assume you mean RP-side rules), so that the RP is not fooled into trusting unverified pieces of the cert. But that would only add complexity to the already complex cert processing code, and might end up undermining its security. This would not be a good thing. Can you please explain (informally) what stuff in the cert can be trusted by the RP, other than the public key? For example, if the cert contains some future X.509 extension ("the Subject's eyes are blue") - should it be trusted by the RP as applying to the TLS endpoint? And lastly, referring to your other email, can you please be more specific about the domain name constraints, i.e. what exact part of the SIDR spec you propose that we adopt here? Thanks, Yaron On 01/27/2011 05:56 PM, Stephen Kent wrote: > At 8:40 AM +0200 1/27/11, Yaron Sheffer wrote: >> Hi Paul, >> >> if earlier I was confused, now I am extremely worried. It seems to me >> than with the goal of simplifying the protocol, you are removing all >> remnants of operational security. >> >> If the DNS registrar signs anything more than the public key, in >> particular if it signs the Subject or Subject Alt Name on a >> certificate, and if we specify explicitly that this cert is to be used >> as a trust anchor, then the registrar acts as a CA. So, like it or >> not, it needs to play by CA rules. >> >> If all you sign is the public key, and if you mandate that the cert >> MUST only be associated with a particular FQDN and the RP MUST ignore >> non-key material, then we can relax these rules. I think this is the >> path we should follow if we are to provide a credible, yet secure, >> alternative to PKI. >> >> I am well aware of the failings of commercial PKI. But trying to >> replace them by a scheme that offers even less security doesn't make >> sense to me. >> >> More below. >> >> Yaron > > Yaron, > > I agree that we have to be careful in the design that DANE adopts, to avoid > undermining the current level of security offered for TLS. I think this > can be done safely with either a "bare" key or a cert as the contents of > the signed record. An advantage of using a cert is that it might be > easier to make use of the rest of the TLS cert processing software, > i.e., minimize the impact of using DNS. For example, we could require > that the cert contain a SAN of the form DNSname, and mandate checks to > ensure that the SAN is consistent with the > DNS context from which it was acquired (he said, imprecisely). > > I disagree that the client (RP) needs to ignore everything in a cert > acquired > in this fashion. If we impose appropriate rules, we can make this safe. > I view the rules as a form of pre-processing applied to the cert before > accepting it for use, e.g., as a TA. > > Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D210128C186 for ; Thu, 27 Jan 2011 13:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.15 X-Spam-Level: X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyJmbq+CCJPS for ; Thu, 27 Jan 2011 13:13:34 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A870628C17D for ; Thu, 27 Jan 2011 13:13:33 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0RLGXh4010946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jan 2011 22:16:33 +0100 (MET) From: Martin Rex Message-Id: <201101272116.p0RLGWuV017884@fs4113.wdf.sap.corp> To: asteingruebl@paypal-inc.com (Steingruebl Andy) Date: Thu, 27 Jan 2011 22:16:32 +0100 (MET) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB1A2F1A36@DEN-MEXMS-001.corp.ebay.com> from "Steingruebl, Andy" at Jan 27, 11 11:13:57 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:13:34 -0000 Steingruebl, Andy wrote: > > > From: Stephen Kent [mailto:kent@bbn.com] > > > > Sorry for being dense, but can you explain how the SNI extension and IP > > exhaustion relate to the issue of extracting a DNS name from a cert vs. > > inferring it from the DNS record? > > Ordinarily, in order to host multiple TLS-endpoints (web virtual hosting) on a single-IP, you have two choices: > > 1. A cert with multiple SANs > 2. use SNI so a client can indicate which end-endpoint (hostname) it is trying to reach. > > #1 is extremely problematic when virtual-hosting services for different entities, or lots of entities. For example, CDNs will often try to virtual a number of websites at the same IP, and will have a certificate with SANs that span a multitude of organizations/businesses. > > #2 is problematic because SNI isn't supported in Windows-XP. > > Currently, #1 or a single-IP per "website/hostname" is required. > > With TLSA if we don't have to embed the hostname in the certificate > offered during the TLS handshake, we don't care about SNI if a > client supports TLSA. Now, what client will support TLSA and not > SNI, well, that's why this isn't really that big a deal I suppose.. Conceptually, there _is_ a significant difference. (see last sentence of section 1 of every TLS spec in existence). Support for DANE/TLSA could be added entirely at the app layer without a single change to the underlying TLS implementation. The use of SNI, on the other hand, has the inevitable prerequisite that the underlying TLS implementation itself must support it. So for implementations running on top of Windows SChannel, supporting DANE/TLSA is conceivable even for Windows XP and completely independent of what Microsoft does. This applies to _all_ environments with currently extrension-free TLS implementations (WinXP is probably the single largest example, but there are _many_ more such environments&devices). In some environments, there may be dozens or even hundreds of virtual hosts on the same IPv4-address, and having to re-issue a cert everytime a virtual host is added or removed would be a real problem without SNI. Having a self-signed server cert change every few weeks sounds like a very bad idea, because it precludes clients from sensible "pinning" of server certs as a means to improve trust through memorizing prior experience. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67423A691B for ; Thu, 27 Jan 2011 10:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.301 X-Spam-Level: X-Spam-Status: No, score=-8.301 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-97+vKBywmL for ; Thu, 27 Jan 2011 10:12:36 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id B0CD33A681F for ; Thu, 27 Jan 2011 10:12:36 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=QfnAXelGMs2/De0U5zltQxjUNOiozG2xr3nIWZvf9QlpHBX0VEr4nxpl Xu4H1PZAMrEJoWHOZLY4GTqKPiYqpAPjdU52uGvzO70QnsAt5Vt7952fH ibkESPpjfqf0luR; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1296152141; x=1327688141; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Stephen=20Kent=20|CC:=20Paul=20 Wouters=20,=20"keyassure@ietf.org"=0D =0A=09|Date:=20Thu,=2027=20Jan=202011 =2011:13:57=20-0700|Subject:=20RE:=20[keyassure]=20Using =20trust=20anchor=20language|Message-ID:=20<5EE049BA3C653 8409BBE6F1760F328ABEB1A2F1A36@DEN-MEXMS-001.corp.ebay.com >|References:=20=0D=0A=20<4D404B76.7010702@gmail.com>=20<4D4052C8. 3060308@vpnc.org>=0D=0A=20=0D=0A=20<4D4182E6.1000908 @vpnc.org>=20=0D =0A=20=0D=0A=20 =0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB1A2F19B2@DEN- MEXMS-001.corp.ebay.com>=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quoted-printab le|MIME-Version:=201.0; bh=Z3QMXRe5d02r5eqNZCU/CipI2pzT2+TGyBXnJUtAI3I=; b=aapioOQ4NKOMYR0kx+tP/AILSye4oMhtBhr7D/fYcOlqUYacgeQLD7qq HL6uEQXvaTCscmAyMWaYsg5IIDtNjUjmJHbjtBG6rWiiuGfyosT2M7X23 Nx8Knxi0aSdu9Rh; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,387,1291622400"; d="scan'208";a="486270" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 27 Jan 2011 10:15:40 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Thu, 27 Jan 2011 11:13:59 -0700 From: "Steingruebl, Andy" To: Stephen Kent Date: Thu, 27 Jan 2011 11:13:57 -0700 Thread-Topic: [keyassure] Using trust anchor language Thread-Index: Acu+SlVeuNGcV3B0TV6MjtWcY8V1ggAAve4w Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB1A2F1A36@DEN-MEXMS-001.corp.ebay.com> References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> <4D4182E6.1000908@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB1A2F19B2@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: ibY3gl8VZ3/BnPOXCTNJLw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 18:12:37 -0000 > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] >=20 > Sorry for being dense, but can you explain how the SNI extension and IP > exhaustion relate to the issue of extracting a DNS name from a cert vs. > inferring it from the DNS record? Ordinarily, in order to host multiple TLS-endpoints (web virtual hosting) o= n a single-IP, you have two choices: 1. A cert with multiple SANs 2. use SNI so a client can indicate which end-endpoint (hostname) it is try= ing to reach. #1 is extremely problematic when virtual-hosting services for different ent= ities, or lots of entities. For example, CDNs will often try to virtual a = number of websites at the same IP, and will have a certificate with SANs th= at span a multitude of organizations/businesses. #2 is problematic because SNI isn't supported in Windows-XP. Currently, #1 or a single-IP per "website/hostname" is required. With TLSA if we don't have to embed the hostname in the certificate offered= during the TLS handshake, we don't care about SNI if a client supports TLS= A. Now, what client will support TLSA and not SNI, well, that's why this i= sn't really that big a deal I suppose.. - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A95B3A69B1 for ; Thu, 27 Jan 2011 09:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XADX-tGhlFuA for ; Thu, 27 Jan 2011 09:44:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BFF023A681F for ; Thu, 27 Jan 2011 09:44:51 -0800 (PST) Received: from [192.1.255.194] (port=49202) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiVwo-000IDM-Mj; Thu, 27 Jan 2011 12:47:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB1A2F19B2@DEN-MEXMS-001.corp.ebay.com> References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> <4D4182E6.1000908@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB1A2F19B2@DEN-MEXMS-001.corp.ebay.com> Date: Thu, 27 Jan 2011 12:47:30 -0500 To: "Steingruebl, Andy" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:44:53 -0000 At 10:28 AM -0700 1/27/11, Steingruebl, Andy wrote: > > -----Original Message----- >> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On >> Behalf Of Stephen Kent >> >> Paul, >> >> My understanding has been that the primary motivation for wild cards in web >> site certs was to avoid the need to pay for multiple certs. Since we are >> avoiding that concern here, and since one could even choose to put the >> same key in multiple certs, each with a different name, what is the major >> concern over putting a DNS name in a cert? It's not hard to >>generate multiple >> certs, e.g., one per site. > >A model that doesn't require a name embedded in the cert allows us >to get wider TLS deployment without IP exhaustion without requiring >SNI. For what that is worth. > >- Andy Andy, Sorry for being dense, but can you explain how the SNI extension and IP exhaustion relate to the issue of extracting a DNS name from a cert vs. inferring it from the DNS record? Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32263A6944 for ; Thu, 27 Jan 2011 09:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.273 X-Spam-Level: X-Spam-Status: No, score=-8.273 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cdKtENFvrwg for ; Thu, 27 Jan 2011 09:25:21 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id B930E3A696E for ; Thu, 27 Jan 2011 09:25:20 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=tSNnupNme17bLbLUasXIY7CURwAqBNcQsN/UzqnPZH4HWlJsCcEY3Otv p30M3W+WqcIKKFFymfjuISnf8Okg3FXgfmuNthzg2hGJ8cloCt5zaoHkk 0bNYClpfx3pjf81; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1296149305; x=1327685305; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Stephen=20Kent=20,=20Paul=20Wou ters=20|CC:=20"keyassure@ietf.org"=20 |Date:=20Thu,=2027=20Jan=202011=2010: 28:22=20-0700|Subject:=20RE:=20[keyassure]=20Using=20trus t=20anchor=20language|Message-ID:=20<5EE049BA3C6538409BBE 6F1760F328ABEB1A2F19B2@DEN-MEXMS-001.corp.ebay.com> |References:=20=0D=0A=09<4D404B76.7010702@gmail.com>=20<4D4052C8.3 060308@vpnc.org>=0D=0A=09=0D=0A=09<4D4182E6.1000908@ vpnc.org>=20=0D=0A =09=0D=0A=20 |In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=tZFaQw8bS320yggE+7J4U4NesJL2AzdnC73V4EhoKnA=; b=G4vBCDY1xGuD2gYvKOVz59e7/JdG6Qivy0Zq9JN8gfxmjkiMm+QONE3P kJTGjN48FSTYxZAvkOGHZ4mqIUQcKCmIeL4onO6VDBJXitO0ZKNsLO+Kh 7fnwya2IKyFCx/x; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,386,1291622400"; d="scan'208";a="485010" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 27 Jan 2011 09:28:24 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Thu, 27 Jan 2011 10:28:24 -0700 From: "Steingruebl, Andy" To: Stephen Kent , Paul Wouters Date: Thu, 27 Jan 2011 10:28:22 -0700 Thread-Topic: [keyassure] Using trust anchor language Thread-Index: Acu+RQl4bzCGAXDwT1q77IRTFeJn2gAAk+5A Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB1A2F19B2@DEN-MEXMS-001.corp.ebay.com> References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> <4D4182E6.1000908@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: Jp77u31CBCbfsKb9nlLJKQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:25:24 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Stephen Kent >=20 > Paul, >=20 > My understanding has been that the primary motivation for wild cards in w= eb > site certs was to avoid the need to pay for multiple certs. Since we are > avoiding that concern here, and since one could even choose to put the > same key in multiple certs, each with a different name, what is the major > concern over putting a DNS name in a cert? It's not hard to generate mult= iple > certs, e.g., one per site. A model that doesn't require a name embedded in the cert allows us to get w= ider TLS deployment without IP exhaustion without requiring SNI. For what = that is worth. - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A22728C14B for ; Thu, 27 Jan 2011 09:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXDQhPHf4QtK for ; Thu, 27 Jan 2011 09:06:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 221F828C14C for ; Thu, 27 Jan 2011 09:06:52 -0800 (PST) Received: from [192.1.255.194] (port=49196) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiVM3-0003TQ-Tp; Thu, 27 Jan 2011 12:09:56 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> <4D4182E6.1000908@vpnc.org> Date: Thu, 27 Jan 2011 12:01:11 -0500 To: Paul Wouters From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:06:53 -0000 At 11:13 AM -0500 1/27/11, Paul Wouters wrote: >On Thu, 27 Jan 2011, Stephen Kent wrote: > >>>Arrrgh. I apologize for assuming that folks understand the use of >>>limited trust anchors, given that most of us are used to trust >>>anchors with unlimited power. This is a trust anchor *only* for >>>this host name. Words to that effect needs to be added, and needs >>>to be a MUST. >> >>You might note how to effect this, in a PKI-compliant fashion,. e.g., by >>associating name constraints for the FQDN with the cert. Carl >>Wallace's I-D on TA constraints provides one example of how to do >>this, as does the local TA management I-D now in SIDR (only a tiny >>part of that functionality would be needed here). > >You might not want to do that though, and rely on DNSSEC to provide the name, >and possibly re-use the same cert for multiple domains without needing to >use wildcards or a long list of subjectAltnames. > >Paul Paul, My understanding has been that the primary motivation for wild cards in web site certs was to avoid the need to pay for multiple certs. Since we are avoiding that concern here, and since one could even choose to put the same key in multiple certs, each with a different name, what is the major concern over putting a DNS name in a cert? It's not hard to generate multiple certs, e.g., one per site. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640763A67F4 for ; Thu, 27 Jan 2011 08:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzbPUNvAF7ZK for ; Thu, 27 Jan 2011 08:10:10 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8939D3A67D3 for ; Thu, 27 Jan 2011 08:10:10 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 41BB3BF8B; Thu, 27 Jan 2011 11:13:13 -0500 (EST) Date: Thu, 27 Jan 2011 11:13:12 -0500 (EST) From: Paul Wouters To: Stephen Kent In-Reply-To: Message-ID: References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> <4D4182E6.1000908@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 16:10:12 -0000 On Thu, 27 Jan 2011, Stephen Kent wrote: >> Arrrgh. I apologize for assuming that folks understand the use of limited >> trust anchors, given that most of us are used to trust anchors with >> unlimited power. This is a trust anchor *only* for this host name. Words to >> that effect needs to be added, and needs to be a MUST. > > You might note how to effect this, in a PKI-compliant fashion,. e.g., by > associating name constraints for the FQDN with the cert. Carl Wallace's I-D > on TA constraints provides one example of how to do this, as does the local > TA management I-D now in SIDR (only a tiny part of that functionality would > be needed here). You might not want to do that though, and rely on DNSSEC to provide the name, and possibly re-use the same cert for multiple domains without needing to use wildcards or a long list of subjectAltnames. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E753A682A for ; Thu, 27 Jan 2011 07:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfJMV2FFgcyI for ; Thu, 27 Jan 2011 07:53:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 393403A67ED for ; Thu, 27 Jan 2011 07:53:20 -0800 (PST) Received: from [192.1.255.194] (port=49191) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiUCt-000G6w-Gv; Thu, 27 Jan 2011 10:56:23 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D411362.9000407@gmail.com> References: <4D411362.9000407@gmail.com> Date: Thu, 27 Jan 2011 10:56:17 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:53:21 -0000 At 8:40 AM +0200 1/27/11, Yaron Sheffer wrote: >Hi Paul, > >if earlier I was confused, now I am extremely worried. It seems to >me than with the goal of simplifying the protocol, you are removing >all remnants of operational security. > >If the DNS registrar signs anything more than the public key, in >particular if it signs the Subject or Subject Alt Name on a >certificate, and if we specify explicitly that this cert is to be >used as a trust anchor, then the registrar acts as a CA. So, like it >or not, it needs to play by CA rules. > >If all you sign is the public key, and if you mandate that the cert >MUST only be associated with a particular FQDN and the RP MUST >ignore non-key material, then we can relax these rules. I think this >is the path we should follow if we are to provide a credible, yet >secure, alternative to PKI. > >I am well aware of the failings of commercial PKI. But trying to >replace them by a scheme that offers even less security doesn't make >sense to me. > >More below. > > Yaron Yaron, I agree that we have to be careful in the design that DANE adopts, to avoid undermining the current level of security offered for TLS. I think this can be done safely with either a "bare" key or a cert as the contents of the signed record. An advantage of using a cert is that it might be easier to make use of the rest of the TLS cert processing software, i.e., minimize the impact of using DNS. For example, we could require that the cert contain a SAN of the form DNSname, and mandate checks to ensure that the SAN is consistent with the DNS context from which it was acquired (he said, imprecisely). I disagree that the client (RP) needs to ignore everything in a cert acquired in this fashion. If we impose appropriate rules, we can make this safe. I view the rules as a form of pre-processing applied to the cert before accepting it for use, e.g., as a TA. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B851F3A6900 for ; Thu, 27 Jan 2011 07:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.395 X-Spam-Level: X-Spam-Status: No, score=-102.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8pLbQY-UqxM for ; Thu, 27 Jan 2011 07:38:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D90FE3A68ED for ; Thu, 27 Jan 2011 07:38:23 -0800 (PST) Received: from [192.1.255.194] (port=49189) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiTyR-0001zh-7L; Thu, 27 Jan 2011 10:41:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D4182E6.1000908@vpnc.org> References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> <4D4182E6.1000908@vpnc.org> Date: Thu, 27 Jan 2011 10:04:22 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 15:38:24 -0000 At 6:36 AM -0800 1/27/11, Paul Hoffman wrote: >On 1/26/11 9:12 AM, Zack Weinberg wrote: >>On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman wrote: >>... >>>Every TLS client has its own rules for what to do with each individual trust >>>anchor. Most TLS clients have the policy that "anything that chains to any >>>trust anchor I have is allowed", but that policy is not mandated anywhere. >>>More careful TLS clients will have more careful policies. Our protocol >>>should not force a careless policy on anyone. >>... >>>The policy for these four types is "treat them as a trust anchor". I'm not >>>sure how to make that any clearer. >> >>Precisely because of what you say in the first paragraph I've quoted, >>I think DANE needs to be more specific about appropriate client policy >>than "treat [a certificate with a valid TLSA record] as a trust >>anchor". >> >>At the very least, I think we need language to the effect that a >>certificate with a TLSA record SHOULD NOT be promoted to trust anchor >>for any certificate chain other than the one received from the server >>at the domain name where the TLSA record appears. (Possibly even MUST >>NOT.) (I may have my PKIX/TLS terminology all wrong, but I hope my >>meaning is clear.) > >Arrrgh. I apologize for assuming that folks understand the use of >limited trust anchors, given that most of us are used to trust >anchors with unlimited power. This is a trust anchor *only* for this >host name. Words to that effect needs to be added, and needs to be a >MUST. You might note how to effect this, in a PKI-compliant fashion,. e.g., by associating name constraints for the FQDN with the cert. Carl Wallace's I-D on TA constraints provides one example of how to do this, as does the local TA management I-D now in SIDR (only a tiny part of that functionality would be needed here). Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FCE3A684E for ; Thu, 27 Jan 2011 06:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.739 X-Spam-Level: X-Spam-Status: No, score=-101.739 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anW3q7rkdew1 for ; Thu, 27 Jan 2011 06:33:18 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8B13C3A67EF for ; Thu, 27 Jan 2011 06:33:18 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0REaLCC058188 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Jan 2011 07:36:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D4182E6.1000908@vpnc.org> Date: Thu, 27 Jan 2011 06:36:22 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:33:19 -0000 On 1/26/11 9:12 AM, Zack Weinberg wrote: > On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman wrote: > ... >> Every TLS client has its own rules for what to do with each individual trust >> anchor. Most TLS clients have the policy that "anything that chains to any >> trust anchor I have is allowed", but that policy is not mandated anywhere. >> More careful TLS clients will have more careful policies. Our protocol >> should not force a careless policy on anyone. > ... >> The policy for these four types is "treat them as a trust anchor". I'm not >> sure how to make that any clearer. > > Precisely because of what you say in the first paragraph I've quoted, > I think DANE needs to be more specific about appropriate client policy > than "treat [a certificate with a valid TLSA record] as a trust > anchor". > > At the very least, I think we need language to the effect that a > certificate with a TLSA record SHOULD NOT be promoted to trust anchor > for any certificate chain other than the one received from the server > at the domain name where the TLSA record appears. (Possibly even MUST > NOT.) (I may have my PKIX/TLS terminology all wrong, but I hope my > meaning is clear.) Arrrgh. I apologize for assuming that folks understand the use of limited trust anchors, given that most of us are used to trust anchors with unlimited power. This is a trust anchor *only* for this host name. Words to that effect needs to be added, and needs to be a MUST. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C4E3A67AA for ; Thu, 27 Jan 2011 04:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89kyBVPuRNkO for ; Thu, 27 Jan 2011 04:49:00 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id DC2D23A67A6 for ; Thu, 27 Jan 2011 04:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=qebUn3UIybrw0jG6ohC+MCQKeqrU/oTrmBvnrjRYinI=; b=NRzKqhBIGaY0wB+5dHLo1UpGLV9PHjKzOqQzN0wMt2bDNwsyw7KqM1ZfEcS/eTy81NOQpw6B8fC7R 0KLyGhOmcbjJf3f9uBTlQrK1jMPZrsJNboSxUlfhS+Hjl+dzHwQ0lgMhf87KuPvSURUcADdWlsfe1h Ltv4q2APgoLTk4f0= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Thu, 27 Jan 2011 13:52:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4D411362.9000407@gmail.com> Date: Thu, 27 Jan 2011 13:51:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27BF6A4C-C668-404D-ABA7-97633F3EDEF2@kirei.se> References: <4D411362.9000407@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 12:49:01 -0000 On 27 jan 2011, at 07.40, Yaron Sheffer wrote: > If the DNS registrar signs anything more than the public key, in = particular if it signs the Subject or Subject Alt Name on a certificate, = and if we specify explicitly that this cert is to be used as a trust = anchor, then the registrar acts as a CA. So, like it or not, it needs to = play by CA rules. With "DNS registrar" I assume you mean the person responsible for = editing the DNS information. In the DNS world, the registrar is actually = the organization registering new domains names in a DNS registry on = behalf of the registrant - e.g., Godaddy is a registrar. I suggest we = use the term "DNS administrator" instead. > If all you sign is the public key, and if you mandate that the cert = MUST only be associated with a particular FQDN and the RP MUST ignore = non-key material, then we can relax these rules. I think this is the = path we should follow if we are to provide a credible, yet secure, = alternative to PKI. The DNS administrator will sign the whole TLSA resource record (RR) - a = cert or just a hash of a cert. Even though the whole RR is signed, the = DANE specification can still mandate that the client should ignore the = hostname part of the cert. Given this, I can generate a self-signed = certificate with CN=3Dwww.paypal.com and publishing it as a TLSA RR as = www.kirei.se. My DNS administrator doesn't need to understand what's in = the TLSA RR - he/she just has to publish whatever I submit. The = selective ignore part is all on the RP side. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1141C3A6AF6 for ; Wed, 26 Jan 2011 22:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRkGqXSZjzJc for ; Wed, 26 Jan 2011 22:37:36 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 414893A6AED for ; Wed, 26 Jan 2011 22:37:36 -0800 (PST) Received: by wwa36 with SMTP id 36so2026736wwa.13 for ; Wed, 26 Jan 2011 22:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KVsG6uthCx3Ei+MG8yoTHvjPiRSM0bEY1fiPyER/Bgo=; b=K+Oaz4QBwsoqqDB7Ukbtbw3bO6jzUdy+1LIt+zSot3Y6sQ2jREzKsxifWyp+VzBVlh 6km+5dFRxa8SDsXDWx62fXO+H6S00tnW1HmJRMu9+F3DZ5EdS50X9YV1+ilyxEAjkCYD V90QoPFiGsnCHX4XUNhMJA9QIaWNRNJWsIhTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=DEPNSgKsYQi1JROL7Mw5dWhoXEB0sW8wOatmL5VO7eZ5wv46kSOp3T5Le+ODNCmF2Q Ybc16iTYv/YcuQW3f2U1aSWkVBDjz7AXOr4A6PLk7fvSRc8CNa2qxC3eUb+V48ZkKnWW nAQ+jjZyQ8EzkKpE7vuGPOeQ/MMGTd4g+rcJQ= Received: by 10.227.183.13 with SMTP id ce13mr537983wbb.187.1296110438356; Wed, 26 Jan 2011 22:40:38 -0800 (PST) Received: from [10.0.0.6] ([109.66.6.142]) by mx.google.com with ESMTPS id f35sm11554849wbf.20.2011.01.26.22.40.36 (version=SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 22:40:37 -0800 (PST) Message-ID: <4D411362.9000407@gmail.com> Date: Thu, 27 Jan 2011 08:40:34 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 06:37:40 -0000 Hi Paul, if earlier I was confused, now I am extremely worried. It seems to me than with the goal of simplifying the protocol, you are removing all remnants of operational security. If the DNS registrar signs anything more than the public key, in particular if it signs the Subject or Subject Alt Name on a certificate, and if we specify explicitly that this cert is to be used as a trust anchor, then the registrar acts as a CA. So, like it or not, it needs to play by CA rules. If all you sign is the public key, and if you mandate that the cert MUST only be associated with a particular FQDN and the RP MUST ignore non-key material, then we can relax these rules. I think this is the path we should follow if we are to provide a credible, yet secure, alternative to PKI. I am well aware of the failings of commercial PKI. But trying to replace them by a scheme that offers even less security doesn't make sense to me. More below. Yaron > Date: Wed, 26 Jan 2011 08:58:48 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] Using trust anchor language > To: keyassure@ietf.org > Message-ID:<4D4052C8.3060308@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/26/11 8:27 AM, Yaron Sheffer wrote: >> Hi Paul, >> >> I am extremely confused by the wording of the new draft, and my >> confusion is even more exacerbated by your clarification below :-) >> Please help me! >> >> Quoting the new text in full: >> >> Items received in TLSA resource records can be treated like trust >> anchors by the TLS client. The trust anchor MUST NOT be loaded for >> longer than the TTL on the TSLA record. >> >> I have three issues with this text: >> >> First, the text is imprecise. In some of the cases there are no >> "items received". The RP received a hash of a cert, and that cert is >> in fact what we want treated as a trust anchor. > > Now I'm the one confused. If the TLS client received a hash of a cert > (either type 1 or type 3), then they received an item. > Yes, but the object that asserts a claim ("I am THIS subject, and I am the holder of THIS public key") is the cert itself, not its hash. >> Second, we use a lower-case "can" for a critical process. A compliant >> Relying Party SHOULD/MUST use these RRs as trust anchors. > > Not at all. RFC 2119 has specific uses, and none of them apply here > (unless the WG wants to make such an assertion). Your proposal would > force a security policy on someone who, for example, just wanted to know > whether or not a site had a TLSA record. > This is plain nonsense. Of course someone can be playing games. We are talking of someone using TLSA for the purpose for which TLSA was established, i.e. to set up a secure TLS connection. And you ARE defining a security policy by saying these certs are to be used as trust anchors. >> And third, the way I understand "trust anchor" is you should trust it >> blindly, like you trust all those 60 certs in your browser. (I am >> not talking of enterprise/government cases, but of the other 99.9% of >> the world). > > Every TLS client has its own rules for what to do with each individual > trust anchor. Most TLS clients have the policy that "anything that > chains to any trust anchor I have is allowed", but that policy is not > mandated anywhere. More careful TLS clients will have more careful > policies. Our protocol should not force a careless policy on anyone. > So we are in complete agreement. I would like to focus on the 99.9% of the world who do not have fancy policies and will take you at your world: use these certs as trust anchors. We need to specify a *reasonable* secure policy for such clients. What we have now is not reasonable. >> Does this mean the RP should not even try to validate the cert? > > Correct: that is the definition of a trust anchor. > No wonder. I consulted RFC 4949 before posting :-) >> If this is so, we should make the certificate trustworthy. Here's a >> set of tentative rules: >> >> - The DNS registrar MUST have access to the certificate at the time it >> generate the TLSA record. > > There is no such thing as a "DNS registrar". Please choose a phrase that > exists. Also, what does "have access" mean? > Please don't nitpick, Wikipedia seems to understand what I mean: http://en.wikipedia.org/wiki/Domain_name_registrar). "Have access" means: "can read and validate it". >> - The registrar MUST ensure that the certificate is valid, and/or must >> validate any non-key information included in the certificate. > > This makes no sense for a self-signed end-entity certificate. How can > one validate such a certificate? > True. For self-signed certs, the Registrar needs to verify that the non-key information is correct. Like, call you on the phone to make sure you exist. Yes, just like a traditional CA. >> - In particular the registrar MUST ensure that the certificate does not >> refer to any DNS address outside of that registrar's scope of authority. > > By "DNS address" I assume you mean "host name". What is the problem with > any of the four types defined so far referring to a host name outside > the "scope of authority" (whatever that is)? These are being used ad > trust anchors. > You are telling the RP to add the cert as a trust anchor. Then you are saying I can have my certs include DNS:vpnc.org as a Subject Alt Name, and any RP will happily accept them. >> - The registrar MUST establish a Certificate Practice Statement (CPS) >> and make it publicly available. > > Why would an entity that does not issue certificates need a CPS? > It doesn't generate the cert. But it effectively signs it. So yes, it "issues" a certificate. >> I have a feeling this is NOT what you meant. But I fail to understand >> exactly what security policy we now assume. > > The policy for these four types is "treat them as a trust anchor". I'm > not sure how to make that any clearer. > > It is only too clear now. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BD23A690B for ; Wed, 26 Jan 2011 09:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwRTBVZ8buNf for ; Wed, 26 Jan 2011 09:09:49 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C12653A6824 for ; Wed, 26 Jan 2011 09:09:48 -0800 (PST) Received: by wwa36 with SMTP id 36so1309519wwa.13 for ; Wed, 26 Jan 2011 09:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PKgG+rcF7gBJTW/W1oOMFwpSuUluo/TfdYwhT9k8xbY=; b=gtVYx3XIcwrL5GcV/rgXzx+WR68W5uq0jLHDUw2htLUYxssoEbDU6ZKOZ+LvH6gPA9 4Oig8RzQq5sqT7yN+Qys6tPfMN9t73nxSArueFab3TStySBUBSQnhf2uSyWXY49NpTK5 jTs0MkOUFvH4gPgFRA5P643EdAuY4GueN+mmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=hYOwMc05cO7vOhj7tv6OIox67lk2TbbS3oHTzb9HcD3ezD6Lc0+HYf9KC4q/Jtf1DH UI5kLiKXVZoE7LV1HjidOCnRor01A6QYJQ0acnunhV4DghrWqL0nWM+6SaE94f0yyxny rI3ZEHe3SCO9ELkETOxJZRKKJYJap1K/eB14U= MIME-Version: 1.0 Received: by 10.227.137.85 with SMTP id v21mr7792176wbt.157.1296061969186; Wed, 26 Jan 2011 09:12:49 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.152.145 with HTTP; Wed, 26 Jan 2011 09:12:48 -0800 (PST) In-Reply-To: <4D4052C8.3060308@vpnc.org> References: <4D404B76.7010702@gmail.com> <4D4052C8.3060308@vpnc.org> Date: Wed, 26 Jan 2011 09:12:48 -0800 X-Google-Sender-Auth: sK21j2EicNoOyM2ahTtSyuG3Shg Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 17:09:49 -0000 On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman wrote: ... > Every TLS client has its own rules for what to do with each individual trust > anchor. Most TLS clients have the policy that "anything that chains to any > trust anchor I have is allowed", but that policy is not mandated anywhere. > More careful TLS clients will have more careful policies. Our protocol > should not force a careless policy on anyone. ... > The policy for these four types is "treat them as a trust anchor". I'm not > sure how to make that any clearer. Precisely because of what you say in the first paragraph I've quoted, I think DANE needs to be more specific about appropriate client policy than "treat [a certificate with a valid TLSA record] as a trust anchor". At the very least, I think we need language to the effect that a certificate with a TLSA record SHOULD NOT be promoted to trust anchor for any certificate chain other than the one received from the server at the domain name where the TLSA record appears. (Possibly even MUST NOT.) (I may have my PKIX/TLS terminology all wrong, but I hope my meaning is clear.) zw Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85C43A6804 for ; Wed, 26 Jan 2011 08:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.046 X-Spam-Level: X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYgjphC9TfEE for ; Wed, 26 Jan 2011 08:55:57 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CA12B3A6814 for ; Wed, 26 Jan 2011 08:55:57 -0800 (PST) Received: from host1841695244.direcway.com (host1841695244.direcway.com [184.169.5.244] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0QGwnVv001044 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 26 Jan 2011 09:58:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D4052C8.3060308@vpnc.org> Date: Wed, 26 Jan 2011 08:58:48 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D404B76.7010702@gmail.com> In-Reply-To: <4D404B76.7010702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:55:58 -0000 On 1/26/11 8:27 AM, Yaron Sheffer wrote: > Hi Paul, > > I am extremely confused by the wording of the new draft, and my > confusion is even more exacerbated by your clarification below :-) > Please help me! > > Quoting the new text in full: > > Items received in TLSA resource records can be treated like trust > anchors by the TLS client. The trust anchor MUST NOT be loaded for > longer than the TTL on the TSLA record. > > I have three issues with this text: > > First, the text is imprecise. In some of the cases there are no > "items received". The RP received a hash of a cert, and that cert is > in fact what we want treated as a trust anchor. Now I'm the one confused. If the TLS client received a hash of a cert (either type 1 or type 3), then they received an item. > Second, we use a lower-case "can" for a critical process. A compliant > Relying Party SHOULD/MUST use these RRs as trust anchors. Not at all. RFC 2119 has specific uses, and none of them apply here (unless the WG wants to make such an assertion). Your proposal would force a security policy on someone who, for example, just wanted to know whether or not a site had a TLSA record. > And third, the way I understand "trust anchor" is you should trust it > blindly, like you trust all those 60 certs in your browser. (I am > not talking of enterprise/government cases, but of the other 99.9% of > the world). Every TLS client has its own rules for what to do with each individual trust anchor. Most TLS clients have the policy that "anything that chains to any trust anchor I have is allowed", but that policy is not mandated anywhere. More careful TLS clients will have more careful policies. Our protocol should not force a careless policy on anyone. > Does this mean the RP should not even try to validate the cert? Correct: that is the definition of a trust anchor. > If this is so, we should make the certificate trustworthy. Here's a > set of tentative rules: > > - The DNS registrar MUST have access to the certificate at the time it > generate the TLSA record. There is no such thing as a "DNS registrar". Please choose a phrase that exists. Also, what does "have access" mean? > - The registrar MUST ensure that the certificate is valid, and/or must > validate any non-key information included in the certificate. This makes no sense for a self-signed end-entity certificate. How can one validate such a certificate? > - In particular the registrar MUST ensure that the certificate does not > refer to any DNS address outside of that registrar's scope of authority. By "DNS address" I assume you mean "host name". What is the problem with any of the four types defined so far referring to a host name outside the "scope of authority" (whatever that is)? These are being used ad trust anchors. > - The registrar MUST establish a Certificate Practice Statement (CPS) > and make it publicly available. Why would an entity that does not issue certificates need a CPS? > I have a feeling this is NOT what you meant. But I fail to understand > exactly what security policy we now assume. The policy for these four types is "treat them as a trust anchor". I'm not sure how to make that any clearer. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54C0F3A67D6 for ; Wed, 26 Jan 2011 08:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CF0zxUtKBvg for ; Wed, 26 Jan 2011 08:25:34 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0EF283A6836 for ; Wed, 26 Jan 2011 08:25:33 -0800 (PST) Received: by fxm9 with SMTP id 9so1218089fxm.31 for ; Wed, 26 Jan 2011 08:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RLXj8bk7VXpL/QjcvSBOakiQD7JMN6pxnR2Ifm4+ff4=; b=kPOA5GUx4OVVv+l1buXjFjH7/q3lwqaxP8uhIIG8Hn7eBdKKkzEmGxa9ohpGfUZsNl Hk1phaeU3qTqziqA2cHvmirj7JWqXzhxJyY2PWCKtfiKDw+6fzL0W6hxGtUiDOViNtzA maSyrndz4rt+63u3ZYt5tEo9ts0mk4NAOzMHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=B7wbRmvT1Nj0hownH8bkIT3jrTofWryNy3+rtlY3PahgZZzFvWcz8VqKd1PyT7OTvG /4yQK1LHuyREkyqquAb8uc9wIkU0TonzNvUfgWVdmnBL6DYMqVN+AW06Ni8dM/1smrxz LXvY9WNLPtagRlEf1Ho31MYb69u9zVQVbs7zw= Received: by 10.223.72.9 with SMTP id k9mr8368157faj.93.1296059259222; Wed, 26 Jan 2011 08:27:39 -0800 (PST) Received: from [192.168.2.184] (bzq-79-181-11-139.red.bezeqint.net [79.181.11.139]) by mx.google.com with ESMTPS id y3sm5584940fai.14.2011.01.26.08.27.37 (version=SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 08:27:38 -0800 (PST) Message-ID: <4D404B76.7010702@gmail.com> Date: Wed, 26 Jan 2011 18:27:34 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Using trust anchor language X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 16:25:35 -0000 Hi Paul, I am extremely confused by the wording of the new draft, and my confusion is even more exacerbated by your clarification below :-) Please help me! Quoting the new text in full: Items received in TLSA resource records can be treated like trust anchors by the TLS client. The trust anchor MUST NOT be loaded for longer than the TTL on the TSLA record. I have three issues with this text: First, the text is imprecise. In some of the cases there are no "items received". The RP received a hash of a cert, and that cert is in fact what we want treated as a trust anchor. Second, we use a lower-case "can" for a critical process. A compliant Relying Party SHOULD/MUST use these RRs as trust anchors. And third, the way I understand "trust anchor" is you should trust it blindly, like you trust all those 60 certs in your browser. (I am not talking of enterprise/government cases, but of the other 99.9% of the world). Does this mean the RP should not even try to validate the cert? If this is so, we should make the certificate trustworthy. Here's a set of tentative rules: - The DNS registrar MUST have access to the certificate at the time it generate the TLSA record. - The registrar MUST ensure that the certificate is valid, and/or must validate any non-key information included in the certificate. - In particular the registrar MUST ensure that the certificate does not refer to any DNS address outside of that registrar's scope of authority. - The registrar MUST establish a Certificate Practice Statement (CPS) and make it publicly available. I have a feeling this is NOT what you meant. But I fail to understand exactly what security policy we now assume. Thanks, Yaron > Date: Tue, 25 Jan 2011 11:59:00 -0800 > From: Paul Hoffman > Subject: [keyassure] Using trust anchor language: > draft-ietf-dane-protocol-03.txt > To: "keyassure@ietf.org" > Message-ID:<4D3F2B84.1090205@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Greetings again. There was not an open issue on how TLSA deals with > non-key information in PKIX certificates, but Phill had brought up > strong reservations and Steve Kent responded. There was then a longish > thread on alternatives, but Jakob and I had never clarified the > document. Thus, we put out -03 with some proposed wording that should > make clear that the keys in certificate associations are trust anchors. > The side effect of making that clear is that we could wipe out all the > wishy-washy stuff from the old 3.1. > > The diffs are at > . > > If folks are happy with this clarification, it will close some of the > open issues that were spurred by the language in 3.1. > > --Paul Hoffman > > > ------------------------------ > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > End of keyassure Digest, Vol 6, Issue 38 > **************************************** Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7E63A6916 for ; Tue, 25 Jan 2011 19:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP1CNwzGPZmv for ; Tue, 25 Jan 2011 19:48:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A77053A6910 for ; Tue, 25 Jan 2011 19:48:02 -0800 (PST) Received: from [128.89.255.39] (port=59020 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PhwPN-000Grv-IT; Tue, 25 Jan 2011 22:51:01 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4D3F2B84.1090205@vpnc.org> Date: Tue, 25 Jan 2011 22:50:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D37C130-1A31-403B-BF58-A6BD6D1F4520@bbn.com> References: <4D3F2B84.1090205@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Using trust anchor language: draft-ietf-dane-protocol-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 03:48:03 -0000 Paul, This wording looks good to me. Very clear. --Richard On Jan 25, 2011, at 2:59 PM, Paul Hoffman wrote: > Greetings again. There was not an open issue on how TLSA deals with = non-key information in PKIX certificates, but Phill had brought up = strong reservations and Steve Kent responded. There was then a longish = thread on alternatives, but Jakob and I had never clarified the = document. Thus, we put out -03 with some proposed wording that should = make clear that the keys in certificate associations are trust anchors. = The side effect of making that clear is that we could wipe out all the = wishy-washy stuff from the old 3.1. >=20 > The diffs are at = . >=20 > If folks are happy with this clarification, it will close some of the = open issues that were spurred by the language in 3.1. >=20 > --Paul Hoffman > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008193A6860 for ; Tue, 25 Jan 2011 11:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdNAUaFOCh0C for ; Tue, 25 Jan 2011 11:56:03 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5365B3A6838 for ; Tue, 25 Jan 2011 11:56:03 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0PJx1ZR046421 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 12:59:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3F2B84.1090205@vpnc.org> Date: Tue, 25 Jan 2011 11:59:00 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "keyassure@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [keyassure] Using trust anchor language: draft-ietf-dane-protocol-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:56:04 -0000 Greetings again. There was not an open issue on how TLSA deals with non-key information in PKIX certificates, but Phill had brought up strong reservations and Steve Kent responded. There was then a longish thread on alternatives, but Jakob and I had never clarified the document. Thus, we put out -03 with some proposed wording that should make clear that the keys in certificate associations are trust anchors. The side effect of making that clear is that we could wipe out all the wishy-washy stuff from the old 3.1. The diffs are at . If folks are happy with this clarification, it will close some of the open issues that were spurred by the language in 3.1. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E707E3A6894; Tue, 25 Jan 2011 11:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-ATz1sYVDsN; Tue, 25 Jan 2011 11:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF0C3A688D; Tue, 25 Jan 2011 11:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110125194502.6885.78390.idtracker@localhost> Date: Tue, 25 Jan 2011 11:45:02 -0800 Cc: keyassure@ietf.org Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-03.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For TLS Author(s) : P. Hoffman, J. Schlyter Filename : draft-ietf-dane-protocol-03.txt Pages : 10 Date : 2011-01-25 TLS and DTLS use certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certification authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dane-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-25113937.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2333A6853 for ; Tue, 25 Jan 2011 11:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5B3zko7XSK1 for ; Tue, 25 Jan 2011 11:23:05 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 2F1253A6852 for ; Tue, 25 Jan 2011 11:23:05 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9B4F52284AD3; Tue, 25 Jan 2011 14:26:02 -0500 (EST) Message-Id: <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> From: Warren Kumari To: Warren Kumari In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Jan 2011 14:26:00 -0500 References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:23:06 -0000 [ Apologies to those who who may already have seen this data.] Adam Langley (who works on Chrome) has some numbers on actual DNS latency as seen by users of Chrome. ----- An experiment was conducted to help understand real world DNS latency and how it would affect things like TLSA.... A DNS lookup was made for RR type 13172 (taken from /dev/urandom). This data was collected from some Chrome users who opted into statistics gathering. The experiment was only enabled for Linux users and only in development versions of Chrome. Therefore, keep in mind that Linux users tend to have better network connections in general and the types of users who install development versions also tend to have better networks. 15,216 lookups were measured by 64-bit users and 9,516 by 32-bit users. For the 64-bit users: 51.3% of lookups finished in 0ms (i.e. a local cache, either the one within Chrome or a cache on the same LAN.) Afterwards, the curve trails off very slowly: 67.3% < 10ms 72.8% < 20ms 82% < 50ms 86.5 < 100ms 93% < 200ms 96.5 < 500ms 97.5 < 1000ms 0.56% of lookups didn't complete within 10 seconds (we don't have histogram buckets over 10 seconds). For the 32-bit users the curve is similar, but shifted to the right: 68.5% < 50ms 79% < 100ms 94% < 500ms 1.4% >= 10 seconds. ------ I think that these number are really interesting, and should be kept in mind when we are discussing the solutions that involve multiple DNS round trips... W On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote: > I was hoping that would be able to stick to one open item at a time > but the discussions on #17 (Should the first doc be TLS only or try > be everything to everyone?) has wrapped directly to this issue, so: > > I'm opening up Issue #1 (Deal with multiple TLS-based services under > one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) > [ Dons frock, flaps hands, twirls the incense burner three times to > the left, presses button to make water squirt out of daisy add > releases the 12 doves -- now it is official ] > ----- > Description: > How to deal with multiple TLS-based services running under one > domain name, such as a POP, IMAP, and SMTP server all running on > mail.example.com. > > Suggestions so far include: > Prefacing the host name with a service name (_pop.mail.example.com) > Prefacing the host name with a port number (_110.mail.example.com) > Returning a set of records that contain port numbers in the response. > SRV / ESRV > > ----- > > > > W > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3695A3A69B8 for ; Mon, 24 Jan 2011 15:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVvc8iH9MUui for ; Mon, 24 Jan 2011 15:32:06 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id ECEC93A6995 for ; Mon, 24 Jan 2011 15:32:05 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 259BA2284A39; Mon, 24 Jan 2011 18:35:01 -0500 (EST) Message-Id: <3C237029-F48F-4838-90A2-860A1D6BFE9C@kumari.net> From: Warren Kumari To: mrex@sap.com In-Reply-To: <201101242244.p0OMid74025819@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Jan 2011 18:35:00 -0500 References: <201101242244.p0OMid74025819@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:32:07 -0000 While this is an interesting thread (and demonstrates the need for this), I was wondering if we could try and return to the original question.... For a while it looked like we were getting somewhere on that, but I think that we have drifted sufficiently off course that a gentle nudge is in order... So, . W On Jan 24, 2011, at 5:44 PM, Martin Rex wrote: > Stephen Kent wrote: >> >>> The original design behind SSL was the real world. An extremely >>> weak server endpoint identification was considered good enough, >>> which is why hardly anyone appears to have security concerns >>> about a TLS X.509 PKI with a set of ~60 independent TAs that >>> bootstrap trust to like ~600 seperately operated, omnipotent CAs, >>> providing server admins a choice of functionally equivalent >>> server certs over a very broad price range. >> >> I don't think I agree with your characterization of the "original >> design" rationale. Long ago there were many fewer TAs in browsers, >> and the power shifted between CAs and browser vendors over time. I >> served as CTO for a major CA in the mid-90's, so I recall what things >> were like then. > > Netscape 3.01 (~1996) already had 16 independent rootCA certs. > (just looked at it -- yup, I still got one of those around). > > I remember that around year 2000, > > Thawte sold regular server certs a USD 100 and wildcard certs at USD > 400, > and if you paid for 2 years in advance, you could get a server cert > with 2 years lifetime. > > while VeriSign wanted USD 700 for a regular server cert and didn't > offer any wildcard certs at all. > > > So both, the multiple independent rootCA certs and the widely varying > prices are really pretty old stuff. > > -Martin > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- The plural of anecdote is not evidence. -- Bill Lockyer, California Attorney General Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC91F3A69AF for ; Mon, 24 Jan 2011 14:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDVrRx++daXa for ; Mon, 24 Jan 2011 14:42:34 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id E54793A6932 for ; Mon, 24 Jan 2011 14:42:33 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0OMifAZ008736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jan 2011 23:44:41 +0100 (MET) From: Martin Rex Message-Id: <201101242244.p0OMid74025819@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Mon, 24 Jan 2011 23:44:39 +0100 (MET) In-Reply-To: from "Stephen Kent" at Jan 24, 11 04:26:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:42:35 -0000 Stephen Kent wrote: > > >The original design behind SSL was the real world. An extremely > >weak server endpoint identification was considered good enough, > >which is why hardly anyone appears to have security concerns > >about a TLS X.509 PKI with a set of ~60 independent TAs that > >bootstrap trust to like ~600 seperately operated, omnipotent CAs, > >providing server admins a choice of functionally equivalent > >server certs over a very broad price range. > > I don't think I agree with your characterization of the "original > design" rationale. Long ago there were many fewer TAs in browsers, > and the power shifted between CAs and browser vendors over time. I > served as CTO for a major CA in the mid-90's, so I recall what things > were like then. Netscape 3.01 (~1996) already had 16 independent rootCA certs. (just looked at it -- yup, I still got one of those around). I remember that around year 2000, Thawte sold regular server certs a USD 100 and wildcard certs at USD 400, and if you paid for 2 years in advance, you could get a server cert with 2 years lifetime. while VeriSign wanted USD 700 for a regular server cert and didn't offer any wildcard certs at all. So both, the multiple independent rootCA certs and the widely varying prices are really pretty old stuff. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0870E3A6AF5 for ; Mon, 24 Jan 2011 13:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxDCrZg79Q6L for ; Mon, 24 Jan 2011 13:23:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E943028C0D8 for ; Mon, 24 Jan 2011 13:23:31 -0800 (PST) Received: from dhcp89-089-102.bbn.com ([128.89.89.102]:49201) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PhTvc-000If0-Sf; Mon, 24 Jan 2011 16:26:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101211645.p0LGjqVu023472@fs4113.wdf.sap.corp> References: <201101211645.p0LGjqVu023472@fs4113.wdf.sap.corp> Date: Mon, 24 Jan 2011 16:26:21 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:23:33 -0000 At 5:45 PM +0100 1/21/11, Martin Rex wrote: >... > >Several protocol are in a poor shape because early implementations >were "liberal in what they accept"ed far beyond reasonable levels. I a very much in agreement with your observation that, in the secruity space, Jon's pithy sound bite is often the wrong thing to do. > > If one tries to use an offered path, life can become more complex, > > and, in this example, an unnecessary validation failure occurs. > >If all that it takes to build a cert path, for which a full cert >path validation can be performed, is to ignore certs at >the end of the original/given certs path, then there certainly >is a bug in the code doing the cert path validation. I can imagine an implementer just taking whatever is offered by the other end and plugging it into the local path validation code. if if fails, the RP give up. Also, if the server offered a list of TAs to which it could validate, then there is a sort of shared responsibility here The client should have sent a path that it knows terminates at one of those TAs, if it knows the TAs. Of course, if the client does not know, it's not clear if sending just the EE cert is better than sending a path. >Cross-cert scenarios are pretty messy, and there seem to be some >very unresponsible approaches a cert path validation out in the wild, >like automatic/silent AIA-chasing. Path building in a cross-certified environment is complex, period. Note that PKIX does not standardize path building, only path validation. Path building is covered by an informational RFC. >The straight-forward way for making cert path validation work >in cross certification scenarios is to distribute cross-certs >as trust anchors. that does make life easier, but it may not always be practical. > > Thanks for reminding me of the server->client TA list. I agree that > > if the client send a path that terminates at one of those TAs, the >> server SHOULD accept it. But, isn't this an example of asymmetry in >> TLS, i.e., the client has no analogous capability to let he server >> know what set of TAs it will accept. So there is still a problem when >> one tries to use TLS as a peer secruity protocol, as opposed to the >> client/server model that is common for most public web site access. > >For the big majority of TLS servers, this is not a problem. They have >just one single credential/cert anyway, and if that doesn't work, there >would not be a way to handshake around this problem. agreed, but that does support my observation about the asymmetry here. >The "Server Name Indication" is an existing TLS extension intended >to help the server select a suitable server credential, for servers >that have more than one available. So for situations, where the >server needs to know which TAs the client has available to verify >the servers cert path, the obvious solution would be to define >another TLS extension to convey this information and have the >client include it in the ClientHello handshake message. that would make the exchange more symmetric re cert oath info. >For SSL/TLS, announcing the "standard" list of TAs from the >TLS X.509 PKI is very undesirable. There are simply too >many of them (~60), and when stuffing those into ClientHello, >the size of the ClientHello would increase from typically <100 >octets today to >16 KByte, requiring a fragmentation of ClientHello >(which a lot of implementations will break on, although it has >always been a MUST support feature since SSLv3), and might >incur a penalty from TCP slow start, besides wasting a lot >of network bandwidth (on average). agreed. it would not be useful to send all of them. >The original design behind SSL was the real world. An extremely >weak server endpoint identification was considered good enough, >which is why hardly anyone appears to have security concerns >about a TLS X.509 PKI with a set of ~60 independent TAs that >bootstrap trust to like ~600 seperately operated, omnipotent CAs, >providing server admins a choice of functionally equivalent >server certs over a very broad price range. I don't think I agree with your characterization of the "original design" rationale. Long ago there were many fewer TAs in browsers, and the power shifted between CAs and browser vendors over time. I served as CTO for a major CA in the mid-90's, so I recall what things were like then. >For TLS client certs, if they're used at all, the most reasonable and >most manageable setup is when the server admin (organization) issues >those themselves, similar to the membership plastic cards that inhabit >everybodies wallets. And then, the announcement of the trusted CAs >by the server when asking for the client cert is somewhat similar >to the logos at the door of businesses which plastic cards they >will accept from clients. agreed. see my MILCOM paper from 1997 "How Many CAs are Enough?" (or Google the title and find PPT slides based on the paper :-)) Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E154E3A6A4D for ; Fri, 21 Jan 2011 08:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.868 X-Spam-Level: X-Spam-Status: No, score=-9.868 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULSDSnFSv1Hr for ; Fri, 21 Jan 2011 08:43:12 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A508B3A6A47 for ; Fri, 21 Jan 2011 08:43:11 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0LGjrXk026865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jan 2011 17:45:53 +0100 (MET) From: Martin Rex Message-Id: <201101211645.p0LGjqVu023472@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Fri, 21 Jan 2011 17:45:52 +0100 (MET) In-Reply-To: from "Stephen Kent" at Jan 21, 11 10:38:55 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 16:43:13 -0000 Stephen Kent wrote: > > > > >But the entity should expect that the reciepient checks the _offered_path_, > >even when the recipient uses a different path for acutal certificate > >path validation, and therefore entities should refrain from sending > >a path that they themselves can easily determine to be invalid. > > I disagree. The only path that is relevant to an RP is the one that > the RP chooses to employ for cert validation. I'm sorry, I did not mean to imply a duty for the receipient to perform cert path validation on the original path. But any assumption on the side of the sender, to throw garbage at the server in a security protocol and expect the server to simply ignore anything that doesn't fit a very clear and explicit protocol specification, would be totally flawed. Several protocol are in a poor shape because early implementations were "liberal in what they accept"ed far beyond reasonable levels. > > If one tries to use an offered path, life can become more complex, > and, in this example, an unnecessary validation failure occurs. If all that it takes to build a cert path, for which a full cert path validation can be performed, is to ignore certs at the end of the original/given certs path, then there certainly is a bug in the code doing the cert path validation. Cross-cert scenarios are pretty messy, and there seem to be some very unresponsible approaches a cert path validation out in the wild, like automatic/silent AIA-chasing. The straight-forward way for making cert path validation work in cross certification scenarios is to distribute cross-certs as trust anchors. > > Thanks for reminding me of the server->client TA list. I agree that > if the client send a path that terminates at one of those TAs, the > server SHOULD accept it. But, isn't this an example of asymmetry in > TLS, i.e., the client has no analogous capability to let he server > know what set of TAs it will accept. So there is still a problem when > one tries to use TLS as a peer secruity protocol, as opposed to the > client/server model that is common for most public web site access. For the big majority of TLS servers, this is not a problem. They have just one single credential/cert anyway, and if that doesn't work, there would not be a way to handshake around this problem. The "Server Name Indication" is an existing TLS extension intended to help the server select a suitable server credential, for servers that have more than one available. So for situations, where the server needs to know which TAs the client has available to verify the servers cert path, the obvious solution would be to define another TLS extension to convey this information and have the client include it in the ClientHello handshake message. For SSL/TLS, announcing the "standard" list of TAs from the TLS X.509 PKI is very undesirable. There are simply too many of them (~60), and when stuffing those into ClientHello, the size of the ClientHello would increase from typically <100 octets today to >16 KByte, requiring a fragmentation of ClientHello (which a lot of implementations will break on, although it has always been a MUST support feature since SSLv3), and might incur a penalty from TCP slow start, besides wasting a lot of network bandwidth (on average). The original design behind SSL was the real world. An extremely weak server endpoint identification was considered good enough, which is why hardly anyone appears to have security concerns about a TLS X.509 PKI with a set of ~60 independent TAs that bootstrap trust to like ~600 seperately operated, omnipotent CAs, providing server admins a choice of functionally equivalent server certs over a very broad price range. For TLS client certs, if they're used at all, the most reasonable and most manageable setup is when the server admin (organization) issues those themselves, similar to the membership plastic cards that inhabit everybodies wallets. And then, the announcement of the trusted CAs by the server when asking for the client cert is somewhat similar to the logos at the door of businesses which plastic cards they will accept from clients. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805783A6A21 for ; Fri, 21 Jan 2011 07:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZqKQX3CqW1H for ; Fri, 21 Jan 2011 07:39:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 576F23A6A20 for ; Fri, 21 Jan 2011 07:39:40 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48715 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PgJ84-0005Tx-RT; Fri, 21 Jan 2011 10:42:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101211442.p0LEgc1l016413@fs4113.wdf.sap.corp> References: <201101211442.p0LEgc1l016413@fs4113.wdf.sap.corp> Date: Fri, 21 Jan 2011 10:38:55 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 15:39:41 -0000 At 3:42 PM +0100 1/21/11, Martin Rex wrote: >Stephen Kent wrote: >> > >> >This really isn't a client-server issue, since both sides have a need >> >to, when necessary, authenticate themselves to the other. Like anything >> >communicating over IP we should think of each side as a peer. >> >> Sorry, I should have used more precise terminology. Each relying >> party gets to choose its TAs. The entity offering a cert is free to >> propose a TA (or a cert path terminating at a TA) to the other end, >> but it cannot mandate that the RP use that path. > >But the entity should expect that the reciepient checks the _offered_path_, >even when the recipient uses a different path for acutal certificate >path validation, and therefore entities should refrain from sending >a path that they themselves can easily determine to be invalid. I disagree. The only path that is relevant to an RP is the one that the RP chooses to employ for cert validation. If one tries to use an offered path, life can become more complex, and, in this example, an unnecessary validation failure occurs. > > I know that the server can send a cert path to the client, > > but does TLS support the client sending other than an EE cert to the >> server? > >In TLS, when the server explicitly requests a client certificate, >then the client must either indicate that it does not have a >(suitable) client cert, or the client MUST send the FULL cert path. >Only the the self-signed cert at the end of the path may be omitted. > http://tools.ietf.org/html/rfc2246#page-39 > >Since the TLS Server is supposed to (in SSLv3&TLSv1.0 the server MUST) >announce the certificate signers that it trusts, when it requests a >client certificate, one may argue that sending a client certificate >with cert path up to at least one of the trusted signers, as announced >by the server, should be OK. Thanks for reminding me of the server->client TA list. I agree that if the client send a path that terminates at one of those TAs, the server SHOULD accept it. But, isn't this an example of asymmetry in TLS, i.e., the client has no analogous capability to let he server know what set of TAs it will accept. So there is still a problem when one tries to use TLS as a peer secruity protocol, as opposed to the client/server model that is common for most public web site access. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE563A6A18 for ; Fri, 21 Jan 2011 07:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPEm2ySYzOZh for ; Fri, 21 Jan 2011 07:39:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 241223A696E for ; Fri, 21 Jan 2011 07:39:37 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48715 helo=[192.168.1.12]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PgJ82-0005Tx-0b; Fri, 21 Jan 2011 10:42:22 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> Date: Fri, 21 Jan 2011 10:28:17 -0500 To: Geoff Beier From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 15:39:38 -0000 At 7:21 PM -0500 1/20/11, Geoff Beier wrote: >On Thu, Jan 20, 2011 at 17:38, Stephen Kent wrote: >> Also, of course, TLS is NOT a peer protocol; the >> protocol distinguishes between client and server. I know that the server >> can send a cert path to the client, but does TLS support the client sending >> other than an EE cert to the server? In contrast, I believe IKEv2 does > >TLS does support this. From RFC 5246, section 7.4.6: > >"This message conveys the client's certificate chain to the server; >the server will use it when verifying the CertificateVerify message" > >I've seen interoperability problems when the client sends a >certification path that the server does not trust even though the >server could build an alternative path using certificates in its own >trust store. For example: > >Client's trust store contains Root A. Root A has issued a cert to CA >B, which has issued a cert to CA C. The server sends CA C in the hint >list. The client then sends its EE cert along with CA C, CA B and Root >A in the Client Certificate message. The server's trust store contains >root D, which has issued a cert to CA C. The server then rejects the >client because the path the client sent doesn't terminate in root D, >even though it should have enough information to trust the EE cert >based on the cert its own trust anchor issued. > >That's a little hard to explain but isn't hypothetical at all. I've >seen it in the wild. It comes about because people are much more >likely to have narrowed their server's trust store than their >client's, and some cert processing libraries have been known to prefer >longer certification paths over shorter ones when choosing from >multiple possible paths. > >Geoff Geoff, Thanks for the clarification. Your example points out the complexity that arises when one entity offers more than just an EE cert to authenticate itself, and the RP receiving the cert path has to decide how to handle it. rejecting the path even when the RP could have validated the EE cert, via another path, is something we ought to try to avoid. I believe IKE has encountered analogous problems. DANE needs to ask whether it makes sense to send a cert path, vs. just an EE cert, given the potential for confusion, or whether we need to mandate more sophisticated processing for RPs, so that we avoid this sort of problem. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6295E3A69E1 for ; Fri, 21 Jan 2011 06:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.168 X-Spam-Level: X-Spam-Status: No, score=-10.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48+53mpIo0mu for ; Fri, 21 Jan 2011 06:42:27 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id F11A03A69DC for ; Fri, 21 Jan 2011 06:42:26 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0LEgdlk006987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jan 2011 15:42:39 +0100 (MET) From: Martin Rex Message-Id: <201101211442.p0LEgc1l016413@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Fri, 21 Jan 2011 15:42:38 +0100 (MET) In-Reply-To: from "Stephen Kent" at Jan 20, 11 05:38:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 14:42:28 -0000 Stephen Kent wrote: > > > >This really isn't a client-server issue, since both sides have a need > >to, when necessary, authenticate themselves to the other. Like anything > >communicating over IP we should think of each side as a peer. > > Sorry, I should have used more precise terminology. Each relying > party gets to choose its TAs. The entity offering a cert is free to > propose a TA (or a cert path terminating at a TA) to the other end, > but it cannot mandate that the RP use that path. But the entity should expect that the reciepient checks the _offered_path_, even when the recipient uses a different path for acutal certificate path validation, and therefore entities should refrain from sending a path that they themselves can easily determine to be invalid. > > I know that the server can send a cert path to the client, > but does TLS support the client sending other than an EE cert to the > server? In TLS, when the server explicitly requests a client certificate, then the client must either indicate that it does not have a (suitable) client cert, or the client MUST send the FULL cert path. Only the the self-signed cert at the end of the path may be omitted. http://tools.ietf.org/html/rfc2246#page-39 Since the TLS Server is supposed to (in SSLv3&TLSv1.0 the server MUST) announce the certificate signers that it trusts, when it requests a client certificate, one may argue that sending a client certificate with cert path up to at least one of the trusted signers, as announced by the server, should be OK. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749EE3A688A for ; Thu, 20 Jan 2011 16:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3K55HgkJb8U for ; Thu, 20 Jan 2011 16:19:26 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 56E053A6884 for ; Thu, 20 Jan 2011 16:19:26 -0800 (PST) Received: by wyf23 with SMTP id 23so1285205wyf.31 for ; Thu, 20 Jan 2011 16:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+xCbAEY2EBIVosI+NvuFilKBsMZpmCfk9W1BxZ3ab6Q=; b=ts5m+gbuVWxd6ZkgsnOBEpbylooXN9kQqtKnaFhUCqU2CQO502CFQJ/gUnmVzWdfaR b+ExEvUJqWjQucGtwMuR4kqMUXo0jqNUAsD6uVEqEWVYr2S7i9aOOn2Re/zpzI+cRJKt q9O1vKcCoMvgIb+42697UR3vr7oTLasdHjO0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=I+4OV3FV6JlL2PPpjFQVaQYZ01A+MmwHWjnBudy+TMIVRZOOLXXxbQjW83756QsYV5 t3xVcIt5w63iCcEN39xw3DsC9B389Q7L59Jmpigv0BTFlxttNVep016R4iBzh5JsWH7Y cIfnFM9D7KFVTSGUNvN7T+cTlP35uEJ6/NvnQ= Received: by 10.227.179.141 with SMTP id bq13mr3160219wbb.149.1295569329612; Thu, 20 Jan 2011 16:22:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.168.7 with HTTP; Thu, 20 Jan 2011 16:21:49 -0800 (PST) In-Reply-To: References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> From: Geoff Beier Date: Thu, 20 Jan 2011 19:21:49 -0500 Message-ID: To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 00:19:27 -0000 On Thu, Jan 20, 2011 at 17:38, Stephen Kent wrote: > Also, of course, TLS is NOT a peer protocol; the > protocol distinguishes between client and server. =A0I know that the serv= er > can send a cert path to the client, but does TLS support the client sendi= ng > other than an EE cert to the server? =A0In contrast, I believe IKEv2 does TLS does support this. From RFC 5246, section 7.4.6: "This message conveys the client's certificate chain to the server; the server will use it when verifying the CertificateVerify message" I've seen interoperability problems when the client sends a certification path that the server does not trust even though the server could build an alternative path using certificates in its own trust store. For example: Client's trust store contains Root A. Root A has issued a cert to CA B, which has issued a cert to CA C. The server sends CA C in the hint list. The client then sends its EE cert along with CA C, CA B and Root A in the Client Certificate message. The server's trust store contains root D, which has issued a cert to CA C. The server then rejects the client because the path the client sent doesn't terminate in root D, even though it should have enough information to trust the EE cert based on the cert its own trust anchor issued. That's a little hard to explain but isn't hypothetical at all. I've seen it in the wild. It comes about because people are much more likely to have narrowed their server's trust store than their client's, and some cert processing libraries have been known to prefer longer certification paths over shorter ones when choosing from multiple possible paths. Geoff Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86F13A6858 for ; Thu, 20 Jan 2011 14:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7mXSwRE+Y6c for ; Thu, 20 Jan 2011 14:35:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BD6903A682F for ; Thu, 20 Jan 2011 14:35:25 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49304) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pg38r-000LoH-FS; Thu, 20 Jan 2011 17:38:09 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> Date: Thu, 20 Jan 2011 17:38:07 -0500 To: James Cloos From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 22:35:26 -0000 At 5:33 PM -0500 1/18/11, James Cloos wrote: > >>>>> "SK" == Stephen Kent writes: > >>> One possible usage of DANE would be to limit which specific CAs from >>> those considered valid CAs under the TLS X.509 PKI, are also valid >>> signers for a particular server or a particular DNS domain. > >SK> I understand the attraction for this notion, but it does conflict >SK> with the concept that, ultimately, the client (software) gets to >SK> make decisions of this sort. > >This really isn't a client-server issue, since both sides have a need >to, when necessary, authenticate themselves to the other. Like anything >communicating over IP we should think of each side as a peer. Sorry, I should have used more precise terminology. Each relying party gets to choose its TAs. The entity offering a cert is free to propose a TA (or a cert path terminating at a TA) to the other end, but it cannot mandate that the RP use that path. Also, of course, TLS is NOT a peer protocol; the protocol distinguishes between client and server. I know that the server can send a cert path to the client, but does TLS support the client sending other than an EE cert to the server? In contrast, I believe IKEv2 does support more of a peer approach to this data exchange. (I'm not certain, but I bet Paul knows :-).) >So feel free to invert client and server below. > >Even though a client always has the right to decide how it will >authenticate a server, and how much it trusts any given authentication, >it cannot hurt for the server to provide (essentially) out-of-band >hints on its preferred method(s) of authenticating itself. agreed. >The client still has to choose to trust any DNS-specified hint that the >server only uses some specified trust anchor. I think what you mean to say here is that the RP can choose to ignore the hint provided by the entity that offered the cert path, but if it is going to make use of DANE in the first place ... Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFA23A7037 for ; Thu, 20 Jan 2011 09:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7v1bpCL8+fz for ; Thu, 20 Jan 2011 09:10:19 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5E9423A7150 for ; Thu, 20 Jan 2011 09:10:18 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49278) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pfy4A-000EuU-0I; Thu, 20 Jan 2011 12:12:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> <0D5B32F6-C8EC-4F5E-BBE6-EAEA6778C73B@bbn.com> Date: Thu, 20 Jan 2011 12:10:02 -0500 To: "Carl Wallace" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:10:21 -0000 At 10:30 AM -0500 1/20/11, Carl Wallace wrote: > > > Another approach is to include constraints in each TA definition and >> > enforce them during path validation (a la RFC 5914 and 5937). No >> > subjugation required. >> >> Either way, you're changing the TA from its published format (a >self-signed >> certificate) to something else, and changing the contents of the >cert/TA in >> the process (adding name constraints). The only difference between >these >> two proposals is whether you change TAs as published into certs signed >> under your own TA or just convert them all into RFC 5914 TAs. The >former, >> cert-based approach makes validation slightly easier, because there's >lots of >> support for self-signed certs as TAs in crypto libraries and not so >much RFC >> 5914, but the two are really equivalent. > >The cert-based approach requires you to make revocation information >available. but only for the re-issued (formerly TA certs), and only VERY locally. If this is a per-RP mechanism, revocation of these certs is within your cert store. I'd just delete the cert, not put it on a CRL, in that case :-). Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B523A713A for ; Thu, 20 Jan 2011 09:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK5o1PaprkDk for ; Thu, 20 Jan 2011 09:10:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 720A43A7037 for ; Thu, 20 Jan 2011 09:10:14 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49278) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pfy49-000EuU-EB; Thu, 20 Jan 2011 12:12:57 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> Date: Thu, 20 Jan 2011 12:07:32 -0500 To: "Carl Wallace" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:10:15 -0000 At 7:44 AM -0500 1/20/11, Carl Wallace wrote: > > >Without a single root, (name) constraints extensions simply dont >work. >> >> not true. >> >> >The "cross-certification" hack subjugates a signer that was >originally >> >born somewhere else under your own root with constraints in order to >> >make the (name) constraints work. >> >> yes, that's what it does, and that's OK, because every RP is supposed >to be >> able to choose its set of TAs. One example of how to do this, the one >> proposed in the SIDR work, is to have every RP be its own TA, and >> "subjugate" every purported TA under the RP. > >Another approach is to include constraints in each TA definition and >enforce them during path validation (a la RFC 5914 and 5937). No >subjugation required. yes. RFC 5914 assumes local TA management of a specific form which achieves the same effect. 5937 assumes use of a more sophisticated TA management environment that can do even more that what we're discussing here. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE213A712A for ; Thu, 20 Jan 2011 07:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6YNcTCpW+Bg for ; Thu, 20 Jan 2011 07:28:13 -0800 (PST) Received: from mail152.messagelabs.com (mail152.messagelabs.com [216.82.253.19]) by core3.amsl.com (Postfix) with SMTP id 1BC3C3A6FB7 for ; Thu, 20 Jan 2011 07:28:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-10.tower-152.messagelabs.com!1295537453!40404918!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 21394 invoked from network); 20 Jan 2011 15:30:53 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-10.tower-152.messagelabs.com with SMTP; 20 Jan 2011 15:30:53 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 20 Jan 2011 10:30:51 -0500 Message-ID: In-Reply-To: <0D5B32F6-C8EC-4F5E-BBE6-EAEA6778C73B@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] Issue #17 - Should draft-ietf-dane-protocol Thread-Index: Acu4tUZVGOpCV9X3TrSFnyCznHhFOQAARtSg References: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> <0D5B32F6-C8EC-4F5E-BBE6-EAEA6778C73B@bbn.com> From: "Carl Wallace" To: "Richard L. Barnes" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 15:28:14 -0000 > > Another approach is to include constraints in each TA definition and > > enforce them during path validation (a la RFC 5914 and 5937). No > > subjugation required. >=20 > Either way, you're changing the TA from its published format (a self-signed > certificate) to something else, and changing the contents of the cert/TA in > the process (adding name constraints). The only difference between these > two proposals is whether you change TAs as published into certs signed > under your own TA or just convert them all into RFC 5914 TAs. The former, > cert-based approach makes validation slightly easier, because there's lots of > support for self-signed certs as TAs in crypto libraries and not so much RFC > 5914, but the two are really equivalent. The cert-based approach requires you to make revocation information available. Defining your TAs to be constrained from the outset does not. Agree re: support for self-signed certs vs 5914. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADB13A7112 for ; Thu, 20 Jan 2011 07:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.702 X-Spam-Level: X-Spam-Status: No, score=-102.702 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkZzgUK3G2km for ; Thu, 20 Jan 2011 07:15:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6E28B3A6FB7 for ; Thu, 20 Jan 2011 07:15:35 -0800 (PST) Received: from ros-dhcp192-1-51-84.bbn.com ([192.1.51.84]:54432) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfwHC-000CVy-AU; Thu, 20 Jan 2011 10:18:18 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 20 Jan 2011 10:18:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D5B32F6-C8EC-4F5E-BBE6-EAEA6778C73B@bbn.com> References: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> To: Carl Wallace X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 15:15:36 -0000 >>> Without a single root, (name) constraints extensions simply dont > work. >>=20 >> not true. >>=20 >>> The "cross-certification" hack subjugates a signer that was > originally >>> born somewhere else under your own root with constraints in order to >>> make the (name) constraints work. >>=20 >> yes, that's what it does, and that's OK, because every RP is supposed > to be >> able to choose its set of TAs. One example of how to do this, the = one >> proposed in the SIDR work, is to have every RP be its own TA, and >> "subjugate" every purported TA under the RP. >=20 > Another approach is to include constraints in each TA definition and > enforce them during path validation (a la RFC 5914 and 5937). No > subjugation required. Either way, you're changing the TA from its published format (a = self-signed certificate) to something else, and changing the contents of = the cert/TA in the process (adding name constraints). The only = difference between these two proposals is whether you change TAs as = published into certs signed under your own TA or just convert them all = into RFC 5914 TAs. The former, cert-based approach makes validation = slightly easier, because there's lots of support for self-signed certs = as TAs in crypto libraries and not so much RFC 5914, but the two are = really equivalent. --Richard=20= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298BA3A7104 for ; Thu, 20 Jan 2011 04:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho5GCmDF-Axv for ; Thu, 20 Jan 2011 04:41:29 -0800 (PST) Received: from mail165.messagelabs.com (mail165.messagelabs.com [216.82.253.147]) by core3.amsl.com (Postfix) with SMTP id 44D653A6FCE for ; Thu, 20 Jan 2011 04:41:29 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-9.tower-165.messagelabs.com!1295527450!40875578!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 32207 invoked from network); 20 Jan 2011 12:44:11 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-9.tower-165.messagelabs.com with SMTP; 20 Jan 2011 12:44:11 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 20 Jan 2011 07:44:10 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [keyassure] Issue #17 - Should draft-ietf-dane-protocol Thread-Index: Acu4NRZSFGT4QI9nROGW0ByQtEsNugAag3Xg References: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> From: "Carl Wallace" To: Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 12:41:30 -0000 > >Without a single root, (name) constraints extensions simply dont work. >=20 > not true. >=20 > >The "cross-certification" hack subjugates a signer that was originally > >born somewhere else under your own root with constraints in order to > >make the (name) constraints work. >=20 > yes, that's what it does, and that's OK, because every RP is supposed to be > able to choose its set of TAs. One example of how to do this, the one > proposed in the SIDR work, is to have every RP be its own TA, and > "subjugate" every purported TA under the RP. Another approach is to include constraints in each TA definition and enforce them during path validation (a la RFC 5914 and 5937). No subjugation required. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AF128C0F1 for ; Wed, 19 Jan 2011 15:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awQ6tji5FnUy for ; Wed, 19 Jan 2011 15:57:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A992628C0DE for ; Wed, 19 Jan 2011 15:57:55 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49258) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pfhx6-000Mh2-BC; Wed, 19 Jan 2011 19:00:36 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> References: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> Date: Wed, 19 Jan 2011 18:57:23 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 23:57:56 -0000 At 3:30 AM +0100 1/19/11, Martin Rex wrote: >... > >I agree that support for multiple fully-equivalent signatures on >a certificate, similar to multiple signers in PKCS#7, would be >more than just complex to define (and process), especially in >combination with the existing constraints and revocation architecture. agreed >For the IETF it is more reasonable to allow a secondary validation >of certs originating somewhere out of the "TLS X.509 PKI" cloud >through DANE for significantly improved risk management, >rather than trying to touch the X.509 can of worms. >As a bonus, this creates additional incentive to deploy DNSSEC. DANE can offer raw keys to do this, or it can offer X.509./PKIX certs to be used as TAs. That's why I am picky about distinguishing between issues that are intrinsic to X.509/PKIX and ones that are browser-specific. Some of the latter can be avoided while still using X.509 certs. > >> >> > > One could enable users to manage the TAs offered by browser vendors >> > > in ways that limit the scope of them, e.g., through the use of name >> >> constraints. See the work in the SIDR WG on local TA management, for >> >> example (draft-ietf-sidr-ltamgmt-00.txt). >> > >> >Name Constraints have the prerequisite of a strict X.509 hierarchy >> >with only one single globally trusted root and another prerequisite >> >that name constraints are fully supported by the entire installed base. >> >> The name constraints extension does not require a single root; it >> does require a hierarchic name space. Don't confuse hierarchic name >> spaces (like the DNS) and hierarchic CA models. As PHB noted, cross >> certification has long been a feature of X.509 and that implies >> support for non-hierarchic CA relationships. > >I don't think this is a correct characterization. it is. >Without a single root, (name) constraints extensions simply >dont work. not true. >The "cross-certification" hack subjugates a signer that >was originally born somewhere else under your own root with constraints >in order to make the (name) constraints work. yes, that's what it does, and that's OK, because every RP is supposed to be able to choose its set of TAs. One example of how to do this, the one proposed in the SIDR work, is to have every RP be its own TA, and "subjugate" every purported TA under the RP. >When creating a cross-certification, you have one of two choices: >impose (name) constraints on the cross cert (path) and fail to validate all >certs issued by that foreign signer (perfectly valid under the foreign root) >that don't fit the name constraints imposed by your own root or hierarchy, >or create a cross-cert without (name) constraints and loose the ability >to enforce constraints (for signers originally operating under different roots). not quite true, perhaps because you didn't mean to put "all" where you did. if you impose (that is the target of that cross cert) that will no longer validate. It depends on the name scope of certs that the target CA issues, and what constraints you impose. >If you think of special environments where names and attributes are >created in allegedly independent hierarchies in a specific mandated >fashion so that there is no interference when cross-certing, then >this is essentially one hierarchy with a single root authority, just >that the root isn't actually created as a real _key_, and the cross-certs >are used as workarounds for the lack of a real root _key_. >That the root authority, which has the power to mandate rules doesn't >have the power/capability to sign keys is a mere implementation detail. not true, again. Let me give an example. if BBN issues certs for its employees, and SAP did the same for its employees, each could cross-certify the other with obvious name constraints. these cross certs would ensure that folks in each company would not believe certs issued by the other company, when the names were outside the scope of the company in question. This assumes a hierarchic name space, but does not make either BBN nor SAP a "root" etc. >Cross-certing existing PKIs that were established without a single >root authority that layed out rules/guidelines for issuing certs >is an entirely different situation, where constraints fail badly. That statement is sufficiently vague that I'm not sure what to say. But, I will note that each RP can manage TAs any way it wants, and, if the RP (or an organizational CA) is careful, it can achieve a reasonable level re cert names, irrespective of any conventions of PKI-wide security conventions. Anyway, this discussion is largely not critical to DANE, except in so far as it is important for folks to not make inaccurate assumptions re what X.509/PKKIX requires, vs. what browsers imply :-). Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286AD28C116 for ; Wed, 19 Jan 2011 09:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEtMZ3xxE9EB for ; Wed, 19 Jan 2011 09:45:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 57EB828C119 for ; Wed, 19 Jan 2011 09:45:47 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49252) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pfc8x-000HgN-K5; Wed, 19 Jan 2011 12:48:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB1A10E99B@DEN-MEXMS-001.corp.ebay.com> References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> <5EE049BA3C6538409BBE6F1760F328ABEB1A10E99B@DEN-MEXMS-001.corp.ebay.com> Date: Wed, 19 Jan 2011 11:16:19 -0500 To: "Steingruebl, Andy" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:45:48 -0000 At 4:21 PM -0700 1/18/11, Steingruebl, Andy wrote: > > -----Original Message----- >> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On >> Behalf Of Stephen Kent > > >> I see no reference to "CAA" in the charter. To what does that acronym >> refer? > >DNS Certification Authority Authorization (CAA) Resource Record >http://tools.ietf.org/html/draft-hallambaker-donotissue-01 > >- Andy thanks, Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4700528C119 for ; Tue, 18 Jan 2011 19:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWooyAvTFUDL for ; Tue, 18 Jan 2011 19:55:26 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D779428C101 for ; Tue, 18 Jan 2011 19:55:25 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0J3uHiP008400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 04:56:17 +0100 (MET) From: Martin Rex Message-Id: <201101190356.p0J3uG8K027596@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 19 Jan 2011 04:56:16 +0100 (MET) In-Reply-To: <201101182134.p0ILYA99006399@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 18, 11 10:34:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 03:55:27 -0000 Martin Rex wrote: > > > > > ... and with X.509 one could require that an EE cert for a server > > link to a specific TA (or set of TAs). > > With X.509, this option is available only to the client, not the > server and/or DNS admin. > > One possible client-side solution for such a requirement would be > "pinning" of a server cert (or a server cert signer) similar to what > is described here: > http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > However some folks in the IETF decided to completely subvert this: > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-6.6.1 > > by having a name match of a cert from any CA under the TLS X.509 PKI > _unconditionally_ override client cert pinning. I hadn't noticed that the original w3.org/TR document provides the same poor guidance in section 5.2 of unconditionally overriding a cert "pinned" by the user when receiving a certificate that validates under the TLS X.509 PKI. For the behaviour currently specified in above two documents, the use of the term "pinning a cert" is inappropriate and quite misleading. What the specified behaviour really amounts to is pinning the decision "Don't bother me again about this exact error situation" -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2714028B23E for ; Tue, 18 Jan 2011 18:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.161 X-Spam-Level: X-Spam-Status: No, score=-10.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pamogWG5hr1R for ; Tue, 18 Jan 2011 18:28:47 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 995F43A70BD for ; Tue, 18 Jan 2011 18:28:47 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0J2UqEa000202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 03:30:52 +0100 (MET) From: Martin Rex Message-Id: <201101190230.p0J2UpDt023151@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Wed, 19 Jan 2011 03:30:51 +0100 (MET) In-Reply-To: from "Stephen Kent" at Jan 18, 11 05:41:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 02:28:49 -0000 Stephen Kent wrote: > > > > >The issue that X.509 does not provide room for an additional signature > >is an X.509/PKIX shortcoming. Would X.509 provide room to accomodate > >an secondary signature, then one would not need DNSSEC/DANE to convey > >a secondary signature (authenticated through the independent DNS PKI). > > It is a deliberate design decision. In X.509/PKIX the issuer takes > responsibility for the certs that it issues, and it has sole > authority for revocation of those certs. if one has multiple sigs, > the revocation policy becomes more complex, at best. > (The X.509 CRL relies on uniqueness of the serial number > associated with a cert, and that is a per-CA identifier.) > There is also the issue of chaining complexity re validation, etc. I agree that support for multiple fully-equivalent signatures on a certificate, similar to multiple signers in PKCS#7, would be more than just complex to define (and process), especially in combination with the existing constraints and revocation architecture. For the IETF it is more reasonable to allow a secondary validation of certs originating somewhere out of the "TLS X.509 PKI" cloud through DANE for significantly improved risk management, rather than trying to touch the X.509 can of worms. As a bonus, this creates additional incentive to deploy DNSSEC. > > > > One could enable users to manage the TAs offered by browser vendors > > > in ways that limit the scope of them, e.g., through the use of name > >> constraints. See the work in the SIDR WG on local TA management, for > >> example (draft-ietf-sidr-ltamgmt-00.txt). > > > >Name Constraints have the prerequisite of a strict X.509 hierarchy > >with only one single globally trusted root and another prerequisite > >that name constraints are fully supported by the entire installed base. > > The name constraints extension does not require a single root; it > does require a hierarchic name space. Don't confuse hierarchic name > spaces (like the DNS) and hierarchic CA models. As PHB noted, cross > certification has long been a feature of X.509 and that implies > support for non-hierarchic CA relationships. I don't think this is a correct characterization. Without a single root, (name) constraints extensions simply dont work. The "cross-certification" hack subjugates a signer that was originally born somewhere else under your own root with constraints in order to make the (name) constraints work. When creating a cross-certification, you have one of two choices: impose (name) constraints on the cross cert (path) and fail to validate all certs issued by that foreign signer (perfectly valid under the foreign root) that don't fit the name constraints imposed by your own root or hierarchy, or create a cross-cert without (name) constraints and loose the ability to enforce constraints (for signers originally operating under different roots). If you think of special environments where names and attributes are created in allegedly independent hierarchies in a specific mandated fashion so that there is no interference when cross-certing, then this is essentially one hierarchy with a single root authority, just that the root isn't actually created as a real _key_, and the cross-certs are used as workarounds for the lack of a real root _key_. That the root authority, which has the power to mandate rules doesn't have the power/capability to sign keys is a mere implementation detail. Cross-certing existing PKIs that were established without a single root authority that layed out rules/guidelines for issuing certs is an entirely different situation, where constraints fail badly. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B4C3A70B2 for ; Tue, 18 Jan 2011 18:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 076PGC0oxszr for ; Tue, 18 Jan 2011 18:14:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id C335E3A70B1 for ; Tue, 18 Jan 2011 18:14:00 -0800 (PST) Received: by yxt33 with SMTP id 33so97578yxt.31 for ; Tue, 18 Jan 2011 18:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2xHEcXakTr/miDBun+GVJO6rVPk9VNrscbhWL7aNNto=; b=rcARWv5jQJ2jHv+4yIi+MEYYf/qU2gbSereiJ5xKqBXnPfjSwjagjkv9SbY+gsN/PX losRYlE7Km4cg6x8LarOmfrnqiNcGV//Z6wo+LuIL0d1Q00S4eNIt7Irs6b9eUFYrGt1 QPYItBrYXK4B10965P+13o4CrwFWWvTvuVExc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sjkdRux5cGkux1PBLWinW7sK32hdplCllp5PWz22010t5/D52Kj4wt+gje3BafV1FN fWYtsF7/jUNxiy7J56ot5DMnxAvAPDoGoJ2XRIlqOefRbnA2H8RSK8JaXkn7+nHjGUiY cjBGbNX9X+zbHrElgBB+JiTfBCkwCgJsCbSWc= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr93349ank.1.1295403399142; Tue, 18 Jan 2011 18:16:39 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 18 Jan 2011 18:16:39 -0800 (PST) In-Reply-To: <4D331614.2030204@vpnc.org> References: <4D32CDAA.10107@gmail.com> <4D331614.2030204@vpnc.org> Date: Tue, 18 Jan 2011 21:16:39 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=00163662e65b725e10049a299b45 Cc: keyassure@ietf.org Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 02:14:02 -0000 --00163662e65b725e10049a299b45 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 16, 2011 at 11:00 AM, Paul Hoffman wrote: > On 1/16/11 2:51 AM, Yaron Sheffer wrote: > >> Hi Paul, >> >> No, I am not taking any sides regarding support for protocols that are >> not mentioned in the charter (which is Issue #5). Note that IPsec itself >> is, in fact, already in the charter. >> >> Neither am I proposing to expand the scope of the current document >> (which is Issue #17). I actually prefer the current focus. >> >> I am just proposing the make the record's *name* protocol-agnostic, so >> it can be reused in the future without excuses. >> > > Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer to > keep the name as tied to what we know it will be used for and let other > people do deltas if they want. Not a bikeshed discussion at all. How strong is this 'preference' of yours. Do you think it is worth actually arguing over or do you just think that you should have your way because you don't think it important even though others do? -- Website: http://hallambaker.com/ --00163662e65b725e10049a299b45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 16, 2011 at 11:00 AM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
On 1/16/11 2:51 AM, Yaron Sheffer wrote:
Hi Paul,

No, I am not taking any sides regarding support for protocols that are
not mentioned in the charter (which is Issue #5). Note that IPsec itself is, in fact, already in the charter.

Neither am I proposing to expand the scope of the current document
(which is Issue #17). I actually prefer the current focus.

I am just proposing the make the record's *name* protocol-agnostic, so<= br> it can be reused in the future without excuses.

Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer= to keep the name as tied to what we know it will be used for and let other= people do deltas if they want.


Not a bikeshed discussion at all.=A0

How stro= ng is this 'preference' of yours. Do you think it is worth actually= arguing over or do you just think that you should have your way because yo= u don't think it important even though others do?

--
Website: http://hallam= baker.com/

--00163662e65b725e10049a299b45-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7E73A708F for ; Tue, 18 Jan 2011 18:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.723 X-Spam-Level: X-Spam-Status: No, score=-101.723 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mddfs5fElVzE for ; Tue, 18 Jan 2011 18:01:49 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 349103A703F for ; Tue, 18 Jan 2011 18:01:49 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0J24RV6068607 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 19:04:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3646AA.8060106@vpnc.org> Date: Tue, 18 Jan 2011 18:04:26 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 02:01:50 -0000 On 1/18/11 5:28 PM, Steve Schultze wrote: > I'm in favor of a version of Matt's text in section 3.0: > > http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html > > Any reason why that's not a good idea? We have so far chosen not to get into any nuts-and-bolts of DNSSEC checking, and this would send us far down that path. It is a big step, and we should consider it carefully. FWIW, I think we should take that step because we have gotten no support from the DNSEXT WG on last-mile DNSSEC, but I know others here don't agree. > I'm not totally sure whether > the text should go into the intro to section 3 or in 3.1. I'm not > really a fan of the "The preceding paragraph is probably wrong" > parenthetical in 3.1. Nor are Jakob and I, of course. But early honesty helps shine a spotlight on places that need work. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD3E28C0ED for ; Tue, 18 Jan 2011 17:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOtfA90bZPF5 for ; Tue, 18 Jan 2011 17:25:44 -0800 (PST) Received: from ppa01.Princeton.EDU (ppa01.Princeton.EDU [128.112.128.213]) by core3.amsl.com (Postfix) with ESMTP id D17B228C0F7 for ; Tue, 18 Jan 2011 17:25:43 -0800 (PST) Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa01.Princeton.EDU (8.14.3/8.14.3) with ESMTP id p0J1SM6Q006457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Jan 2011 20:28:22 -0500 Received: from new-host-2.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p0J1SLOB017117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Jan 2011 20:28:22 -0500 From: Steve Schultze Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 20:28:21 -0500 Message-Id: To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6230 signatures=655887 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1101180210 Subject: [keyassure] draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 01:25:44 -0000 I'm in favor of a version of Matt's text in section 3.0: http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html Any reason why that's not a good idea? I'm not totally sure whether the = text should go into the intro to section 3 or in 3.1. I'm not really a = fan of the "The preceding paragraph is probably wrong" parenthetical in = 3.1.= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8B728C0F7 for ; Tue, 18 Jan 2011 16:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzIe7W8hnDV1 for ; Tue, 18 Jan 2011 16:58:40 -0800 (PST) Received: from ppa04.Princeton.EDU (ppa04.Princeton.EDU [128.112.128.215]) by core3.amsl.com (Postfix) with ESMTP id 66AB028C0E1 for ; Tue, 18 Jan 2011 16:58:40 -0800 (PST) Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa04.Princeton.EDU (8.14.3/8.14.3) with ESMTP id p0J11Iuc015897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Jan 2011 20:01:18 -0500 Received: from new-host-2.home (pool-173-71-100-208.cmdnnj.fios.verizon.net [173.71.100.208]) (authenticated bits=0) by csgsmtp200l.Princeton.EDU (8.13.8/8.12.9) with ESMTP id p0J11IvP009419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 18 Jan 2011 20:01:18 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Steve Schultze In-Reply-To: <4D331614.2030204@vpnc.org> Date: Tue, 18 Jan 2011 20:01:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3038D717-FCF1-4A21-B596-A6BD2E723E70@princeton.edu> References: <4D32CDAA.10107@gmail.com> <4D331614.2030204@vpnc.org> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6230 signatures=655887 X-Proofpoint-Spam-Details: rule=quarantine_notspam policy=quarantine score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1012030000 definitions=main-1101180205 Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 00:58:41 -0000 On Jan 16, 2011, at 11:00 AM, Paul Hoffman wrote: > On 1/16/11 2:51 AM, Yaron Sheffer wrote: >> Hi Paul, >>=20 >> No, I am not taking any sides regarding support for protocols that = are >> not mentioned in the charter (which is Issue #5). Note that IPsec = itself >> is, in fact, already in the charter. >>=20 >> Neither am I proposing to expand the scope of the current document >> (which is Issue #17). I actually prefer the current focus. >>=20 >> I am just proposing the make the record's *name* protocol-agnostic, = so >> it can be reused in the future without excuses. >=20 > Ah, I didn't realize this was a bikeshed discussion. :-) I would = prefer to keep the name as tied to what we know it will be used for and = let other people do deltas if they want. Er, the name can be "tied to what we know it will be used for" and still = be general enough that if other uses come along our work can be reused. = If we are too specific, any subsequent use for something outside of TLS = would require creating a new RRTYPE and getting that deployed. I don't = see any reason why we'd want to make that necessary. I'm with Yaron. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D483A7069 for ; Tue, 18 Jan 2011 16:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.159 X-Spam-Level: X-Spam-Status: No, score=-10.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng08b+PD7N23 for ; Tue, 18 Jan 2011 16:43:24 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4FAA33A6FDB for ; Tue, 18 Jan 2011 16:43:24 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0J0jhlR008239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 01:45:43 +0100 (MET) From: Martin Rex Message-Id: <201101190045.p0J0jhws017247@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Wed, 19 Jan 2011 01:45:43 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Jan 18, 11 10:14:49 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 00:43:25 -0000 Phillip Hallam-Baker wrote: > > In practice X.509 started to absorb features from PGP very early on. I guess we live in different universes. X.509 never adopted the capability of multiple signers, and a lot of the PKIX features (basically everything with the word constraint in it) has the prerequisite of a CA hierarchy with only one single trust anchor (because constraints do not work across independent trust anchors). PGP, on the other hand, faced the reality from the beginning and provides the necessary capabilities to deal with large numbers of independent trust communities and varying levels of trust. And in order to cope with this, allows for multiple signers on associations of keys and identites. The concept of multiple signers covers the gaps created by independent trust anchors. With X.509 it is is pretty difficult to establish a notion of varying levels of trust. Which might be a reason why the CA/Browser forum came up with an approach (DV-,OV-,EV-certs) that is entirely invisible/ignored by IETF protocols http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14 But one area where PGP has traditionally been lacking is a reliable/deterministic approach to revocation. (I do not mean revoking your own key, but revoking your signature on someone else's key). > > The systems have already converged. PGP key signing has never enjoyed any > real market success as a host authentication mechanism. The idea behind PGP were pretty successful authenticating host in the form of SSH. The SSH keyring is called "known_hosts". > > even if it had the idea of a monolithic PKI hierarchy like DNSSEC > is entirely antithetical to the PGP design goals. To the contrary. PGP _could_ support arbitrary numbers of monolithic PKI hierarchies alongside the web of trust of individuals just fine. But honestly, it is extremely dangerous and negligent to let others update the list of signers that you should trust without your explicit consent, and for the area where PGP is being used, it has been completely unnecessary. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B86F28C13C for ; Tue, 18 Jan 2011 15:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.243 X-Spam-Level: X-Spam-Status: No, score=-8.243 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcPgOtVEBWxi for ; Tue, 18 Jan 2011 15:19:18 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 0A30D28C0FA for ; Tue, 18 Jan 2011 15:19:17 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=qrmVR2LmfGfwJHba6WSNyLStYcT9/Flu6hSu7JSVm8ydxSazPzvdP7dS HxIYigerzgdHLf4WkiXldqZP/KXf6/hTcW8xVs8cG0yNiFNc/cSfH1Idq jiPSdL3AYUhYUTq; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1295392917; x=1326928917; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Stephen=20Kent=20|CC:=20"keyass ure@ietf.org"=20|Date:=20Tue,=2018=20 Jan=202011=2016:21:55=20-0700|Subject:=20RE:=20[keyassure ]=20Issue=20#17=20-=20Should=20draft-ietf-dane-protocol |Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABEB1A10E99 B@DEN-MEXMS-001.corp.ebay.com>|References:=20<20110118141 7.p0IEHHek011249@fs4113.wdf.sap.corp>=0D=0A=09=0D=0A=09=0D=0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quot ed-printable|MIME-Version:=201.0; bh=ibM9hSZxbtb19sgmiQXmA+UmlXlKpTtxR5XE5p/nerA=; b=kTniQ3QEQS/vJUVpCCzNc0ZkKwt0neqFd5hIIag69j6g97MRRGSVLOd5 kgBPB+/h3ZBpomc4TF1CUfY72RYCwt/gf4i9GQat4cB/MKjf5Dhk0lo5E 26C3ei3KIVA7KLT; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,340,1291622400"; d="scan'208";a="850311" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 18 Jan 2011 15:21:56 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 18 Jan 2011 16:21:55 -0700 From: "Steingruebl, Andy" To: Stephen Kent Date: Tue, 18 Jan 2011 16:21:55 -0700 Thread-Topic: [keyassure] Issue #17 - Should draft-ietf-dane-protocol Thread-Index: Acu3YlvSGiagUDkkTA2W5hiikrbQdgABA6rw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB1A10E99B@DEN-MEXMS-001.corp.ebay.com> References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 2ehsU0htl3wp/GKPwVyyCQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:19:19 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Stephen Kent > I see no reference to "CAA" in the charter. To what does that acronym > refer? DNS Certification Authority Authorization (CAA) Resource Record http://tools.ietf.org/html/draft-hallambaker-donotissue-01 - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDABE28C0FA for ; Tue, 18 Jan 2011 14:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV3rFMBSC3jd for ; Tue, 18 Jan 2011 14:49:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CC18A28C0D7 for ; Tue, 18 Jan 2011 14:49:31 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49247) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfKPJ-000BpW-TT; Tue, 18 Jan 2011 17:52:10 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> Date: Tue, 18 Jan 2011 17:48:58 -0500 To: Paul Wouters From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:49:32 -0000 At 3:51 PM -0500 1/18/11, Paul Wouters wrote: >On Tue, 18 Jan 2011, Stephen Kent wrote: > >>>One possible usage of DANE would be to limit which specific CAs from >>>those considered valid CAs under the TLS X.509 PKI, are also valid >>>signers for a particular server or a particular DNS domain. >> >>I understand the attraction for this notion, but it does conflict with the >>concept that, ultimately, the client (software) gets to make >>decisions of this sort. > >Leave that to the CAA draft please. > >Paul I see no reference to "CAA" in the charter. To what does that acronym refer? Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CFF28C11B for ; Tue, 18 Jan 2011 14:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLTqF9IyyCD8 for ; Tue, 18 Jan 2011 14:43:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6BFA528C11D for ; Tue, 18 Jan 2011 14:43:41 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49246) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfKJf-000Bm5-AD; Tue, 18 Jan 2011 17:46:19 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101182134.p0ILYA99006399@fs4113.wdf.sap.corp> References: <201101182134.p0ILYA99006399@fs4113.wdf.sap.corp> Date: Tue, 18 Jan 2011 17:41:09 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:43:42 -0000 At >... > >The issue that X.509 does not provide room for an additional signature >is an X.509/PKIX shortcoming. Would X.509 provide room to accomodate >an secondary signature, then one would not need DNSSEC/DANE to convey >a secondary signature (authenticated through the independent DNS PKI). It is a deliberate design decision. In X.509/PKIX the issuer takes responsibility for the certs that it issues, and it has sole authority for revocation of those certs. if one has multiple sigs, the revocation policy becomes more complex, at best. (The X.509 CRL relies on uniqueness of the serial number associated with a cert, and that is a per-CA identifier.) There is also the issue of chaining complexity re validation, etc. > > One could enable users to manage the TAs offered by browser vendors > > in ways that limit the scope of them, e.g., through the use of name >> constraints. See the work in the SIDR WG on local TA management, for >> example (draft-ietf-sidr-ltamgmt-00.txt). > >Name Constraints have the prerequisite of a strict X.509 hierarchy >with only one single globally trusted root and another prerequisite >that name constraints are fully supported by the entire installed base. The name constraints extension does not require a single root; it does require a hierarchic name space. Don't confuse hierarchic name spaces (like the DNS) and hierarchic CA models. As PHB noted, cross certification has long been a feature of X.509 and that implies support for non-hierarchic CA relationships. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115A328C0E0 for ; Tue, 18 Jan 2011 14:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwYKf2EPhWog for ; Tue, 18 Jan 2011 14:43:05 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id A499D28C0D7 for ; Tue, 18 Jan 2011 14:43:05 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 84FCA40109; Tue, 18 Jan 2011 22:45:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1295390742; bh=VozwVgG3l+57CqGqndjkNBArs2oLmUu9DX9rx1cUMIY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=PyuQNQgBpdsx1ZFNnUSm8vlANnPeOLWJX1mY2H7ljrTzpTJSnw+cbw/0Eb+km+Nc3 ln4c54mBFLdmJm1NFuDK0mssUciPyMj5LVQLU0ihC68hH3lqvXQUErnAlmXIntxy9R LAn1XJ5OFN0uE03mtHIKUFh+h6VR8OeQ3+gZYSh4= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 0F48E36003A; Tue, 18 Jan 2011 22:33:08 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: (Stephen Kent's message of "Tue\, 18 Jan 2011 13\:30\:11 -0500") References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 18 Jan 2011 17:33:07 -0500 Message-ID: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110118:keyassure@ietf.org::9/LvcZ4pSzK4b1G1:000000000000000000000000000000000000000000BbGfk X-Hashcash: 1:30:110118:kent@bbn.com::eOdGIiAbhcrb7mIS:0000eqE4+ X-Hashcash: 1:30:110118:mrex@sap.com::ucQ8hpImMtSKL5AA:0000fha7h Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:43:07 -0000 >>>>> "SK" == Stephen Kent writes: >> One possible usage of DANE would be to limit which specific CAs from >> those considered valid CAs under the TLS X.509 PKI, are also valid >> signers for a particular server or a particular DNS domain. SK> I understand the attraction for this notion, but it does conflict SK> with the concept that, ultimately, the client (software) gets to SK> make decisions of this sort. This really isn't a client-server issue, since both sides have a need to, when necessary, authenticate themselves to the other. Like anything communicating over IP we should think of each side as a peer. So feel free to invert client and server below. Even though a client always has the right to decide how it will authenticate a server, and how much it trusts any given authentication, it cannot hurt for the server to provide (essentially) out-of-band hints on its preferred method(s) of authenticating itself. The client still has to choose to trust any DNS-specified hint that the server only uses some specified trust anchor. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389283A7050 for ; Tue, 18 Jan 2011 14:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgBuURQrF32V for ; Tue, 18 Jan 2011 14:32:59 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 97B973A7021 for ; Tue, 18 Jan 2011 14:32:59 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 0975D4053E; Tue, 18 Jan 2011 22:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1295390137; bh=yU61ya/D+9ltNr7BmoEOQeNcBvQQMheG5hrgYVYEhtE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=e9WVUtrLishL0p5OLV9V3shxVLBVvFtvgCZCIjLjOoko1+0ZcZsEpRnuygSoEh+8b NHCzDBB1435lmSjGGcdWgfNILnHuUuEImSrQKVScwRnzZMXRWvT49D0RfZWRgFoAyH b/eqnFalnHOXjNtG6uIfnV4X8l5meMm2wWWEYB6c= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 33ACA36004A; Tue, 18 Jan 2011 22:23:44 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: (Phillip Hallam-Baker's message of "Tue, 18 Jan 2011 10:14:49 -0500") References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 18 Jan 2011 17:23:43 -0500 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110118:keyassure@ietf.org::YMAkt58y1fHkF3un:000000000000000000000000000000000000000000XErfc X-Hashcash: 1:30:110118:hallam@gmail.com::WXjfGKuq+Z2KsFqp:huFz1 X-Hashcash: 1:30:110118:mrex@sap.com::/u9WX0XZ04rKehhW:0000uuwSh Cc: Phillip Hallam-Baker Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:33:01 -0000 >>>>> "PH" == Phillip Hallam-Baker writes: PH> the idea of a monolithic PKI hierarchy like DNSSEC is entirely PH> antithetical to the PGP design goals. Not antithetical but rather just another path in the trust graph; one which starts at the . DS rather than at another OpenPGP key. (Unless, of course, one trusts the . DS /because/ of a trust path back to an OpenPGP key. :) OpenPGP's choice to make the trust graph explicit, and the choice by most software authors to allow users to configure how much they trust any given key, how much less trust they allocate to keys which are signed by trusted keys and how much more trust they allocate to additional paths through the graph is one of its biggest strengths. Signing OpenPGP keys with DNSSEC fits nicely into that model. The value of a chain of RRSIGs probably should be a bit different than the value of a chain of OpenPGP sigs, but the concept is the same. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBD43A6F00 for ; Tue, 18 Jan 2011 13:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJphb-LJfAXf for ; Tue, 18 Jan 2011 13:52:32 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id A72573A6EF5 for ; Tue, 18 Jan 2011 13:52:31 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 9FD2D400EE; Tue, 18 Jan 2011 21:54:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1295387708; bh=DgtDgAjoM35qLgXz9JJWz4rPa97kEbuhSHVqocw/9tw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=SMPw01FtWIvCx2vEPp6tPsPd4NDUrjZD52PCtuQEcqrNFcI+OmUJsh5oWcMif62Q7 7H1Wx2yB2Kx6YTCX988gw44wttNXgKfJzNrSnTaJJDW7vz28VqonjRZjyW6XX1nfZP kKzGsFmuc0orsqgWF4QiAPaWbKYTmfRvrurpOfFI= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 3E37B360029; Tue, 18 Jan 2011 21:47:16 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> (Warren Kumari's message of "Mon, 17 Jan 2011 15:46:10 -0500") References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 18 Jan 2011 16:47:15 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110118:keyassure@ietf.org::IHIU4XmZWqbNRYB2:000000000000000000000000000000000000000000sYp5O X-Hashcash: 1:30:110118:warren@kumari.net::qJLkAcC3VWgItl7G:0000000000000000000000000000000000000000000itb5p Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:52:36 -0000 >>>>> "WK" == Warren Kumari writes: WK> Description: WK> How to deal with multiple TLS-based services running under WK> one domain name, such as a POP, IMAP, and SMTP server all WK> running on mail.example.com. DDDS seems to be a good fit. Cf RFCs 3401-3404. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1CA3A6E7B for ; Tue, 18 Jan 2011 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-75WepPyAM0 for ; Tue, 18 Jan 2011 13:37:53 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id DDF673A6DCE for ; Tue, 18 Jan 2011 13:37:52 -0800 (PST) Received: (qmail 5209 invoked by uid 0); 18 Jan 2011 21:40:30 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 18 Jan 2011 21:40:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=rt3eS5CaEzO81bOLSQvqs+0TtxCa6MkfBNYZx+5VY/vPxILNPJMBx4Tdqe4nTx9sVaQ+DrWXRoCCzHosCEbV7dFPXyCnHhXftbnrGbkmUlqGx/mvI2JMmcd8YmRy27li; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.134]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PfJHy-0002e3-FW for keyassure@ietf.org; Tue, 18 Jan 2011 14:40:30 -0700 Message-ID: <4D3608CD.8060302@KingsMountain.com> Date: Tue, 18 Jan 2011 13:40:29 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [keyassure] fyi: DNSSEC practice statements and associated documents X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:37:54 -0000 FYI, there already has been a fair amount of work done w.r.t. wrapping policy, procedures, and conventions around the technical capabilities of DNSSEC, a la what is done in the PKIX/X.509 world. Here's some pointers to relevant documents and repositories... DNSSEC Policy & Practice Statement Framework (DRAFT) http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework Abstract This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. -- DPS framework (slides) DNSSEC in Sweden: Five Years of Practical Experience (slides) Root DNSSEC docs ---------------- Root DNSSEC - documentation (many documents) http://www.root-dnssec.org/documentation/ IANA DNSSEC Information https://www.iana.org/dnssec/ Individual DPSs --------------- DNSSEC Practice Statement for the Root Zone KSK Operator https://www.iana.org/dnssec/icann-dps.txt Verisign DNSSEC Practice Statements (.net, .edu, Signing Services, root zone ZSK operator) https://verisigninc.com/en_US/repository/index.xhtml RIPE DNSSEC Policy and Practice Statement http://www.ripe.net/rs/reverse/dnssec/dps.html DNSSEC Practice Statement (DPS) -- .se http://www.iis.se/docs/se-dnssec-dps-eng.pdf DNSSEC Practice Statement for the JP Zone (JP DPS) https://jprs.jp/doc/dnssec/jp-dps-eng.html --- end Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F350B3A6EEE for ; Tue, 18 Jan 2011 13:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.156 X-Spam-Level: X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRZJlBXSzUCl for ; Tue, 18 Jan 2011 13:33:56 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 4FF523A6E7B for ; Tue, 18 Jan 2011 13:33:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0ILYBWa024749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jan 2011 22:34:11 +0100 (MET) From: Martin Rex Message-Id: <201101182134.p0ILYA99006399@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Tue, 18 Jan 2011 22:34:10 +0100 (MET) In-Reply-To: from "Stephen Kent" at Jan 18, 11 01:30:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:33:58 -0000 Stephen Kent wrote: > > >In the existing TLS X.509 PKI there is currently no means for a server > >or domain admin to limit/restrict which CAs are allowed to confirm > >a server credential as valid. Any single one will do. And according > >to this research: http://www.eff.org/files/DefconSSLiverse.pdf > >(page 19) there are plenty of CAs for attackers to choose from. > > yep. > > >DANE could become a band-aid to mitigate this PKIX security problem, > >by establishing a secondary requirement vaguely similar to "dual control" > >(http://www.yourwindow.to/information-security/gl_dualcontrol.htm) > > this is NOT a PKIX problem. It is a browser design problem. I'm sorry for another mixup of terminology PKIX (the technology/protocols) vs. PKI (the use of PKIX protocols with a certain set of trust anchors, such as the TLS X.509 PKI). The fact that browsers are using a large set of independent trust-anchors from commercial CAS (TLS X.509 PKI) is admittedly a browser problem. But one that is hardly avoidable for a browser, the way that HTTPS is currently used on the internet. The issue that X.509 does not provide room for an additional signature is an X.509/PKIX shortcoming. Would X.509 provide room to accomodate an secondary signature, then one would not need DNSSEC/DANE to convey a secondary signature (authenticated through the independent DNS PKI). > > One could enable users to manage the TAs offered by browser vendors > in ways that limit the scope of them, e.g., through the use of name > constraints. See the work in the SIDR WG on local TA management, for > example (draft-ietf-sidr-ltamgmt-00.txt). Name Constraints have the prerequisite of a strict X.509 hierarchy with only one single globally trusted root and another prerequisite that name constraints are fully supported by the entire installed base. Neither the existing TLS X.509 PKI nor most of the installed base of PKI software meets these prerequisites, and frankly, I don't see a realistic migration path for the former and no incentive for the latter. While it is possible to build PKIs (and obtain software) that fulfills these prerequisite, I personally doubt that they scale beyond a small set of closely related organizations. The only reason why this kind-of-works in the DNSSEC case is that is uses an existing delegation hierarchy, is not abused as a business model, incurs fairly minor costs and does not need to scale beyond DNS (only a fraction of internet users are DNS domain admins). > > >One possible usage of DANE would be to limit which specific CAs from > >those considered valid CAs under the TLS X.509 PKI, are also valid > >signers for a particular server or a particular DNS domain. > > I understand the attraction for this notion, but it does conflict with > the concept that, ultimately, the client (software) gets to make > decisions of this sort. There are two distinct issues that ought not to be confused. Ignoring information provided by the admin of a DNS domain about valid certificate signers for a host in that domain would be much worse than ignoring Certificate revocation information (CRLs/OCSP). But there currently is no means for an DNS admin or server admin to convey such information. DANE could convey this information. Not checking whether such information exist (or ignoring it) is ultimately the clients decision, but may put the client at risk. While PKIX provides a means to convey revocation information from certificate signers to clients, PKIX provides no means to credentials bearers to convey independent confirmation of an identity asserted by an X.509 certificate. > > >With the PGP web-of-trust model, it would be technically possible > >to require any number of additional signers for a server credential > >before it is considered valid. > > yes, and with X.509 one could require that an EE cert for a server > link to a specific TA (or set of TAs). With X.509, this option is available only to the client, not the server and/or DNS admin. One possible client-side solution for such a requirement would be "pinning" of a server cert (or a server cert signer) similar to what is described here: http://www.w3.org/TR/wsc-ui/#selfsignedcerts However some folks in the IETF decided to completely subvert this: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-6.6.1 by having a name match of a cert from any CA under the TLS X.509 PKI _unconditionally_ override client cert pinning. Maybe the IETF can make at least have DANE provide some risk mitigation capabilities for the server and DNS admins? -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7EAE28C142 for ; Tue, 18 Jan 2011 12:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bL4dUKm3Vad for ; Tue, 18 Jan 2011 12:48:53 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id DFD2028C13F for ; Tue, 18 Jan 2011 12:48:52 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4D8DEC50C; Tue, 18 Jan 2011 15:51:30 -0500 (EST) Date: Tue, 18 Jan 2011 15:51:29 -0500 (EST) From: Paul Wouters To: Stephen Kent In-Reply-To: Message-ID: References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:48:53 -0000 On Tue, 18 Jan 2011, Stephen Kent wrote: >> One possible usage of DANE would be to limit which specific CAs from >> those considered valid CAs under the TLS X.509 PKI, are also valid >> signers for a particular server or a particular DNS domain. > > I understand the attraction for this notion, but it does conflict with the > concept that, ultimately, the client (software) gets to make decisions of > this sort. Leave that to the CAA draft please. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603B828C142 for ; Tue, 18 Jan 2011 12:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc8CLFCcgNOJ for ; Tue, 18 Jan 2011 12:45:32 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 896A428C12F for ; Tue, 18 Jan 2011 12:45:32 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 17D6DC50C; Tue, 18 Jan 2011 15:48:09 -0500 (EST) Date: Tue, 18 Jan 2011 15:48:08 -0500 (EST) From: Paul Wouters To: Nicholas Weaver In-Reply-To: <1B086403-4351-4E8C-86DE-AD138CA33642@icsi.berkeley.edu> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> <4D35CFC5.8040705@vpnc.org> <1B086403-4351-4E8C-86DE-AD138CA33642@icsi.berkeley.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:45:33 -0000 On Tue, 18 Jan 2011, Nicholas Weaver wrote: > because otherwise, how do you know which port for which service, which is IMO, necessary to really get things to work? The application that is about to do TLS knows what port the service is running on. The only question is, should it lookup the TLSA data on the hostname or on the .hostname. The first will result in the app potentially looking through multiple TLSA records before it finds a match (something it might need to support anyway) I dont think there are that mant TLS services on a single host that this is worth the extra complications of the service specifiers. Especially since we're mostly talking about mail and web, and otherwise with custom apps for TLS, the whole "service" lookup becomes tricky anyway. Also, if in the future we want to optimise this and return these along with A records, it would be much better if they are for the same FQDN and not some _service._transport modifier. So if we do modifiers, I would really want to be able to use the non-modified method as well. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A74E3A7061 for ; Tue, 18 Jan 2011 11:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCYfR2R-MUAz for ; Tue, 18 Jan 2011 11:23:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6913B3A7054 for ; Tue, 18 Jan 2011 11:23:02 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49228) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PfHBT-0005fK-ET; Tue, 18 Jan 2011 14:25:39 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> Date: Tue, 18 Jan 2011 13:30:11 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:23:04 -0000 At 3:17 PM +0100 1/18/11, Martin Rex wrote: >Stephen Kent wrote: >> >> The use of the phrase "n-factor authentication" in your message does >> not match what is commonly accepted in the security field. In >> multi-factor authentication the factors represent different types of >> authentication data, not multiple instances of auth data of the same >> type. > >You're correct. The term(s) 2-Factor and Multi-Factor have been >squatted by marketeers and regulators for a very specific purpose. > > >I was trying to describe a specific security feature at an abstract >level using invalid terminology. agreed. >X.509/PKIX credentials are confirmed as valid with one single digital >signature. There is no means (native to X.509) to require multiple >independent signatures (logical "AND"). On the contrary, when there >are multiple omipotent CA trusted as credential signers (logical "OR"), >then the bottom-line security is significantly impaired. agreed >In the existing TLS X.509 PKI there is currently no means for a server >or domain admin to limit/restrict which CAs are allowed to confirm >a server credential as valid. Any single one will do. And according >to this research: http://www.eff.org/files/DefconSSLiverse.pdf >(page 19) there are plenty of CAs for attackers to choose from. yep. >DANE could become a band-aid to mitigate this PKIX security problem, >by establishing a secondary requirement vaguely similar to "dual control" >(http://www.yourwindow.to/information-security/gl_dualcontrol.htm) this is NOT a PKIX problem. It is a browser design problem. One could enable users to manage the TAs offered by browser vendors in ways that limit the scope of them, e.g., through the use of name constraints. See the work in the SIDR WG on local TA management, for example (draft-ietf-sidr-ltamgmt-00.txt). >One possible usage of DANE would be to limit which specific CAs from >those considered valid CAs under the TLS X.509 PKI, are also valid >signers for a particular server or a particular DNS domain. I understand the attraction for this notion, but it does conflict with the concept that, ultimately, the client (software) gets to make decisions of this sort. >With the PGP web-of-trust model, it would be technically possible >to require any number of additional signers for a server credential >before it is considered valid. yes, and with X.509 one could require that an EE cert for a server link to a specific TA (or set of TAs). >But in order to gauge the effective security, one needs to look at >the overall picture not just one specific procedure. > >The TLS X.509 PKI traditionally has weaknesses, because it keys off >the WHOIS database for issuing server certs, and some CA issuing procedures >involven unauthenticated SMTP Email. DANE will inherit its properties >from the DNS administration procedures, so what matters is the difficulty >of getting malicious DNS records into the DNS database that feeds >into the automatic DNSSEC record signing service. The statement about using whois data may be true for some CAs, but it not part of X.509 or PKIX standards, nor it it mandated by browser vendors. I think it best to focus on what DANE can do, based on DNS, not on the CP/S for every possible CA that becomes a TA in some browser. >Two factor authentication schemes for humans may have similar problems. >Although an authentication scheme involving a fingerprint and a token >counts as two factor, a successful attack on this scheme usually >requires only one single assault on one person. Absent a discussion of a threat model, one cannot judge the extent to which a multi-factor authentication scheme represents a useful improvement over a specific, single-factor scheme. In your example, if the threat is perceived to be hackers, then use of a fingerprint probably does make a big, positive difference. if the threat is a criminal with physical access to the user, it's not so impressive :-). >Similarly, a procedure to register/establish new multi-factor authentication >credentials might require only one single proof of identity (ID-card). In this case the concern is not whether the registered user is securely authenticated, but rather whether the ID asserted by that individual is accurate. Those are different security issues. >Requiring multiple signatures on a server key in a PGP web-of-trust style >may improve security. But if all of the necessary signatures can be >obtained with the exact same "proof of ownership", then this mostly >adds complexity without value (it would only protect from exploration >of accidental unique flaws in the validation/issuing procedures >of individual signers). There are lots of ways a multi-signature cert may offer little improvement over a single signature cert. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A8C3A7030 for ; Tue, 18 Jan 2011 11:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63kqNAozTxKC for ; Tue, 18 Jan 2011 11:13:03 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id 0B8363A7023 for ; Tue, 18 Jan 2011 11:13:02 -0800 (PST) Received: by yia28 with SMTP id 28so3304432yia.15 for ; Tue, 18 Jan 2011 11:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R+pWaD1kRLnyXHWT0/YcO1HqFvMZwmriwXB9djmNPL8=; b=annypC0gG6SqZh/Dp2l9MLpDzPSuSj6x3Jbf+qoglCzOK6H2rvWlCwxzWpon51/Uyu XqBNuAJx4dPiAVyBAhfJG1o9Y5QR+9ac8vLxkqRP+/7GEamaLXibeYnRY39TZf3HF3HW 7VVERkY1NzM+RuOkzC4DX/89Ax5+M6s6kz9Gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wo2XGVuh1qHFLUG6FZUXOoSBR8jFi5RpE6O2pZ6nOSG95ClV1TMzbXwW1zXNnrEpEs FlMMecWkWW3pikphCxpgt0u0rKKYxdou5P2y6rWGAH99913A9sZh26dzn5V8ERJI3X/M xqxi4M9yEOLlF+gt3ObmTmqLZeDFDO+5rxoIY= MIME-Version: 1.0 Received: by 10.100.153.17 with SMTP id a17mr3685207ane.239.1295378140564; Tue, 18 Jan 2011 11:15:40 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 18 Jan 2011 11:15:40 -0800 (PST) In-Reply-To: <877he2hyih.fsf@latte.josefsson.org> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> <877he2hyih.fsf@latte.josefsson.org> Date: Tue, 18 Jan 2011 14:15:40 -0500 Message-ID: From: Phillip Hallam-Baker To: Simon Josefsson Content-Type: multipart/alternative; boundary=0016e644d5cceb0fd1049a23b9a1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:13:04 -0000 --0016e644d5cceb0fd1049a23b9a1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 18, 2011 at 1:12 PM, Simon Josefsson wrote: > Nicholas Weaver writes: > > > Isn't this the whole point of SRV records? Why shouldn't we do them, > with the natural DNSSEC authenticated flow of using the SRV record(s) to > find the ports, and then lookup the key(s) associated with the ports > selected. > > > > (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by > ports -> (hostname, port, key)+ > > Many applications does not work like that today. Users are typically > asked to enter a hostname, and can provide an optional port number if > the default port number for the application protocol (e.g., 25 for smtp) > is not the intended port. > > I believe DANE should be agnostic of whether SRV are used or not. Thus > DANE could support both these look mechanisms: > > 1) SRV record used > > (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by > ports -> (hostname, port, key)+ > > 2) SRV record not used > > (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+ > > This appears to be another argument for the option to prefix the > hostname with a port number (not service), as in: > > I agree. Having the ability to declare a site wide policy is going to be totally fine for many sites and completely meet their needs. Other sites are going to need to have more fine control on their trust configuration because they do things that are either more complex or involve outsourcing or for other reasons. I don't see any problem in having a scheme that supports more than one layer of detail, particularly when the constraints imposed by DNS wildcards and CNAMES are considered. Those constraints mean that it is not possible to use prefix records in the way that we would want to use them unless the prefix is attached to a name that is canonical. So any discovery scheme would have to have at least two stages: Stage 1: Lookup the domain name without prefix, collect general records. This stage could return a flag that says 'more detailed information available' which would trigger a stage 2 Stage 2: Lookup protocol prefixed records for the service This would be where SRV records would be handled and could be the place where additional, more specific keying information is dealt with. This could if necessary then trigger a third layer of resolution that would be specific to the host. Stage 3: Lookup protocol and port prefixed records for the host Although such discovery requires three logical round trips it is entirely feasible to elide this and combine all the round trips into one through use of ENDS(0) extensions. -- Website: http://hallambaker.com/ --0016e644d5cceb0fd1049a23b9a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 18, 2011 at 1:12 PM, Simon J= osefsson <simon= @josefsson.org> wrote:
Nicholas Weaver <nweaver@icsi.berkeley.edu> writes:

> Isn't this the whole point of SRV records? =A0Why shouldn't we= do them, with the natural DNSSEC authenticated flow of using the SRV recor= d(s) to find the ports, and then lookup the key(s) associated with the port= s selected.
>
> (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Loo= kup keys by ports -> (hostname, port, key)+

Many applications does not work like that today. =A0Users are typical= ly
asked to enter a hostname, and can provide an optional port number if
the default port number for the application protocol (e.g., 25 for smtp) is not the intended port.

I believe DANE should be agnostic of whether SRV are used or not. =A0Thus DANE could support both these look mechanisms:

1) SRV record used

(hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup k= eys by ports -> (hostname, port, key)+

2) SRV record not used

(hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+
This appears to be another argument for the option to prefix the
hostname with a port number (not service), as in:

=
I agree.

Having the ability to decl= are a site wide policy is going to be totally fine for many sites and compl= etely meet their needs.

Other sites are going to need to have more fine control= on their trust configuration because they do things that are either more c= omplex or involve outsourcing or for other reasons.


I don't see any problem in having a scheme that sup= ports more than one layer of detail, particularly when the constraints impo= sed by DNS wildcards and CNAMES are considered.

Those constraints mean that it is not possible to use prefix records in the= way that we would want to use them unless the prefix is attached to a name= that is canonical.


So any discover= y scheme would have to have at least two stages:

Stage 1: Lookup the domain name without prefix, collect= general records.

This stage could return a flag t= hat says 'more detailed information available' which would trigger = a stage 2

Stage 2: Lookup protocol prefixed records for the servi= ce

This would be where SRV records would be handle= d and could be the place where additional, more specific keying information= is dealt with.

This could if necessary then trigger a third layer of r= esolution that would be specific to the host.

Stag= e 3: Lookup protocol and port prefixed records for the host


Although such discovery requires three logical ro= und trips it is entirely feasible to elide this and combine all the round t= rips into one through use of ENDS(0) extensions.

--
Website: http://hallambaker.com/
--0016e644d5cceb0fd1049a23b9a1-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2503A705C for ; Tue, 18 Jan 2011 10:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.21 X-Spam-Level: X-Spam-Status: No, score=-8.21 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKS74BcYw1CH for ; Tue, 18 Jan 2011 10:43:17 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 5FCB63A6E32 for ; Tue, 18 Jan 2011 10:43:17 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=tVQTN/yQelMd9G8gyUBRrWgWHZ7Qgvpa/Y19LaduOH2IuQU0pvX278zC 3mmqeJPVH0OyoBYZE7X80S/3O+qC5RMR0dG6Lk5dY2aYxoxkjwzlnfCtU /TTWhb6Gkdi48FB; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1295376356; x=1326912356; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Wouters=20,=20Paul =20Hoffman=20|CC:=20"keyassure@iet f.org"=20|Date:=20Tue,=2018=20Jan=202 011=2011:45:52=20-0700|Subject:=20RE:=20[keyassure]=20Pos sible=20fix=20for=20pkix/dane=20certificate=20disagreemen t|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABEB1A10E6 36@DEN-MEXMS-001.corp.ebay.com>|References:=20=0D=0A=09<4D334A39. 9050109@gmail.com>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<4D3448C6.4040205@nic .cz>=0D=0A=09=0D=0A=09<4D34538F.9010001@nic.cz>=0D =0A=09=0D=0A=09=0D=0A=09<4D3469EA.5000509@v pnc.org>=0D=0A=09=0D=0A=09<4D3478B7.8020707@vpnc.org>=0D =0A=20|In-Reply-To:=20|Content-Transfer-Encoding:=20quo ted-printable|MIME-Version:=201.0; bh=05n8k6G89ztdjm8Yao0ZcoC1WIo84pThh4EhqRWDwms=; b=FWwCLo8Dnifhs7sfwMBXTQbSBioUdQsj84M/SrbXrVkmay8Q4Gm49IwT 0CRM/QZf5zMHt2tjtO7xB9gk+nC78EQs0pAQCV8VhrWOo2JleUfxvkUsj c85Hh21QNj6dkBI; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,339,1291622400"; d="scan'208";a="844194" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 18 Jan 2011 10:45:55 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-003.corp.ebay.com ([10.241.17.54]) with mapi; Tue, 18 Jan 2011 11:45:54 -0700 From: "Steingruebl, Andy" To: Paul Wouters , Paul Hoffman Date: Tue, 18 Jan 2011 11:45:52 -0700 Thread-Topic: [keyassure] Possible fix for pkix/dane certificate disagreement Thread-Index: Acu2dT9dM9u+Fp9lQpqYaSLfLhPZ0gAymOig Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB1A10E636@DEN-MEXMS-001.corp.ebay.com> References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> <4D3478B7.8020707@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: CQB8ueFzu+cAuSIXbeLkpg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:43:20 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Paul Wouters =20 > While most believe the existence of DANE itself signifies the preference, > Phillip does not agree. A specific sub-type in section 2 for TLSA would a= ddress > this. Not sure where to add this point but I also believe this should not be an a= ll/nothing choice. I expect we would not deploy in isolation, completely d= itch our existing EV support, etc. I intend to use something like DANE to = get exclusivity, not (initially?) separation from the existing CA world. - Andy Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C35B3A6F0B for ; Tue, 18 Jan 2011 10:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7KETGEou2Dh for ; Tue, 18 Jan 2011 10:09:55 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id E3BA23A704D for ; Tue, 18 Jan 2011 10:09:54 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0IICMiv009734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jan 2011 19:12:24 +0100 From: Simon Josefsson To: Nicholas Weaver References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110118:paul.hoffman@vpnc.org::8CSACZ79Lof+VjqQ:EHKH X-Hashcash: 1:22:110118:keyassure@ietf.org::RQmH/NrzeU/9ldTK:Jo1J X-Hashcash: 1:22:110118:nweaver@icsi.berkeley.edu::XsHO4o8pX45gSmdY:EAC6 Date: Tue, 18 Jan 2011 19:12:22 +0100 In-Reply-To: <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> (Nicholas Weaver's message of "Tue, 18 Jan 2011 08:27:55 -0800") Message-ID: <877he2hyih.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:09:56 -0000 Nicholas Weaver writes: > Isn't this the whole point of SRV records? Why shouldn't we do them, with the natural DNSSEC authenticated flow of using the SRV record(s) to find the ports, and then lookup the key(s) associated with the ports selected. > > (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+ Many applications does not work like that today. Users are typically asked to enter a hostname, and can provide an optional port number if the default port number for the application protocol (e.g., 25 for smtp) is not the intended port. I believe DANE should be agnostic of whether SRV are used or not. Thus DANE could support both these look mechanisms: 1) SRV record used (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+ 2) SRV record not used (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+ This appears to be another argument for the option to prefix the hostname with a port number (not service), as in: _110.mail.example.org IN ... /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6270E3A7045 for ; Tue, 18 Jan 2011 10:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQc1JE2uMJ4y for ; Tue, 18 Jan 2011 10:05:12 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 097983A6F0B for ; Tue, 18 Jan 2011 10:05:11 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0II7bpt009442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jan 2011 19:07:38 +0100 From: Simon Josefsson To: Paul Hoffman References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110118:keyassure@ietf.org::n4Qpb5+6Qrk++0Vw:7YgZ X-Hashcash: 1:22:110118:paul.hoffman@vpnc.org::t0NQnr0snFxgdn3G:6XWT Date: Tue, 18 Jan 2011 19:07:37 +0100 In-Reply-To: <4D35B941.9020009@vpnc.org> (Paul Hoffman's message of "Tue, 18 Jan 2011 08:01:05 -0800") Message-ID: <87bp3ehyqe.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:05:13 -0000 Paul Hoffman writes: > On 1/18/11 5:01 AM, Simon Josefsson wrote: >> Warren Kumari writes: >> >>> I was hoping that would be able to stick to one open item at a time >>> but the discussions on #17 (Should the first doc be TLS only or try be >>> everything to everyone?) has wrapped directly to this issue, so: >>> >>> I'm opening up Issue #1 (Deal with multiple TLS-based services under >>> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) >>> [ Dons frock, flaps hands, twirls the incense burner three times to >>> the left, presses button to make water squirt out of daisy add >>> releases the 12 doves -- now it is official ] >>> ----- >>> Description: >>> How to deal with multiple TLS-based services running under one domain >>> name, such as a POP, IMAP, and SMTP server all running on >>> mail.example.com. >>> >>> Suggestions so far include: >>> Prefacing the host name with a service name (_pop.mail.example.com) >>> Prefacing the host name with a port number (_110.mail.example.com) >>> Returning a set of records that contain port numbers in the response. >>> SRV / ESRV >>> >>> ----- >> >> I believe this is an important problem that must be supported. I >> brought this up earlier: >> >> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html >> >> Service names are not sufficient here, since you can have a SMTP server >> listening on port 25, 80, 587, 4711, 11147 etc and using the service >> name would not differentiate these but that may be important. >> >> A combination of service name and port number, like >> _4711._smtp.mail.example.com, is another option and does carry more >> information than only port numbers would -- however it is not clear to >> me if this has any practical advantage. >> >> Port numbers could be easier to implement -- depending on >> implementations, parts of this could be done by the TLS library, and it >> often does not know what kind of application protocol is running on top >> of TLS. > > When you say "port numbers could be easier to implement", do you port > numbers in "Prefacing the host name..." or "Returning a set of > records..."? I mean "Prefacing the host name...". I don't immediately see how SRV would be used here, so I don't have an opinion on that approach. Maybe someone could add an example, similar to the existing examples for the other proposals, to this ticket? /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E43E3A7023 for ; Tue, 18 Jan 2011 09:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bTvOcCe-u5W for ; Tue, 18 Jan 2011 09:54:43 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 71F623A6E78 for ; Tue, 18 Jan 2011 09:54:43 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 53B2836A598; Tue, 18 Jan 2011 09:57:21 -0800 (PST) References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> <4D35CFC5.8040705@vpnc.org> In-Reply-To: <4D35CFC5.8040705@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <1B086403-4351-4E8C-86DE-AD138CA33642@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 18 Jan 2011 09:57:21 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:54:45 -0000 On Jan 18, 2011, at 9:37 AM, Paul Hoffman wrote: > On 1/18/11 8:27 AM, Nicholas Weaver wrote: >>=20 >> On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote: >>>>=20 >>>> I believe this is an important problem that must be supported. I >>>> brought this up earlier: >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html >>>>=20 >>>> Service names are not sufficient here, since you can have a SMTP = server >>>> listening on port 25, 80, 587, 4711, 11147 etc and using the = service >>>> name would not differentiate these but that may be important. >>>>=20 >>>> A combination of service name and port number, like >>>> _4711._smtp.mail.example.com, is another option and does carry more >>>> information than only port numbers would -- however it is not clear = to >>>> me if this has any practical advantage. >>>>=20 >>>> Port numbers could be easier to implement -- depending on >>>> implementations, parts of this could be done by the TLS library, = and it >>>> often does not know what kind of application protocol is running on = top >>>> of TLS. >>>=20 >>> When you say "port numbers could be easier to implement", do you = port numbers in "Prefacing the host name..." or "Returning a set of = records..."? >>=20 >> Isn't this the whole point of SRV records? Why shouldn't we do them, = with the natural DNSSEC authenticated flow of using the SRV record(s) to = find the ports, and then lookup the key(s) associated with the ports = selected. >=20 > Yes. However, that doesn't answer the question in issue #1, which is = why I was asking Simon (and now you) for clarification on which solution = you prefer for the protocol. >=20 >> (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup = keys by ports -> (hostname, port, key)+ >>=20 >> Yes, this adds an additional RTT of lookup latency for the SRV = lookup, but since there is a common (but not always universal) mapping = of service to common ports, you could do, in parallel [1] >> (host, service) -> Lookup SRV >> (host, port) -> Lookup Speculative Key >=20 > This sounds like you prefer "Prefacing the host name with a port = number (_110.mail.example.com)" over "Returning a set of records that = contain port numbers in the response", but you (and Simon) were not = specific. I think the answer depends on if you are using SRV or not: So with SRV, I'd personally like the convention of _service._transport.hostname=20 _smtp._tcp.mail.example.com SRV -> 0 5 25 mail.example.com _25._tcp.mail.example.com NEW_RR -> key = material/thumbprint/certificate/whatever. So yeah, I'd personally like a split model: SRV is used to find the port for a service the key record is used to find the key on a port. Without using SRV, you'd need to have a combined record _service._transport.hostname -> key material + port number because otherwise, how do you know which port for which service, which = is IMO, necessary to really get things to work? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B8B3A6FAB for ; Tue, 18 Jan 2011 09:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.722 X-Spam-Level: X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaaLs2wDLxox for ; Tue, 18 Jan 2011 09:34:33 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3D17A3A6F6C for ; Tue, 18 Jan 2011 09:34:33 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IHb979049470 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 10:37:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D35CFC5.8040705@vpnc.org> Date: Tue, 18 Jan 2011 09:37:09 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> In-Reply-To: <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:34:34 -0000 On 1/18/11 8:27 AM, Nicholas Weaver wrote: > > On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote: >>> >>> I believe this is an important problem that must be supported. I >>> brought this up earlier: >>> >>> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html >>> >>> Service names are not sufficient here, since you can have a SMTP server >>> listening on port 25, 80, 587, 4711, 11147 etc and using the service >>> name would not differentiate these but that may be important. >>> >>> A combination of service name and port number, like >>> _4711._smtp.mail.example.com, is another option and does carry more >>> information than only port numbers would -- however it is not clear to >>> me if this has any practical advantage. >>> >>> Port numbers could be easier to implement -- depending on >>> implementations, parts of this could be done by the TLS library, and it >>> often does not know what kind of application protocol is running on top >>> of TLS. >> >> When you say "port numbers could be easier to implement", do you port numbers in "Prefacing the host name..." or "Returning a set of records..."? > > Isn't this the whole point of SRV records? Why shouldn't we do them, with the natural DNSSEC authenticated flow of using the SRV record(s) to find the ports, and then lookup the key(s) associated with the ports selected. Yes. However, that doesn't answer the question in issue #1, which is why I was asking Simon (and now you) for clarification on which solution you prefer for the protocol. > (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+ > > Yes, this adds an additional RTT of lookup latency for the SRV lookup, but since there is a common (but not always universal) mapping of service to common ports, you could do, in parallel [1] > (host, service) -> Lookup SRV > (host, port) -> Lookup Speculative Key This sounds like you prefer "Prefacing the host name with a port number (_110.mail.example.com)" over "Returning a set of records that contain port numbers in the response", but you (and Simon) were not specific. > And use the speculative lookup if the SRV matches. I think this will be a likely action by applications. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC6D28C146 for ; Tue, 18 Jan 2011 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEZyes3JTB01 for ; Tue, 18 Jan 2011 08:25:18 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id BF0F828C175 for ; Tue, 18 Jan 2011 08:25:18 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 68D7536A5A3; Tue, 18 Jan 2011 08:27:56 -0800 (PST) References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> <4D35B941.9020009@vpnc.org> In-Reply-To: <4D35B941.9020009@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <22F81E91-F965-477E-A28C-EDF2FB54F7A2@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Tue, 18 Jan 2011 08:27:55 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:25:19 -0000 On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote: >>=20 >> I believe this is an important problem that must be supported. I >> brought this up earlier: >>=20 >> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html >>=20 >> Service names are not sufficient here, since you can have a SMTP = server >> listening on port 25, 80, 587, 4711, 11147 etc and using the service >> name would not differentiate these but that may be important. >>=20 >> A combination of service name and port number, like >> _4711._smtp.mail.example.com, is another option and does carry more >> information than only port numbers would -- however it is not clear = to >> me if this has any practical advantage. >>=20 >> Port numbers could be easier to implement -- depending on >> implementations, parts of this could be done by the TLS library, and = it >> often does not know what kind of application protocol is running on = top >> of TLS. >=20 > When you say "port numbers could be easier to implement", do you port = numbers in "Prefacing the host name..." or "Returning a set of = records..."? Isn't this the whole point of SRV records? Why shouldn't we do them, = with the natural DNSSEC authenticated flow of using the SRV record(s) to = find the ports, and then lookup the key(s) associated with the ports = selected. (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by = ports -> (hostname, port, key)+ Yes, this adds an additional RTT of lookup latency for the SRV lookup, = but since there is a common (but not always universal) mapping of = service to common ports, you could do, in parallel [1] (host, service) -> Lookup SRV (host, port) -> Lookup Speculative Key And use the speculative lookup if the SRV matches. And its not like there are going to be many cases where a = middlebox/proxy/server barfs on SRV records but allows the key-lookup = records. [1] Given how aggressively browsers prefetch A records these days, this = seems like a trivial increase in overhead by comparison. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB9528C176 for ; Tue, 18 Jan 2011 07:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.718 X-Spam-Level: X-Spam-Status: No, score=-101.718 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ-1KrSJrpv2 for ; Tue, 18 Jan 2011 07:58:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0BE9928C175 for ; Tue, 18 Jan 2011 07:58:29 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IG15Si045249 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 09:01:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D35B941.9020009@vpnc.org> Date: Tue, 18 Jan 2011 08:01:05 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <87y66ijrhm.fsf@latte.josefsson.org> In-Reply-To: <87y66ijrhm.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:58:29 -0000 On 1/18/11 5:01 AM, Simon Josefsson wrote: > Warren Kumari writes: > >> I was hoping that would be able to stick to one open item at a time >> but the discussions on #17 (Should the first doc be TLS only or try be >> everything to everyone?) has wrapped directly to this issue, so: >> >> I'm opening up Issue #1 (Deal with multiple TLS-based services under >> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) >> [ Dons frock, flaps hands, twirls the incense burner three times to >> the left, presses button to make water squirt out of daisy add >> releases the 12 doves -- now it is official ] >> ----- >> Description: >> How to deal with multiple TLS-based services running under one domain >> name, such as a POP, IMAP, and SMTP server all running on >> mail.example.com. >> >> Suggestions so far include: >> Prefacing the host name with a service name (_pop.mail.example.com) >> Prefacing the host name with a port number (_110.mail.example.com) >> Returning a set of records that contain port numbers in the response. >> SRV / ESRV >> >> ----- > > I believe this is an important problem that must be supported. I > brought this up earlier: > > http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html > > Service names are not sufficient here, since you can have a SMTP server > listening on port 25, 80, 587, 4711, 11147 etc and using the service > name would not differentiate these but that may be important. > > A combination of service name and port number, like > _4711._smtp.mail.example.com, is another option and does carry more > information than only port numbers would -- however it is not clear to > me if this has any practical advantage. > > Port numbers could be easier to implement -- depending on > implementations, parts of this could be done by the TLS library, and it > often does not know what kind of application protocol is running on top > of TLS. When you say "port numbers could be easier to implement", do you port numbers in "Prefacing the host name..." or "Returning a set of records..."? Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292553A7027 for ; Tue, 18 Jan 2011 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRaZgOzJR4Se for ; Tue, 18 Jan 2011 07:56:48 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6D3373A702D for ; Tue, 18 Jan 2011 07:56:48 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IFxPOS045142 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 18 Jan 2011 08:59:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D35B8DC.2040707@vpnc.org> Date: Tue, 18 Jan 2011 07:59:24 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D3403D4.6090702@nic.cz> <8739oql6o7.fsf@latte.josefsson.org> In-Reply-To: <8739oql6o7.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:56:49 -0000 On 1/18/11 4:47 AM, Simon Josefsson wrote: > Ondøej Surý writes: > >> On 16.1.2011 15:27, Simon Josefsson wrote: >>> As a reminder, TLS supports more than X.509. The current draft is >>> hard wired for X.509 only. >> >> Can we untie the draft from X.509? > > It is technically simple to do (compare my draft with the current one), > but the impression I got was that authors preferred not to. There was not much interest originally in doing so, but it sounds like more people are interested now. I just sent a proposal to untie types 1 and 2 from PKIX or even certificates at all. However, if you want to possibly untie types 3 and 4 from PKIX, it would be really useful to see text first. I have no idea how to make OpenPGP work with them, and they make no sense for bare keys, I think. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF65028C1A7 for ; Tue, 18 Jan 2011 07:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.715 X-Spam-Level: X-Spam-Status: No, score=-101.715 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O2hewB+Uk-c for ; Tue, 18 Jan 2011 07:53:47 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E78BF28C17F for ; Tue, 18 Jan 2011 07:53:46 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0IFu305045049 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 08:56:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D35B812.50801@vpnc.org> Date: Tue, 18 Jan 2011 07:56:02 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] what PKIX is not X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:53:47 -0000 Thank you very much for this! It helps move the discussion forwards. On 1/17/11 2:59 PM, Stephen Kent wrote: > I've seen several references to PKIX in the context of TLS that suggest > some confusion. > > It appears that some folks believe that the trust anchor (TA) management > model that browsers have adopted is somehow a PKIX-based requirement. > That is not true. Browser vendors have adopted a TA model that is > generally compliant with what X.509 and PKIX require, but neither X.509 > nor PKIX mandate that model. So, for example, if DANE defines a way to > distribute TAs via the DNS, that will not conflict with PKIX standards. We currently don't talk in the document about the certificate association made by TLSA types 3 and 4 as being temporary trust anchors, but if we did so, it might clear up any confusion that people have about the relationship between TLSA and PKIX. > The checks used to validate a TA are not specified in the core PKIX > specs. (We do have other standards the define ways to deliver and > validate TA material, but they are not the only game in town, e.g., see > the SIDR WG spec on how to do this.) Section 6.1.1 of RFC 5280 says that > the TA info used to validate a cert path includes > > (1) the trusted issuer name, > > (2) the trusted public key algorithm, > > (3) the trusted public key, and > > (4) optionally, the trusted public key parameters associated > with the public key. > > So, if DANE defines a way to populate items 1-3 (and, optionally 4) from > data acquired from the DNS, it can satisfy the 5280 requirements for a > TA. This could be dine via a self-signed cert, or even using a raw key. > It's up to DANE to decide what checks it imposes on the data it > retrieves from the DNS before using that data to validate an EE cert for > a TLS server, for example. We can clear this up for types 3 and 4 by saying that the trust anchors gotten from TLSA act as full trust anchors for the client for the life of the TTL of the TLSA RR. > If DANE decides that it will use a raw key from the DNS directly in a > TLS handshake, for example, then it moves outside the PKIX/X.509 realm, > as no certs are being validated. DANE would then need to decide what, if > any, constraints it would impose of how the key is used, e.g., matched > to the DNS name for a server. Exactly. We could clear up types 1 and 2 by not calling them certificates but instead binary blobs that are compared against the first binary blob in the TLS "Certificate" structure. That way, if there is later a standards-track update to TLS to allow OpenPGP certs or bare keys or whatnot, TLSA will already work with those. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F5A3A7011 for ; Tue, 18 Jan 2011 07:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbiR3ithWwMQ for ; Tue, 18 Jan 2011 07:12:12 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7EC3B3A7010 for ; Tue, 18 Jan 2011 07:12:12 -0800 (PST) Received: by gyd12 with SMTP id 12so2611811gyd.31 for ; Tue, 18 Jan 2011 07:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bjeb7LYdFTmc7E8PGPi4PC/55vTywy3DGrrTVs1IDlM=; b=Y5wXXKMxu7FPHkQ3ArhRT9zAWP6aItV0Rnb7V+mhL+cS00SmrCYEvwC5MjiJakoaU2 DIl6HvnPEdF72+n6OKtbnUpUKxO2E5ch2xzXeLLgbhrOlxHXFVBEwpDuD3zALbfJcQuq KJ42Oy8WMewt6tG12o7BX7B3IgfGF5bgNc21Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YYi8KlTmkSgyygSg+obvf4fA3LB7Npt7/FgF6cQGJ1EeSqTN3vxVujVAQDHH3xdhIE YEbQfb09kxJYFjpQS+jq+y20OOGYJQHDeYV89GnW9ASrxq8FEkukaUt/CXQ48mPI+3yg 3cQsDP59veoWndFtO00IH4vd+f302GI1+sT+Q= MIME-Version: 1.0 Received: by 10.100.48.13 with SMTP id v13mr1026508anv.69.1295363689505; Tue, 18 Jan 2011 07:14:49 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 18 Jan 2011 07:14:49 -0800 (PST) In-Reply-To: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> References: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> Date: Tue, 18 Jan 2011 10:14:49 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e644bc2e916828049a205cbf Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:12:14 -0000 --0016e644bc2e916828049a205cbf Content-Type: text/plain; charset=ISO-8859-1 Martin seems to be referring to the original PGP paper rather than the code that Phil Z. actually implemented. In practice X.509 started to absorb features from PGP very early on. The single rooted hierarchy was gone in 1995 and cross certification was introduced about the same time and is increasingly deployed and used. In practice it has been possible to do everything that can be done in PGP in X.509 for some time now. The only practical difference is that in PGP everyone is a trust provider and every key can be used for trust provision and in X.509 anyone can be a trust provider but this is a distinct role and the keys used for this purpose are separate from end entity keys. The systems have already converged. PGP key signing has never enjoyed any real market success as a host authentication mechanism and even if it had the idea of a monolithic PKI hierarchy like DNSSEC is entirely antithetical to the PGP design goals. Its like demanding that the Playboy mansion car park be redesigned to accomodate the Pope-mobile. On Tue, Jan 18, 2011 at 9:17 AM, Martin Rex wrote: > Stephen Kent wrote: > > > > The use of the phrase "n-factor authentication" in your message does > > not match what is commonly accepted in the security field. In > > multi-factor authentication the factors represent different types of > > authentication data, not multiple instances of auth data of the same > > type. > > You're correct. The term(s) 2-Factor and Multi-Factor have been > squatted by marketeers and regulators for a very specific purpose. > > > I was trying to describe a specific security feature at an abstract > level using invalid terminology. > > X.509/PKIX credentials are confirmed as valid with one single digital > signature. There is no means (native to X.509) to require multiple > independent signatures (logical "AND"). On the contrary, when there > are multiple omipotent CA trusted as credential signers (logical "OR"), > then the bottom-line security is significantly impaired. > > In the existing TLS X.509 PKI there is currently no means for a server > or domain admin to limit/restrict which CAs are allowed to confirm > a server credential as valid. Any single one will do. And according > to this research: http://www.eff.org/files/DefconSSLiverse.pdf > (page 19) there are plenty of CAs for attackers to choose from. > > > DANE could become a band-aid to mitigate this PKIX security problem, > by establishing a secondary requirement vaguely similar to "dual control" > (http://www.yourwindow.to/information-security/gl_dualcontrol.htm) > > One possible usage of DANE would be to limit which specific CAs from > those considered valid CAs under the TLS X.509 PKI, are also valid > signers for a particular server or a particular DNS domain. > > With the PGP web-of-trust model, it would be technically possible > to require any number of additional signers for a server credential > before it is considered valid. > > > But in order to gauge the effective security, one needs to look at > the overall picture not just one specific procedure. > > The TLS X.509 PKI traditionally has weaknesses, because it keys off > the WHOIS database for issuing server certs, and some CA issuing procedures > involven unauthenticated SMTP Email. DANE will inherit its properties > from the DNS administration procedures, so what matters is the difficulty > of getting malicious DNS records into the DNS database that feeds > into the automatic DNSSEC record signing service. > > > Two factor authentication schemes for humans may have similar problems. > Although an authentication scheme involving a fingerprint and a token > counts as two factor, a successful attack on this scheme usually > requires only one single assault on one person. > > > Similarly, a procedure to register/establish new multi-factor > authentication > credentials might require only one single proof of identity (ID-card). > > > Requiring multiple signatures on a server key in a PGP web-of-trust style > may improve security. But if all of the necessary signatures can be > obtained with the exact same "proof of ownership", then this mostly > adds complexity without value (it would only protect from exploration > of accidental unique flaws in the validation/issuing procedures > of individual signers). > > > -Martin > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e644bc2e916828049a205cbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Martin seems to be referring to the original PGP paper rather than the code= that Phil Z. actually implemented.


In pr= actice X.509 started to absorb features from PGP very early on. The single = rooted hierarchy was gone in 1995 and cross certification was introduced ab= out the same time and is increasingly deployed and used.

In practice it has been possible to do everything that = can be done in PGP in X.509 for some time now. The only practical differenc= e is that in PGP everyone is a trust provider and every key can be used for= trust provision and in X.509 anyone can be a trust provider but this is a = distinct role and the keys used for this purpose are separate from end enti= ty keys.


The systems have already converged. PGP = key signing has never enjoyed any real market success as a host authenticat= ion mechanism and even if it had the idea of a monolithic PKI hierarchy lik= e DNSSEC is entirely antithetical to the PGP design goals.

Its like demanding that the Playboy mansion car park be= redesigned to accomodate the Pope-mobile.



On Tue, Jan 18, 2011 at 9:17 AM, Mar= tin Rex <mrex@sap.com<= /a>> wrote:
Stephen Kent wrote:
>
> The use of the phrase "n-factor authentication" in your mess= age does
> not match what is commonly accepted in the security field. =A0In
> multi-factor authentication the factors represent different types of > authentication data, not multiple instances of auth data of the same > type.

You're correct. =A0The term(s) 2-Factor and Multi-Factor have been
squatted by marketeers and regulators for a very specific purpose.


I was trying to describe a specific security feature at an abstract
level using invalid terminology.

X.509/PKIX credentials are confirmed as valid with one single digital
signature. There is no means (native to X.509) to require multiple
independent signatures (logical "AND"). =A0On the contrary, when = there
are multiple omipotent CA trusted as credential signers (logical "OR&q= uot;),
then the bottom-line security is significantly impaired.

In the existing TLS X.509 PKI there is currently no means for a server
or domain admin to limit/restrict which CAs are allowed to confirm
a server credential as valid. =A0Any single one will do. =A0And according to this research: =A0http://www.eff.org/files/DefconSSLiverse.pdf
(page 19) there are plenty of CAs for attackers to choose from.


DANE could become a band-aid to mitigate this PKIX security problem,
by establishing a secondary requirement vaguely similar to "dual contr= ol"
(http://www.yourwindow.to/information-security/gl_dualc= ontrol.htm)

One possible usage of DANE would be to limit which specific CAs from
those considered valid CAs under the TLS X.509 PKI, are also valid
signers for a particular server or a particular DNS domain.

With the PGP web-of-trust model, it would be technically possible
to require any number of additional signers for a server credential
before it is considered valid.


But in order to gauge the effective security, one needs to look at
the overall picture not just one specific procedure.

The TLS X.509 PKI traditionally has weaknesses, because it keys off
the WHOIS database for issuing server certs, and some CA issuing procedures=
involven unauthenticated SMTP Email. =A0DANE will inherit its properties from the DNS administration procedures, so what matters is the difficulty of getting malicious DNS records into the DNS database that feeds
into the automatic DNSSEC record signing service.


Two factor authentication schemes for humans may have similar problems.
Although an authentication scheme involving a fingerprint and a token
counts as two factor, a successful attack on this scheme usually
requires only one single assault on one person.


Similarly, a procedure to register/establish new multi-factor authenticatio= n
credentials might require only one single proof of identity (ID-card).


Requiring multiple signatures on a server key in a PGP web-of-trust style may improve security. =A0But if all of the necessary signatures can be
obtained with the exact same "proof of ownership", then this most= ly
adds complexity without value (it would only protect from exploration
of accidental unique flaws in the validation/issuing procedures
of individual signers).


-Martin

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



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

--0016e644bc2e916828049a205cbf-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428203A6FFF for ; Tue, 18 Jan 2011 06:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.154 X-Spam-Level: X-Spam-Status: No, score=-10.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SN4-1yBflnz for ; Tue, 18 Jan 2011 06:16:38 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C9B173A6FFE for ; Tue, 18 Jan 2011 06:16:37 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0IEHgMG006312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jan 2011 15:17:42 +0100 (MET) From: Martin Rex Message-Id: <201101181417.p0IEHHek011249@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Tue, 18 Jan 2011 15:17:17 +0100 (MET) In-Reply-To: from "Stephen Kent" at Jan 17, 11 06:01:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 14:16:39 -0000 Stephen Kent wrote: > > The use of the phrase "n-factor authentication" in your message does > not match what is commonly accepted in the security field. In > multi-factor authentication the factors represent different types of > authentication data, not multiple instances of auth data of the same > type. You're correct. The term(s) 2-Factor and Multi-Factor have been squatted by marketeers and regulators for a very specific purpose. I was trying to describe a specific security feature at an abstract level using invalid terminology. X.509/PKIX credentials are confirmed as valid with one single digital signature. There is no means (native to X.509) to require multiple independent signatures (logical "AND"). On the contrary, when there are multiple omipotent CA trusted as credential signers (logical "OR"), then the bottom-line security is significantly impaired. In the existing TLS X.509 PKI there is currently no means for a server or domain admin to limit/restrict which CAs are allowed to confirm a server credential as valid. Any single one will do. And according to this research: http://www.eff.org/files/DefconSSLiverse.pdf (page 19) there are plenty of CAs for attackers to choose from. DANE could become a band-aid to mitigate this PKIX security problem, by establishing a secondary requirement vaguely similar to "dual control" (http://www.yourwindow.to/information-security/gl_dualcontrol.htm) One possible usage of DANE would be to limit which specific CAs from those considered valid CAs under the TLS X.509 PKI, are also valid signers for a particular server or a particular DNS domain. With the PGP web-of-trust model, it would be technically possible to require any number of additional signers for a server credential before it is considered valid. But in order to gauge the effective security, one needs to look at the overall picture not just one specific procedure. The TLS X.509 PKI traditionally has weaknesses, because it keys off the WHOIS database for issuing server certs, and some CA issuing procedures involven unauthenticated SMTP Email. DANE will inherit its properties from the DNS administration procedures, so what matters is the difficulty of getting malicious DNS records into the DNS database that feeds into the automatic DNSSEC record signing service. Two factor authentication schemes for humans may have similar problems. Although an authentication scheme involving a fingerprint and a token counts as two factor, a successful attack on this scheme usually requires only one single assault on one person. Similarly, a procedure to register/establish new multi-factor authentication credentials might require only one single proof of identity (ID-card). Requiring multiple signatures on a server key in a PGP web-of-trust style may improve security. But if all of the necessary signatures can be obtained with the exact same "proof of ownership", then this mostly adds complexity without value (it would only protect from exploration of accidental unique flaws in the validation/issuing procedures of individual signers). -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B0E3A6DAA for ; Tue, 18 Jan 2011 04:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt063wrO274j for ; Tue, 18 Jan 2011 04:58:52 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 671923A6FE4 for ; Tue, 18 Jan 2011 04:58:38 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0ID19G5024985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jan 2011 14:01:11 +0100 From: Simon Josefsson To: Warren Kumari References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110118:keyassure@ietf.org::vMl32vRstqJyt7/R:0BvN X-Hashcash: 1:22:110118:warren@kumari.net::bNUmJ5qapgfpn9wh:VFFK Date: Tue, 18 Jan 2011 14:01:09 +0100 In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> (Warren Kumari's message of "Mon, 17 Jan 2011 15:46:10 -0500") Message-ID: <87y66ijrhm.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:59:02 -0000 Warren Kumari writes: > I was hoping that would be able to stick to one open item at a time > but the discussions on #17 (Should the first doc be TLS only or try be > everything to everyone?) has wrapped directly to this issue, so: > > I'm opening up Issue #1 (Deal with multiple TLS-based services under > one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) > [ Dons frock, flaps hands, twirls the incense burner three times to > the left, presses button to make water squirt out of daisy add > releases the 12 doves -- now it is official ] > ----- > Description: > How to deal with multiple TLS-based services running under one domain > name, such as a POP, IMAP, and SMTP server all running on > mail.example.com. > > Suggestions so far include: > Prefacing the host name with a service name (_pop.mail.example.com) > Prefacing the host name with a port number (_110.mail.example.com) > Returning a set of records that contain port numbers in the response. > SRV / ESRV > > ----- I believe this is an important problem that must be supported. I brought this up earlier: http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html Service names are not sufficient here, since you can have a SMTP server listening on port 25, 80, 587, 4711, 11147 etc and using the service name would not differentiate these but that may be important. A combination of service name and port number, like _4711._smtp.mail.example.com, is another option and does carry more information than only port numbers would -- however it is not clear to me if this has any practical advantage. Port numbers could be easier to implement -- depending on implementations, parts of this could be done by the TLS library, and it often does not know what kind of application protocol is running on top of TLS. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E9B3A6F2F for ; Tue, 18 Jan 2011 04:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmYEUwsV0j6x for ; Tue, 18 Jan 2011 04:45:29 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 979413A6DAA for ; Tue, 18 Jan 2011 04:45:28 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0IClrAI024140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Jan 2011 13:47:55 +0100 From: Simon Josefsson To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= References: <4D3403D4.6090702@nic.cz> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110118:keyassure@ietf.org::0wO+YA2yglA5uMo4:6REK X-Hashcash: 1:22:110118:ondrej.sury@nic.cz::VaWPxcAXznlqdnif:Q8OC Date: Tue, 18 Jan 2011 13:47:52 +0100 In-Reply-To: <4D3403D4.6090702@nic.cz> (=?iso-8859-2?Q?=22Ond=F8ej_Sur=FD?= =?iso-8859-2?Q?=22's?= message of "Mon, 17 Jan 2011 09:54:44 +0100") Message-ID: <8739oql6o7.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 12:45:30 -0000 Ond=F8ej Sur=FD writes: > On 16.1.2011 15:27, Simon Josefsson wrote: >> As a reminder, TLS supports more than X.509. The current draft is >> hard wired for X.509 only. > > Can we untie the draft from X.509? It is technically simple to do (compare my draft with the current one), but the impression I got was that authors preferred not to. /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B98D3A6E74 for ; Tue, 18 Jan 2011 01:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTtKnnc5ClBB for ; Tue, 18 Jan 2011 01:40:00 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 2F7A03A6DAA for ; Tue, 18 Jan 2011 01:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=DhzaRRiuVWEIt55sDAwHCR2mig8KfHkBxI+xALv0Aic=; b=s/AXMvophm7ckb5+fBZEIBNMYNSVc1udzR21Oay0QyifWC76ZI7sLldo30He7g/Ad8FXgDqtjAplt RVcv/uvv3RjkFbm/Mds2zkT4ZYkHVjIPkDhKIzLgsizzKcHacr2fJDYmqOI1tc40sYT0lvANDoaEjs p7XNSqRDczlkbQ1U= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 18 Jan 2011 10:42:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Jakob Schlyter In-Reply-To: <4D354568.1020205@nic.cz> Date: Tue, 18 Jan 2011 10:42:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> <4D34959A.4050104@nic.cz> <4D349B38.80801@nic.cz> <4D354568.1020205@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 09:40:02 -0000 On 18 jan 2011, at 08.46, Ond=C5=99ej Sur=C3=BD wrote: > Since you have stripped rest of the mail it's unclear now. I was = talking about SRVNames in the Certificate as specified in RFC 4985 and = pointed out by Matt McCutchen (thanks Matt), and not about SRV DNS RRs. = While we may use SRV RR types as well to solve Issue#1, I wasn't talking = about them. I feel it's important to make that distinction, so we talk = about the same thing. Correct, we have two different mechanisms: - indicating service in the certificate itself (using SRVNames) - indicating service using the DNS hostname, e.g. = _http._tcp.example.com. IN TLSA ... It would be possible to use them separately or together. If I have a web = server and a mail server - with different certificates - at the host = mail.example.com, I could a) publish two TLSA RR at mail.example.com, each cert using SRVNames to = specify what service is used with what certificate b) publish one TLSA RR at _smtp._tcp.example.com and one at = _http._tcp.example.com. c) both (a) and (b) Phil; does this separation make sense? jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CECD3A6F6D for ; Mon, 17 Jan 2011 23:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVYQ6khyahKV for ; Mon, 17 Jan 2011 23:48:42 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id AC4543A6E7B for ; Mon, 17 Jan 2011 23:48:42 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 8366D73432C for ; Tue, 18 Jan 2011 08:51:18 +0100 (CET) Message-ID: <4D354676.5030101@nic.cz> Date: Tue, 18 Jan 2011 08:51:18 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:48:44 -0000 On 17.1.2011 21:46, Warren Kumari wrote: > I was hoping that would be able to stick to one open item at a time but > the discussions on #17 (Should the first doc be TLS only or try be > everything to everyone?) has wrapped directly to this issue, so: > > I'm opening up Issue #1 (Deal with multiple TLS-based services under one > domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) > [ Dons frock, flaps hands, twirls the incense burner three times to the > left, presses button to make water squirt out of daisy add releases the > 12 doves -- now it is official ] > ----- > Description: > How to deal with multiple TLS-based services running under one domain > name, such as a POP, IMAP, and SMTP server all running on mail.example.com. > > Suggestions so far include: > Prefacing the host name with a service name (_pop.mail.example.com) > Prefacing the host name with a port number (_110.mail.example.com) > Returning a set of records that contain port numbers in the response. > SRV / ESRV > > ----- I would suggest adding using the SRVNames certificate extension to this list. E.g. one would create multiple TLSA records, but each certificate would (if there's need) include SRVNames extension which would specify if it can be used for the protocol. Since we honor certificate data (with notable exception of self-signed) that should just work[*] for type 1/2 certs (EE). O. * - I don't know if there is a support for SRVNames cert extension in the current implementations, since I didn't know about RFC 4985 until yesterday. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519533A6E7B for ; Mon, 17 Jan 2011 23:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDfPBB1okSn5 for ; Mon, 17 Jan 2011 23:44:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 484A53A6E81 for ; Mon, 17 Jan 2011 23:44:13 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 3126573432C; Tue, 18 Jan 2011 08:46:48 +0100 (CET) Message-ID: <4D354568.1020205@nic.cz> Date: Tue, 18 Jan 2011 08:46:48 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> <4D34959A.4050104@nic.cz> <4D349B38.80801@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:44:16 -0000 On 17.1.2011 21:23, Phillip Hallam-Baker wrote: > > > On Mon, Jan 17, 2011 at 2:40 PM, Ondřej Surý > wrote: > > > Further thinking about this. It seems to me that we have two issues > here: > > Issue#1 - Multiple services at one name > > Issue#tbd - Ignoring (or not) certificate data in self-signed certs > > > Agreed > > The solution for Issue#1 might be usage of SRVNames. > > > I think so. SRV Names are the DNS way to address protocols, they are a > very powerful and useful tool. > > They also allow us to focus on a much narrower set of concerns at a > given instance. If we are talking about a record with an _https._tcp > prefix then I am very happy to only be talking about TLS and only > talking about HTTP. Since you have stripped rest of the mail it's unclear now. I was talking about SRVNames in the Certificate as specified in RFC 4985 and pointed out by Matt McCutchen (thanks Matt), and not about SRV DNS RRs. While we may use SRV RR types as well to solve Issue#1, I wasn't talking about them. I feel it's important to make that distinction, so we talk about the same thing. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1550B3A6E40 for ; Mon, 17 Jan 2011 19:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji+rXONJ2tE8 for ; Mon, 17 Jan 2011 19:00:14 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 003F13A6DB3 for ; Mon, 17 Jan 2011 19:00:13 -0800 (PST) Received: from [192.168.0.150] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 92BCD2284AE2; Mon, 17 Jan 2011 22:02:48 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 17 Jan 2011 22:02:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5E438434-9BCF-41CA-A0BA-4D22857E7A00@kumari.net> References: To: Stephen Kent X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 03:00:15 -0000 On Jan 17, 2011, at 5:11 PM, Stephen Kent wrote: > Warren, >=20 > I agree that getting DANE right for one protocol, e.g., TLS, is a lot = easier than trying to get it right for more than one. The big issue = that we need to keep in mind is to not impose design constraints, or = make design assumptions, at this stage that will conflict with late use = of DANE with IPsec, etc. Oh, yes, I fully, completely, 100% agree with you. I still think that we should stick with TLS in the current doc so that = we can have a clean, clear and concise document -- while writing it (and = future documents) we will ensure that we are not constraining the = design, or making assumptions that preclude supporting other protocols. I'm trying to avoid ending up with a document that is vague and = hand-wavy -- "the first field can contain a hash, or a key, or a cert, = or a means of getting a cert, or a further identifier that specifies = that the filed is extended in some way, or a protocol identifier, or a = small eggplant, or a bunch of parameters, or a coordinate on a plane, or = a hostname. The length of this field varies according to what you put in = it. The interpretation of all of the following fields is determined by = the value of this field." W > Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC50C28C1CB for ; Mon, 17 Jan 2011 16:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, FRT_LEVITRA=1.812, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mif5z0QMumy for ; Mon, 17 Jan 2011 16:01:39 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 618FD3A6EF8 for ; Mon, 17 Jan 2011 16:01:39 -0800 (PST) Received: by gxk28 with SMTP id 28so2407182gxk.31 for ; Mon, 17 Jan 2011 16:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LmNGY1tFE8rYn/1JhR4oPxRD5HEPoZP3Vyfdl3IOsYg=; b=k+4or9XkHxiE/hK/otTUPLlgIYiLTNf5NB+7FFwGYkg9DLupGbH6E53UtIc2DJfSb+ SWHkWK+iXFvFD9V0GNWhy2ExuJV+n2eS6dL27cljanEL38ybjcLDb+7VuroJMCkgEfyO 99q1Vc6p2P9ojDb6vWxombcOWfEZ4VugRfv7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RvSe6pR/YjIsQQ8YiGWvJfTg6HT/822UYctVpnV8Vz+d0iRF+I2BXZzeVFjmybmkfx r2akuJduxXq2fyGIF0yDR6UxSlU5hFJLszwW1Ra0VF/MstMU87Cl2PwtAFzfxfq2ywDK 8PseKi4Ik5Shr6pVun6ofQV22ThaLRAN8aENE= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr2917535anf.103.1295309054200; Mon, 17 Jan 2011 16:04:14 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 16:04:14 -0800 (PST) In-Reply-To: <4D34CF87.8000006@vpnc.org> References: <4D34CF87.8000006@vpnc.org> Date: Mon, 17 Jan 2011 19:04:14 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e64f8f4a0ccadb049a13a431 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 00:01:40 -0000 --0016e64f8f4a0ccadb049a13a431 Content-Type: text/plain; charset=ISO-8859-1 That is all I was ever arguing for, not to box ourselves into a corner unnecessarily. On Mon, Jan 17, 2011 at 6:23 PM, Paul Hoffman wrote: > On 1/17/11 2:11 PM, Stephen Kent wrote: > >> I agree that getting DANE right for one protocol, e.g., TLS, is a lot >> easier than trying to get it right for more than one. The big issue that >> we need to keep in mind is to not impose design constraints, or make >> design assumptions, at this stage that will conflict with late use of >> DANE with IPsec, etc. >> > > As an IPsec person who tests IPsec with PKIX certificates (< > http://www.vpnc.org/testing.html#CertIKEv1Interop>), I am quite sure that > nothing in the current draft will conflict with a future profile for IPsec, > if that community wants such a profile. As co-author of the current draft, > I'm pretty sure I would notice if a change was made that brought up such > conflict and would prevent it. > > --Paul Hoffman, Director > --VPN Consortium > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e64f8f4a0ccadb049a13a431 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is all I was ever arguing for, not to box ourselves into a corner unne= cessarily.

On Mon, Jan 17, 2011 at 6:23 = PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 1/17/11 2:11 PM, Steph= en Kent wrote:
I agree that getting DANE right for one protocol, e.g., TLS, is a lot
easier than trying to get it right for more than one. The big issue that we need to keep in mind is to not impose design constraints, or make
design assumptions, at this stage that will conflict with late use of
DANE with IPsec, etc.

As an IPsec person who tests IPsec with PKIX certificates (<http://= www.vpnc.org/testing.html#CertIKEv1Interop>), I am quite sure that n= othing in the current draft will conflict with a future profile for IPsec, = if that community wants such a profile. As co-author of the current draft, = I'm pretty sure I would notice if a change was made that brought up suc= h conflict and would prevent it.

--Paul Hoffman, Director
--VPN Consortium


_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e64f8f4a0ccadb049a13a431-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F68A28C0E1 for ; Mon, 17 Jan 2011 15:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, FRT_LEVITRA=1.812] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htu6w+ldB3Qh for ; Mon, 17 Jan 2011 15:27:57 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 61A7328C0CF for ; Mon, 17 Jan 2011 15:27:57 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 53477C4D4; Mon, 17 Jan 2011 18:30:32 -0500 (EST) Date: Mon, 17 Jan 2011 18:30:31 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D34CF87.8000006@vpnc.org> Message-ID: References: <4D34CF87.8000006@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:27:58 -0000 On Mon, 17 Jan 2011, Paul Hoffman wrote: > As an IPsec person who tests IPsec with PKIX certificates > (), I am quite sure that > nothing in the current draft will conflict with a future profile for IPsec, > if that community wants such a profile. As co-author of the current draft, > I'm pretty sure I would notice if a change was made that brought up such > conflict and would prevent it. Just a FYI: I also see no reason to actually use DANE over IPSECKEY (RFC 4025) and OE (RFC 4322) Those offer some more flexibility actually such as sending IP traffic for a certain host indirectly via IPsec to a specific IPsec gateway. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4F628C120 for ; Mon, 17 Jan 2011 15:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.812 X-Spam-Level: X-Spam-Status: No, score=-100.812 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FRT_LEVITRA=1.812, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNeGh7UQ2ciQ for ; Mon, 17 Jan 2011 15:21:17 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2E65128C0CF for ; Mon, 17 Jan 2011 15:21:17 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HNNpn1003400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 16:23:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D34CF87.8000006@vpnc.org> Date: Mon, 17 Jan 2011 15:23:51 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:21:18 -0000 On 1/17/11 2:11 PM, Stephen Kent wrote: > I agree that getting DANE right for one protocol, e.g., TLS, is a lot > easier than trying to get it right for more than one. The big issue that > we need to keep in mind is to not impose design constraints, or make > design assumptions, at this stage that will conflict with late use of > DANE with IPsec, etc. As an IPsec person who tests IPsec with PKIX certificates (), I am quite sure that nothing in the current draft will conflict with a future profile for IPsec, if that community wants such a profile. As co-author of the current draft, I'm pretty sure I would notice if a change was made that brought up such conflict and would prevent it. --Paul Hoffman, Director --VPN Consortium Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B39F28C0E1 for ; Mon, 17 Jan 2011 15:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BAiVWCtmXqG for ; Mon, 17 Jan 2011 15:20:54 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 99EA228C0CF for ; Mon, 17 Jan 2011 15:20:54 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B9928C4D4; Mon, 17 Jan 2011 18:23:28 -0500 (EST) Date: Mon, 17 Jan 2011 18:23:28 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D34C16A.1010008@vpnc.org> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D34C16A.1010008@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:20:55 -0000 On Mon, 17 Jan 2011, Paul Hoffman wrote: >> In other words, is there actually a problem? > > There is. If I trust CA1 for issuing to my mail server but not my web server, > and CA2 for issuing to my web server but not my mail server, just having CA1 > and CA2 in the response does not represent what I believe. and using the same FQDN to access them I assume (or else there is no issue) In that case, why not use type 1 or type 2? (eg end-user cert based TLSA instead of CA type based) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3278F28C19B for ; Mon, 17 Jan 2011 15:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhjSrYTwkJMC for ; Mon, 17 Jan 2011 15:01:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2341728C16B for ; Mon, 17 Jan 2011 15:01:02 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49188) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pey6q-000KPN-3P; Mon, 17 Jan 2011 18:03:37 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101171545.p0HFjnqN024402@fs4113.wdf.sap.corp> References: <201101171545.p0HFjnqN024402@fs4113.wdf.sap.corp> Date: Mon, 17 Jan 2011 18:01:01 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:01:03 -0000 At 4:45 PM +0100 1/17/11, Martin Rex wrote: >Phillip Hallam-Baker wrote: >> >> There are only two key formats that are widely used: X.509 and PGP. The PGP >> format is expressly designed to support Web of trust and so is irrelevant >> here because what we are doing is the exact opposite of what Phil Zimmerman >> proposed. > >Two-factor authentication has become popular for humans, because if >adequately set up, administrated and used it will require the two >simultaneous security breaches for an unauthorized access. > >The X.509 architecture has a design flaw that limits the security to >n-factor (n<=1). For the existing TLS X.509 PKI n is around 1/600 (0.00167) > >The PGP web of trust provides n-factor security (n>=1), and obtaining >(n>>1) is easy and straightforward. > >keyassurance through DNSSEC might be used to get back an n-factor security >with X.509 TLS PKI closer to n=1 (or even slightly better). > >While it's true that a PGP n-factor server authentication based on >pre-shared PGP trust anchors would work entirely without DNSSEC-based >key assurance (requiring PGP-enabled TLS on both ends, of course), >it might still be useful for the situation where there are no >pre-shared PGP trust anchors and either trusting DNSSEC or >allowing a leap-of-faith distribution of PGP keys or trust anchors >under protection of DNSSEC keys. > >-Martin The use of the phrase "n-factor authentication" in your message does not match what is commonly accepted in the security field. In multi-factor authentication the factors represent different types of authentication data, not multiple instances of auth data of the same type. So, for example, using a password and a challenge-response token is an example of two-factor authentication, but using two passwords is not. Thus, in the PGP web of trust context, having a cert with signatures from multiple individuals is not an example of multi-factor authentication. Similarly, have multiple X.509 certs, each with the same public key, but issued by different CAs, also would not be an example of multi-factor authentication. BTW, PGP and X.509 are really comparable in this respect, so I disagree with what appears to be the general thrust of your example. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EA428C16B for ; Mon, 17 Jan 2011 15:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHqDEEglu3oH for ; Mon, 17 Jan 2011 15:01:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C3F2628C178 for ; Mon, 17 Jan 2011 15:01:02 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49188) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pey6s-000KPN-28 for keyassure@ietf.org; Mon, 17 Jan 2011 18:03:38 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 17 Jan 2011 17:59:13 -0500 To: keyassure@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-916817079==_ma============" Subject: [keyassure] what PKIX is not X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:01:03 -0000 --============_-916817079==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I've seen several references to PKIX in the context of TLS that suggest some confusion. It appears that some folks believe that the trust anchor (TA) management model that browsers have adopted is somehow a PKIX-based requirement. That is not true. Browser vendors have adopted a TA model that is generally compliant with what X.509 and PKIX require, but neither X.509 nor PKIX mandate that model. So, for example, if DANE defines a way to distribute TAs via the DNS, that will not conflict with PKIX standards. The checks used to validate a TA are not specified in the core PKIX specs. (We do have other standards the define ways to deliver and validate TA material, but they are not the only game in town, e.g., see the SIDR WG spec on how to do this.) Section 6.1.1 of RFC 5280 says that the TA info used to validate a cert path includes (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. So, if DANE defines a way to populate items 1-3 (and, optionally 4) from data acquired from the DNS, it can satisfy the 5280 requirements for a TA. This could be dine via a self-signed cert, or even using a raw key. It's up to DANE to decide what checks it imposes on the data it retrieves from the DNS before using that data to validate an EE cert for a TLS server, for example. If DANE decides that it will use a raw key from the DNS directly in a TLS handshake, for example, then it moves outside the PKIX/X.509 realm, as no certs are being validated. DANE would then need to decide what, if any, constraints it would impose of how the key is used, e.g., matched to the DNS name for a server. Steve --============_-916817079==_ma============ Content-Type: text/html; charset="us-ascii" what PKIX is not
I've seen several references to PKIX in the context of TLS that suggest some confusion.

It appears that some folks believe that the trust anchor (TA) management model that browsers have adopted is somehow a PKIX-based requirement. That is not true. Browser vendors have adopted a TA model that is generally compliant with what X.509 and PKIX require, but neither X.509 nor PKIX mandate that model. So, for example, if DANE defines a way to distribute TAs via the DNS, that will not conflict with PKIX standards.

The checks used to validate a TA are not specified in the core PKIX specs. (We do have other standards the define ways to deliver and validate TA material, but they are not the only game in town, e.g., see the SIDR WG spec on how to do this.)  Section 6.1.1 of RFC 5280 says that the TA info used to validate a cert path includes

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
              with the public key.

So, if DANE defines a way to populate items 1-3 (and, optionally 4) from data acquired from the DNS, it can satisfy the 5280 requirements for a TA.  This could be dine via a self-signed cert, or even using a raw key. It's up to DANE to decide what checks it imposes on the data it retrieves from the DNS before using that data to validate an EE cert for a TLS server, for example.

If DANE decides that it will use a raw key from the DNS directly in a TLS handshake, for example, then it moves outside the PKIX/X.509 realm, as no certs are being validated.  DANE would then need to decide what, if any, constraints it would impose of how the key is used, e.g., matched to the DNS name for a server.

Steve


--============_-916817079==_ma============-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE0B28C135 for ; Mon, 17 Jan 2011 15:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYi59oivcCcl for ; Mon, 17 Jan 2011 15:00:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3DED028C120 for ; Mon, 17 Jan 2011 15:00:58 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49188) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pey6n-000KPN-7o; Mon, 17 Jan 2011 18:03:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> <4D3478B7.8020707@vpnc.org> Date: Mon, 17 Jan 2011 18:03:28 -0500 To: Paul Wouters From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:00:59 -0000 >... >PKIX is all about the server teling the client policy, even if the >precise policy >bits are contained in a PKIX certificate and not in an RRTYPE. I don't see why >DANE could not do the same (as long as the protocol allows >specifying both policies) Your statement that "PKIX is all about the server teling the client policy ..." is not really true. X.509 and PKIX standards assume that each client (relying party) locally selects the set of trust anchors that it employs. Thus a server, when it supplies an EE cert in a TLS exchange, is offering a cert for validation by the client, under the policies adopted by that client (e.g., as reflected in the trust anchors configured in that client). The server may have some policy inputs to the PKIX validation process, based on the value of certain extensions in its cert, but those extension values have to be approved by the CA that issued the server's EE cert. Thus the server may not have had free rein re those extension values. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2A628C135 for ; Mon, 17 Jan 2011 15:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohvp2PN6cE4j for ; Mon, 17 Jan 2011 15:00:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 22E9728C120 for ; Mon, 17 Jan 2011 15:00:59 -0800 (PST) Received: from dhcp89-089-063.bbn.com ([128.89.89.63]:49188) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Pey6o-000KPN-88; Mon, 17 Jan 2011 18:03:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 17 Jan 2011 17:11:02 -0500 To: Warren Kumari From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 23:01:00 -0000 Warren, I agree that getting DANE right for one protocol, e.g., TLS, is a lot easier than trying to get it right for more than one. The big issue that we need to keep in mind is to not impose design constraints, or make design assumptions, at this stage that will conflict with late use of DANE with IPsec, etc. Steve Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E15528C151 for ; Mon, 17 Jan 2011 14:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.716 X-Spam-Level: X-Spam-Status: No, score=-101.716 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Xl0j8AZLK9M for ; Mon, 17 Jan 2011 14:21:04 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5D3E03A6D87 for ; Mon, 17 Jan 2011 14:21:04 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HMNcYg001342 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 15:23:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D34C16A.1010008@vpnc.org> Date: Mon, 17 Jan 2011 14:23:38 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 22:21:05 -0000 On 1/17/11 1:35 PM, Paul Wouters wrote: > On Mon, 17 Jan 2011, Warren Kumari wrote: > >> Description: >> How to deal with multiple TLS-based services running under one domain >> name, such as a POP, IMAP, and SMTP server all running on >> mail.example.com. >> >> Suggestions so far include: >> Prefacing the host name with a service name (_pop.mail.example.com) >> Prefacing the host name with a port number (_110.mail.example.com) >> Returning a set of records that contain port numbers in the response. >> SRV / ESRV > > Multiple TLSA records and letting the client find the matching one from > the TLS handshake? That is another possible solution, but... > In other words, is there actually a problem? There is. If I trust CA1 for issuing to my mail server but not my web server, and CA2 for issuing to my web server but not my mail server, just having CA1 and CA2 in the response does not represent what I believe. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D9F3A6F64 for ; Mon, 17 Jan 2011 13:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7SnEU+1gO6w for ; Mon, 17 Jan 2011 13:49:38 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id D935B3A6F5F for ; Mon, 17 Jan 2011 13:49:37 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B481EC4D4; Mon, 17 Jan 2011 16:52:12 -0500 (EST) Date: Mon, 17 Jan 2011 16:52:12 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D34AE70.6030201@vpnc.org> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D34AE70.6030201@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:49:38 -0000 On Mon, 17 Jan 2011, Paul Hoffman wrote: > I think SRV is an interesting approach, but simply naming the protocol is > completely insufficient. Could someone who supports this and has thought > about it a while give some rough text that we could consider? It will also make it much harder to implement for the DNS administrator. I'm not sure why this is required. If the administrator feels that they need a separate TLSA entry, can't they just assign a different hostname and put the certificate there? eg mail.example.com and www.example.com? or payments.example.com? When there are vastly different security requirements for a particular service, they tend to be hosted on a separate server anyway, precisely because of the different requirements (eg PCI compliance) and so they have a different hostname and different TLSA location. Using SRV's or _service._proto prefixes makes deployment harder in the easy case, while using different domains for your complicated setup only makes things harder for the harder case, and therefor to me puts the complexity where it belongs. And I don't think this approach "damages the internet" because of a theoretical corner case of two widely different security levels running on the same hostname in DNS, deploying both PKIX with CAs and DANE. I do have an oustanding question there to Phillip to explain his use case better, but if those cases are not forthcoming, my preference would be to keep it simple. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904703A6F5D for ; Mon, 17 Jan 2011 13:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXt5w8lh-ecT for ; Mon, 17 Jan 2011 13:33:08 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 90C0B3A6E3A for ; Mon, 17 Jan 2011 13:33:08 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D3AA2C4D4; Mon, 17 Jan 2011 16:35:42 -0500 (EST) Date: Mon, 17 Jan 2011 16:35:42 -0500 (EST) From: Paul Wouters To: Warren Kumari In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:33:10 -0000 On Mon, 17 Jan 2011, Warren Kumari wrote: > Description: > How to deal with multiple TLS-based services running under one domain name, > such as a POP, IMAP, and SMTP server all running on mail.example.com. > > Suggestions so far include: > Prefacing the host name with a service name (_pop.mail.example.com) > Prefacing the host name with a port number (_110.mail.example.com) > Returning a set of records that contain port numbers in the response. > SRV / ESRV Multiple TLSA records and letting the client find the matching one from the TLS handshake? In other words, is there actually a problem? Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2931228C17D for ; Mon, 17 Jan 2011 13:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.715 X-Spam-Level: X-Spam-Status: No, score=-101.715 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QWmHJQoUS3g for ; Mon, 17 Jan 2011 13:00:06 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BE2CD28C155 for ; Mon, 17 Jan 2011 13:00:06 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HL2ewN098249 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 14:02:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D34AE70.6030201@vpnc.org> Date: Mon, 17 Jan 2011 13:02:40 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> In-Reply-To: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:00:09 -0000 On 1/17/11 12:46 PM, Warren Kumari wrote: > I was hoping that would be able to stick to one open item at a time but > the discussions on #17 (Should the first doc be TLS only or try be > everything to everyone?) has wrapped directly to this issue, so: > > I'm opening up Issue #1 (Deal with multiple TLS-based services under one > domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) > [ Dons frock, flaps hands, twirls the incense burner three times to the > left, presses button to make water squirt out of daisy add releases the > 12 doves -- now it is official ] > ----- > Description: > How to deal with multiple TLS-based services running under one domain > name, such as a POP, IMAP, and SMTP server all running on mail.example.com. > > Suggestions so far include: > Prefacing the host name with a service name (_pop.mail.example.com) > Prefacing the host name with a port number (_110.mail.example.com) > Returning a set of records that contain port numbers in the response. > SRV / ESRV > > ----- I think SRV is an interesting approach, but simply naming the protocol is completely insufficient. Could someone who supports this and has thought about it a while give some rough text that we could consider? As for ESRV, there has been no noticeable interest in the WGs that the authors have brought it to, so I think we would be impossibly premature to rely on it for our protocol. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59A028C219 for ; Mon, 17 Jan 2011 12:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfC5rPsq3Cgz for ; Mon, 17 Jan 2011 12:43:39 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id DB3F028C217 for ; Mon, 17 Jan 2011 12:43:38 -0800 (PST) Received: from [172.19.119.184] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 0777C2284AE2 for ; Mon, 17 Jan 2011 15:46:12 -0500 (EST) Message-Id: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> From: Warren Kumari To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 17 Jan 2011 15:46:10 -0500 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:43:40 -0000 I was hoping that would be able to stick to one open item at a time but the discussions on #17 (Should the first doc be TLS only or try be everything to everyone?) has wrapped directly to this issue, so: I'm opening up Issue #1 (Deal with multiple TLS-based services under one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1)) [ Dons frock, flaps hands, twirls the incense burner three times to the left, presses button to make water squirt out of daisy add releases the 12 doves -- now it is official ] ----- Description: How to deal with multiple TLS-based services running under one domain name, such as a POP, IMAP, and SMTP server all running on mail.example.com. Suggestions so far include: Prefacing the host name with a service name (_pop.mail.example.com) Prefacing the host name with a port number (_110.mail.example.com) Returning a set of records that contain port numbers in the response. SRV / ESRV ----- W Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2516D28C169 for ; Mon, 17 Jan 2011 12:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.713 X-Spam-Level: X-Spam-Status: No, score=-101.713 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4A85nUFjYJz for ; Mon, 17 Jan 2011 12:25:53 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6391E28C160 for ; Mon, 17 Jan 2011 12:25:53 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HKSReJ096767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 13:28:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D34A66B.7020103@vpnc.org> Date: Mon, 17 Jan 2011 12:28:27 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D349FF3.3000905@gmail.com> In-Reply-To: <4D349FF3.3000905@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:25:55 -0000 On 1/17/11 12:00 PM, Yaron Sheffer wrote: > I'd like to support Paul W.'s position here, and strongly disagree with > Paul H. Just to be clear (because people are changing views as we discuss), you are supporting having some end-entity certificate types that are labeled as "ignore everything other than the key" and some end-entity certificate types that are labeled as "treat all PKIX information as you would if you had not gotten the cert from TLSA", yes? I'm not fond of that because I think host admins will make the wrong choice, but it is a tenable solution. > Of course the DNS records are specifying policy. They (in > conjunction with the DANE RFC) tell the client what it is allowed to do. > That's policy in my book. But that's now what Paul W suggested: he had it as a suggestion, not what the client is allowed to do. That's what I objected to. > And specifying new RR types where the client MUST ignore everything in > the cert, other than the public key, is a nice way out of the > contradiction we've gotten ourselves into by trying to "sort of, but not > really" reuse PKIX. Thus, we fully agree. > An even cleaner way out is to specify exactly what fields MUST and MUST > NOT exist in the cert, and retain the PKIX semantics for all fields. Thus, we fully agree. > It would have been even cleaner to use raw RSA keys instead of > self-signed certs, but I don't know whether they would be usable in TLS. It is easy to find out by looking in the TLS specification. They are not. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752053A6F51 for ; Mon, 17 Jan 2011 12:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.017 X-Spam-Level: X-Spam-Status: No, score=-3.017 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc3r3gJYoZqj for ; Mon, 17 Jan 2011 12:20:45 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 049B53A6E28 for ; Mon, 17 Jan 2011 12:20:44 -0800 (PST) Received: by yxt33 with SMTP id 33so2352644yxt.31 for ; Mon, 17 Jan 2011 12:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/ptXNBpYFFxhw/ByGKcxFGeA/lXk96GIleDmswxfylM=; b=EFLOaQG3bABWBndDrYwP66GYOTrVmpqVtWo6QErTuAmJtFqioGjk4PWBN/YzUd7QAI 2MUMG3VrPUuVLfsUPwnf89oaPsE0WIxG5sE5UXKl1emLGU176+4j9pkHd6aKWyPh50V3 QBfAjmjpo2LO2hfPIlEfnlbVeuCDe3PZTS9CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZCr48NQXs6FcZ0f/gdUF6GJV0NpK1M+KuSaYCKoHbln5V68hrELyabTSBuCsfV1L8z Fg1gCVLbT3yd5SIoE1i3SGhWaIVBbmCHAd238dORQ6BeMcxzEQRa7abqMdX6EWqCpcuo 4+CdsdjDrw5sWodkX+2JbqCWrLT1JSovX2rHI= MIME-Version: 1.0 Received: by 10.100.48.13 with SMTP id v13mr251319anv.69.1295295799805; Mon, 17 Jan 2011 12:23:19 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 12:23:19 -0800 (PST) In-Reply-To: <4D349B38.80801@nic.cz> References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> <4D34959A.4050104@nic.cz> <4D349B38.80801@nic.cz> Date: Mon, 17 Jan 2011 15:23:19 -0500 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016e644bc2e06c8ed049a108e78 Cc: keyassure@ietf.org Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:20:47 -0000 --0016e644bc2e06c8ed049a108e78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 17, 2011 at 2:40 PM, Ond=C5=99ej Sur=C3=BD = wrote: > > > Further thinking about this. It seems to me that we have two issues here= : > > Issue#1 - Multiple services at one name > > Issue#tbd - Ignoring (or not) certificate data in self-signed certs > Agreed > The solution for Issue#1 might be usage of SRVNames. > I think so. SRV Names are the DNS way to address protocols, they are a very powerful and useful tool. They also allow us to focus on a much narrower set of concerns at a given instance. If we are talking about a record with an _https._tcp prefix then = I am very happy to only be talking about TLS and only talking about HTTP. The solution to Issue#tbd might be in tool which would easily generate > different self-signed certs from one private key (or ability to do that > on-fly), hence defeating the need to ignore cert properties. Someone suggested being able to (optionally) put a critical extension in th= e cert with an SRV property. I rather like that proposal as it really ties everything very neatly to the DNS set of identifiers and a DNS way of looking at the world. --=20 Website: http://hallambaker.com/ --0016e644bc2e06c8ed049a108e78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 17, 2011 at 2:40 PM, Ond=C5= =99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:

Further thinking about this. =C2=A0It seems to me that we have two issues h= ere:

Issue#1 - Multiple services at one name

Issue#tbd - Ignoring (or not) certificate data in self-signed certs

Agreed=C2=A0

=C2=A0
The solution for Issue#1 might be usage of SRVNames.
<= br>
I think so. SRV Names are the DNS way to address protocols, t= hey are a very powerful and useful tool.

They also= allow us to focus on a much narrower set of concerns at a given instance. = If we are talking about a record with an _https._tcp prefix then I am very = happy to only be talking about TLS and only talking about HTTP.


The solution to Issue#tbd might be in tool which would easily generate diff= erent self-signed certs from one private key (or ability to do that on-fly)= , hence defeating the need to ignore cert properties.

Someone suggested being able to (optionally) put a critical = extension in the cert with an SRV property.

I rath= er like that proposal as it really ties everything very neatly to the DNS s= et of identifiers and a DNS way of looking at the world.


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

--0016e644bc2e06c8ed049a108e78-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C81C3A6F57 for ; Mon, 17 Jan 2011 12:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7nAGhQkQgYe for ; Mon, 17 Jan 2011 12:07:48 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 3DBA73A6F55 for ; Mon, 17 Jan 2011 12:07:48 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 36D1B704076; Mon, 17 Jan 2011 12:10:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=sk/kYaHSSoBczMK0+mMe/0kH8VkZJiNHkDSjBpGYhJU OEYKoGO9UleVLRnIauu00EE/0RaBo78NUk8Vv3IdjNDnfTimMlZ+WfGvsO2rHYoT WaqteOJw9x7xbba+3gOOP7SSfth4mBu6VCcrLyRviotutakrYzEcmnWjat+FasV8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=lTl9Ygti1J5uV5aAA+GEjrsK3zY=; b=QBEnEn7zK2 SLVfTpWMrRS09YDjW5LIEw7hlYv+b+ZEd9NZtTeTDLDuaVOTFOQwm23WZdqMAkfo MsmK0CZp0UN3PogfvE37OFM4bno1FEIsDpLS12BW4zIMsFSLzCAOW2DUatPIBxVA rNE9/bNmSA/UCbPK8SYCKkzaWcLFLi7a0= Received: from [192.168.1.40] (pool-74-96-47-53.washdc.east.verizon.net [74.96.47.53]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id A1887704071; Mon, 17 Jan 2011 12:10:22 -0800 (PST) From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4D349B38.80801@nic.cz> References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> <4D34959A.4050104@nic.cz> <4D349B38.80801@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Jan 2011 15:10:21 -0500 Message-ID: <1295295021.2221.57.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:07:49 -0000 On Mon, 2011-01-17 at 20:40 +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 17.1.2011 20:16, Ond=C5=99ej Sur=C3=BD wrote: > > BTW do you realize that all the services you have named use the same > > certificate? So the level of trust is probably same for all those ser= vices. >=20 > Just to make sure... I was not arguing here with you, just pointing ou= t=20 > that it's quite different to have all "mail" services under one name=20 > (and probably same policy) and to have "low-level" SMTP cert and some=20 > other high security protocol at other name (like running incoming SMTP=20 > server under www.paypal.com name) Understood. I don't have an example of the latter. However, even when the services are at the same trust level, diversion of a connection bound for one service to another legitimate service is something that TLS can, and IMHO should, prevent. Using different certificates bound to the individual services is one way to do this. (The other would be to put a SRVName in the server_name extension and have the server check it.) > >> PKIX supports it via SRVNames (RFC 4985). DANE should support it too= . > > > > I don't see a problem here for non-self-signed certs (3.1.4 says that > > additional certificate data should be processed as normal). > > > > The only issue is with self-signed certs type 1/2 (type 3/4 is CA > > self-signed cert). So basically you are saying (if I may generalize) > > that we should not ignore certificate data in self-signed certs and t= hus > > support SRVNames in self-signed certs. >=20 > Further thinking about this. It seems to me that we have two issues he= re: >=20 > Issue#1 - Multiple services at one name >=20 > Issue#tbd - Ignoring (or not) certificate data in self-signed certs Right. > The solution for Issue#1 might be usage of SRVNames. That is one possible solution. I prefer the solutions listed in the ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/1), which will also work with bare public keys. > The solution to Issue#tbd might be in tool which would easily generate=20 > different self-signed certs from one private key (or ability to do that= =20 > on-fly), hence defeating the need to ignore cert properties. Sure. Generating a cert with appropriate property values (subjectAltName, validity period, ...) is doable. The question is whether the practical value of honoring a particular PKIX property (either because it is a useful security measure or to meet admin expectations) justifies the admin effort to set it properly. I don't think this case has been made convincingly one way or the other. --=20 Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5CC28C1B7 for ; Mon, 17 Jan 2011 12:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXSWrWcxnbLn for ; Mon, 17 Jan 2011 12:01:03 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BF14B28C1C7 for ; Mon, 17 Jan 2011 12:01:02 -0800 (PST) Received: by wwa36 with SMTP id 36so5264252wwa.13 for ; Mon, 17 Jan 2011 12:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=21hmzTugBQoLnrp0aRbmIIprcklmdRAD8dyR2grS3rU=; b=Ed9aSQTNskbCVbc3DgTbcd6qXpaWu441yyraeYZvM43GnUpdkMNn1TafJAraWkwmsY EyUoXNKg6JZ6qf6R/hyVQhbfA8vphNROMLpcc8gW73EG/LxTe8TwcFhhVtkk/LldmWpp Uf61EPyhdXUfnKa5LvuvXRq7Z7VwpMw8zFLfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=pwVAXzMvF4aIwu8orUkA5rBUR/xMYndtXkwzX2cgifNBzVdQmbx/tPFYuuvBKL5tv7 UckQg1zpf8jI8mVny/0lxI+5vbaa57WHQDCyK4DRZWKdIXBc0B1Rt+FYTWGRqqgK3/f+ TW+r7JziTVeoigzJ5moItMRhJFmhyZcHc6MpQ= Received: by 10.227.167.8 with SMTP id o8mr4500462wby.166.1295294456283; Mon, 17 Jan 2011 12:00:56 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id m13sm3604662wbz.21.2011.01.17.12.00.54 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Jan 2011 12:00:55 -0800 (PST) Message-ID: <4D349FF3.3000905@gmail.com> Date: Mon, 17 Jan 2011 22:00:51 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:01:04 -0000 Hi, I'd like to support Paul W.'s position here, and strongly disagree with Paul H. Of course the DNS records are specifying policy. They (in conjunction with the DANE RFC) tell the client what it is allowed to do. That's policy in my book. And specifying new RR types where the client MUST ignore everything in the cert, other than the public key, is a nice way out of the contradiction we've gotten ourselves into by trying to "sort of, but not really" reuse PKIX. An even cleaner way out is to specify exactly what fields MUST and MUST NOT exist in the cert, and retain the PKIX semantics for all fields. It would have been even cleaner to use raw RSA keys instead of self-signed certs, but I don't know whether they would be usable in TLS. Thanks, Yaron Date: Mon, 17 Jan 2011 08:10:18 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] Possible fix for pkix/dane certificate > disagreement > To: keyassure@ietf.org > Message-ID:<4D3469EA.5000509@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/17/11 7:11 AM, Paul Wouters wrote: > > > > DANE is an alternative for PKIX. > > > > The important issue here is can someone use both or not, and can someone > > migrate from one to the other. DANE should not be limited by PKIX, just > > like PKIX should not be limited by DANE. But we have had this discussion > > a few times already. > > > > My concern is for example with the regularly seen expired > certificates. I > > forsee people, especially those using self signed certificates, to > > generate TLSA records and forget about their certificate's expiry date. > > > > I think there is real value in ignoring all certificate properties. > But we > > could decide on making such a TLSA record have its own "certificate > type". > > > > eg, we could add type 5/6 to section 2 of the DANE draft: > > > > 5 Hash of a public key taken from an end-entity certificate. All PKIX > > elements are specifically ignored. > > > > 6 Full public key taken from an end-entity certificate. All PKIX > > elements are specifically ignored. > > I agree that we should nail down in the spec whether PKIX information > other than the key itself should be paid attention to in end-entity > certificates gotten through TLSA. I disagree that we want to have two > semantics based on different values in the TLSA record. Doing so says > that the server gets to tell the client what security policy the client > should use. > > --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C7528C12F for ; Mon, 17 Jan 2011 11:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXYo74G6P0z2 for ; Mon, 17 Jan 2011 11:38:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 422363A6F51 for ; Mon, 17 Jan 2011 11:38:06 -0800 (PST) Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 7065673431A for ; Mon, 17 Jan 2011 20:40:40 +0100 (CET) Message-ID: <4D349B38.80801@nic.cz> Date: Mon, 17 Jan 2011 20:40:40 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> <4D34959A.4050104@nic.cz> In-Reply-To: <4D34959A.4050104@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:38:08 -0000 On 17.1.2011 20:16, Ondřej Surý wrote: > On 17.1.2011 19:51, Matt McCutchen wrote: >> On Mon, 2011-01-17 at 15:50 +0100, Ondřej Surý wrote: >>> On 17.1.2011 15:30, Phillip Hallam-Baker wrote: >>>> The specific concern would be that someone could make use of the >>>> lightweight SMTP cert issue process to acquire a certificate for >>>> another >>>> service. >>> > >>>> Another concern would be that in a heavily outsourced deployment, I may >>>> trust a company to run my inbound mail server but not want them to have >>>> the ability to advertise other services (like accepting payments). >>>> >>>> The simplest, most direct way to enforce this type of restriction is to >>>> put a note in the certificate governing acceptable use. >>> >>> No, the simplest, most direct way (apart from not using DANE at all) is >>> to have different host names for inbound mail server and other services. >>> >>> You have painted the very rare scenario in which the canonical name (ie. >>> the target of MX record) is same as some other service, and you document >>> the degradation of security on such unlikely scenario. >>> >>> >>> I propose that either you present an evidence that it will have any real >>> impact or we just drop this issue since it's impact is negligible. >>> Thank you. >>> >> >> Here's an example: my university's student mail system provides POP3S, >> IMAPS, SMTP with STARTTLS for message submission, and a HTTPS webmail >> interface all on the same server name (mail.umd.edu). > > Thank you for the real world example. > >> This kind of configuration is convenient for users: they only have to >> remember the one host name, not the prefixes used for the different >> services (which are not standardized anywhere and will be different for >> different service providers). > > BTW do you realize that all the services you have named use the same > certificate? So the level of trust is probably same for all those services. Just to make sure... I was not arguing here with you, just pointing out that it's quite different to have all "mail" services under one name (and probably same policy) and to have "low-level" SMTP cert and some other high security protocol at other name (like running incoming SMTP server under www.paypal.com name) >> PKIX supports it via SRVNames (RFC 4985). DANE should support it too. > > I don't see a problem here for non-self-signed certs (3.1.4 says that > additional certificate data should be processed as normal). > > The only issue is with self-signed certs type 1/2 (type 3/4 is CA > self-signed cert). So basically you are saying (if I may generalize) > that we should not ignore certificate data in self-signed certs and thus > support SRVNames in self-signed certs. Further thinking about this. It seems to me that we have two issues here: Issue#1 - Multiple services at one name Issue#tbd - Ignoring (or not) certificate data in self-signed certs The solution for Issue#1 might be usage of SRVNames. The solution to Issue#tbd might be in tool which would easily generate different self-signed certs from one private key (or ability to do that on-fly), hence defeating the need to ignore cert properties. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A06A3A6F20 for ; Mon, 17 Jan 2011 11:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMCpyji8UIrG for ; Mon, 17 Jan 2011 11:34:39 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A33FE3A6E59 for ; Mon, 17 Jan 2011 11:34:39 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BEFD8C4D4; Mon, 17 Jan 2011 14:37:13 -0500 (EST) Date: Mon, 17 Jan 2011 14:37:13 -0500 (EST) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <4D34959A.4050104@nic.cz> Message-ID: References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> <4D34959A.4050104@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:34:40 -0000 On Mon, 17 Jan 2011, Ondřej Surý wrote: > I don't see a problem here for non-self-signed certs (3.1.4 says that > additional certificate data should be processed as normal). > > The only issue is with self-signed certs type 1/2 (type 3/4 is CA self-signed > cert). So basically you are saying (if I may generalize) that we should not > ignore certificate data in self-signed certs and thus support SRVNames in > self-signed certs. Note that we should support a dual migration, where someone will move from PKIX to DANE, but also has to deal with users going from software that does not support DANE to software that supports DANE. This will be the main reason why "DANE certs" are seeing X.509 extended properties to begin with. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E698428C12F for ; Mon, 17 Jan 2011 11:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EGTXpWEGrIb for ; Mon, 17 Jan 2011 11:30:47 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E7F933A6DCE for ; Mon, 17 Jan 2011 11:30:46 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8F947C4D4; Mon, 17 Jan 2011 14:33:20 -0500 (EST) Date: Mon, 17 Jan 2011 14:33:20 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> <4D3478B7.8020707@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:30:48 -0000 On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > So to accept the proposal to ignore critical extensions, revocation, expiry is to create a huge amount of scope for interoperability failures. I am okay with leaving that for a new sub type for bare public key TLS. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD113A6EE1 for ; Mon, 17 Jan 2011 11:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4AMy3aPfBIh for ; Mon, 17 Jan 2011 11:14:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 82CA93A6E5C for ; Mon, 17 Jan 2011 11:14:08 -0800 (PST) Received: from [172.20.26.41] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 5A91C73431A for ; Mon, 17 Jan 2011 20:16:42 +0100 (CET) Message-ID: <4D34959A.4050104@nic.cz> Date: Mon, 17 Jan 2011 20:16:42 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <1295290319.2221.8.camel@mattlaptop2.local> In-Reply-To: <1295290319.2221.8.camel@mattlaptop2.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:14:10 -0000 On 17.1.2011 19:51, Matt McCutchen wrote: > On Mon, 2011-01-17 at 15:50 +0100, Ondřej Surý wrote: >> On 17.1.2011 15:30, Phillip Hallam-Baker wrote: >>> The specific concern would be that someone could make use of the >>> lightweight SMTP cert issue process to acquire a certificate for another >>> service. >> > >>> Another concern would be that in a heavily outsourced deployment, I may >>> trust a company to run my inbound mail server but not want them to have >>> the ability to advertise other services (like accepting payments). >>> >>> The simplest, most direct way to enforce this type of restriction is to >>> put a note in the certificate governing acceptable use. >> >> No, the simplest, most direct way (apart from not using DANE at all) is >> to have different host names for inbound mail server and other services. >> >> You have painted the very rare scenario in which the canonical name (ie. >> the target of MX record) is same as some other service, and you document >> the degradation of security on such unlikely scenario. >> >> >> I propose that either you present an evidence that it will have any real >> impact or we just drop this issue since it's impact is negligible. >> Thank you. >> > > Here's an example: my university's student mail system provides POP3S, > IMAPS, SMTP with STARTTLS for message submission, and a HTTPS webmail > interface all on the same server name (mail.umd.edu). Thank you for the real world example. > This kind of configuration is convenient for users: they only have to > remember the one host name, not the prefixes used for the different > services (which are not standardized anywhere and will be different for > different service providers). BTW do you realize that all the services you have named use the same certificate? So the level of trust is probably same for all those services. > PKIX supports it via SRVNames (RFC 4985). DANE should support it too. I don't see a problem here for non-self-signed certs (3.1.4 says that additional certificate data should be processed as normal). The only issue is with self-signed certs type 1/2 (type 3/4 is CA self-signed cert). So basically you are saying (if I may generalize) that we should not ignore certificate data in self-signed certs and thus support SRVNames in self-signed certs. Correct? O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A093A6EFC for ; Mon, 17 Jan 2011 11:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.153 X-Spam-Level: X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bxqbs7aAqZK for ; Mon, 17 Jan 2011 11:05:56 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 77DD33A6DED for ; Mon, 17 Jan 2011 11:05:56 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0HJ8T38016221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jan 2011 20:08:29 +0100 (MET) From: Martin Rex Message-Id: <201101171908.p0HJ8SmS005934@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 17 Jan 2011 20:08:28 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Jan 17, 11 09:55:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:05:57 -0000 Phillip Hallam-Baker wrote: > > OK, we will return to this in last call then > > And in IETF last call > > And when the PKIX people object to your whole spec on the grounds that you > are changing theirs we can start DANE from scratch I'm not sure I fully understand what you're talking about, but I believe it is a non-issue. The existing TLS X.509 PKI has a huge gaping security problem, and DANE is supposed to provide a band-aid for this. But why should DANE be _limited_ to mitigating serious PKIX problems? Does PKIX have a monopoly of foobaring the worlds security needs? I also don't see any requirements in and around TLS that it ought to be limited to (vanilla) PKIX. There may be a strong economic interest from commercial CAs and parties of the CA/Browser forum that no alternatives to commercial CAs become commonly used with HTTPS, but that is definitely not a resonable engineering decision for the IETF to prevent this from happening. The issue seems to be much less about processing X.509 certs and attributes, rather than deciding when to consider which specific certs or keys as trusted. So far, they solution to bootstrapping trust in PKIX is also primarily done as "deus ex machina" (aka leap-of-faith). like an initial install of http://www.mozilla.com/en-US/firefox/ Last time I checked, DANE builds on DNSSEC, and DNSSEC itself is also not wedlocked to PKIX. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8853A6E82 for ; Mon, 17 Jan 2011 11:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.712 X-Spam-Level: X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KxPEurlLT9D for ; Mon, 17 Jan 2011 11:02:24 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 56FDF3A6DC8 for ; Mon, 17 Jan 2011 11:02:24 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HJ4wG2093028 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 12:04:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3492D9.8030905@vpnc.org> Date: Mon, 17 Jan 2011 11:04:57 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> <4D3478B7.8020707@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:02:25 -0000 On 1/17/11 10:34 AM, Paul Wouters wrote: > On Mon, 17 Jan 2011, Paul Hoffman wrote: > >>>> I agree that we should nail down in the spec whether PKIX information >>>> other than the key itself should be paid attention to in end-entity >>>> certificates gotten through TLSA. I disagree that we want to have two >>>> semantics based on different values in the TLSA record. Doing so says >>>> that the server gets to tell the client what security policy the >>>> client should use. >>> >>> So change it from "ignored" to "MAY ignore" ? >> >> Clients "MAY ignore" anything already. It sounds like you are trying >> to add bits that say "and I want you to enforce this even though I >> have no idea what your local policy is". That doesn't sound like it >> adds much value to me. > > I'm trying to addres Phillip's concern about implicitely changing PKIX > validation > by making it more explicit, and giving the administrator the local > policy choice > to put down a preference of either DANE or PKIX as their trust anchor. > > While most believe the existence of DANE itself signifies the > preference, Phillip > does not agree. A specific sub-type in section 2 for TLSA would address > this. > > PKIX is all about the server teling the client policy, even if the > precise policy > bits are contained in a PKIX certificate and not in an RRTYPE. I don't > see why > DANE could not do the same (as long as the protocol allows specifying > both policies) > > In the current spec, there is the contradiction of "expired cert" vs > "valid RRSIG". > It would be nice if a preference could be specified and that this use > case would > not end up being varying per implementation. (even though I think that > implementations > should ignore everything but the public key from a cert when using DANE) In this discussion, people (not just Phill) have brought out many different parts of a PKIX cert that might or might not be taken into account by the TLS client receiving the cert through TLSA. I don't think there is much agreement yet on which parts are important, and thus should be an open issue for us to deal with so we can see where consensus lies. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753CE3A6DC8 for ; Mon, 17 Jan 2011 11:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izek4JXesJhV for ; Mon, 17 Jan 2011 11:01:44 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id F2C8C3A6D01 for ; Mon, 17 Jan 2011 11:01:43 -0800 (PST) Received: by gyd12 with SMTP id 12so2311370gyd.31 for ; Mon, 17 Jan 2011 11:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JnIj5jnod2khg8ca849lkNVvOF+LQooAmoRq+7kbj90=; b=bsy02dn2wmbfKz4UDgvFgKSlMaPPgPImH61ph4ewYyvKdZ01QYChf9xZpZNY57jMrU TuVbnO312yASfGzFIWsUWe50ev/GIK/dmHixCEQJKw3mgwIxEmHN30ugL9j5YXGOC8G+ 51Nqtf8z2vkEgpTLrMZ6WSzQ65XOWFtkBbMBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kaFmhBOfFeDuFATgw8c+lLJirR/AwCIq/au8VRpNaObCsV6KVSdROc66xqP0X6vIuI sYxqDr7utHQnhgvK5kY1DTc/EPtCiQ9LNxnfm/xdXUcfUGAZLgpvvtslvt1RUAiiglGp keEP3W+0Hra/Zu3HZECeLVWWXbHFqwFilOTas= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr2724806anf.103.1295291058437; Mon, 17 Jan 2011 11:04:18 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 11:04:18 -0800 (PST) In-Reply-To: <4D3478B7.8020707@vpnc.org> References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> <4D3478B7.8020707@vpnc.org> Date: Mon, 17 Jan 2011 14:04:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e64f8f4a6b4113049a0f7380 Cc: keyassure@ietf.org Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 19:01:45 -0000 --0016e64f8f4a6b4113049a0f7380 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 17, 2011 at 12:13 PM, Paul Hoffman wrote: > On 1/17/11 8:33 AM, Paul Wouters wrote: > >> On Mon, 17 Jan 2011, Paul Hoffman wrote: >> >> I agree that we should nail down in the spec whether PKIX information >>> other than the key itself should be paid attention to in end-entity >>> certificates gotten through TLSA. I disagree that we want to have two >>> semantics based on different values in the TLSA record. Doing so says >>> that the server gets to tell the client what security policy the >>> client should use. >>> >> >> So change it from "ignored" to "MAY ignore" ? >> > > Clients "MAY ignore" anything already. It sounds like you are trying to add > bits that say "and I want you to enforce this even though I have no idea > what your local policy is". That doesn't sound like it adds much value to > me. No, you are quite incorrect. Clients 'may' do anything they like. But that does not mean that they 'MAY' do anything in the sense of normative compliance. In the case of X.509 and PKIX there are very specific MUST requirements that have to be observed for interoperability. One of them is that RPs MUST NOT accept a certificate with a critical extension that they do not understand. that is an interoperability criteria. In practice it is a restriction that would take a great deal of effort to avoid enforcing since existing code has those restrictions built in at a very low level. If we were to attempt to adopt the approach suggested and simply ignore critical extensions and expiry dates, the likely outcome is going to be that some people are going to code to the DANE spec and others are going to code to the PKIX spec. And as a PKIX person I am not going to tell the person who is reading that document that they are wrong to ignore the DANE requirements. So to accept the proposal to ignore critical extensions, revocation, expiry is to create a huge amount of scope for interoperability failures. If people don't want critical extensions then they shouldn't put them in their self-signed certs. The only way that a critical extension is going to get in a cert is if someone decides to put it there. If people don't want to worry about expiry dates then set them to the issue date plus 100 years. -- Website: http://hallambaker.com/ --0016e64f8f4a6b4113049a0f7380 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 17, 2011 at 12:13 PM, Paul H= offman <paul.= hoffman@vpnc.org> wrote:
On 1/17/11 8:33 AM, Paul Wouters wrote:
On Mon, 17 Jan 2011, Paul Hoffman wrote:

I agree that we should nail down in the spec whether PKIX information
other than the key itself should be paid attention to in end-entity
certificates gotten through TLSA. I disagree that we want to have two
semantics based on different values in the TLSA record. Doing so says
that the server gets to tell the client what security policy the
client should use.

So change it from "ignored" to "MAY ignore" ?

Clients "MAY ignore" anything already. It sounds like you are try= ing to add bits that say "and I want you to enforce this even though I= have no idea what your local policy is". That doesn't sound like = it adds much value to me.

No, you are quite incorrect.

C= lients 'may' do anything they like.

But th= at does not mean that they 'MAY' do anything in the sense of normat= ive compliance. In the case of X.509 and PKIX there are very specific MUST = requirements that have to be observed for interoperability.

One of them is that RPs MUST NOT accept a certificate w= ith a critical extension that they do not understand. that is an interopera= bility criteria.
=A0

In practice i= t is a restriction that would take a great deal of effort to avoid enforcin= g since existing code has those restrictions built in at a very low level.<= /div>

If we were to attempt to adopt the approach suggested a= nd simply ignore critical extensions and expiry dates, the likely outcome i= s going to be that some people are going to code to the DANE spec and other= s are going to code to the PKIX spec. And as a PKIX person I am not going t= o tell the person who is reading that document that they are wrong to ignor= e the DANE requirements.

So to accept the proposal to ignore critical extensions= , revocation, expiry is to create a huge amount of scope for interoperabili= ty failures.


If people don't wa= nt critical extensions then they shouldn't put them in their self-signe= d certs. The only way that a critical extension is going to get in a cert i= s if someone decides to put it there.

If people don't want to worry about expiry dates th= en set them to the issue date plus 100 years.


=
--
Website: http://hallambake= r.com/

--0016e64f8f4a6b4113049a0f7380-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F9228C107 for ; Mon, 17 Jan 2011 10:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OItaEDb26Ffa for ; Mon, 17 Jan 2011 10:49:29 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 840533A6D1F for ; Mon, 17 Jan 2011 10:49:27 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id E879520806A; Mon, 17 Jan 2011 10:52:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=vaC341wcAAAGQK5gTQ831SdjFnNKyGg0wDDyypDwepz 4BonoPvmMDdS6Jun8jvW3rXhku327g0JMX52p/l/eWHUeUsg0qH4JSXE/itZ8t9O rI1/SBrbXgYDJfzxU2m21t6taNE92eDo43R9dMM3tlc9hxghhMD3U89Qteyz2WhE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=3lpqJtTpZxJLl7JY+DhYDZM7HEM=; b=aHzisyTl2S MDzx8k28zXTcLOEtudeqeIx4XG+eBd5MQJgXU345sYbwjQenCTvzkgeMIpFZhKLL XfuPfI6LvKzpMEw8m3nZCH78OKkA3hen8TncxImtOp4XPPMtpw+WdUIiwf4hSoWg 6fGze7nxX96J9Siiz9QBRd82f9IzJ4m/E= Received: from [192.168.1.40] (pool-74-96-47-53.washdc.east.verizon.net [74.96.47.53]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 700C1208060; Mon, 17 Jan 2011 10:52:01 -0800 (PST) From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4D34573A.1090509@nic.cz> References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Mon, 17 Jan 2011 13:51:59 -0500 Message-ID: <1295290319.2221.8.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Multiple services at one name (issue #1) X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:49:30 -0000 On Mon, 2011-01-17 at 15:50 +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 17.1.2011 15:30, Phillip Hallam-Baker wrote: > > The specific concern would be that someone could make use of the > > lightweight SMTP cert issue process to acquire a certificate for anot= her > > service. > > > > Another concern would be that in a heavily outsourced deployment, I m= ay > > trust a company to run my inbound mail server but not want them to ha= ve > > the ability to advertise other services (like accepting payments). > > > > The simplest, most direct way to enforce this type of restriction is = to > > put a note in the certificate governing acceptable use. >=20 > No, the simplest, most direct way (apart from not using DANE at all) is= =20 > to have different host names for inbound mail server and other services= . >=20 > You have painted the very rare scenario in which the canonical name (ie= .=20 > the target of MX record) is same as some other service, and you documen= t=20 > the degradation of security on such unlikely scenario. >=20 > > I propose that either you present an evidence that it will have any rea= l=20 > impact or we just drop this issue since it's impact is negligible.=20 > Thank you. > Here's an example: my university's student mail system provides POP3S, IMAPS, SMTP with STARTTLS for message submission, and a HTTPS webmail interface all on the same server name (mail.umd.edu). This kind of configuration is convenient for users: they only have to remember the one host name, not the prefixes used for the different services (which are not standardized anywhere and will be different for different service providers). PKIX supports it via SRVNames (RFC 4985). DANE should support it too. --=20 Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA3A28C209 for ; Mon, 17 Jan 2011 10:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDm-cFsGao37 for ; Mon, 17 Jan 2011 10:32:13 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 6923428C211 for ; Mon, 17 Jan 2011 10:32:12 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id E4953C50C; Mon, 17 Jan 2011 13:34:45 -0500 (EST) Date: Mon, 17 Jan 2011 13:34:44 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D3478B7.8020707@vpnc.org> Message-ID: References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> <4D3478B7.8020707@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 18:32:14 -0000 On Mon, 17 Jan 2011, Paul Hoffman wrote: >>> I agree that we should nail down in the spec whether PKIX information >>> other than the key itself should be paid attention to in end-entity >>> certificates gotten through TLSA. I disagree that we want to have two >>> semantics based on different values in the TLSA record. Doing so says >>> that the server gets to tell the client what security policy the >>> client should use. >> >> So change it from "ignored" to "MAY ignore" ? > > Clients "MAY ignore" anything already. It sounds like you are trying to add > bits that say "and I want you to enforce this even though I have no idea what > your local policy is". That doesn't sound like it adds much value to me. I'm trying to addres Phillip's concern about implicitely changing PKIX validation by making it more explicit, and giving the administrator the local policy choice to put down a preference of either DANE or PKIX as their trust anchor. While most believe the existence of DANE itself signifies the preference, Phillip does not agree. A specific sub-type in section 2 for TLSA would address this. PKIX is all about the server teling the client policy, even if the precise policy bits are contained in a PKIX certificate and not in an RRTYPE. I don't see why DANE could not do the same (as long as the protocol allows specifying both policies) In the current spec, there is the contradiction of "expired cert" vs "valid RRSIG". It would be nice if a preference could be specified and that this use case would not end up being varying per implementation. (even though I think that implementations should ignore everything but the public key from a cert when using DANE) Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8289B28C136 for ; Mon, 17 Jan 2011 09:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.715 X-Spam-Level: X-Spam-Status: No, score=-101.715 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWASzDtqCdM9 for ; Mon, 17 Jan 2011 09:10:54 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 401B928C132 for ; Mon, 17 Jan 2011 09:10:53 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HHDRvb087743 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 10:13:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3478B7.8020707@vpnc.org> Date: Mon, 17 Jan 2011 09:13:27 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:10:56 -0000 On 1/17/11 8:33 AM, Paul Wouters wrote: > On Mon, 17 Jan 2011, Paul Hoffman wrote: > >> I agree that we should nail down in the spec whether PKIX information >> other than the key itself should be paid attention to in end-entity >> certificates gotten through TLSA. I disagree that we want to have two >> semantics based on different values in the TLSA record. Doing so says >> that the server gets to tell the client what security policy the >> client should use. > > So change it from "ignored" to "MAY ignore" ? Clients "MAY ignore" anything already. It sounds like you are trying to add bits that say "and I want you to enforce this even though I have no idea what your local policy is". That doesn't sound like it adds much value to me. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E5728C16B for ; Mon, 17 Jan 2011 09:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.713 X-Spam-Level: X-Spam-Status: No, score=-101.713 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqObs1fieSpe for ; Mon, 17 Jan 2011 09:08:55 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 611A428C169 for ; Mon, 17 Jan 2011 09:08:55 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HHBTjR087658 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 10:11:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D347840.9070303@vpnc.org> Date: Mon, 17 Jan 2011 09:11:28 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <4D345BA3.5010206@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 17:08:56 -0000 On 1/17/11 8:18 AM, Phillip Hallam-Baker wrote: > This is an existing security control established in PKIX Correct. And we are discussing expressly ignoring it when used in end-entity certificates when used for associating a key with a domain name. > I believe the burden of proof is on those proposing to make a change > that they are not going to cause damage. You are saying we have to prove something unprovable? That seems like a mighty high bar, one that doesn't apply to any other work in the IETF. > Now if you look at this thread, I have given numerous use cases that > demonstrate a need for what I am arguing for. I have not seen any use > case given in favor of ignoring the information. I have reviewed your messages on this (poorly-named) thread, and I do not see a use case that demonstrates a need. I assume that means I am not understanding you. Can you copy one from earlier in this thread here? (FWIW, I see statements that do not relate to end-entity certificates, but those are not what we are discussing here.) > I have provided evidence, it is your side that has refused. Please ratchet down the invective. There are no "sides" here. Further, some of us who disagree with you so far were waiting for you to be clearer: that is quite different that "refusing". > I don't > think I have seen a single use case from you ever. The use cases for TLSA are listed in the draft. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E0E28C0F6 for ; Mon, 17 Jan 2011 08:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv5owr86VKkn for ; Mon, 17 Jan 2011 08:30:59 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1B99828C0F1 for ; Mon, 17 Jan 2011 08:30:59 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 9E2D4BF8B; Mon, 17 Jan 2011 11:33:32 -0500 (EST) Date: Mon, 17 Jan 2011 11:33:32 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D3469EA.5000509@vpnc.org> Message-ID: References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> <4D3469EA.5000509@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:31:00 -0000 On Mon, 17 Jan 2011, Paul Hoffman wrote: > I agree that we should nail down in the spec whether PKIX information other > than the key itself should be paid attention to in end-entity certificates > gotten through TLSA. I disagree that we want to have two semantics based on > different values in the TLSA record. Doing so says that the server gets to > tell the client what security policy the client should use. So change it from "ignored" to "MAY ignore" ? Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731553A6F51 for ; Mon, 17 Jan 2011 08:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.712 X-Spam-Level: X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKUnLU035Nom for ; Mon, 17 Jan 2011 08:18:01 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 896BF28C0DD for ; Mon, 17 Jan 2011 08:18:01 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0HGAIer084715 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 17 Jan 2011 09:10:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3469EA.5000509@vpnc.org> Date: Mon, 17 Jan 2011 08:10:18 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:18:03 -0000 On 1/17/11 7:11 AM, Paul Wouters wrote: > > DANE is an alternative for PKIX. > > The important issue here is can someone use both or not, and can someone > migrate from one to the other. DANE should not be limited by PKIX, just > like PKIX should not be limited by DANE. But we have had this discussion > a few times already. > > My concern is for example with the regularly seen expired certificates. I > forsee people, especially those using self signed certificates, to > generate TLSA records and forget about their certificate's expiry date. > > I think there is real value in ignoring all certificate properties. But we > could decide on making such a TLSA record have its own "certificate type". > > eg, we could add type 5/6 to section 2 of the DANE draft: > > 5 Hash of a public key taken from an end-entity certificate. All PKIX > elements are specifically ignored. > > 6 Full public key taken from an end-entity certificate. All PKIX > elements are specifically ignored. I agree that we should nail down in the spec whether PKIX information other than the key itself should be paid attention to in end-entity certificates gotten through TLSA. I disagree that we want to have two semantics based on different values in the TLSA record. Doing so says that the server gets to tell the client what security policy the client should use. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072CA28C0E0 for ; Mon, 17 Jan 2011 08:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G6BZBahvNeH for ; Mon, 17 Jan 2011 08:16:26 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 52A373A6F4E for ; Mon, 17 Jan 2011 08:16:26 -0800 (PST) Received: by yxt33 with SMTP id 33so2227093yxt.31 for ; Mon, 17 Jan 2011 08:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WGvfBEa9lhOuifGkVpWvq3RS2x9RpunYCcSkQinarRc=; b=qWFpIPOg7hIwrGR5pFUo+VqRzCildXxlheK4oCJ1/KIk2YrbIbm9PvlHXiIaNTYw+t iAlyjdTJP2MX6Lt8vLFuUzal5xJ+h4Y89ahW8OCYaJYz/KmBx6uffxjK4fps+hpWAqd9 t6FeNIAWI7jOiKu8A1wTyUZvaGJqp2/BStRAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eVEKdy0IWdl8ypbMt8amx79iMNkCxdjYXPMgZHVOwrMuSNMgNxcY23f1iAzt5v71M8 EHxl2zphli1Rts5CfizUchvkhICNmpj+XrbUwZEY+zAUIfjdH919DUhNFqbrBWengW5x qt1lWXAjS/D7DwMAu3JzPgTheeZSX4ReiqLRU= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr2621584anf.103.1295281140521; Mon, 17 Jan 2011 08:19:00 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 08:18:57 -0800 (PST) In-Reply-To: <4D345BA3.5010206@nic.cz> References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> <4D345BA3.5010206@nic.cz> Date: Mon, 17 Jan 2011 11:18:57 -0500 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Content-Type: multipart/alternative; boundary=0016e64f8f4a43dc90049a0d241c Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 16:16:28 -0000 --0016e64f8f4a43dc90049a0d241c Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable This is an existing security control established in PKIX I believe the burden of proof is on those proposing to make a change that they are not going to cause damage. Now if you look at this thread, I have given numerous use cases that demonstrate a need for what I am arguing for. I have not seen any use case given in favor of ignoring the information. I have provided evidence, it is your side that has refused. I don't think I have seen a single use case from you ever. 2011/1/17 Ond=F8ej Sur=FD > I have politely asked you to provide evidence that it's going to be issue= , > so we can continue the discussion. Yet you came back with threats about > WGLC and IETFLC and a straw man argument that I block the discussion. > > Hence I believe no further discussion is possible. If you have arguments > which I have asked for then I would be more than happy to continue this > discussion in productive and constructive manner. > > Ondrej > > > On 17.1.2011 15:55, Phillip Hallam-Baker wrote: > >> OK, we will return to this in last call then >> >> And in IETF last call >> >> And when the PKIX people object to your whole spec on the grounds that >> you are changing theirs we can start DANE from scratch >> >> >> Blocking discussion of critical security issues in the WG is not going >> to get you to RFC any faster. >> >> You cannot claim to have a WG consensus if your response to every issue >> you don't like is to put your chair hart on and attempt to block >> discussion. >> >> >> On Mon, Jan 17, 2011 at 9:50 AM, Ond=F8ej Sur=FD > > wrote: >> >> On 17.1.2011 15:30, Phillip Hallam-Baker wrote: >> >> The specific concern would be that someone could make use of the >> lightweight SMTP cert issue process to acquire a certificate for >> another >> service. >> >> > >> >> Another concern would be that in a heavily outsourced >> deployment, I may >> trust a company to run my inbound mail server but not want them >> to have >> the ability to advertise other services (like accepting payments)= . >> >> The simplest, most direct way to enforce this type of >> restriction is to >> put a note in the certificate governing acceptable use. >> >> >> No, the simplest, most direct way (apart from not using DANE at all) >> is to have different host names for inbound mail server and other >> services. >> >> You have painted the very rare scenario in which the canonical name >> (ie. the target of MX record) is same as some other service, and you >> document the degradation of security on such unlikely scenario. >> >> >> I propose that either you present an evidence that it will have any >> real impact or we just drop this issue since it's impact is >> negligible. Thank you. >> >> >> BTW: I just hand checked top20 domain names from alexa list and all >> of them has something like [.*][mx|mail|smtp]. for >> where usually domainname1 =3D domainname2. >> >> O. >> >> -- >> Ond=F8ej Sur=FD >> vedouc=ED v=FDzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz= / >> >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> >> https://www.ietf.org/mailman/listinfo/keyassure >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> > > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ --0016e64f8f4a43dc90049a0d241c Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable This is an existing security control established in PKIX

I believe the burden of proof is on those proposing to make a change that = they are not going to cause damage.


Now if you look at this thread, I have given numerous use cases that demons= trate a need for what I am arguing for. I have not seen any use case given = in favor of ignoring the information.

I have provi= ded evidence, it is your side that has refused. I don't think I have se= en a single use case from you ever.



2011/1/17 Ond=F8ej S= ur=FD <ondrej.su= ry@nic.cz>
I have politely asked you to provide evidence that it's going to be iss= ue, so we can continue the discussion. =A0Yet you came back with threats ab= out WGLC and IETFLC and a straw man argument that I block the discussion.
Hence I believe no further discussion is possible. =A0If you have arguments= which I have asked for then I would be more than happy to continue this di= scussion in productive and constructive manner.

Ondrej


On 17.1.2011 15:55, Phillip Hallam-Baker wrote:
OK, we will return to this in last call then

And in IETF last call

And when the PKIX people object to your whole spec on the grounds that
you are changing theirs we can start DANE from scratch


Blocking discussion of critical security issues in the WG is not going
to get you to RFC any faster.

You cannot claim to have a WG consensus if your response to every issue
you don't like is to put your chair hart on and attempt to block discus= sion.


On Mon, Jan 17, 2011 at 9:50 AM, Ond=F8ej Sur=FD <ondrej.sury@nic.cz
<mailto:ondrej.s= ury@nic.cz>> wrote:

=A0 =A0On 17.1.2011 15:30, Phillip Hallam-Baker wrote:

=A0 =A0 =A0 =A0The specific concern would be that someone could make use o= f the
=A0 =A0 =A0 =A0lightweight SMTP cert issue process to acquire a certificat= e for
=A0 =A0 =A0 =A0another
=A0 =A0 =A0 =A0service.

=A0 =A0 >

=A0 =A0 =A0 =A0Another concern would be that in a heavily outsourced
=A0 =A0 =A0 =A0deployment, I may
=A0 =A0 =A0 =A0trust a company to run my inbound mail server but not want = them
=A0 =A0 =A0 =A0to have
=A0 =A0 =A0 =A0the ability to advertise other services (like accepting pay= ments).

=A0 =A0 =A0 =A0The simplest, most direct way to enforce this type of
=A0 =A0 =A0 =A0restriction is to
=A0 =A0 =A0 =A0put a note in the certificate governing acceptable use.


=A0 =A0No, the simplest, most direct way (apart from not using DANE at all= )
=A0 =A0is to have different host names for inbound mail server and other =A0 =A0services.

=A0 =A0You have painted the very rare scenario in which the canonical name=
=A0 =A0(ie. the target of MX record) is same as some other service, and yo= u
=A0 =A0document the degradation of security on such unlikely scenario.

=A0 =A0<chair hat>
=A0 =A0I propose that either you present an evidence that it will have any=
=A0 =A0real impact or we just drop this issue since it's impact is
=A0 =A0negligible. Thank you.
=A0 =A0</chair hat>

=A0 =A0BTW: I just hand checked top20 domain names from alexa list and all=
=A0 =A0of them has something like [.*][mx|mail|smtp].<domainname1> f= or
=A0 =A0<domainname2> where usually domainname1 =3D domainname2.

=A0 =A0O.

=A0 =A0--
=A0 =A0 =A0Ond=F8ej Sur=FD
=A0 =A0 =A0vedouc=ED v=FDzkumu/Head of R&D department
=A0 =A0 =A0-------------------------------------------
=A0 =A0 =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0 =A0 =A0Americka 23, 120 00 Praha 2, Czech Republic
=A0 =A0 =A0mailto:= ondrej.sury@nic.cz <mailto:ondrej.sury@nic.cz> http://nic.cz/

=A0 =A0 =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0 =A0 =A0-------------------------------------------
=A0 =A0_______________________________________________
=A0 =A0keyassure mailing list
=A0 =A0keyassure@i= etf.org <mailto:keyassure@ietf.org>

=A0 =A0https://www.ietf.org/mailman/listinfo/keyassure




--
Website: http://halla= mbaker.com/



--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------
_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e64f8f4a43dc90049a0d241c-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E2528C11D for ; Mon, 17 Jan 2011 07:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvzfHmBuo7MX for ; Mon, 17 Jan 2011 07:45:21 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B84D33A6D4E for ; Mon, 17 Jan 2011 07:45:20 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0HFjnFv004422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jan 2011 16:45:49 +0100 (MET) From: Martin Rex Message-Id: <201101171545.p0HFjnqN024402@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 17 Jan 2011 16:45:49 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Jan 16, 11 10:01:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:45:21 -0000 Phillip Hallam-Baker wrote: > > There are only two key formats that are widely used: X.509 and PGP. The PGP > format is expressly designed to support Web of trust and so is irrelevant > here because what we are doing is the exact opposite of what Phil Zimmerman > proposed. Two-factor authentication has become popular for humans, because if adequately set up, administrated and used it will require the two simultaneous security breaches for an unauthorized access. The X.509 architecture has a design flaw that limits the security to n-factor (n<=1). For the existing TLS X.509 PKI n is around 1/600 (0.00167) The PGP web of trust provides n-factor security (n>=1), and obtaining (n>>1) is easy and straightforward. keyassurance through DNSSEC might be used to get back an n-factor security with X.509 TLS PKI closer to n=1 (or even slightly better). While it's true that a PGP n-factor server authentication based on pre-shared PGP trust anchors would work entirely without DNSSEC-based key assurance (requiring PGP-enabled TLS on both ends, of course), it might still be useful for the situation where there are no pre-shared PGP trust anchors and either trusting DNSSEC or allowing a leap-of-faith distribution of PGP keys or trust anchors under protection of DNSSEC keys. -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426E428C0D7 for ; Mon, 17 Jan 2011 07:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiNXI1GtupBs for ; Mon, 17 Jan 2011 07:09:02 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4C40128C10A for ; Mon, 17 Jan 2011 07:09:02 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 41733C4D3; Mon, 17 Jan 2011 10:11:36 -0500 (EST) Date: Mon, 17 Jan 2011 10:11:35 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: [keyassure] Possible fix for pkix/dane certificate disagreement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:09:03 -0000 DANE is an alternative for PKIX. The important issue here is can someone use both or not, and can someone migrate from one to the other. DANE should not be limited by PKIX, just like PKIX should not be limited by DANE. But we have had this discussion a few times already. My concern is for example with the regularly seen expired certificates. I forsee people, especially those using self signed certificates, to generate TLSA records and forget about their certificate's expiry date. I think there is real value in ignoring all certificate properties. But we could decide on making such a TLSA record have its own "certificate type". eg, we could add type 5/6 to section 2 of the DANE draft: 5 Hash of a public key taken from an end-entity certificate. All PKIX elements are specifically ignored. 6 Full public key taken from an end-entity certificate. All PKIX elements are specifically ignored. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D0F28C136 for ; Mon, 17 Jan 2011 07:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbPw94lcsILL for ; Mon, 17 Jan 2011 07:06:51 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 3F2F728C133 for ; Mon, 17 Jan 2011 07:06:50 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id C9D4A734360 for ; Mon, 17 Jan 2011 16:09:23 +0100 (CET) Message-ID: <4D345BA3.5010206@nic.cz> Date: Mon, 17 Jan 2011 16:09:23 +0100 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:06:52 -0000 I have politely asked you to provide evidence that it's going to be issue, so we can continue the discussion. Yet you came back with threats about WGLC and IETFLC and a straw man argument that I block the discussion. Hence I believe no further discussion is possible. If you have arguments which I have asked for then I would be more than happy to continue this discussion in productive and constructive manner. Ondrej On 17.1.2011 15:55, Phillip Hallam-Baker wrote: > OK, we will return to this in last call then > > And in IETF last call > > And when the PKIX people object to your whole spec on the grounds that > you are changing theirs we can start DANE from scratch > > > Blocking discussion of critical security issues in the WG is not going > to get you to RFC any faster. > > You cannot claim to have a WG consensus if your response to every issue > you don't like is to put your chair hart on and attempt to block discussion. > > > On Mon, Jan 17, 2011 at 9:50 AM, Ondøej Surý > wrote: > > On 17.1.2011 15:30, Phillip Hallam-Baker wrote: > > The specific concern would be that someone could make use of the > lightweight SMTP cert issue process to acquire a certificate for > another > service. > > > > > Another concern would be that in a heavily outsourced > deployment, I may > trust a company to run my inbound mail server but not want them > to have > the ability to advertise other services (like accepting payments). > > The simplest, most direct way to enforce this type of > restriction is to > put a note in the certificate governing acceptable use. > > > No, the simplest, most direct way (apart from not using DANE at all) > is to have different host names for inbound mail server and other > services. > > You have painted the very rare scenario in which the canonical name > (ie. the target of MX record) is same as some other service, and you > document the degradation of security on such unlikely scenario. > > > I propose that either you present an evidence that it will have any > real impact or we just drop this issue since it's impact is > negligible. Thank you. > > > BTW: I just hand checked top20 domain names from alexa list and all > of them has something like [.*][mx|mail|smtp]. for > where usually domainname1 = domainname2. > > O. > > -- > Ondøej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoøe CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > > > -- > Website: http://hallambaker.com/ > -- Ondøej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoøe CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16FA3A6E53 for ; Mon, 17 Jan 2011 06:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfXZ+-KXfxhA for ; Mon, 17 Jan 2011 06:54:23 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id E2A913A6B61 for ; Mon, 17 Jan 2011 06:54:22 -0800 (PST) Received: by gwj17 with SMTP id 17so2186627gwj.31 for ; Mon, 17 Jan 2011 06:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jjgIjsPBO9BTQ4uMr5OuX33YHvVrsI+9WDDmDAYuwoE=; b=xaXPCAuRlMat7SNdxVt7UEYBEzYW6ZXnuu4PK2eG4bgmNgWom3VzFQeISrSjgBwP0s CTM5+HQ7hc48uUvkgNv1CO5Go9LKo4Q/OyK7R0G6fdJ4bCfbqptrmDbgQbI7XTScXZwr k8V8fsTlyppdrB+gsF7G5oAHbzRbnUMfEMy6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FTSvcZhqlnjJvJlfaHckk9H2QxmNQ1gIe4PzN3C9H56vSmqy769jKeGbvssv+auSRW rwCgkZHRvXSxWe9AkQp5jPEe1eThRadGK+qzIQUHoYkjMr+m9LDwdVGIhjcmfkr+Jptp KVd44LkQLjfAXSEiPDdVlMC829rH74uvcSk/g= MIME-Version: 1.0 Received: by 10.100.48.13 with SMTP id v13mr44293anv.69.1295276217069; Mon, 17 Jan 2011 06:56:57 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 06:56:56 -0800 (PST) In-Reply-To: References: <4D3403D4.6090702@nic.cz> <4D344DED.8090907@nic.cz> Date: Mon, 17 Jan 2011 09:56:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e644bc2ecdf0f2049a0bfe56 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:54:24 -0000 --0016e644bc2ecdf0f2049a0bfe56 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 2011/1/17 Paul Wouters > On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > > 2011/1/17 Ond=F8ej Sur=FD >> >> We should solve the hardest problem first. >> >> Which in your opinion is? >> >> Working out how to support HTTP over TLS, SMTP over TLS and protocol X >> over TLS without conflict. >> > > Using which certificate validation scheme? DANE or PKIX/CA's? or Both? > > The last one is out of scope for DANE. The first one is by generating > TLSA/HASTLS records that the application can look up - ignoring everythin= g > else in the certificate container. > DANE has to prove that it can co-exist in the existing infrastructure without causing damage. --=20 Website: http://hallambaker.com/ --0016e644bc2ecdf0f2049a0bfe56 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

2011/1/17 Paul Wouters <paul@xelerance.com>
On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:

2011/1/17 Ond=F8ej Sur=FD <ondrej.sury@nic.cz>

=A0 =A0 =A0We should solve the hardest problem first.

Which in your opinion is?

Working out how to support HTTP over TLS, SMTP over TLS and protocol X over= TLS without conflict.

Using which certificate validation scheme? DANE or PKIX/CA's? or Both?<= br>
The last one is out of scope for DANE. The first one is by generating
TLSA/HASTLS records that the application can look up - ignoring everything<= br> else in the certificate container.

DANE= has to prove that it can co-exist in the existing infrastructure without c= ausing damage.



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

--0016e644bc2ecdf0f2049a0bfe56-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAD63A6E62 for ; Mon, 17 Jan 2011 06:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIqUWVKw7I87 for ; Mon, 17 Jan 2011 06:52:52 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 73A173A6B61 for ; Mon, 17 Jan 2011 06:52:52 -0800 (PST) Received: by gwj17 with SMTP id 17so2186080gwj.31 for ; Mon, 17 Jan 2011 06:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OERaKLxMtMPTgjq4asb5WUNKyXTD+SzYN5iTe6w2YN0=; b=QPo2opnTTtyvrmfUfSmjHTYCxspbMuGh/AtsolgiW7XZIqh6Ew6Ntw1W2gVYt+13Rg ElVBWMJYkEw7XWeLSCMgwrP1KGaxAHGtq6m/MsJmWVwwXnIYUG4ieJGmXziuomvN13/A tZr01gC5De+Yy3d4Rr/vIyxNEpG+paTS7C1ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IrWQcDhis5E3N3Z5t34FyAuo33nazCx99Of5xxFWyeNFUzCuxewd0OVFpOhxkRHJSv 2+Dc1fkzwWhFqh6hJr5a+QgN2N4XnJyhQm3R3nWyWVDGi1BtUH02hI5XL4pdjbwI8fjq CFP8bzXA5JW6zYyKO70Dq6iW512fJawu2wVMM= MIME-Version: 1.0 Received: by 10.100.242.4 with SMTP id p4mr2545688anh.205.1295276125350; Mon, 17 Jan 2011 06:55:25 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 06:55:25 -0800 (PST) In-Reply-To: <4D34573A.1090509@nic.cz> References: <4D334A39.9050109@gmail.com> <4D34573A.1090509@nic.cz> Date: Mon, 17 Jan 2011 09:55:25 -0500 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636af0272566b92049a0bf958 Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:52:54 -0000 --001636af0272566b92049a0bf958 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable OK, we will return to this in last call then And in IETF last call And when the PKIX people object to your whole spec on the grounds that you are changing theirs we can start DANE from scratch Blocking discussion of critical security issues in the WG is not going to get you to RFC any faster. You cannot claim to have a WG consensus if your response to every issue you don't like is to put your chair hart on and attempt to block discussion. On Mon, Jan 17, 2011 at 9:50 AM, Ond=F8ej Sur=FD wrote= : > On 17.1.2011 15:30, Phillip Hallam-Baker wrote: > >> The specific concern would be that someone could make use of the >> lightweight SMTP cert issue process to acquire a certificate for another >> service. >> > > > >> Another concern would be that in a heavily outsourced deployment, I may >> trust a company to run my inbound mail server but not want them to have >> the ability to advertise other services (like accepting payments). >> >> The simplest, most direct way to enforce this type of restriction is to >> put a note in the certificate governing acceptable use. >> > > No, the simplest, most direct way (apart from not using DANE at all) is t= o > have different host names for inbound mail server and other services. > > You have painted the very rare scenario in which the canonical name (ie. > the target of MX record) is same as some other service, and you document = the > degradation of security on such unlikely scenario. > > > I propose that either you present an evidence that it will have any real > impact or we just drop this issue since it's impact is negligible. Thank > you. > > > BTW: I just hand checked top20 domain names from alexa list and all of th= em > has something like [.*][mx|mail|smtp]. for whe= re > usually domainname1 =3D domainname2. > > O. > > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ --001636af0272566b92049a0bf958 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable OK, we will return to this in last call then

And in IETF= last call

And when the PKIX people object to your= whole spec on the grounds that you are changing theirs we can start DANE f= rom scratch


Blocking discussion of critical security= issues in the WG is not going to get you to RFC any faster.

=
You cannot claim to have a WG consensus if your response to ever= y issue you don't like is to put your chair hart on and attempt to bloc= k discussion.


On Mon, Jan 17, 2011 at = 9:50 AM, Ond=F8ej Sur=FD <ondrej.sury@nic.cz> wrote:
On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
The specific concern would be that someone could make use of the
lightweight SMTP cert issue process to acquire a certificate for another service.
>
Another concern would be that in a heavily outsourced deployment, I may
trust a company to run my inbound mail server but not want them to have
the ability to advertise other services (like accepting payments).

The simplest, most direct way to enforce this type of restriction is to
put a note in the certificate governing acceptable use.

No, the simplest, most direct way (apart from not using DANE at all) is to = have different host names for inbound mail server and other services.

You have painted the very rare scenario in which the canonical name (ie. th= e target of MX record) is same as some other service, and you document the = degradation of security on such unlikely scenario.

<chair hat>
I propose that either you present an evidence that it will have any real im= pact or we just drop this issue since it's impact is negligible. Thank = you.
</chair hat>

BTW: I just hand checked top20 domain names from alexa list and all of them= has something like [.*][mx|mail|smtp].<domainname1> for <domainna= me2> where usually domainname1 =3D domainname2.

O.

--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------
_______________________________________________



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

--001636af0272566b92049a0bf958-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED84F3A6B61 for ; Mon, 17 Jan 2011 06:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLJE+N9IxgwE for ; Mon, 17 Jan 2011 06:51:50 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id DFD713A6C25 for ; Mon, 17 Jan 2011 06:51:49 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 7A4FFBF8B; Mon, 17 Jan 2011 09:54:23 -0500 (EST) Date: Mon, 17 Jan 2011 09:54:23 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D3403D4.6090702@nic.cz> <4D344DED.8090907@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:51:52 -0000 On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > 2011/1/17 Ondøej Surý > > We should solve the hardest problem first. > > Which in your opinion is? > > Working out how to support HTTP over TLS, SMTP over TLS and protocol X over TLS without conflict. Using which certificate validation scheme? DANE or PKIX/CA's? or Both? The last one is out of scope for DANE. The first one is by generating TLSA/HASTLS records that the application can look up - ignoring everything else in the certificate container. The combination of the two, which can be conflicting, can only be left as local site/vendor policy. So I am not sure what there is left to "solve" Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42193A6C25 for ; Mon, 17 Jan 2011 06:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4z0ants33oo for ; Mon, 17 Jan 2011 06:49:16 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 63E2A3A6B61 for ; Mon, 17 Jan 2011 06:49:16 -0800 (PST) Received: by yxt33 with SMTP id 33so2189688yxt.31 for ; Mon, 17 Jan 2011 06:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t/HTWR6Gb0aX0OSsllTp8vjiaySUwpwkpctVLLYQyqk=; b=ENFloIjAub+IRyP5J43vxxhFWKXVyuXwy3/9EXIVlc0DjjPjtvD3cOAHJUF08B2KpZ DTYFE8vJEzMOYbLOVxQfXgdyNtuE/EtPQ25enn/1ulFR7VJVx4PCUtKiLmKAACyooFdr +I0UJKJ24+iwG//gfyy8bK7F++51SHoo5QHz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MGEDanYhVaFiQ3vkR19Xm1dJUd2bV6XsJQYZwkSJkIt3nz7kM0O+Mu1wi3bHDhvQt1 SO/W7pYIZmoAChc09wo8griXyYddAhkl26xepxMOY8mZTSoNtxOmju60p9gfCn19wg8+ 4tSA8FjN4OYRsMVmLb1J7ry6iqhUC0+/hRJBQ= MIME-Version: 1.0 Received: by 10.100.174.5 with SMTP id w5mr2592354ane.171.1295275910555; Mon, 17 Jan 2011 06:51:50 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 06:51:50 -0800 (PST) In-Reply-To: <4D34538F.9010001@nic.cz> References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> <4D34538F.9010001@nic.cz> Date: Mon, 17 Jan 2011 09:51:50 -0500 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Content-Type: multipart/alternative; boundary=0016e64405a088e817049a0bec42 Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:49:17 -0000 --0016e64405a088e817049a0bec42 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 2011/1/17 Ond=F8ej Sur=FD > On 17.1.2011 15:20, Phillip Hallam-Baker wrote: > >> Rule number one is do no harm. >> >> If this group proposes a spec that damages the security of other >> infrastructure it is going to be resisted. >> > > You have created the hypothetical scenario in which the harm is created. = I > find such scenario unlikely for security wise administrators (the admin > blindly pasting output of some random sendmail script into the DNS). Relying on the competence of administrators to fix protocol security shortcomings is not acceptable. All I am arguing for here is that this group does not presume to turn off security controls that already exist in PKIX because it does not understand what they are for. Postulating a competent administrator is another way of saying 'lets rely o= n magic here'. Anyone can design a system that is secure when someone who is competent (an= d honest) uses it. But in the real world only some people are competent some of the time. Deployment of DNSSEC is already going to be a bear of a job. And you are arguing that its ok to turn off controls to make it harder. --=20 Website: http://hallambaker.com/ --0016e64405a088e817049a0bec42 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

2011/1/17 Ond=F8ej Sur=FD <ondrej.sury@nic.cz>
On 17.1.2011 15:20, Phillip Hallam-Baker wrote:
Rule number one is do no harm.

If this group proposes a spec that damages the security of other
infrastructure it is going to be resisted.

You have created the hypothetical scenario in which the harm is created. = =A0I find such scenario unlikely for security wise administrators (the admi= n blindly pasting output of some random sendmail script into the DNS).

Relying on the competence of administrators to fix prot= ocol security shortcomings is not acceptable.

All = I am arguing for here is that this group does not presume to turn off secur= ity controls that already exist in PKIX because it does not understand what= they are for.


Postulating a competent administrator is= another way of saying 'lets rely on magic here'.

Anyone can design a system that is secure when someone who is compe= tent (and honest) uses it. But in the real world only some people are compe= tent some of the time.

Deployment of DNSSEC is already going to be a bear of a= job. And you are arguing that its ok to turn off controls to make it harde= r.



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

--0016e64405a088e817049a0bec42-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37493A6E62 for ; Mon, 17 Jan 2011 06:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJMDV7BNDZ+v for ; Mon, 17 Jan 2011 06:48:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 65DAA3A6C25 for ; Mon, 17 Jan 2011 06:48:03 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id BC059734360 for ; Mon, 17 Jan 2011 15:50:34 +0100 (CET) Message-ID: <4D34573A.1090509@nic.cz> Date: Mon, 17 Jan 2011 15:50:34 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:48:05 -0000 On 17.1.2011 15:30, Phillip Hallam-Baker wrote: > The specific concern would be that someone could make use of the > lightweight SMTP cert issue process to acquire a certificate for another > service. > > Another concern would be that in a heavily outsourced deployment, I may > trust a company to run my inbound mail server but not want them to have > the ability to advertise other services (like accepting payments). > > The simplest, most direct way to enforce this type of restriction is to > put a note in the certificate governing acceptable use. No, the simplest, most direct way (apart from not using DANE at all) is to have different host names for inbound mail server and other services. You have painted the very rare scenario in which the canonical name (ie. the target of MX record) is same as some other service, and you document the degradation of security on such unlikely scenario. I propose that either you present an evidence that it will have any real impact or we just drop this issue since it's impact is negligible. Thank you. BTW: I just hand checked top20 domain names from alexa list and all of them has something like [.*][mx|mail|smtp]. for where usually domainname1 = domainname2. O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF7E28C0DF for ; Mon, 17 Jan 2011 06:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnZBJBUPlA+r for ; Mon, 17 Jan 2011 06:35:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A3BC93A6E62 for ; Mon, 17 Jan 2011 06:35:38 -0800 (PST) Received: by ywk9 with SMTP id 9so1903902ywk.31 for ; Mon, 17 Jan 2011 06:38:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lv/qCPf9RVCYQCtT4lriWX9Moo+eTQdKpoww7ojrJ70=; b=tZBrdBKZuhgbBCdv9BH3GpkW8trhgR/CLldoQfKxUCi9Q/J8wKhnWHBm7AEz1zx3KZ 8YDAeuZusZ9K4nit+JPOjzBRzSz2I4rEqbFgevQ29lJxeMUa39nClDIz12+NNfpqPr8K Il1H6IiqeqTITIAPDbUuZkfoA3PjnATOjY/1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qoGvAYfTC00fJVX+ZQhWNut5Q6gBKyU7SwTNlnxq9ghSF0EEgEKQel9wsj2qzqZ5Fi uJ6PD6Wc944yleHS6CTofjkxKS/am0E14+5bIYm2geXXXJOPzUfPGXue7K7d7+eFsh0G vVnyv87EzC7JG/70MimHr05C1Apq/MrSuKDVs= MIME-Version: 1.0 Received: by 10.100.153.17 with SMTP id a17mr2527903ane.239.1295275092585; Mon, 17 Jan 2011 06:38:12 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 06:38:12 -0800 (PST) In-Reply-To: <4D344DED.8090907@nic.cz> References: <4D3403D4.6090702@nic.cz> <4D344DED.8090907@nic.cz> Date: Mon, 17 Jan 2011 09:38:12 -0500 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= Content-Type: multipart/alternative; boundary=0016e644d5ccc7ae8c049a0bbb24 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:35:40 -0000 --0016e644d5ccc7ae8c049a0bbb24 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 2011/1/17 Ond=F8ej Sur=FD > > We should solve the hardest problem first. >> > > Which in your opinion is? Working out how to support HTTP over TLS, SMTP over TLS and protocol X over TLS without conflict. --=20 Website: http://hallambaker.com/ --0016e644d5ccc7ae8c049a0bbb24 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 2011/1/17 Ond=F8ej Sur=FD <ondrej.sury@nic.cz>
=

We should solve the hardest problem first.

Which in your opinion is?

Working out how t= o support HTTP over TLS, SMTP over TLS and protocol X over TLS without conf= lict.




--
Website: http://hallambaker.com/
--0016e644d5ccc7ae8c049a0bbb24-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D743F28C10A for ; Mon, 17 Jan 2011 06:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5ZeryPBQYhf for ; Mon, 17 Jan 2011 06:32:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id B564D28C136 for ; Mon, 17 Jan 2011 06:32:21 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 5C5F8734352 for ; Mon, 17 Jan 2011 15:34:55 +0100 (CET) Message-ID: <4D34538F.9010001@nic.cz> Date: Mon, 17 Jan 2011 15:34:55 +0100 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:32:24 -0000 On 17.1.2011 15:20, Phillip Hallam-Baker wrote: > Rule number one is do no harm. > > If this group proposes a spec that damages the security of other > infrastructure it is going to be resisted. You have created the hypothetical scenario in which the harm is created. I find such scenario unlikely for security wise administrators (the admin blindly pasting output of some random sendmail script into the DNS). > DNS name allocation has always been left to site policy. The target of > an MX record is required to be a canonical name. Thus it should be the > unique name of the host. And the usage of the (one or more different) certificates was also a site policy, yet you are proposing that we should include it now into the protocol. > If you want to propose unnecessary changes to DNS operations to make > your specification proposal work then you are going to find getting IETF > consensus very difficult. I am proposing no such thing. I am proposing we should leave the decisions up to the site admins, who knows the best how to deal with certificates, host names etc. according to their local (site) policy. If we want to be extra sure that we document security properly we could create a BCP (or series of BCP) document(s) on how to handle specific protocols. Right now I see no real need to include usage specifier into DANE protocol. That might change on the basis of issue #1 result, but right now I doubt it. Ondrej > On Mon, Jan 17, 2011 at 8:48 AM, Ondøej Surý > wrote: > > On 17.1.2011 13:52, Phillip Hallam-Baker wrote: > > > > On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters > > >> wrote: > > On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > > I would like it to be possible for services like SMTP to > establish TLS keys with minimal infrastructure. That > can't happen if there is a risk that the low assurance > SMTP key > will compromise the high assurance Web Server. > > > I'm not sure how this problem would work. Can you explain it > in a > little more detail? > > Paul > > > Let us say that the authors of Sendmail decide that they want to > make it > easy to turn on STARTTLS. > > So when the server is configured it looks to see if there is > DNSSEC on > the domain associated with its host name. If so it generates a > public > key pair, rolls itself a certificate and either tells the admin > the DNS > RR to insert in the zone or uses a TSIG type mechanism to > register the > key itself. > > > For this to be acceptable two conditions need to be met: > > 1) The security must be adequate for the SMTP service > > 2) The mechanism must not reduce the security of any other > service at > the domain > > > Since SMTP is generally engaged without cryptographic security, any > improvement is better than none and the first condition is a > really low bar. > > But the second can be very complex. Particularly since the > authors of > the mail server don't want to have any idea what the rest of the > infrastructure might be at a site. > > The safest way to make this work automatically is to make it > possible > for the mail service to mark its keys for SMTP use only. > > > I don't think we need to solve 2) from this babysitting perspective. > > What you are talking about is about having different certs for > different services and we are back at issue #1 in the tracker. > > If I take your example then most common case is that SMTP server is > named mail., f.e. mail.example.net > . And I guess in most cases it will not > clash with another services under this name. And it should be > handled by the admins in the few corner cases where the name of the > mail server is same as name of some other important service. > > Ondrej > -- > Ondøej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoøe CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > > > -- > Website: http://hallambaker.com/ > -- Ondøej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoøe CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C1228C13C for ; Mon, 17 Jan 2011 06:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHzDpKTV9L4b for ; Mon, 17 Jan 2011 06:32:21 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id B0EAA28C133 for ; Mon, 17 Jan 2011 06:32:21 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id AA545BF8B; Mon, 17 Jan 2011 09:34:55 -0500 (EST) Date: Mon, 17 Jan 2011 09:34:55 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:32:22 -0000 On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > The specific concern would be that someone could make use of the lightweight SMTP cert issue process to acquire a certificate for another > service. > > Another concern would be that in a heavily outsourced deployment, I may trust a company to run my inbound mail server but not want them to have > the ability to advertise other services (like accepting payments). > > The simplest, most direct way to enforce this type of restriction is to put a note in the certificate governing acceptable use. So issue such a certificate, and use PCIX and trusted CA's like the currently deployed sites do? Don't use DANE. What would DANE buy you in this case? Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF4928C0D9 for ; Mon, 17 Jan 2011 06:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ye9nLcKqI6y for ; Mon, 17 Jan 2011 06:30:15 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 55C973A6E62 for ; Mon, 17 Jan 2011 06:30:15 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 23146BF8B; Mon, 17 Jan 2011 09:32:49 -0500 (EST) Date: Mon, 17 Jan 2011 09:32:48 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:30:17 -0000 On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > Rule number one is do no harm. > If this group proposes a spec that damages the security of other infrastructure it is going to be resisted. Though written as a definite statement, I don't think there is agreement that DANE in its current form would "damage" existing infrastructure. This seems self-evident as anyone can decide as a site policy not to deploy DANE and use any existing security infrastructure (such as trusted CAs) > DNS name allocation has always been left to site policy. DANE would not change that. > The target of an MX record is required to be a canonical name. Thus it should be the > unique name of the host. I know many mail servers that listen to mail.exmaple.com though it is not their unique name, especially when running mail for more then one domain. In fact, the hostname of the machine is pretty irrelevant to its name in DNS. > If you want to propose unnecessary changes to DNS operations to make your specification proposal work then you are going to find getting IETF > consensus very difficult. I find these general top quoted statements without any context quite frustrating to process. Paul > > On Mon, Jan 17, 2011 at 8:48 AM, Ondøej Surý wrote: > On 17.1.2011 13:52, Phillip Hallam-Baker wrote: > > > On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters > wrote: > >    On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > >        I would like it to be possible for services like SMTP to >        establish TLS keys with minimal infrastructure. That >        can't happen if there is a risk that the low assurance SMTP key >        will compromise the high assurance Web Server. > > >    I'm not sure how this problem would work. Can you explain it in a >    little more detail? > >    Paul > > > Let us say that the authors of Sendmail decide that they want to make it > easy to turn on STARTTLS. > > So when the server is configured it looks to see if there is DNSSEC on > the domain associated with its host name. If so it generates a public > key pair, rolls itself a certificate and either tells the admin the DNS > RR to insert in the zone or uses a TSIG type mechanism to register the > key itself. > > > For this to be acceptable two conditions need to be met: > > 1) The security must be adequate for the SMTP service > > 2) The mechanism must not reduce the security of any other service at > the domain > > > Since SMTP is generally engaged without cryptographic security, any > improvement is better than none and the first condition is a really low bar. > > But the second can be very complex. Particularly since the authors of > the mail server don't want to have any idea what the rest of the > infrastructure might be at a site. > > The safest way to make this work automatically is to make it possible > for the mail service to mark its keys for SMTP use only. > > > I don't think we need to solve 2) from this babysitting perspective. > > What you are talking about is about having different certs for different services and we are back at issue #1 in the tracker. > > If I take your example then most common case is that SMTP server is named mail., f.e. mail.example.net.  And I guess in most > cases it will not clash with another services under this name.  And it should be handled by the admins in the few corner cases where the > name of the mail server is same as name of some other important service. > > Ondrej > -- >  Ondøej Surý >  vedoucí výzkumu/Head of R&D department >  ------------------------------------------- >  CZ.NIC, z.s.p.o.    --    Laboratoøe CZ.NIC >  Americka 23, 120 00 Praha 2, Czech Republic >  mailto:ondrej.sury@nic.cz    http://nic.cz/ >  tel:+420.222745110       fax:+420.222745112 >  ------------------------------------------- > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > > > -- > Website: http://hallambaker.com/ > > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E46428C0D9 for ; Mon, 17 Jan 2011 06:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmUp0WvSD+9b for ; Mon, 17 Jan 2011 06:27:31 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id D9CF83A6E62 for ; Mon, 17 Jan 2011 06:27:30 -0800 (PST) Received: by yia28 with SMTP id 28so2675864yia.15 for ; Mon, 17 Jan 2011 06:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TcqgFDNM9u/IpXIEDUA0p+/bcU5EIDo+7uCabJZGZCI=; b=xWsFdMn6di/wsLR3zyQQ+ozVvUlU5gQ9UsmYHlpJmcrjd/bdvJ8AsJjLmsCNS2xlii 6wmuArP54PfXB2pZw/wfRBaNSEs/LESSPLMvtKO/mySVJTbGY+Z1llsPNbAtXyoqiQC4 3eKI7mp1wvqGrsqRSs6uKAY12TQlNNtPzku2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VQxnlPgtWHaDdlVFP+GQ51ppKjTmhDrWoCj3IPIyQSIkaKLVj2XcfatpDHkyJ5LlfY v+J9Kc8JdQYrQ3D2CaUIxpokuqK3JoOyx9x8xnhToH58sWHNv0mIMoEM8boACBcr4Qpn JR+HYI4R8dX2lEsNbUkjrRGfdlercgCNomOj8= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr2569843ank.1.1295274604905; Mon, 17 Jan 2011 06:30:04 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 06:30:04 -0800 (PST) In-Reply-To: References: <4D334A39.9050109@gmail.com> Date: Mon, 17 Jan 2011 09:30:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=00163662e65bb6444b049a0b9ec3 Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:27:33 -0000 --00163662e65bb6444b049a0b9ec3 Content-Type: text/plain; charset=ISO-8859-1 The specific concern would be that someone could make use of the lightweight SMTP cert issue process to acquire a certificate for another service. Another concern would be that in a heavily outsourced deployment, I may trust a company to run my inbound mail server but not want them to have the ability to advertise other services (like accepting payments). The simplest, most direct way to enforce this type of restriction is to put a note in the certificate governing acceptable use. On Mon, Jan 17, 2011 at 9:17 AM, Paul Wouters wrote: > On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > > Let us say that the authors of Sendmail decide that they want to make it >> easy to turn on STARTTLS. >> So when the server is configured it looks to see if there is DNSSEC on the >> domain associated with its host name. If so it generates a public >> key pair, rolls itself a certificate and either tells the admin the DNS RR >> to insert in the zone or uses a TSIG type mechanism to register the >> key itself. >> >> For this to be acceptable two conditions need to be met: >> >> 1) The security must be adequate for the SMTP service >> >> 2) The mechanism must not reduce the security of any other service at the >> domain >> > > It also assumes a "higher secure level" is available for the other (say > www) service, which > already has a cert - issued by the sysadmin and/or signed by a CA -thus > using PKIX. > > > Since SMTP is generally engaged without cryptographic security, any >> improvement is better than none and the first condition is a really low >> bar. >> > > Sure. > > > But the second can be very complex. Particularly since the authors of the >> mail server don't want to have any idea what the rest of the >> infrastructure might be at a site. >> >> The safest way to make this work automatically is to make it possible for >> the mail service to mark its keys for SMTP use only. >> > > I'm still unsure how this affects the cert on the web port? If we have > multiple TLSA certs in DNS under the same name, and one appears on the > mail server and one on the http server, how did the security of the http > server get reduced by sendmail adding its cert to its config and DNS? > > At most, I can think of some compromise/mistake where the mail cert would > get used on the httpd server. Eg a hacker compromises the webserver, the > webserver cert is stored on disk (not in hardware) and password protected > (which AFAIK is quite rare on web servers these days) and will now use > the mail server cert on the web server to do evil. All of which I think > could be done without restarting the webserver and thus losing the web > server certificate. > > Any sufficiently important web server cert will be in stored in hardware > and will be run on a dedicated server that is not also running mail. > > So I find it hard to see a real life use case where abusing the multiple > TLSA certificates would provide a real life issue. > > Paul > -- Website: http://hallambaker.com/ --00163662e65bb6444b049a0b9ec3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The specific concern would be that someone could make use of the lightweigh= t SMTP cert issue process to acquire a certificate for another service.

Another concern would be that in a heavily o= utsourced deployment, I may trust a company to run my inbound mail server b= ut not want them to have the ability to advertise other services (like acce= pting payments).

The simplest, most direct way to enforce this type of r= estriction is to put a note in the certificate governing acceptable use.



On Mon, Jan 17, 2= 011 at 9:17 AM, Paul Wouters <paul@xelerance.com> wrote:
On Mon, 17 Jan 2011, Phil= lip Hallam-Baker wrote:

Let us say that the authors of Sendmail decide that they want to make it ea= sy to turn on STARTTLS.
So when the server is configured it looks to see if there is DNSSEC on the = domain associated with its host name. If so it generates a public
key pair, rolls itself a certificate and either tells the admin the DNS RR = to insert in the zone or uses a TSIG type mechanism to register the
key itself.

For this to be acceptable two conditions need to be met:

1) The security must be adequate for the SMTP service

2) The mechanism must not reduce the security of any other service at the d= omain

It also assumes a "higher secure level" is available for the othe= r (say www) service, which
already has a cert - issued by the sysadmin and/or signed by a CA -thus usi= ng PKIX.


Since SMTP is generally engaged without cryptographic security, any improve= ment is better than none and the first condition is a really low
bar.

Sure.


But the second can be very complex. Particularly since the authors of the m= ail server don't want to have any idea what the rest of the
infrastructure might be at a site.

The safest way to make this work automatically is to make it possible for t= he mail service to mark its keys for SMTP use only.=A0

I'm still unsure how this affects the cert on the web port? If we have<= br> multiple TLSA certs in DNS under the same name, and one appears on the
mail server and one on the http server, how did the security of the http server get reduced by sendmail adding its cert to its config and DNS?

At most, I can think of some compromise/mistake where the mail cert would get used on the httpd server. Eg a hacker compromises the webserver, the webserver cert is stored on disk (not in hardware) and password protected (which AFAIK is quite rare on web servers these days) and will now use
the mail server cert on the web server to do evil. All of which I think
could be done without restarting the webserver and thus losing the web
server certificate.

Any sufficiently important web server cert will be in stored in hardware and will be run on a dedicated server that is not also running mail.

So I find it hard to see a real life use case where abusing the multiple TLSA certificates would provide a real life issue.

Paul



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

--00163662e65bb6444b049a0b9ec3-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E4A3A6F3E for ; Mon, 17 Jan 2011 06:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUb42ma0APEf for ; Mon, 17 Jan 2011 06:22:41 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2C0B928C0F8 for ; Mon, 17 Jan 2011 06:22:41 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 01F9ABF8B; Mon, 17 Jan 2011 09:25:15 -0500 (EST) Date: Mon, 17 Jan 2011 09:25:14 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D3403D4.6090702@nic.cz> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:22:46 -0000 On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > The only reason to narrow consideration to TLS would be to try to save time. > AsI am pointing out here, we have three choices. > > 1) TLS only > 2) X.509 only > 3) HTTP only > Support for multiple application protocols is essential. There are more application protocols that may be used than there is code space for DNS > RRs. If we don't address this use case the whole scheme is worthless. I think its fair to say that most custom application that might want to get hooked into DANE are using a http protocol using x.509 with tls. (or IPsec or ssh) But DANE currently actually does not care if you use TLS or X.509 or http. It just cares about the cert/pubkey used for crypto and on which port it will be (with HASTLS) So I think it covers the vast majority of use cases, even for proprietary protocols. We might currently not be covering user identities, but I thought people in general thought this was not the protocol for user identities. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4593A6F3E for ; Mon, 17 Jan 2011 06:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpJ757Js-CJy for ; Mon, 17 Jan 2011 06:17:53 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1BF503A6F3C for ; Mon, 17 Jan 2011 06:17:53 -0800 (PST) Received: by gyd12 with SMTP id 12so2169518gyd.31 for ; Mon, 17 Jan 2011 06:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zMTtiC33szAHCiXH7qFUVZsJvk/34Z9jjh3bibtHaJQ=; b=YybLWjLQOV9V94wcowlLElkEYtcSKBywNYX1Azd8iKFZ2Qam9PH+KUpBapPZOg7ARS 2O05AzrzcMGxwS6A3/aUYQN2vHN2cnOseifZYCJ/0/k9lzuHYiwPc7r46Q+UwI4ZFmMm ufz4XA/s8oXzUO7nlaBnda2oOYNRG2nI7HyMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jd1uokv3ypAqCB2o+6Z7tFSUNknHGoS1JxsTGfqv2OVaPrFUH6I5yJg5AV95/NPvqS sVL6v1i4HT+QGyvE+xikQ788XzPyGehAEDGyOYGiKpF5oqH9sLQgKaPXUPuWiu1QY3z7 jtC0pPE/V5/hltKVPDqoirbNet/roKT/JPT80= MIME-Version: 1.0 Received: by 10.100.126.1 with SMTP id y1mr1225235anc.35.1295274027146; Mon, 17 Jan 2011 06:20:27 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 06:20:27 -0800 (PST) In-Reply-To: <4D3448C6.4040205@nic.cz> References: <4D334A39.9050109@gmail.com> <4D3448C6.4040205@nic.cz> Date: Mon, 17 Jan 2011 09:20:27 -0500 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016e645b848465c63049a0b7c24 Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:17:54 -0000 --0016e645b848465c63049a0b7c24 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Rule number one is do no harm. If this group proposes a spec that damages the security of other infrastructure it is going to be resisted. DNS name allocation has always been left to site policy. The target of an M= X record is required to be a canonical name. Thus it should be the unique nam= e of the host. If you want to propose unnecessary changes to DNS operations to make your specification proposal work then you are going to find getting IETF consensus very difficult. On Mon, Jan 17, 2011 at 8:48 AM, Ond=F8ej Sur=FD wrote= : > On 17.1.2011 13:52, Phillip Hallam-Baker wrote: > >> >> >> On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters > > wrote: >> >> On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: >> >> I would like it to be possible for services like SMTP to >> establish TLS keys with minimal infrastructure. That >> can't happen if there is a risk that the low assurance SMTP key >> will compromise the high assurance Web Server. >> >> >> I'm not sure how this problem would work. Can you explain it in a >> little more detail? >> >> Paul >> >> >> Let us say that the authors of Sendmail decide that they want to make it >> easy to turn on STARTTLS. >> >> So when the server is configured it looks to see if there is DNSSEC on >> the domain associated with its host name. If so it generates a public >> key pair, rolls itself a certificate and either tells the admin the DNS >> RR to insert in the zone or uses a TSIG type mechanism to register the >> key itself. >> >> >> For this to be acceptable two conditions need to be met: >> >> 1) The security must be adequate for the SMTP service >> >> 2) The mechanism must not reduce the security of any other service at >> the domain >> >> >> Since SMTP is generally engaged without cryptographic security, any >> improvement is better than none and the first condition is a really low >> bar. >> >> But the second can be very complex. Particularly since the authors of >> the mail server don't want to have any idea what the rest of the >> infrastructure might be at a site. >> >> The safest way to make this work automatically is to make it possible >> for the mail service to mark its keys for SMTP use only. >> > > I don't think we need to solve 2) from this babysitting perspective. > > What you are talking about is about having different certs for different > services and we are back at issue #1 in the tracker. > > If I take your example then most common case is that SMTP server is named > mail., f.e. mail.example.net. And I guess in most cases it > will not clash with another services under this name. And it should be > handled by the admins in the few corner cases where the name of the mail > server is same as name of some other important service. > > Ondrej > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ --0016e645b848465c63049a0b7c24 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Rule number one is do no harm.

If this group proposes a = spec that damages the security of other infrastructure it is going to be re= sisted.


DNS name allocation has alw= ays been left to site policy. The target of an MX record is required to be = a canonical name. Thus it should be the unique name of the host.

If you want to propose unnecessary changes to DNS opera= tions to make your specification proposal work then you are going to find g= etting IETF consensus very difficult.




On Mon, Jan 17, 2011 at = 8:48 AM, Ond=F8ej Sur=FD <ondrej.sury@nic.cz> wrote:
On 17.1.2011 13:52, Phillip Hallam-Baker wrote:


On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters <paul@xelerance.com
<mailto:paul@xel= erance.com>> wrote:

=A0 =A0On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:

=A0 =A0 =A0 =A0I would like it to be possible for services like SMTP to =A0 =A0 =A0 =A0establish TLS keys with minimal infrastructure. That
=A0 =A0 =A0 =A0can't happen if there is a risk that the low assurance = SMTP key
=A0 =A0 =A0 =A0will compromise the high assurance Web Server.


=A0 =A0I'm not sure how this problem would work. Can you explain it in= a
=A0 =A0little more detail?

=A0 =A0Paul


Let us say that the authors of Sendmail decide that they want to make it easy to turn on STARTTLS.

So when the server is configured it looks to see if there is DNSSEC on
the domain associated with its host name. If so it generates a public
key pair, rolls itself a certificate and either tells the admin the DNS
RR to insert in the zone or uses a TSIG type mechanism to register the
key itself.


For this to be acceptable two conditions need to be met:

1) The security must be adequate for the SMTP service

2) The mechanism must not reduce the security of any other service at
the domain


Since SMTP is generally engaged without cryptographic security, any
improvement is better than none and the first condition is a really low bar= .

But the second can be very complex. Particularly since the authors of
the mail server don't want to have any idea what the rest of the
infrastructure might be at a site.

The safest way to make this work automatically is to make it possible
for the mail service to mark its keys for SMTP use only.

I don't think we need to solve 2) from this babysitting perspective.
What you are talking about is about having different certs for different se= rvices and we are back at issue #1 in the tracker.

If I take your example then most common case is that SMTP server is named m= ail.<something>, f.e. mail.example.net. =A0And I guess in most cases it will not clash= with another services under this name. =A0And it should be handled by the = admins in the few corner cases where the name of the mail server is same as= name of some other important service.

Ondrej
--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e645b848465c63049a0b7c24-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D728C3A6F39 for ; Mon, 17 Jan 2011 06:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoY3mZ+IDmxi for ; Mon, 17 Jan 2011 06:15:06 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8D2AE3A6F3D for ; Mon, 17 Jan 2011 06:15:05 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id CC03EBF8B; Mon, 17 Jan 2011 09:17:37 -0500 (EST) Date: Mon, 17 Jan 2011 09:17:37 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:15:06 -0000 On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote: > Let us say that the authors of Sendmail decide that they want to make it easy to turn on STARTTLS. > So when the server is configured it looks to see if there is DNSSEC on the domain associated with its host name. If so it generates a public > key pair, rolls itself a certificate and either tells the admin the DNS RR to insert in the zone or uses a TSIG type mechanism to register the > key itself. > > For this to be acceptable two conditions need to be met: > > 1) The security must be adequate for the SMTP service > > 2) The mechanism must not reduce the security of any other service at the domain It also assumes a "higher secure level" is available for the other (say www) service, which already has a cert - issued by the sysadmin and/or signed by a CA -thus using PKIX. > Since SMTP is generally engaged without cryptographic security, any improvement is better than none and the first condition is a really low > bar. Sure. > But the second can be very complex. Particularly since the authors of the mail server don't want to have any idea what the rest of the > infrastructure might be at a site. > > The safest way to make this work automatically is to make it possible for the mail service to mark its keys for SMTP use only.  I'm still unsure how this affects the cert on the web port? If we have multiple TLSA certs in DNS under the same name, and one appears on the mail server and one on the http server, how did the security of the http server get reduced by sendmail adding its cert to its config and DNS? At most, I can think of some compromise/mistake where the mail cert would get used on the httpd server. Eg a hacker compromises the webserver, the webserver cert is stored on disk (not in hardware) and password protected (which AFAIK is quite rare on web servers these days) and will now use the mail server cert on the web server to do evil. All of which I think could be done without restarting the webserver and thus losing the web server certificate. Any sufficiently important web server cert will be in stored in hardware and will be run on a dedicated server that is not also running mail. So I find it hard to see a real life use case where abusing the multiple TLSA certificates would provide a real life issue. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D2C28C0F6 for ; Mon, 17 Jan 2011 06:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogYbgE1XwSVR for ; Mon, 17 Jan 2011 06:08:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 53D6628B797 for ; Mon, 17 Jan 2011 06:08:20 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id BA2B7734352 for ; Mon, 17 Jan 2011 15:10:53 +0100 (CET) Message-ID: <4D344DED.8090907@nic.cz> Date: Mon, 17 Jan 2011 15:10:53 +0100 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D3403D4.6090702@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:08:22 -0000 On 17.1.2011 14:02, Phillip Hallam-Baker wrote: > The only reason to narrow consideration to TLS would be to try to > save time. Eh, I got lost, at first you wrote: On 16.1.2011 14:50, Phillip Hallam-Baker wrote: > 1) Should the protocol only support TLS > 2) Should the protocol only support TLS+HTTP > 3) Should the protocol only support TLS+HTTP for Web browsing. and now you are writing: On 17.1.2011 14:02, Phillip Hallam-Baker wrote: > As I am pointing out here, we have three choices. > > 1) TLS only > 2) X.509 only > 3) HTTP only I guess you have changed that on the basis of Simon's mail. Alright. Anyway the issue #17 is about: TLS-only or more, ie. widen the scope Your options are to be more specific, ie. narrow the scope. Or am I missing something? Or is this a language barrier issue? If I am mistaken (on the narrow vs widen) could you please explain it in some other wording (preferably be as concrete as possible, so we don't get entangled into general statements), thanks. > Any decent PKI architecture is going to be independent of the > protocol that consumes the key. Choosing to only document TLS will > save a some time. But only designing for TLS will not. > > Choosing to support multiple key formats does greatly increase the > complexity of the specification but delivers zero value as the only > people who care about the use of the key format are a narrow > technical clique. Support for different key formats will not increase > the practical value of the spec in any way whatsoever. So could you please express your proposal on the issue #17 (ie. be constructive) instead of telling us what is not going to work (ie. being destructive)? > Support for multiple application protocols is essential. There are > more application protocols that may be used than there is code space > for DNS RRs. If we don't address this use case the whole scheme is > worthless. I don't remember that we ever talked about encoding application protocols into DNS RRTYPEs, but I may have missed something. So I don't really get what you are talking about. > So suggest that we stop talking about #17 at this point because it is > not the most relevant decision. I don't agree with you. The draft-ietf-dane-protocol talks about TLS at all place and the decision on whether TLS-only or more could have serious impact on the document. > It is a choice that people are wanting to take to fool themselves > that they are getting focused when they are doing no such thing. I suggest we leave "the people" out of technical discussion. > We should solve the hardest problem first. Which in your opinion is? O. -- Ondøej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoøe CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1DD828C0D7 for ; Mon, 17 Jan 2011 05:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7MZiT6vu226 for ; Mon, 17 Jan 2011 05:46:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 10B3C28C0D9 for ; Mon, 17 Jan 2011 05:46:21 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 8D081734334 for ; Mon, 17 Jan 2011 14:48:54 +0100 (CET) Message-ID: <4D3448C6.4040205@nic.cz> Date: Mon, 17 Jan 2011 14:48:54 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D334A39.9050109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:46:22 -0000 On 17.1.2011 13:52, Phillip Hallam-Baker wrote: > > > On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters > wrote: > > On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > > I would like it to be possible for services like SMTP to > establish TLS keys with minimal infrastructure. That > can't happen if there is a risk that the low assurance SMTP key > will compromise the high assurance Web Server. > > > I'm not sure how this problem would work. Can you explain it in a > little more detail? > > Paul > > > Let us say that the authors of Sendmail decide that they want to make it > easy to turn on STARTTLS. > > So when the server is configured it looks to see if there is DNSSEC on > the domain associated with its host name. If so it generates a public > key pair, rolls itself a certificate and either tells the admin the DNS > RR to insert in the zone or uses a TSIG type mechanism to register the > key itself. > > > For this to be acceptable two conditions need to be met: > > 1) The security must be adequate for the SMTP service > > 2) The mechanism must not reduce the security of any other service at > the domain > > > Since SMTP is generally engaged without cryptographic security, any > improvement is better than none and the first condition is a really low bar. > > But the second can be very complex. Particularly since the authors of > the mail server don't want to have any idea what the rest of the > infrastructure might be at a site. > > The safest way to make this work automatically is to make it possible > for the mail service to mark its keys for SMTP use only. I don't think we need to solve 2) from this babysitting perspective. What you are talking about is about having different certs for different services and we are back at issue #1 in the tracker. If I take your example then most common case is that SMTP server is named mail., f.e. mail.example.net. And I guess in most cases it will not clash with another services under this name. And it should be handled by the admins in the few corner cases where the name of the mail server is same as name of some other important service. Ondrej -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A493A6E48 for ; Mon, 17 Jan 2011 05:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Oaq2N4UlzRO for ; Mon, 17 Jan 2011 05:38:53 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 25C123A6CAA for ; Mon, 17 Jan 2011 05:38:53 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 11BAE4043D; Mon, 17 Jan 2011 13:41:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1295271686; bh=+hnOQdSaw10wJVH2h8D1QlvmiyxPI0SzzodJCk/Id7o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=QgPfBXhXscKCAiq5O6zRclXYaOVsFpxbBGWF2uUZ/3pgGsj1ciVqOF1IUDKsRv3Fm uUULwPn23TaduN+fHDir6RZ9FZI4R8Tf1rD+lNtbGlDWUKToiSVKawelL7zb76+E1f /BCp52R/CmV5I0ltNQQpPGm9+pNSasci0mW7Ornw= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id D5CD6360029; Mon, 17 Jan 2011 01:42:08 +0000 (UTC) From: James Cloos To: Phillip Hallam-Baker In-Reply-To: (Phillip Hallam-Baker's message of "Sun, 16 Jan 2011 17:40:51 -0500") References: <90409881-EE2F-471A-BA95-CCC66FF2B318@kirei.se> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 16 Jan 2011 20:42:08 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110117:hallam@gmail.com::P92RDuthLtaIJIRL:2Oxft X-Hashcash: 1:30:110117:jakob@kirei.se::nBqLcR6lQfaelS+Q:009i3fb X-Hashcash: 1:30:110117:keyassure@ietf.org::sZPweOr5IvxTpQCG:000000000000000000000000000000000000000000dTM4/ Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:38:55 -0000 >>>>> "PH" == Phillip Hallam-Baker writes: PH> I would separate out the documentation of the trust mechanism itself PH> from the specific binding to TLS / HTTP and Web browsing considerations. PH> I don't propose actually writing an IPSEC or SSH binding. But we should PH> be pretty confident we could write one if necessary. That makes very good sense. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4AB3A6F16 for ; Mon, 17 Jan 2011 05:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uflleIaoTgJQ for ; Mon, 17 Jan 2011 05:00:23 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B37E93A6D3D for ; Mon, 17 Jan 2011 05:00:23 -0800 (PST) Received: by gyd12 with SMTP id 12so2145275gyd.31 for ; Mon, 17 Jan 2011 05:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u5ywvHAV0+qY00btp791b1j2+pAf5m9pc2PHUrUf4Rk=; b=VQHzTCmt5qmRIUk4gOhizgZq12fIEPF1dkmHU90jEIXDhDgyk9J+Q6KxEeTnQjoHBU kpW+/oy3AqL4MahgAsQMwBLbFUl9MKUazSX2VB5CZxLoi7YGOCIk/fN2Tb0HprBEKaKF RhMFcuDxUT+x+sKzZ/daZx47zccah0509fT6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Evr2ygRGhTsEs3nXdeJzsITr8jNo98lyqgX3XYTz+rZ4fMI6nRZxNRV+nSecLhDiQP by59TfI1r0oqKMVBSWTUaRuClt+GTz5drBAINj478wPtWptAse/sl2G7DEZ0+SZdtXx2 rstIW1Htt16GC393ctqIfyapARBfAmDKPogmI= MIME-Version: 1.0 Received: by 10.100.242.4 with SMTP id p4mr2470164anh.205.1295269377639; Mon, 17 Jan 2011 05:02:57 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 05:02:57 -0800 (PST) In-Reply-To: <4D3403D4.6090702@nic.cz> References: <4D3403D4.6090702@nic.cz> Date: Mon, 17 Jan 2011 08:02:57 -0500 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001636af02722484ac049a0a6789 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:00:25 -0000 --001636af02722484ac049a0a6789 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable The only reason to narrow consideration to TLS would be to try to save time= . AsI am pointing out here, we have three choices. 1) TLS only 2) X.509 only 3) HTTP only Any decent PKI architecture is going to be independent of the protocol that consumes the key. Choosing to only document TLS will save a some time. But only designing for TLS will not. Choosing to support multiple key formats does greatly increase the complexity of the specification but delivers zero value as the only people who care about the use of the key format are a narrow technical clique. Support for different key formats will not increase the practical value of the spec in any way whatsoever. Support for multiple application protocols is essential. There are more application protocols that may be used than there is code space for DNS RRs= . If we don't address this use case the whole scheme is worthless. So suggest that we stop talking about #17 at this point because it is not the most relevant decision. It is a choice that people are wanting to take to fool themselves that they are getting focused when they are doing no suc= h thing. We should solve the hardest problem first. On Mon, Jan 17, 2011 at 3:54 AM, Ond=F8ej Sur=FD wrote= : > On 16.1.2011 05:00, Warren Kumari wrote: > >> >> On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote: >> >> Buoyed by actual progress on getting the first issue resolved, I'm >>> proposing that we jump right into... the 17th issue. >>> >>> Issue #17: Should draft-ietf-dane-protocol support TLS only or be >>> more ambitious? >>> (http://trac.tools.ietf.org/wg/dane/trac/ticket/17): >>> >>> Description: ------- Please note: This is not the "what all >>> protocols can / do we want to support" issue. That will be a >>> separate (and probably lively!) discussion. >>> >>> The current version of draft-ietf-dane-protocol is titled "Using >>> Secure DNS to Associate Certificates with Domain Names For TLS" >>> and first goal / milestone is "First WG draft of standards-track >>> protocol for using DNS to associate hosts with keys for TLS and >>> DTLS". >>> >>> What I would like us to discuss is: Should *this* document simply >>> specify how to support TLS and future protocols can be supported >>> by saying "TLSA, but interpret field Foo to contain Bar" (or >>> "Similar to TLSA, but this different RR, formatted like Baz"). Note >>> that some other protocols already have similar RRtypes; for example >>> SSH already has SSHFP. >>> >> >> >> >> This approach is my personal preference. Having a document that >> clearly explains how something works for one simple, concrete use >> case is (IMO) much easier to understand than a document that tried >> to be all things to all people and cover all cases. This approach >> should also allow us to make much faster progress, and will allow us >> to gain experience and will address the largest use case up front. >> > > > > +1 > > > On 16.1.2011 15:27, Simon Josefsson wrote: > >> As a reminder, TLS supports more than X.509. The current draft is >> hard wired for X.509 only. >> > > Can we untie the draft from X.509? > > > 1) Should the protocol only support TLS with X.509 >> 2) Should the protocol only support TLS with X.509 + HTTP >> 3) Should the protocol only support TLS with X.509 + HTTP for Web >> browsing. >> > > I certainly don't want to limit this to just HTTP. One of my initial > drives for this WG was to support and improve SMTP, where lot's of unsign= ed > certs happen to reside. > > > > > > Anyway I think the issue #17 is TLS-only or more. So we should focus on > that and make separate issue out of the TLS+ or TLS+HTTP. Let'= s > not widen our issues unless absolutely necessary. > > > > Ondrej > -- > Ond=F8ej Sur=FD > vedouc=ED v=FDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=F8e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ --001636af02722484ac049a0a6789 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable The only reason to narrow consideration to TLS would be to try to save time= .

AsI am pointing out here, we have three choices.
=

1) TLS only
2) X.509 only
3) HTTP o= nly

Any decent PKI architecture is going to be independent = of the protocol that consumes the key. Choosing to only document TLS will s= ave a some time. But only designing for TLS will not.=A0

Choosing to support multiple key formats does greatly increase the com= plexity of the specification but delivers zero value as the only people who= care about the use of the key format are a narrow technical clique. Suppor= t for different key formats will not increase the practical value of the sp= ec in any way whatsoever.

Support for multiple application protocols is essential= . There are more application protocols that may be used than there is code = space for DNS RRs. If we don't address this use case the whole scheme i= s worthless.


So suggest that we stop talking about #1= 7 at this point because it is not the most relevant decision. It is a choic= e that people are wanting to take to fool themselves that they are getting = focused when they are doing no such thing.=A0

We should solve the hardest problem first.=A0


On Mon, Jan 17, 2011 at 3:54 AM, Ond=F8= ej Sur=FD <ondre= j.sury@nic.cz> wrote:
On 16.1.2= 011 05:00, Warren Kumari wrote:

On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote:

Buoyed by actual progress on getting the first issue resolved, I'm
proposing that we jump right into... the 17th issue.

Issue #17: Should draft-ietf-dane-protocol support TLS only or be
more ambitious?
(http://trac.tools.ietf.org/wg/dane/trac/ticket/17):

Description: ------- Please note: This is not the "what all
protocols can / do we want to support" issue. That will be a
separate (and probably lively!) discussion.

The current version of draft-ietf-dane-protocol is titled "Using
Secure DNS to Associate Certificates with Domain Names For TLS"
and first goal / milestone is "First WG draft of standards-track
protocol for using DNS to associate hosts with keys for TLS and
DTLS".

What I would like us to discuss is: Should *this* document simply
specify how to support TLS and future protocols can be supported
by saying "TLSA, but interpret field Foo to contain Bar" (or
"Similar to TLSA, but this different RR, formatted like Baz"). No= te
that some other protocols already have similar RRtypes; for example
SSH already has SSHFP.

<no hats>

This approach is my personal preference. Having a document that
clearly explains how something works for one simple, concrete use
case is (IMO) much easier to understand than a document that tried
to be all things to all people and cover all cases. This approach
should also allow us to make much faster progress, and will allow us
to gain experience and will address the largest use case up front.

<no hat>

+1


On 16.1.2011 15:27, Simon Josefsson wrote:
As a reminder, TLS supports more than X.509. =A0The current draft is
hard wired for X.509 only.

Can we untie the draft from X.509?


1) Should the protocol only support TLS with X.509
2) Should the protocol only support TLS with X.509 + HTTP
3) Should the protocol only support TLS with X.509 + HTTP for Web
browsing.

I certainly don't want to limit this to just HTTP. =A0One of my initial= drives for this WG was to support and improve SMTP, where lot's of uns= igned certs happen to reside.

</no hat>

<chair hat>

Anyway I think the issue #17 is TLS-only or more. =A0So we should focus on = that and make separate issue out of the TLS+<any_proto> or TLS+HTTP. = Let's not widen our issues unless absolutely necessary.

</chair hat>

Ondrej
--
=A0Ond=F8ej Sur=FD
=A0vedouc=ED v=FDzkumu/Head of R&D department
=A0-------------------------------------------
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC
=A0Americka 23, 120 00 Praha 2, Czech Republic
=A0mailto:ondrej.su= ry@nic.cz =A0 =A0http://ni= c.cz/
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112
=A0-------------------------------------------

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--001636af02722484ac049a0a6789-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EA53A6EE9 for ; Mon, 17 Jan 2011 04:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbjdp9XwF3Z8 for ; Mon, 17 Jan 2011 04:49:49 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id EA3783A6E49 for ; Mon, 17 Jan 2011 04:49:48 -0800 (PST) Received: by yia28 with SMTP id 28so2641079yia.15 for ; Mon, 17 Jan 2011 04:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XVrXCb4PW07rT5wn4QbkZqaOyMVFDwyaOKDJv0LJaa4=; b=EaJUHQJFLSDdNTTNOIV0ejgGdQtwMX6bHv+Qq8vbkzF3b0AlthZDGgt+U4uR+Kodvy XeiEieAwNt/gOMsQslZVZ3Oqvw0d6MC2TM651ZWvn4cRUXIa8kl3OtOlU50KJLvMU3ol JMP1J1dXhJj5x7Ox/tDat6rgO89y7yZ43FpEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vHYqKm/GDM0LyTYpcBL1QGCNCzWRxkkVnUwzFc3yqGsIgqc6VNz60ELjW24aA9+n29 hZjeyeRdR3SavvrxkmTsalgFZkhuSrYiBO55K017eYnjrDD4nDPZQpJ4ZuqOJBgEJJva erM7CoYeUWw63M/QjYwUOFjqoZaBPbu6ajwRY= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr2483316anf.103.1295268742830; Mon, 17 Jan 2011 04:52:22 -0800 (PST) Received: by 10.100.31.8 with HTTP; Mon, 17 Jan 2011 04:52:22 -0800 (PST) In-Reply-To: References: <4D334A39.9050109@gmail.com> Date: Mon, 17 Jan 2011 07:52:22 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e64f8f4a4e1c74049a0a41fa Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 12:49:50 -0000 --0016e64f8f4a4e1c74049a0a41fa Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters wrote: > On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > >> I would like it to be possible for services like SMTP to establish TLS >> keys with minimal infrastructure. That >> can't happen if there is a risk that the low assurance SMTP key will >> compromise the high assurance Web Server. >> > > I'm not sure how this problem would work. Can you explain it in a little > more detail? > > Paul > Let us say that the authors of Sendmail decide that they want to make it easy to turn on STARTTLS. So when the server is configured it looks to see if there is DNSSEC on the domain associated with its host name. If so it generates a public key pair, rolls itself a certificate and either tells the admin the DNS RR to insert in the zone or uses a TSIG type mechanism to register the key itself. For this to be acceptable two conditions need to be met: 1) The security must be adequate for the SMTP service 2) The mechanism must not reduce the security of any other service at the domain Since SMTP is generally engaged without cryptographic security, any improvement is better than none and the first condition is a really low bar. But the second can be very complex. Particularly since the authors of the mail server don't want to have any idea what the rest of the infrastructure might be at a site. The safest way to make this work automatically is to make it possible for the mail service to mark its keys for SMTP use only. -- Website: http://hallambaker.com/ --0016e64f8f4a4e1c74049a0a41fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 16, 2011 at 9:54 PM, Paul Wo= uters <paul@xele= rance.com> wrote:
On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
I would like it to be possible for services like SMTP to establish TLS keys= with minimal infrastructure. That
can't happen if there is a risk that the low assurance SMTP key will co= mpromise the high assurance Web Server.

I'm not sure how this problem would work. Can you explain it in a littl= e more detail?

Paul

Let us say that the authors of Sendmail decid= e that they want to make it easy to turn on STARTTLS.

So= when the server is configured it looks to see if there is DNSSEC on the do= main associated with its host name. If so it generates a public key pair, r= olls itself a certificate and either tells the admin the DNS RR to insert i= n the zone or uses a TSIG type mechanism to register the key itself.


For this to be acceptable two conditions need= to be met:

1) The security must be adequate for t= he SMTP service

2) The mechanism must not reduce t= he security of any other service at the domain


Since SMTP is generally engaged without = cryptographic security, any improvement is better than none and the first c= ondition is a really low bar.

But the second can b= e very complex. Particularly since the authors of the mail server don't= want to have any idea what the rest of the infrastructure might be at a si= te.

The safest way to make this work automatically is to ma= ke it possible for the mail service to mark its keys for SMTP use only.=A0<= /div>


--0016e64f8f4a4e1c74049a0a41fa-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0743A6EC5 for ; Mon, 17 Jan 2011 00:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0n9BAlH1yGc for ; Mon, 17 Jan 2011 00:52:15 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 6714D3A6EC3 for ; Mon, 17 Jan 2011 00:52:13 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 626257342E8 for ; Mon, 17 Jan 2011 09:54:44 +0100 (CET) Message-ID: <4D3403D4.6090702@nic.cz> Date: Mon, 17 Jan 2011 09:54:44 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 08:52:16 -0000 On 16.1.2011 05:00, Warren Kumari wrote: > > On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote: > >> Buoyed by actual progress on getting the first issue resolved, I'm >> proposing that we jump right into... the 17th issue. >> >> Issue #17: Should draft-ietf-dane-protocol support TLS only or be >> more ambitious? >> (http://trac.tools.ietf.org/wg/dane/trac/ticket/17): >> >> Description: ------- Please note: This is not the "what all >> protocols can / do we want to support" issue. That will be a >> separate (and probably lively!) discussion. >> >> The current version of draft-ietf-dane-protocol is titled "Using >> Secure DNS to Associate Certificates with Domain Names For TLS" >> and first goal / milestone is "First WG draft of standards-track >> protocol for using DNS to associate hosts with keys for TLS and >> DTLS". >> >> What I would like us to discuss is: Should *this* document simply >> specify how to support TLS and future protocols can be supported >> by saying "TLSA, but interpret field Foo to contain Bar" (or >> "Similar to TLSA, but this different RR, formatted like Baz"). Note >> that some other protocols already have similar RRtypes; for example >> SSH already has SSHFP. > > > > This approach is my personal preference. Having a document that > clearly explains how something works for one simple, concrete use > case is (IMO) much easier to understand than a document that tried > to be all things to all people and cover all cases. This approach > should also allow us to make much faster progress, and will allow us > to gain experience and will address the largest use case up front. +1 On 16.1.2011 15:27, Simon Josefsson wrote: > As a reminder, TLS supports more than X.509. The current draft is > hard wired for X.509 only. Can we untie the draft from X.509? > 1) Should the protocol only support TLS with X.509 > 2) Should the protocol only support TLS with X.509 + HTTP > 3) Should the protocol only support TLS with X.509 + HTTP for Web > browsing. I certainly don't want to limit this to just HTTP. One of my initial drives for this WG was to support and improve SMTP, where lot's of unsigned certs happen to reside. Anyway I think the issue #17 is TLS-only or more. So we should focus on that and make separate issue out of the TLS+ or TLS+HTTP. Let's not widen our issues unless absolutely necessary. Ondrej -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052A73A6D63 for ; Sun, 16 Jan 2011 18:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S9Ed3WdgnYd for ; Sun, 16 Jan 2011 18:51:46 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C33BF3A67C0 for ; Sun, 16 Jan 2011 18:51:45 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id D4281BF8B; Sun, 16 Jan 2011 21:54:17 -0500 (EST) Date: Sun, 16 Jan 2011 21:54:17 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:51:47 -0000 On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > If the creator of a self signed certificate chose to put restrictions on its use then those should be > respected. You are probably right - especially if the creator has a future choice of bare public key TLS. > I would like it to be possible for services like SMTP to establish TLS keys with minimal infrastructure. That > can't happen if there is a risk that the low assurance SMTP key will compromise the high assurance Web Server. I'm not sure how this problem would work. Can you explain it in a little more detail? Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9304D28C0EB for ; Sun, 16 Jan 2011 18:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEdMT2FDh3q8 for ; Sun, 16 Jan 2011 18:30:08 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A0EB228C0E3 for ; Sun, 16 Jan 2011 18:30:07 -0800 (PST) Received: by ywk9 with SMTP id 9so1729203ywk.31 for ; Sun, 16 Jan 2011 18:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=515oxZn7mis2hw1yi8hdCXx5nSrh0vQtddOlNj9X7eA=; b=FK1dNXTQAUPOrp2FQMHMbFFdIHj+ZQ6PztMUueGXd00HSbTmFYyNYaMsyrJ+23V5J/ VIftJbC/BGeOiS5QnVj0duunq5Uu583SXMvfTxEULVwFKerxYIBLoHbnTJEdJNtstB2q 7HhvGewrOCfeTbu4YI4VgsT5cmV3ICCGGDSQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FG2dCDDmv2Lz0SZP6tVC+8gNoCF/gjqxLqy/5gL/Jc6YY8o5ICvfiRv3wjxETCAZyg uxGUlA9mlLylID9WmIbxYMnsToyX5sxYS+kRmTLGzHBt01GCYa6myKqIgAJVL9rOzciV 2wDnMje8Epoj517fZPriejhbMYkiPWSJif/yE= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr2171474anf.103.1295231558958; Sun, 16 Jan 2011 18:32:38 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 16 Jan 2011 18:32:38 -0800 (PST) In-Reply-To: References: <4D334A39.9050109@gmail.com> Date: Sun, 16 Jan 2011 21:32:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e64f8f4af93eab049a01989d Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:30:10 -0000 --0016e64f8f4af93eab049a01989d Content-Type: text/plain; charset=ISO-8859-1 If the creator of a self signed certificate chose to put restrictions on its use then those should be respected. I would like it to be possible for services like SMTP to establish TLS keys with minimal infrastructure. That can't happen if there is a risk that the low assurance SMTP key will compromise the high assurance Web Server. On Sun, Jan 16, 2011 at 9:08 PM, Paul Wouters wrote: > On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > > Mostly agree >> But restrictions on the validity and/or use of the certificate MUST still >> be observed. >> >> i.e. if a self-signed certificate says that the subject is Bank of Ethel >> then that is a positive statement and >> MUST be ignored. >> >> But if the certificate says 'not valid after X' or 'only for protocol Y' >> or has an unknown critical extension >> then it MUST be rejected. >> > > I am not sure if I agree (or disagree) > > If the pubkey is DNSSEC validated, shouldn't it be treated as valid? > especially in the > absence of a validation by a CA (eg a self signed cert) > > I forsee people adding existing non-CA, self signed certs in DNS and > forgetting their > validity period. And in some sense whether or not the validated pubkey is > in DNSSEC, > is the claim of validity. > > However I also expect browsers not to take these certificates too different > from their > existing policies with respect to displaying non-validated certificate > properties. So > this issue is somewhat moot, the admin should generate a proper certificate > and hopefully > later can use a bare public key TLS variant to avoid all of this. > > I guess I could live with either, which means its probably a local > user/vendor policy > decision? eg I could see a browser popup for this. > > The one thing I am feeling more strongly about, is the ignoring of the CN= > in self signed > certs and taking the DNS location of the TLSA record as the authority for > the certificate > being valid, even if the CN= does not match. Specifically because it eases > larger scale > ssl deployment, which I think is one of the goals of this draft. > > Paul > > > On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer >> wrote: >> Hi Paul, >> >> For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. >> But it's got to be >> normative. >> >> Having reread 3.1.3, I am literally shocked by the way we propose to >> deal with certs that (1) >> validate OK with respect to DNSSEC but (2) do not chain up to a known >> trust anchor. We propose to >> leave the decision to the user, just like the bad old days of PKI! >> >> Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following >> text: >> >> 3.1.3 Non-Validated Certificates >> >> Certificates that are correctly associated with a domain name, but >> which do not chain into a >> locally stored trust anchor, are no different from self-signed >> certificates. Therefore, only their >> public key can be used in conjunction with the associated domain >> name. Other pertinent data in the >> certificate, such as the Subject, Issuer and Subject Alternative Name >> fields, as well as EV >> indications, MUST be ignored. In particular, TLS clients MUST NOT >> present such data to the user. >> >> [Alternatively, if we suggest to give Type 3/4 associations the full >> CA treatment, where the >> complete cert chain becomes trusted, this may also be fine. But we >> should not leave this decision >> to the end user!] >> >> Thanks, >> Yaron >> >> Date: Sat, 15 Jan 2011 17:08:11 -0800 >> From: Paul Hoffman >> Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - >> cert >> validation >> To: keyassure@ietf.org >> Message-ID:<4D3244FB.9050305@vpnc.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 1/15/11 1:15 PM, Yaron Sheffer wrote: >> Sec. 3.1.2 of the draft singles out self-signed certs, >> where "host >> names" (in the section title) or "all data other than the >> key" (first >> paragraph) is ignored. >> >> I have two issues here: >> >> - The first paragraph should have a normative SHOULD, >> instead of "can". >> The data is indeed untrustworthy and clients SHOULD >> ignore it unless >> validated otherwise. >> >> >> This was argued about previously, I think. This should be a new >> open >> issue because it deals with adding a 2119-level restriction. >> Also, why >> "SHOULD" and not "MUST"? When is is OK to not ignore the data? >> (FWIW, I >> don't have strong feelings either way on any of this). >> >> - The exact same considerations apply to non-self signed >> certs. I don't >> see a reason to talk specifically about self-signed >> certs. >> >> >> We disagree here. The Issuer field in a CA certificate cannot >> be ignored >> when doing PKIX chaining. >> >> Just because >> someone presents a cert that has, say, Verisign as the >> Issuer, doesn't >> mean it is a valid Verisign certificate unless validated >> in the >> traditional manner. >> >> >> Um, exactly. But self-signed certs are not "validated in the >> traditional >> manner", which is why this section exists. >> >> So none of the certificate data can be trusted, >> including the important Subject and SubjectAltName >> fields. Sec. 3.1.4 >> kind of implies this fact, but the incorrect >> differentiation between >> regular and self-signed certs remains. >> >> >> I believe there is a strong differentiation between "was >> validated" and >> "wasn't validated". If you and I are saying the same thing, I >> would love >> to see text to clarify what we have written. >> >> --Paul Hoffman >> >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> >> -- Website: http://hallambaker.com/ --0016e64f8f4af93eab049a01989d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If the creator of a self signed certificate chose to put restrictions on it= s use then those should be respected.


I w= ould like it to be possible for services like SMTP to establish TLS keys wi= th minimal infrastructure. That can't happen if there is a risk that th= e low assurance SMTP key will compromise the high assurance Web Server.


On Sun, Jan 16, 2011 at = 9:08 PM, Paul Wouters <paul@xelerance.com> wrote:
On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:

Mostly agree
But restrictions on the validity and/or use of the certificate MUST still b= e observed.

i.e. if a self-signed certificate says that the subject is Bank of Ethel th= en that is a positive statement and
MUST be ignored.

But if the certificate says 'not valid after X' or 'only for pr= otocol Y' or has an unknown critical extension
then it MUST be rejected.

I am not sure if I agree (or disagree)

If the pubkey is DNSSEC validated, shouldn't it be treated as valid? es= pecially in the
absence of a validation by a CA (eg a self signed cert)

I forsee people adding existing non-CA, self signed certs in DNS and forget= ting their
validity period. And in some sense whether or not the validated pubkey is i= n DNSSEC,
is the claim of validity.

However I also expect browsers not to take these certificates too different= from their
existing policies with respect to displaying non-validated certificate prop= erties. So
this issue is somewhat moot, the admin should generate a proper certificate= and hopefully
later can use a bare public key TLS variant to avoid all of this.

I guess I could live with either, which means its probably a local user/ven= dor policy
decision? eg I could see a browser popup for this.

The one thing I am feeling more strongly about, is the ignoring of the CN= =3D in self signed
certs and taking the DNS location of the TLSA record as the authority for t= he certificate
being valid, even if the CN=3D does not match. Specifically because it ease= s larger scale
ssl deployment, which I think is one of the goals of this draft.

Paul


On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=A0 =A0 =A0Hi Paul,

=A0 =A0 =A0For the first sentence of 3.1.2, I don't care if it's S= HOULD or MUST. But it's got to be
=A0 =A0 =A0normative.

=A0 =A0 =A0Having reread 3.1.3, I am literally shocked by the way we propo= se to deal with certs that (1)
=A0 =A0 =A0validate OK with respect to DNSSEC but (2) do not chain up to a= known trust anchor. We propose to
=A0 =A0 =A0leave the decision to the user, just like the bad old days of P= KI!

=A0 =A0 =A0Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the fol= lowing text:

=A0 =A0 =A03.1.3 Non-Validated Certificates

=A0 =A0 =A0Certificates that are correctly associated with a domain name, = but which do not chain into a
=A0 =A0 =A0locally stored trust anchor, are no different from self-signed = certificates. Therefore, only their
=A0 =A0 =A0public key can be used in conjunction with the associated domai= n name. Other pertinent data in the
=A0 =A0 =A0certificate, such as the Subject, Issuer and Subject Alternativ= e Name fields, as well as EV
=A0 =A0 =A0indications, MUST be ignored. In particular, TLS clients MUST N= OT present such data to the user.

=A0 =A0 =A0[Alternatively, if we suggest to give Type 3/4 associations the= full CA treatment, where the
=A0 =A0 =A0complete cert chain becomes trusted, this may also be fine. But= we should not leave this decision
=A0 =A0 =A0to the end user!]

=A0 =A0 =A0Thanks,
=A0 =A0 =A0=A0 =A0 =A0 =A0Yaron

=A0 =A0 =A0 =A0 =A0 =A0Date: Sat, 15 Jan 2011 17:08:11 -0800
=A0 =A0 =A0 =A0 =A0 =A0From: Paul Hoffman<paul.hoffman@vpnc.org>
=A0 =A0 =A0 =A0 =A0 =A0Subject: Re: [keyassure] draft-ietf-dane-protocol-0= 2 posted - cert
=A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0validation
=A0 =A0 =A0 =A0 =A0 =A0To: keyassure@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0Message-ID:<4D3244FB.9050305@vpnc.org>
=A0 =A0 =A0 =A0 =A0 =A0Content-Type: text/plain; charset=3DISO-8859-1; for= mat=3Dflowed

=A0 =A0 =A0 =A0 =A0 =A0On 1/15/11 1:15 PM, Yaron Sheffer wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sec. 3.1.2 of the draft singles out sel= f-signed certs, where "host
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0names" (in the section title) or &= quot;all data other than the key" (first
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0paragraph) is ignored.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I have two issues here:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- The first paragraph should have a nor= mative SHOULD, instead of "can".
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The data is indeed untrustworthy and cl= ients SHOULD ignore it unless
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0validated otherwise.


=A0 =A0 =A0 =A0 =A0 =A0This was argued about previously, I think. This sho= uld be a new open
=A0 =A0 =A0 =A0 =A0 =A0issue because it deals with adding a 2119-level res= triction. Also, why
=A0 =A0 =A0 =A0 =A0 =A0"SHOULD" and not "MUST"? When i= s is OK to not ignore the data? (FWIW, I
=A0 =A0 =A0 =A0 =A0 =A0don't have strong feelings either way on any of= this).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- The exact same considerations apply t= o non-self signed certs. I don't
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0see a reason to talk specifically about= self-signed certs.


=A0 =A0 =A0 =A0 =A0 =A0We disagree here. The Issuer field in a CA certific= ate cannot be ignored
=A0 =A0 =A0 =A0 =A0 =A0when doing PKIX chaining.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Just because
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0someone presents a cert that has, say, = Verisign as the Issuer, doesn't
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mean it is a valid Verisign certificate= unless validated in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0traditional manner.


=A0 =A0 =A0 =A0 =A0 =A0Um, exactly. But self-signed certs are not "va= lidated in the traditional
=A0 =A0 =A0 =A0 =A0 =A0manner", which is why this section exists.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So none of the certificate data can be = trusted,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0including the important Subject and Sub= jectAltName fields. Sec. 3.1.4
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kind of implies this fact, but the inco= rrect differentiation between
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regular and self-signed certs remains.<= br>

=A0 =A0 =A0 =A0 =A0 =A0I believe there is a strong differentiation between= "was validated" and
=A0 =A0 =A0 =A0 =A0 =A0"wasn't validated". If you and I are = saying the same thing, I would love
=A0 =A0 =A0 =A0 =A0 =A0to see text to clarify what we have written.

=A0 =A0 =A0 =A0 =A0 =A0--Paul Hoffman

=A0 =A0 =A0_______________________________________________
=A0 =A0 =A0keyassure mailing list
=A0 =A0 =A0keyassu= re@ietf.org
=A0 =A0 =A0https://www.ietf.org/mailman/listinfo/keyassure




--
Website: http://halla= mbaker.com/






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

--0016e64f8f4af93eab049a01989d-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7548928C0E3 for ; Sun, 16 Jan 2011 18:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljEO7Br79sqS for ; Sun, 16 Jan 2011 18:06:00 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7FFD528C0E7 for ; Sun, 16 Jan 2011 18:05:59 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 56C57BF8B; Sun, 16 Jan 2011 21:08:30 -0500 (EST) Date: Sun, 16 Jan 2011 21:08:29 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4D334A39.9050109@gmail.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:06:01 -0000 On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote: > Mostly agree > But restrictions on the validity and/or use of the certificate MUST still be observed. > > i.e. if a self-signed certificate says that the subject is Bank of Ethel then that is a positive statement and > MUST be ignored. > > But if the certificate says 'not valid after X' or 'only for protocol Y' or has an unknown critical extension > then it MUST be rejected. I am not sure if I agree (or disagree) If the pubkey is DNSSEC validated, shouldn't it be treated as valid? especially in the absence of a validation by a CA (eg a self signed cert) I forsee people adding existing non-CA, self signed certs in DNS and forgetting their validity period. And in some sense whether or not the validated pubkey is in DNSSEC, is the claim of validity. However I also expect browsers not to take these certificates too different from their existing policies with respect to displaying non-validated certificate properties. So this issue is somewhat moot, the admin should generate a proper certificate and hopefully later can use a bare public key TLS variant to avoid all of this. I guess I could live with either, which means its probably a local user/vendor policy decision? eg I could see a browser popup for this. The one thing I am feeling more strongly about, is the ignoring of the CN= in self signed certs and taking the DNS location of the TLSA record as the authority for the certificate being valid, even if the CN= does not match. Specifically because it eases larger scale ssl deployment, which I think is one of the goals of this draft. Paul > On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer wrote: > Hi Paul, > > For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But it's got to be > normative. > > Having reread 3.1.3, I am literally shocked by the way we propose to deal with certs that (1) > validate OK with respect to DNSSEC but (2) do not chain up to a known trust anchor. We propose to > leave the decision to the user, just like the bad old days of PKI! > > Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text: > > 3.1.3 Non-Validated Certificates > > Certificates that are correctly associated with a domain name, but which do not chain into a > locally stored trust anchor, are no different from self-signed certificates. Therefore, only their > public key can be used in conjunction with the associated domain name. Other pertinent data in the > certificate, such as the Subject, Issuer and Subject Alternative Name fields, as well as EV > indications, MUST be ignored. In particular, TLS clients MUST NOT present such data to the user. > > [Alternatively, if we suggest to give Type 3/4 associations the full CA treatment, where the > complete cert chain becomes trusted, this may also be fine. But we should not leave this decision > to the end user!] > > Thanks, >        Yaron > > Date: Sat, 15 Jan 2011 17:08:11 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert >        validation > To: keyassure@ietf.org > Message-ID:<4D3244FB.9050305@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/15/11 1:15 PM, Yaron Sheffer wrote: > Sec. 3.1.2 of the draft singles out self-signed certs, where "host > names" (in the section title) or "all data other than the key" (first > paragraph) is ignored. > > I have two issues here: > > - The first paragraph should have a normative SHOULD, instead of "can". > The data is indeed untrustworthy and clients SHOULD ignore it unless > validated otherwise. > > > This was argued about previously, I think. This should be a new open > issue because it deals with adding a 2119-level restriction. Also, why > "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I > don't have strong feelings either way on any of this). > > - The exact same considerations apply to non-self signed certs. I don't > see a reason to talk specifically about self-signed certs. > > > We disagree here. The Issuer field in a CA certificate cannot be ignored > when doing PKIX chaining. > > Just because > someone presents a cert that has, say, Verisign as the Issuer, doesn't > mean it is a valid Verisign certificate unless validated in the > traditional manner. > > > Um, exactly. But self-signed certs are not "validated in the traditional > manner", which is why this section exists. > > So none of the certificate data can be trusted, > including the important Subject and SubjectAltName fields. Sec. 3.1.4 > kind of implies this fact, but the incorrect differentiation between > regular and self-signed certs remains. > > > I believe there is a strong differentiation between "was validated" and > "wasn't validated". If you and I are saying the same thing, I would love > to see text to clarify what we have written. > > --Paul Hoffman > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > > > -- > Website: http://hallambaker.com/ > > > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0CBF3A6E38 for ; Sun, 16 Jan 2011 14:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS44Nb4FbLVc for ; Sun, 16 Jan 2011 14:38:19 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 6E6EA3A6C16 for ; Sun, 16 Jan 2011 14:38:19 -0800 (PST) Received: by gxk28 with SMTP id 28so1963404gxk.31 for ; Sun, 16 Jan 2011 14:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mMm6YOW0O1TFE8c7QXhgZnSs3olZN2F/CKFED+JmLp8=; b=e6Ef/wzaRWJFvM6kzACLOm7qH721xRUSgqwzZJLtpbuAoT6ueGk2plQFeSohqbUp9O 0P+AxS9qYwuQQ+zFvTSFnC6wq6TOHr22kevLHUvT7GmtpRLYkO1x2vfdBlMye8sN2cy0 48OjU1nv+Ct+nf3KhryOG9XRO3tkCmilgdX8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v8hvalbF5h8CfkE4Wpvx1+0NKhmozzhSXSDr1LZuYOC0nA5LiTuHFkqBr8eDPVv8b9 309fAbP084xc4UJsqdZlxDIk7PjvjkPiDM6Ty+BKAniW7+KEBJK3ApnFb0+O2zWJVSvz FxrZkAICm/32Nw8AZcxomGjNDFsiGFUFTSHcI= MIME-Version: 1.0 Received: by 10.100.242.4 with SMTP id p4mr2080737anh.205.1295217651643; Sun, 16 Jan 2011 14:40:51 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 16 Jan 2011 14:40:51 -0800 (PST) In-Reply-To: <90409881-EE2F-471A-BA95-CCC66FF2B318@kirei.se> References: <90409881-EE2F-471A-BA95-CCC66FF2B318@kirei.se> Date: Sun, 16 Jan 2011 17:40:51 -0500 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001636af02720875b20499fe5c30 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 22:38:20 -0000 --001636af02720875b20499fe5c30 Content-Type: text/plain; charset=ISO-8859-1 Working at a general level creates standards that are of higher quality overall and less likely to have the corner cases swept under the rug. I would separate out the documentation of the trust mechanism itself from the specific binding to TLS / HTTP and Web browsing considerations. I don't propose actually writing an IPSEC or SSH binding. But we should be pretty confident we could write one if necessary. If the architecture is right the distinction between the two should be very clear. If there is excessive special pleading it is a sign that the architecture is wrong. Its like having the warnings flag on a compiler - it helps avoid mistakes. We have done this in SAML, Web Services and pretty much every other specification of this type that I am familiar with. On Sun, Jan 16, 2011 at 4:14 PM, Jakob Schlyter wrote: > On 16 jan 2011, at 05.00, Warren Kumari wrote: > > > Having a document that clearly explains how something works for one > simple, concrete use case is (IMO) much easier to understand than a document > that tried to be all things to all people and cover all cases. > > This approach should also allow us to make much faster progress, and will > allow us to gain experience and will address the largest use case up front. > > Speaking as author of RFC 4255 (SSHFP), I agree with the above and believe > that draft-ietf-dane-protocol should support TLS only. > > jakob > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636af02720875b20499fe5c30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Working at a general level creates standards that are of higher quality ove= rall and less likely to have the corner cases swept under the rug.

=
I would separate out the documentation of the trust mechanism it= self from the specific binding to TLS / HTTP and Web browsing consideration= s. I don't propose actually writing an IPSEC or SSH binding. But we sho= uld be pretty confident we could write one if necessary.



If the architecture is ri= ght the distinction between the two should be very clear. If there is exces= sive special pleading it is a sign that the architecture is wrong. Its like= having the warnings flag on a compiler - it helps avoid mistakes.

We have done this in SAML, Web Services and pretty much= every other specification of this type that I am familiar with.
=

On Sun, Jan 16, 2011 at 4:14 PM, Jakob S= chlyter <jakob@kirei= .se> wrote:
On 16 jan 2011, at 05.00,= Warren Kumari wrote:

> Having a document that clearly explains how something works for one si= mple, concrete use case is (IMO) much easier to understand than a document = that tried to be all things to all people and cover all cases.
> This approach should also allow us to make much faster progress, and w= ill allow us to gain experience and will address the largest use case up fr= ont.

Speaking as author of RFC 4255 (SSHFP), I agree with the above and be= lieve that draft-ietf-dane-protocol should support TLS only.

=A0 =A0 =A0 =A0jakob

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



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

--001636af02720875b20499fe5c30-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0B93A6E3A for ; Sun, 16 Jan 2011 13:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWFhnElI3Hyk for ; Sun, 16 Jan 2011 13:21:24 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id D68F33A6D82 for ; Sun, 16 Jan 2011 13:21:23 -0800 (PST) Received: by yia28 with SMTP id 28so2414495yia.15 for ; Sun, 16 Jan 2011 13:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tS9zD9lRfpTwqeBcxQlCyEAJuN68gRwgWHc8ti872l0=; b=CUECMPh89BswiProeaD9dxf3YHq54Ykwmnf7gsD4EjO8g/L+jcpbblM+/WCoziQ8Qy ZWvWeqbeO2dP0ehGHuikhQNwq+7/SJTCXeqd5OVhLLSWMfugs/sfHhBiHlXKU+MZQMVx pe/tfBrllzlC8EchL8QWl8n6nRfJMqBxPPm6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x+b5sm2xYOvG4Ku0Mor/ZIpCat3H/wDt6hySflwZdnZeEC4k/+k7n9GjUhtJyE9JWN XN488oqku6htx/RiLCOEkmODYn29OwqQycv7pbiff71hN2pae4CMSsx+ti9TEbHRU32C dtTzRoB8uAwh6GoTU2be74dSN8UTpT+f2RZEo= MIME-Version: 1.0 Received: by 10.100.153.17 with SMTP id a17mr2045380ane.239.1295213034870; Sun, 16 Jan 2011 13:23:54 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 16 Jan 2011 13:23:54 -0800 (PST) In-Reply-To: <4D334A39.9050109@gmail.com> References: <4D334A39.9050109@gmail.com> Date: Sun, 16 Jan 2011 16:23:54 -0500 Message-ID: From: Phillip Hallam-Baker To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016e644d5ccda18940499fd4875 Cc: keyassure@ietf.org Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 21:21:25 -0000 --0016e644d5ccda18940499fd4875 Content-Type: text/plain; charset=ISO-8859-1 Mostly agree But restrictions on the validity and/or use of the certificate MUST still be observed. i.e. if a self-signed certificate says that the subject is Bank of Ethel then that is a positive statement and MUST be ignored. But if the certificate says 'not valid after X' or 'only for protocol Y' or has an unknown critical extension then it MUST be rejected. On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer wrote: > Hi Paul, > > For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But > it's got to be normative. > > Having reread 3.1.3, I am literally shocked by the way we propose to deal > with certs that (1) validate OK with respect to DNSSEC but (2) do not chain > up to a known trust anchor. We propose to leave the decision to the user, > just like the bad old days of PKI! > > Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text: > > 3.1.3 Non-Validated Certificates > > Certificates that are correctly associated with a domain name, but which do > not chain into a locally stored trust anchor, are no different from > self-signed certificates. Therefore, only their public key can be used in > conjunction with the associated domain name. Other pertinent data in the > certificate, such as the Subject, Issuer and Subject Alternative Name > fields, as well as EV indications, MUST be ignored. In particular, TLS > clients MUST NOT present such data to the user. > > [Alternatively, if we suggest to give Type 3/4 associations the full CA > treatment, where the complete cert chain becomes trusted, this may also be > fine. But we should not leave this decision to the end user!] > > Thanks, > Yaron > > Date: Sat, 15 Jan 2011 17:08:11 -0800 >> From: Paul Hoffman >> Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert >> validation >> To: keyassure@ietf.org >> Message-ID:<4D3244FB.9050305@vpnc.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 1/15/11 1:15 PM, Yaron Sheffer wrote: >> >>> Sec. 3.1.2 of the draft singles out self-signed certs, where "host >>> names" (in the section title) or "all data other than the key" (first >>> paragraph) is ignored. >>> >>> I have two issues here: >>> >>> - The first paragraph should have a normative SHOULD, instead of "can". >>> The data is indeed untrustworthy and clients SHOULD ignore it unless >>> validated otherwise. >>> >> >> This was argued about previously, I think. This should be a new open >> issue because it deals with adding a 2119-level restriction. Also, why >> "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I >> don't have strong feelings either way on any of this). >> >> - The exact same considerations apply to non-self signed certs. I don't >>> see a reason to talk specifically about self-signed certs. >>> >> >> We disagree here. The Issuer field in a CA certificate cannot be ignored >> when doing PKIX chaining. >> >> Just because >>> someone presents a cert that has, say, Verisign as the Issuer, doesn't >>> mean it is a valid Verisign certificate unless validated in the >>> traditional manner. >>> >> >> Um, exactly. But self-signed certs are not "validated in the traditional >> manner", which is why this section exists. >> >> So none of the certificate data can be trusted, >>> including the important Subject and SubjectAltName fields. Sec. 3.1.4 >>> kind of implies this fact, but the incorrect differentiation between >>> regular and self-signed certs remains. >>> >> >> I believe there is a strong differentiation between "was validated" and >> "wasn't validated". If you and I are saying the same thing, I would love >> to see text to clarify what we have written. >> >> --Paul Hoffman >> >> _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e644d5ccda18940499fd4875 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mostly agree

But restrictions on the validity and/or use= of the certificate MUST still be observed.

i.e. i= f a self-signed certificate says that the subject is Bank of Ethel then tha= t is a positive statement and MUST be ignored.

But if the certificate says 'not valid after X'= or 'only for protocol Y' or has an unknown critical extension then= it MUST be rejected.



On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wro= te:
Hi Paul,

For the first sentence of 3.1.2, I don't care if it's SHOULD or MUS= T. But it's got to be normative.

Having reread 3.1.3, I am literally shocked by the way we propose to deal w= ith certs that (1) validate OK with respect to DNSSEC but (2) do not chain = up to a known trust anchor. We propose to leave the decision to the user, j= ust like the bad old days of PKI!

Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text:=

3.1.3 Non-Validated Certificates

Certificates that are correctly associated with a domain name, but which do= not chain into a locally stored trust anchor, are no different from self-s= igned certificates. Therefore, only their public key can be used in conjunc= tion with the associated domain name. Other pertinent data in the certifica= te, such as the Subject, Issuer and Subject Alternative Name fields, as wel= l as EV indications, MUST be ignored. In particular, TLS clients MUST NOT p= resent such data to the user.

[Alternatively, if we suggest to give Type 3/4 associations the full CA tre= atment, where the complete cert chain becomes trusted, this may also be fin= e. But we should not leave this decision to the end user!]

Thanks,
=A0 =A0 =A0 =A0Yaron

Date: Sat, 15 Jan 2011 17:08:11 -0800
From: Paul Hoffman<paul.hoffman@vpnc.org>
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert
=A0 =A0 =A0 =A0validation
To: keyassure@ietf.= org
Message-ID:<4D3244FB.9050305@vpnc.org>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed

On 1/15/11 1:15 PM, Yaron Sheffer wrote:
Sec. 3.1.2 of the draft singles out self-signed certs, where "host
names" (in the section title) or "all data other than the key&quo= t; (first
paragraph) is ignored.

I have two issues here:

- The first paragraph should have a normative SHOULD, instead of "can&= quot;.
The data is indeed untrustworthy and clients SHOULD ignore it unless
validated otherwise.

This was argued about previously, I think. This should be a new open
issue because it deals with adding a 2119-level restriction. Also, why
"SHOULD" and not "MUST"? When is is OK to not ignore th= e data? (FWIW, I
don't have strong feelings either way on any of this).

- The exact same considerations apply to non-self signed certs. I don't=
see a reason to talk specifically about self-signed certs.

We disagree here. The Issuer field in a CA certificate cannot be ignored when doing PKIX chaining.

Just because
someone presents a cert that has, say, Verisign as the Issuer, doesn't<= br> mean it is a valid Verisign certificate unless validated in the
traditional manner.

Um, exactly. But self-signed certs are not "validated in the tradition= al
manner", which is why this section exists.

So none of the certificate data can be trusted,
including the important Subject and SubjectAltName fields. Sec. 3.1.4
kind of implies this fact, but the incorrect differentiation between
regular and self-signed certs remains.

I believe there is a strong differentiation between "was validated&quo= t; and
"wasn't validated". If you and I are saying the same thing, I= would love
to see text to clarify what we have written.

--Paul Hoffman

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e644d5ccda18940499fd4875-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A063A6E5E for ; Sun, 16 Jan 2011 13:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzEU-4sv8QtT for ; Sun, 16 Jan 2011 13:12:22 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 628AF3A6E5B for ; Sun, 16 Jan 2011 13:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=FpmRDs80DyRoifXyW1NjBFkEZ6i3hPBvO1Uzxkli/QA=; b=og/j55XurUSHgi3LdLdWpa6Vge0Nzaf07Uobmunukx+mNUOJtWa2K3VzpTU0p+Miep745qGIsvtG8 pA/VN0YHtHB6uf6PoY71BjRX3gNDVaIYdsqNnJ8bwJao4RSlT/HJyJ0ow4h/fX0Di7n+PXuxnMXY3R Bofl1A+iEmqZ/97E= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 16 Jan 2011 22:14:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Sun, 16 Jan 2011 22:14:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90409881-EE2F-471A-BA95-CCC66FF2B318@kirei.se> References: To: Warren Kumari X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 21:12:23 -0000 On 16 jan 2011, at 05.00, Warren Kumari wrote: > Having a document that clearly explains how something works for one = simple, concrete use case is (IMO) much easier to understand than a = document that tried to be all things to all people and cover all cases.=20= > This approach should also allow us to make much faster progress, and = will allow us to gain experience and will address the largest use case = up front. Speaking as author of RFC 4255 (SSHFP), I agree with the above and = believe that draft-ietf-dane-protocol should support TLS only. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04323A6E11 for ; Sun, 16 Jan 2011 11:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El0cQC794-F8 for ; Sun, 16 Jan 2011 11:40:35 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BE9D33A6E15 for ; Sun, 16 Jan 2011 11:40:34 -0800 (PST) Received: by wwa36 with SMTP id 36so4408711wwa.13 for ; Sun, 16 Jan 2011 11:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+vfS2OzqjTi4PKOhzCY3+6ym3ZIvg5NehQL+d6qLEHc=; b=p7E99zOjZql6XBx5IZxSsriKxbW3Qts+P6wv2go6ARngZuZLR+ATu2W61aXrgUZjyy e8UwvuZP5vhhuoY9XkvcogzZHjOU3+dhBgdzZgsvc4VJd0couEbZEkSBh7V30QXbsSSW xsJf5MRC1/jzdw0Ycih5KrFleN1W0fYpPuyFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=RCdEBd1yJP8nb9a11HO6b30yHjVLiTypoO7G5GLui5GamopoVdPNjY4IrGvqaGva8x 04eXRSZiY+fMVge0dMDCX7095fIcv8s8zoDDeNXU2bMwpjQtPWaE+h8kOo5wqDM4855r RaC0s+iTW2g140GgrksuG7rhI2PfDbxwpnkWk= Received: by 10.227.93.94 with SMTP id u30mr3128141wbm.153.1295206975171; Sun, 16 Jan 2011 11:42:55 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id 11sm2736373wbj.19.2011.01.16.11.42.52 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 11:42:54 -0800 (PST) Message-ID: <4D334A39.9050109@gmail.com> Date: Sun, 16 Jan 2011 21:42:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16 X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 19:40:36 -0000 Hi Paul, For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But it's got to be normative. Having reread 3.1.3, I am literally shocked by the way we propose to deal with certs that (1) validate OK with respect to DNSSEC but (2) do not chain up to a known trust anchor. We propose to leave the decision to the user, just like the bad old days of PKI! Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text: 3.1.3 Non-Validated Certificates Certificates that are correctly associated with a domain name, but which do not chain into a locally stored trust anchor, are no different from self-signed certificates. Therefore, only their public key can be used in conjunction with the associated domain name. Other pertinent data in the certificate, such as the Subject, Issuer and Subject Alternative Name fields, as well as EV indications, MUST be ignored. In particular, TLS clients MUST NOT present such data to the user. [Alternatively, if we suggest to give Type 3/4 associations the full CA treatment, where the complete cert chain becomes trusted, this may also be fine. But we should not leave this decision to the end user!] Thanks, Yaron > Date: Sat, 15 Jan 2011 17:08:11 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert > validation > To: keyassure@ietf.org > Message-ID:<4D3244FB.9050305@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/15/11 1:15 PM, Yaron Sheffer wrote: >> Sec. 3.1.2 of the draft singles out self-signed certs, where "host >> names" (in the section title) or "all data other than the key" (first >> paragraph) is ignored. >> >> I have two issues here: >> >> - The first paragraph should have a normative SHOULD, instead of "can". >> The data is indeed untrustworthy and clients SHOULD ignore it unless >> validated otherwise. > > This was argued about previously, I think. This should be a new open > issue because it deals with adding a 2119-level restriction. Also, why > "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I > don't have strong feelings either way on any of this). > >> - The exact same considerations apply to non-self signed certs. I don't >> see a reason to talk specifically about self-signed certs. > > We disagree here. The Issuer field in a CA certificate cannot be ignored > when doing PKIX chaining. > >> Just because >> someone presents a cert that has, say, Verisign as the Issuer, doesn't >> mean it is a valid Verisign certificate unless validated in the >> traditional manner. > > Um, exactly. But self-signed certs are not "validated in the traditional > manner", which is why this section exists. > >> So none of the certificate data can be trusted, >> including the important Subject and SubjectAltName fields. Sec. 3.1.4 >> kind of implies this fact, but the incorrect differentiation between >> regular and self-signed certs remains. > > I believe there is a strong differentiation between "was validated" and > "wasn't validated". If you and I are saying the same thing, I would love > to see text to clarify what we have written. > > --Paul Hoffman > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002733A6E5D for ; Sun, 16 Jan 2011 11:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgwKLIVwOIkm for ; Sun, 16 Jan 2011 11:01:08 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2AF103A6E04 for ; Sun, 16 Jan 2011 11:01:08 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id EADB7C4D3; Sun, 16 Jan 2011 14:03:38 -0500 (EST) Date: Sun, 16 Jan 2011 14:03:38 -0500 (EST) From: Paul Wouters To: Simon Josefsson In-Reply-To: <874o98sz46.fsf@latte.josefsson.org> Message-ID: References: <874o98sz46.fsf@latte.josefsson.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Phillip Hallam-Baker Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 19:01:09 -0000 On Sun, 16 Jan 2011, Simon Josefsson wrote: > Our WG charter does not say "X.509" so I think a proposal for TLS that > encompass other certificate formats would be useful. I'm considering > updating my early proposal that has this support: And non-certificat formats, such as bare public key where the pubkey is obtained via DNSSEC. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAD73A6E5E for ; Sun, 16 Jan 2011 10:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Id4ZR+9WDias for ; Sun, 16 Jan 2011 10:59:31 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 663B93A6E5F for ; Sun, 16 Jan 2011 10:59:31 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 7842640276; Sun, 16 Jan 2011 19:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1295204522; bh=Rbn9GhMmJBivzOgPZhCPpgI3nlwGJAGdmhQ2/Edxn7Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=YcHB6bg/wEKMjNCpN4siM4SCVIYidQvV7P2Nfas8WN2w7fJWF6pkH7o4DJwE2NtSJ ayjbYqPcIqGaUU2L7M2FL09/pAE3tTCY5nzsmazNIteBU85b0AaLS+2CU65VTnI4Km j4VYlw9scv52DlHEVmYWOdNaxZW8bI9xv+dY2c4g= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 48974360029; Sun, 16 Jan 2011 17:42:35 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: (Paul Wouters's message of "Sun, 16 Jan 2011 01:40:45 -0500 (EST)") References: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 16 Jan 2011 12:42:34 -0500 Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110116:keyassure@ietf.org::31gYA0TAzqmdhEuF:000000000000000000000000000000000000000000/iDw4 X-Hashcash: 1:30:110116:paul@xelerance.com::9v/LB8r8V18YKk9p:000000000000000000000000000000000000000000E0hv1 X-Hashcash: 1:30:110116:warren@kumari.net::gZj4emS8UOg+gBFq:0000000000000000000000000000000000000000000nrWTo Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 18:59:32 -0000 >>>>> "PW" == Paul Wouters writes: PW> but [PGP is] user based and not host based identities, No, OpenPGP is nym based. That can by anything, user, host, whatever. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCF73A6E59 for ; Sun, 16 Jan 2011 10:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy3TyXxz-e4Z for ; Sun, 16 Jan 2011 10:51:30 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 4FABA3A6E04 for ; Sun, 16 Jan 2011 10:51:30 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 5DBDF4043A; Sun, 16 Jan 2011 18:53:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1295204039; bh=KVmG6I+H8NEmwuUcLWv6D8EwKW7iNRhbLWCOmStnG9A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=OQChcGrGLc8DUq6Jj/QuotvkyNEMq/cH7jpsGeVjfHXvSQeIvA4eSzGwJQtlvJ3xg NeDPz/bc4adfp+drF8sZlCOLOH2tjQ3C4H3KshIbIe5r+QXq2IYiYjdOamSvcGSnIu qW6NlhDcNaWz9ujnzV9MepjVHL5agvm8g81pgdUQ= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 0E17D360029; Sun, 16 Jan 2011 17:47:06 +0000 (UTC) From: James Cloos To: keyassure@ietf.org In-Reply-To: (Warren Kumari's message of "Sat, 15 Jan 2011 22:15:46 -0500") References: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 16 Jan 2011 12:47:05 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110116:keyassure@ietf.org::rOv5n+ezV7+dGTMy:000000000000000000000000000000000000000000yYc0T X-Hashcash: 1:30:110116:warren@kumari.net::1IYEiGbISnBq6oOD:0000000000000000000000000000000000000000000YCPE3 Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 18:51:31 -0000 >>>>> "WK" == Warren Kumari writes: WK> The other alternative would be to make *this* document be much more WK> generic and able to support arbitrary key bindings. It should be more generic. There is no value in wasting time on a draft which only supports one particular use case when we could produce a way to use DNSSEC to anchor trust paths for essentially all trustable IP traffic. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9063A6BC1 for ; Sun, 16 Jan 2011 07:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.966 X-Spam-Level: X-Spam-Status: No, score=-100.966 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98F5UTJvvHBz for ; Sun, 16 Jan 2011 07:57:50 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 135473A6BA3 for ; Sun, 16 Jan 2011 07:57:50 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0GG0KK7070593 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 16 Jan 2011 09:00:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D331614.2030204@vpnc.org> Date: Sun, 16 Jan 2011 08:00:20 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D32CDAA.10107@gmail.com> In-Reply-To: <4D32CDAA.10107@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:57:50 -0000 On 1/16/11 2:51 AM, Yaron Sheffer wrote: > Hi Paul, > > No, I am not taking any sides regarding support for protocols that are > not mentioned in the charter (which is Issue #5). Note that IPsec itself > is, in fact, already in the charter. > > Neither am I proposing to expand the scope of the current document > (which is Issue #17). I actually prefer the current focus. > > I am just proposing the make the record's *name* protocol-agnostic, so > it can be reused in the future without excuses. Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer to keep the name as tied to what we know it will be used for and let other people do deltas if they want. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BACA43A6BA3 for ; Sun, 16 Jan 2011 07:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.709 X-Spam-Level: X-Spam-Status: No, score=-101.709 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p342tc1p2M6J for ; Sun, 16 Jan 2011 07:56:43 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id ED6D23A6B94 for ; Sun, 16 Jan 2011 07:56:42 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0GFxDik070537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 16 Jan 2011 08:59:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3315D1.8000000@vpnc.org> Date: Sun, 16 Jan 2011 07:59:13 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 15:56:43 -0000 On 1/15/11 10:40 PM, Paul Wouters wrote: > On Sat, 15 Jan 2011, Warren Kumari wrote: > >>> The other alternative would be to make *this* document be much more >>> generic and able to support arbitrary key bindings. >> >> I am concerned that, no matter how well the document is written, >> trying to make it sufficiently generic will end up hard to understand, >> vague and difficult to implement from. Even getting the terminology >> sufficiently precise for clear discussions while still being generic >> is tricky.... > > I think so too. > > SSH and IPsec already have their own RRTYPE. Right. Unless developers from those communities come to us and say "we want to abandon our existing RRtype and use yours, please expand yours", I don't think that this WG should try to shoe-horn them into our base protocol. > TLS is the big one missing > here. Other ones I can > think of are PGP or S/MIME related, but those are user based and not > host based identities, > which are probably better handled seperately. Actually, S/MIME *does* have a host-based identity solution, as shown in draft-turner-dnssec-centric-pki-00.txt. However, that one is far enough away from the model of "this cert/CA is for this transaction" that we are using that I would say that those folks could do their own. It can be done as a new RRtype that looks a lot like ours, or they could choose to repurpose ours with different semantics. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D303A6D3F for ; Sun, 16 Jan 2011 06:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwLucaySA1nd for ; Sun, 16 Jan 2011 06:58:59 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 70D373A6BD7 for ; Sun, 16 Jan 2011 06:58:58 -0800 (PST) Received: by gxk28 with SMTP id 28so1879050gxk.31 for ; Sun, 16 Jan 2011 07:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5mvN9DIZvawy4SBjT7Cihc+C2TzTin/a0BKvZajiStc=; b=ZaVR3KyTk1XNuLLvZRpOr8x9DGaw0yuXzaT+8b5Wywp0kt3phY+0RwhjrZWqAIWBxj uxI3wp6eq+t4GrSh0u6w01TowgokDVP5JUdN1pbqyoD4G51VodwBC6TfDF/0tqkxouZW t1hMrnDvE8XHUPLGR7bDkKygouvkUj7tjhTmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A9fjWOpSEXYzYkHkrEYwZUb31bjRarGUKkcAR59W3iemcX1NHhr3EczBXQsbavEpQl Ec6btxOqrfRCrKMmRhIHgxIpTPYR6gnKv9+KNXGIeTpknmJUXlYED7ZQmLAdM2RZMt0z PRg/EpaQBll86Kv2XeLx1kqfakd8CDRZjKYAY= MIME-Version: 1.0 Received: by 10.100.255.4 with SMTP id c4mr1642437ani.69.1295190088700; Sun, 16 Jan 2011 07:01:28 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 16 Jan 2011 07:01:28 -0800 (PST) In-Reply-To: <874o98sz46.fsf@latte.josefsson.org> References: <874o98sz46.fsf@latte.josefsson.org> Date: Sun, 16 Jan 2011 10:01:28 -0500 Message-ID: From: Phillip Hallam-Baker To: Simon Josefsson Content-Type: multipart/alternative; boundary=0016368e1bf02752f10499f7f1ce Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 14:59:01 -0000 --0016368e1bf02752f10499f7f1ce Content-Type: text/plain; charset=ISO-8859-1 People have written drafts which purport to show use of different keying modes. That is not the same thing at all. At the end of the day the cert format is just a packaging issue and the only things that really matter are that it is acceptably secure and everyone does the same thing. We seem to have a very peculiar set of priorities here. Support for SPKI keying which nobody uses and support for PGP key signature formats which are not designed for directory based PKI are discussed as if they were important and useful options. Meanwhile support for widely used protocols is treated as if it was a somewhat eccentric idea. I think some people have their priorities wrong here. There are only two key formats that are widely used: X.509 and PGP. The PGP format is expressly designed to support Web of trust and so is irrelevant here because what we are doing is the exact opposite of what Phil Zimmerman proposed. On Sun, Jan 16, 2011 at 9:27 AM, Simon Josefsson wrote: > Phillip Hallam-Baker writes: > > > There are actually three issues here > > > > 1) Should the protocol only support TLS > > 2) Should the protocol only support TLS+HTTP > > 3) Should the protocol only support TLS+HTTP for Web browsing. > > As a reminder, TLS supports more than X.509. The current draft is hard > wired for X.509 only. So it is more like: > > 1) Should the protocol only support TLS with X.509 > 2) Should the protocol only support TLS with X.509 + HTTP > 3) Should the protocol only support TLS with X.509 + HTTP for Web browsing. > > Our WG charter does not say "X.509" so I think a proposal for TLS that > encompass other certificate formats would be useful. I'm considering > updating my early proposal that has this support: > > http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00 > > /Simon > -- Website: http://hallambaker.com/ --0016368e1bf02752f10499f7f1ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable People have written drafts which purport to show use of different keying mo= des. That is not the same thing at all.

At the end of th= e day the cert format is just a packaging issue and the only things that re= ally matter are that it is acceptably secure and everyone does the same thi= ng.


We seem to have a very peculiar set of p= riorities here. Support for SPKI keying which nobody uses and support for P= GP key signature formats which are not designed for directory based PKI are= discussed as if they were important and useful options.

Meanwhile support for widely used protocols is treated = as if it was a somewhat eccentric idea.


=
I think some people have their priorities wrong here.


There are only two key formats that are widely us= ed: X.509 and PGP. The PGP format is expressly designed to support Web of t= rust and so is irrelevant here because what we are doing is the exact oppos= ite of what Phil Zimmerman proposed.


On Sun, Jan 16, 201= 1 at 9:27 AM, Simon Josefsson <simon@josefsson.org> wrote:
Phillip Hallam-Baker <hallam@gmail.com> writes:

> There are actually three issues here
>
> 1) Should the protocol only support TLS
> 2) Should the protocol only support TLS+HTTP
> 3) Should the protocol only support TLS+HTTP for Web browsing.

As a reminder, TLS supports more than X.509. =A0The current draft is = hard
wired for X.509 only. =A0So it is more like:

1) Should the protocol only support TLS with X.509
2) Should the protocol only support TLS with X.509 + HTTP
3) Should the protocol only support TLS with X.509 + HTTP for Web browsing.=

Our WG charter does not say "X.509" so I think a proposal for TLS= that
encompass other certificate formats would be useful. =A0I'm considering=
updating my early proposal that has this support:

http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00<= /a>

/Simon



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

--0016368e1bf02752f10499f7f1ce-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AA73A6C5D for ; Sun, 16 Jan 2011 06:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMyQ5gs2oDfU for ; Sun, 16 Jan 2011 06:24:47 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id BB2E93A6BD7 for ; Sun, 16 Jan 2011 06:24:46 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0GER52L006123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 16 Jan 2011 15:27:07 +0100 From: Simon Josefsson To: Phillip Hallam-Baker References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110116:hallam@gmail.com::QeNtTT59rvtevRit:2WwV X-Hashcash: 1:22:110116:keyassure@ietf.org::8nnaDcJ835E3IsXl:6LL5 X-Hashcash: 1:22:110116:warren@kumari.net::8RURmnNUDj8Aeqfy:C2lB Date: Sun, 16 Jan 2011 15:27:05 +0100 In-Reply-To: (Phillip Hallam-Baker's message of "Sun, 16 Jan 2011 08:50:10 -0500") Message-ID: <874o98sz46.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 14:24:48 -0000 Phillip Hallam-Baker writes: > There are actually three issues here > > 1) Should the protocol only support TLS > 2) Should the protocol only support TLS+HTTP > 3) Should the protocol only support TLS+HTTP for Web browsing. As a reminder, TLS supports more than X.509. The current draft is hard wired for X.509 only. So it is more like: 1) Should the protocol only support TLS with X.509 2) Should the protocol only support TLS with X.509 + HTTP 3) Should the protocol only support TLS with X.509 + HTTP for Web browsing. Our WG charter does not say "X.509" so I think a proposal for TLS that encompass other certificate formats would be useful. I'm considering updating my early proposal that has this support: http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00 /Simon Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37223A6C5D for ; Sun, 16 Jan 2011 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLBr5r3jvLr1 for ; Sun, 16 Jan 2011 05:47:39 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id BB2353A6BD7 for ; Sun, 16 Jan 2011 05:47:39 -0800 (PST) Received: by ywk9 with SMTP id 9so1587145ywk.31 for ; Sun, 16 Jan 2011 05:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FcKWfs+eRlD9z7POi+PZN8+1JFnzZAaKOseaf1yXEyY=; b=XnY/MknVzTLIXAE4KSWL35J4t/FNqsxygIacYjp2l8E9nbIk2XwJWPvCwVPxjFpJYf 7NOiTp5ZSFmMUiS32dsYUoWnKAYm9VmHrmdpkT2ky1g5IN8eEv1kNd0+srXAAqwp4CpV pV/5ktqIrRnlKvw/Q+0rQJzns+ZMSOaEimRq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dx1cTF3l6GI/1uRJNgTh7tj9OCxr3M4Ak8SdNbjuvSkcL7mVsx/4Oh3f0cnWEyNgiC vxcInNCUxcaDP/x3OqQEedvkShn3YAKhfKwmxI/NGRDUddreGpLB6ZkhBoR3xkEcoulO LwgDhVqOmXiUJhiHhiqa0TCu9WLHG8yEQJWm0= MIME-Version: 1.0 Received: by 10.100.153.17 with SMTP id a17mr1846016ane.239.1295185810794; Sun, 16 Jan 2011 05:50:10 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sun, 16 Jan 2011 05:50:10 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Jan 2011 08:50:10 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=0016e644d5cc2ba8180499f6f284 Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 13:47:40 -0000 --0016e644d5cc2ba8180499f6f284 Content-Type: text/plain; charset=ISO-8859-1 There are actually three issues here 1) Should the protocol only support TLS 2) Should the protocol only support TLS+HTTP 3) Should the protocol only support TLS+HTTP for Web browsing. Options 1 and 2 are both very broad. Only option 3 is actually narrowly focused but it is rather hard to separate out. Currently TLS is in use to secure practically every application layer protocol - SMTP, POP, IMAP, HTTP. It is also used to support several thousand Web Services protocols built on HTTP. Over the next few years that number of protocols will grow to tens of thousands. Deciding only to support TLS gives the illusion of focus but does not provide any focus whatsoever because we use TLS to secure 99% of stuff today. As a historical matter, X.509 was designed long before TLS but worked fine for TLS keying because the architecture was right. Stove pipe protocols tend to be too narrowly focused so that they end up not even supporting their own needs. Take a look a PKIX, it did not get complex overnight. It got complex because the initial design was inadequate for real-world needs and was only extended piecemeal. Working out how to apply a scheme to multiple protocols is the best way to make sure that what is produced is worth producing. --0016e644d5cc2ba8180499f6f284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are actually three issues here

1) Should the protocol only support TLS
2) Sh= ould the protocol only support TLS+HTTP
3) Should the protocol on= ly support TLS+HTTP for Web browsing.

Options 1 an= d 2 are both very broad. Only option 3 is actually narrowly focused but it = is rather hard to separate out.


Currently TLS is in use to secure practi= cally every application layer protocol - SMTP, POP, IMAP, HTTP. It is also = used to support several thousand Web Services protocols built on HTTP. Over= the next few years that number of protocols will grow to tens of thousands= .


Deciding only to support TLS gives the i= llusion of focus but does not provide any focus whatsoever because we use T= LS to secure 99% of stuff today. As a historical matter, X.509 was designed= long before TLS but worked fine for TLS keying because the architecture wa= s right.

Stove pipe protocols tend to be too narrowly focused so= that they end up not even supporting their own needs.=A0

Take a look a PKIX, it did not get complex overnight. It got comple= x because the initial design was inadequate for real-world needs and was on= ly extended piecemeal.


Working out how to apply a scheme to mul= tiple protocols is the best way to make sure that what is produced is worth= producing.=A0

--0016e644d5cc2ba8180499f6f284-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945143A6D23 for ; Sun, 16 Jan 2011 02:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORgWmkigUkGW for ; Sun, 16 Jan 2011 02:48:55 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6CC1C3A6B3F for ; Sun, 16 Jan 2011 02:48:55 -0800 (PST) Received: by wyf23 with SMTP id 23so4438658wyf.31 for ; Sun, 16 Jan 2011 02:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Nt7t1MqgSY0JIRcs5ZbBs2kOfGri9DhDK1oPk5JnjGw=; b=QBSzIxi/2luOOAkbLFijV2ecAdBI1mPg34bmU0+oFcaADWjRXvCe7f+D5VyVpV2Mv7 +Ij/Rhyi04s8PIzFNIthfVeE56JcHhirkH+CJAo5mthdk4sGXPYwfoTPaFht7uMIIP/a ScaEVCWtHFdKh/5r7yLBG9elVH70vlVr1FHgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=RjOr0eegfEjOrkVIQ5htRRZz5qxqPJjqnJeofBl9DZbpdIKgD27sq09hzFGSIcbilG un2wgQ5Ivt8Hb1LHrOYvSl2x31bgYr9n9TfvmroY3M3XBHDFya9n34bWuJKmkfY1Rh6H i916Ea/W6d/kszbZd4j825FC1DXd7XyXGTdms= Received: by 10.227.147.5 with SMTP id j5mr2772569wbv.61.1295175084612; Sun, 16 Jan 2011 02:51:24 -0800 (PST) Received: from [10.0.0.5] (93-172-188-143.bb.netvision.net.il [93.172.188.143]) by mx.google.com with ESMTPS id f35sm2415928wbf.8.2011.01.16.02.51.23 (version=SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 02:51:24 -0800 (PST) Message-ID: <4D32CDAA.10107@gmail.com> Date: Sun, 16 Jan 2011 12:51:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 10:48:56 -0000 Hi Paul, No, I am not taking any sides regarding support for protocols that are not mentioned in the charter (which is Issue #5). Note that IPsec itself is, in fact, already in the charter. Neither am I proposing to expand the scope of the current document (which is Issue #17). I actually prefer the current focus. I am just proposing the make the record's *name* protocol-agnostic, so it can be reused in the future without excuses. Thanks, Yaron > Date: Sat, 15 Jan 2011 17:00:44 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted > To: keyassure@ietf.org > Message-ID:<4D32433C.8020101@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/15/11 1:00 PM, Yaron Sheffer wrote: > >> I have an issue with the name of the DNS record type. "TLSA" implies one >> specific protocol. The working group's scope includes additional ones, >> and those and possibly others will want to use the same record type, >> hopefully. > > This would be issue #5 on our open issues list (reminder: > ). Are you trying to > get the chairs to start this discussion sooner than the others they > might want? :-) [1] > > --Paul Hoffman > > [1] The smiley there is because Yaron is co-chair of the IPsecME WG with > me and we tend to run our group off the issue tracker. > > > ------------------------------ > Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3865A3A6D0D for ; Sat, 15 Jan 2011 23:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqYca6jHikVB for ; Sat, 15 Jan 2011 23:23:07 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by core3.amsl.com (Postfix) with ESMTP id 0EB013A6D06 for ; Sat, 15 Jan 2011 23:23:07 -0800 (PST) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh02-2.mail.saunalahti.fi (Postfix) with SMTP id AC17FEF4AD; Sun, 16 Jan 2011 09:25:35 +0200 (EET) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A04686A7527; Sun, 16 Jan 2011 09:25:35 +0200 Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id D7FDC158A62; Sun, 16 Jan 2011 09:25:31 +0200 (EET) Date: Sun, 16 Jan 2011 09:25:44 +0200 From: Ilari Liusvaara To: Paul Wouters Message-ID: <20110116072544.GA3071@LK-Perkele-VI.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 07:23:08 -0000 On Sun, Jan 16, 2011 at 01:40:45AM -0500, Paul Wouters wrote: > On Sat, 15 Jan 2011, Warren Kumari wrote: > > >>The other alternative would be to make *this* document be much more > >> generic and able to support arbitrary key bindings. > > > >I am concerned that, no matter how well the document is written, trying > >to make it sufficiently generic will end up hard to understand, vague and > >difficult to implement from. > > SSH and IPsec already have their own RRTYPE. TLS is the big one missing > here. Other ones I can think of are PGP or S/MIME related, but those are > user based and not host based identities, which are probably better > handled seperately. Agreed. I looked at the SSHFP and IPSECKEY RFCs. They both appear to be fairly solid. And PGP and S/MIME are not even closely related to TLS (IPSec and SECSH are at least somewhat related to TLS). So I would go with TLS-only for the document. -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326643A6D0B for ; Sat, 15 Jan 2011 22:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPEUyw6EgWM4 for ; Sat, 15 Jan 2011 22:38:17 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 34B4C3A6D05 for ; Sat, 15 Jan 2011 22:38:17 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 1599DBF8B; Sun, 16 Jan 2011 01:40:46 -0500 (EST) Date: Sun, 16 Jan 2011 01:40:45 -0500 (EST) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 06:38:18 -0000 On Sat, 15 Jan 2011, Warren Kumari wrote: >> The other alternative would be to make *this* document be much more generic and able to support arbitrary key bindings. > > I am concerned that, no matter how well the document is written, trying to make it sufficiently generic will end up hard to understand, vague and difficult to implement from. Even getting the terminology sufficiently precise for clear discussions while still being generic is tricky.... I think so too. SSH and IPsec already have their own RRTYPE. TLS is the big one missing here. Other ones I can think of are PGP or S/MIME related, but those are user based and not host based identities, which are probably better handled seperately. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8F83A6DA3 for ; Sat, 15 Jan 2011 19:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVZjrk8w4Da8 for ; Sat, 15 Jan 2011 19:58:14 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id D4E8A3A67E3 for ; Sat, 15 Jan 2011 19:58:13 -0800 (PST) Received: from [192.168.0.150] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9C6432284A6C; Sat, 15 Jan 2011 23:00:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Sat, 15 Jan 2011 23:00:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.1081) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 03:58:14 -0000 On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote: > Buoyed by actual progress on getting the first issue resolved, I'm = proposing that we jump right into... the 17th issue. >=20 > Issue #17: Should draft-ietf-dane-protocol support TLS only or be more = ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17): >=20 > Description: > ------- > Please note: This is not the "what all protocols can / do we want to = support" issue. That will be a separate (and probably lively!) = discussion. >=20 > The current version of draft-ietf-dane-protocol is titled "Using = Secure DNS to Associate Certificates with Domain Names For TLS" and = first goal / milestone is "First WG draft of standards-track protocol = for using DNS to associate hosts with keys for TLS and DTLS". >=20 > What I would like us to discuss is: > Should *this* document simply specify how to support TLS and future = protocols can be supported by saying "TLSA, but interpret field Foo to = contain Bar" (or "Similar to TLSA, but this different RR, formatted like = Baz"). Note that some other protocols already have similar RRtypes; for = example SSH already has SSHFP. This approach is my personal preference. Having a document that clearly explains how something works for one = simple, concrete use case is (IMO) much easier to understand than a = document that tried to be all things to all people and cover all cases.=20= This approach should also allow us to make much faster progress, and = will allow us to gain experience and will address the largest use case = up front. >=20 > The other alternative would be to make *this* document be much more = generic and able to support arbitrary key bindings. I am concerned that, no matter how well the document is written, trying = to make it sufficiently generic will end up hard to understand, vague = and difficult to implement from. Even getting the terminology = sufficiently precise for clear discussions while still being generic is = tricky.... W > ------ >=20 > Getting consensus on this issue soon would be good, as it affects how = the document is written... >=20 > W Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BFF23A6DA3 for ; Sat, 15 Jan 2011 19:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdBDgm6s-9lu for ; Sat, 15 Jan 2011 19:13:19 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id A94513A6BE5 for ; Sat, 15 Jan 2011 19:13:19 -0800 (PST) Received: from [192.168.0.150] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9A2C82284A6C; Sat, 15 Jan 2011 22:15:48 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Jan 2011 22:15:46 -0500 Message-Id: To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 03:13:20 -0000 Buoyed by actual progress on getting the first issue resolved, I'm = proposing that we jump right into... the 17th issue. Issue #17: Should draft-ietf-dane-protocol support TLS only or be more = ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17): Description: ------- Please note: This is not the "what all protocols can / do we want to = support" issue. That will be a separate (and probably lively!) = discussion. The current version of draft-ietf-dane-protocol is titled "Using Secure = DNS to Associate Certificates with Domain Names For TLS" and first goal = / milestone is "First WG draft of standards-track protocol for using DNS = to associate hosts with keys for TLS and DTLS". What I would like us to discuss is: Should *this* document simply specify how to support TLS and future = protocols can be supported by saying "TLSA, but interpret field Foo to = contain Bar" (or "Similar to TLSA, but this different RR, formatted like = Baz"). Note that some other protocols already have similar RRtypes; for = example SSH already has SSHFP. The other alternative would be to make *this* document be much more = generic and able to support arbitrary key bindings. ------ Getting consensus on this issue soon would be good, as it affects how = the document is written... W= Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8AE3A6BE7 for ; Sat, 15 Jan 2011 17:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.708 X-Spam-Level: X-Spam-Status: No, score=-101.708 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL5K+H-eCGqx for ; Sat, 15 Jan 2011 17:05:41 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 762383A6BA7 for ; Sat, 15 Jan 2011 17:05:41 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0G18A7a048008 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 15 Jan 2011 18:08:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3244FB.9050305@vpnc.org> Date: Sat, 15 Jan 2011 17:08:11 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D320E7E.9090607@gmail.com> In-Reply-To: <4D320E7E.9090607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert validation X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 01:05:42 -0000 On 1/15/11 1:15 PM, Yaron Sheffer wrote: > Sec. 3.1.2 of the draft singles out self-signed certs, where "host > names" (in the section title) or "all data other than the key" (first > paragraph) is ignored. > > I have two issues here: > > - The first paragraph should have a normative SHOULD, instead of "can". > The data is indeed untrustworthy and clients SHOULD ignore it unless > validated otherwise. This was argued about previously, I think. This should be a new open issue because it deals with adding a 2119-level restriction. Also, why "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I don't have strong feelings either way on any of this). > - The exact same considerations apply to non-self signed certs. I don't > see a reason to talk specifically about self-signed certs. We disagree here. The Issuer field in a CA certificate cannot be ignored when doing PKIX chaining. > Just because > someone presents a cert that has, say, Verisign as the Issuer, doesn't > mean it is a valid Verisign certificate unless validated in the > traditional manner. Um, exactly. But self-signed certs are not "validated in the traditional manner", which is why this section exists. > So none of the certificate data can be trusted, > including the important Subject and SubjectAltName fields. Sec. 3.1.4 > kind of implies this fact, but the incorrect differentiation between > regular and self-signed certs remains. I believe there is a strong differentiation between "was validated" and "wasn't validated". If you and I are saying the same thing, I would love to see text to clarify what we have written. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C18A3A6BA8 for ; Sat, 15 Jan 2011 16:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.706 X-Spam-Level: X-Spam-Status: No, score=-101.706 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wwYaJGhWSYE for ; Sat, 15 Jan 2011 16:58:14 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9FC343A6BA7 for ; Sat, 15 Jan 2011 16:58:14 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0G10her047848 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 15 Jan 2011 18:00:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D32433C.8020101@vpnc.org> Date: Sat, 15 Jan 2011 17:00:44 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4D320AF6.8070200@gmail.com> In-Reply-To: <4D320AF6.8070200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 00:58:16 -0000 On 1/15/11 1:00 PM, Yaron Sheffer wrote: > I have an issue with the name of the DNS record type. "TLSA" implies one > specific protocol. The working group's scope includes additional ones, > and those and possibly others will want to use the same record type, > hopefully. This would be issue #5 on our open issues list (reminder: ). Are you trying to get the chairs to start this discussion sooner than the others they might want? :-) [1] --Paul Hoffman [1] The smiley there is because Yaron is co-chair of the IPsecME WG with me and we tend to run our group off the issue tracker. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7181928C0D9 for ; Sat, 15 Jan 2011 13:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb5t24BQf7dL for ; Sat, 15 Jan 2011 13:13:33 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B601428B56A for ; Sat, 15 Jan 2011 13:13:27 -0800 (PST) Received: by wwa36 with SMTP id 36so3897363wwa.13 for ; Sat, 15 Jan 2011 13:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bJpJDZrffCqFaEIp81HUnlohkC5cMygTP8gzw4jxdyU=; b=nr2dk3YvtqEbPEUljJTtYM+tLEzNzFLKYboian0KLIXp29IGHgEySBaq1QO9QAAhrJ 2oCvuasdPKlHMkZopje1a5H7/QZlWMmpVe+1927pO8wvDwLgjOOW08bDxspqvlnv8+ub ob1LcqSfBrZXxuPeYq/+OyXtXCd5ae71sA77o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=jd5emsOcBrNxLHViI+2utSDswQRALmIHMFXjz0nHB+ny4gmrrp8yhRETCgo87D8fx0 KtkeYfOeezdMCGHrTu5JxdvS4ESl3oMdlAneVq+gC4WKUoBzVhU7VFD9qplbYzk+10hW sf0fkjXdVmiFnceopCQ1RYy+5gPVYDH5j2Pyo= Received: by 10.227.20.16 with SMTP id d16mr2232699wbb.173.1295126145182; Sat, 15 Jan 2011 13:15:45 -0800 (PST) Received: from [10.0.0.6] (bzq-109-67-17-212.red.bezeqint.net [109.67.17.212]) by mx.google.com with ESMTPS id 11sm2013049wbi.0.2011.01.15.13.15.43 (version=SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 13:15:44 -0800 (PST) Message-ID: <4D320E7E.9090607@gmail.com> Date: Sat, 15 Jan 2011 23:15:42 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert validation X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 21:13:34 -0000 Hi, Sec. 3.1.2 of the draft singles out self-signed certs, where "host names" (in the section title) or "all data other than the key" (first paragraph) is ignored. I have two issues here: - The first paragraph should have a normative SHOULD, instead of "can". The data is indeed untrustworthy and clients SHOULD ignore it unless validated otherwise. - The exact same considerations apply to non-self signed certs. I don't see a reason to talk specifically about self-signed certs. Just because someone presents a cert that has, say, Verisign as the Issuer, doesn't mean it is a valid Verisign certificate unless validated in the traditional manner. So none of the certificate data can be trusted, including the important Subject and SubjectAltName fields. Sec. 3.1.4 kind of implies this fact, but the incorrect differentiation between regular and self-signed certs remains. Thanks, Yaron Date: Sat, 15 Jan 2011 08:21:17 -0800 > From: Paul Hoffman > Subject: [keyassure] draft-ietf-dane-protocol-02 posted > To: "keyassure@ietf.org" > Message-ID:<4D31C97D.90707@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > The main change is the definition of the wire format to match the > consensus call made yesterday closing issue #4. Jakob and I intend to > keep pumping out drafts as issues are closed. We probably won't do one > draft per consensus call, but hope to do one when each "big" issue is > closed. > > --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4921628C0D8 for ; Sat, 15 Jan 2011 12:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh1QJFzQ8crj for ; Sat, 15 Jan 2011 12:58:50 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1B61F3A6E3C for ; Sat, 15 Jan 2011 12:58:49 -0800 (PST) Received: by wyf23 with SMTP id 23so4130496wyf.31 for ; Sat, 15 Jan 2011 13:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DIW5vK0/iSTnIvlGujEIjBrVyFe2In2q27W049qpT4c=; b=Qc3Zp26iJGG4a3zCnYW7MJOdYBXbAjJN4vVIhuE5i62E2o46rPtZJiGccPb90rNfFq DfhaThzCAs274iTACeVPovSsEIrQEApwOar0wdXDdtNaiFsn8E5jr230YwpQUj9B5xqu +2fySv9ETGhGRHYah3nBoTsJLGSUko/A1kUnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=seAiuQ8YaAHQ1zc39g0W1VRTWlk7a+hDQGvjd0awg8qsl+0CF8L6BQ9kIsIWHwUKgJ jxUMqYPfdLMxDQn+bI4xJahSOJN75ih/kJrWvk29DdrlzbvA0I5uP7o2eoY/tAktzNtq eL9y8XMC1V65iUPpSQBJkJ5W+0VjjyiiHAaJ8= Received: by 10.227.141.78 with SMTP id l14mr2241063wbu.128.1295125240846; Sat, 15 Jan 2011 13:00:40 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id q18sm2001837wbe.5.2011.01.15.13.00.39 (version=SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 13:00:40 -0800 (PST) Message-ID: <4D320AF6.8070200@gmail.com> Date: Sat, 15 Jan 2011 23:00:38 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 20:58:51 -0000 Hi, I have an issue with the name of the DNS record type. "TLSA" implies one specific protocol. The working group's scope includes additional ones, and those and possibly others will want to use the same record type, hopefully. How about adopting a protocol-agnostic name? To throw something out, I suggest NEE: Named End Entity. Thanks, Yaron Date: Sat, 15 Jan 2011 08:21:17 -0800 > From: Paul Hoffman > Subject: [keyassure] draft-ietf-dane-protocol-02 posted > To: "keyassure@ietf.org" > Message-ID:<4D31C97D.90707@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > The main change is the definition of the wire format to match the > consensus call made yesterday closing issue #4. Jakob and I intend to > keep pumping out drafts as issues are closed. We probably won't do one > draft per consensus call, but hope to do one when each "big" issue is > closed. > > --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722DE3A6C00 for ; Sat, 15 Jan 2011 08:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.41 X-Spam-Level: X-Spam-Status: No, score=-100.41 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-ZYvrbOZfSE for ; Sat, 15 Jan 2011 08:18:50 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0B8CD3A6D6A for ; Sat, 15 Jan 2011 08:18:49 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0FGLHhw034266 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 15 Jan 2011 09:21:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D31C97D.90707@vpnc.org> Date: Sat, 15 Jan 2011 08:21:17 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "keyassure@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [keyassure] draft-ietf-dane-protocol-02 posted X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 16:18:51 -0000 The main change is the definition of the wire format to match the consensus call made yesterday closing issue #4. Jakob and I intend to keep pumping out drafts as issues are closed. We probably won't do one draft per consensus call, but hope to do one when each "big" issue is closed. --Paul Hoffman Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180F93A6B7B; Sat, 15 Jan 2011 08:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CpX0O7KD9n5; Sat, 15 Jan 2011 08:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3463A68D1; Sat, 15 Jan 2011 08:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110115160002.13114.60442.idtracker@localhost> Date: Sat, 15 Jan 2011 08:00:02 -0800 Cc: keyassure@ietf.org Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-02.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 16:00:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For TLS Author(s) : P. Hoffman, J. Schlyter Filename : draft-ietf-dane-protocol-02.txt Pages : 12 Date : 2011-01-15 TLS and DTLS use certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certification authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dane-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-15075441.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9858E3A6CA7 for ; Fri, 14 Jan 2011 14:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUnBAfZPmZKo for ; Fri, 14 Jan 2011 14:46:44 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 01EE53A6BF6 for ; Fri, 14 Jan 2011 14:46:44 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 40D59228408A; Fri, 14 Jan 2011 17:49:10 -0500 (EST) Message-Id: From: Warren Kumari To: Ilari Liusvaara In-Reply-To: <20110114070251.GA15044@LK-Perkele-VI.localdomain> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Jan 2011 17:49:09 -0500 References: <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> <4D28B758.7080801@vpnc.org> <011801cbb3aa$fcb23220$f6169660$@augustcellars.com> <20110114070251.GA15044@LK-Perkele-VI.localdomain> X-Mailer: Apple Mail (2.936) Cc: Jim Schaad , keyassure@ietf.org, 'Paul Hoffman' Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 22:46:45 -0000 Ok, after discussions with my cochair, we are calling consensus. WG consensus is that we will ask the IANA to create and maintain a (one octet) registry to identify the hash and cert types. This does still allow for the registration and use of things like ODI (and parameterized hash functions, and other cool things) by allowing them to specify how the "body" ("bytes containing the certificate or the hash of the associated certificate") is interpreted. I would like to thank everyone who contributed to getting consensus on this issue-- don't for a minute think that you are off the hook now though, there are many more issues to work through :-P W On Jan 14, 2011, at 2:02 AM, Ilari Liusvaara wrote: > On Thu, Jan 13, 2011 at 09:22:06PM -0800, Jim Schaad wrote: >> Is there any reason to worry about any of the parameterized hash >> functions >> such as the randomized hash function proposal presented at the SAAG >> meeting >> in SFO? > > I think those can be handled by defining the "hashes" to include the > parameters in hash-function specific way. > > -Ilari > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--" -- Terry Pratchett Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2593A6C45 for ; Fri, 14 Jan 2011 07:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.703 X-Spam-Level: X-Spam-Status: No, score=-101.703 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU5ByTv4+Qgr for ; Fri, 14 Jan 2011 07:16:57 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 430553A6C1D for ; Fri, 14 Jan 2011 07:16:57 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0EFJMx4092544 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 14 Jan 2011 08:19:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D30697B.1090701@vpnc.org> Date: Fri, 14 Jan 2011 07:19:23 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> <4D28B758.7080801@vpnc.org> <011801cbb3aa$fcb23220$f6169660$@augustcellars.com> <20110114070251.GA15044@LK-Perkele-VI.localdomain> In-Reply-To: <20110114070251.GA15044@LK-Perkele-VI.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 15:16:58 -0000 On 1/13/11 11:02 PM, Ilari Liusvaara wrote: > On Thu, Jan 13, 2011 at 09:22:06PM -0800, Jim Schaad wrote: >> Is there any reason to worry about any of the parameterized hash functions >> such as the randomized hash function proposal presented at the SAAG meeting >> in SFO? > > I think those can be handled by defining the "hashes" to include the > parameters in hash-function specific way. +1. Any parameterized hash function needs to be able to say where those parameters go in the the outside protocol. For example, they could be stuffed at the beginning or end of the hash value here. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C513A693A for ; Thu, 13 Jan 2011 22:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZuZCgre8QAx for ; Thu, 13 Jan 2011 22:59:36 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id 7941E3A6C54 for ; Thu, 13 Jan 2011 22:59:35 -0800 (PST) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 70E73C7E57; Fri, 14 Jan 2011 09:01:58 +0200 (EET) Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A011A56D0B5; Fri, 14 Jan 2011 09:01:58 +0200 Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id 6B39727D87; Fri, 14 Jan 2011 09:01:54 +0200 (EET) Date: Fri, 14 Jan 2011 09:02:51 +0200 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20110114070251.GA15044@LK-Perkele-VI.localdomain> References: <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> <4D28B758.7080801@vpnc.org> <011801cbb3aa$fcb23220$f6169660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <011801cbb3aa$fcb23220$f6169660$@augustcellars.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org, 'Paul Hoffman' Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 06:59:37 -0000 On Thu, Jan 13, 2011 at 09:22:06PM -0800, Jim Schaad wrote: > Is there any reason to worry about any of the parameterized hash functions > such as the randomized hash function proposal presented at the SAAG meeting > in SFO? I think those can be handled by defining the "hashes" to include the parameters in hash-function specific way. -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C753A6839 for ; Thu, 13 Jan 2011 21:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOW5WQNCFGAR for ; Thu, 13 Jan 2011 21:01:58 -0800 (PST) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 9B3793A6862 for ; Thu, 13 Jan 2011 21:01:58 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 161A72CA41; Thu, 13 Jan 2011 21:04:23 -0800 (PST) From: "Jim Schaad" To: "'Paul Hoffman'" , References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> <4D28B758.7080801@vpnc.org> In-Reply-To: <4D28B758.7080801@vpnc.org> Date: Thu, 13 Jan 2011 21:22:06 -0800 Message-ID: <011801cbb3aa$fcb23220$f6169660$@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: AQKRiu0QwA/owEnu1/WogDNJujlSsAEgzopcAgN0p8wBrDZJ6gD7vdOAAv95JxoBySPfKwEE7ze7AaEDpucBYXgShgKK5lAMAxAwH6sCcZDR2gEAIDAeAioAUdEBpevnbQK/r+GLAVpeOJyRR6facA== Content-Language: en-us Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 05:01:59 -0000 Is there any reason to worry about any of the parameterized hash functions such as the randomized hash function proposal presented at the SAAG meeting in SFO? > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Paul Hoffman > Sent: Saturday, January 08, 2011 11:13 AM > To: keyassure@ietf.org > Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- > "Identification of hash and cert types." > > On 1/8/11 11:04 AM, Warren Kumari wrote: > > Ok, so I'm proposing a compromise here as a third option. As this is a > > compromise, I'm assuming no-one will love it, but maybe folk will be > > willing to accept it... > > If that's the way you think the consensus is going, that's fine. I didn't see it > going that way. Phill had one proposal with (possibly one) person behind it. I > had another with a small handful behind it. Others had not weighed in yet. > > Of the now three proposals for the format, I still feel that "a two-octet number" > is better than ODI or a mixture of the two, FWIW. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A023A6B3B for ; Wed, 12 Jan 2011 09:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCEgAe1mkTgY for ; Wed, 12 Jan 2011 09:02:20 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 8DA113A6A59 for ; Wed, 12 Jan 2011 09:02:20 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id C019D36A412; Wed, 12 Jan 2011 09:04:40 -0800 (PST) References: <1294800660.4455.41.camel@mattlaptop2.local> <20110112153233.GB26731@shinkuro.com> <482BB12C-C36A-4CFA-979C-F9E57DBE4826@icsi.berkeley.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 12 Jan 2011 09:04:40 -0800 To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: Dan Kaminsky , Nicholas Weaver , keyassure@ietf.org Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 17:02:21 -0000 On Jan 12, 2011, at 8:28 AM, Paul Wouters wrote: >> Since systems are often, by default, configured to use (and ONLY know = about) the NAT's DNS gateway, doing just about anything with DNSSEC to = the client means that the stub resolver MUST be willing to bypass the = recursive resolver infrastructure completely, and even then, be prepared = for failures, including failures of new RTYPES to work when old RTYPES = work successfully. >=20 > How much of those ENDS0 clients allow TCP? Because if not, then your = DNSSEC limit is > already at 90% without even considering new RRTYPE's, and I'd think = that there is a large > overlap in systems not able to do EDNS0/TCP and systems not able to do = new RRTYPEs. Its pretty good. DNS over TCP is much MUCH less mangled than DNS over = UDP.=20 > Also, if you are asking TLSA/HASTLS/TXT records, you *are* an endpoint = either doing DNSSEC > yourself, or you are using a DNSSEC-capable resolver. In neither case = are you using a bad > NAT router DNS stub forwarder as listed above in the list of broken = stuff out there. The model of doing DNSSEC yourself [1] requires either being able to = query the appropriate records from the configured recursive resolver or = bypassing it entirely. This shows that the model of 'only get from the = recursive resolver', as the recursive resolver IS the NAT proxy in many = many cases, doesn't work, you MUST be prepared to bypass it. Oh, and the NAT can only handle an unknown RTYPE=3D1169 [2] in 91% of = the cases, and can handle either a TXT record OR an unknown RTYPE in 92% = of the cases, so unknown RTYPES really aren't that much worse than TXT = records (its highly coupled between the two) from the NAT viewpoint. And its been pointed out that, oops, you need to look at correlation on = the direct case as well: 98.2% were able to get a TXT or Unknown rtype = on a direct connection, compared with 98.1% for TXT only and 97.0% for = unknown only (and this unknown IS a meta type, so if anything will get = shot down, it will). So in conclusion, I was wrong, it actually is a myth that new RTYPES = perform significantly worse than TXT records: So don't be afraid to = design new RTYPEs instead of shoving it into a TXT record: TXT records = don't work better enough for this to be worth doing.=20 >=20 > Paul > Paul [1] ObIMO, the only place that makes sense: the recursive resolver is = PROVED untrustworthy, and doing validation on the recursive resolver = provides effectively no meaningful increase in security while creating a = huge hit on reliability)=20 [2] There was a bug in this test that before December 5th, would have = the test try 169 rather than 1169. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F183A6A5C for ; Wed, 12 Jan 2011 08:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCRsf-cbrkgK for ; Wed, 12 Jan 2011 08:26:40 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 7D6D33A6A4B for ; Wed, 12 Jan 2011 08:26:39 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id EA7ACC487; Wed, 12 Jan 2011 11:28:57 -0500 (EST) Date: Wed, 12 Jan 2011 11:28:57 -0500 (EST) From: Paul Wouters To: Nicholas Weaver , Dan Kaminsky In-Reply-To: <482BB12C-C36A-4CFA-979C-F9E57DBE4826@icsi.berkeley.edu> Message-ID: References: <1294800660.4455.41.camel@mattlaptop2.local> <20110112153233.GB26731@shinkuro.com> <482BB12C-C36A-4CFA-979C-F9E57DBE4826@icsi.berkeley.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 16:26:42 -0000 On Wed, 12 Jan 2011, Nicholas Weaver wrote: > Date: Wed, 12 Jan 2011 08:09:54 -0800 > From: Nicholas Weaver > Cc: keyassure@ietf.org > To: Andrew Sullivan > Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client > > > On Jan 12, 2011, at 7:32 AM, Andrew Sullivan wrote: >> What bothers me about this is that anything that can do DNSSEC >> _anyway_ can already cope with unknown RRTYPEs. Moreover, anyone who >> is interested in this right now is obviously going to be willing to >> keep their system up to date too. The difficulty of dealing with >> RRTYPE numbers one doesn't know is a zombie fact: something that used >> to be true but now will not die. I don't expect everyone to >> understand this, but I do expect people who are promoting DNSSEC to do >> so. > > Not necessarily. Even directly over the network (so direct client to server) you see a greater problem requesting an unknown RTYPE rather than a TXT record, and you see problems fetching records with EDNS0 enabled once you hit >512B responses. > > Success rate in Netalyzr > EDNS0 98.5% > EDNS0 1400B response 95.8% > (old test, so always run) > > TXT 98.1% > RTYPE=169 97.0% > (newer test) > > The situation is MUCH MUCH MUCH worse when you are talking about probing the NAT's DNS gateway: > EDNS0 90% > TXT 92% > AAAA 95% > (the unknown rtype test was bugged, so its not considered here). > > Since systems are often, by default, configured to use (and ONLY know about) the NAT's DNS gateway, doing just about anything with DNSSEC to the client means that the stub resolver MUST be willing to bypass the recursive resolver infrastructure completely, and even then, be prepared for failures, including failures of new RTYPES to work when old RTYPES work successfully. How much of those ENDS0 clients allow TCP? Because if not, then your DNSSEC limit is already at 90% without even considering new RRTYPE's, and I'd think that there is a large overlap in systems not able to do EDNS0/TCP and systems not able to do new RRTYPEs. Also, if you are asking TLSA/HASTLS/TXT records, you *are* an endpoint either doing DNSSEC yourself, or you are using a DNSSEC-capable resolver. In neither case are you using a bad NAT router DNS stub forwarder as listed above in the list of broken stuff out there. Paul Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 303243A6B31 for ; Wed, 12 Jan 2011 08:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXvVO0ZF2R8y for ; Wed, 12 Jan 2011 08:13:33 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id ED0C43A6A4B for ; Wed, 12 Jan 2011 08:13:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RpzeR/gNRFSFU8IlnCJV29tNCZ1e/xMWGcXXLGlDaCUgbwmUKNGezBnND4OWrGlo; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Pd3MW-0000q5-S7 for keyassure@ietf.org; Wed, 12 Jan 2011 11:15:52 -0500 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 12 Jan 2011 11:15:52 -0500 Message-ID: <18457109.1294848952806.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Wed, 12 Jan 2011 10:15:52 -0600 (GMT-06:00) From: "Jeffrey A. Williams" To: keyassure@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688e83f28b8c11523b2d7ce0608238f540a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 16:13:34 -0000 Andrew and all, Isn't that Phreebird instead of Phreeload? See: http://www.darkreading.com/authentication/167901072/security/application-security/228200646/index.html Otherwise I agree. >:) -----Original Message----- >From: Andrew Sullivan >Sent: Jan 12, 2011 9:32 AM >To: keyassure@ietf.org >Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client > >On Tue, Jan 11, 2011 at 10:12:50PM -0500, Paul Wouters wrote: > >> He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago >> about this. I also asked him for a somewhat more formal specification of >> his TXT records, though I urged him to be part of the IETF process in >> getting the right new RRTYPE. His fears are mostly based on old software >> seeing and having to configure decimal numbers for new RRTYPEs. > >What bothers me about this is that anything that can do DNSSEC >_anyway_ can already cope with unknown RRTYPEs. Moreover, anyone who >is interested in this right now is obviously going to be willing to >keep their system up to date too. The difficulty of dealing with >RRTYPE numbers one doesn't know is a zombie fact: something that used >to be true but now will not die. I don't expect everyone to >understand this, but I do expect people who are promoting DNSSEC to do >so. > >A > >-- >Andrew Sullivan >ajs@shinkuro.com >Shinkuro, Inc. >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Kindest Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 IT/network security Eng. SR. Eng. Network data security, IT/information and web security. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E27B3A6B31 for ; Wed, 12 Jan 2011 08:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChfRlRrQM0xs for ; Wed, 12 Jan 2011 08:07:34 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id A3F0B3A6B07 for ; Wed, 12 Jan 2011 08:07:34 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8FFBE36A417; Wed, 12 Jan 2011 08:09:54 -0800 (PST) References: <1294800660.4455.41.camel@mattlaptop2.local> <20110112153233.GB26731@shinkuro.com> In-Reply-To: <20110112153233.GB26731@shinkuro.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <482BB12C-C36A-4CFA-979C-F9E57DBE4826@icsi.berkeley.edu> Content-Transfer-Encoding: quoted-printable From: Nicholas Weaver Date: Wed, 12 Jan 2011 08:09:54 -0800 To: Andrew Sullivan X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 16:07:35 -0000 On Jan 12, 2011, at 7:32 AM, Andrew Sullivan wrote: > What bothers me about this is that anything that can do DNSSEC > _anyway_ can already cope with unknown RRTYPEs. Moreover, anyone who > is interested in this right now is obviously going to be willing to > keep their system up to date too. The difficulty of dealing with > RRTYPE numbers one doesn't know is a zombie fact: something that used > to be true but now will not die. I don't expect everyone to > understand this, but I do expect people who are promoting DNSSEC to do > so. Not necessarily. Even directly over the network (so direct client to = server) you see a greater problem requesting an unknown RTYPE rather = than a TXT record, and you see problems fetching records with EDNS0 = enabled once you hit >512B responses. Success rate in Netalyzr EDNS0 98.5% EDNS0 1400B response 95.8% (old test, so always run) TXT 98.1% RTYPE=3D169 97.0% (newer test) The situation is MUCH MUCH MUCH worse when you are talking about probing = the NAT's DNS gateway: EDNS0 90% TXT 92% AAAA 95% (the unknown rtype test was bugged, so its not considered here). Since systems are often, by default, configured to use (and ONLY know = about) the NAT's DNS gateway, doing just about anything with DNSSEC to = the client means that the stub resolver MUST be willing to bypass the = recursive resolver infrastructure completely, and even then, be prepared = for failures, including failures of new RTYPES to work when old RTYPES = work successfully. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB1328C13E for ; Wed, 12 Jan 2011 07:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p48wJOdWw8F for ; Wed, 12 Jan 2011 07:30:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C2F6128C12E for ; Wed, 12 Jan 2011 07:30:16 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D0CCD1ECB41F for ; Wed, 12 Jan 2011 15:32:35 +0000 (UTC) Date: Wed, 12 Jan 2011 10:32:33 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110112153233.GB26731@shinkuro.com> References: <1294800660.4455.41.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 15:30:18 -0000 On Tue, Jan 11, 2011 at 10:12:50PM -0500, Paul Wouters wrote: > He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago > about this. I also asked him for a somewhat more formal specification of > his TXT records, though I urged him to be part of the IETF process in > getting the right new RRTYPE. His fears are mostly based on old software > seeing and having to configure decimal numbers for new RRTYPEs. What bothers me about this is that anything that can do DNSSEC _anyway_ can already cope with unknown RRTYPEs. Moreover, anyone who is interested in this right now is obviously going to be willing to keep their system up to date too. The difficulty of dealing with RRTYPE numbers one doesn't know is a zombie fact: something that used to be true but now will not die. I don't expect everyone to understand this, but I do expect people who are promoting DNSSEC to do so. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49A528C0EF for ; Wed, 12 Jan 2011 06:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d7p4SOV2CaC for ; Wed, 12 Jan 2011 06:19:27 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id CFAE728C0E8 for ; Wed, 12 Jan 2011 06:19:26 -0800 (PST) Received: by yxt33 with SMTP id 33so263319yxt.31 for ; Wed, 12 Jan 2011 06:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=spPUWBlEq03SSSq1DOYn9vVrMfMS8W56T2tS0aYY4OM=; b=DOOfLrUOkJG0AqvRnmB50MHfUuYw7OD1L6+B7Yt5HasJ0q8+UtFCb6czasgsXsfDMI RKcWTrnQYQv3Sk+xFMAp1YH4fSGy8K0rxgMqhDj3lg2YVoifVrNPqyB38EuwyJ5oXuMH aRjN2JtV01/70jn29rexYNz4MWPShL5asaLQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vFn/faC539d0OETXnmVM01r0XgCe85dQnIunI+gIYPwerjr8CvLiy8H0vcVhda4ZD4 PDmW2KNIPS6BmeQ2s4L6bImOakJW/4WZ8ZGRRXTO/4Q+Yq3g84dvX0S8mMUJcHPLwOCS v0GDVRCesH0dSTOMj3HBb4B9dkhkdGKDO49Wk= MIME-Version: 1.0 Received: by 10.100.197.6 with SMTP id u6mr633352anf.103.1294842106300; Wed, 12 Jan 2011 06:21:46 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 12 Jan 2011 06:21:46 -0800 (PST) In-Reply-To: <20110112050131.GA330@LK-Perkele-VI.localdomain> References: <4D27A3DC.8010409@vpnc.org> <201101120229.p0C2TvXL013730@fs4113.wdf.sap.corp> <20110112050131.GA330@LK-Perkele-VI.localdomain> Date: Wed, 12 Jan 2011 09:21:46 -0500 Message-ID: From: Phillip Hallam-Baker To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=0016e64f8f4ac94c140499a6ebd6 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 14:19:28 -0000 --0016e64f8f4ac94c140499a6ebd6 Content-Type: text/plain; charset=ISO-8859-1 I am pretty sure that the X.500 OID and the RSADSI OID are actually for different packaging formats. When the X.500 directory was specified the OID did not specify the PKCS#1 bit packaging. That was specified later when Dorothy Denning pointed out that there are security implications to the packaging format. These should have different identifiers since they are actually different algorithms and cannot be substituted. Later on Rogaway and Bellare came out with important work. RSADSI have actually assigned 6 different code points for different versions of RSA over the years. And the differences actually matter quite a bit. I cannot understand what you would need that 64K array for either Crypto APIs already have code for managing OIDs. You are really not helping anyone here. All you are doing is ensuring that the application has to be revised to use a new algorithm rather than allowing the crypto library to announce that it is available. What I care about here is that people can take an ODI from another context and cut and paste it into this use without it causing problems. That will work perfectly provided I have the code point 0x30 or 0x30 0x12 reserved for ODI. If people want to have additional codes for shortcuts for the mandatory algorithms then I really don't have a problem with that. If all we are going to do is to track the mandatory algorithms with the registry then a single byte code will be adequate. If we do run out then people will have to use the ODI scheme for mandatory algs as well. On Wed, Jan 12, 2011 at 12:01 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Jan 12, 2011 at 03:29:57AM +0100, Martin Rex wrote: > > Paul Hoffman wrote: > > > > > > > My preference would also be a fixed size integer. > > Same (1 or 2 octets). > > The reason for this is that with 2 octets, one gets 65536 entry array > if one lays it out in full. Too large for embedded code, but any general > purpose computer has an OS capable of demand paging. And in environment > like that, the resources used by full table are penuts (and it is very > easy to program). > > > Is there a problem for a registry to contain more than a > > primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather > > something like (IntegerValue,AlgorithmName,StandardizationLevel) > > with StandardizationLevel values such as > > { required, recommended, optional, experimental, discouraged } > > Aren't registeries usually like that? > > > The problem with ASN.1 OIDs is that they wasteful (in terms of code, > storage > > network bandwidth, cpu cycles), variable-sized blobs and therefore a > royal > > PITA to use in software. > > > > I strongly prefer > > > > switch(algorithm_cp) { > > case A: /* code for A */ > > break; > > case B: /* code for B */ > > break; > > case C: /* code for C */ > > break; > > default: /* produce some useful error msg about unsupported alg */ > > break; > > } > > Or even: > > #define MAXHASHOUTPUT 256 > > struct hash_algo* dane_hashes[65536]; > > int h; > struct hash_algo* H; > unsigned char hashbuffer[MAXHASHOUTPUT]; > > h = p[2] * 256 + p[3]; > H = dane_hashes[h]; > if(!H) > return -1; > > H->hash(hashbuffer, data, datalen); > return memcmp(hashbuffer, p + 4, H->hashlen) ? 0 : 1; > > > > ASN.1 OIDs in PKIX are a pain, and they're ambiguous. > > > > e.g. for RSA there seem to be two(!) OIDs in use in X.509, > > something which is not going to happen with a single registry: > > > > 2.5.8.1.1 > > 1.2.840.113549.1.1.1 > > What, only two? :-) > > Yeah. Aliases. Brings nothing useful... Only interop problems. > > > Finding out the meaning of an OID you do _not_ happen to know > > is far from trivial, something that will not happen with a registry. > > > > The difficulty with OIDs (or other complex variable sized objects) > > is not in sending/emitting them, but in receiving/parsing them. > > The code to produce a meaningful error message for an unrecognized > > value is trivial for a scalar integer value and complex for an OID > > (to produce an error message that can be copy&pasted into google). > > Oh, and don't forget the NULL vs. empty parameters problem. Wonder > how much code gets that wrong... Probably LOTS. > > > -Ilari > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e64f8f4ac94c140499a6ebd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am pretty sure that the X.500 OID and the RSADSI OID are actually for dif= ferent packaging formats.

When the X.500 directory was s= pecified the OID did not specify the PKCS#1 bit packaging. That was specifi= ed later when Dorothy Denning pointed out that there are security implicati= ons to the packaging format.=A0

These should have different identifiers since they are = actually different algorithms and cannot be substituted. Later on Rogaway a= nd Bellare came out with important work.


RSADSI have actually assigned 6 different code points for different ve= rsions of RSA over the years. And the differences actually matter quite a b= it.


I cannot understand what you wo= uld need that 64K array for either

Crypto APIs already have code for managing OIDs. You ar= e really not helping anyone here. All you are doing is ensuring that the ap= plication has to be revised to use a new algorithm rather than allowing the= crypto library to announce that it is available.


What I care about here is that people ca= n take an ODI from another context and cut and paste it into this use witho= ut it causing problems.

That will work perfectly p= rovided I have the code point 0x30 or 0x30 0x12 reserved for ODI.

If people want to have additional codes for shortcuts f= or the mandatory algorithms then I really don't have a problem with tha= t. If all we are going to do is to track the mandatory algorithms with the = registry then a single byte code will be adequate. If we do run out then pe= ople will have to use the ODI scheme for mandatory algs as well.




On We= d, Jan 12, 2011 at 12:01 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>= wrote:
On Wed, Jan 12, 2011 at 0= 3:29:57AM +0100, Martin Rex wrote:
> Paul Hoffman wrote:
> >
>
> My preference would also be a fixed size integer.

Same (1 or 2 octets).

The reason for this is that with 2 octets, one gets 65536 entry array
if one lays it out in full. Too large for embedded code, but any general purpose computer has an OS capable of demand paging. And in environment
like that, the resources used by full table are penuts (and it is very
easy to program).

> Is there a problem for a registry to contain more than a
> primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather
> something like (IntegerValue,AlgorithmName,StandardizationLevel)
> with StandardizationLevel values such as
> { required, recommended, optional, experimental, discouraged }

Aren't registeries usually like that?

> The problem with ASN.1 OIDs is that they wasteful (in terms of code, s= torage
> network bandwidth, cpu cycles), variable-sized blobs and therefore a r= oyal
> PITA to use in software.
>
> I strongly prefer
>
> =A0 =A0switch(algorithm_cp) {
> =A0 =A0 =A0 case A: /* code for A */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 case B: /* code for B */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 case C: /* code for C */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0 =A0 default: /* produce some useful error msg about unsupporte= d alg */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> =A0 =A0}

Or even:

#define MAXHASHOUTPUT 256

struct hash_algo* dane_hashes[65536];

int h;
struct hash_algo* H;
unsigned char hashbuffer[MAXHASHOUTPUT];

h =3D p[2] * 256 + p[3];
H =3D dane_hashes[h];
if(!H)
=A0 =A0 =A0 =A0return -1;

H->hash(hashbuffer, data, datalen);
return memcmp(hashbuffer, p + 4, H->hashlen) ? 0 : 1;


> ASN.1 OIDs in PKIX are a pain, and they're ambiguous.
>
> e.g. for RSA there seem to be two(!) OIDs in use in X.509,
> something which is not going to happen with a single registry:
>
> =A0 =A0 2.5.8.1.1
> =A0 =A0 1.2.840.113549.1.1.1

What, only two? :-)

Yeah. Aliases. Brings nothing useful... Only interop problems.

> Finding out the meaning of an OID you do _not_ happen to know
> is far from trivial, something that will not happen with a registry. >
> The difficulty with OIDs (or other complex variable sized objects)
> is not in sending/emitting them, but in receiving/parsing them.
> The code to produce a meaningful error message for an unrecognized
> value is trivial for a scalar integer value and complex for an OID
> (to produce an error message that can be copy&pasted into google).=

Oh, and don't forget the NULL vs. empty parameters problem. Wonde= r
how much code gets that wrong... Probably LOTS.


-Ilari
__________________________________= _____________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e64f8f4ac94c140499a6ebd6-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2605A3A6AE3 for ; Tue, 11 Jan 2011 20:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erybuTA+558o for ; Tue, 11 Jan 2011 20:58:38 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id C95733A6AE1 for ; Tue, 11 Jan 2011 20:58:36 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id 9D57B13B778; Wed, 12 Jan 2011 07:00:53 +0200 (EET) Received: from emh06.mail.saunalahti.fi ([62.142.5.116]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A04025917A8; Wed, 12 Jan 2011 07:00:53 +0200 Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 3AD10E51A9; Wed, 12 Jan 2011 07:00:48 +0200 (EET) Date: Wed, 12 Jan 2011 07:01:31 +0200 From: Ilari Liusvaara To: Martin Rex Message-ID: <20110112050131.GA330@LK-Perkele-VI.localdomain> References: <4D27A3DC.8010409@vpnc.org> <201101120229.p0C2TvXL013730@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201101120229.p0C2TvXL013730@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 04:58:39 -0000 On Wed, Jan 12, 2011 at 03:29:57AM +0100, Martin Rex wrote: > Paul Hoffman wrote: > > > > My preference would also be a fixed size integer. Same (1 or 2 octets). The reason for this is that with 2 octets, one gets 65536 entry array if one lays it out in full. Too large for embedded code, but any general purpose computer has an OS capable of demand paging. And in environment like that, the resources used by full table are penuts (and it is very easy to program). > Is there a problem for a registry to contain more than a > primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather > something like (IntegerValue,AlgorithmName,StandardizationLevel) > with StandardizationLevel values such as > { required, recommended, optional, experimental, discouraged } Aren't registeries usually like that? > The problem with ASN.1 OIDs is that they wasteful (in terms of code, storage > network bandwidth, cpu cycles), variable-sized blobs and therefore a royal > PITA to use in software. > > I strongly prefer > > switch(algorithm_cp) { > case A: /* code for A */ > break; > case B: /* code for B */ > break; > case C: /* code for C */ > break; > default: /* produce some useful error msg about unsupported alg */ > break; > } Or even: #define MAXHASHOUTPUT 256 struct hash_algo* dane_hashes[65536]; int h; struct hash_algo* H; unsigned char hashbuffer[MAXHASHOUTPUT]; h = p[2] * 256 + p[3]; H = dane_hashes[h]; if(!H) return -1; H->hash(hashbuffer, data, datalen); return memcmp(hashbuffer, p + 4, H->hashlen) ? 0 : 1; > ASN.1 OIDs in PKIX are a pain, and they're ambiguous. > > e.g. for RSA there seem to be two(!) OIDs in use in X.509, > something which is not going to happen with a single registry: > > 2.5.8.1.1 > 1.2.840.113549.1.1.1 What, only two? :-) Yeah. Aliases. Brings nothing useful... Only interop problems. > Finding out the meaning of an OID you do _not_ happen to know > is far from trivial, something that will not happen with a registry. > > The difficulty with OIDs (or other complex variable sized objects) > is not in sending/emitting them, but in receiving/parsing them. > The code to produce a meaningful error message for an unrecognized > value is trivial for a scalar integer value and complex for an OID > (to produce an error message that can be copy&pasted into google). Oh, and don't forget the NULL vs. empty parameters problem. Wonder how much code gets that wrong... Probably LOTS. -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B373A6866 for ; Tue, 11 Jan 2011 19:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnV-WLcBokoj for ; Tue, 11 Jan 2011 19:10:33 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 9A41B3A6892 for ; Tue, 11 Jan 2011 19:10:33 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id F1C17C4B0; Tue, 11 Jan 2011 22:12:50 -0500 (EST) Date: Tue, 11 Jan 2011 22:12:50 -0500 (EST) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1294800660.4455.41.camel@mattlaptop2.local> Message-ID: References: <1294800660.4455.41.camel@mattlaptop2.local> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 03:10:34 -0000 On Tue, 11 Jan 2011, Matt McCutchen wrote: > I thought I would mention, for those not already aware, that Dan > Kaminsky has a prototype client for a DANE-like system; he just picked a > record format. The client is called Phreeload, part of the Phreebird > Suite (http://dankaminsky.com/phreebird/). I have been playing with it > and have added the necessary record at mattmccutchen.net . It should be > pretty easy to modify Phreeload to understand whatever record format we > decide on. He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago about this. I also asked him for a somewhat more formal specification of his TXT records, though I urged him to be part of the IETF process in getting the right new RRTYPE. His fears are mostly based on old software seeing and having to configure decimal numbers for new RRTYPEs. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40C03A685A for ; Tue, 11 Jan 2011 18:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XtN2-134knT for ; Tue, 11 Jan 2011 18:48:44 -0800 (PST) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 51C673A682A for ; Tue, 11 Jan 2011 18:48:44 -0800 (PST) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id ACC1B3BC063 for ; Tue, 11 Jan 2011 18:51:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=LLCmr/J 1mJeSuMGmPpuBe83WuejWApQ6o+tgYy2Dg6fht/WmtWq1GVWQyKvuVZaMIjuLhHG q7klFlGXJf1QcKACdGgBDiCBisPP0pcht98AwZRHUwXmcdKSJVbf7PhxFcRK8sBH 08vjjinYfBejOO8Zps8Oi4KRszJqzVImtk4M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=+b+LlCCLki+uP mDHKG98iCM1DiA=; b=G1xYgLzngKLlQzmktQ9Xe2fN5VlG7zvUyLf7wg2Py+ffn BwPbDU6F9GQrsinKfeiOwAfnDl2n2XORKltk4TSbUHKeiExNLctrSrO/di18Gjqk Ow4OYs3agDZuAvu+VmmdgQI87vwv48RxJpgEqsM3fk9eRgkshNWtZeDio7nup4= Received: from [192.168.1.40] (pool-74-96-127-39.washdc.east.verizon.net [74.96.127.39]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id 451813BC059 for ; Tue, 11 Jan 2011 18:51:02 -0800 (PST) From: Matt McCutchen To: keyassure Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 Jan 2011 21:51:00 -0500 Message-ID: <1294800660.4455.41.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [keyassure] Phreeload, Dan Kaminsky's prototype client X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 02:48:47 -0000 I thought I would mention, for those not already aware, that Dan Kaminsky has a prototype client for a DANE-like system; he just picked a record format. The client is called Phreeload, part of the Phreebird Suite (http://dankaminsky.com/phreebird/). I have been playing with it and have added the necessary record at mattmccutchen.net . It should be pretty easy to modify Phreeload to understand whatever record format we decide on. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B0D3A67AD for ; Tue, 11 Jan 2011 18:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.853 X-Spam-Level: X-Spam-Status: No, score=-9.853 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6Fa2XgRd5GN for ; Tue, 11 Jan 2011 18:27:43 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D0D5F3A659A for ; Tue, 11 Jan 2011 18:27:42 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0C2Twrn022955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jan 2011 03:29:58 +0100 (MET) From: Martin Rex Message-Id: <201101120229.p0C2TvXL013730@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 12 Jan 2011 03:29:57 +0100 (MET) In-Reply-To: <4D27A3DC.8010409@vpnc.org> from "Paul Hoffman" at Jan 7, 11 03:38:04 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 02:27:44 -0000 Paul Hoffman wrote: > > On 1/7/11 3:12 PM, Warren Kumari wrote: > > > > If possible I'd like us to try and separate the discussions of "Who gets > > / how to get an identifier for an algorithm" from the question of how we > > actually identify these -- while I realize that there are > > interdependencies in the two issues and they are not fully separable, > > I'd appreciate it if we can try and separate them as much as possible so > > that it is easier to call consensus.... > > Just to be clear, my preferences are: > > - Somewhat liberal policy for assigning: "RFC published", not "IETF > consensus" or "expert review" > > - two-byte integers for identifying, with 1000 reserved for private use My preference would also be a fixed size integer. Is there a problem for a registry to contain more than a primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather something like (IntegerValue,AlgorithmName,StandardizationLevel) with StandardizationLevel values such as { required, recommended, optional, experimental, discouraged } The problem with ASN.1 OIDs is that they wasteful (in terms of code, storage network bandwidth, cpu cycles), variable-sized blobs and therefore a royal PITA to use in software. I strongly prefer switch(algorithm_cp) { case A: /* code for A */ break; case B: /* code for B */ break; case C: /* code for C */ break; default: /* produce some useful error msg about unsupported alg */ break; } to if ( 0==compare_OID(parsed_oid,A_oid) ) { /* code for A */ } else if ( 0==compare_OID(parsed_oid,B_oid) ) { /* code for B */ } else if ( 0==compare_OID(parsed_oid,C_oid) ) { /* code for C */ } else { /* produce some useful error msg about unsupported alg */ } ASN.1 OIDs in PKIX are a pain, and they're ambiguous. e.g. for RSA there seem to be two(!) OIDs in use in X.509, something which is not going to happen with a single registry: 2.5.8.1.1 1.2.840.113549.1.1.1 Finding out the meaning of an OID you do _not_ happen to know is far from trivial, something that will not happen with a registry. The difficulty with OIDs (or other complex variable sized objects) is not in sending/emitting them, but in receiving/parsing them. The code to produce a meaningful error message for an unrecognized value is trivial for a scalar integer value and complex for an OID (to produce an error message that can be copy&pasted into google). Phillip Hallam-Baker wrote: > > Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the > packaging format. > > So it really is unavoidable. This information appears outdated. The PKCS#1 v1.5 signature scheme was actually tightened up in PKCS#1 v2.1 to completely obviate the royal PITA part of ASN.1, the _parsing_: http://tools.ietf.org/html/rfc3447#section-9.2 And an implementation is likely to not even attempt to decrypt the PKCS#1 signature blob if it does not recognize the RSA-based signature AlgID accompanying it... -Martin Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B602128C11E for ; Tue, 11 Jan 2011 04:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvhGTpp2MGTV for ; Tue, 11 Jan 2011 04:33:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 5AC2E28C0EE for ; Tue, 11 Jan 2011 04:33:43 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 2E610734376 for ; Tue, 11 Jan 2011 13:35:59 +0100 (CET) Message-ID: <4D2C4EAE.3070509@nic.cz> Date: Tue, 11 Jan 2011 13:35:58 +0100 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Apology... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 12:33:44 -0000 Hi all, I'm joining with the appology. I had a long deserved vacation during end of the year and then I had to focus my attention on the work and some stuff in my personal life. This was resolved yesterday and I should have some more time. I'll try to dig through the tons of emails this week. Ondrej On 5.1.2011 00:46, Warren Kumari wrote: > Hi all, > > I'd just quickly like to apologize for not having been nearly as > involved recently as I should have been -- I got sidetracked with > $dayjob (and other things) and haven't been giving DANE as much > attention as it deserves. > > I have almost managed to clean off my plate (and dig out from under a > mountain of mail) and should be able to devote more time soon... > > Apologies again, > W > > -- > "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) > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0009F3A6839 for ; Mon, 10 Jan 2011 11:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FzZd4E4yFEL for ; Mon, 10 Jan 2011 11:09:26 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 095573A6823 for ; Mon, 10 Jan 2011 11:09:26 -0800 (PST) Received: (qmail 15481 invoked by uid 0); 10 Jan 2011 19:11:40 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 10 Jan 2011 19:11:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TRO/FjHqi1Sn2TV251QQ8Hl1iKntb5P0op/qoZ+hwXV8dWI16cuc7lMbuezinPNUFcfNQaQ4ofRUQvdtJxXW/Ea9c7zDgUQWL7zhfIwR2BaM3I/B29iJjELodSDyh6hu; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.153]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PcN9Y-0006cb-9Y for keyassure@ietf.org; Mon, 10 Jan 2011 12:11:40 -0700 Message-ID: <4D2B59EB.1070705@KingsMountain.com> Date: Mon, 10 Jan 2011 11:11:39 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF DANE WG list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:09:27 -0000 PaulH replied.. > > On 1/7/11 3:12 PM, Warren Kumari wrote: > >> If possible I'd like us to try and separate the discussions of "Who gets >> / how to get an identifier for an algorithm" from the question of how we >> actually identify these -- while I realize that there are >> interdependencies in the two issues and they are not fully separable, >> I'd appreciate it if we can try and separate them as much as possible so >> that it is easier to call consensus.... > > Just to be clear, my preferences are: > > - Somewhat liberal policy for assigning: "RFC published", not "IETF > consensus" or "expert review" > > - two-byte integers for identifying, with 1000 reserved for private use +1 altho we could probably get by with just one octet for hash alg identifiers, I wouldn't go to the mat over having two. HTH, =JeffH Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33403A6810 for ; Sun, 9 Jan 2011 12:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JliTy7QkxoMs for ; Sun, 9 Jan 2011 12:16:44 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by core3.amsl.com (Postfix) with ESMTP id 005B13A67D4 for ; Sun, 9 Jan 2011 12:16:42 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh06-2.mail.saunalahti.fi (Postfix) with SMTP id 3FE5EC7ECE; Sun, 9 Jan 2011 22:18:53 +0200 (EET) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A07D6402BB2; Sun, 09 Jan 2011 22:18:53 +0200 Received: from LK-Perkele-VI (a88-112-56-215.elisa-laajakaista.fi [88.112.56.215]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 96A19158A64; Sun, 9 Jan 2011 22:18:49 +0200 (EET) Date: Sun, 9 Jan 2011 22:19:16 +0200 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20110109201916.GA26324@LK-Perkele-VI.localdomain> References: <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:16:44 -0000 On Sun, Jan 09, 2011 at 12:06:16AM -0500, Phillip Hallam-Baker wrote: > Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the > packaging format. > > So it really is unavoidable. I agree that it is _currently_ unavoidable, but I don't agree that it is _fundamental_ requirement of TLS. I.e. it may be avoidable in future (even without a new TLS version)! Based on my reading of relevant RFCs: The only reason (partial) ASN.1 decoding is _currently_ unavoidable for a TLS v1.2 client is lack of ASN.1-free raw key format[*]. Define a ASN.1-free raw key format, get codepoint for it (IETF consensus) and this goes away. Bonus points for new SignatureAlgorithm that is ASN.1-free RSA (specification required). The existing RSA there is PKCS#1 v1.5 anyway... [*] You hit PKCS#1 signature verification in implementing OpenPGP (to handle the case where primary key is RSA). -Ilari Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26D43A691D for ; Sat, 8 Jan 2011 21:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXLT+BcBD1fN for ; Sat, 8 Jan 2011 21:04:07 -0800 (PST) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id 34C2F3A6916 for ; Sat, 8 Jan 2011 21:04:07 -0800 (PST) Received: by gyf1 with SMTP id 1so3964937gyf.1 for ; Sat, 08 Jan 2011 21:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=f+hn/7d+VrzAK+oLEIyTixkKHyKIvDilWK29ZPrIUV0=; b=rWD2aEwfpYkcoTHFhWn5jMkWZ9f3jzfDHe8L5/dxPVaVgwi+ndAmWEaSxXYgTMrRVz ynshH3wLK0CIDwPmo0k7WdDewilIcLwf5P+DruK0a7LLgJhuhYdeu2xxglVHEU4ok77i 81VgkkDhEWxXpZ8aatHLTwD4DZhGb20XpLsfs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MgOTsEe+JMD6wblYyWYmnQbyMTxADI/QIfKbkzDZcrOOxgGczYyNwQsRHexy1nSOev +oE3Eg+/l4V+maBuTvayqffktg5Kv2/y23SnJ6BH30+wxF6yBgKrc7F6pZXlPhUqgJ33 cVyIr/gHSC5ptknfuD0djO38Loh3YkcoG5COY= MIME-Version: 1.0 Received: by 10.100.255.4 with SMTP id c4mr1096455ani.205.1294549576807; Sat, 08 Jan 2011 21:06:16 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 21:06:16 -0800 (PST) In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> Date: Sun, 9 Jan 2011 00:06:16 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016368e1bf0ab73ec049962cf35 Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 05:04:08 -0000 --0016368e1bf0ab73ec049962cf35 Content-Type: text/plain; charset=ISO-8859-1 Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the packaging format. So it really is unavoidable. You can fake it of course (most people do in fact) but that is exactly what I suggested for ODI If we adopt Warren's suggestion then we only need one byte since we can always use ODIs if the registry is exhausted. Having seen the mess caused by the decision to use 4 byte IP addresses, I am not keen to see a repeat. And contrary to what some may claim there were several people who pointed out that 4 billion addresses was too small at the time the decision was taken. On Sat, Jan 8, 2011 at 11:38 PM, Paul Wouters wrote: > On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote: > > Here you are interfacing to PKIX which is an ASN.1 spec. >> > > Not only. Once bare public key TLS support is there, things could move > towards a full drop of ASN.1/PKIX. > > In fact, one could argue one of the reasons we need DANE is to fix > limitations in PKIX, and the DANE spec is more then happy to provide > side benefits to the PKIX community to help address those limitations, > but DANE is clearly not a subset of PKIX protocols. > > > And in the >> unlikely event that we did people can read the full ASN.1 documentation >> that explains exactly what to do.] >> > > Problems, not solutions, start with the phrase "read the full ASN.1 > documentation". > > Paul > -- Website: http://hallambaker.com/ --0016368e1bf0ab73ec049962cf35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the p= ackaging format.

So it really is unavoidable.=A0

You can fake it of course (most people do in fact) but th= at is exactly what I suggested for ODI


If we adopt Warren's suggestion then= we only need one byte since we can always use ODIs if the registry is exha= usted.


Having seen the mess caused = by the decision to use 4 byte IP addresses, I am not keen to see a repeat. = And contrary to what some may claim there were several people who pointed o= ut that 4 billion addresses was too small at the time the decision was take= n.


On Sat, Jan 8, 2011 at 11:38 PM, Pa= ul Wouters <paul= @xelerance.com> wrote:
On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote:

Here you are interfacing to PKIX which is an ASN.1 spec.

Not only. Once bare public key TLS support is there, things could move
towards a full drop of ASN.1/PKIX.

In fact, one could argue one of the reasons we need DANE is to fix
limitations in PKIX, and the DANE spec is more then happy to provide
side benefits to the PKIX community to help address those limitations,
but DANE is clearly not a subset of PKIX protocols.


And in the
unlikely event that we did people can read the full ASN.1 documentation tha= t explains exactly what to do.]

Problems, not solutions, start with the phrase "read the full ASN.1 do= cumentation".

Paul



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

--0016368e1bf0ab73ec049962cf35-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762B33A6910 for ; Sat, 8 Jan 2011 20:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+Oc6l4qDUIN for ; Sat, 8 Jan 2011 20:36:12 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 589693A68BA for ; Sat, 8 Jan 2011 20:36:12 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 7E8E3C509; Sat, 8 Jan 2011 23:38:21 -0500 (EST) Date: Sat, 8 Jan 2011 23:38:21 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 04:36:13 -0000 On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote: > Here you are interfacing to PKIX which is an ASN.1 spec. Not only. Once bare public key TLS support is there, things could move towards a full drop of ASN.1/PKIX. In fact, one could argue one of the reasons we need DANE is to fix limitations in PKIX, and the DANE spec is more then happy to provide side benefits to the PKIX community to help address those limitations, but DANE is clearly not a subset of PKIX protocols. > And in the > unlikely event that we did people can read the full ASN.1 documentation that explains exactly what to do.] Problems, not solutions, start with the phrase "read the full ASN.1 documentation". Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329EB3A6910 for ; Sat, 8 Jan 2011 20:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlCS2DbWWM5q for ; Sat, 8 Jan 2011 20:21:43 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0E8E93A6817 for ; Sat, 8 Jan 2011 20:21:43 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 66375C509; Sat, 8 Jan 2011 23:23:51 -0500 (EST) Date: Sat, 8 Jan 2011 23:23:50 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <1294497295.1886.8.camel@mattlaptop2.local> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 04:21:44 -0000 On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote: > The problem with attempting to re-use the DNSSEC registries is that > the DNSEXT people presumably chose to have their own registry so as to > have control themselves. Is that really the reason? > What happens if we want to use an algorithm and they do not? Who is "we" and who is "they"? DANE is about validating crypto identities via DNS? That means "we" are "they". If I take all the SHA1 and SHA2 and SHA3 candidates, we end up with what? 25 hashing algorithms in 25 years? So one byte would give us about 200 years? Add a few new container formats (eg bare public key, and some x.509 v4+ or something) and I still don't see this hitting 256. Though I guess one more byte to be super safe would not hurt either. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C003A6817 for ; Sat, 8 Jan 2011 11:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI3Enp5KY03X for ; Sat, 8 Jan 2011 11:37:57 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 756993A6818 for ; Sat, 8 Jan 2011 11:37:57 -0800 (PST) Received: by gyd12 with SMTP id 12so7807493gyd.31 for ; Sat, 08 Jan 2011 11:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KMTFXzjzFgqhegKijq90WmOZoZJFr57bKATUQ0Lcwuc=; b=rqaQeXaf2hkbTjbywPrWiZFOjMXnReIKzd++lI7zQuyo7HmUyXPeNWXLUzT9v2v2p+ YZC125z0HKC6wckz59dV28RBta4WxwdK88BWtGN5dZ+gMxMPmriHuL9ZHg1WwBSZoAsh sXDRLVTc7rLiR3f3CybyrXnF8saFAaPIQUQIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GbpiQJZIIeCIpXAG7TXKGfsTGAXDDuCWKPxzS5xBHaoMGs7B+CqThDlFsGzbYkLdYv n7HsjJ9y8qMW9N1hqAy/y9p4T85SHCtrOSQbsNpoXjVTiOqR/LUb5z3k41XDNhGKGmRE ufi2Ufa4kw44zARMtIsSojLaVezzguIrkUSE8= MIME-Version: 1.0 Received: by 10.100.93.6 with SMTP id q6mr3887804anb.69.1294515605556; Sat, 08 Jan 2011 11:40:05 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 11:40:05 -0800 (PST) In-Reply-To: <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> Date: Sat, 8 Jan 2011 14:40:05 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=0016e6434bced34d8b04995ae687 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:37:59 -0000 --0016e6434bced34d8b04995ae687 Content-Type: text/plain; charset=ISO-8859-1 OK if that is your proposal, I will take the code point 30 12 for an ODI reference minus the initial ASN.1 SEQ identifier (30 12). On Sat, Jan 8, 2011 at 2:04 PM, Warren Kumari wrote: > > Boys! Please... > > > > Ok, so I'm proposing a compromise here as a third option. As this is a > compromise, I'm assuming no-one will love it, but maybe folk will be willing > to accept it... > > We ask the IANA to create us a registry (I'm proposing 2 octet codespace, > with some portion chopped out for experimental values -- this gives us >65k > usable values (and I don't want to live in a world where we approach that > :-P), but that's just a thought). ODI can be assigned a value from this > space, and once / if everyone discovers that they like it, folk will no > longer bother trying to get assignments from our registry, which would > remove the "registering new values" burden from the IANA. > > > The obvious downsides are: > 1: If ODI becomes the standard that everyone converges on, we will have > burnt 16 bits for nothing. > 2: In instances where ODI is used the "payload" will not be in the same > place in the structure. Implementations that do not support ODI obviously > just treat these as they would any other case where they do not understand > the identified algorithm / registered value.... > > The parsing for this is simple (in c-ish psudocode): > switch (dane_struct->codepoint) { > case CP_SHA_256: > handle_sha256(dane_struct); > break; > case CP_SHA_512: > handle_sha512(dane_struct); > break; > #ifdef HAVE_ODI > case_CP_ODI: > handle_odi(dane_struct); > break; > #endif > case default: > debug("Not yet supported algorithm number: ", dane_struct->codepoint); > break; > } > > > To my mind, these downsides are minor... Thoughts? > > W > > > > > On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote: > > On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote: >> >>> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman >> > wrote: >>> >>> On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote: >>> >>> Since this is precisely the type of change that KEYPROV was >>> required >>> to make during IESG review, I would have to disagree. >>> >>> We had specified our own password string prep, we were told we >>> had to >>> use the existing string prep from another spec. >>> >>> >>> The "precisely" in the first paragraph completely disagrees with the >>> second paragraph. The format of the identifier is completely >>> dissimilar from a modification of a difficult internationalization >>> process. >>> >>> >>> No, it was a change the WG debated at considerable length when there was >>> no need to as it was not a decision it should have made. >>> >> >> Then you should blame the WG chairs (you were one of them). >> >> That's fine for you to predict, but I predict differently. I think >>> if we choose either a short numeric identifier (as is already used >>> in most DNS protocols) or an OID (as is already used in PKIX and >>> S/MIME), the IESG will be fine. >>> >>> >>> We also had a draft written by the current IETF chair and one of the >>> IETF Security Area directors that converted all our XML formats into >>> ASN.1. The other Security AD told us to add it as a WG item. >>> >> >> Correct. If this WG was considering having our algorithm identifiers as >> XML structures, we might have the same. Fortunately, we don't. >> >> Have you any idea how much the security area likes ASN.1? >>> >> >> Having written a handful of Security Area RFCs that use ASN.1: yes, I do. >> >> Here you are interfacing to PKIX which is an ASN.1 spec. >>> >> >> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with PKIX in a >> similar fashion, and neither are in ASN.1 format. To the best of my >> knowledge, no one ever suggested that they should be. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >> > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e6434bced34d8b04995ae687 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK if that is your proposal, I will take the code point 30 12 for an ODI re= ference minus the initial ASN.1 SEQ identifier (30 12).

=

On Sat, Jan 8, 2011 at 2= :04 PM, Warren Kumari <warren@kumari.net> wrote:
<chair hat>
Boys! Please...
</chair hat>

<no hat>
Ok, so I'm proposing a compromise here as a third option. As this is a = compromise, I'm assuming no-one will love it, but maybe folk will be wi= lling to accept it...

We ask the IANA to create us a registry (I'm proposing 2 octet codespac= e, with some portion chopped out for experimental values -- this gives us &= gt;65k usable values (and I don't want to live in a world where we appr= oach that :-P), but that's just a thought). ODI can be assigned a value= from this space, and once / if everyone discovers that they like it, folk = will no longer bother trying to get assignments from our registry, which wo= uld remove the "registering new values" burden from the IANA.


The obvious downsides are:
1: If ODI becomes the standard that everyone converges on, =A0we will have = burnt 16 bits for nothing.
2: In instances where ODI is used the "payload" will not be in th= e same place in the structure. Implementations that do not support ODI obvi= ously just treat these as they would any other case where they do not under= stand the identified algorithm / registered value....

The parsing for this is simple (in c-ish psudocode):
switch (dane_struct->codepoint) {
=A0case =A0CP_SHA_256:
=A0 =A0 =A0handle_sha256(dane_struct);
=A0 =A0 =A0break;
=A0case CP_SHA_512:
=A0 =A0 =A0handle_sha512(dane_struct);
=A0 =A0 =A0break;
#ifdef HAVE_ODI
=A0case_CP_ODI:
=A0 =A0 =A0handle_odi(dane_struct);
=A0 =A0 =A0break;
#endif
=A0case default:
=A0 =A0 =A0debug("Not yet supported algorithm number: ", dane_st= ruct->codepoint);
=A0 =A0 =A0break;
}


To my mind, these downsides are minor... Thoughts?

W
</no hat>



On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:

On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <paul.hoffman@vpnc.org
<mailto:paul.= hoffman@vpnc.org>> wrote:

=A0 On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:

=A0 =A0 =A0 Since this is precisely the type of change that KEYPROV was re= quired
=A0 =A0 =A0 to make during IESG review, I would have to disagree.

=A0 =A0 =A0 We had specified our own password string prep, we were told we=
=A0 =A0 =A0 had to
=A0 =A0 =A0 use the existing string prep from another spec.


=A0 The "precisely" in the first paragraph completely disagrees = with the
=A0 second paragraph. The format of the identifier is completely
=A0 dissimilar from a modification of a difficult internationalization
=A0 process.


No, it was a change the WG debated at considerable length when there was no need to as it was not a decision it should have made.

Then you should blame the WG chairs (you were one of them).

=A0 That's fine for you to predict, but I predict differently. I think=
=A0 if we choose either a short numeric identifier (as is already used
=A0 in most DNS protocols) or an OID (as is already used in PKIX and
=A0 S/MIME), the IESG will be fine.


We also had a draft written by the current IETF chair and one of the
IETF Security Area directors that converted all our XML formats into
ASN.1. The other Security AD told us to add it as a WG item.

Correct. If this WG was considering having our algorithm identifiers as XML= structures, we might have the same. Fortunately, we don't.

Have you any idea how much the security area likes ASN.1?

Having written a handful of Security Area RFCs that use ASN.1: yes, I do.
Here you are interfacing to PKIX which is an ASN.1 spec.

So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with = PKIX in a similar fashion, and neither are in ASN.1 format. To the best of = my knowledge, no one ever suggested that they should be.
_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure

_______________________________________________
keyassure mailing list
keyassure@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e6434bced34d8b04995ae687-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27913A6810 for ; Sat, 8 Jan 2011 11:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-eRCv9+vcak for ; Sat, 8 Jan 2011 11:21:06 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id B51733A680F for ; Sat, 8 Jan 2011 11:21:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=pT3Ov8ypUgn9V1cQEBjTG9OKt+bd9jIOsJXPXpLe4sjWEgXz6AirccVmyasXwuwy; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1PbeNc-0004UB-K9; Sat, 08 Jan 2011 14:23:12 -0500 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sat, 8 Jan 2011 14:23:12 -0500 Message-ID: <9761708.1294514592532.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Sat, 8 Jan 2011 13:23:12 -0600 (GMT-06:00) From: "Jeffrey A. Williams" To: Warren Kumari , Paul Hoffman Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606886f93d9a075ea8c61ef2dba0870f153f0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:21:08 -0000 warren and all, Good compermise third option IMO. Kindest Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 IT/network security Eng. SR. Eng. Network data security, IT/information and web security. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 -----Original Message----- >From: Warren Kumari >Sent: Jan 8, 2011 1:04 PM >To: Paul Hoffman >Cc: keyassure@ietf.org >Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." > > >Boys! Please... > > > >Ok, so I'm proposing a compromise here as a third option. As this is a >compromise, I'm assuming no-one will love it, but maybe folk will be >willing to accept it... > >We ask the IANA to create us a registry (I'm proposing 2 octet >codespace, with some portion chopped out for experimental values -- >this gives us >65k usable values (and I don't want to live in a world >where we approach that :-P), but that's just a thought). ODI can be >assigned a value from this space, and once / if everyone discovers >that they like it, folk will no longer bother trying to get >assignments from our registry, which would remove the "registering new >values" burden from the IANA. > > >The obvious downsides are: >1: If ODI becomes the standard that everyone converges on, we will >have burnt 16 bits for nothing. >2: In instances where ODI is used the "payload" will not be in the >same place in the structure. Implementations that do not support ODI >obviously just treat these as they would any other case where they do >not understand the identified algorithm / registered value.... > >The parsing for this is simple (in c-ish psudocode): >switch (dane_struct->codepoint) { > case CP_SHA_256: > handle_sha256(dane_struct); > break; > case CP_SHA_512: > handle_sha512(dane_struct); > break; >#ifdef HAVE_ODI > case_CP_ODI: > handle_odi(dane_struct); > break; >#endif > case default: > debug("Not yet supported algorithm number: ", dane_struct- > >codepoint); > break; >} > > >To my mind, these downsides are minor... Thoughts? > >W > > > >On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote: > >> On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote: >>> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman >> > wrote: >>> >>> On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote: >>> >>> Since this is precisely the type of change that KEYPROV was >>> required >>> to make during IESG review, I would have to disagree. >>> >>> We had specified our own password string prep, we were told we >>> had to >>> use the existing string prep from another spec. >>> >>> >>> The "precisely" in the first paragraph completely disagrees with >>> the >>> second paragraph. The format of the identifier is completely >>> dissimilar from a modification of a difficult internationalization >>> process. >>> >>> >>> No, it was a change the WG debated at considerable length when >>> there was >>> no need to as it was not a decision it should have made. >> >> Then you should blame the WG chairs (you were one of them). >> >>> That's fine for you to predict, but I predict differently. I think >>> if we choose either a short numeric identifier (as is already used >>> in most DNS protocols) or an OID (as is already used in PKIX and >>> S/MIME), the IESG will be fine. >>> >>> >>> We also had a draft written by the current IETF chair and one of the >>> IETF Security Area directors that converted all our XML formats into >>> ASN.1. The other Security AD told us to add it as a WG item. >> >> Correct. If this WG was considering having our algorithm identifiers >> as XML structures, we might have the same. Fortunately, we don't. >> >>> Have you any idea how much the security area likes ASN.1? >> >> Having written a handful of Security Area RFCs that use ASN.1: yes, >> I do. >> >>> Here you are interfacing to PKIX which is an ASN.1 spec. >> >> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with >> PKIX in a similar fashion, and neither are in ASN.1 format. To the >> best of my knowledge, no one ever suggested that they should be. >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > >_______________________________________________ >keyassure mailing list >keyassure@ietf.org >https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F803A6810 for ; Sat, 8 Jan 2011 11:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.696 X-Spam-Level: X-Spam-Status: No, score=-101.696 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ8D0o1B5sDi for ; Sat, 8 Jan 2011 11:11:20 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E1A893A680F for ; Sat, 8 Jan 2011 11:11:20 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p08JDSIR084771 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 8 Jan 2011 12:13:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D28B758.7080801@vpnc.org> Date: Sat, 08 Jan 2011 11:13:28 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> In-Reply-To: <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:11:22 -0000 On 1/8/11 11:04 AM, Warren Kumari wrote: > Ok, so I'm proposing a compromise here as a third option. As this is a > compromise, I'm assuming no-one will love it, but maybe folk will be > willing to accept it... If that's the way you think the consensus is going, that's fine. I didn't see it going that way. Phill had one proposal with (possibly one) person behind it. I had another with a small handful behind it. Others had not weighed in yet. Of the now three proposals for the format, I still feel that "a two-octet number" is better than ODI or a mixture of the two, FWIW. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7B93A6805 for ; Sat, 8 Jan 2011 11:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptKb4gWxeGyP for ; Sat, 8 Jan 2011 11:02:56 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id ADFF43A680F for ; Sat, 8 Jan 2011 11:02:53 -0800 (PST) Received: from [192.168.0.227] (unknown [64.13.52.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id DC2FE228454C; Sat, 8 Jan 2011 14:05:00 -0500 (EST) Message-Id: <304A0AAD-9A3B-41C0-8A78-5176C2970517@kumari.net> From: Warren Kumari To: Paul Hoffman In-Reply-To: <4D28A057.7040708@vpnc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 8 Jan 2011 14:04:59 -0500 References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> <4D28A057.7040708@vpnc.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 19:02:58 -0000 Boys! Please... Ok, so I'm proposing a compromise here as a third option. As this is a compromise, I'm assuming no-one will love it, but maybe folk will be willing to accept it... We ask the IANA to create us a registry (I'm proposing 2 octet codespace, with some portion chopped out for experimental values -- this gives us >65k usable values (and I don't want to live in a world where we approach that :-P), but that's just a thought). ODI can be assigned a value from this space, and once / if everyone discovers that they like it, folk will no longer bother trying to get assignments from our registry, which would remove the "registering new values" burden from the IANA. The obvious downsides are: 1: If ODI becomes the standard that everyone converges on, we will have burnt 16 bits for nothing. 2: In instances where ODI is used the "payload" will not be in the same place in the structure. Implementations that do not support ODI obviously just treat these as they would any other case where they do not understand the identified algorithm / registered value.... The parsing for this is simple (in c-ish psudocode): switch (dane_struct->codepoint) { case CP_SHA_256: handle_sha256(dane_struct); break; case CP_SHA_512: handle_sha512(dane_struct); break; #ifdef HAVE_ODI case_CP_ODI: handle_odi(dane_struct); break; #endif case default: debug("Not yet supported algorithm number: ", dane_struct- >codepoint); break; } To my mind, these downsides are minor... Thoughts? W On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote: > On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote: >> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman > > wrote: >> >> On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote: >> >> Since this is precisely the type of change that KEYPROV was >> required >> to make during IESG review, I would have to disagree. >> >> We had specified our own password string prep, we were told we >> had to >> use the existing string prep from another spec. >> >> >> The "precisely" in the first paragraph completely disagrees with >> the >> second paragraph. The format of the identifier is completely >> dissimilar from a modification of a difficult internationalization >> process. >> >> >> No, it was a change the WG debated at considerable length when >> there was >> no need to as it was not a decision it should have made. > > Then you should blame the WG chairs (you were one of them). > >> That's fine for you to predict, but I predict differently. I think >> if we choose either a short numeric identifier (as is already used >> in most DNS protocols) or an OID (as is already used in PKIX and >> S/MIME), the IESG will be fine. >> >> >> We also had a draft written by the current IETF chair and one of the >> IETF Security Area directors that converted all our XML formats into >> ASN.1. The other Security AD told us to add it as a WG item. > > Correct. If this WG was considering having our algorithm identifiers > as XML structures, we might have the same. Fortunately, we don't. > >> Have you any idea how much the security area likes ASN.1? > > Having written a handful of Security Area RFCs that use ASN.1: yes, > I do. > >> Here you are interfacing to PKIX which is an ASN.1 spec. > > So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with > PKIX in a similar fashion, and neither are in ASN.1 format. To the > best of my knowledge, no one ever suggested that they should be. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A753A67EA for ; Sat, 8 Jan 2011 09:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.694 X-Spam-Level: X-Spam-Status: No, score=-101.694 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YMRcB99A7Rv for ; Sat, 8 Jan 2011 09:33:15 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8CD043A67E4 for ; Sat, 8 Jan 2011 09:33:12 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p08HZKbd082099 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 8 Jan 2011 10:35:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D28A057.7040708@vpnc.org> Date: Sat, 08 Jan 2011 09:35:19 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:33:17 -0000 On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote: > On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman > wrote: > > On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote: > > Since this is precisely the type of change that KEYPROV was required > to make during IESG review, I would have to disagree. > > We had specified our own password string prep, we were told we > had to > use the existing string prep from another spec. > > > The "precisely" in the first paragraph completely disagrees with the > second paragraph. The format of the identifier is completely > dissimilar from a modification of a difficult internationalization > process. > > > No, it was a change the WG debated at considerable length when there was > no need to as it was not a decision it should have made. Then you should blame the WG chairs (you were one of them). > That's fine for you to predict, but I predict differently. I think > if we choose either a short numeric identifier (as is already used > in most DNS protocols) or an OID (as is already used in PKIX and > S/MIME), the IESG will be fine. > > > We also had a draft written by the current IETF chair and one of the > IETF Security Area directors that converted all our XML formats into > ASN.1. The other Security AD told us to add it as a WG item. Correct. If this WG was considering having our algorithm identifiers as XML structures, we might have the same. Fortunately, we don't. > Have you any idea how much the security area likes ASN.1? Having written a handful of Security Area RFCs that use ASN.1: yes, I do. > Here you are interfacing to PKIX which is an ASN.1 spec. So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with PKIX in a similar fashion, and neither are in ASN.1 format. To the best of my knowledge, no one ever suggested that they should be. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4D728C131 for ; Sat, 8 Jan 2011 08:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofoSLPsZG3MI for ; Sat, 8 Jan 2011 08:35:11 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 0478828C11E for ; Sat, 8 Jan 2011 08:35:10 -0800 (PST) Received: by gxk28 with SMTP id 28so8467162gxk.31 for ; Sat, 08 Jan 2011 08:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xdj/5PzT2QC5GXVgIvFPNPWgcDI3SLzR3+7xZhWz5Uo=; b=ldl3zibbriBCKVIdBgU2OvJcrtwUcu+aTbYiUw8vl7hJAiEeYDtPQ884AVCJRj11YW BLa8zEqVlUKP38SuNc26wh68zqtSVCczGAZxLsWOkeG54WUoGRgNaWqwC2CM2/iXnwVE XfkPjRJpFDnr6fhS0ssi4J3vliz6XRvXwULlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wxOt1AyVJPHqBuNGq0DPIPjnNiqpqYMcoyu8PbIdgsM3mUl9YCxh2iWXXbo1INHiSH ixClwI+zXUa64B/tj5Jti14Ox2HMEJ0HxKq7b+JGBuZGQ0UU2n0z0EBaBU/tVK0b4D4V 3hQq3APrYg1gx0MqJKK6R/9NvyYB3k8YeE67c= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2490132ane.171.1294504638837; Sat, 08 Jan 2011 08:37:18 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:37:18 -0800 (PST) In-Reply-To: <4D288E65.5000608@vpnc.org> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <4D288E65.5000608@vpnc.org> Date: Sat, 8 Jan 2011 11:37:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e644dbc62875f904995859fe Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:35:13 -0000 --0016e644dbc62875f904995859fe Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman wrote: > On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote: > >> Since this is precisely the type of change that KEYPROV was required >> to make during IESG review, I would have to disagree. >> >> We had specified our own password string prep, we were told we had to >> use the existing string prep from another spec. >> > > The "precisely" in the first paragraph completely disagrees with the second > paragraph. The format of the identifier is completely dissimilar from a > modification of a difficult internationalization process. No, it was a change the WG debated at considerable length when there was no need to as it was not a decision it should have made. That's fine for you to predict, but I predict differently. I think if we > choose either a short numeric identifier (as is already used in most DNS > protocols) or an OID (as is already used in PKIX and S/MIME), the IESG will > be fine. We also had a draft written by the current IETF chair and one of the IETF Security Area directors that converted all our XML formats into ASN.1. The other Security AD told us to add it as a WG item. Have you any idea how much the security area likes ASN.1? Here you are interfacing to PKIX which is an ASN.1 spec. > As for the negatives on OIDs, your description of how to encode ODIs is, so > far, incomplete (hint: large integers), so even you can't say how easy or > hard it is. > > Another difference is that when I make a technical point I make a technical point rather than asking people to play guessing games. If you have a point then make your point. Hint: You don't exactly have the standing in the field to be condescending towards others. As it is you seem to be criticizing me for not explaining how to handle an edge case that could not possibly occur unless our entire understanding of crypto suddenly changed. [Since the output of all currently used digest algorithms is fixed, an implementation that supports a fixed number of digest algorithms is not going to require any length greater than 127 bytes and thus the large integer issue would never occur. Furthermore, unless there are unexpected developments in computing we really should not be expecting to use digests of more than 256 bits. And in the unlikely event that we did people can read the full ASN.1 documentation that explains exactly what to do.] -- Website: http://hallambaker.com/ --0016e644dbc62875f904995859fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jan 8, 2011 at 11:18 AM, Paul Ho= ffman <paul.h= offman@vpnc.org> wrote:
On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
Since this is precisely the type of change that KEYPROV was required
to make during IESG review, I would have to disagree.

We had specified our own password string prep, we were told we had to
use the existing string prep from another spec.

The "precisely" in the first paragraph completely disagrees with = the second paragraph. The format of the identifier is completely dissimilar= from a modification of a difficult internationalization process.

No, it was a change the WG debated at considerable leng= th when there was no need to as it was not a decision it should have made.<= /div>

That's fine for you to predict, but I predict differently. I think if w= e choose either a short numeric identifier (as is already used in most DNS = protocols) or an OID (as is already used in PKIX and S/MIME), the IESG will= be fine.

We also had a draft written by the current IETF chair a= nd one of the IETF Security Area directors that converted all our XML forma= ts into ASN.1.=A0The other Security AD told us to add it as a WG item.

Have you any idea how much the security area likes ASN.= 1?

Here you are interfacing to PKIX which is an AS= N.1 spec.


=A0
As for the negatives on OIDs, your description of how to encode ODIs is, so= far, incomplete (hint: large integers), so even you can't say how easy= or hard it is.


Another difference is that when I make a technical poin= t I make a technical point rather than asking people to play guessing games= .

If you have a point then make your point.=A0

Hint: You don't exactly have the standing in the fi= eld to be condescending towards others.

As it is y= ou seem to be criticizing me for not explaining how to handle an edge case = that could not possibly occur unless our entire understanding of crypto sud= denly changed.


[Since the output of all currently used = digest algorithms is fixed, an implementation that supports a fixed number = of digest algorithms is not going to require any length greater than 127 by= tes and thus the large integer issue would never occur.

Furthermore, unless there are unexpected developments i= n computing we really should not be expecting to use digests of more than 2= 56 bits. And in the unlikely event that we did people can read the full ASN= .1 documentation that explains exactly what to do.]

--
Website: http://hallam= baker.com/

--0016e644dbc62875f904995859fe-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2CE3A6975 for ; Sat, 8 Jan 2011 08:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.692 X-Spam-Level: X-Spam-Status: No, score=-101.692 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMw765ECEy2f for ; Sat, 8 Jan 2011 08:16:37 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C2D233A691E for ; Sat, 8 Jan 2011 08:16:37 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p08GIiH0079299 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 8 Jan 2011 09:18:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D288E65.5000608@vpnc.org> Date: Sat, 08 Jan 2011 08:18:45 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:16:38 -0000 On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote: > Since this is precisely the type of change that KEYPROV was required > to make during IESG review, I would have to disagree. > > We had specified our own password string prep, we were told we had to > use the existing string prep from another spec. The "precisely" in the first paragraph completely disagrees with the second paragraph. The format of the identifier is completely dissimilar from a modification of a difficult internationalization process. >> From a process point of view I think that the chances of being told to > move from ASN.1 to a custom registry are essentially 0% while the > chance of being told to move from a custom registry to ASN.1 is > approximately 50:50% That's fine for you to predict, but I predict differently. I think if we choose either a short numeric identifier (as is already used in most DNS protocols) or an OID (as is already used in PKIX and S/MIME), the IESG will be fine. > Proliferating crypto registries imposes a cost on the whole > organization. It is making busy-work that is not necessary. And yet IETF WGs do it on a regular basis, with the full approval of the IESG. > The point of working in the IETF as opposed to doing a roll your own > standards organization is meant to be building on the work of others. > ODI is designed to be a re-usable building block that can be used in > other places. It builds on ASN.1 which is itself a frequently used > building block that is essentially a standard in the crypto world. ...and yet your ODI proposal, which you brought to many WGs, has garnered almost no support. > So far I have given concrete benefits for my design choices. In > contrast the opposition has been 'well I prefer' without giving actual > benefits. The fact that you don't like the actual benefits that we have listed repeatedly doesn't mean we didn't give them. > The nearest we got was Paul's rather silly claim that ODI is > difficult to code (false) and the vague idea that having a registry > puts you in control. That is not a vague idea: it is one that is embraced by virtually every WG in the IETF. Further, the idea of "I know how to encode a two-octet integer" is easy to understand. The fact that they are shorter is a benefit, even though a small one. As for the negatives on OIDs, your description of how to encode ODIs is, so far, incomplete (hint: large integers), so even you can't say how easy or hard it is. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0A628C119 for ; Sat, 8 Jan 2011 08:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.69 X-Spam-Level: X-Spam-Status: No, score=-101.69 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deQKY2on+JnE for ; Sat, 8 Jan 2011 08:07:33 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 07D1A28C115 for ; Sat, 8 Jan 2011 08:07:32 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p08G9eVf078712 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 8 Jan 2011 09:09:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D288C45.5070201@vpnc.org> Date: Sat, 08 Jan 2011 08:09:41 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <20110108073002.13657.77609.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-01.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:07:33 -0000 On 1/7/11 11:41 PM, Jakob Schlyter wrote: > FYI, -01 contains a set of editorial edits and clarifications based on comments from the list. To be more precise, we included all the edits and clarifications that we thought were non-controversial. If you brought up an issue during the review of the -00 and we didn't include it, and you still think it is an issue, be sure that the WG chairs/secretary open an issue on the topic so the WG can discuss it and come to consensus. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6B428C127 for ; Sat, 8 Jan 2011 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.689 X-Spam-Level: X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD+KuP3UPXlS for ; Sat, 8 Jan 2011 08:05:45 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 33BB328C115 for ; Sat, 8 Jan 2011 08:05:45 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p08G7qwa078605 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 8 Jan 2011 09:07:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D288BD9.3030104@vpnc.org> Date: Sat, 08 Jan 2011 08:07:53 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <201101080323.p083NMAN009227@new.toad.com> In-Reply-To: <201101080323.p083NMAN009227@new.toad.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:05:46 -0000 On 1/7/11 7:23 PM, John Gilmore wrote: > Let's be sure I understand the issue before jumping in. > > Some people want to use a small numerical value, such as one octet, to > designate which hash or crypto algorithm is in use in a DNS record. > For example, the DNSKEY record contains a 1-octet "algorithm" field, > defined in RFC 4034. The field's initial definition was in the RFC, > Appendix A.1, and subsequent assignments are done by IANA. There are > reserved values for subsequent extension of the protocol by IETF, for > private extensions, and values reserved for the indefinite future. > > Other people want to use an ASN.1 "OID" (or "ODR"), which is a > multibyte sequence of arbitrary length, each subsequence of which > defines a code point for allocating sub-code-points. Sort of like a > domain name system for naming things in binary. For example, (someone > come up with a field in an existing approved Standards Track RFC, > please). This field would be restricted to have a known prefix of a > number of fixed byte values (specified in its RFC), and a set of known > suffixes, which are fixed byte strings, each of which would represent > an algorithm. The organization identified by the initial prefix would > have the power to define additional suffixes that identify additional > algorithms, without amendment of the RFC and without further action > by IETF. > > Is that really the issue? If not, please edit and repost similar text > to provide a succinct 2-paragraph description of the issue. You have intertwined the issues, as have others. Warren asked us to detwine them, which I think is good. Using your text above, one issue is "format is small numerical value or ASN.1 OID". The second issue is "who gets to put other values into the specified format, and with what difficulty". Hope this helps. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6B128C106 for ; Sat, 8 Jan 2011 06:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.66 X-Spam-Level: X-Spam-Status: No, score=-3.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1M5WWIUtqWn for ; Sat, 8 Jan 2011 06:58:25 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 6C8AB28C0F0 for ; Sat, 8 Jan 2011 06:58:25 -0800 (PST) Received: by gwj17 with SMTP id 17so9683651gwj.31 for ; Sat, 08 Jan 2011 07:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R1PYpMA1tou2GqxWH6+jX58iNrJ9AMzrKPcZ84+zRus=; b=p3kRCJJPVt6ghad4IZ8f1I+kACPYbPIUY1zmWjnezGj6xswJhyQFhsWk6BoCZrLi6N goM/8gwMB/JNI22CZof4xSIoKTEpLyCBotleuOQah3tKrh1gvLuX+zTLOTMoQx0itLFr jwRrSYTxSDzButbE70CHd1GfGMONwNmDB9/04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fy3wgLAGGvRb/5v0RBGkj+1ZzLl4zbIKBKtjG555OJVwpSyyT5xw6vwi8WqGdOZnPd EDL+bLji5G33LcpugSoqOxnGfWHtVqsrf3ctObl2tjwl/Th8RUeV9FsjB5KBERH0WfuP fiaqW7IqSZ7F2Vpd7AeQ4IrIjrnwxWKH3IWnE= MIME-Version: 1.0 Received: by 10.100.93.6 with SMTP id q6mr3775632anb.69.1294498833182; Sat, 08 Jan 2011 07:00:33 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 07:00:33 -0800 (PST) In-Reply-To: <1294497970.1886.15.camel@mattlaptop2.local> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> <1294497970.1886.15.camel@mattlaptop2.local> Date: Sat, 8 Jan 2011 10:00:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:58:26 -0000 On Sat, Jan 8, 2011 at 9:46 AM, Matt McCutchen wro= te: > On Sat, 2011-01-08 at 09:34 -0500, Phillip Hallam-Baker wrote: >> The technical impact of this choice is >> >> 1) Whether the identifier is 1 or 2 bytes or an average of about 8. > > No, it's more than 8; for example, here is the 20-byte prefix for a "CA > certificate" with SHA-256: > > 30 12 06 03 55 04 25 06 09 60 86 48 01 65 03 04 02 01 04 20 ODI has two identifiers in it. The algorithm ones are from the NIST arc so are the shorter ones. We do need to have a mechanism to identify both parts. >> I don't think that the shaving of a few bytes here is relevant. If we >> go for 1 byte it is very likely we end up with an exhaustion issue >> down the line. > > I don't think so. =A0Are hash algorithms really being invented at such a > rate that over the likely lifespan of DANE (is 30 years a safe high > estimate?) more than 200 or so algorithms would be registered? =A0There > are only 10 entries in the DNSSEC registry so far. =A0On the other hand, > using OIDs lets us do slick things like let organizations assign their > own globally unique algorithm IDs. We need to have a different identifier for each strength. So we have six slots taken by SHA2 and the expected SHA3 for a start. There are currently 5 finalists, that would be 18 identifiers used if we did them all. The risk of exhaustion may not be very high, but fixed length fields make many of us nervous. I expect to be around in 30 years time. I don't expect there will have been major changes to IP or HTTP in that time. I have been writing HTTP code 19 years now and that has not changed. My personal design horizon for protocols is never less than a millennia, Having had to deal with other people's short sightedness I would argue against a design horizon of less than 200 years. --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC00928C106 for ; Sat, 8 Jan 2011 06:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGghXUHISNN7 for ; Sat, 8 Jan 2011 06:56:46 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id F010728C0F0 for ; Sat, 8 Jan 2011 06:56:45 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 249A21D0063 for ; Sat, 8 Jan 2011 06:58:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=a2c722j Q1tEVlG3QE0ivt/k8pBMxXxiKE6H3R+F5fko12o93wOf3yUZSwVzIyK6Apn7IG0Y OlGHf220R80fZz3tZR5mV9zN0HFtrvy55dVnSNGOj9eBxRpg/qC8ySCvWIvV1WAj /EFjk8RTsJ91hAnvGBNJ1YYvW2w+rlqNuo+s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=ErPao7CiFrUma 0gAdAdX1KSNoh0=; b=I3ts1+2acsuL9prLhu7shAuqw6j+MyvQHs6k7TM0cUVPW eYS+JmyZlqXpfqsZBIBhY/xPMTHbLIgM+XJNo2wFa9Zh8lllxGWRfVEBcOVg9DYY Nm9hRj6Myw7IwDLP7wNJUDXUav8rJsXENQlCYFORNhdSoWwiDdQx95l61hY7D0= Received: from [192.168.1.40] (pool-74-96-127-122.washdc.east.verizon.net [74.96.127.122]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id A5B381D0058 for ; Sat, 8 Jan 2011 06:58:53 -0800 (PST) From: Matt McCutchen To: keyassure Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Jan 2011 09:58:52 -0500 Message-ID: <1294498732.1886.24.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [keyassure] ODI should not include object type X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:56:46 -0000 AIUI, an ODI is a stand-in for the object itself via a hash algorithm. And ASN.1 objects are not self-typing. Therefore, I do not think the object type belongs in ODIs either. Self-typing, if desired, is a purpose orthogonal to hashing. In the DANE draft, the expected object type (i.e., PKIX certificate) is known from context. And that must be so for the sake of the "certificate type" values 2 and 4 that embed the object without additional metadata. So having the object type in ODIs is not helpful to DANE. Removing the object type will help make the overhead of ODIs more reasonable. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E438428C107 for ; Sat, 8 Jan 2011 06:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Ol1duwtJ5a for ; Sat, 8 Jan 2011 06:49:49 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 11CC528C0F0 for ; Sat, 8 Jan 2011 06:49:49 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 36E6063406C; Sat, 8 Jan 2011 06:51:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=WvjwHPxX7nXdJgguw5FIiSUT8xnGpqNHVHShivfoltT DRTAK5agscbVqYZE9f7xW58GXXzIcqo1FeFrfCvnBH4CHB6K56dBDVh7WR7yEqva UybCQhWoVfJBA7L5d2n3AbxktnlJwC5fZD/NFC5YxDKIXOx7BALE/V5Up3YKZ5hs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=JVVmYxF0rr0HswbSst0+bWd8CXo=; b=gsG2xgetxb BLxod+3aBB0xVSPnM+N0aE6MiXwFqkxInudN7c1K6h3TPviMWsKdNmK6owEqPfLX flkHTz2vqveR8IIVpqggZ+yrFj2OBzrG9UhLVAPCIGsM/C9bAuRumuEuM6dXVmXc ruIAdD2K3ApFO9UTNXvSBpaIz/+UCc1WY= Received: from [192.168.1.40] (pool-74-96-127-122.washdc.east.verizon.net [74.96.127.122]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id BC139634064; Sat, 8 Jan 2011 06:51:56 -0800 (PST) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <1294497295.1886.8.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Jan 2011 09:51:55 -0500 Message-ID: <1294498315.1886.18.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:49:50 -0000 On Sat, 2011-01-08 at 09:41 -0500, Phillip Hallam-Baker wrote: > The problem with attempting to re-use the DNSSEC registries is that > the DNSEXT people presumably chose to have their own registry so as to > have control themselves. I wouldn't presume that. We would have to look back through their discussion. They may have just thought that the use of one-byte values was more in keeping with the design of DNS. Even so, if we determine that our goals are the same as theirs (as I would guess), there is no issue. > What happens if we want to use an algorithm and they do not? That would be problematic. > What happens if they add a code point for an algorithm that we do not want? We just publish advice for people not to use it. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2890528C100 for ; Sat, 8 Jan 2011 06:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMwLisLbwlxl for ; Sat, 8 Jan 2011 06:44:04 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 6007028C0F0 for ; Sat, 8 Jan 2011 06:44:04 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 934EE28406E; Sat, 8 Jan 2011 06:46:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=AE+0bANUJX+BRwYZ3+GL7zFryrIeUhfoaa8BVsrV2ZI 5aOP+FhhBqdBoXuTgBxZbq2hVDluoTDXKoJHP+pYYGLS0Rz815HwHA1/eaR8JMmg wwif9PJ22AYLuhFWrMpkzK9tQzWi/FsXINrAqIzLHEru7mYg8ZP/zqyId4/HP9as = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Up3TbGUbOlpXsI4Qz9bvgIyBIg8=; b=c/rs2ZPCdE lnUYgGgn+LWFdyk88U5V0NEFyOjyjsWPqFDr1+Vfu0eSNQLE8UHMQslUyi3Bxc+A C0mLZ7vwQvTMyzdmHKDvrfWFYkqlJkBtUixer6pBGqKJllwJgtI2v0FBgtUb05bT omJEsW6b86X7yAh7Ppkz0PGNCriE7M4mY= Received: from [192.168.1.40] (pool-74-96-127-122.washdc.east.verizon.net [74.96.127.122]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id 20E0628406C; Sat, 8 Jan 2011 06:46:12 -0800 (PST) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Jan 2011 09:46:10 -0500 Message-ID: <1294497970.1886.15.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:44:05 -0000 On Sat, 2011-01-08 at 09:34 -0500, Phillip Hallam-Baker wrote: > The technical impact of this choice is > > 1) Whether the identifier is 1 or 2 bytes or an average of about 8. No, it's more than 8; for example, here is the 20-byte prefix for a "CA certificate" with SHA-256: 30 12 06 03 55 04 25 06 09 60 86 48 01 65 03 04 02 01 04 20 > I don't think that the shaving of a few bytes here is relevant. If we > go for 1 byte it is very likely we end up with an exhaustion issue > down the line. I don't think so. Are hash algorithms really being invented at such a rate that over the likely lifespan of DANE (is 30 years a safe high estimate?) more than 200 or so algorithms would be registered? There are only 10 entries in the DNSSEC registry so far. On the other hand, using OIDs lets us do slick things like let organizations assign their own globally unique algorithm IDs. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E935228C104 for ; Sat, 8 Jan 2011 06:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rY-XvYpnPZI for ; Sat, 8 Jan 2011 06:39:05 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C1CA328C0F0 for ; Sat, 8 Jan 2011 06:39:05 -0800 (PST) Received: by ywk9 with SMTP id 9so7986261ywk.31 for ; Sat, 08 Jan 2011 06:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=udx3p/lpGZRbaaYsyf8ze+zEePzH0go9JbdXq5VjNvI=; b=eP70C9P5SkQEUGgHmfugZvNXc17uu1ssg3Ft9h205WVxYzhWL09B/ccfKMBR3uCPuA y3UsqcZbU3ZB+QB3DQtZuSmtyzKYL3WC9gTVbZQRHzVOoF6VBmxZAOT6Mty7ku/BMP4O gE1hmnC2Mh8DecNlH6iGBOB9+HNIYFNAI8YIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=I0lN0NmXGXCpG4+MnK8PvyGegl9xIpHu5xx1SFtxUylxx1jMwvZnjoCRrn/DZBLmF3 bEmyqx4bzqfeXU14iccCjmDXGeFUr+99XVmWGL+dsS/95Ep1gyP91Tvymnp7pDDa4p1S 36uNTr89mVU022fUEd2P6SPVMli+VgZ+jRHCU= MIME-Version: 1.0 Received: by 10.100.153.17 with SMTP id a17mr281778ane.239.1294497673586; Sat, 08 Jan 2011 06:41:13 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 06:41:13 -0800 (PST) In-Reply-To: <1294497295.1886.8.camel@mattlaptop2.local> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> <1294497295.1886.8.camel@mattlaptop2.local> Date: Sat, 8 Jan 2011 09:41:13 -0500 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:39:07 -0000 On Sat, Jan 8, 2011 at 9:34 AM, Matt McCutchen wro= te: > On Sat, 2011-01-08 at 09:07 -0500, Phillip Hallam-Baker wrote: >> Proliferating crypto registries imposes a cost on the whole >> organization. It is making busy-work that is not necessary. > > I agree. > >> The point of working in the IETF as opposed to doing a roll your own >> standards organization is meant to be building on the work of others. >> ODI is designed to be a re-usable building block that can be used in >> other places. > > Right, but it is a /new/ re-usable building block. =A0Reusing the DNSSEC > registry would be a more conservative choice than inventing ODI and > would still achieve the goal of not proliferating crypto registries. > There is a trade-off. The problem with attempting to re-use the DNSSEC registries is that the DNSEXT people presumably chose to have their own registry so as to have control themselves. What happens if we want to use an algorithm and they do not? What happens if they add a code point for an algorithm that we do not want? --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA48B28C0FD for ; Sat, 8 Jan 2011 06:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwa+23wokBll for ; Sat, 8 Jan 2011 06:32:49 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id B4DCD28C0F0 for ; Sat, 8 Jan 2011 06:32:49 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id D13C4280069; Sat, 8 Jan 2011 06:34:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=COwS/BIC7A9eL01QTNqoE40n59wCpYJ+4Z3LwudHwee THsIev+LA4faj0WHbI3jk82rhm1vHCnJb1RPLCmcmWoJOINq+ojKMCUmK5eOA5B5 bFejNO8byvlxEeQS80jcPNmoEgDlbm83CK/DUcU8LkLwz9l+oH2gPiBmf3L9OgBc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=MRjor3ghbPaicV0zfGVafOJQ0+I=; b=n1FXQyVkw6 m0j6E6z4RDzwubfm5G3hhka/JAT1z1mCXQvjv1n2dhDPAz1sCOpLdIKXlYon8CPc fY402I7CnIhV3uD5TdjmsPuxIz38kb1wq42rC95oecEfE8evDziI6VKjcapwsoi7 ybrW+vq4dAaYyEhRCrM8iEKozhcmfX190= Received: from [192.168.1.40] (pool-74-96-127-122.washdc.east.verizon.net [74.96.127.122]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 6421F280063; Sat, 8 Jan 2011 06:34:57 -0800 (PST) From: Matt McCutchen To: Phillip Hallam-Baker In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Sat, 08 Jan 2011 09:34:55 -0500 Message-ID: <1294497295.1886.8.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:32:51 -0000 On Sat, 2011-01-08 at 09:07 -0500, Phillip Hallam-Baker wrote: > Proliferating crypto registries imposes a cost on the whole > organization. It is making busy-work that is not necessary. I agree. > The point of working in the IETF as opposed to doing a roll your own > standards organization is meant to be building on the work of others. > ODI is designed to be a re-usable building block that can be used in > other places. Right, but it is a /new/ re-usable building block. Reusing the DNSSEC registry would be a more conservative choice than inventing ODI and would still achieve the goal of not proliferating crypto registries. There is a trade-off. > So far I have given concrete benefits for my design choices. In > contrast the opposition has been 'well I prefer' without giving actual > benefits. In order to verify this kind of claim, I have to dig back through the mail and assess whether the benefits claimed for the alternative solution are "actual", etc., and possibly miss something. This is frustrating and leads to discussions that go around in circles. Could we perhaps maintain a list of benefits for each solution in one place on the wiki? (I am having trouble with loginmgr though; I contacted webmaster@tools.ietf.org on Wednesday and haven't heard back yet.) -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267CC28C0FD for ; Sat, 8 Jan 2011 06:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.391 X-Spam-Level: X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGYIqMOHyTOW for ; Sat, 8 Jan 2011 06:32:23 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id D0B8728C0F0 for ; Sat, 8 Jan 2011 06:32:22 -0800 (PST) Received: by yie19 with SMTP id 19so5690077yie.31 for ; Sat, 08 Jan 2011 06:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OBU1LxH8QMnvM40mNlF7hFNkiznUsPKVM+7iy8DrSS8=; b=iEKXh2Pcak1Fy9x7mA3RU2tS/CFXGwZUWdUD6tC0NiGylzxVYJr+7wKdosM4vxzH1C zVEguRs/RxwFVH85i3C2+Sm3b5d7XCedLVq7AgviEqiYApI9HaKLjAtD2Xpnzgt60KqS 3N9ND5T79V3B5GtJtKFKiMPYkILQOzHFSQfK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GAJGCISpVMTRNcrpbG8G/pTDJlfH4nqmFbBmvZt6waCX5CKTDWxup2RLip84qaoYrZ +SJJNtf3PcvjH2cLdcaAG+BCCiLUcNtjq3IwE9AhREg4wc8p4ffpU2KGXWfVcDLCa4jr T7FFHeBHxWCAHtIA5EtdU37jVE+vRW9qq81Kc= MIME-Version: 1.0 Received: by 10.100.255.4 with SMTP id c4mr833320ani.205.1294497270557; Sat, 08 Jan 2011 06:34:30 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 06:34:30 -0800 (PST) In-Reply-To: <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> Date: Sat, 8 Jan 2011 09:34:30 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:32:24 -0000 On Fri, Jan 7, 2011 at 6:12 PM, Warren Kumari wrote: > If possible I'd like us to try and separate the discussions of "Who gets / > how to get an identifier for an algorithm" from the question of how we > actually identify these -- while I realize that there are interdependencies > in the two issues and they are not fully separable, I'd appreciate it if we > can try and separate them as much as possible so that it is easier to call > consensus.... The technical impact of this choice is 1) Whether the identifier is 1 or 2 bytes or an average of about 8. 2) Whether the identifier space can be exhausted or not 3) What are the criteria for gating access to the registry. I don't think that the shaving of a few bytes here is relevant. If we go for 1 byte it is very likely we end up with an exhaustion issue down the line. If we go for a self-describing length scheme we endup with something that looks like ASN.1 If people want we could have a hybrid scheme in which we asked IANA to establish a registry of the ASN.1 identifiers for the mandatory to implement and preferred algorithms for use. This registry would then ideally have two initial entries as followed SHA2 256bits MANDATORY ... SHA2 512bits MANDATORY ... Anyone who wants to use vanity crypto simply uses their own code point. It is possible to use any algorithm people like in private between consenting adults. But the registry only has to track the ones that are either mentioned in a spec or have been added because there is a consensus they should be supported. -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E0428C0F6 for ; Sat, 8 Jan 2011 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctl-WXDbxkAM for ; Sat, 8 Jan 2011 06:05:35 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 9310728C0F5 for ; Sat, 8 Jan 2011 06:05:35 -0800 (PST) Received: by yie19 with SMTP id 19so5684905yie.31 for ; Sat, 08 Jan 2011 06:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uweofP8KNXiVexXMPqZKK6iHG+E1HHn8UNaG6lt6xgc=; b=bpsQ6C7Wnp8iJ2i2NTsI5KF6dxAqPbpg1j6ZjhZK26cISyxcimwMKWs2/y3HcoEmEz RH7xynBoxu/g1WqKv1q6U+FiMRfa/HEd7kDhBDuTjBHgL+dXjO7UWWPBKAsIAp4V45gq Zrb8JSfyhg7xobvfKcKtJs5hTfvPcqKNVajBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qMMru9u+P3G6bAKvV+AGyGXydn/nFlD2Hvv+GBUQhMYNMrBWTyYyScucDV070b44nG TXJTZG1VyjBLYTkZAqIQmXCCAg9eGCifPHu+JfwXP8R05Dgh4Qb+bxxRO2u3wk2GbWqD HFwg0fDtQBUcxoTc2R2IlGl3fVFa+Gw/1fegg= MIME-Version: 1.0 Received: by 10.100.255.4 with SMTP id c4mr822247ani.205.1294495662668; Sat, 08 Jan 2011 06:07:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 06:07:42 -0800 (PST) In-Reply-To: <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> Date: Sat, 8 Jan 2011 09:07:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 14:05:36 -0000 Since this is precisely the type of change that KEYPROV was required to make during IESG review, I would have to disagree. We had specified our own password string prep, we were told we had to use the existing string prep from another spec. >From a process point of view I think that the chances of being told to move from ASN.1 to a custom registry are essentially 0% while the chance of being told to move from a custom registry to ASN.1 is approximately 50:50% Proliferating crypto registries imposes a cost on the whole organization. It is making busy-work that is not necessary. The point of working in the IETF as opposed to doing a roll your own standards organization is meant to be building on the work of others. ODI is designed to be a re-usable building block that can be used in other places. It builds on ASN.1 which is itself a frequently used building block that is essentially a standard in the crypto world. So far I have given concrete benefits for my design choices. In contrast the opposition has been 'well I prefer' without giving actual benefits. The nearest we got was Paul's rather silly claim that ODI is difficult to code (false) and the vague idea that having a registry puts you in control. On Fri, Jan 7, 2011 at 6:04 PM, Warren Kumari wrote: > [ Resending, my mail server et the first one ] > On Jan 7, 2011, at 6:52 AM, Phillip Hallam-Baker wrote: > >> ODI already describes a bare key mechanism in the CAA draft. >> >> We have not got a code point assigned yet, but I have asked the ADs abou= t >> it. >> >> >> I am somewhat surprised that we settled on this issue to discuss first >> since it affects the whole security area. >> > > I'm sorry, but I disagree with you here. I assume we all agree that folk > need to be able to tell what algorithm was used to generate > 0x1234ABCD....212 ? > > How does it "affect the whole security area" if we decide "We'll ask the > IANA to please keep track of the fact that 17 means AlgorithmX" or "We'll > choose which Smurf looks most like the algorithm in question and use the > ROT13 encoded version of his name to identify it"? > > As long as there are a base set of algorithms that implementations are > expected to implement (and a means to get new algorithms added and old on= es > retired) and way to uniquely identify them, I fail to see how what the > identifier is is such a big issue.... > > W > > >> >> >> On Thu, Jan 6, 2011 at 9:49 PM, Paul Wouters wrote: >>> >>> On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote: >>> >>>> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. >>> >>> DANE should be usable for people without PKIX or ASN.1. If we get a TLS >>> scheme for "bare public key" then we can't use OIDs for hash references= . >>> >>> I'm in favour of our own registry, re-using where possible the same alg= o >>> numbers as in other dnssec registries. >>> >>> Paul >>> >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure > > Life is a concentration camp. =A0You're stuck here and there's no way out= and > you can only rage impotently against your persecutors. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Woody Allen > > > > --=20 Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA683A69BC for ; Fri, 7 Jan 2011 23:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nouknBVkWQCK for ; Fri, 7 Jan 2011 23:39:39 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id DAEBA3A69BA for ; Fri, 7 Jan 2011 23:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=ryjURBSxJSpNsLSsHz2e64z1N7jX9MYMqRligPFMbQ8=; b=qYrSZUt26Du9VnlHnOssPfqMDVGSq7D7yS0wwC3RLEXrMUC0wJhbX7JrKTZkDntRp+UTcAPJqkGVG 90US9ZtyZ2BPVlAdI46eVlfVh5cFQPFz6EQIoviwO+Km5fDgtGtqGp7HY53X3u7/ZrYu+sGCxXV6fU fpVRa8FEdHcX96nI= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS for ; Sat, 8 Jan 2011 08:41:40 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Jakob Schlyter In-Reply-To: <20110108073002.13657.77609.idtracker@localhost> Date: Sat, 8 Jan 2011 08:41:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110108073002.13657.77609.idtracker@localhost> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-01.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 07:39:40 -0000 FYI, -01 contains a set of editorial edits and clarifications based on = comments from the list. jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F1628C0E2; Fri, 7 Jan 2011 23:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQsc0PCMaZ5E; Fri, 7 Jan 2011 23:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8323A69BC; Fri, 7 Jan 2011 23:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110108073002.13657.77609.idtracker@localhost> Date: Fri, 07 Jan 2011 23:30:02 -0800 Cc: keyassure@ietf.org Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-01.txt X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 07:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For TLS Author(s) : P. Hoffman, J. Schlyter Filename : draft-ietf-dane-protocol-01.txt Pages : 10 Date : 2011-01-07 TLS and DTLS use certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. Instead of trusting a certification authority to have made this association correctly, the user might instead trust the authoritative DNS server for the domain name to make that association. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dane-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-07232545.I-D@ietf.org> --NextPart-- Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95E93A69A3 for ; Fri, 7 Jan 2011 19:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi5RH3fcAgPI for ; Fri, 7 Jan 2011 19:21:41 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id 1546A3A698F for ; Fri, 7 Jan 2011 19:21:35 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p083NMAN009227; Fri, 7 Jan 2011 19:23:22 -0800 Message-Id: <201101080323.p083NMAN009227@new.toad.com> To: Phillip Hallam-Baker In-reply-to: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> Comments: In-reply-to Phillip Hallam-Baker message dated "Fri, 07 Jan 2011 13:19:59 -0500." Date: Fri, 07 Jan 2011 19:23:22 -0800 From: John Gilmore Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 03:21:42 -0000 Let's be sure I understand the issue before jumping in. Some people want to use a small numerical value, such as one octet, to designate which hash or crypto algorithm is in use in a DNS record. For example, the DNSKEY record contains a 1-octet "algorithm" field, defined in RFC 4034. The field's initial definition was in the RFC, Appendix A.1, and subsequent assignments are done by IANA. There are reserved values for subsequent extension of the protocol by IETF, for private extensions, and values reserved for the indefinite future. Other people want to use an ASN.1 "OID" (or "ODR"), which is a multibyte sequence of arbitrary length, each subsequence of which defines a code point for allocating sub-code-points. Sort of like a domain name system for naming things in binary. For example, (someone come up with a field in an existing approved Standards Track RFC, please). This field would be restricted to have a known prefix of a number of fixed byte values (specified in its RFC), and a set of known suffixes, which are fixed byte strings, each of which would represent an algorithm. The organization identified by the initial prefix would have the power to define additional suffixes that identify additional algorithms, without amendment of the RFC and without further action by IETF. Is that really the issue? If not, please edit and repost similar text to provide a succinct 2-paragraph description of the issue. John Gilmore Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B533A693F for ; Fri, 7 Jan 2011 17:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.584 X-Spam-Level: X-Spam-Status: No, score=-100.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alRpn3cuGSh6 for ; Fri, 7 Jan 2011 17:16:35 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 8F56D3A6938 for ; Fri, 7 Jan 2011 17:16:32 -0800 (PST) Received: from [10.2.55.178] (unknown [166.137.11.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 8C6FA2284B18; Fri, 7 Jan 2011 20:18:38 -0500 (EST) References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> <4D27A3DC.8010409@vpnc.org> In-Reply-To: <4D27A3DC.8010409@vpnc.org> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <0D4E628E-043A-4134-8E26-599F46DF79FC@kumari.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Warren Kumari Date: Fri, 7 Jan 2011 20:18:30 -0500 To: Paul Hoffman Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 01:16:36 -0000 Awesome, thanks for the clarity... W Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Jan 7, 2011, at 6:38 PM, Paul Hoffman wrote: > On 1/7/11 3:12 PM, Warren Kumari wrote: >=20 >> If possible I'd like us to try and separate the discussions of "Who gets >> / how to get an identifier for an algorithm" from the question of how we >> actually identify these -- while I realize that there are >> interdependencies in the two issues and they are not fully separable, >> I'd appreciate it if we can try and separate them as much as possible so >> that it is easier to call consensus.... >=20 > Just to be clear, my preferences are: >=20 > - Somewhat liberal policy for assigning: "RFC published", not "IETF consen= sus" or "expert review" >=20 > - two-byte integers for identifying, with 1000 reserved for private use >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB5228B797 for ; Fri, 7 Jan 2011 15:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.687 X-Spam-Level: X-Spam-Status: No, score=-101.687 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MmC7m-ZJQx2 for ; Fri, 7 Jan 2011 15:35:59 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 802493A69B0 for ; Fri, 7 Jan 2011 15:35:59 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p07Nc4SH049783 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 7 Jan 2011 16:38:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D27A3DC.8010409@vpnc.org> Date: Fri, 07 Jan 2011 15:38:04 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> In-Reply-To: <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:36:00 -0000 On 1/7/11 3:12 PM, Warren Kumari wrote: > If possible I'd like us to try and separate the discussions of "Who gets > / how to get an identifier for an algorithm" from the question of how we > actually identify these -- while I realize that there are > interdependencies in the two issues and they are not fully separable, > I'd appreciate it if we can try and separate them as much as possible so > that it is easier to call consensus.... Just to be clear, my preferences are: - Somewhat liberal policy for assigning: "RFC published", not "IETF consensus" or "expert review" - two-byte integers for identifying, with 1000 reserved for private use Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3143A69B0 for ; Fri, 7 Jan 2011 15:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPAvCKVLxic6 for ; Fri, 7 Jan 2011 15:11:45 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 121533A69BD for ; Fri, 7 Jan 2011 15:10:20 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 9720B2284B18; Fri, 7 Jan 2011 18:12:27 -0500 (EST) Message-Id: <6F60B7E7-DDF7-4699-9788-EFB66BB980A6@kumari.net> From: Warren Kumari To: Paul Wouters In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Jan 2011 18:12:27 -0500 References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Phillip Hallam-Baker , Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:11:47 -0000 [ Top posting intentional -- this is a meta point and not a response to Paul Wouters' mail. ] [ Resending, mail-server fun -- I've been passing outbound mail though SpamAssassin and spamd has started dying on messages with an (as yet unidentified) set of strings... ] So far it looks to me like the group is leaning towards us having our own registry (and using simple ordinals from the registry to identify the hash / cert / algorithm), but I'd like to A: hear a few more voices and B: wait for Ondrej to be back. If possible I'd like us to try and separate the discussions of "Who gets / how to get an identifier for an algorithm" from the question of how we actually identify these -- while I realize that there are interdependencies in the two issues and they are not fully separable, I'd appreciate it if we can try and separate them as much as possible so that it is easier to call consensus.... I'd also like to thank everyone who has contributed and to thank folk for staying on topic -- I know how tempting it is to go off on a tangent so thanks for staying focused and clearly stating preferences. W On Jan 7, 2011, at 11:16 AM, Paul Wouters wrote: > On Fri, 7 Jan 2011, Phillip Hallam-Baker wrote: > >> ODI already describes a bare key mechanism in the CAA draft. > > CAA is about PKIX, Dane is not exlusively PKIX. > > I like my IANA registries as technology agnostic as possible, and > definitely not > drag in ASN.1 for technologies that are not PKIX based. > > It is certainly in line with the other DNS(SEC) related IANA > registries to use > simple octet based algorithm and type definitions. > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- "Have you got any previous convictions?" "Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--" -- Terry Pratchett Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BE528C13B for ; Fri, 7 Jan 2011 15:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMkkmadvIhYF for ; Fri, 7 Jan 2011 15:02:47 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 7AAD728C110 for ; Fri, 7 Jan 2011 15:02:43 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 4880A2284B32; Fri, 7 Jan 2011 18:04:49 -0500 (EST) Message-Id: <513ACBDA-C6E6-40B4-ADFB-8FF8AD2F7506@kumari.net> From: Warren Kumari To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 7 Jan 2011 18:04:48 -0500 References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:02:48 -0000 [ Resending, my mail server et the first one ] On Jan 7, 2011, at 6:52 AM, Phillip Hallam-Baker wrote: > ODI already describes a bare key mechanism in the CAA draft. > > We have not got a code point assigned yet, but I have asked the ADs > about it. > > > I am somewhat surprised that we settled on this issue to discuss first > since it affects the whole security area. > I'm sorry, but I disagree with you here. I assume we all agree that folk need to be able to tell what algorithm was used to generate 0x1234ABCD....212 ? How does it "affect the whole security area" if we decide "We'll ask the IANA to please keep track of the fact that 17 means AlgorithmX" or "We'll choose which Smurf looks most like the algorithm in question and use the ROT13 encoded version of his name to identify it"? As long as there are a base set of algorithms that implementations are expected to implement (and a means to get new algorithms added and old ones retired) and way to uniquely identify them, I fail to see how what the identifier is is such a big issue.... W > > > On Thu, Jan 6, 2011 at 9:49 PM, Paul Wouters > wrote: >> On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote: >> >>> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. >> >> DANE should be usable for people without PKIX or ASN.1. If we get a >> TLS >> scheme for "bare public key" then we can't use OIDs for hash >> references. >> >> I'm in favour of our own registry, re-using where possible the same >> algo >> numbers as in other dnssec registries. >> >> Paul >> > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Life is a concentration camp. You're stuck here and there's no way out and you can only rage impotently against your persecutors. -- Woody Allen Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8213C3A67AF for ; Fri, 7 Jan 2011 10:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJQzb-KCYPpg for ; Fri, 7 Jan 2011 10:17:53 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 7642D3A67A1 for ; Fri, 7 Jan 2011 10:17:53 -0800 (PST) Received: by yxt33 with SMTP id 33so7715868yxt.31 for ; Fri, 07 Jan 2011 10:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0NUNktzE2Ul3kclGLZc2SDXL2NrjTfJVLtkQhOiekow=; b=QPsWg2ToifqyZk/vDBCmkkj6hkSs+zvgqqUqVhtKaas7VN2s12Uo5czK/JH3uO5DZp 0qr/sGBBrYXy5k01ijxOqcm7B3nFH+NT1bW5vXSU/ycYpEaXqSC7O/3dB1vOY0vUTCJW dnT+q8wHdUQtM36lBjnJNDHm7TZj6iEORBXD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YxBn465KTn4lofGZf69hMWskZxWysouhCCjJp13O2XO2d45aW3Gy6CMx/XzcHwQoIX KJtrrIfg1NhePNTRPi404izHigB0x9RjMJVa0mSPPMrFUl/5GWYJZ+Vg+/ZPUDqXJ43M gh2UxTxmCIh5UG7NVNMAnb/WoVuon2bScJQEg= MIME-Version: 1.0 Received: by 10.100.96.1 with SMTP id t1mr15592099anb.137.1294424400015; Fri, 07 Jan 2011 10:20:00 -0800 (PST) Received: by 10.100.31.8 with HTTP; Fri, 7 Jan 2011 10:19:59 -0800 (PST) In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> Date: Fri, 7 Jan 2011 13:19:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:17:54 -0000 The ODI spec is not tied to PKIX at all. It is expressly intended to be totally generic. An ODI could reference a HTML document or a MIME package. Unless of course you know something about ODI that I do not. On Fri, Jan 7, 2011 at 11:16 AM, Paul Wouters wrote: > On Fri, 7 Jan 2011, Phillip Hallam-Baker wrote: > >> ODI already describes a bare key mechanism in the CAA draft. > > CAA is about PKIX, Dane is not exlusively PKIX. > > I like my IANA registries as technology agnostic as possible, and definitely > not > drag in ASN.1 for technologies that are not PKIX based. > > It is certainly in line with the other DNS(SEC) related IANA registries to > use > simple octet based algorithm and type definitions. > > Paul > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5743A67AF for ; Fri, 7 Jan 2011 10:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjSG-n5iGn+8 for ; Fri, 7 Jan 2011 10:13:39 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 8F5B23A67A1 for ; Fri, 7 Jan 2011 10:13:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=2EtSQxUSFakcORSV/GG5lg6Psh5o/vbphIhIcKeQPKA=; b=1DqaMDTqbS/IHVURPO8FtZ/yNGPiEWLWfKuG4abaGOLcT+mEHM/lFrb1vphP1QQjlYK619Jz49FcI Oh7+M49km9p5lEK0zQ9B1WAugEgHKDHRmAwtEconthnNz/CiLYJMUdcGvm/Ti0cmzX31InhaW3Yhbu gsAN57kh/XQKu4RE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS for ; Fri, 7 Jan 2011 19:15:42 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Jakob Schlyter In-Reply-To: Date: Fri, 7 Jan 2011 19:15:40 +0100 Content-Transfer-Encoding: 7bit Message-Id: <4B1BDD23-C86C-4AD1-AB34-6E5A4F4CE860@kirei.se> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 18:13:40 -0000 On 7 jan 2011, at 03.49, Paul Wouters wrote: > I'm in favour of our own registry, re-using where possible the same algo > numbers as in other dnssec registries. +1 jakob Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4152B3A68C0 for ; Fri, 7 Jan 2011 08:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hUiDJTylJHB for ; Fri, 7 Jan 2011 08:14:31 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2253A3A6842 for ; Fri, 7 Jan 2011 08:14:31 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 5DD89C1FA; Fri, 7 Jan 2011 11:16:36 -0500 (EST) Date: Fri, 7 Jan 2011 11:16:35 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:14:32 -0000 On Fri, 7 Jan 2011, Phillip Hallam-Baker wrote: > ODI already describes a bare key mechanism in the CAA draft. CAA is about PKIX, Dane is not exlusively PKIX. I like my IANA registries as technology agnostic as possible, and definitely not drag in ASN.1 for technologies that are not PKIX based. It is certainly in line with the other DNS(SEC) related IANA registries to use simple octet based algorithm and type definitions. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55783A6824 for ; Fri, 7 Jan 2011 03:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBGVTTUVEF9Z for ; Fri, 7 Jan 2011 03:50:26 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id DCB0F3A6828 for ; Fri, 7 Jan 2011 03:50:25 -0800 (PST) Received: by ywk9 with SMTP id 9so7639817ywk.31 for ; Fri, 07 Jan 2011 03:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qYBxOhBfqEL1tX+HgiQnipdpT2cTxwIEVV4BrqoVi98=; b=bXc1q69frrNUA38aLbJfMB0292NjIrYwGC4XwlJY1+Zq5WGGOGrFCFVFReC2zgTqFr +M2oPj5VZrSaGWs6ORuXIuqjVmDvB4uf/kIXOB2c7eDfGaEYl6Zy84uooiFKjC0E51oY 6Bkxo6dOdj+A0IbHkrk4bMiwiXoSvYro6OIxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kGV2UGnjqXowm8iQGa8vPEfG5o8kq/9IBvaEtMB5q8j+g76Vj9XgOFCrMEhlyEA/1h N3MBlWOGIuQtwjOWZVxKZuAiw2CDjjCbsGXe9woCy0pYxlIDhgRmHmfJzQJZhDitV0W1 ltcLz829ZATQWBiZiRTRgo5GotVLu66Rx+Ye8= MIME-Version: 1.0 Received: by 10.100.96.1 with SMTP id t1mr15328719anb.137.1294401148478; Fri, 07 Jan 2011 03:52:28 -0800 (PST) Received: by 10.100.31.8 with HTTP; Fri, 7 Jan 2011 03:52:28 -0800 (PST) In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> Date: Fri, 7 Jan 2011 06:52:28 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:50:32 -0000 ODI already describes a bare key mechanism in the CAA draft. We have not got a code point assigned yet, but I have asked the ADs about it. I am somewhat surprised that we settled on this issue to discuss first since it affects the whole security area. On Thu, Jan 6, 2011 at 9:49 PM, Paul Wouters wrote: > On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote: > >> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. > > DANE should be usable for people without PKIX or ASN.1. If we get a TLS > scheme for "bare public key" then we can't use OIDs for hash references. > > I'm in favour of our own registry, re-using where possible the same algo > numbers as in other dnssec registries. > > Paul > -- Website: http://hallambaker.com/ Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E933A6E28 for ; Thu, 6 Jan 2011 18:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Eo3G+1cSMWz for ; Thu, 6 Jan 2011 18:47:39 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 055403A6DF7 for ; Thu, 6 Jan 2011 18:47:38 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 65EFEBFFA; Thu, 6 Jan 2011 21:49:43 -0500 (EST) Date: Thu, 6 Jan 2011 21:49:42 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 02:47:40 -0000 On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote: > PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. DANE should be usable for people without PKIX or ASN.1. If we get a TLS scheme for "bare public key" then we can't use OIDs for hash references. I'm in favour of our own registry, re-using where possible the same algo numbers as in other dnssec registries. Paul Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6253A6BA8 for ; Thu, 6 Jan 2011 17:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.672 X-Spam-Level: X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF2rXYjhqZoe for ; Thu, 6 Jan 2011 17:26:28 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0D9323A69C9 for ; Thu, 6 Jan 2011 17:26:27 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p071SWJw097940 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jan 2011 18:28:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D266C40.5070008@vpnc.org> Date: Thu, 06 Jan 2011 17:28:32 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 01:26:30 -0000 On 1/6/11 5:05 PM, Phillip Hallam-Baker wrote: > Working Groups have a limited lifespan. Which has created no end of > problem in the security area as we have groups whose primary reason > for continuing at the moment is maintaining the set of algorithms. This doesn't match my experience. Can you name even one WG that has that as a primary reason for existing? For that matter, can you name one whose last charter was that? > That type of maintenance is not something that IETF process was > designed to support and is not cost free. Correct. That's why we don't do it. > Because a WG that is open > for maintenance of algorithms tends to find other reasons for keeping > itself busy. Fully agree. That's why we don't do it. > We already have S/MIME, TLS, IPSEC, DNSSEC and PKIX, choosing > algorithms. S/MINE is close. TLS hasn't done any algorithm choosing in a while; nor has IPsecME. DNSSEC just went through an unfortunate round of that while they did other work. PKIX hasn't done that in a while (although they are not doing anything I consider all that useful...). > But its the same people making the choices on the basis of > the same set of criteria. If that were only true. Unfortunately, it is not. > And at the end of the day that particular > set of protocols really form a single family and should really be > using a common set of algorithms. But the IETF has refused to do that for over a decade, unfortunately. > As far as interoperability is concerned, I think it is very simple: > the group mandates an initial MUST support algorithm and later RFCs > may update that requirement across the whole family of protocols. Sounds good to me. > If people want to use something that is not the mandated algorithm of > an IETF consensus successor (as I expect SHA3 will prove) then they > have to expect to pay the price of losing interoperability. Correct. > But the > people who do vanity crypto know all about that from the start. That > is their own funeral. Correct (except if you are GOST...) > The problem with vanity crypto is the implicit endorsement that comes > from being assigned a code point, not the possible lack of > interoperability. As people will have observed on the IETF mailing > list, some people make the strangest claims on the basis of what > appears in published RFCs. They can make such claims without us. You are calling for a highly restricted registry that requires IETF consensus to change. This argues against your earlier point of the cost of doing reviews. > Apart from the representatives of the government behind it, there is > not one single person who has come to me and said that they are really > keen to implement GHOST. I have however had people tell me that GHOST > is an IETF sanctioned and endorsed algorithm on the basis of the > assignment of a DNSSEC code point. You probably meant "GOST" there, the Russian crypto standard. And I have heard from multiple vendors who want to implement GOST so that they can sell to the Russian market. Some are even keen to implement SEED for similar reasons in South Korea. And so on. The fact that they have not come to you to say this is somewhat off-topic. > So the ODI/ODR scheme is quite explicitly and deliberately designed to > deny that type of implicit endorsement. If people want to use any > algorithm other than the standard set of algorithms they are on notice > that they are on their own with regards to both interoperability and > quality of the algorithm. If the WG wants such restrictions, we don't need OIDs: we can just make entry to the registry as restrictive as we want. I propose liberalness so that it wastes less time arguing, but others like restrictiveness. > PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. I > would like to see DNSSEC and TLS eventually take the same approach to > specify non-mandatory algorithm suites. Noted (although I have not seen your proposals to those WGs to do so). Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FC93A6E23 for ; Thu, 6 Jan 2011 17:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poKrhIDppHtk for ; Thu, 6 Jan 2011 17:03:40 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 49EAC3A6DD1 for ; Thu, 6 Jan 2011 17:03:40 -0800 (PST) Received: by yxt33 with SMTP id 33so7465788yxt.31 for ; Thu, 06 Jan 2011 17:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=B03y4G7l1J8ypmcMA06BNTbg1G35I0PCHwXyFqz1Lfw=; b=XkIpwGSd9r3JkGipBLSvAofTq56UeEEbiwcu7Uy29twjvTKeI5DMJm0pr/is7P6bJh XQUrWdRX1BXggVEl1nVIAby+Oz5JzA0VSixtoqi7t2Ajm7qMQY2luwTuW75yQe+HAG30 AMHLC9OZiCYSvOVqqLrPjkcItpwD2lGenDpZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WlTWTd/yMWT2NUf2DNuTOesBzQ0hi2hTkT40E5ZSjaLK4/RtbiI5copvSIkl2eWSC9 psSWIIT8j8x5/FUgAxO83nCR2gpGOgbM1371Gxe2BX/SHjLH9uh7IK8aSZiMGD65RIyn UMIXfYb//7dPJOE4KAczdeCsBuHv7WTXFdLKA= MIME-Version: 1.0 Received: by 10.100.93.6 with SMTP id q6mr2750121anb.69.1294362346868; Thu, 06 Jan 2011 17:05:46 -0800 (PST) Received: by 10.100.31.8 with HTTP; Thu, 6 Jan 2011 17:05:46 -0800 (PST) In-Reply-To: <4D260325.6000705@vpnc.org> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> <4D260325.6000705@vpnc.org> Date: Thu, 6 Jan 2011 20:05:46 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 01:03:41 -0000 Working Groups have a limited lifespan. Which has created no end of problem in the security area as we have groups whose primary reason for continuing at the moment is maintaining the set of algorithms. That type of maintenance is not something that IETF process was designed to support and is not cost free. Because a WG that is open for maintenance of algorithms tends to find other reasons for keeping itself busy. We already have S/MIME, TLS, IPSEC, DNSSEC and PKIX, choosing algorithms. But its the same people making the choices on the basis of the same set of criteria. And at the end of the day that particular set of protocols really form a single family and should really be using a common set of algorithms. As far as interoperability is concerned, I think it is very simple: the group mandates an initial MUST support algorithm and later RFCs may update that requirement across the whole family of protocols. If people want to use something that is not the mandated algorithm of an IETF consensus successor (as I expect SHA3 will prove) then they have to expect to pay the price of losing interoperability. But the people who do vanity crypto know all about that from the start. That is their own funeral. The problem with vanity crypto is the implicit endorsement that comes from being assigned a code point, not the possible lack of interoperability. As people will have observed on the IETF mailing list, some people make the strangest claims on the basis of what appears in published RFCs. Apart from the representatives of the government behind it, there is not one single person who has come to me and said that they are really keen to implement GHOST. I have however had people tell me that GHOST is an IETF sanctioned and endorsed algorithm on the basis of the assignment of a DNSSEC code point. So the ODI/ODR scheme is quite explicitly and deliberately designed to deny that type of implicit endorsement. If people want to use any algorithm other than the standard set of algorithms they are on notice that they are on their own with regards to both interoperability and quality of the algorithm. PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. I would like to see DNSSEC and TLS eventually take the same approach to specify non-mandatory algorithm suites. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565F93A6C9B for ; Thu, 6 Jan 2011 09:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.67 X-Spam-Level: X-Spam-Status: No, score=-101.67 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEAhSfJ+1v8o for ; Thu, 6 Jan 2011 09:58:00 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 738E43A68D5 for ; Thu, 6 Jan 2011 09:58:00 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p06I05QW081871 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Jan 2011 11:00:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D260325.6000705@vpnc.org> Date: Thu, 06 Jan 2011 10:00:05 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Matt McCutchen References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> <1294335556.2352.67.camel@mattlaptop2.local> In-Reply-To: <1294335556.2352.67.camel@mattlaptop2.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:58:01 -0000 On 1/6/11 9:39 AM, Matt McCutchen wrote: > On Thu, 2011-01-06 at 08:37 -0800, Paul Hoffman wrote: >> On 1/6/11 8:26 AM, Matt McCutchen wrote: >>> On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote: >>> Sure. So: >>> >>> Benefits of operating our own registry: >>> - ? >> >> - Developers know how to interoperate with each other when they are >> using the same hash algorithm > > What do you mean? A hash algorithm is just a mathematical function, no > matter where it is defined. It's not as if anything extra has to be > specified in order to use it with DANE. Registries are for identifiers. How do you know that "17" means "SHA-1" and not "SHA-256"? You look it up in a registry. > Be sure to count maintenance over time. Ummm, how much maintenance do you think is needed for a registry? Someone proposes a new hash algorithm, we say "yes, here's your number", and don. >> is probably worth the benefit of us being >> sure that it contains what we want for first developers. > > (*) You are proposing that the registry constitute implicit advice about > what algorithms developers should consider implementing beyond the > mandatory ones. No, I am *not*. Please don't put words in my mouth. I never said that. > Alternatively, we could use a wide-open registry Alternatively, we could (as I proposed earlier) use a registry with easy but not trivial registration and a bunch of pre-defined private use values. > and > give such advice elsewhere, or not give advice at all. Fully agree. > Assuming we give > advice, I prefer the separation of purposes in the second approach, but > it may still lead to vanity crypto trouble, in which case the advantage > over operating our own registry would be lost. Fully agree about the "advice elsewhere", but am open to what others might want. Different WGs in the IETF are wildly inconsistent on this. What is "vanity crypto trouble"? Someone registers their vanity crypto algorithm in our registry: what is the problem? >>> As Phill has pointed out >>> (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html), >>> OIDs are not any harder to use than any other registry because any given >>> application can just recognize the hard-coded prefixes for the >>> algorithms it supports. >> >> "hard-coded prefixes" means "our own registry", by definition. > > How so? Anyone can calculate the prefix for an OID without our > involvement. You do want interoperability, yes? If so, how would what you just proposed work? >> We gain nothing by using OIDs > > Assuming we want a completely open registry, the OID registry is a > popular one in which organizations can get their own subtrees (e.g., my > university has one) and then allocate globally unique identifiers. ...and no one knows how to interoperate. Well, they will know because someone will make a registry-like system that says which OIDs means what, and now we have the worst of both worlds. >> other than bytes of overhead > > It comes to about 20 bytes per record, and that will go down if full > compression of DNS responses is ever implemented. I think it's a small > price to pay for the elegance, but this is subjective. Quite. You seem to think that the problems that we have had in the PKIX world with muffed OIDs is worth the "elegance"; I disagree. >> plus forcing developers to understand their encoding. > > Not really, whoever advocates the use of a given algorithm with DANE > will publish all the information the developers need. And all the developers will be able to understand the OID encoding rules given with no errors, of course. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3933A6F26 for ; Thu, 6 Jan 2011 09:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDMYK6cOKmlr for ; Thu, 6 Jan 2011 09:37:11 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 5A24D3A6EFE for ; Thu, 6 Jan 2011 09:37:11 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 5A2CF25C064; Thu, 6 Jan 2011 09:39:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=qmnedu5feM0yTWp7JwnPzPvZx55M4cP8/+GBsnXVzgB n6IbCTtVXSY6Y0oxZaSVnoSPNd1rXnkjHnnaBKyHR+GncXsexS0AUqNG3M6e1HKK 1BuLg7Di2SP9y8cmy5lzs7s/U/rb78pWn/A+5M4i/MXzVuVPY8d8MUrFoZewuNrE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=WV+LxV3IUOKl2UGz7x+lVlXM1RI=; b=cGoy5f1KtU npQtwr/5c931or/GZWv/FeGEys3+ZLsK22j4+k9JK4D/aJu8l21OXqEe3md6QXvI riqjgzH+phY72kUsB8FujKGwnOIRfVVMZFOD0RDQ/d8BZntppJBXnH5/NBi0jb0M euTwG2VQJ0GXFFUvGKNsLD0HlueNAoVe0= Received: from [192.168.1.40] (pool-74-96-34-246.washdc.east.verizon.net [74.96.34.246]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id E110E25C063; Thu, 6 Jan 2011 09:39:17 -0800 (PST) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <4D25EFAE.8030506@vpnc.org> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> <4D25EFAE.8030506@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Jan 2011 12:39:16 -0500 Message-ID: <1294335556.2352.67.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 17:37:12 -0000 On Thu, 2011-01-06 at 08:37 -0800, Paul Hoffman wrote: > On 1/6/11 8:26 AM, Matt McCutchen wrote: > > On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote: > > Sure. So: > > > > Benefits of operating our own registry: > > - ? > > - Developers know how to interoperate with each other when they are > using the same hash algorithm What do you mean? A hash algorithm is just a mathematical function, no matter where it is defined. It's not as if anything extra has to be specified in order to use it with DANE. > - When a developer sees a record with a value for the hash algorithm > that they don't know, that developer can quickly determine if he cares > enough to update his implementation. See below (*) > > Benefits of reusing another appropriate registry: > > - We don't have to deal with political issues regarding "vanity crypto" > > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html) > > False: we are just exporting the problem to whomever is running the > registry we are using. Indeed. I said "we" meaning the DANE group. > That is, I have no problem with using someone else's registry, but the > overhead of creating our own (Jakob and I spend 10 minutes writing an > IANA Considerations section) Be sure to count maintenance over time. > is probably worth the benefit of us being > sure that it contains what we want for first developers. (*) You are proposing that the registry constitute implicit advice about what algorithms developers should consider implementing beyond the mandatory ones. Alternatively, we could use a wide-open registry and give such advice elsewhere, or not give advice at all. Assuming we give advice, I prefer the separation of purposes in the second approach, but it may still lead to vanity crypto trouble, in which case the advantage over operating our own registry would be lost. > > As Phill has pointed out > > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html), > > OIDs are not any harder to use than any other registry because any given > > application can just recognize the hard-coded prefixes for the > > algorithms it supports. > > "hard-coded prefixes" means "our own registry", by definition. How so? Anyone can calculate the prefix for an OID without our involvement. > We gain nothing by using OIDs Assuming we want a completely open registry, the OID registry is a popular one in which organizations can get their own subtrees (e.g., my university has one) and then allocate globally unique identifiers. > other than bytes of overhead It comes to about 20 bytes per record, and that will go down if full compression of DNS responses is ever implemented. I think it's a small price to pay for the elegance, but this is subjective. > plus forcing developers to understand their encoding. Not really, whoever advocates the use of a given algorithm with DANE will publish all the information the developers need. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35633A6E48 for ; Thu, 6 Jan 2011 08:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.668 X-Spam-Level: X-Spam-Status: No, score=-101.668 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2s3V-is65ht for ; Thu, 6 Jan 2011 08:34:57 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F1F7C3A6E39 for ; Thu, 6 Jan 2011 08:34:56 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p06Gb3xr077635 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 6 Jan 2011 09:37:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D25EFAE.8030506@vpnc.org> Date: Thu, 06 Jan 2011 08:37:02 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> <1294331212.2352.21.camel@mattlaptop2.local> In-Reply-To: <1294331212.2352.21.camel@mattlaptop2.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:34:57 -0000 On 1/6/11 8:26 AM, Matt McCutchen wrote: > On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote: > Sure. So: > > Benefits of operating our own registry: > - ? - Developers know how to interoperate with each other when they are using the same hash algorithm - When a developer sees a record with a value for the hash algorithm that they don't know, that developer can quickly determine if he cares enough to update his implementation. > Benefits of reusing another appropriate registry: > - Less work for us and for registrants (though maybe not by much, you > have said) True. > - We don't have to deal with political issues regarding "vanity crypto" > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html) False: we are just exporting the problem to whomever is running the registry we are using. That is, I have no problem with using someone else's registry, but the overhead of creating our own (Jakob and I spend 10 minutes writing an IANA Considerations section) is probably worth the benefit of us being sure that it contains what we want for first developers. > As Phill has pointed out > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html), > OIDs are not any harder to use than any other registry because any given > application can just recognize the hard-coded prefixes for the > algorithms it supports. "hard-coded prefixes" means "our own registry", by definition. We gain nothing by using OIDs other than bytes of overhead plus forcing developers to understand their encoding. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0556B3A6C4F for ; Thu, 6 Jan 2011 08:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.48 X-Spam-Level: X-Spam-Status: No, score=-103.48 tagged_above=-999 required=5 tests=[AWL=-1.503, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk71eRna9xHe for ; Thu, 6 Jan 2011 08:33:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 154513A6C2F for ; Thu, 6 Jan 2011 08:33:42 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p06GZmM7024141 for ; Thu, 6 Jan 2011 08:35:49 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294331749; bh=EGvL3fVs4phCBMPpgLrVo8sPVp0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Vqkehj5IN2hllsX44R+T5rD5iiuQi6lzAIZfl1xmB46iwgpcJBtSxJ4gnMGrVmqm4 kLTBmBkOKIJIoGZH04p3A== Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by kpbe16.cbf.corp.google.com with ESMTP id p06GZMK5029781 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 08:35:47 -0800 Received: by qyk7 with SMTP id 7so17819192qyk.0 for ; Thu, 06 Jan 2011 08:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i8/WZzZwJNNVoMu/CRkh/LlzmCCyLWT8NccsD7Hik8k=; b=ot9emU8tIc83QLjie0aknMzreLJTSMwDfXtkhex9eui4nVQYZqcdqlhGIf0Ux1lfmW 1JWwo8+rByXXhTinJ6sA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=p4+g1Gvueqp+7HXlj3tqPmWLuwjjPoOM0DYPhrtcHAEviGWWHartTVJgt19KBMOPd9 mlTVFmOyCvF1IDP9N2tg== MIME-Version: 1.0 Received: by 10.224.53.193 with SMTP id n1mr22856684qag.270.1294331747124; Thu, 06 Jan 2011 08:35:47 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 08:35:47 -0800 (PST) In-Reply-To: <1294331466.2352.25.camel@mattlaptop2.local> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <1294331466.2352.25.camel@mattlaptop2.local> Date: Thu, 6 Jan 2011 16:35:47 +0000 Message-ID: From: Ben Laurie To: Matt McCutchen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:33:44 -0000 On 6 January 2011 16:31, Matt McCutchen wrote: > On Thu, 2011-01-06 at 16:20 +0000, Ben Laurie wrote: >> On 6 January 2011 16:08, Matt McCutchen wrote: >> > I don't think this is a valid argument, in light of Phill's previous >> > comments on the subject. =A0Why would we have to choose which entries = are >> > valid, and not just state that any entry representing a hash algorithm >> > is potentially valid and let each implementation choose which ones to >> > support? >> >> Someone has to choose which ones are actually valid - you can't punt >> to implementations, because then interop is impossible. > > The mandatory algorithms provide interop. =A0If some parties wish to use > another algorithm, it is their responsibility to make sure the peer > supports it. This is how you end up with people using CRC-32 as a cryptographic hash. I don't think it is acceptable to burden developers with such decisions. I do agree that a route needs to be provided for those who want to do their own thing, though. But it must be clear that they're doing their own thing. Unless there's a registry which has appropriate policies around strength already in existence, that means its our problem to define what is OK to use and what is not. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490F63A6E25 for ; Thu, 6 Jan 2011 08:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS7BFBT6549Y for ; Thu, 6 Jan 2011 08:29:01 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 4E53A3A6C2F for ; Thu, 6 Jan 2011 08:29:01 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 5611734806E; Thu, 6 Jan 2011 08:31:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=HkFj8bZYH+ZpyKdqGdyYm0/dwOtFuDCSiptoHgybCoE YlAzPTJYIjcjN/b9aGy2vclTS1siBC+YkTJFYJ3suY2F3EPbfU93/p3kzoGzWqoQ n1XP+h0f/6hyObZjBJCtsghGRt67xKNMj8N75SECZ+aWgneu5Vm7XH6hUTH/alLo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=x19mkkeosYkJp0o6lvbFf+eCHNg=; b=V+ZdHEqIRq hrsAwPdrsFk29NVScDPXm5gKCbgzdIC8psoDjtzYuYR+NrHTSM+Q/eZfqIjf+PA6 AVZe7S7dpuPiSWTYvQE0T+tqYlBfA4txluQ3jdKZvRPWl5TNOmKa5+vToYa0/32g GeRYx3vvuwJ+v+GvLvnnpnmvy/efnMt98= Received: from [192.168.1.40] (pool-74-96-34-246.washdc.east.verizon.net [74.96.34.246]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id DD45B34806C; Thu, 6 Jan 2011 08:31:07 -0800 (PST) From: Matt McCutchen To: Ben Laurie In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Jan 2011 11:31:06 -0500 Message-ID: <1294331466.2352.25.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:29:02 -0000 On Thu, 2011-01-06 at 16:20 +0000, Ben Laurie wrote: > On 6 January 2011 16:08, Matt McCutchen wrote: > > I don't think this is a valid argument, in light of Phill's previous > > comments on the subject. Why would we have to choose which entries are > > valid, and not just state that any entry representing a hash algorithm > > is potentially valid and let each implementation choose which ones to > > support? > > Someone has to choose which ones are actually valid - you can't punt > to implementations, because then interop is impossible. The mandatory algorithms provide interop. If some parties wish to use another algorithm, it is their responsibility to make sure the peer supports it. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135DC3A6C4F for ; Thu, 6 Jan 2011 08:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhhVorFCZf42 for ; Thu, 6 Jan 2011 08:24:48 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id F28053A6C2F for ; Thu, 6 Jan 2011 08:24:47 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id EDDB125C06B; Thu, 6 Jan 2011 08:26:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=kpnI2SGtI86BiBFkp+N3pAjyo+EflQVD3Ig3f6KQUd7 qfGv3W75O6JaykZ2Kmmzoz8/gQ6owGGtUuG1hUNFEKfC6fJ097rck4h5mo22Hgkf AdWsP5kcvgo3qf45Vf7Qvd3i7ar2KpmYwVQQ9yXv8ZJlNzuVGV5JTq3JDTxyq2IY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=XOD1yemqSzu4TaeEIjgdO4MJxpE=; b=qJgszUbGwp 0Z+nrMWWdoE5NgcuXPoLAzlW8LarxA3JuqYlK2URjtzlsc6bQWK8JPqx6iBERX+5 Z1bQy9/bkmeH+75Q9gd7Xe4RCV1v3VVSin/R7OffDLxCsOHYyjAqkidumYAmwFGr vGluGIMVD5d3bC2mc8R2YRwkMURK0Kl/M= Received: from [192.168.1.40] (pool-74-96-34-246.washdc.east.verizon.net [74.96.34.246]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 72A1C25C06A; Thu, 6 Jan 2011 08:26:54 -0800 (PST) From: Matt McCutchen To: Paul Hoffman In-Reply-To: <4D25EA6B.2070201@vpnc.org> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> <4D25EA6B.2070201@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Jan 2011 11:26:52 -0500 Message-ID: <1294331212.2352.21.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:24:49 -0000 On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote: > On 1/6/11 8:08 AM, Matt McCutchen wrote: > > On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote: > > >> I vote for our own registry, the reason being that we will have to, in > >> any case, choose which entries in someone else's are valid, and which > >> are mandatory. By the time we've specified that we might as well > >> allocate our own identifiers, too. > > > > I don't think this is a valid argument, in light of Phill's previous > > comments on the subject. Why would we have to choose which entries are > > valid, and not just state that any entry representing a hash algorithm > > is potentially valid and let each implementation choose which ones to > > support? > > If our registry (a) is easy for someone to add to and (b) has plenty of > private use values pre-allocated, "we" would not have to choose which > entries are valid. Regardless, implementations would choose which ones > to support. Someone might make an applicability profile (like has just > been done in the DNSEXT WG for DNSSEC), and someone else might make a > different profile. Sure. So: Benefits of operating our own registry: - ? Benefits of reusing another appropriate registry: - Less work for us and for registrants (though maybe not by much, you have said) - We don't have to deal with political issues regarding "vanity crypto" (http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html) As Phill has pointed out (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html), OIDs are not any harder to use than any other registry because any given application can just recognize the hard-coded prefixes for the algorithms it supports. -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6653A6E1A for ; Thu, 6 Jan 2011 08:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.611 X-Spam-Level: X-Spam-Status: No, score=-103.611 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCxNb2YlWHre for ; Thu, 6 Jan 2011 08:18:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 506E03A6C2F for ; Thu, 6 Jan 2011 08:18:06 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p06GKCvJ010915 for ; Thu, 6 Jan 2011 08:20:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294330813; bh=/1JJLBDqonBdPY6MGvv1P1F7fb4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Rl1x9u3VnfSBCTLdpz5svXenScfCcmPJDkqKk9mhXKAnJhYcaFu58OJCwLdsA8iWF xEam37J2EgXTpDn1iZaxA== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by wpaz21.hot.corp.google.com with ESMTP id p06GJq8c016493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 08:20:11 -0800 Received: by qyk10 with SMTP id 10so17312582qyk.14 for ; Thu, 06 Jan 2011 08:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sYZQ0OuVwhfS3npzlY4+ZDaddamqNxPsvn/h3eGsTjc=; b=AeTTlGLejMlEhchvbQDPagaaTW9fv99LXRDtj1XvTnYLKlopMP8B1HEOGLygAvGTcP eVPMpBJdMeKebEEGDqsg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LumJCUOW9cNwOKJ4SqAOqKxJ1OjlOu9Z82Dd1Rx38bm8G9Uzfa/H8gkNh45HZHthR5 YydtnABHPE3jmDC7VJsg== MIME-Version: 1.0 Received: by 10.224.182.137 with SMTP id cc9mr22854041qab.320.1294330811173; Thu, 06 Jan 2011 08:20:11 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 08:20:11 -0800 (PST) In-Reply-To: <1294330098.2352.14.camel@mattlaptop2.local> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> Date: Thu, 6 Jan 2011 16:20:11 +0000 Message-ID: From: Ben Laurie To: Matt McCutchen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:18:08 -0000 On 6 January 2011 16:08, Matt McCutchen wrote: > On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote: >> On 5 January 2011 20:00, Warren Kumari wrote: >> > Matt will be adding additional issues to the tracker but for now can w= e try >> > and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticke= t/4 ? >> > Hopefully this will be one of the easier / less controversial issues t= o >> > address, and we can quickly wrap it up and move on... >> > >> > Please excuse the poor quality of the description -- the issue was cre= ated >> > from the thread: "Object Digest Reference" =A0(started here: >> > http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) = -- as >> > with many of our threads this went off the rails and didn't come to cl= ear >> > consensus. >> > I'd like us to revisit this and decide on a means of identifying what = the >> > hash / =A0cert type are. >> >> It seems to me there's a simplifying decision we can take, namely: our >> own registry or someone else's? If we choose our own, then a lot of >> pointless debate about which someone else can be avoided. >> >> I vote for our own registry, the reason being that we will have to, in >> any case, choose which entries in someone else's are valid, and which >> are mandatory. By the time we've specified that we might as well >> allocate our own identifiers, too. > > I don't think this is a valid argument, in light of Phill's previous > comments on the subject. =A0Why would we have to choose which entries are > valid, and not just state that any entry representing a hash algorithm > is potentially valid and let each implementation choose which ones to > support? Someone has to choose which ones are actually valid - you can't punt to implementations, because then interop is impossible. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ACCB3A6E53 for ; Thu, 6 Jan 2011 08:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.666 X-Spam-Level: X-Spam-Status: No, score=-101.666 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7scBUeH02ydw for ; Thu, 6 Jan 2011 08:12:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 235B23A6E30 for ; Thu, 6 Jan 2011 08:12:29 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p06GEZoX076426 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 6 Jan 2011 09:14:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D25EA6B.2070201@vpnc.org> Date: Thu, 06 Jan 2011 08:14:35 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> <1294330098.2352.14.camel@mattlaptop2.local> In-Reply-To: <1294330098.2352.14.camel@mattlaptop2.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:12:30 -0000 On 1/6/11 8:08 AM, Matt McCutchen wrote: > On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote: >> I vote for our own registry, the reason being that we will have to, in >> any case, choose which entries in someone else's are valid, and which >> are mandatory. By the time we've specified that we might as well >> allocate our own identifiers, too. > > I don't think this is a valid argument, in light of Phill's previous > comments on the subject. Why would we have to choose which entries are > valid, and not just state that any entry representing a hash algorithm > is potentially valid and let each implementation choose which ones to > support? If our registry (a) is easy for someone to add to and (b) has plenty of private use values pre-allocated, "we" would not have to choose which entries are valid. Regardless, implementations would choose which ones to support. Someone might make an applicability profile (like has just been done in the DNSEXT WG for DNSSEC), and someone else might make a different profile. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC8F03A6E30 for ; Thu, 6 Jan 2011 08:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.664 X-Spam-Level: X-Spam-Status: No, score=-101.664 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO-24zUvz7of for ; Thu, 6 Jan 2011 08:09:51 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C78A13A6C2F for ; Thu, 6 Jan 2011 08:09:51 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p06GBwrJ076313 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 6 Jan 2011 09:11:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D25E9CD.1040100@vpnc.org> Date: Thu, 06 Jan 2011 08:11:57 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: keyassure@ietf.org References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:09:52 -0000 On 1/6/11 7:56 AM, Ben Laurie wrote: > It seems to me there's a simplifying decision we can take, namely: our > own registry or someone else's? If we choose our own, then a lot of > pointless debate about which someone else can be avoided. > > I vote for our own registry, the reason being that we will have to, in > any case, choose which entries in someone else's are valid, and which > are mandatory. By the time we've specified that we might as well > allocate our own identifiers, too. +1 Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9645B3A6E30 for ; Thu, 6 Jan 2011 08:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKrFjkNfXVU0 for ; Thu, 6 Jan 2011 08:06:13 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id A8D873A6E1A for ; Thu, 6 Jan 2011 08:06:13 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 73EDD28006D; Thu, 6 Jan 2011 08:08:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=tEteiJVQV2MOWxdqkQlZWeRO0s/GmOoxx0oM5LjEFA4 9kNnVLosynzu/H6fLmu8CraE+v1oYo3kkdhwl1c54Fj7WNErbNo/0geOCR2o69g0 jESsKIFrNJXIZf1PcfRNn4hC0Uoi+mKLIapmQTaryQOVlR7ETm3INwHZWIpmj6c8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=XYz5Hz1mmub4Za52nusgpnu38Lo=; b=ZcjvUUJ2HL pVXaj6v8hilptRJbkwR+jW85pMzn9AViga4wi1tuygZLjMKtV/ZmOhv3TDNZmTsa 6gDk0qi2X9OPmT3GFfpk+NWXQduTpAZnYP3VnZTOWoqIByicPeCb2qT8X/sy/3Kj iQNkcwaTDHYaP4P6eqsGUCmuoKWKCuYe0= Received: from [192.168.1.40] (pool-74-96-34-246.washdc.east.verizon.net [74.96.34.246]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 0567B280069; Thu, 6 Jan 2011 08:08:19 -0800 (PST) From: Matt McCutchen To: Ben Laurie In-Reply-To: References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 Jan 2011 11:08:18 -0500 Message-ID: <1294330098.2352.14.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:06:14 -0000 On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote: > On 5 January 2011 20:00, Warren Kumari wrote: > > Matt will be adding additional issues to the tracker but for now can we try > > and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4 ? > > Hopefully this will be one of the easier / less controversial issues to > > address, and we can quickly wrap it up and move on... > > > > Please excuse the poor quality of the description -- the issue was created > > from the thread: "Object Digest Reference" (started here: > > http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) -- as > > with many of our threads this went off the rails and didn't come to clear > > consensus. > > I'd like us to revisit this and decide on a means of identifying what the > > hash / cert type are. > > It seems to me there's a simplifying decision we can take, namely: our > own registry or someone else's? If we choose our own, then a lot of > pointless debate about which someone else can be avoided. > > I vote for our own registry, the reason being that we will have to, in > any case, choose which entries in someone else's are valid, and which > are mandatory. By the time we've specified that we might as well > allocate our own identifiers, too. I don't think this is a valid argument, in light of Phill's previous comments on the subject. Why would we have to choose which entries are valid, and not just state that any entry representing a hash algorithm is potentially valid and let each implementation choose which ones to support? -- Matt Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09103A6E30 for ; Thu, 6 Jan 2011 07:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.685 X-Spam-Level: X-Spam-Status: No, score=-103.685 tagged_above=-999 required=5 tests=[AWL=-1.708, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qSNWHMSqr7B for ; Thu, 6 Jan 2011 07:54:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8E7E33A6DD4 for ; Thu, 6 Jan 2011 07:54:16 -0800 (PST) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p06FuMaj006988 for ; Thu, 6 Jan 2011 07:56:22 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294329383; bh=fhSxIHIOC4odTjCSxF2Gx9dC3zE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=FLpvZZGX3vHROu5hfNtnMyZ8hVP6VZtKzcS2CeSDBhiD44uiztdovGBs46jyp06L+ 93FfTOMynM28vTgeLr+Mw== Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by hpaq2.eem.corp.google.com with ESMTP id p06FtC3N021326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 07:56:21 -0800 Received: by qyk7 with SMTP id 7so17982954qyk.14 for ; Thu, 06 Jan 2011 07:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R2VMDhISrOnBDBEmt6T4o8maS/eCU/yFedQ9iPJnI9Y=; b=bkyLVMUQmkbXGdB39K9NJm/Q44qKJcmuJWXlFNoP+jT84k60LfhTeB+hqgcnd0D0z6 MfWqXPvJKH/j5lHtZcAg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FWgcc/7HhW+dq+SUTM+QKIexq1c7QAwR22YtSwlHnNQYS6xqzbu6UkbEhnGWthwOVn x9ZPDqc58PkRhPVOv3cw== MIME-Version: 1.0 Received: by 10.224.73.134 with SMTP id q6mr22867868qaj.220.1294329381205; Thu, 06 Jan 2011 07:56:21 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 07:56:21 -0800 (PST) In-Reply-To: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> References: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> Date: Thu, 6 Jan 2011 15:56:21 +0000 Message-ID: From: Ben Laurie To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:54:18 -0000 On 5 January 2011 20:00, Warren Kumari wrote: > Matt will be adding additional issues to the tracker but for now can we t= ry > and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4= ? > Hopefully this will be one of the easier / less controversial issues to > address, and we can quickly wrap it up and move on... > > Please excuse the poor quality of the description -- the issue was create= d > from the thread: "Object Digest Reference" =A0(started here: > http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) -- = as > with many of our threads this went off the rails and didn't come to clear > consensus. > I'd like us to revisit this and decide on a means of identifying what the > hash / =A0cert type are. It seems to me there's a simplifying decision we can take, namely: our own registry or someone else's? If we choose our own, then a lot of pointless debate about which someone else can be avoided. I vote for our own registry, the reason being that we will have to, in any case, choose which entries in someone else's are valid, and which are mandatory. By the time we've specified that we might as well allocate our own identifiers, too. Cheers, Ben. Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E02A3A6C9F for ; Wed, 5 Jan 2011 11:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXgBNIy1vCdS for ; Wed, 5 Jan 2011 11:58:15 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id AAD9E3A6C78 for ; Wed, 5 Jan 2011 11:58:15 -0800 (PST) Received: by smtp.kumari.net (Postfix, from userid 5001) id D82D72284A56; Wed, 5 Jan 2011 15:00:21 -0500 (EST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 20668228497C for ; Wed, 5 Jan 2011 15:00:21 -0500 (EST) Message-Id: <4C1CD2A9-F9B4-4136-A9DC-69BDB5B1689D@kumari.net> From: Warren Kumari To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 5 Jan 2011 15:00:20 -0500 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types." X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:58:17 -0000 Hello all, I'd like us to start working through the issues that we have listed in the tracker (http://trac.tools.ietf.org/wg/dane/trac/report/1) -- this will hopefully allow us to actually come to some consensus and avoid having the same set of discussions over and over again... Matt will be adding additional issues to the tracker but for now can we try and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4 ? Hopefully this will be one of the easier / less controversial issues to address, and we can quickly wrap it up and move on... Please excuse the poor quality of the description -- the issue was created from the thread: "Object Digest Reference" (started here: http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) -- as with many of our threads this went off the rails and didn't come to clear consensus. I'd like us to revisit this and decide on a means of identifying what the hash / cert type are. W -- "Real children don't go hoppity-skip unless they are on drugs." -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather) Return-Path: X-Original-To: keyassure@core3.amsl.com Delivered-To: keyassure@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA623A6D3C for ; Tue, 4 Jan 2011 15:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAQ7DuSCciHk for ; Tue, 4 Jan 2011 15:44:11 -0800 (PST) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 5C0363A6ABF for ; Tue, 4 Jan 2011 15:44:11 -0800 (PST) Received: by smtp.kumari.net (Postfix, from userid 5001) id F0EE52284B18; Tue, 4 Jan 2011 18:46:17 -0500 (EST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 5FF66228491F for ; Tue, 4 Jan 2011 18:46:17 -0500 (EST) Message-Id: From: Warren Kumari To: keyassure@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 4 Jan 2011 18:46:17 -0500 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Apology... X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 23:44:12 -0000 Hi all, I'd just quickly like to apologize for not having been nearly as involved recently as I should have been -- I got sidetracked with $dayjob (and other things) and haven't been giving DANE as much attention as it deserves. I have almost managed to clean off my plate (and dig out from under a mountain of mail) and should be able to devote more time soon... Apologies again, W -- "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)