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 B7E913A6A1D for ; Mon, 28 Feb 2011 10:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 5KzSaZ0mdB4O for ; Mon, 28 Feb 2011 10:53:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 69C113A6A31 for ; Mon, 28 Feb 2011 10:53:23 -0800 (PST) Received: from dhcp89-089-216.bbn.com ([128.89.89.216]:49168) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pu8Eg-000GNy-8Q; Mon, 28 Feb 2011 13:54:22 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201102241727.p1OHRWQK019306@fs4113.wdf.sap.corp> References: <201102241727.p1OHRWQK019306@fs4113.wdf.sap.corp> Date: Mon, 28 Feb 2011 13:40:46 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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: Mon, 28 Feb 2011 18:53:26 -0000 At 6:27 PM +0100 2/24/11, Martin Rex wrote: >... > > In the IETF, PKIX profiles X.509 for use with IETF security protocols, >> so it probably makes sense to stick with the PKIX label here. This is >> certainly true for EE certs. For a self-signed cert used to convey >> trust anchor material, we may need some additional/different text. > > >But this would imply that EE certs will have to be issued by commercial CAs. no. anyone can be a CA. >I thought that one of the purposes of DANE was to allow server admins >to create their own certificate and distribute it through DNS(SEC) TLSA >records. see comment above. >Maybe we should distinguish more types: > > 1 -- An end-entity X.509 certificate in ASN.1 DER encoding > > 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding > > 3 -- An end-entity PKIX certificate from the TLS X.509 PKI > > 4 -- A certification authority's PKIX certificate from the TLS X.509 PKI > >For (1), the client would match the server certificate with the TLSA >record and be done with it, for (3), besides matching the server certificate >with the TLSA record, the client is expected to perform a regular >certificate path validation. as others have pointed out, X.509 vs. PKIX is not generally a meaningful distinction in this context, so the wording above is confusing, at best. I plan to work with Paul to generate appropriate text, to match PKIX standards, while preserving the intent of the DANE docs. 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 EA81B3A6A96 for ; Mon, 28 Feb 2011 08:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 nXGsrDLa9H74 for ; Mon, 28 Feb 2011 08:10:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 16DF03A69FE for ; Mon, 28 Feb 2011 08:10:15 -0800 (PST) Received: from dhcp89-089-216.bbn.com ([128.89.89.216]:49154) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pu5gp-000Kzu-0l; Mon, 28 Feb 2011 11:11:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> <4D617535.9040404@vpnc.org> Date: Mon, 28 Feb 2011 10:12:01 -0500 To: Ben Laurie From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Mon, 28 Feb 2011 16:10:16 -0000 At 3:12 PM +0000 2/25/11, Ben Laurie wrote: >... > > if you issue a cert, you are a CA > >Eh? If I make a self-signed cert, am I a CA? yes. >If I publish an EE cert issued by someone else, am I a CA? no. publishing is not the same as issuing. any 3rd party can publish any cert. >Presumably at least one of these is a "no", so the zone operator is >not necessarily a CA. This was my point. OK. >... > > It would not be useful to you, but rather to someone who puts it in a >> DNS record, if that someone does so on your behalf. Otherwise that entity >> does not know if the public key really is yours. But, I don't know that >> this results in a vulnerability for the DANE context. > >Ah. If I am asking someone else to update DNS for me, then indeed a >PoP might be appropriate. But surely that's an issue for whatever >protocol I am using for speaking with my DNS provider? seems reasonable to me. 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 6F6D93A6A18 for ; Sun, 27 Feb 2011 09:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.481 X-Spam-Level: X-Spam-Status: No, score=-101.481 tagged_above=-999 required=5 tests=[AWL=0.565, 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 47uOr9oSVDMj for ; Sun, 27 Feb 2011 09:28:51 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BA2813A6A13 for ; Sun, 27 Feb 2011 09:28: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 p1RHSYtp030490 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 27 Feb 2011 10:28:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6A89C2.3030101@vpnc.org> Date: Sun, 27 Feb 2011 09:28:34 -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: Jakob Schlyter References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <4D6826FE.2080107@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] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" 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, 27 Feb 2011 17:28:52 -0000 On 2/27/11 4:27 AM, Jakob Schlyter wrote: > On 25 feb 2011, at 23.02, Paul Hoffman wrote: > >> Hash algorithm: >> >> - All implementations must support SHA-256. > > i.e., reference type 2. > >> - All implementations should have the facility to later use other hash algorithms. > > Also, all implementations must support reference type 0 (aka "full certificate"). Er, right, of course. That too. 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 C8C173A6827 for ; Sun, 27 Feb 2011 04:26:45 -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=[AWL=0.000, 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 WfoK1WeGbgDF for ; Sun, 27 Feb 2011 04:26:44 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 1EEEC3A6803 for ; Sun, 27 Feb 2011 04:26:43 -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=l42WhTADT6eQBaRW5U0OIG7l/VWfsgV7ZEEH/B3EN2E=; b=GcSxsYT3klEF8rqhQYL76m8tH/wnJCXG0oxiKILVObfPItkcs9Hx9Tk0husG6G4HWk89vsG+JXted EI7CsKoqVnYWWm3dFZuA6CWMGmSmwalQ77VCLrByJ+1YTnHZlo2II+IwubnZGQNvyZdtm0qok5HOpc mXzYo4ml4sHOe2Uw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 27 Feb 2011 13:27:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4D6826FE.2080107@vpnc.org> Date: Sun, 27 Feb 2011 13:27:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> <4D6826FE.2080107@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" 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, 27 Feb 2011 12:26:45 -0000 On 25 feb 2011, at 23.02, Paul Hoffman wrote: > Hash algorithm: >=20 > - All implementations must support SHA-256. i.e., reference type 2. > - All implementations should have the facility to later use other hash = algorithms. Also, all implementations must support reference type 0 (aka "full = certificate"). 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 D22EB3A695E for ; Sat, 26 Feb 2011 17:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8QyBHidU2ir for ; Sat, 26 Feb 2011 17:26:22 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 1066A3A6939 for ; Sat, 26 Feb 2011 17:26:21 -0800 (PST) Received: from [192.168.0.150] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id ED0241B40ACC; Sat, 26 Feb 2011 20:27:17 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Feb 2011 20:27:16 -0500 Message-Id: <1DBC6AE4-C860-4936-8EB5-30736B7202E0@kumari.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: Re: [keyassure] [dane] protocol #19 (new): Format for TLSA DNS lookup. 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, 27 Feb 2011 01:26:23 -0000 I believe that this issue has been addressed, both in numerous = discussions and in version -05 of the draft, section 2.1 ("Requested = Domain Name") No-one has objected to the text in the section, so I'm closing this = issue. If you do object to the text, you must offer alternative = (better!) text... W [ DANE is also beta testing the email2trac functionality -- this should = show up in 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 114CD3A6A48 for ; Fri, 25 Feb 2011 14:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.473 X-Spam-Level: X-Spam-Status: No, score=-101.473 tagged_above=-999 required=5 tests=[AWL=0.573, 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 jZKSd+NpCRuU for ; Fri, 25 Feb 2011 14:01:46 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4CA483A68BC for ; Fri, 25 Feb 2011 14:01: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 p1PM2c2c060661 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 25 Feb 2011 15:02:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6826FE.2080107@vpnc.org> Date: Fri, 25 Feb 2011 14:02: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: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> In-Reply-To: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" 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, 25 Feb 2011 22:01:47 -0000 On 2/25/11 1:31 PM, Warren Kumari wrote: > Hi all, > > While we are all ruminating on the other issues, I figured we might as > well try address this one: > > Need to specify which crypto algorithms and certificate types are > mandatory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21 > > Description: > Currently, the draft is silent on which crypto algorithms and > certificate types must be implemented for interoperability. It should be > specific before the document is finished. Certificate type: - Writing both type 1 and 2 must be supported by all DNS implementations - Processing type 1 must be supported by all TLS clients. - Processing type 2 should be supported by all TLS clients. The exceptions are TLS clients that do not use the PKIX certificate format for trust anchors. Hash algorithm: - All implementations must support SHA-256. - All implementations should have the facility to later use other hash algorithms. 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 7125B3A6A5A for ; Fri, 25 Feb 2011 13:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.029, 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 PGounF-A1u2L for ; Fri, 25 Feb 2011 13:51:15 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A95C23A6A48 for ; Fri, 25 Feb 2011 13:51:13 -0800 (PST) Received: by bwz13 with SMTP id 13so2719567bwz.31 for ; Fri, 25 Feb 2011 13:52:06 -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=eZeYnkANfzuQkQIeGFpKqPdGCOmAP1ZngB2DaNFE0J4=; b=oCHOyju/JANN3PnMco9Jvu0SpkxoEmjfSHpvQuknZXJKPaJRQrd4Acav8N5MkJ0NWg F0KtiRFjiQz8pDmb68+AIgo1usl0tHc5pI7dhbuJAm6qFPsRWlQn/9S4TTcXbm/WEARq ojb3nZW7lK3LeaZgPnkXjEaNHVM6UKkNJ/Rqg= 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=KljMTYtkb6iz10tEyrxVkJvWcGDiN8ro+FVNUdaGtkrdcDyUYt3HJpRyK08dCw75n7 0sl3wf3Miv2Q1VbSImipb/2tAM4HxwboOKeoqDx/7yRGGugHEEDOQ4Kyjn+RT//tLN45 ru0D4aGu1sIwXosC5HRpQb1eyUP2Lb/tqpSaQ= MIME-Version: 1.0 Received: by 10.204.52.136 with SMTP id i8mr2466912bkg.74.1298670726141; Fri, 25 Feb 2011 13:52:06 -0800 (PST) Received: by 10.204.14.139 with HTTP; Fri, 25 Feb 2011 13:52:06 -0800 (PST) In-Reply-To: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> References: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@kumari.net> Date: Fri, 25 Feb 2011 16:52:06 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=001636c5bc0f4fd965049d225780 Cc: keyassure@ietf.org Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" 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, 25 Feb 2011 21:51:16 -0000 --001636c5bc0f4fd965049d225780 Content-Type: text/plain; charset=ISO-8859-1 Currently, the only digest algorithm that can be recommended is SHA-2 We really do need SHA2 in here as a MUST, unless we are still discussing this when the SHA3 competition results are out. I would strongly suggest NOT supporting SHA1 in any form. On Fri, Feb 25, 2011 at 4:31 PM, Warren Kumari wrote: > Hi all, > > While we are all ruminating on the other issues, I figured we might as well > try address this one: > > Need to specify which crypto algorithms and certificate types are mandatory > to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21 > > Description: > Currently, the draft is silent on which crypto algorithms and certificate > types must be implemented for interoperability. It should be specific before > the document is finished. > > > W > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636c5bc0f4fd965049d225780 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Currently, the only digest algorithm that can be recommended is SHA-2
<= br>
We really do need SHA2 in here as a MUST, unless we are still= discussing this when the SHA3 competition results are out.


I would strongly suggest NOT supporting SHA1= in any form.

On Fri, Feb 25, 2011 at 4:3= 1 PM, Warren Kumari <warren@kumari.net> wrote:
Hi all,

While we are all ruminating on the other issues, I figured we might as well= try address this one:

Need to specify which crypto algorithms and certificate types are mandatory= to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21=

Description:
Currently, the draft is silent on which crypto algorithms and certificate t= ypes must be implemented for interoperability. It should be specific before= the document is finished.


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



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

--001636c5bc0f4fd965049d225780-- 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 2A8803A6A60 for ; Fri, 25 Feb 2011 13:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 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 I3a2ZdjTNA1p for ; Fri, 25 Feb 2011 13:30:50 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id D980A3A6A6E for ; Fri, 25 Feb 2011 13:30:49 -0800 (PST) Received: from [172.19.118.186] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E273B1B41296 for ; Fri, 25 Feb 2011 16:31:42 -0500 (EST) Message-Id: <9933A160-3DAF-42FA-B5FA-DDF185FA5C63@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: Fri, 25 Feb 2011 16:31:40 -0500 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement" 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, 25 Feb 2011 21:30:53 -0000 Hi all, While we are all ruminating on the other issues, I figured we might as well try address this one: Need to specify which crypto algorithms and certificate types are mandatory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21 Description: Currently, the draft is silent on which crypto algorithms and certificate types must be implemented for interoperability. It should be specific before the document is finished. 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 DBE2C3A68B1 for ; Fri, 25 Feb 2011 09:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 o+9rhpj-9Abp for ; Fri, 25 Feb 2011 09:14:39 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 13E3B3A679F for ; Fri, 25 Feb 2011 09:14:38 -0800 (PST) Received: from [172.19.118.186] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 32B681B40ACC for ; Fri, 25 Feb 2011 12:15:30 -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: Fri, 25 Feb 2011 12:15:29 -0500 X-Mailer: Apple Mail (2.936) Subject: [keyassure] Meeting in Prague. 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, 25 Feb 2011 17:14:40 -0000 Hello all. We have been granted a meeting slot in Prague. If anyone wants agenda time to discuss things *in our charter*, let the chairs know well ahead of time so that we can schedule you. TLS is also scheduled to meet -- if what you want to discuss involves changes to TLS (like bare keys), please take it to TLS.... Also, if you want to suggest something like TLSA for a non-TLS protocol that doesn't already have keys, that is fine too, *as long as you have a published draft before the meeting*. Cutoff date for -00 submissions: 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF ID Submission Tool. Thank you and hope to see you in Prague! 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 40BF73A69C3 for ; Fri, 25 Feb 2011 07:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 OVPNAjHLbnFl for ; Fri, 25 Feb 2011 07:11:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 1521E3A69E9 for ; Fri, 25 Feb 2011 07:11:41 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p1PFCXdf025293 for ; Fri, 25 Feb 2011 07:12:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298646754; bh=KskDWELEAYoKWVsPB1AxetTR+Ls=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=w3xQ3YHfZ1AMdxGzhu2lKEai2YP7HQM8WFovbsj9EBhH+8uJa3AJfh065fn3hHa4n EgTloO02ui3OS7KLvp8PQ== Received: from vxd7 (vxd7.prod.google.com [10.241.33.199]) by wpaz33.hot.corp.google.com with ESMTP id p1PFCSNa019460 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 25 Feb 2011 07:12:32 -0800 Received: by vxd7 with SMTP id 7so1431380vxd.6 for ; Fri, 25 Feb 2011 07:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8AmGnupDoVRX3bL6WwACJntEpIyBxWhKjZLp2OKhzPo=; b=rXmOUvTmAOmyHIffP/U94rawGhEz3VAftxn6B97cjokYpWJHKPL3bDqnsRyy7thd+d M2bSJ/rbzDMHAGbxdxHw== 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=kWKbp5g9VlCPErquhgDgUzgkS62W5FISBEK5lHsKcd9ISs8sMezccmao7OpjxVqkP1 hF2TDKNX3r5ts5xN/fZQ== MIME-Version: 1.0 Received: by 10.52.168.229 with SMTP id zz5mr4156592vdb.28.1298646751366; Fri, 25 Feb 2011 07:12:31 -0800 (PST) Received: by 10.220.88.137 with HTTP; Fri, 25 Feb 2011 07:12:31 -0800 (PST) In-Reply-To: References: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> <4D617535.9040404@vpnc.org> Date: Fri, 25 Feb 2011 15:12:31 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Fri, 25 Feb 2011 15:11:43 -0000 On 22 February 2011 01:01, Stephen Kent wrote: >> ... >> =A0> >>> >>> =A0I agree that the info in the record could be a TA, and not a CA, but= not >>> if >>> =A0the format of the data is an X.509 cert. >> >> You said a minute ago: "if you issue an X.509 cert under which other >> certs will be validated, >> you are a CA." > > yep. > >> This sounds correct to me. However, mostly what's being done here is >> _not_ the issuing of X.509 certs under which other certs will be >> validated (though it is an option), so most times the zone operator is >> not a CA. > > I though one option was to place a cert in the DNS and use it as the > basis for validating a cert chain that terminates at the EE cert for the > web site. =A0If so, then that cert is used to validate other certs and > it would generally be viewed as a CA cert. =A0I admit that some ambiguity > arises when the cert is viewed as a TA. The ambiguity arises because In > general, > if you issue a cert, you are a CA Eh? If I make a self-signed cert, am I a CA? If I publish an EE cert issued by someone else, am I a CA? Presumably at least one of these is a "no", so the zone operator is not necessarily a CA. This was my point. >, but when a cert used to convey TA data, > an RP may elect to not check all of the data. > > We do have TA format standards that make it clear what data is to be chec= ked > and it might be preferable to use them, vs. a self-signed cert (although = the > later option might minimize code reuse). > >> In any case it does seem worth making clear when we are talking about >> a PKIX CA vs. any other kind. > > It's really =A0not a "PKIX CA" per se; it's an X.509 CA. > >> =A0> Also, will not performing PoP be a >>> >>> =A0good outcome? >> >> What would be the point of proving to myself that I own a key? > > It would not be useful to you, but rather to someone who puts it in a > DNS record, if that someone does so on your behalf. Otherwise that entity > does not know if the public key really is yours. =A0But, I don't know tha= t > this results in a vulnerability for the DANE context. Ah. If I am asking someone else to update DNS for me, then indeed a PoP might be appropriate. But surely that's an issue for whatever protocol I am using for speaking with my DNS provider? > > 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 C75EE3A67F5 for ; Thu, 24 Feb 2011 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 SUrbqpZFxynW for ; Thu, 24 Feb 2011 09:27:06 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7EB903A67F4 for ; Thu, 24 Feb 2011 09:27:05 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1OHRXYY008471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Feb 2011 18:27:33 +0100 (MET) From: Martin Rex Message-Id: <201102241727.p1OHRWQK019306@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 24 Feb 2011 18:27:32 +0100 (MET) In-Reply-To: from "Stephen Kent" at Feb 23, 11 09:08:50 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] I-D Action:draft-ietf-dane-protocol-05.txt 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, 24 Feb 2011 17:27:06 -0000 Stephen Kent wrote: > > At 3:05 PM +0100 2/23/11, Martin Rex wrote: > >Jakob Schlyter wrote: > >> > >> On 23 feb 2011, at 12.04, Ben Laurie wrote: > >> > >> > 1 -- A PKIX end-entity certificate in DER encoding > >> > > >> > 2 -- A PKIX certification authority's certificate in DER encoding > >> > >> I agree this is a reasonable clarification. > > > >If anything, I would really prefer something like > > > > 1 -- An end-entity X.509 certificate in ASN.1 DER encoding > > > > 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding > > > > In the IETF, PKIX profiles X.509 for use with IETF security protocols, > so it probably makes sense to stick with the PKIX label here. This is > certainly true for EE certs. For a self-signed cert used to convey > trust anchor material, we may need some additional/different text. But this would imply that EE certs will have to be issued by commercial CAs. I thought that one of the purposes of DANE was to allow server admins to create their own certificate and distribute it through DNS(SEC) TLSA records. Maybe we should distinguish more types: 1 -- An end-entity X.509 certificate in ASN.1 DER encoding 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding 3 -- An end-entity PKIX certificate from the TLS X.509 PKI 4 -- A certification authority's PKIX certificate from the TLS X.509 PKI For (1), the client would match the server certificate with the TLSA record and be done with it, for (3), besides matching the server certificate with the TLSA record, the client is expected to perform a regular certificate path validation. -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 9EA2C3A67E4 for ; Wed, 23 Feb 2011 19:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 kXRWnSY0vi8F for ; Wed, 23 Feb 2011 19:56:07 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 23C673A67D6 for ; Wed, 23 Feb 2011 19:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298519816; x=1330055816; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |Subject:=20Re:=20[keyassure]=20I-D=20Action:draft-ietf-d ane-protocol-05.txt|In-Reply-To:=20<4D65303D.5040704@vpnc .org>|Message-Id:=20|Date:=20Thu,=2024=20Feb=202011=2016:56:46=20+13 00; bh=9uhYRVuBQjJXQ+zvOnHidsWv8jV/V5MIO1sVEb9eJ2Y=; b=EbmLlIyIj5sOOM7XX8XwRon6r1Lb9oFaQGL+4DgY7MiTt/kuvCTrM3K7 K8PPYQqE3HSIhxRF1kOC+oKXYBPFMEgPgv6RkjdyJzMatnagKB0AJ/QYk 3aTl3s3F+x4jHU+ybtZ0Sjalg6uF491jmEBoOLAOh00jOhHfI3mGdK8bu Y=; X-IronPort-AV: E=Sophos;i="4.62,214,1296990000"; d="scan'208";a="47623866" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Feb 2011 16:56:46 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PsSJq-0004JJ-HM; Thu, 24 Feb 2011 16:56:46 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PsSJq-00051V-An; Thu, 24 Feb 2011 16:56:46 +1300 From: Peter Gutmann To: keyassure@ietf.org, paul.hoffman@vpnc.org In-Reply-To: <4D65303D.5040704@vpnc.org> Message-Id: Date: Thu, 24 Feb 2011 16:56:46 +1300 Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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: Thu, 24 Feb 2011 03:56:08 -0000 Paul Hoffman writes: >X.509 is a standard that does not contain all of the extensions created by >the PKIX Working Group in the IETF. Using "PKIX" makes it clear that we are >talking about certificates with the IETF extensions, not certificates missing >them. This is just getting excessively pedantic. Everyone knows what an "X.509 certificate" is, standards have been specifying this for years and implementers have been able to work with them without having to say "An X.509 certificate conformant to the PKIX profile encoded using X.690 ASN.1 DER encoding". In any case since conformance to X.509, PKIX, and DER is more or less arbitrary, if you truly required strict X.509 + PKIX + DER, hundreds of thousands/millions of certs out there would fail to meet the spec. All you need to say is "a vaguely certificate-shaped object", which "X.509 cert" does admirably. Peter. 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 9CFFA3A6984 for ; Wed, 23 Feb 2011 19:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAvtyfadADdX for ; Wed, 23 Feb 2011 19:51:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8426D3A67F8 for ; Wed, 23 Feb 2011 19:51:28 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40350 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsSFT-0007F1-6D; Wed, 23 Feb 2011 22:52:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201102231405.p1NE56H3015575@fs4113.wdf.sap.corp> References: <201102231405.p1NE56H3015575@fs4113.wdf.sap.corp> Date: Wed, 23 Feb 2011 21:08:50 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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: Thu, 24 Feb 2011 03:51:29 -0000 At 3:05 PM +0100 2/23/11, Martin Rex wrote: >Jakob Schlyter wrote: >> >> On 23 feb 2011, at 12.04, Ben Laurie wrote: >> >> > 1 -- A PKIX end-entity certificate in DER encoding >> > >> > 2 -- A PKIX certification authority's certificate in DER encoding >> >> I agree this is a reasonable clarification. > >If anything, I would really prefer something like > > 1 -- An end-entity X.509 certificate in ASN.1 DER encoding > > 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding > In the IETF, PKIX profiles X.509 for use with IETF security protocols, so it probably makes sense to stick with the PKIX label here. This is certainly true for EE certs. For a self-signed cert used to convey trust anchor material, we may need some additional/different text. 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 6C42C3A67D6 for ; Wed, 23 Feb 2011 19:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxF4p8bHb-wP for ; Wed, 23 Feb 2011 19:50:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 24EDD3A67A8 for ; Wed, 23 Feb 2011 19:50:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40350 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsSEv-0007F1-4q; Wed, 23 Feb 2011 22:51:42 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110222044358.GC25182@odin.mars.sol> References: <20110221144527.GB25182@odin.mars.sol> <20110222044358.GC25182@odin.mars.sol> Date: Wed, 23 Feb 2011 22:23:10 -0500 To: Scott Schmit From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 24 Feb 2011 03:50:55 -0000 Scott, Sorry my reply got stuck in my outbox for a day or so. >On Mon, Feb 21, 2011 at 08:38:43PM -0500, Stephen Kent wrote keyassure: >> At 9:45 AM -0500 2/21/11, Scott Schmit wrote: >> For DANE we should generate a profile indicating what extensions >> MUST be present, MUST be omitted, MAY be present, etc. We also can >> limit the types of values allowed in standard cert fields, to further >> simplify generation and parsing. This is what we did for SIDR. > >This assumes that the only certificates that you're interested in using >with DANE are newly-generated self-signed certificates. What does a web >site like Amazon or IETF do if they don't want to break existing users >that don't have DANE support and don't want to setup dane.amazon.com or >dane.ietf.org? If the rules defined for DANE-compatible certs happen >to be what they already have, then great, but will that work for all the >existing certs out there? I was describing constraints for a cert to be stored in the DNS, and to be used as a CA/TA. These are newly-generated certs, and I was addressing the arguments about the potential complexity of using X.509 certs for this purpose. So, is the motivation here that Amazon wants to use DANE to protect itself from rogue TAs in browsers? An X.509 EE cert contains the name of its issuer. The problem with trying to have the same EE cert be verified by the existing, browser-based TA and a TA acquired via DANE, is that they would need to have the same Subject name. If that name must match the DNS name from which the record was obtained, there is a problem :-) trying to convey or reference a common TA. >I could also imagine putting a CA certificate in the DNS so that the >organization doesn't need to deal with renewing the CA cert and also >updating the DNS. EEs have no control over the CA's certs. What CA cert? A web site has an EE cert, it does mot have a CA cert to renew (typically). Did you mean not renewing its EE cert? >... > > Not sure what you mean here by "sanitizing." > >Not letting the nasty stuff through. Not saying they never make >mistakes, but stuff that causes outright vulnerabilities I would imagine >they fix (even if it takes a public shaming first). I don't know that ASN.1 parsing vulnerabilities are still a valid concern, but at least I understand your point. > > >Even if we reuse pieces of what's there, they're still invasive changes >> >to ASN.1/X.509 parsing code--the very stuff that has had all those >> >problems. Also, the non-DANE case isn't going away overnight, so both >> >cases must still be covered (complicating the logic), and the more >> >difficult DANE is to adopt, the less overnight it'll be. >> >> What non-DANE cases do you have in mind? > >The status quo today--the world without DANE. I now understand what the "non-DANE" cases are, but I don't understand your argument. The way the DANE doc reads mow, there do not appear to be any changes to cert parsing. > > >* Validity vs RRSIG period [take the min period] >> >> This need mot be an issue. You will process the DNS TTL first, and reject >> the record if it is expired. If the TTL is OK, then why not process the >> cert validity interval separately, when performing cert path validation. > >I probably misstated my intent. What you described is what I meant. It's >probably better stated as "obey both". OK. > > >* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated] >> >> TTL is not really equivalent to a CRL or OCSP. It is analogous to the >> cert validity interval. The question here is whether a cert retrieved from >> the DNS is a TA, or not. if it is, then it will not be revoked via >> a CRL or OCSP, buy the very nature of a TA. But, if the cert is not >> a TA, the question of what sort of revocation mechanism is used is >> relevant. > >I shouldn't have put TTL there. Martin Rex points out TTL isn't covered >by DNSSEC (and how can it be? it's supposed to count down!), so for as >long as the RRSIG is valid, an attacker can simply keep resending the >same record any time the TTL expires. Instead, it's RRSIG (or something >else). > >While you're right that the RRSIG period is basically a validity period, >it's also not quite the same because of who is doing the signing. With >CAs today, no one would tolerate a validity of two weeks because they'd >need to get a cert reissued from the CA constantly. On the other hand, >shorter periods are typical in DNSSEC. By having the signing keys, >making the RRSIG period be short isn't so onerous as long as you can >automate the process. Some folks issue very short lifetime certs already. It is not done by CAs where the process costs $, but that would not be a requirement for DANE-based certs. SO, I still think that it is a mistake to compare the RSIG period with a revocation mechanism like CRLs or OCSP. > > >* CA flag, path length, etc vs the dane-04 cert type [???] >> >> The Basic Constraints extension needs to be present in a CA cert, but >> the path length field is rarely used, and I would profile it away for DANE. > >Which works for new certs but not existing ones. At first I thought that Rex had cited an example of Entrust using a v1 cert. But, upon further discussion with him I learned that what he was saying is that Entrust has several non-conforming v3 certs in some browsers, e.g., certs without a basic constraint extension or with such an extension, but not marked critical, etc. None of these bad certs have path length in them, so I think that is a red herring. > >> >Other tricky things to resolve: >> >* How do EV certs fit in? (Whatever rules we come up with to process >> > subjects can't break the link to EV certs or make it over-permissive) >> >> I don't understand the context here. Are you talking about sites >> that have EV certs and want to also use DANE mechanisms? > >Yes. EV certs are issued on the basis of a CA having been audited, and promising to follow certain procedures when issuing EV certs. A web site that wants to use DANE to issue its own CA/TA is not a valid EV cert issuer absent such an audit. So, only if there is a way to use DANE to point to the extant EV cert issuer would it be reasonable to use DANE and simultaneously preserve the EV property of an extant web site (EE) 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 C84043A6902 for ; Wed, 23 Feb 2011 14:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, 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 BnyNkGBB75YB for ; Wed, 23 Feb 2011 14:23:12 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 16F023A68FD for ; Wed, 23 Feb 2011 14:23:11 -0800 (PST) Received: by bwz13 with SMTP id 13so689184bwz.31 for ; Wed, 23 Feb 2011 14:23:59 -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=bOHm4RhIY6I/H2iaFuu5fmywcotkx6vC5LIn5c0wlhQ=; b=OzysErsc4PDvhNgSg5uPKyhHaYUMOn2E19gRm+1QffVpGhMcG/mlO/ycI43xyPGV8J KM4joalJWqqLashPvoo57tfSglo5tCMLHGWtkHsmbQigGJLQ3rZLWY0ck5AXieSRnmLD 903P9ZA5mareGwPHWB251ma84Eqboc6wDJPyc= 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=HG9Dsekj4AXtoA6kkT0iv6RdIGbVKIit8ezjXtXZz3pce681xl76GA3X7Y9a40dhlt exxNcPhgDwW2tKist40rLrIE0PKWXw19y4uVuAhzw2NHM1W5hS0wlRwoUF8wWGJPXoYe zwCSvx75p/tuUjRmX17gdUqGNSulY5CQf4nNg= MIME-Version: 1.0 Received: by 10.204.129.83 with SMTP id n19mr33865bks.207.1298499838284; Wed, 23 Feb 2011 14:23:58 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 23 Feb 2011 14:23:58 -0800 (PST) In-Reply-To: <4D6583AD.80801@vpnc.org> References: <201102232039.p1NKdXR2008868@fs4113.wdf.sap.corp> <4D6583AD.80801@vpnc.org> Date: Wed, 23 Feb 2011 17:23:58 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=00151747c0709a142c049cfa8d98 Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 22:23:14 -0000 --00151747c0709a142c049cfa8d98 Content-Type: text/plain; charset=ISO-8859-1 Which is a profile of X.509 V3: This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. It is pretty important to specify the version number since we are going to need to revisit the format in the next 40 years as the date field was botched. On Wed, Feb 23, 2011 at 5:01 PM, Paul Hoffman wrote: > On 2/23/11 1:03 PM, Zack Weinberg wrote: > >> Could we short-circuit this entire argument by deferring to the >> protocol being secured for the certificate format? Concretely, >> wording like >> >> [...] The types defined in this document are: >> >> 1 -- An end-entity certificate, in the wire format used by >> the protocol being secured >> 2 -- A certification authority's certificate, ditto >> > > The WG already agreed that "the protocol being secured" is TLS, as the > current draft states. TLS has exactly one certificate type: PKIX > certificates in the format given in RFC 5280. (There is a > non-standards-track extension to allow OpenPGP certificates.) > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --00151747c0709a142c049cfa8d98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Which is a profile of X.509 V3:

= 
This =
memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model is provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.

It = is pretty important to specify the version number since we are going to nee= d to revisit the format in the next 40 years as the date field was botched.=


On Wed, Feb 23, 2011 at = 5:01 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 2/23/11 1:03 PM, Zack Weinberg wrote:<= br>
Could we short-circuit this entire argument by deferring to the
protocol being secured for the certificate format? =A0Concretely,
wording like

=A0 =A0 =A0 [...] The types defined in this document are:

=A0 =A0 =A0 =A0 =A01 -- An end-entity certificate, in the wire format used= by
the protocol being secured
=A0 =A0 =A0 =A0 =A02 -- A certification authority's certificate, ditto=

The WG already agreed that "the protocol being secured" is TLS, a= s the current draft states. TLS has exactly one certificate type: PKIX cert= ificates in the format given in RFC 5280. (There is a non-standards-track e= xtension to allow OpenPGP certificates.)

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



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

--00151747c0709a142c049cfa8d98-- 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 9F47E3A695F for ; Wed, 23 Feb 2011 14:19:55 -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 3ueEOENEBn6P for ; Wed, 23 Feb 2011 14:19:54 -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 7B5943A692B for ; Wed, 23 Feb 2011 14:19:54 -0800 (PST) Received: by wyb42 with SMTP id 42so3174342wyb.31 for ; Wed, 23 Feb 2011 14:20:42 -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=atYxK0Hv6xQ9+QaYgNVm8yo764QN2ZDX/agx6QQVzyU=; b=XNEwWc1LimbKdcR18x5xrbp62Z9jfOsPCjSb7BITx9AolyIEXhpw6aRTQhvFlRQVbs UbZ5T3+GqAA1Oi4fDvtj1vHtS418BmM79y9e1Gib4ZvhnL4Nk4gszgKYNTsbbPzIFsyN 1a8OmzmZBPKE7+CobJX1/uHwrDHphqBQsQOE0= 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=oyYcmnmM6/dyMeXQVDDTsWl66TnCsKAV58PfR3mF1O82Q4Ik317LZ3Un68vlgXMHv2 IsRvWkgrC47/UzWlcAK+wx0ui9AUghQym2bZ1ZhFct/CRrj++YcI+HQyhdZc6ZqIToIX x8VjvVSL6N4Lbq/5t8ixKS9VpLogk2ozDqVDQ= MIME-Version: 1.0 Received: by 10.227.24.69 with SMTP id u5mr20323wbb.223.1298499641938; Wed, 23 Feb 2011 14:20:41 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.155.85 with HTTP; Wed, 23 Feb 2011 14:20:41 -0800 (PST) In-Reply-To: <4D6583AD.80801@vpnc.org> References: <201102232039.p1NKdXR2008868@fs4113.wdf.sap.corp> <4D6583AD.80801@vpnc.org> Date: Wed, 23 Feb 2011 14:20:41 -0800 X-Google-Sender-Auth: Yt8ZuwdpNOIVGk7S0ruzW-yPAHM Message-ID: From: Zack Weinberg To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 22:19:55 -0000 On Wed, Feb 23, 2011 at 2:01 PM, Paul Hoffman wrote: > On 2/23/11 1:03 PM, Zack Weinberg wrote: >> >> Could we short-circuit this entire argument by deferring to the >> protocol being secured for the certificate format? > > The WG already agreed that "the protocol being secured" is TLS, as the > current draft states. TLS has exactly one certificate type: PKIX > certificates in the format given in RFC 5280. (There is a > non-standards-track extension to allow OpenPGP certificates.) Right. My suggested edit isn't meant to be a semantic change, just to arrange that we can stop arguing about what that certificate format is called. ... It does also mean that OpenPGP-cert extension, if it ever becomes popular, could also be accomodated by cert types 1 and 2, because they would still be "certificates in the wire format used by the protocol". Personally I see that as a good thing, because (one fervently hopes) the OpenPGP format is unambiguously distinguishable from the X.509 format, so putting that information into the RR metadata would be a redundancy and open the possibility of the two being out of sync. ... Come to think of it, the distinction between cert types 1 and 2 (end entity or CA) is *also* a redundancy (with the isCA field and/or the key usage restrictions) that should perhaps be eliminated. Why not just use type 1 for both, and have the client's processing pay attention to the cert's self-description? (This is not a rhetorical question; maybe there's a good reason I don't know about.) 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 C64AF3A68FD for ; Wed, 23 Feb 2011 14:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.438 X-Spam-Level: X-Spam-Status: No, score=-101.438 tagged_above=-999 required=5 tests=[AWL=0.608, 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 mNTtlrMA60zU for ; Wed, 23 Feb 2011 14:00:33 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 24A4F3A67FC for ; Wed, 23 Feb 2011 14:00: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 p1NM1KXv026913 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 15:01:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6583AD.80801@vpnc.org> Date: Wed, 23 Feb 2011 14:01: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 References: <201102232039.p1NKdXR2008868@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 22:00:33 -0000 On 2/23/11 1:03 PM, Zack Weinberg wrote: > Could we short-circuit this entire argument by deferring to the > protocol being secured for the certificate format? Concretely, > wording like > > [...] The types defined in this document are: > > 1 -- An end-entity certificate, in the wire format used by > the protocol being secured > 2 -- A certification authority's certificate, ditto The WG already agreed that "the protocol being secured" is TLS, as the current draft states. TLS has exactly one certificate type: PKIX certificates in the format given in RFC 5280. (There is a non-standards-track extension to allow OpenPGP certificates.) 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 D4B663A68C6 for ; Wed, 23 Feb 2011 13:03:12 -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 cgHzp+Jw3+Hv for ; Wed, 23 Feb 2011 13:03:12 -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 EC4AC3A6891 for ; Wed, 23 Feb 2011 13:03:11 -0800 (PST) Received: by wwb39 with SMTP id 39so1773583wwb.13 for ; Wed, 23 Feb 2011 13:03:59 -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=g2kXWakV9MDMgxfSkr1mUK3h4ydYnY7rLIrsn2Ar1C8=; b=E7F//YSCTKx2joq4iOwgKCN23IPfoQIIUbtCYczUn+DYFS8jL6Cs1ceQwq5RGLgHbR nWbHT5C2b3jI16AkjmMdK1bC/ZVnIkSSljm3O0Fku1MzkDnaeAfs5Czhh+yDiETa1jDd UYmnBnn1wWz1GSLDH1y5Ni4MIuB0HsB3lCJTU= 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=mN5xBgL1tIQQB2Bvo86qK4bC0E8lvXq+4sh1H5eMF7Cc15/2qVB/KQHZHIkyBbIb7F F6tk1vYbEJdSMWIIC2Qv4vJbNanZXsdXrHRoZVmhzYTng7P54mjHSYO84GAskFHsqq+t 9TVAUlmr22nv3O6hAY+OoH1JwhjgMgLLvnPD8= MIME-Version: 1.0 Received: by 10.227.136.70 with SMTP id q6mr4100933wbt.165.1298495039123; Wed, 23 Feb 2011 13:03:59 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.155.85 with HTTP; Wed, 23 Feb 2011 13:03:58 -0800 (PST) In-Reply-To: <201102232039.p1NKdXR2008868@fs4113.wdf.sap.corp> References: <201102232039.p1NKdXR2008868@fs4113.wdf.sap.corp> Date: Wed, 23 Feb 2011 13:03:58 -0800 X-Google-Sender-Auth: xjj8heUFDhDaFG2Ij9V8qQyFhZo Message-ID: From: Zack Weinberg To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org, i.grok@comcast.net, Phillip Hallam-Baker Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 21:03:13 -0000 Could we short-circuit this entire argument by deferring to the protocol being secured for the certificate format? Concretely, wording like [...] The types defined in this document are: 1 -- An end-entity certificate, in the wire format used by the protocol being secured 2 -- A certification authority's certificate, ditto 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 BD79B3A6A5E for ; Wed, 23 Feb 2011 12:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 jdewbWTg9yCI for ; Wed, 23 Feb 2011 12:38:49 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 79F113A6A5F for ; Wed, 23 Feb 2011 12:38:49 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1NKdXCT007210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 21:39:34 +0100 (MET) From: Martin Rex Message-Id: <201102232039.p1NKdXR2008868@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Wed, 23 Feb 2011 21:39:32 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Feb 23, 11 02:45:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org, i.grok@comcast.net Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 20:38:50 -0000 It seems were quoting / replying to the wrong mail. Phillip Hallam-Baker wrote: > > BER encoding is supported by practically every ASN.1 library. It is > identical semantically to DER which is a pain in the patootie. > > From a drafting perspective, I would first state that the identifier > corresponds to an X.509v3 cert without mentioning encoding at all. I don't think that mentioning the encoding creates a problem. My main concern at this point was about "DER" alone rather than "ASN.1 DER". > > Then I would follow that with a statement that the TLS protocol requires > certificates to conform to the X.509v3 requirement for DER encoding and the > requirements of the PKIX certificate profile. Which is pretty much plain wrong. ;-) Nothing in TLS precludes the use of X.509v1 certs, The last sentence of Section 1 of all TLS documents (2246,4346,5246) reads: The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. Which clearly explains that PKIX is just one possible approach to interpreting the certificates exchange -- and definitely not the only one. Similarily, RFC-2818, the informational RFC which describes how "HTTP Over TLS" is commonly performed says this: If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) Which describes a case where the TLS server certificate matching is a PKIX-free memcmp() on X.509 certificates. > > Specifying X.509v3 If you keep sticking the v3 onto X.509, then you're creating a necessity for a bare public key format. While I'm pretty sure that self-signed end-entity X.509v1 certs interoperate with all TLS implementations I've tested, I'm not aware of a definition of a self-signed EndEntity X.509v3 cert (that isn't in conflict with some version of X.509v3). > in DER encoding may appear to be more precise and less > ambiguous, but might well actually introduces ambiguity since another > interpretation of the statement is that there should be an additional ASN.1 > structure wrapping the cert. If there was a wrapping ASN.1 structure, it would be named and its ASN.1 definition appear in an Appendix of the document. I don't think that the document will grow the necessary level of ambiguity for this to happen. -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 7BEDD3A67F9 for ; Wed, 23 Feb 2011 11:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Nj+2Xlw7UuO8 for ; Wed, 23 Feb 2011 11:44:46 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3FFA13A67ED for ; Wed, 23 Feb 2011 11:44:45 -0800 (PST) Received: by bwz13 with SMTP id 13so531772bwz.31 for ; Wed, 23 Feb 2011 11:45:32 -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=lPrQyHcnQ6Fecnup/BqcMbj1KeVF4R2zb3g7K3CaWGs=; b=M9KzWXomuGai4lCvGrxOa1eRAWXj56UjNIzkh0FippO1NBrFqnvP6+1eRpP9HXT29i /y9mwID1aX9q/fd/cuooHiuFuPbl1iKOOX8BMtUq2r6ibtRp5XIIs1gymVFZccEmBwem oWNJqsguOPa7m/IakO4L496S2Sk+O7l/zhq4E= 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=hgrQKT1VWXPZDhNnepw5F2H79PfLcnberkUIdW9znOLXreTzl/QKEB0PbaUE7kkOGo dkwXdnLTYyOOXZlsTUYq9SbnT8J3GC1GOmoKTHsEVJWoyxnCHiqc4GM4p8HdTbbSGSDS +lBGTt1/smT9c8gjCQrkcgqT7ZTwZ1oum7CYY= MIME-Version: 1.0 Received: by 10.204.102.206 with SMTP id h14mr4142888bko.45.1298490331349; Wed, 23 Feb 2011 11:45:31 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 23 Feb 2011 11:45:31 -0800 (PST) In-Reply-To: <201102231857.p1NIvSOQ002578@fs4113.wdf.sap.corp> References: <20110221144527.GB25182@odin.mars.sol> <201102231857.p1NIvSOQ002578@fs4113.wdf.sap.corp> Date: Wed, 23 Feb 2011 14:45:31 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=001636c5a8a4f1c855049cf85667 Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 19:44:47 -0000 --001636c5a8a4f1c855049cf85667 Content-Type: text/plain; charset=ISO-8859-1 BER encoding is supported by practically every ASN.1 library. It is identical semantically to DER which is a pain in the patootie. >From a drafting perspective, I would first state that the identifier corresponds to an X.509v3 cert without mentioning encoding at all. Then I would follow that with a statement that the TLS protocol requires certificates to conform to the X.509v3 requirement for DER encoding and the requirements of the PKIX certificate profile. Specifying X.509v3 in DER encoding may appear to be more precise and less ambiguous, but might well actually introduces ambiguity since another interpretation of the statement is that there should be an additional ASN.1 structure wrapping the cert. On Wed, Feb 23, 2011 at 1:57 PM, Martin Rex wrote: > Scott Schmit wrote: > > > > An item for security considerations: > > * Now that CAs aren't necessarily issuing these certs, the client needs > > to be much more careful in its parsing (the null terminated vs length- > > delimited string bug comes to mind) > > This sounds somewhat strange to me. > > When doing TLS authentication of a peer, the peer's certificate > is always untrusted at the time when it is parsed. Parsing the > received X.509 cert is a prerequisite to being able to validate > the cert and determining whether it is trusted/trustworthy or not. > > An ASN.1 parser that is not careful is an unconditionally bad idea > and asking for trouble; lots of trouble. Tolerance to common > bugs of encodings produced by peers should never be accepted > "by accident", only by conscious trade-off decisions that are > clearly documented for the caller/consumer of the technology. > > > -Martin > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636c5a8a4f1c855049cf85667 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable BER encoding is supported by practically every ASN.1 library. It is identic= al semantically to DER which is a pain in the patootie.

=
From a drafting perspective, I would first state that the id= entifier corresponds to an X.509v3 cert without mentioning encoding at all.= =A0

Then I would follow that with a statement that the TLS = protocol requires certificates to conform to the X.509v3 requirement for DE= R encoding and the requirements of the PKIX certificate profile.


Specifying X.509v3 in DER encoding may appear= to be more precise and less ambiguous, but might well actually introduces = ambiguity since another interpretation of the statement is that there shoul= d be an additional ASN.1 structure wrapping the cert.


On Wed, Feb 23, 2011 at = 1:57 PM, Martin Rex <m= rex@sap.com> wrote:
Scott Schmit wrote:
>
> An item for security considerations:
> * Now that CAs aren't necessarily issuing these certs, the client = needs
> =A0 to be much more careful in its parsing (the null terminated vs len= gth-
> =A0 delimited string bug comes to mind)

This sounds somewhat strange to me.

When doing TLS authentication of a peer, the peer's certificate
is always untrusted at the time when it is parsed. =A0Parsing the
received X.509 cert is a prerequisite to being able to validate
the cert and determining whether it is trusted/trustworthy or not.

An ASN.1 parser that is not careful is an unconditionally bad idea
and asking for trouble; lots of trouble. =A0Tolerance to common
bugs of encodings produced by peers should never be accepted
"by accident", only by conscious trade-off decisions that are
clearly documented for the caller/consumer of the technology.


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



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

--001636c5a8a4f1c855049cf85667-- 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 14B343A6929 for ; Wed, 23 Feb 2011 10:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 8kmIM3-FyFJ3 for ; Wed, 23 Feb 2011 10:56:44 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B019C3A6915 for ; Wed, 23 Feb 2011 10:56:43 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1NIvTHH021272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 19:57:29 +0100 (MET) From: Martin Rex Message-Id: <201102231857.p1NIvSOQ002578@fs4113.wdf.sap.corp> To: i.grok@comcast.net (Scott Schmit) Date: Wed, 23 Feb 2011 19:57:28 +0100 (MET) In-Reply-To: <20110221144527.GB25182@odin.mars.sol> from "Scott Schmit" at Feb 21, 11 09:45:27 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] Interpreting certificates (and summary) 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, 23 Feb 2011 18:56:45 -0000 Scott Schmit wrote: > > An item for security considerations: > * Now that CAs aren't necessarily issuing these certs, the client needs > to be much more careful in its parsing (the null terminated vs length- > delimited string bug comes to mind) This sounds somewhat strange to me. When doing TLS authentication of a peer, the peer's certificate is always untrusted at the time when it is parsed. Parsing the received X.509 cert is a prerequisite to being able to validate the cert and determining whether it is trusted/trustworthy or not. An ASN.1 parser that is not careful is an unconditionally bad idea and asking for trouble; lots of trouble. Tolerance to common bugs of encodings produced by peers should never be accepted "by accident", only by conscious trade-off decisions that are clearly documented for the caller/consumer of the technology. -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 289FC3A6A14 for ; Wed, 23 Feb 2011 08:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.431 X-Spam-Level: X-Spam-Status: No, score=-101.431 tagged_above=-999 required=5 tests=[AWL=0.615, 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 V1N4a7sqKZsE for ; Wed, 23 Feb 2011 08:43:40 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6B4E03A690A for ; Wed, 23 Feb 2011 08:43:40 -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 p1NGiRxg013760 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 09:44:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D65396C.901@vpnc.org> Date: Wed, 23 Feb 2011 08:44: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: <201102231629.p1NGTN76023860@fs4113.wdf.sap.corp> In-Reply-To: <201102231629.p1NGTN76023860@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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, 23 Feb 2011 16:43:41 -0000 On 2/23/11 8:29 AM, Martin Rex wrote: > "PKIX certificates" looks somewhat undefined to me. Would "PKIX [RFC5280] certificates" define it better? > For me, it suggests the rules defined in rfc-5280 for X.509v3 End-entity > and CA path certificates only, but excludes both TrustAnchors and > self-signed X.509v1 certs for use as public key containers. Why do you feel that the latter two are excluded? I admit that I may be missing something, but I don't see anything in 5280 or in TLS that prohibits either. We might need to add text in our document explicitly calling them out as OK, but not much more, do we? 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 4363D3A6933 for ; Wed, 23 Feb 2011 08:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 W8j3VWVLuJrP for ; Wed, 23 Feb 2011 08:28:38 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DCCB33A6904 for ; Wed, 23 Feb 2011 08:28:37 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1NGTNmm028403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 17:29:23 +0100 (MET) From: Martin Rex Message-Id: <201102231629.p1NGTN76023860@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 23 Feb 2011 17:29:23 +0100 (MET) In-Reply-To: <4D65303D.5040704@vpnc.org> from "Paul Hoffman" at Feb 23, 11 08:05:17 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] I-D Action:draft-ietf-dane-protocol-05.txt 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, 23 Feb 2011 16:28:40 -0000 Paul Hoffman wrote: > > On 2/23/11 6:05 AM, Martin Rex wrote: > > Jakob Schlyter wrote: > >> > >> On 23 feb 2011, at 12.04, Ben Laurie wrote: > >> > >>> 1 -- A PKIX end-entity certificate in DER encoding > >>> > >>> 2 -- A PKIX certification authority's certificate in DER encoding > >> > >> I agree this is a reasonable clarification. > > > > If anything, I would really prefer something like > > > > 1 -- An end-entity X.509 certificate in ASN.1 DER encoding > > > > 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding > > X.509 is a standard that does not contain all of the extensions created > by the PKIX Working Group in the IETF. Using "PKIX" makes it clear that > we are talking about certificates with the IETF extensions, not > certificates missing them. "PKIX certificates" looks somewhat undefined to me. For me, it suggests the rules defined in rfc-5280 for X.509v3 End-entity and CA path certificates only, but excludes both TrustAnchors and self-signed X.509v1 certs for use as public key containers. -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 A28A33A68F7 for ; Wed, 23 Feb 2011 08:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.412 X-Spam-Level: X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=0.634, 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 4U+K4UP++Tgz for ; Wed, 23 Feb 2011 08:04:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CC9753A6906 for ; Wed, 23 Feb 2011 08:04: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 p1NG5G5i011761 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 23 Feb 2011 09:05:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D65303D.5040704@vpnc.org> Date: Wed, 23 Feb 2011 08:05: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 References: <201102231405.p1NE56H3015575@fs4113.wdf.sap.corp> In-Reply-To: <201102231405.p1NE56H3015575@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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, 23 Feb 2011 16:04:30 -0000 On 2/23/11 6:05 AM, Martin Rex wrote: > Jakob Schlyter wrote: >> >> On 23 feb 2011, at 12.04, Ben Laurie wrote: >> >>> 1 -- A PKIX end-entity certificate in DER encoding >>> >>> 2 -- A PKIX certification authority's certificate in DER encoding >> >> I agree this is a reasonable clarification. > > If anything, I would really prefer something like > > 1 -- An end-entity X.509 certificate in ASN.1 DER encoding > > 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding X.509 is a standard that does not contain all of the extensions created by the PKIX Working Group in the IETF. Using "PKIX" makes it clear that we are talking about certificates with the IETF extensions, not certificates missing them. 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 DFFCA3A69FA for ; Wed, 23 Feb 2011 06:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 fQ-1cVFchmjT for ; Wed, 23 Feb 2011 06:04:25 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DC7F53A689D for ; Wed, 23 Feb 2011 06:04:24 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1NE57BP001157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 15:05:07 +0100 (MET) From: Martin Rex Message-Id: <201102231405.p1NE56H3015575@fs4113.wdf.sap.corp> To: jakob@kirei.se (Jakob Schlyter) Date: Wed, 23 Feb 2011 15:05:06 +0100 (MET) In-Reply-To: from "Jakob Schlyter" at Feb 23, 11 01:07:37 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] I-D Action:draft-ietf-dane-protocol-05.txt 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, 23 Feb 2011 14:04:26 -0000 Jakob Schlyter wrote: > > On 23 feb 2011, at 12.04, Ben Laurie wrote: > > > 1 -- A PKIX end-entity certificate in DER encoding > > > > 2 -- A PKIX certification authority's certificate in DER encoding > > I agree this is a reasonable clarification. If anything, I would really prefer something like 1 -- An end-entity X.509 certificate in ASN.1 DER encoding 2 -- A certification authority's X.509 certificate in ASN.1 DER encoding -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 711233A6878 for ; Wed, 23 Feb 2011 04:06:55 -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 WBggSpaGUOcW for ; Wed, 23 Feb 2011 04:06:54 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id EF48C3A6874 for ; Wed, 23 Feb 2011 04:06:53 -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=/sbr7fu/Bt1JsoIEoLWbpkYqHQdNORsSNq8D8OAFW9w=; b=Rmil6k7E9YtJmQsvyomr4/CoZqtButatLgov/ZMm89/taeTdXe/EU+bm8Dat1Jytt3GSPcWMrVWOF /VEppmrB+qTBBekRYYAahFfi7Ufd5vkh0U30rEdEbBwGZuOiCifJafNg0tlG/yAy1fzcFemOuycwjA TpVaLJc0JqBGD/RU= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 23 Feb 2011 13:07:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Wed, 23 Feb 2011 13:07:37 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20110223070001.22677.26185.idtracker@localhost> <27B72168-C055-4C0F-B880-15E43AC5E7BE@kirei.se> To: Ben Laurie X-Mailer: Apple Mail (2.1082) Cc: keyassure Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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, 23 Feb 2011 12:06:55 -0000 On 23 feb 2011, at 12.04, Ben Laurie wrote: > 1 -- A PKIX end-entity certificate in DER encoding > > 2 -- A PKIX certification authority's certificate in DER encoding I agree this is a reasonable clarification. 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 572443A684B for ; Wed, 23 Feb 2011 03:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 cMR0IVS-1Ngg for ; Wed, 23 Feb 2011 03:03:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 57A703A680A for ; Wed, 23 Feb 2011 03:03:40 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p1NB4RVp003207 for ; Wed, 23 Feb 2011 03:04:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298459067; bh=YTUS1Y3M5RtpI9q5RfH8j1+Qxgc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=EodAoiGuYlGz2vwfTspzcljGJ9X4aXHSzCW+13yVRLDd4H9LWlAwZaR/FQerQOalr enscc/F9en1KUPewJnqUQ== Received: from vws4 (vws4.prod.google.com [10.241.21.132]) by wpaz5.hot.corp.google.com with ESMTP id p1NB4PgK031302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 23 Feb 2011 03:04:26 -0800 Received: by vws4 with SMTP id 4so2126597vws.34 for ; Wed, 23 Feb 2011 03:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z2isxopT9nPRuYMAE+V6HkbAP8mVL2slfGlznQVwCM4=; b=gZJS+6i+n/oNZoy+BEKZEiRjt/7/aRlW92MxHqwJ+3wgOsUEPZJXp+TFmfkio8keSI nisxk0gZSMiFJBXa9RMA== 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=HI0Ouap9UL3GADyDc1T9e9Vfr+QXxd1PuvEeDCv4nP1Vay9imtVHc2s4qCsbxaFyBL m/gccjk9qTgZjN4sqUQA== MIME-Version: 1.0 Received: by 10.52.158.136 with SMTP id wu8mr5836325vdb.148.1298459064502; Wed, 23 Feb 2011 03:04:24 -0800 (PST) Received: by 10.220.88.137 with HTTP; Wed, 23 Feb 2011 03:04:24 -0800 (PST) In-Reply-To: <27B72168-C055-4C0F-B880-15E43AC5E7BE@kirei.se> References: <20110223070001.22677.26185.idtracker@localhost> <27B72168-C055-4C0F-B880-15E43AC5E7BE@kirei.se> Date: Wed, 23 Feb 2011 11:04:24 +0000 Message-ID: From: Ben Laurie To: Jakob Schlyter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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, 23 Feb 2011 11:03:42 -0000 On 23 February 2011 07:06, Jakob Schlyter wrote: > On 23 feb 2011, at 08.00, internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the DNS-based Authentication of Named Entit= ies Working Group of the IETF. >> >> >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Secure DNS to Associate Ce= rtificates with Domain Names For TLS >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : P. Hoffman, J. Schlyter >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dane-protocol-05.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-22 > > We've made some updates and clarifications based on input from Scott Schm= it and others, and also addressed issue #20. > Diff and full history can be found at http://tools.ietf.org/wg/dane/draft= -ietf-dane-protocol/. In this version you define cert types like this: 1 -- An end-entity certificate in DER encoding 2 -- A certification authority's certificate in DER encoding and later say: Certificate types 1 and 2 explicitly only apply to PKIX-formatted certificates. If TLS allows other formats later, or if extensions to this protocol are made that accept other formats for certificates, those certificates will need certificate types. Since DER encoding can be applied to anything specified in ASN.1, perhaps this explicitness should be in the definitions, e.g.: 1 -- A PKIX end-entity certificate in DER encoding 2 -- A PKIX certification authority's certificate in DER 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 C71713A6816 for ; Wed, 23 Feb 2011 00:07:50 -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 ec6kV6-ahC0X for ; Wed, 23 Feb 2011 00:07:49 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 767D73A680E for ; Wed, 23 Feb 2011 00:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298448516; x=1329984516; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[keyassure]=20Interp reting=20certificates=20(and=20summary)|Cc:=20keyassure@i etf.org|In-Reply-To:=20<201102222240.p1MMeTGB022170@fs411 3.wdf.sap.corp>|Message-Id:=20|Date:=20Wed,=2023=20Feb=202011=2021:0 8:27=20+1300; bh=YqIDdloNRM3NWBvU3J5yuiaqxR2G6zuJ0RvkjEm482c=; b=id8YUldJ1gAVMlc/mpJlginq0hNm4j6+RgoASngiKs8oeMlVES3NvhiA ZHwmm2uw9nhBJxy850Yjhc8wozRNA4t7u1/LlVl7AC6/bU75c75qIhQ2F EB0Y9IrtEjJNHBhAYR3F5PvnEMrmJwKUjI+mItwQWebBY/1gC500lYbbm k=; X-IronPort-AV: E=Sophos;i="4.62,211,1296990000"; d="scan'208";a="47455911" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Feb 2011 21:08:27 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ps9lr-0004JH-Gg; Wed, 23 Feb 2011 21:08:27 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Ps9lr-0005OW-49; Wed, 23 Feb 2011 21:08:27 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201102222240.p1MMeTGB022170@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 23 Feb 2011 21:08:27 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 23 Feb 2011 08:07:50 -0000 Martin Rex writes: >While in theory, it should be possible to ASN.1 re-encode -- I would be >careful. There are CAs out there with defective PKI-Software, distributing >X.509 certs that are not valid ASN.1 DER. You never, ever try to re-encode certs, because waaaay too many of them break if you try it. This has been standard practice for about 15-20 years now, the rule of thumb is "there is only one (re-)encoding rule and its name is memcpy()" (with a corollay of "there is only one X.500 name comparison rule and it's name is memcmp()"). Peter. 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 453833A6989 for ; Tue, 22 Feb 2011 23:28:11 -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 xUUv2UjR1g87 for ; Tue, 22 Feb 2011 23:28:06 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 959F23A657C for ; Tue, 22 Feb 2011 23:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298446133; x=1329982133; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20carl@redhoundsoftware.com,=20paul@xelerance.com |Subject:=20Re:=20[keyassure]=20[dane]=20protocol=20#20 =20(new):=20Change=20the=20format=20of=20the=20two=20fiel ds=20to=20have=20fewer=20certificate=20types|Cc:=20hallam @gmail.com,=20keyassure@ietf.org,=20trac@tools.ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Wed,=2023=20Feb=202011=2020 :28:44=20+1300; bh=p1V4FBpPHja2Ky2Q5rJ86v10oEWyzp9rvmXE0oriniE=; b=JnA6B8g/ow696eTTeG9osyrQiyOsi5t80fK4027Kl7douvgzvnkEK2zO dVTPgc/qzNPilzLygHNh5qy5wS4+OdeWKoWpdDIK2ZlHbLSmlLKSNSwqS 2/vuZ/DPOmZtXqS/iP7oHLrZcSuCvSjZLYxsQ3lGSzysQi822xo5cAG6h 4=; X-IronPort-AV: E=Sophos;i="4.62,210,1296990000"; d="scan'208";a="47452005" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Feb 2011 20:28:45 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ps99R-00035O-GE; Wed, 23 Feb 2011 20:28:45 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Ps99Q-0003Rh-W4; Wed, 23 Feb 2011 20:28:44 +1300 From: Peter Gutmann To: carl@redhoundsoftware.com, paul@xelerance.com In-Reply-To: Message-Id: Date: Wed, 23 Feb 2011 20:28:44 +1300 Cc: keyassure@ietf.org, hallam@gmail.com, trac@tools.ietf.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 23 Feb 2011 07:28:11 -0000 Paul Wouters writes: >There is also the OpenPGP container I believe? That might be called >"certificate" as well? Yeah, Phil named his key format after the one used by the mechanism that PGP was diamtrically opposed to (PEM). How about doing some checking instead of just inventing things to support your argument? >Why are not calling it "PKIX certificate" to avoid confusion? Because it isn't? At most it's an "X.509 certificate", but "certificate" pretty much implies that anyway. Peter. 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 327AF3A6862 for ; Tue, 22 Feb 2011 23:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 NLAGL+65HQjE for ; Tue, 22 Feb 2011 23:07:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 025E93A657C for ; Tue, 22 Feb 2011 23:07:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:48902 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ps8pm-000EG7-Ll; Wed, 23 Feb 2011 02:08:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201102221826.p1MIQEwR007372@fs4113.wdf.sap.corp> References: <201102221826.p1MIQEwR007372@fs4113.wdf.sap.corp> Date: Wed, 23 Feb 2011 02:07:57 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, trac@tools.ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of 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, 23 Feb 2011 07:07:48 -0000 At 7:26 PM +0100 2/22/11, Martin Rex wrote: >Stephen Kent wrote: >> > >> >Simplicity and robustness. >> > >> >When simple public keys for servers are to be used with DANE, these >> >will usually be X.509v1 certificates, which do not contain >> >a BasicConstraints extension. >> >> Why would they be v1 certs? >> >> We know that using v1 certs introduced vulnerabilities in browsers, >> e.g., it enabled EEs to issue subordinate certs. > >Getting all X.509v3 attributes into a usable consistent fashion is >pretty difficult -- and a complete waste if they're supposed to be >entirely ignored. I agree, but that seems orthogonal to what I proposed, i.e., a profile for certs that would be stored in TLSA records. >Also self-signed X.509v3 End-Entity certs don't really exist. I agree that if the cert is self-signed, it should, be a CA cert based on fundamental X.509/PKIX rules, but if an SS cert is a TA package, this is a bit less clear. >I know that self-signed X.509v1 certs work fine with TLS implementations. >I wouldn't know which exact attributes I would have to add to a >self-signed X.509v3 certificate in order to not run into interop >problems. E.g. a KeyUsage constraint _without_ keyCertSign in an >X.509v3 self-signed certificate would obviously be self-contradictory. because a self-signed cert used as a TA pkg is special, it's hard to argue what is required. > > I thought that browsers were fixed and that most commercial CAs used > > v3 certs now, since v3 has been the current standard for a very long >> time. I'm surprised to hear that Entrust still has a v1 cert out >> there > >That Entrust cert is a v3 cert -- which is why our software rejects it. I (and I think some others) got the opposite impression from your message. Nevermind. >But it seems that most other PKI-Software (MS-CryptoAPI, Firefox, ...) >did not complain about this malformed X.509v3 TrustAnchor, because they're >shipping it as trust anchor. I can believe that, because if you view it as a TA package, then there are no hard and fast rules about what needs to be verified. > > Anyway, why should we think in terms of v1 certs for servers at this > > point in time? Do you statistics that suggest that most (many?) web >> sites are using v1 certs? if we're talking about certs that sites >> can issue themselves (vs. buying certs), then there is a lot of v3 >> cert CA SW available. > >selfsigned X.509v1 containers are the X.509 public key bag that >we're looking for for TLSA EE certs -- those where NO PKIX certificate >path validation is to be performed on the certificate. You really can't perform path validation on an SS cert, because there is no path :-). The issue is what other cert validation checks one should perform, and what use one should make of the fields in the cert wrt path validation for certs that chain to it. 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 2057C3A69A2 for ; Tue, 22 Feb 2011 23:06:12 -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 kyR3Vfl5uGMX for ; Tue, 22 Feb 2011 23:06:10 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id BF0563A657C for ; Tue, 22 Feb 2011 23:06:09 -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=J3Ipmu3ZaTLHE/yyVte8EN+a3+xL6lcFhQjJiwhnpBo=; b=0HFYQmlsdc3bxW6+6WpIbUoI/HRjDAEEzzyC1JevrfJM+9dmgACLAXjuYL8Lx4BAcgCMtSTJAbJbw ws2yX+pCbQd+4WfO7sV3y4GRdsZxDbP0nwHAxi4S7Drf9hpkzEpvpv3dl2IW57NRA8igG0nqWItDl9 63VOkPL3Z+YQA3mw= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS for ; Wed, 23 Feb 2011 08:06:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Jakob Schlyter In-Reply-To: <20110223070001.22677.26185.idtracker@localhost> Date: Wed, 23 Feb 2011 08:06:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27B72168-C055-4C0F-B880-15E43AC5E7BE@kirei.se> References: <20110223070001.22677.26185.idtracker@localhost> To: keyassure X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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, 23 Feb 2011 07:06:12 -0000 On 23 feb 2011, at 08.00, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >=20 >=20 > Title : Using Secure DNS to Associate Certificates = with Domain Names For TLS > Author(s) : P. Hoffman, J. Schlyter > Filename : draft-ietf-dane-protocol-05.txt > Pages : 12 > Date : 2011-02-22 We've made some updates and clarifications based on input from Scott = Schmit and others, and also addressed issue #20. Diff and full history can be found at = http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/. 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 598023A6995; Tue, 22 Feb 2011 23:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Hraqx0KTrF20; Tue, 22 Feb 2011 23:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFE23A67DB; Tue, 22 Feb 2011 23:00:01 -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.12 Message-ID: <20110223070001.22677.26185.idtracker@localhost> Date: Tue, 22 Feb 2011 23:00:01 -0800 Cc: keyassure@ietf.org Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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, 23 Feb 2011 07:00:19 -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-05.txt Pages : 12 Date : 2011-02-22 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. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-22225754.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 2337A3A6768 for ; Tue, 22 Feb 2011 17:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdd-2Ih7d1Ck for ; Tue, 22 Feb 2011 17:19:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AD0B03A672F for ; Tue, 22 Feb 2011 17:19:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:58581 helo=[169.223.137.111]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ps3Od-000DsG-UJ; Tue, 22 Feb 2011 20:20:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> Date: Tue, 22 Feb 2011 19:56:55 -0500 To: Henry Story From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 23 Feb 2011 01:19:22 -0000 At 10:17 AM +0100 2/22/11, Henry Story wrote: >... > > >> I don't think that most users, who often can't even tell if they >>have contacted a TLS-secured site, would think of a public key as >>part of the identity for the service. I also don't think that most >>of them think about the port either. > >I was not speaking to most users but to this group of security >specialists during a discussion on a protocol. The public key is a >definite description that uniquely identifies the agent for the >purpose of computers, not for the general public. The context you envisioned was not clear from your statement. a public key can be a UID for an object, but I'd hesitate to call it descriptive. >... > >I am aware of symmetric cryptography's role. But it is public key >cryptography that is core in authenticating the server, and setting >up the symmetric crypto channel. Symmetric cryptography is used >because it is less cpu intensive. I think it best to be precise when discussing what one would like to see become a standard. 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 831FD3A672E for ; Tue, 22 Feb 2011 16:52:00 -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 yukd2IZhwTB9 for ; Tue, 22 Feb 2011 16:51:59 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 2A6F33A6452 for ; Tue, 22 Feb 2011 16:51: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 5AF92C50F; Tue, 22 Feb 2011 19:52:44 -0500 (EST) Date: Tue, 22 Feb 2011 19:52:44 -0500 (EST) From: Paul Wouters To: Carl Wallace 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=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Cc: Phillip Hallam-Baker , keyassure@ietf.org, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 23 Feb 2011 00:52:00 -0000 On Tue, 22 Feb 2011, Carl Wallace wrote: > > According to the standard, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnecessary to > specify in either case.  > > True enough but there are plenty of base64 encoded certs kicking around.  Clarifying the hash is calculated > over the DER encoded certificate seems inoffensive enough while making a useful distinction.   There is also the OpenPGP container I believe? That might be called "certificate" as well? Why are not calling it "PKIX certificate" to avoid confusion? 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 16B683A672E for ; Tue, 22 Feb 2011 16:51: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 GIeuOEOpr-UZ for ; Tue, 22 Feb 2011 16:51:00 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8E8323A6452 for ; Tue, 22 Feb 2011 16:51:00 -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 0B7F2C50F; Tue, 22 Feb 2011 19:51:45 -0500 (EST) Date: Tue, 22 Feb 2011 19:51:44 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <5D7881A4-849B-435D-A516-2D96DF64FD84@kumari.net> <20110222223906.GA592@LK-Perkele-VI.localdomain> 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, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 23 Feb 2011 00:51:02 -0000 On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > I would also like to see some justification for supporting SHA1 in a new specification. We really want all > PKIX compliant code to support SHA2 and that is going to need to be the must, so what is the value to having > SHA1 in there at all? The reasoning at section 2.2 states: Using the same hash algorithm as is used in the signature in the certificate will make it more likely that the TLS client will understand this TLSA data. I think a lot (most?) certificates still use SHA1? 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 E2F0F3A66B4 for ; Tue, 22 Feb 2011 16:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.039, 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 dW8U9et+eSJf for ; Tue, 22 Feb 2011 16:19:39 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 9C3A33A63EB for ; Tue, 22 Feb 2011 16:19:39 -0800 (PST) Received: by bwz12 with SMTP id 12so4289691bwz.27 for ; Tue, 22 Feb 2011 16:20:24 -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=hPH9uGt3U71DSadhQf4zXGiy1xlCLtruyaCMhxDc8/4=; b=k35cK6e8tpmvi1mZGG2BPU0dkfdBHv/2brCFFBFKxWAesazdVSJZUADhl4V3muNr/o NMYJvG9Crr0y+YhpTtGRu5wderLUH5adVYI0bL+mwKgQ45A6s261kG48j8lr9IWnF2hy Yskv9eDoA/oodpzP4TmRCS4jsv/4hxRm0V7D8= 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=lQW2BHCh3kYQMY8Xhg8BHEJ9D7xrFu58d/XM7pr5T4imPhTzOyDOT6kNq1YX7IBI/b Vs36Uktz7NELDUqkZW1SBFNvqjNPCQOFHymAB3NFfaw4Iy6rGdtvElHUscqtrW5iOgDn 7lDUJesyOD2Df5XCljevFZxlcQNSE6Qi2IRXE= MIME-Version: 1.0 Received: by 10.204.129.83 with SMTP id n19mr3075617bks.207.1298420417506; Tue, 22 Feb 2011 16:20:17 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 16:20:17 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 19:20:17 -0500 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=00151747c070c12e29049ce80fff Cc: keyassure@ietf.org, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 23 Feb 2011 00:19:41 -0000 --00151747c070c12e29049ce80fff Content-Type: text/plain; charset=ISO-8859-1 Then we should specify BINARY as in the MIME specification. Specifying DER encoding is going to lead some twits to try re-DER encoding. On Tue, Feb 22, 2011 at 6:47 PM, Carl Wallace wrote: > > According to the standard, a certificate is not X.509 or PKIX unless DER > encoded, thus it is unnecessary to specify in either case. > > True enough but there are plenty of base64 encoded certs kicking around. > Clarifying the hash is calculated over the DER encoded certificate seems > inoffensive enough while making a useful distinction. > -- Website: http://hallambaker.com/ --00151747c070c12e29049ce80fff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Then we should specify BINARY as in the MIME specification.

<= div>Specifying DER encoding is going to lead some twits to try re-DER encod= ing.

On Tue, Feb 22, 2011 at 6:47 PM, Car= l Wallace <carl@redhoundsoftware.com> wrote:
> According to the standard, a certificate is not X.509 or PKIX unless D= ER encoded, thus it is unnecessary to specify in either case.=A0
=
True enough but there= are plenty of base64 encoded certs kicking around. =A0Clarifying the hash = is calculated over the DER encoded certificate seems inoffensive enough whi= le making a useful distinction. =A0



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

--00151747c070c12e29049ce80fff-- 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 EECA23A6981 for ; Tue, 22 Feb 2011 15:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Tu-lRv63zzFl for ; Tue, 22 Feb 2011 15:43:06 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 0C27F3A697B for ; Tue, 22 Feb 2011 15:43:05 -0800 (PST) Received: by qyk7 with SMTP id 7so3210944qyk.10 for ; Tue, 22 Feb 2011 15:43:51 -0800 (PST) Received: by 10.229.96.133 with SMTP id h5mr2559278qcn.147.1298418231165; Tue, 22 Feb 2011 15:43:51 -0800 (PST) Received: from [192.168.1.5] (pool-173-79-109-144.washdc.fios.verizon.net [173.79.109.144]) by mx.google.com with ESMTPS id e29sm4981155qck.39.2011.02.22.15.43.49 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 15:43:50 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 22 Feb 2011 18:47:33 -0500 From: Carl Wallace To: Phillip Hallam-Baker , Ilari Liusvaara Message-ID: Thread-Topic: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3381245256_2351080" Cc: dane issue tracker , keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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: Tue, 22 Feb 2011 23:43:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3381245256_2351080 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > According to the standard, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnecessary to specify in either case. True enough but there are plenty of base64 encoded certs kicking around. Clarifying the hash is calculated over the DER encoded certificate seems inoffensive enough while making a useful distinction. --B_3381245256_2351080 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
> According to the standa= rd, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnece= ssary to specify in either case. 

True enough but there are plent= y of base64 encoded certs kicking around.  Clarifying the hash is calcu= lated over the DER encoded certificate seems inoffensive enough while making= a useful distinction.  
 --B_3381245256_2351080-- 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 DAF1F3A697E for ; Tue, 22 Feb 2011 15:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.041, 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 KAkcuAYtw4Md for ; Tue, 22 Feb 2011 15:37:36 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 110F13A67FA for ; Tue, 22 Feb 2011 15:37:35 -0800 (PST) Received: by bwz12 with SMTP id 12so4261014bwz.27 for ; Tue, 22 Feb 2011 15:38:20 -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=TQMga5CnSw4+foP+LCtemXeT8s4H0D6M8GojZiBizH4=; b=Wwhr1o5zcTYEL/hIdoB9aAvUVJGjDP7xcT9OeDfGOc4mEqT1IKE2G3qZNX8TXkD9Rv hXCSHYN9KLDbZc7l1L6n6ACpppiEEI9HzatG/7QdHODv7xZGXNacVUMGvNCbGj8Pu1Fe 2k2TJ981NDWui2JUdFSFRsLEe0qnOIRhkXbOY= 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=wZFg3yuxn0dBixsRq0+hkE8Wj3XA/I5V5Rp6hZ4MFj770ImLFaAGcGX1YyBtAfHPm9 VY77LOrovgOsXfw44z+hE63A+GHgBePfMqSOgJtZLVRzvVY2aieBhMHi+WAl186y6wqY Wtsw4d7zG03LTz4lL4HWasIroakH8Y4n+NVVo= MIME-Version: 1.0 Received: by 10.204.71.141 with SMTP id h13mr3044179bkj.180.1298417900410; Tue, 22 Feb 2011 15:38:20 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 15:38:20 -0800 (PST) In-Reply-To: <20110222223906.GA592@LK-Perkele-VI.localdomain> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <5D7881A4-849B-435D-A516-2D96DF64FD84@kumari.net> <20110222223906.GA592@LK-Perkele-VI.localdomain> Date: Tue, 22 Feb 2011 18:38:20 -0500 Message-ID: From: Phillip Hallam-Baker To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=0016e6dd8942b95870049ce7793c Cc: keyassure@ietf.org, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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: Tue, 22 Feb 2011 23:37:38 -0000 --0016e6dd8942b95870049ce7793c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 5:39 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari wrote: > > Ok, so it sounds to me as though their is consensus for this change > > / text. > > > > Please clearly state if I have misread / misunderstood your views, > > otherwise I'm going to mark it as fixed.... > > > > W > > > On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote: > > > > >#20: Change the format of the two fields to have fewer certificate > > >types > > > > > >To reduce the chance that someone could give a certificate type that > > >doesn't match the hash type, change the fields as follows: > > > > > >o A one-octet value, called "certificate type", specifying the > > > > > > 1 -- An end-entity certificate > > > 2 -- A certification authority's certificate > > > > > >o A one-octet value, called "reference type", specifying how the > > > > > > 0 -- Full certificate in DER encoding > > > 1 -- SHA-1 hash of the certificate in DER encoding > > > 2 -- SHA-256 hash of the certificate in DER encoding > > > 3 -- SHA-384 hash of the certificate in DER encoding > > > > > What does DER encoding mean for possible future non-ASN.1 certificate > types? > > I think it should be done this way: > > Certificate type: > 1 -- An end-entity certificate in DER encoding > 2 -- A certification authority's certificate in DER encoding > > Reference type: > > 0 -- Full certificate > 1 -- SHA-1 hash of the certificate > 2 -- SHA-256 hash of the certificate > 3 -- SHA-384 hash of the certificate > > This way it doesn't assume that future certificate types are > DER-encodable. The result will be the same with cert types 1 and 2 > anyway. According to the standard, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnecessary to specify in either case. Thus I propose simply: Object type: 1 -- An end-entity certificate 2 -- A certification authority's certificate Reference type: 0 -- Full object 1 -- SHA-1 hash of the object 2 -- SHA-256 hash of the object 3 -- SHA-384 hash of the object I would also like to see some justification for supporting SHA1 in a new specification. We really want all PKIX compliant code to support SHA2 and that is going to need to be the must, so what is the value to having SHA1 in there at all? I can see choosing values so as not to tread on the DNSSEC hash value registry, but would prefer to simply specify 'unassigned' than assign a value to an algorithm we are starting to decommission. -- Website: http://hallambaker.com/ --0016e6dd8942b95870049ce7793c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 22, 2011 at 5:39 PM, Ilari L= iusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari w= rote:
> Ok, so it sounds to me as though their is consensus for this change > / text.
>
> Please clearly state if I have misread / misunderstood your views,
> otherwise I'm going to mark it as fixed....
>
> W

> On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote:
>
> >#20: Change the format of the two fields to have fewer certificate=
> >types
> >
> >To reduce the chance that someone could give a certificate type th= at
> >doesn't match the hash type, change the fields as follows:
> >
> >o =A0A one-octet value, called "certificate type", speci= fying the
> >
> > =A0 =A0 =A01 -- An end-entity certificate=
> > =A0 =A0 =A02 -- A certification authority's certificate
> >
> >o =A0A one-octet value, called "reference type", specify= ing how the
> >
> > =A0 =A0 =A00 -- Full certificate in DER e= ncoding
> > =A0 =A0 =A01 -- SHA-1 hash of the certificate in DER encoding
> > =A0 =A0 =A02 -- SHA-256 hash of the certificate in DER encoding > > =A0 =A0 =A03 -- SHA-384 hash of the certificate in DER encoding > >

What does DER encoding mean for possible future non-ASN.1 certificate=
types?

I think it should be done this way:

Certificate type:
=A0 =A0 =A01 -- An end-entity certificate in DER encoding
=A0 =A0 =A02 -- A certification authority's certificate in DER encodin= g

Reference type:

=A0 =A0 =A00 -- Full certificate
=A0 =A0 =A01 -- SHA-1 hash of the certificate
=A0 =A0 =A02 -- SHA-256 hash of the certificate
=A0 =A0 =A03 -- SHA-384 hash of the certificate
This way it doesn't assume that future certificate types are
DER-encodable. The result will be the same with cert types 1 and 2
anyway.


According to the sta= ndard, a certificate is not X.509 or PKIX unless DER encoded, thus it is un= necessary to specify in either case. Thus I propose simply:


Object type:=A0 =A0 =A01 -- An end-entity certificate
=A0 =A0 =A02 -- A certificati= on authority's certificate

Reference type:

=A0 =A0 =A00 -= - Full object
=A0 =A0 =A01 -- SHA-1 hash of the object
=A0 =A0 =A02 -- SHA-256 hash of the=A0object
=A0 =A0 =A03 -- SHA-384 hash of the=A0object

I would also like to see some justification for support= ing SHA1 in a new specification. We really want all PKIX compliant code to = support SHA2 and that is going to need to be the must, so what is the value= to having SHA1 in there at all?

I can see choosing values so as not to tread on the DNS= SEC hash value registry, but would prefer to simply specify 'unassigned= ' than assign a value to an algorithm we are starting to decommission.<= /div>
--
Website: http://hallambaker.= com/

--0016e6dd8942b95870049ce7793c-- 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 472A03A6966 for ; Tue, 22 Feb 2011 15:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 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 dSB1z1fNnoFF for ; Tue, 22 Feb 2011 15:25:10 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id D36B13A6934 for ; Tue, 22 Feb 2011 15:25:09 -0800 (PST) Received: by bwz12 with SMTP id 12so4253039bwz.27 for ; Tue, 22 Feb 2011 15:25:54 -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=ST6muMcXaN6jRyoYsgeM8AWfSISs73wskAZm6F+2SAA=; b=MM7NezTApAD0QY86d5SGfDas3Q/KY+kipez1bWqMTUk5Gd7BnoqBqCe/pF+F+Di2Jp 8D1IvKMehV4M2SpmOc8s7cBgmhjiZjJT10DZkkPmTT1eN6SGdmst2NyLruN8JmMTbfC+ ujpBA9kGy/Nf+CU9JfQy5fIJ0az7NSLtQEoRE= 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=ldXCOyZwHABJcyFJ9NBIbOKorjDags0dzqNekasJlu+4G7tVA4BxE1d+0Y8OJy4ZVn kkEK1COjOm4pbuMJ42OyIAId1yBlAiBE/fBpO0DeJhaLXs0UeiQbFIMPrrTiqU9M8cqu 406kkeV7OUuhXmcM79Ro92arkLZqLLOXL0Bc0= MIME-Version: 1.0 Received: by 10.204.71.141 with SMTP id h13mr3035936bkj.180.1298417153962; Tue, 22 Feb 2011 15:25:53 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 15:25:53 -0800 (PST) In-Reply-To: <201102222240.p1MMeTGB022170@fs4113.wdf.sap.corp> References: <201102222240.p1MMeTGB022170@fs4113.wdf.sap.corp> Date: Tue, 22 Feb 2011 18:25:53 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e6dd89423b7486049ce74dce Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 23:25:11 -0000 --0016e6dd89423b7486049ce74dce Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex wrote: While in theory, it should be possible to ASN.1 re-encode -- I would > be careful. There are CAs out there with defective PKI-Software, > distributing X.509 certs that are not valid ASN.1 DER. > Give people options where getting it wrong will not cause the software to fail and some people will get it wrong. > One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers, > used to be incorrect ASN.1 DER (IIRC, incorrect encoding of > the unused KeyUsage bits). Which is probably one reason why some ASN.1 > decoders keep an original copy of the ASN.1 DER ToBeSigned around for > decoded X.509 certs... Since none of the roots was DER encoded until quite a few years in, this has always been true. If you want a cert to work you have to keep the original binary. Given that a cert has never been as large as a maximal TCP packet, I have never considered canonicalization or DER encoding to have any value whatsoever. It is simply an idiot idea that came up in an X.500 committee when there was an idea that certs would be stored in X.500 directories. All that is necessary in a certificate is that the signature validates the bits presented. It is not a problem if the same semantics could have been encoded in other bits. I don't see much value in XML canonicalization either. -- Website: http://hallambaker.com/ --0016e6dd89423b7486049ce74dce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <mrex@sap.com> wrote:

While in theory, it should be possible to ASN.1 re-encode= -- I would
be careful. =A0There are CAs out there with defective PKI-Software,
distributing X.509 certs that are not valid ASN.1 DER.

Give people options where getting it wrong will not cause t= he software to fail and some people will get it wrong.


=A0
One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,
used to be incorrect ASN.1 DER (IIRC, incorrect encoding of
the unused KeyUsage bits). =A0Which is probably one reason why some ASN.1 decoders keep an original copy of the ASN.1 DER ToBeSigned around for
decoded X.509 certs...

Since none of the ro= ots was DER encoded until quite a few years in, this has always been true. = If you want a cert to work you have to keep the original binary.

Given that a cert has never been as large as a maximal = TCP packet, I have never considered canonicalization or DER encoding to hav= e any value whatsoever. It is simply an idiot idea that came up in an X.500= committee when there was an idea that certs would be stored in X.500 direc= tories.
=A0

All that is necessary in a certificate i= s that the signature validates the bits presented. It is not a problem if t= he same semantics could have been encoded in other bits.

I don't see much value in XML canonicalization either.

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

--0016e6dd89423b7486049ce74dce-- 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 94EFB3A697E for ; Tue, 22 Feb 2011 15:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 4j2N4ZPlxmYJ for ; Tue, 22 Feb 2011 15:16:43 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 1F8303A6966 for ; Tue, 22 Feb 2011 15:16:42 -0800 (PST) Received: by bwz12 with SMTP id 12so4246088bwz.27 for ; Tue, 22 Feb 2011 15:17: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=u7NhnyVIZA7YukUsKd332hEQ65+C2XQneXevK/5fwC8=; b=SgGEffDzQAVVPTgngr9ze/SLZL0pYrDVi8pUf1SoY69hDJ0gwb7AYWI6AonWx9wPWb +Mjmq+Xf4JmH/Jl1pn5nICMO+LJ2Q7UoJyDKFrLNeNbe99sASFt9wlaZijeG29+kddo9 HDA6y++N6vsaL+dlzw3jLxFh4n6DXG/Fna0Tk= 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=cn7g5efah8TaX+pEvUCMq5jcuqDGyo+mxEig34XrfLvM9hFstc+ZSguJ1pXYfMirB7 dkG8QgMKTnqLbOp8s5ZHBl8HwMRVswP4pISVw7g35XvHrvMA10GdCNap2wejW6epZ9vx LYcVsse1P1/ubqbUDCl8D/UsZfb3NaPvG+H7Y= MIME-Version: 1.0 Received: by 10.204.101.81 with SMTP id b17mr3042638bko.126.1298416647749; Tue, 22 Feb 2011 15:17:27 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 15:17:27 -0800 (PST) In-Reply-To: <201102222240.p1MMeTGB022170@fs4113.wdf.sap.corp> References: <201102222240.p1MMeTGB022170@fs4113.wdf.sap.corp> Date: Tue, 22 Feb 2011 18:17:27 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: multipart/alternative; boundary=0016e6de01640f3fe6049ce72fb1 Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 23:16:44 -0000 --0016e6de01640f3fe6049ce72fb1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex wrote: While in theory, it should be possible to ASN.1 re-encode -- I would > be careful. There are CAs out there with defective PKI-Software, > distributing X.509 certs that are not valid ASN.1 DER. > Give people options where getting it wrong will not cause the software to fail and some people will get it wrong. > One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers, > used to be incorrect ASN.1 DER (IIRC, incorrect encoding of > the unused KeyUsage bits). Which is probably one reason why some ASN.1 > decoders keep an original copy of the ASN.1 DER ToBeSigned around for > decoded X.509 certs... Since none of the roots was DER encoded until quite a few years in, this has always been true. If you want a cert to work you have to keep the original binary. Given that a cert has never been as large as a maximal TCP packet, I have never considered canonicalization or DER encoding to have any value whatsoever. It is simply an idiot idea that came up in an X.500 committee when there was an idea that certs would be stored in X.500 directories. All that is necessary in a certificate is that the signature validates the bits presented. It is not a problem if the same semantics could have been encoded in other bits. I don't see much value in XML canonicalization either. -- Website: http://hallambaker.com/ --0016e6de01640f3fe6049ce72fb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <mrex@sap.com> wrote:

While in theory, it should be possible to ASN.1 re-encode= -- I would
be careful. =A0There are CAs out there with defective PKI-Software,
distributing X.509 certs that are not valid ASN.1 DER.

Give people options where getting it wrong will not cause t= he software to fail and some people will get it wrong.


=A0
One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,
used to be incorrect ASN.1 DER (IIRC, incorrect encoding of
the unused KeyUsage bits). =A0Which is probably one reason why some ASN.1 decoders keep an original copy of the ASN.1 DER ToBeSigned around for
decoded X.509 certs...

Since none of the ro= ots was DER encoded until quite a few years in, this has always been true. = If you want a cert to work you have to keep the original binary.

Given that a cert has never been as large as a maximal = TCP packet, I have never considered canonicalization or DER encoding to hav= e any value whatsoever. It is simply an idiot idea that came up in an X.500= committee when there was an idea that certs would be stored in X.500 direc= tories.
=A0

All that is necessary in a certificate i= s that the signature validates the bits presented. It is not a problem if t= he same semantics could have been encoded in other bits.

I don't see much value in XML canonicalization either.

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

--0016e6de01640f3fe6049ce72fb1-- 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 9490B3A67B5 for ; Tue, 22 Feb 2011 14:42:27 -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 92b5iLYDY1E5 for ; Tue, 22 Feb 2011 14:42:24 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id D13473A697A for ; Tue, 22 Feb 2011 14:42:23 -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=+snqA/671uQwe1KzCFEwQzo8Ka3GnRnYNTjGrLpKt3o=; b=r/SkBSA7mVwMnxTaF1o+WqODveKYVxCaOlqYiL0Jq/UfUkl5pJfk8AZTgi3LoTdLUUX8pLqkZ+GEO 66yF8i/mDG5nT8/pzKMwi3tSjFuuE0OPoARrZ2Pn0nxEATLZ70la8eP9ZYrsNckpNKrBUowdk8SmQX SJgsSe7QFeHPZtYo= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 22 Feb 2011 23:43:06 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <20110222223906.GA592@LK-Perkele-VI.localdomain> Date: Tue, 22 Feb 2011 23:43:04 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <5D7881A4-849B-435D-A516-2D96DF64FD84@kumari.net> <20110222223906.GA592@LK-Perkele-VI.localdomain> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1082) Cc: keyassure , dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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: Tue, 22 Feb 2011 22:42:27 -0000 On 22 feb 2011, at 23.39, Ilari Liusvaara wrote: > I think it should be done this way: > > Certificate type: > 1 -- An end-entity certificate in DER encoding > 2 -- A certification authority's certificate in DER encoding > > Reference type: > > 0 -- Full certificate > 1 -- SHA-1 hash of the certificate > 2 -- SHA-256 hash of the certificate > 3 -- SHA-384 hash of the certificate > > This way it doesn't assume that future certificate types are > DER-encodable. The result will be the same with cert types 1 and 2 > anyway. +1 jakob -- Jakob Schlyter Kirei AB - www.kirei.se 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 F057E3A6995 for ; Tue, 22 Feb 2011 14:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 7YlCe4xXatmX for ; Tue, 22 Feb 2011 14:39:46 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id ED4513A6987 for ; Tue, 22 Feb 2011 14:39:45 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1MMeTO3010482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Feb 2011 23:40:29 +0100 (MET) From: Martin Rex Message-Id: <201102222240.p1MMeTGB022170@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Tue, 22 Feb 2011 23:40:29 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Feb 22, 11 05:25:05 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] Interpreting certificates (and summary) 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, 22 Feb 2011 22:39:47 -0000 > > Well you would have to design a packaging format, which as Peter explained > is going to mean ASN.1 for all practical purposes. > > ASN.1 is what the cryptomodules spew out. And over time that is going to be > how most public key ends up being implemented. If there was an urgent necessity to represent bare keys in a protocol, I personally would also appreciate if it recycled the ASN.1 DER of subjectPublicKeyInfo from PKIX/X.509. Implementing XMLdsig KeyValue conversions to make that stuff usable with common crypto toolkit APIs is a royal PITA -- so no, I really don't want to see yet another public key format standardized just to ensure that again absolutely no-one will be able to reuse existing code. The issue with existing X.509 parsers is that they usually decompose then entire cert and do not return subjectPublicKeyInfo as an ASN.1 DER blob. While in theory, it should be possible to ASN.1 re-encode -- I would be careful. There are CAs out there with defective PKI-Software, distributing X.509 certs that are not valid ASN.1 DER. One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers, used to be incorrect ASN.1 DER (IIRC, incorrect encoding of the unused KeyUsage bits). Which is probably one reason why some ASN.1 decoders keep an original copy of the ASN.1 DER ToBeSigned around for decoded X.509 certs... -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 108303A6987 for ; Tue, 22 Feb 2011 14:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wdI8yNdzp3c for ; Tue, 22 Feb 2011 14:39:09 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id E3EA33A6934 for ; Tue, 22 Feb 2011 14:39:08 -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 ACFDA13B779; Wed, 23 Feb 2011 00:39:52 +0200 (EET) Received: from emh05.mail.saunalahti.fi ([62.142.5.111]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A00E71901E8; Wed, 23 Feb 2011 00:39:52 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh05.mail.saunalahti.fi (Postfix) with ESMTP id E81A427D83; Wed, 23 Feb 2011 00:39:47 +0200 (EET) Date: Wed, 23 Feb 2011 00:39:06 +0200 From: Ilari Liusvaara To: Warren Kumari Message-ID: <20110222223906.GA592@LK-Perkele-VI.localdomain> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <5D7881A4-849B-435D-A516-2D96DF64FD84@kumari.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5D7881A4-849B-435D-A516-2D96DF64FD84@kumari.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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: Tue, 22 Feb 2011 22:39:10 -0000 On Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari wrote: > Ok, so it sounds to me as though their is consensus for this change > / text. > > Please clearly state if I have misread / misunderstood your views, > otherwise I'm going to mark it as fixed.... > > W > On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote: > > >#20: Change the format of the two fields to have fewer certificate > >types > > > >To reduce the chance that someone could give a certificate type that > >doesn't match the hash type, change the fields as follows: > > > >o A one-octet value, called "certificate type", specifying the > > > > 1 -- An end-entity certificate > > 2 -- A certification authority's certificate > > > >o A one-octet value, called "reference type", specifying how the > > > > 0 -- Full certificate in DER encoding > > 1 -- SHA-1 hash of the certificate in DER encoding > > 2 -- SHA-256 hash of the certificate in DER encoding > > 3 -- SHA-384 hash of the certificate in DER encoding > > What does DER encoding mean for possible future non-ASN.1 certificate types? I think it should be done this way: Certificate type: 1 -- An end-entity certificate in DER encoding 2 -- A certification authority's certificate in DER encoding Reference type: 0 -- Full certificate 1 -- SHA-1 hash of the certificate 2 -- SHA-256 hash of the certificate 3 -- SHA-384 hash of the certificate This way it doesn't assume that future certificate types are DER-encodable. The result will be the same with cert types 1 and 2 anyway. -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 0CD1E3A6934 for ; Tue, 22 Feb 2011 14:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 Ri6G-iNEC8ZC for ; Tue, 22 Feb 2011 14:24:21 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 5A6AF3A6983 for ; Tue, 22 Feb 2011 14:24:21 -0800 (PST) Received: by bwz12 with SMTP id 12so4203883bwz.27 for ; Tue, 22 Feb 2011 14:25: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=HW3r2uxyRrXIPeASoOyGYDVPAdGRMwIn63peWEH/l5s=; b=PqtAk3tJOMr/OMoyGroNPbWY6g64E5/8ZJjUIdVeUceN+b+342W92+VXPKuTy7gUxh FBK5SU8zHiUjLhoXa+nRCPhGkzPVzsEN2GmuD4QfEasFWOYtEHOM4CmkRHexxFACNWNj t3Rpl+wAYSnH8a89Qndk8GnwxUid5z8DWU2mw= 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=nTVg3sX6pYjO6cFT/t7oFZW0mfUa9VdTaakQWvvONtLdzLiZIz6meUWejQ7OYvMYNH gVTVP5PEodHXWnNI3sq4ztrNAnxGQA6jtXgXFLSV3DPmAfLhoS4p7xiwcU7t7dJH4YPV hoqciSVjoTafvUsfLW6Uer2I5Ox2SpWt8BqHA= MIME-Version: 1.0 Received: by 10.204.101.81 with SMTP id b17mr3006322bko.126.1298413505610; Tue, 22 Feb 2011 14:25:05 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 14:25:05 -0800 (PST) In-Reply-To: References: <20110221144527.GB25182@odin.mars.sol> Date: Tue, 22 Feb 2011 17:25:05 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6de0164c60564049ce6730b Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 22:24:23 -0000 --0016e6de0164c60564049ce6730b Content-Type: text/plain; charset=ISO-8859-1 Well you would have to design a packaging format, which as Peter explained is going to mean ASN.1 for all practical purposes. ASN.1 is what the cryptomodules spew out. And over time that is going to be how most public key ends up being implemented. And once we get into ECC issues, the difficulty of ASN.1 encoding really is moot, as is the problem of signature or cert size. I could see the point of this if you think we would be moving to a new cert format before we move beyond RSA2048. But once we are in ECC land we have compact signatures and short keys and the added overhead of the cert signature is no longer important. So yes, it can be supported and I would not want to see the draft actually foreclose that option for future development. But I can't see it being very useful either. On Tue, Feb 22, 2011 at 3:56 PM, Paul Wouters wrote: > On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > > Since TLS has the ability to use other cert types it certainly makes sense >> to have the ability to propose extensions to support them in DANE, including >> bare key. >> > > Thanks. > > > The current draft already has that. >> > > But there were issues raised that the types in section 2.2 would not > facilitate non-RSA public keys, such as ECC. > > Paul > -- Website: http://hallambaker.com/ --0016e6de0164c60564049ce6730b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well you would have to design a packaging format, which as Peter explained = is going to mean ASN.1 for all practical purposes.=A0

AS= N.1 is what the cryptomodules spew out. And over time that is going to be h= ow most public key ends up being implemented.

And once we get into ECC issues, the difficulty of ASN.= 1 encoding really is moot, as is the problem of signature or cert size.


I could see the point of this if you t= hink we would be moving to a new cert format before we move beyond RSA2048.= But once we are in ECC land we have compact signatures and short keys and = the added overhead of the cert signature is no longer important.


So yes, it can be supported and I would = not want to see the draft actually foreclose that option for future develop= ment. But I can't see it being very useful either.


On Tue, Feb 22, 2011 at 3:56 PM, Paul Wouters <paul@xelerance.co= m> wrote:
On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

Since TLS has the ability to use other cert types it certainly makes sense = to have the ability to propose extensions to support them in DANE, includin= g bare key.=A0

Thanks.


The current draft already has that.

But there were issues raised that the types in section 2.2 would not facili= tate non-RSA public keys, such as ECC.

Paul



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

--0016e6de0164c60564049ce6730b-- 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 2D01E3A6968 for ; Tue, 22 Feb 2011 14:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh03NZnf1VPG for ; Tue, 22 Feb 2011 14:05:38 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 067FC3A692C for ; Tue, 22 Feb 2011 14:05:37 -0800 (PST) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id CE3C71B4096C; Tue, 22 Feb 2011 17:06:22 -0500 (EST) Message-Id: <5D7881A4-849B-435D-A516-2D96DF64FD84@kumari.net> From: Warren Kumari To: "dane issue tracker" In-Reply-To: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Feb 2011 17:06:21 -0500 References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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: Tue, 22 Feb 2011 22:05:39 -0000 Ok, so it sounds to me as though their is consensus for this change / =20= text. Please clearly state if I have misread / misunderstood your views, =20 otherwise I'm going to mark it as fixed.... W On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote: > #20: Change the format of the two fields to have fewer certificate =20 > types > > To reduce the chance that someone could give a certificate type that > doesn't match the hash type, change the fields as follows: > > o A one-octet value, called "certificate type", specifying the > provided association that will be used to match the target > certificate. This will be an IANA registry in order to make it > easier to add additional certificate types in the future. The > types defined in this document are: > > 1 -- An end-entity certificate > > 2 -- A certification authority's certificate > > o A one-octet value, called "reference type", specifying how the > certificate association is presented. This value is defined in a > new IANA registry. The types defined in this document are: > > 0 -- Full certificate in DER encoding > > 1 -- SHA-1 hash of the certificate in DER encoding > > 2 -- SHA-256 hash of the certificate in DER encoding > > 3 -- SHA-384 hash of the certificate in DER encoding > > Using the same hash algorithm as is used in the signature in the > certificate will make it more likely that the TLS client will > understand this TLSA data. > =EF=BB=BF > > --=20 > -----------------------------------=20 > +---------------------------------------- > Reporter: paul.hoffman@=E2=80=A6 | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: protocol | Version: > Severity: - | Keywords: > -----------------------------------=20 > +---------------------------------------- > > Ticket URL: > dane > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, =20 and he'll be warm for the rest of his life." -- 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 81C2A3A6955 for ; Tue, 22 Feb 2011 12:56:16 -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 zIgMrhpOwKkV for ; Tue, 22 Feb 2011 12:56:15 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 98DDD3A6968 for ; Tue, 22 Feb 2011 12:56: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 43415C50F; Tue, 22 Feb 2011 15:56:59 -0500 (EST) Date: Tue, 22 Feb 2011 15:56:58 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110221144527.GB25182@odin.mars.sol> 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] Interpreting certificates (and summary) 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, 22 Feb 2011 20:56:16 -0000 On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote: > Since TLS has the ability to use other cert types it certainly makes sense to have the ability to propose extensions to support them in DANE, including bare key.  Thanks. > The current draft already has that. But there were issues raised that the types in section 2.2 would not facilitate non-RSA public keys, such as ECC. 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 0B85A3A68F6 for ; Tue, 22 Feb 2011 12:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 6UQLcCpcbaPW for ; Tue, 22 Feb 2011 12:27:05 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 46CBF3A68C6 for ; Tue, 22 Feb 2011 12:27:05 -0800 (PST) Received: by bwz12 with SMTP id 12so4089742bwz.27 for ; Tue, 22 Feb 2011 12:27: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=8huzFPGbLStVDSX0mo7ljyTL/sj2me7x6sr4EL8Naos=; b=OCQnic/JI84ND2QBME9j/u6jeoMECSdYppULAPnELOGlWVNE1MFbEcNvdnPHbdneXd J7zfZeDux6P3jjEy5OF8IkfL/zpH2ugtEXu4HARHJwer7tbQuasdEXo11H9SnOOIyWzN Ox1LknVrjfk1H1ZHj712NDBbYNOBdA2PLiFoQ= 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=kmItWJY/A6cz5074LhN77VTCkwt2d/Tj0WP4z54mAzRkwTXC+tFr5C5zwriBVqIGID GAh2HJhakZyMflm8aVpJoAWCe55XHtkY6JdQHLhOsWboT/l+Ol7ff80BjBrS53Hdw/Dr k556lXrkWU7dCZqYhVFUBx4MHIik/Rt1jn2UI= MIME-Version: 1.0 Received: by 10.204.122.68 with SMTP id k4mr2920580bkr.153.1298406469713; Tue, 22 Feb 2011 12:27:49 -0800 (PST) Received: by 10.204.14.139 with HTTP; Tue, 22 Feb 2011 12:27:49 -0800 (PST) In-Reply-To: References: <20110221144527.GB25182@odin.mars.sol> Date: Tue, 22 Feb 2011 15:27:49 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6dee78866c0fd049ce4d034 Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 20:27:07 -0000 --0016e6dee78866c0fd049ce4d034 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 12:02 PM, Paul Wouters wrote: > On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > > CAA should do its job without adding a single line of code to any client >> or server library. >> >> The only parties that are required to implement CAA are CAs. >> > > So the CAA record meant to protect against bad CAs will only be used by > CAs? > > Odd. I thought it was clients checking the CAA record to see if the record > authorized > a particular CA for signing the cert for the server..... Well maybe you should read the spec. CAA means that CAs that mis-issue against an explicit instruction will have been clearly an unambiguously at fault. The checks can be automated. Either a CA is going to have to comply with instructions in CAA or it is going to find that it's roots are rejected by the browser providers. So I do not expect there to be a very significant population of non-compliant certificates and hence the value of client side checking is likely to be rather small. It is still worth making the check in new code. But CAA delivers immediate benefit to all browser users irrespective of whether they update their browser or not. You can implement the client side checks if you want to. But the effect should be achieved without widespread client side deployment. If you are okay with taking into account that TLSA should be able to support > a bare public key > type in the future, we're done with this discussion. Well oddly enough, CAA actually has that capability already. Since TLS has the ability to use other cert types it certainly makes sense to have the ability to propose extensions to support them in DANE, including bare key. The current draft already has that. -- Website: http://hallambaker.com/ --0016e6dee78866c0fd049ce4d034 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 22, 2011 at 12:02 PM, Paul W= outers <paul@xel= erance.com> wrote:
On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

CAA should do its job without adding a single line of code to any client or= server library.

The only parties that are required to implement CAA are CAs.

So the CAA record meant to protect against bad CAs will only be used by CAs= ?

Odd. I thought it was clients checking the CAA record to see if the record = authorized
a particular CA for signing the cert for the server.....
<= br>
Well maybe you should read the spec.

CAA means that CAs that mis-issue against an explicit instruction will hav= e been clearly an unambiguously at fault. The checks can be automated.

Either a CA is going to have to comply with instruction= s in CAA or it is going to find that it's roots are rejected by the bro= wser providers. So I do not expect there to be a very significant populatio= n of non-compliant certificates and hence the value of client side checking= is likely to be rather small.


It is still worth making the check in ne= w code. But CAA delivers immediate benefit to all browser users irrespectiv= e of whether they update their browser or not.


You can implement the client side checks if you want to. But= the effect should be achieved without widespread client side deployment.= =A0

If you are okay with taking into account that TLSA should be able to suppor= t a bare public key
type in the future, we're done with this discussion.
=
Well oddly enough, CAA actually has that capability already.=

Since TLS has the ability to use other cert types= it certainly makes sense to have the ability to propose extensions to supp= ort them in DANE, including bare key.=A0

The current draft already has that.



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

--0016e6dee78866c0fd049ce4d034-- 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 A52AE3A67ED for ; Tue, 22 Feb 2011 10:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_74=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 PwklHGt4Uq1k for ; Tue, 22 Feb 2011 10:56:40 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 58BE63A6781 for ; Tue, 22 Feb 2011 10:56:39 -0800 (PST) Received: by bwz12 with SMTP id 12so3999443bwz.27 for ; Tue, 22 Feb 2011 10:57:23 -0800 (PST) Received: by 10.204.58.135 with SMTP id g7mr2861079bkh.187.1298401043260; Tue, 22 Feb 2011 10:57:23 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id v25sm4733084bkt.18.2011.02.22.10.57.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 10:57:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Henry Story In-Reply-To: <4D63FD7A.5010203@vpnc.org> Date: Tue, 22 Feb 2011 19:57:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <494A7B4F-8FE1-47D6-880F-EB98FEC7D9D7@bblfish.net> References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> <4D63D865.70704@vpnc.org> <8B1B5F4A-AABC-45FD-B4AD-25323E2956D3@bblfish.net> <4D63EB36.40507@vpnc.org> <27F9D8BA-46BD-4FC3-8C7E-51A0F49A3AF8@bblfish.net> <4D63F0F6.6010103@vpnc.org> <1644C26A-4512-46BB-95CC-A465412542E4@bblfish.net> <4D63FD7A.5010203@vpnc.org> To: Paul Hoffman , keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] publishing the public key 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, 22 Feb 2011 18:56:41 -0000 Ok so the following off list conversation between me and Paul, should = have helped reduce the=20 bandwidth pressure on the group. I'll send it back to the list because I = think that at least I am in sync with how Paul is thinking, so that should help. On 22 Feb 2011, at 19:16, Paul Hoffman wrote: > On 2/22/11 9:28 AM, Henry Story wrote: >>=20 >> On 22 Feb 2011, at 18:23, Paul Hoffman wrote: >>=20 >>> On 2/22/11 9:14 AM, Henry Story wrote: >>>> The TLS protocol currently has the server send the client a >>>> certificate. The client then just needs to look in DNS to find out = if >>>> the public key in the certificate sent by the server matches the >>>> public key for the service in DNSsec. So bare public keys in DNSsec >>>> should work. >>>=20 >>> You have yet to say how the TLS client knows what the public key is = for the cert they get in TLS. This was discussed multiple times on the = list, and (all?) the other supporters of bare keys have agreed that this = is not a trivial thing to do, and have backed down from it. You haven't = even addressed the issue. Instead, you keep coming back to "we want to = do this in WebID". >>=20 >> Does the following sound ok, or am I answering a different question: >>=20 >> 1. TLS client receives cert from TLS server. >> 2. TLS client extracts key from cert using normal x509 libs >> 3. TLS client looks up hosname:port in DNSsec, and finds the bare key >> 4. TLS client matches key found in 2 with the one found in 3 >>=20 >> Is that the kind of thing I should send to the list? I am not sure = at which point the problem arises. >=20 > You can send it to the list, but as has been said on the list already, = normal X.509 libraries do not let you extract the key. The few that do = might have it in different formats, so doing a direct comparison is = impossible. So it feels like the relevant part of your list, step 2, is = not based in reality. If you can show me wrong, that's great, but if = not, you posting the above list doesn't really help. Ok. So at this point we are back to WebID. I am speaking here of WebId = only because we needed the same tools as you need in Dane. So we have = some experience - not perfect - to go by. =20 WebID also requires the public key from the X509 certificate to be = extracted. It needs to be extracted on the server (in Dane it will be on = the client), and the certificate is the client certificate (in Dane it = is the server certificate), but the tools to do that will be the same.=20= http://esw.w3.org/foaf+ssl has listed the many implementations of the = above on servers for every widespread programming language. That is we = have WebID working in perl, python, c, java, ruby(?), javascript, and = others.... Now it is true that for php and javascript there was a lack = of ASN.1 parsing tools, so people initially used opensso to parse the = key, and extract the relevant information that way. Not very nice but we = were trying to see if it works. The Scala code which we can launch directly into the java SSL layer, and = which is an OSGI component is here = https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.= security.foafssl/core/src/main/scala/org/apache/clerezza/foafssl/ssl/X509T= rustManagerWrapperService.scala as you can see there getting the public key from the certificate is one = line of code val publicKey =3D cert0.getPublicKey In WeBID there is a reason to publish the "bare" public key in a web = format such as XML, RDF, html, ... If one wants to put they key in HTML = it makes more sense to put the key in a format where people can verify = visually the correspondence with what their browser tells them. A big = ugly PEM blob is just in my view too much of an eysore, and contains too = much mystification. This issue does not perhaps exist in the same way in DNS and so with = DANE, as I think the format there is also quite old, and it is unlikely = that people will be looking at DNS records without tools. I just don't = know that aspect of DNS very well, so I may be wrong. I think that if there were java libs to do a DNSSEC lookup it = probably would not be that much work to change the SSL layer reasoner to = do a Dane lookup.=20 Henry Social Web Architect http://bblfish.net/ 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 E0F933A6959 for ; Tue, 22 Feb 2011 10:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 cDucfovRra8I for ; Tue, 22 Feb 2011 10:25: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 6A24B3A695D for ; Tue, 22 Feb 2011 10:25:36 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1MIQFZH025008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Feb 2011 19:26:15 +0100 (MET) From: Martin Rex Message-Id: <201102221826.p1MIQEwR007372@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Tue, 22 Feb 2011 19:26:14 +0100 (MET) In-Reply-To: from "Stephen Kent" at Feb 21, 11 08:08:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org, trac@tools.ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of 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, 22 Feb 2011 18:25:40 -0000 Stephen Kent wrote: > > > >Simplicity and robustness. > > > >When simple public keys for servers are to be used with DANE, these > >will usually be X.509v1 certificates, which do not contain > >a BasicConstraints extension. > > Why would they be v1 certs? > > We know that using v1 certs introduced vulnerabilities in browsers, > e.g., it enabled EEs to issue subordinate certs. Getting all X.509v3 attributes into a usable consistent fashion is pretty difficult -- and a complete waste if they're supposed to be entirely ignored. Also self-signed X.509v3 End-Entity certs don't really exist. I know that self-signed X.509v1 certs work fine with TLS implementations. I wouldn't know which exact attributes I would have to add to a self-signed X.509v3 certificate in order to not run into interop problems. E.g. a KeyUsage constraint _without_ keyCertSign in an X.509v3 self-signed certificate would obviously be self-contradictory. > > I thought that browsers were fixed and that most commercial CAs used > v3 certs now, since v3 has been the current standard for a very long > time. I'm surprised to hear that Entrust still has a v1 cert out > there That Entrust cert is a v3 cert -- which is why our software rejects it. But it seems that most other PKI-Software (MS-CryptoAPI, Firefox, ...) did not complain about this malformed X.509v3 TrustAnchor, because they're shipping it as trust anchor. > > Anyway, why should we think in terms of v1 certs for servers at this > point in time? Do you statistics that suggest that most (many?) web > sites are using v1 certs? if we're talking about certs that sites > can issue themselves (vs. buying certs), then there is a lot of v3 > cert CA SW available. selfsigned X.509v1 containers are the X.509 public key bag that we're looking for for TLSA EE certs -- those where NO PKIX certificate path validation is to be performed on the certificate. -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 664C43A6919 for ; Tue, 22 Feb 2011 09:01: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=[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 DeS4m-dZouxx for ; Tue, 22 Feb 2011 09:01:48 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 39BC33A691D for ; Tue, 22 Feb 2011 09:01: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 A9E36C50E; Tue, 22 Feb 2011 12:02:27 -0500 (EST) Date: Tue, 22 Feb 2011 12:02:27 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110221144527.GB25182@odin.mars.sol> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 17:01:49 -0000 On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > CAA should do its job without adding a single line of code to any client or server library. > > The only parties that are required to implement CAA are CAs. So the CAA record meant to protect against bad CAs will only be used by CAs? Odd. I thought it was clients checking the CAA record to see if the record authorized a particular CA for signing the cert for the server..... > Nobody else need write a single line of code. If the scheme works correctly it should deter CAs > from mis-issue and give them the tools to avoid doing so at the same time. If the CAA record is only meant for CAs to "deter" them from being bad CAs, then I have to voice against the draft after all. > There is a client side capability in CAA, and that is certainly something that would be very useful to have. But that functionality should only ever be > relevant when we are having the type of events we have been having in the past few weeks when governments have actually been out co-ercing Internet > technology providers. Reality check. This is the only use of the CAA record. To protect against bogus CAs on the client side. > That discussion can be had when we have a draft for TLS bare public key. > > Well this is the wrong WG to go to for that. If you want to do bare key in TLS then you should go to the TLS list and see what type of reception you get. I already stated that I have no problem leaving out bare public key in TLSA until we have one, but what DOES need to be taken into account by this WG and the TLSA draft is a design that allows this to be later put in as a TLSA type. To which you replied with 5.8MB EXE files. If you are okay with taking into account that TLSA should be able to support a bare public key type in the future, we're done with this discussion. If not, then please come up with why it is harmful to the current TLSA draft to take this into account. Please try to come up with short bullet point style concrete reasons, and avoid talking about 20 years of experience, arguing from authority, or going of in 3 paragraph generalities about policy making. (bonus points for not mangling the reply quoting characters as shown below) > So you are arguing that CAA should be dropped as well? > > > First CAA does not mandate client code. See above. CAA without client verification is snake oil. > Second, I have never sold CAA as being a mechanism to simplify PKI code. Thus a minor increase in complexity of the code is irrelevant for my proposal but > fatal for yours where the only intended purpose is a purported reduction in code complexity. You know that some (including me) are looking at not using any PKIX in the future. That is a strong reduction in code complexity and a strong reduction root trust anchors. It is a very valid security concern that PKIX has not managed to address in 20 years. I was not accusing you of using CAA to simplify PKI. I brought it up to show that adding a few lines of code to an overly complex PKIX system actually can make it stronger, just like adding a few lines of DNSSEC validation can make TLS a lot stronger. 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 5B6C53A68F2 for ; Tue, 22 Feb 2011 08:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 w14eBEXz4IZt for ; Tue, 22 Feb 2011 08:23:59 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id F3DDC3A68EF for ; Tue, 22 Feb 2011 08:23:58 -0800 (PST) Received: by bwz12 with SMTP id 12so3842604bwz.27 for ; Tue, 22 Feb 2011 08:24:43 -0800 (PST) Received: by 10.204.7.220 with SMTP id e28mr2603928bke.157.1298391880935; Tue, 22 Feb 2011 08:24:40 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id z18sm4626371bkf.8.2011.02.22.08.24.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 08:24:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4D63D865.70704@vpnc.org> Date: Tue, 22 Feb 2011 17:24:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B1B5F4A-AABC-45FD-B4AD-25323E2956D3@bblfish.net> References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> <4D63D865.70704@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 22 Feb 2011 16:24:01 -0000 On 22 Feb 2011, at 16:38, Paul Hoffman wrote: > Henry: It feels like you are pushing for DANE and WebID to have "bare = public key" as a way of doing certificate identification without = justification for how this could be useful in DANE. > Without taking any stance on WebID, I find this frustrating as the = document co-author in DANE. The two protocols do not have the same = targets and do not even run over the same transports. > Could you please re-split the discussion and, in the DANE part, be = much more specific about how you see bare public keys in DANE being used = with just TLS? Thanks! So splitting the discussion here, and stopping the cross posting. Advantages for DANE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think my main reason for why this could be better for DANE were: - much shorter entry in the DNS, which has to be fast and efficient - simpler to understand (few people understand what is in X509) =20 I understand why others think that it's easier to put a full X509 in the = DNS. The parsing libs are there, and there is the idea that they could = re-use the semantics of X509, which I don't have enough understanding = of.=20 So just by myself I would not know at this point what the right thing = to do is. I hope my arguments have helped sort out some good arguments = from some less good ones so that the right decision, whatever it is can = be made. WebID will work logically just as well with DANE if it has full X509 = certs in the DNS as if it has bare public keys - especially if whatever = the outcome, browser vendors adopt DANE for the purpose described in 1 = above.=20 WebID is putting bare public keys in the Profile Pages, so I was = wondering why DANE does not do it too.=20 Reasons for interest of WebID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Here are a few reasons for my interest in DANE, which does not get to = answering the bare public key part of your question, but I'll just use = it to frame my recent contribution. 1. DANE should make it easy for the self signed https end points that = are currently 3 times more numerous than CA signed https end points to = be authenticated by browsers. Those browsers will no longer need then to = display ugly warnings messages that users are now taught to bypass. This = is good for https, for security and so for WebID 2. The cheaper and easier https endpoint deployment is the better for = WebID. Dane should make that possible I hope by allowing site owners to = publish the public keys (bare or inside X509 certs) for the services in = DNS 3. DANE and WebID are using different transports but the authentication = logic are nearly the same. Where Dane can be used to authenticate = servers, WebID is used to authenticate clients. Semantically it's nearly = a mirror image - though WebId would end up building on top of DANE. =20 =09 Henry Social Web Architect http://bblfish.net/ 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 316203A692C for ; Tue, 22 Feb 2011 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[AWL=0.666, 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 j41iWhV3y07z for ; Tue, 22 Feb 2011 07:43:35 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5A8E83A693A for ; Tue, 22 Feb 2011 07:43:35 -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 p1MFcDLm046866 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Feb 2011 08:38:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D63D865.70704@vpnc.org> Date: Tue, 22 Feb 2011 07:38: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: Henry Story References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 22 Feb 2011 15:43:36 -0000 Henry: It feels like you are pushing for DANE and WebID to have "bare public key" as a way of doing certificate identification without justification for how this could be useful in DANE. Without taking any stance on WebID, I find this frustrating as the document co-author in DANE. The two protocols do not have the same targets and do not even run over the same transports. Could you please re-split the discussion and, in the DANE part, be much more specific about how you see bare public keys in DANE being used with just TLS? Thanks! 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 4360A3A67AF for ; Tue, 22 Feb 2011 01:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_44=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 C0YAG4YUVcsR for ; Tue, 22 Feb 2011 01:17:09 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id DAF203A67A5 for ; Tue, 22 Feb 2011 01:17:08 -0800 (PST) Received: by bwz12 with SMTP id 12so3440559bwz.27 for ; Tue, 22 Feb 2011 01:17:51 -0800 (PST) Received: by 10.204.32.216 with SMTP id e24mr2226663bkd.204.1298366271428; Tue, 22 Feb 2011 01:17:51 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id j11sm4353756bka.0.2011.02.22.01.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Feb 2011 01:17:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Tue, 22 Feb 2011 10:17:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 22 Feb 2011 09:17:10 -0000 On 22 Feb 2011, at 03:00, Stephen Kent wrote: > At 12:49 AM +0100 2/22/11, Henry Story wrote: >> ... >> > >>> Do you mean "identifies" or "authenticates?" I think most folks view = the DNS name (or URL) as the identity of the web site. >>=20 >> Partly. The DNS domain name is a name that one could think of as = referring to a set of services, each of those having a name of the form = name:port. The relation between the service name and the public key = forms an identifying description, or I should say a definite = description as it is known in philosophy. I used the following example: >>=20 >> name:port knowsPrivateKeyof pubK >=20 > I don't think that most users, who often can't even tell if they have = contacted a TLS-secured site, would think of a public key as part of the = identity for the service. I also don't think that most of them think = about the port either. I was not speaking to most users but to this group of security = specialists during a discussion on a protocol. The public key is a = definite description that uniquely identifies the agent for the purpose = of computers, not for the general public. >=20 >> That sentence does not authenticate, it describes. But it is part of = the TLS authentication protocol. Authentication is the process that uses = that information to prove the authorship of the messages sent down a = socket. >=20 > once the TLS session has been established, it is symmetric crypto, = using a key > delivered or derived using a public key (or pair thereof) that = provides the > data origin authentication and connection-oriented integrity = guarantees to > which you allude. I am aware of symmetric cryptography's role. But it is public key = cryptography that is core in authenticating the server, and setting up = the symmetric crypto channel. Symmetric cryptography is used because it = is less cpu intensive. >=20 >> > We're debating the mechanics of how to enable a client to verify = that the asserted identity matches the client's expectations, based on = the content of a series of DNS records. >>=20 >> Yes, that is what the next part of my e-mail was describing the logic = of. Now in the case of server identity the client knows what it wants = the server's identity to be, since it initiated the call, went to DNS, = found the ip address, and connected. The clienet can then use the public = key found in DNS (or returned by the server) to authenticate the = service it is connected to. >=20 > right. >=20 > Steve Social Web Architect http://bblfish.net/ 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 9AD523A63D2 for ; Mon, 21 Feb 2011 20:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.602, 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 kfkPAnNDNNBl for ; Mon, 21 Feb 2011 20:43:21 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 354F33A680A for ; Mon, 21 Feb 2011 20:43:21 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Asih1g0041HpZEsA4sk4zS; Tue, 22 Feb 2011 04:44:04 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta14.emeryville.ca.mail.comcast.net with comcast id Asjz1g00l00PQ6U8ask06o; Tue, 22 Feb 2011 04:44:01 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1M4hxD7005643 for ; Mon, 21 Feb 2011 23:43:59 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1M4hwQE005641 for keyassure@ietf.org; Mon, 21 Feb 2011 23:43:58 -0500 Date: Mon, 21 Feb 2011 23:43:58 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110222044358.GC25182@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <20110221144527.GB25182@odin.mars.sol> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 04:43:22 -0000 On Mon, Feb 21, 2011 at 08:38:43PM -0500, Stephen Kent wrote keyassure: > At 9:45 AM -0500 2/21/11, Scott Schmit wrote: > For DANE we should generate a profile indicating what extensions > MUST be present, MUST be omitted, MAY be present, etc. We also can > limit the types of values allowed in standard cert fields, to further > simplify generation and parsing. This is what we did for SIDR. This assumes that the only certificates that you're interested in using with DANE are newly-generated self-signed certificates. What does a web site like Amazon or IETF do if they don't want to break existing users that don't have DANE support and don't want to setup dane.amazon.com or dane.ietf.org? If the rules defined for DANE-compatible certs happen to be what they already have, then great, but will that work for all the existing certs out there? I could also imagine putting a CA certificate in the DNS so that the organization doesn't need to deal with renewing the CA cert and also updating the DNS. EEs have no control over the CA's certs. > >While our current focus is TLS/DTLS, general but simple solutions are > >usually the better ones, so that's another reason for the call for bare > >keys--it seems so much simpler. > > The apparent simplicity may not prevail when viewed in the larger app > context. I agree. Hence "seems" :-) > >security libraries (and all the risks that implies). That said, the > >error paths of those libraries are going to take more of a beating, now > >that CAs with a reputation to protect aren't sanitizing the certificate > >fields. > > Not sure what you mean here by "sanitizing." Not letting the nasty stuff through. Not saying they never make mistakes, but stuff that causes outright vulnerabilities I would imagine they fix (even if it takes a public shaming first). > >Even if we reuse pieces of what's there, they're still invasive changes > >to ASN.1/X.509 parsing code--the very stuff that has had all those > >problems. Also, the non-DANE case isn't going away overnight, so both > >cases must still be covered (complicating the logic), and the more > >difficult DANE is to adopt, the less overnight it'll be. > > What non-DANE cases do you have in mind? The status quo today--the world without DANE. > >* Validity vs RRSIG period [take the min period] > > This need mot be an issue. You will process the DNS TTL first, and reject > the record if it is expired. If the TTL is OK, then why not process the > cert validity interval separately, when performing cert path validation. I probably misstated my intent. What you described is what I meant. It's probably better stated as "obey both". > >* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated] > > TTL is not really equivalent to a CRL or OCSP. It is analogous to the > cert validity interval. The question here is whether a cert retrieved from > the DNS is a TA, or not. if it is, then it will not be revoked via > a CRL or OCSP, buy the very nature of a TA. But, if the cert is not > a TA, the question of what sort of revocation mechanism is used is > relevant. I shouldn't have put TTL there. Martin Rex points out TTL isn't covered by DNSSEC (and how can it be? it's supposed to count down!), so for as long as the RRSIG is valid, an attacker can simply keep resending the same record any time the TTL expires. Instead, it's RRSIG (or something else). While you're right that the RRSIG period is basically a validity period, it's also not quite the same because of who is doing the signing. With CAs today, no one would tolerate a validity of two weeks because they'd need to get a cert reissued from the CA constantly. On the other hand, shorter periods are typical in DNSSEC. By having the signing keys, making the RRSIG period be short isn't so onerous as long as you can automate the process. > >* CA flag, path length, etc vs the dane-04 cert type [???] > > The Basic Constraints extension needs to be present in a CA cert, but > the path length field is rarely used, and I would profile it away for DANE. Which works for new certs but not existing ones. > >Other tricky things to resolve: > >* How do EV certs fit in? (Whatever rules we come up with to process > > subjects can't break the link to EV certs or make it over-permissive) > > I don't understand the context here. Are you talking about sites > that have EV certs and want to also use DANE mechanisms? Yes. -- Scott Schmit 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 BA8C83A67F6 for ; Mon, 21 Feb 2011 18:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, 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 1lCdH8yE+6tL for ; Mon, 21 Feb 2011 18:54:12 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 984F23A67EC for ; Mon, 21 Feb 2011 18:54:11 -0800 (PST) Received: by bwz12 with SMTP id 12so3230542bwz.27 for ; Mon, 21 Feb 2011 18:54:54 -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=6i1Z+oWlG0lD8CuQDtneZh2hc8R4vfDdvJThbk0uv+Y=; b=rnVWgL2ZW2gFQgnIW+kcftarNnLp3M7nvc/4mXl3ETMgjjEhWyoCmnUsbz77c5per6 nOvoG00hqS3OeJ2fe+okcSnM/BYsgtN3F+2t/zjuTiY+QrDjeI0V3h6n3Ns5H80+kFbb uJInaEwBNHha3Gpu6qYlglumyEkkGnAeX2z7c= 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=CN+cE3aybEBdnv0+3NL1KAxvaSz/P7helOIQ92LgtAGjwvSSmPW4VcwW1MD6Je0c2f iBD2V8w7JEjm0/3R0h9krzNJeOPsScdzwcWgCC8v9LMY0vXdSyXRsrJ46EvD79G3IFwF RF6XkMz9oWHR/bm2KNYG0xrfMDdgCnO1i290Y= MIME-Version: 1.0 Received: by 10.204.101.81 with SMTP id b17mr1985007bko.126.1298343292936; Mon, 21 Feb 2011 18:54:52 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 18:54:52 -0800 (PST) In-Reply-To: References: <201102211739.p1LHdDTA012923@fs4113.wdf.sap.corp> Date: Mon, 21 Feb 2011 18:54:52 -0800 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=0016e6de0164c5a2b1049cd61a2b Cc: trac@tools.ietf.org, keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the 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, 22 Feb 2011 02:54:13 -0000 --0016e6de0164c5a2b1049cd61a2b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 21, 2011 at 5:08 PM, Stephen Kent wrote: > At 6:39 PM +0100 2/21/11, Martin Rex wrote: > >> Stephen Kent wrote: >> >>> >>> At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >>> >#20: Change the format of the two fields to have fewer certificate >>> types >>> > >>> > To reduce the chance that someone could give a certificate type that >>> > doesn't match the hash type, change the fields as follows: >>> > >>> > o A one-octet value, called "certificate type", specifying the >>> > provided association that will be used to match the target >>> > certificate. This will be an IANA registry in order to make it >>> > easier to add additional certificate types in the future. The >>> > types defined in this document are: >>> > >>> > 1 -- An end-entity certificate >>> > >>> > 2 -- A certification authority's certificate >>> >>> if we're talking about X.509 certs, this distinction is already >>> expressed >>> within the cert itself, via the BasicConstraints extension. Not sure >>> why one would need to express this cert type in the record as well, >>> when a cert (vs. hash) is present). >>> >> >> Simplicity and robustness. >> >> When simple public keys for servers are to be used with DANE, these >> will usually be X.509v1 certificates, which do not contain >> a BasicConstraints extension. >> > > Why would they be v1 certs? > > We know that using v1 certs introduced vulnerabilities in browsers, e.g., > it enabled EEs to issue subordinate certs. > > I thought that browsers were fixed and that most commercial CAs used v3 > certs now, since v3 has been the current standard for a very long time. I'm > surprised to hear that Entrust still has a v1 cert out there, but it may be > that it has been around for a very long time and they don't want to pay to > replace it. > > Anyway, why should we think in terms of v1 certs for servers at this point > in time? Do you statistics that suggest that most (many?) web sites are > using v1 certs? if we're talking about certs that sites can issue > themselves (vs. buying certs), then there is a lot of v3 cert CA SW > available. I would be surprised if Entrust had issued a v1 cert recently as a CA. But there are other ways that the same situation can emerge. One is that some of the earliest root keys have been re-certified. I am not aware that any of the current roots embedded in current browsers was still v1 and it would seem rather odd if it was due to the issues that Steve mentions above. But that does not mean that you can't or shouldn't be able to form a valid trust chain to one of the old v1 roots. If we are comparing like with like, we are talking about current software that is being actively maintained and has a current root store. -- Website: http://hallambaker.com/ --0016e6de0164c5a2b1049cd61a2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 21, 2011 at 5:08 PM, Stephen= Kent <kent@bbn.com> wrote:
At 6:39 PM +0100 2/21/11, Martin Rex wrote:
Stephen Kent wrote:

=A0At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
=A0>#20: Change the format of the two fields to have fewer certificate t= ypes
=A0>
=A0> =A0To reduce the chance that someone could give a certificate type = that
=A0> =A0doesn't match the hash type, change the fields as follows: =A0>
=A0> =A0o =A0A one-octet value, called "certificate type", spe= cifying the
=A0> =A0 =A0 provided association that will be used to match the target<= br> =A0> =A0 =A0 certificate. =A0This will be an IANA registry in order to m= ake it
=A0> =A0 =A0 easier to add additional certificate types in the future. = =A0The
=A0> =A0 =A0 types defined in this document are:
=A0>
=A0> =A0 =A0 =A0 =A01 -- An end-entity certificate
=A0>
=A0> =A0 =A0 =A0 =A02 -- A certification authority's certificate

=A0if we're talking about X.509 certs, this distinction is already expr= essed
=A0within the cert itself, via the BasicConstraints extension. Not sure
=A0why one would need to express this cert type in the record as well,
=A0when a cert (vs. hash) is present).

Simplicity and robustness.

When simple public keys for servers are to be used with DANE, these
will usually be X.509v1 certificates, which do not contain
a BasicConstraints extension.

Why would they be v1 certs?

We know that using v1 certs introduced vulnerabilities in browsers, e.g., i= t enabled EEs to issue subordinate certs.

I thought that browsers were fixed and that most commercial CAs used v3 cer= ts now, since v3 has been the current standard for a very long time. I'= m surprised to hear that Entrust still has a v1 cert out there, but it may = be that it has been around for a very long time and they don't want to = pay to replace it.

Anyway, why should we think in terms of v1 certs for servers at this point = in time? Do you statistics that suggest that most (many?) web sites are usi= ng v1 certs? =A0if we're talking about certs that sites can issue thems= elves (vs. buying certs), then there is a lot of v3 cert CA SW available.

I would be surprised if Entrust had issued a v1 cert re= cently as a CA. But there are other ways that the same situation can emerge= .

One is that some of the earliest root keys have = been re-certified. I am not aware that any of the current roots embedded in= current browsers was still v1 and it would seem rather odd if it was due t= o the issues that Steve mentions above. But that does not mean that you can= 't or shouldn't be able to form a valid trust chain to one of the o= ld v1 roots.


If we are comparing like with like, we a= re talking about current software that is being actively maintained and has= a current root store.=A0

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

--0016e6de0164c5a2b1049cd61a2b-- 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 863AF3A67F7 for ; Mon, 21 Feb 2011 18:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_44=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 chF8h53pYBuW for ; Mon, 21 Feb 2011 18:46:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BEF863A67EC for ; Mon, 21 Feb 2011 18:46:21 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33615 helo=[169.223.137.111]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PriHG-000NJQ-Tw; Mon, 21 Feb 2011 21:47:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> Date: Mon, 21 Feb 2011 21:00:14 -0500 To: Henry Story From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 22 Feb 2011 02:46:22 -0000 At 12:49 AM +0100 2/22/11, Henry Story wrote: >... > > >> Do you mean "identifies" or "authenticates?" I think most folks >>view the DNS name (or URL) as the identity of the web site. > >Partly. The DNS domain name is a name that one could think of as >referring to a set of services, each of those having a name of the >form name:port. The relation between the service name and the public >key forms an identifying description, or I should say a definite >description as it is known in philosophy. I used the following >example: > > name:port knowsPrivateKeyof pubK I don't think that most users, who often can't even tell if they have contacted a TLS-secured site, would think of a public key as part of the identity for the service. I also don't think that most of them think about the port either. >That sentence does not authenticate, it describes. But it is part of >the TLS authentication protocol. Authentication is the process that >uses that information to prove the authorship of the messages sent >down a socket. once the TLS session has been established, it is symmetric crypto, using a key delivered or derived using a public key (or pair thereof) that provides the data origin authentication and connection-oriented integrity guarantees to which you allude. > > We're debating the mechanics of how to enable a client to verify >that the asserted identity matches the client's expectations, based >on the content of a series of DNS records. > >Yes, that is what the next part of my e-mail was describing the >logic of. Now in the case of server identity the client knows what >it wants the server's identity to be, since it initiated the call, >went to DNS, found the ip address, and connected. The clienet can >then use the public key found in DNS (or returned by the server) to >authenticate the service it is connected to. right. 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 0C98A3A67E2 for ; Mon, 21 Feb 2011 17:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 XoU9MYmBLU9g for ; Mon, 21 Feb 2011 17:51:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9510C3A67D8 for ; Mon, 21 Feb 2011 17:51:59 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40733 helo=[169.223.137.111]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrhQg-000PcG-9H; Mon, 21 Feb 2011 20:52:42 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110221144527.GB25182@odin.mars.sol> References: <20110221144527.GB25182@odin.mars.sol> Date: Mon, 21 Feb 2011 20:38:43 -0500 To: Scott Schmit From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 01:52:01 -0000 At 9:45 AM -0500 2/21/11, Scott Schmit wrote: >[Partly a summary, partly an attempt to re-focus the conversation.] > >I think we can all appreciate that complexity is the antithesis of >security, and simpler is better. There have been a significant number of >vulnerabilities in ASN.1 and X.509 parsing, and there will probably be >more. And I've also seen expressed (though I can no longer find the >webpage that went through the problems) that X.509 is a disaster because >rules for parsing and certificate generation are so ambiguous or >inconsistent that clients must violate the spec to work in the real >world. Even if the specs have been fixed, there is almost certainly >still stuff out there that hasn't changed. A few problems with ASN.1 parsing in some libraries were identified, and rectified, many years ago. This does not seem to be a current problem. I know of no "ambiguities" in X.509 cert formats that cause problems. (Which is not to say that some CAs and some RP software have bugs :-). it's SW.) For DANE we should generate a profile indicating what extensions MUST be present, MUST be omitted, MAY be present, etc. We also can limit the types of values allowed in standard cert fields, to further simplify generation and parsing. This is what we did for SIDR. >So, it's entirely believable that some people decided that this was just >too much trouble and came up with their own solution (e.g., SSH). With >DNSSEC providing a secure place to associate keys with nodes, one could >imagine future protocols (or existing ones) being interested in using >the DNS, and DANE seems like a good mechanism for that. SSH has an option to use X.509 certs :-). >And this is is the attraction of bare keys--in DNSSEC, you have a chain >of DS records and DNSKEY records linked to some domain name, all >authenticated using RRSIG records. So clearly, DNSSEC already can do >certificates (in the sense of a binding of a name to a key), we just >need a generic way for applications to use that mechanism. DNSSEC does have a way to distribute keys; nobody is arguing against that. The question is whether it's worth the trouble to modify apps that know how to use certs to use bare keys instead. >While our current focus is TLS/DTLS, general but simple solutions are >usually the better ones, so that's another reason for the call for bare >keys--it seems so much simpler. The apparent simplicity may not prevail when viewed in the larger app context. >Even if you accept all that (and you may not), TLS/DTLS uses X.509 >certs. Listening to Peter, I have a better appreciation now that >because the TLS protocol has no native way to say "here's my key, check >out of band to see if you trust it", the existing code doesn't provide >the right kind of capabilities or interfaces for the programmer to do >that reliably, as there was no requirement at the time for such a >feature. yes. >If we want to see DANE adopted in the near future (or at all) in >protocols that already exist (i.e. using TLS), we must respect that a >lot of people aren't going to see the security benefits of DANE being >worth starting from scratch or significantly rewriting existing, working >security libraries (and all the risks that implies). That said, the >error paths of those libraries are going to take more of a beating, now >that CAs with a reputation to protect aren't sanitizing the certificate >fields. Not sure what you mean here by "sanitizing." >Even if we reuse pieces of what's there, they're still invasive changes >to ASN.1/X.509 parsing code--the very stuff that has had all those >problems. Also, the non-DANE case isn't going away overnight, so both >cases must still be covered (complicating the logic), and the more >difficult DANE is to adopt, the less overnight it'll be. What non-DANE cases do you have in mind? >So I would suggest (and I have no hat, it's just a suggestion) that the >question of bare keys be put aside for the moment. To go with PKIX >certificates, we need to deal with the problem that PKIX certificates >have fields that duplicate what DNSSEC is telling the relying party. >And duplication of information means an opportunity for that information >to conflict. Agreed. We need to decide whether we want to compare redundant fields, or ignore cert fields in favor of DNS data, or whatever. >Looking at some typical certs, here are some sources of conflict I see: >* Subject identification (including alt names) vs domain name [???] the preferred Subject name for TLS is a DNS SAN. we have accommodated several hacks in the Subject DN field for backward compatibility, but for any user-generated certs this ought mot be an issue. >* Validity vs RRSIG period [take the min period] This need mot be an issue. You will process the DNS TTL first, and reject the record if it is expired. If the TTL is OK, then why not process the cert validity interval separately, when performing cert path validation. >* Name constraints vs domain name [???] If the cert is used as a TA, this extension need not be processed. (This is a pet peve of mine, as I think it should, but the X.509 and PKIX specs do not require such behavior.) >* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated] TTL is not really equivalent to a CRL or OCSP. It is analogous to the cert validity interval. The question here is whether a cert retrieved from the DNS is a TA, or not. if it is, then it will not be revoked via a CRL or OCSP, buy the very nature of a TA. But, if the cert is not a TA, the question of what sort of revocation mechanism is used is relevant. >* CA flag, path length, etc vs the dane-04 cert type [???] The Basic Constraints extension needs to be present in a CA cert, but the path length field is rarely used, and I would profile it away for DANE. >Other tricky things to resolve: >* How do EV certs fit in? (Whatever rules we come up with to process > subjects can't break the link to EV certs or make it over-permissive) I don't understand the context here. Are you talking about sites that have EV certs and want to also use DANE mechanisms? >* Are there any other PKIX fields that clients use and trust, but are > only trustworthy if issued by a third party? good question. >* Are the changes to certificate validation required to made DANE > meaningful just as bad as or worse than adding support for bare keys? > (This won't be evident until we answer the above, which is part of why > I suggest setting aside the bare key question.) depending on what DANE does, this could be very easy, or not so trivial. If we profile DANE certs to be simple, and use them only as TA material, this might be very easy. >An item for security considerations: >* Now that CAs aren't necessarily issuing these certs, the client needs > to be much more careful in its parsing (the null terminated vs length- > delimited string bug comes to mind) Peter Gutman has a large collection of mangled certs issued by "real" CAs, so defensive parsing has always been appropriate. 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 BCAD13A67DA for ; Mon, 21 Feb 2011 17:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 MEckkzwvW8QF for ; Mon, 21 Feb 2011 17:51:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id EBCAD3A67D6 for ; Mon, 21 Feb 2011 17:51:58 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40733 helo=[169.223.137.111]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrhQd-000PcG-Ru; Mon, 21 Feb 2011 20:52:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201102211739.p1LHdDTA012923@fs4113.wdf.sap.corp> References: <201102211739.p1LHdDTA012923@fs4113.wdf.sap.corp> Date: Mon, 21 Feb 2011 20:08:22 -0500 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, trac@tools.ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the 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, 22 Feb 2011 01:51:59 -0000 At 6:39 PM +0100 2/21/11, Martin Rex wrote: >Stephen Kent wrote: >> >> At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >> >#20: Change the format of the two fields to have fewer certificate types >> > >> > To reduce the chance that someone could give a certificate type that >> > doesn't match the hash type, change the fields as follows: >> > >> > o A one-octet value, called "certificate type", specifying the >> > provided association that will be used to match the target >> > certificate. This will be an IANA registry in order to make it >> > easier to add additional certificate types in the future. The >> > types defined in this document are: >> > >> > 1 -- An end-entity certificate >> > >> > 2 -- A certification authority's certificate >> >> if we're talking about X.509 certs, this distinction is already expressed >> within the cert itself, via the BasicConstraints extension. Not sure >> why one would need to express this cert type in the record as well, >> when a cert (vs. hash) is present). > >Simplicity and robustness. > >When simple public keys for servers are to be used with DANE, these >will usually be X.509v1 certificates, which do not contain >a BasicConstraints extension. Why would they be v1 certs? We know that using v1 certs introduced vulnerabilities in browsers, e.g., it enabled EEs to issue subordinate certs. I thought that browsers were fixed and that most commercial CAs used v3 certs now, since v3 has been the current standard for a very long time. I'm surprised to hear that Entrust still has a v1 cert out there, but it may be that it has been around for a very long time and they don't want to pay to replace it. Anyway, why should we think in terms of v1 certs for servers at this point in time? Do you statistics that suggest that most (many?) web sites are using v1 certs? if we're talking about certs that sites can issue themselves (vs. buying certs), then there is a lot of v3 cert CA SW available. 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 EDD9A3A67D3 for ; Mon, 21 Feb 2011 17:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsH8uBjWG9Jk for ; Mon, 21 Feb 2011 17:51:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 282CA3A67CF for ; Mon, 21 Feb 2011 17:51:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40733 helo=[169.223.137.111]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrhQP-000PcG-Ms; Mon, 21 Feb 2011 20:52:26 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> <4D617535.9040404@vpnc.org> Date: Mon, 21 Feb 2011 20:01:55 -0500 To: Ben Laurie From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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, 22 Feb 2011 01:51:46 -0000 >... > > >> I agree that the info in the record could be a TA, and not a CA, but not if >> the format of the data is an X.509 cert. > >You said a minute ago: "if you issue an X.509 cert under which other >certs will be validated, >you are a CA." yep. >This sounds correct to me. However, mostly what's being done here is >_not_ the issuing of X.509 certs under which other certs will be >validated (though it is an option), so most times the zone operator is >not a CA. I though one option was to place a cert in the DNS and use it as the basis for validating a cert chain that terminates at the EE cert for the web site. If so, then that cert is used to validate other certs and it would generally be viewed as a CA cert. I admit that some ambiguity arises when the cert is viewed as a TA. The ambiguity arises because In general, if you issue a cert, you are a CA, but when a cert used to convey TA data, an RP may elect to not check all of the data. We do have TA format standards that make it clear what data is to be checked and it might be preferable to use them, vs. a self-signed cert (although the later option might minimize code reuse). >In any case it does seem worth making clear when we are talking about >a PKIX CA vs. any other kind. It's really not a "PKIX CA" per se; it's an X.509 CA. > > Also, will not performing PoP be a >> good outcome? > >What would be the point of proving to myself that I own a key? It would not be useful to you, but rather to someone who puts it in a DNS record, if that someone does so on your behalf. Otherwise that entity does not know if the public key really is yours. But, I don't know that this results in a vulnerability for the DANE context. 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 5A1823A67D3 for ; Mon, 21 Feb 2011 17:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 D0VrTYwjmKxO for ; Mon, 21 Feb 2011 17:49:00 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id D3EDA3A67CF for ; Mon, 21 Feb 2011 17:48:59 -0800 (PST) Received: by bwz12 with SMTP id 12so3195529bwz.27 for ; Mon, 21 Feb 2011 17:49:42 -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=KA9f9P2nFCycd9BYi60+NnX59d1o+THV2pab8tESDI4=; b=kN+9G0nnmTVfbPN8KIaGvxQUqQBIiG70y0YfsMQgikHjena8Q960sN54Ap28D118ON AOTSyJgZFPb1oF9jEmiMY6zGyptstK9XwBgXbiGTliCGRiZQZK+hRdcNeZJDDJP219Rh J09+dISrnH4HG7nBJoSTij0/EIArPD09726Jo= 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=wEUxdiovKYeHvi/8kw7lZnUcIHcRt+3b0cHMf8c1PMdtn/5PJ5wdWtHbq3AdpcH/OV 1AmweIoamp7QteEoi2D5l9FzSuJQ5TgswsSkHl3vF4aj7vkGidlVmONGFnud7wWqUSUg csoCWh786e5YAWMhFoZzxcoop9LQbe5XkWrd8= MIME-Version: 1.0 Received: by 10.204.122.68 with SMTP id k4mr1948402bkr.153.1298339381746; Mon, 21 Feb 2011 17:49:41 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 17:49:41 -0800 (PST) In-Reply-To: <4D62F27A.4000605@vpnc.org> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <4D629711.70300@vpnc.org> <4D62F27A.4000605@vpnc.org> Date: Mon, 21 Feb 2011 17:49:41 -0800 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e6dee788a59c16049cd53196 Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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: Tue, 22 Feb 2011 01:49:01 -0000 --0016e6dee788a59c16049cd53196 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 21, 2011 at 3:17 PM, Paul Hoffman wrote: > > No, because the cert from TLSA won't match the cert in TLS. If the TLSA > cert is an EE cert that is erroneously marked as a CA cert, the TLS client > will try to match it against a trust anchor in the chain after the cert > offered by the TLS server and won't find it. If the TLSA cert is a CA cert > that is erroneously marked as an EE cert, the TLS server won't have the > private key for that CA. I think this is OK and that Steve's concern is not going to be realized because there is going to be a very high probability that most if not all code is going to recognize this distinction. This could be a problem if there was a risk that only a small number of clients would make the check in this fashion; In practice admins tend to use trial and error as their basis for configuration. But I think there should be a high probability that this is going to be rejected by most clients. We should probably make it a MUST though. For a cert to be accepted as a signing cert it has to be marked as such in BOTH places. For a cert to be accepted as EE it has to be marked as such in the DNS. -- Website: http://hallambaker.com/ --0016e6dee788a59c16049cd53196 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 21, 2011 at 3:17 PM, Paul Ho= ffman <paul.h= offman@vpnc.org> wrote:
No, because the cert from TLSA won't match the cert in TLS. If the TLSA= cert is an EE cert that is erroneously marked as a CA cert, the TLS client= will try to match it against a trust anchor in the chain after the cert of= fered by the TLS server and won't find it. If the TLSA cert is a CA cer= t that is erroneously marked as an EE cert, the TLS server won't have t= he private key for that CA.

I think this is OK and that Steve's concern is not = going to be realized because there is going to be a very high probability t= hat most if not all code is going to recognize this distinction.=A0

This could be a problem if there was a risk that only = a small number of clients would make the check in this fashion; In practice= admins tend to use trial and error as their basis for configuration. But I= think there should be a high probability that this is going to be rejected= by most clients.


We should probably make it a MUST though. For a cer= t to be accepted as a signing cert it has to be marked as such in BOTH plac= es. For a cert to be accepted as EE it has to be marked as such in the DNS.=

--0016e6dee788a59c16049cd53196-- 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 19E533A67B6 for ; Mon, 21 Feb 2011 17:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 M2Hl7weu2xT0 for ; Mon, 21 Feb 2011 17:42:26 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id DE86C3A67B4 for ; Mon, 21 Feb 2011 17:42:25 -0800 (PST) Received: by bwz12 with SMTP id 12so3192077bwz.27 for ; Mon, 21 Feb 2011 17:43:08 -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=bnA+gsg3VD3ooiBQep1kIBjx0gXie+a+eNbDN3X3ziE=; b=YdTehzKAFV+fxS1LoV2i4nvYAAyq+fiKIM2ywX46FBH9xAA+GZRpIPb8lcajdEK8eL JWQarBzpMjKvxaTD7ICs2/p1f+4r0VmyqTvqcEJLJmPZkQbPhLEaYTxVOMz83jny4n7o T4cUxkO2BqFpzd5tjTHXCsXbEjpXwCnuIN5vU= 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=pqmgOdqRBVa6rSMMexXK6rAIIV0Vy4RkUZIrJ377ZSHjkQILpbzx4hNZd7h6kbI/0r fKdkDL30jTyOr6wKleFfURTyuE6LZoqz+SxYFa3p2gQ7dYUObRL36v2p9En2ChnrpYTY Pjny7HSh4/eJHDVo0/NzWD6KItMOiMdl6kH3g= MIME-Version: 1.0 Received: by 10.204.119.75 with SMTP id y11mr1988022bkq.18.1298338987217; Mon, 21 Feb 2011 17:43:07 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 17:43:07 -0800 (PST) In-Reply-To: References: <20110221144527.GB25182@odin.mars.sol> Date: Mon, 21 Feb 2011 17:43:07 -0800 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6d59eac219282049cd51a9b Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 01:42:28 -0000 --0016e6d59eac219282049cd51a9b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 21, 2011 at 4:36 PM, Paul Wouters wrote: > On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > > [ silly bytes discussion ] > > > I get rather fed up of this form of argument where issues that affect all >> forms of PKI are to be held against X.509 and discounted or ignored as far >> as your >> alternative proposal goes. >> > > That's because you yourself are not consistent, don't shoot the > messenger. No, I am not shooting the messenger, I am finding him to be hopelessly biased, ill informed and confused. > You can't selectively claim 20 years of operational experience > as an asset in every other email, yet complain when that same operational > experience, and the inherit faults of those systems of the last 20 years > are pointed out. I complain that your comments are biased and poorly informed. I am aware that there are issues with PKIX, there are issues with all deployed protocols. But I also take the time to understand the reasons behind the issues. > Faults which are the reason for developing a DANE system. > The operational experience comes from people implementing and using the system. I don't see any real difference in the architecture, the syntax or the people involved. Insanity is doing the same thing twice and expecting a different result. ASN.1 is a real dog to implement. I know, I have implemented several DER encoders and parsers and it is just abominable. But so is the DNS record format. PKIX path math is tedious, but so is DNSSEC chain validation. Now you can make PKIX path math considerably worse than DNSSEC chain validation, but to do so you have to implement the set of features whose sole purpose is to keep government contractors in business. > Also, I never heard you argue against CAA because it adds "bytes and > complexity" to the resolver code and TLS client. So clearly the situation > is a little more broad then 5MB of windows binary. > CAA should do its job without adding a single line of code to any client or server library. The only parties that are required to implement CAA are CAs. Nobody else need write a single line of code. If the scheme works correctly it should deter CAs from mis-issue and give them the tools to avoid doing so at the same time. There is a client side capability in CAA, and that is certainly something that would be very useful to have. But that functionality should only ever be relevant when we are having the type of events we have been having in the past few weeks when governments have actually been out co-ercing Internet technology providers. > In other words, you are cherry picking your arguments. Others have already > stated that implementing bare public key at worst is a subset of ASN.1, > so let's just drop this whole "added complexity is not justified". > Not at all, I actually bothered to talk about this with the code maintainer last week. I also have rather more experience with the range of code libraries that are used. TLS libraries that currently exist have APIs that assume that an X.509/PKIX certificate will be offered during the initial TLS handshake. > That discussion can be had when we have a draft for TLS bare public key. > Well this is the wrong WG to go to for that. If you want to do bare key in TLS then you should go to the TLS list and see what type of reception you get. We are proposing an alternative code path here. That is inevitably going to >> result in a net increase in the complexity of the system, unless the code >> paths >> are rejected in their entirety. >> > > So you are arguing that CAA should be dropped as well? First CAA does not mandate client code. Second, I have never sold CAA as being a mechanism to simplify PKI code. Thus a minor increase in complexity of the code is irrelevant for my proposal but fatal for yours where the only intended purpose is a purported reduction in code complexity. If I propose using motor oil as a lubricant in my car, the fact that it does not taste good as a desert topping for jello is not relevant. If on the other hand you are proposing an alternative lubricant on the basis that it can be used as a desert topping, the fact that it tastes terrible and is probably carcinogenic is rather relevant to the debate. -- Website: http://hallambaker.com/ --0016e6d59eac219282049cd51a9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 21, 2011 at 4:36 PM, Paul Wo= uters <paul@xele= rance.com> wrote:
On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

[ silly bytes discussion ]


I get rather fed up of this form of argument where issues that affect all f= orms of PKI are to be held against X.509 and discounted or ignored as far a= s your
alternative proposal goes.

That's because you yourself are not consistent, don't shoot the
messenger.

No, I am not shooting the messen= ger, I am finding him to be hopelessly biased, ill informed and confused.

=A0
You can't selectively claim 20 years of operational experience
as an asset in every other email, yet complain when that same operational experience, and the inherit faults of those systems of the last 20 years are pointed out.

I complain that your comm= ents are biased and poorly informed. I am aware that there are issues with = PKIX, there are issues with all deployed protocols. But I also take the tim= e to understand the reasons behind the issues.=A0

=A0
Faults which a= re the reason for developing a DANE system.

=
The operational experience comes from people implementing and using the sys= tem. I don't see any real difference in the architecture, the syntax or= the people involved. Insanity is doing the same thing twice and expecting = a different result.

ASN.1 is a real dog to implement. I know, I have implem= ented several DER encoders and parsers and it is just abominable. But so is= the DNS =A0record format.

PKIX path math is tedio= us, but so is DNSSEC chain validation. Now you can make PKIX path math cons= iderably worse than DNSSEC chain validation, but to do so you have to imple= ment the set of features whose sole purpose is to keep government contracto= rs in business.=A0

=A0
Also, I never = heard you argue against CAA because it adds "bytes and
complexity" to the resolver code and TLS client. So clearly the situat= ion
is a little more broad then 5MB of windows binary.
CAA should do its job without adding a single line of code to a= ny client or server library.

The only parties that= are required to implement CAA are CAs. Nobody else need write a single lin= e of code. If the scheme works correctly it should deter CAs from mis-issue= and give them the tools to avoid doing so at the same time.

There is a client side capability in CAA, and that is c= ertainly something that would be very useful to have. But that functionalit= y should only ever be relevant when we are having the type of events we hav= e been having in the past few weeks when governments have actually been out= co-ercing Internet technology providers.

=A0
In other words, you are cherry picking your arguments. Others have already<= br> stated that implementing bare public key at worst is a subset of ASN.1,
so let's just drop this whole "added complexity is not justified&q= uot;.

Not at all, I actually bothered t= o talk about this with the code maintainer last week. I also have rather mo= re experience with the range of code libraries that are used. TLS libraries= that currently exist have APIs that assume that an X.509/PKIX certificate = will be offered during the initial TLS handshake. =A0


=A0
That discussion can be had when we have a draft for TLS bare public key.

Well this is the wrong WG to go to for th= at. If you want to do bare key in TLS then you should go to the TLS list an= d see what type of reception you get.

We are proposing an alternative code path here. That is inevitably going to= result in a net increase in the complexity of the system, unless the code = paths
are rejected in their entirety.

So you are arguing that CAA should be dropped as well?
First CAA does not mandate client code.

Second, I have never sold CAA as being a mechanism to simplify PKI code. = Thus a minor increase in complexity of the code is irrelevant for my propos= al but fatal for yours where the only intended purpose is a purported reduc= tion in code complexity.


If I propose using motor oil as a lubric= ant in my car, the fact that it does not taste good as a desert topping for= jello is not relevant. If on the other hand you are proposing an alternati= ve lubricant on the basis that it can be used as a desert topping, the fact= that it tastes terrible and is probably carcinogenic is rather relevant to= the debate.

--
Website: ht= tp://hallambaker.com/

--0016e6d59eac219282049cd51a9b-- 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 69D663A67A8 for ; Mon, 21 Feb 2011 16:36:13 -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 EjyQ9bLKvdZK for ; Mon, 21 Feb 2011 16:36:07 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4D2023A67A4 for ; Mon, 21 Feb 2011 16:36:06 -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 E55DEC50F; Mon, 21 Feb 2011 19:36:47 -0500 (EST) Date: Mon, 21 Feb 2011 19:36:47 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110221144527.GB25182@odin.mars.sol> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 00:36:13 -0000 On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: [ silly bytes discussion ] > I get rather fed up of this form of argument where issues that affect all forms of PKI are to be held against X.509 and discounted or ignored as far as your > alternative proposal goes. That's because you yourself are not consistent, don't shoot the messenger. You can't selectively claim 20 years of operational experience as an asset in every other email, yet complain when that same operational experience, and the inherit faults of those systems of the last 20 years are pointed out. Faults which are the reason for developing a DANE system. Also, I never heard you argue against CAA because it adds "bytes and complexity" to the resolver code and TLS client. So clearly the situation is a little more broad then 5MB of windows binary. In other words, you are cherry picking your arguments. Others have already stated that implementing bare public key at worst is a subset of ASN.1, so let's just drop this whole "added complexity is not justified". That discussion can be had when we have a draft for TLS bare public key. And like others have stated here, the minimum we need to do for DANE now is to ensure that if such a TLS method is added, TLSA will be able to add support for it without a total rewrite. > We are proposing an alternative code path here. That is inevitably going to result in a net increase in the complexity of the system, unless the code paths > are rejected in their entirety. So you are arguing that CAA should be dropped as well? > > The only way that an existing legacy infrastructure can be made simpler is to profile and subset. That is often valuable work. And efforts like DANE can > provide features that enable a future simplification step. Indeed, and bare public key is one of the items people are looking at to vastly simplify for the immediate future. 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 946013A6784 for ; Mon, 21 Feb 2011 16:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 XUg6YqDZ6gJU for ; Mon, 21 Feb 2011 16:01:23 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 2D6703A657C for ; Mon, 21 Feb 2011 16:01:23 -0800 (PST) Received: by bwz12 with SMTP id 12so3130851bwz.27 for ; Mon, 21 Feb 2011 16:02: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=2mN1D3F7amyW3E/l43kWWB261dov6grIFzLp/ua0G1Q=; b=QHVmRgN32Q5ZqGgVAYpuwVPxJ+aIUKxRo/oFYsG9Kr+44jpj7/Me4ocuatCCs81IGR FSCZMYimLR/POPz356q9WuG+3P0Gfi2e2zI8xYK/Sx7bFnkr+asrAZA6MvrJj/TqeG1I X+/LCsKHLzTnA1g8iXj/qJRW/UG90kcVscNXE= 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=WqqWWTqtHn8UCSgeXyDRcd0rKb0sDQLTZfVPtPlHn8FYQww/3oE0/GRS7Yf2qLVedQ MlWRx3Nx/bM35j31nhxqcBRByiRtTyeZClePwKlIJ8XBrO18Mg4QwopJZgmCaBKNwgMb xFA3yi/zbJwFEyiLkypdrNPgiKFMXlEcrb8QA= MIME-Version: 1.0 Received: by 10.204.119.75 with SMTP id y11mr1924620bkq.18.1298332924528; Mon, 21 Feb 2011 16:02:04 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 16:02:04 -0800 (PST) In-Reply-To: References: <20110221144527.GB25182@odin.mars.sol> Date: Mon, 21 Feb 2011 16:02:04 -0800 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e6d59eacc44735049cd3b067 Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 22 Feb 2011 00:01:25 -0000 --0016e6d59eacc44735049cd3b067 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 21, 2011 at 1:11 PM, Paul Wouters wrote: > On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > > On windows, I assume that a DNSSEC resolver library will come with the OS > in the near future, so no > additional bytes are added. > Ah so complexity in the operating system does not count? If you are going to pull that one, then your whole argument falls because X.509 is built into the core of Windows and has been for a decade. So by your measure the complexity of X.509 does not count either. I get rather fed up of this form of argument where issues that affect all forms of PKI are to be held against X.509 and discounted or ignored as far as your alternative proposal goes. We are proposing an alternative code path here. That is inevitably going to result in a net increase in the complexity of the system, unless the code paths are rejected in their entirety. The only way that an existing legacy infrastructure can be made simpler is to profile and subset. That is often valuable work. And efforts like DANE can provide features that enable a future simplification step. But that lies far in the future, in the near term the result will be more complexity. -- Website: http://hallambaker.com/ --0016e6d59eacc44735049cd3b067 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Feb 21, 2011 at 1:11 PM, Paul Wouters <paul@xelerance.com> wrote:
=
On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

<= /div> On windows, I assume that a DNSSEC resolver library will come with the OS i= n the near future, so no
additional bytes are added.

Ah so compl= exity in the operating system does not count?

If y= ou are going to pull that one, then your whole argument falls because X.509= is built into the core of Windows and has been for a decade. So by your me= asure the complexity of X.509 does not count either.


I get rather fed up of this form of argu= ment where issues that affect all forms of PKI are to be held against X.509= and discounted or ignored as far as your alternative proposal goes.

We are proposing an alternative code path here. That is= inevitably going to result in a net increase in the complexity of the syst= em, unless the code paths are rejected in their entirety.


The only way that an existing legacy infrastructu= re can be made simpler is to profile and subset. That is often valuable wor= k. And efforts like DANE can provide features that enable a future simplifi= cation step. But that lies far in the future, in the near term the result w= ill be more complexity.

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

--0016e6d59eacc44735049cd3b067-- 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 D74293A6452 for ; Mon, 21 Feb 2011 15:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_44=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 2Vp97nNe839K for ; Mon, 21 Feb 2011 15:49:01 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 565BA3A63CA for ; Mon, 21 Feb 2011 15:49:01 -0800 (PST) Received: by bwz12 with SMTP id 12so3123615bwz.27 for ; Mon, 21 Feb 2011 15:49:43 -0800 (PST) Received: by 10.204.77.196 with SMTP id h4mr1869190bkk.89.1298332182941; Mon, 21 Feb 2011 15:49:42 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id 12sm4119416bki.7.2011.02.21.15.49.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 15:49:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Tue, 22 Feb 2011 00:49:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net> References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 21 Feb 2011 23:49:03 -0000 On 21 Feb 2011, at 23:10, Stephen Kent wrote: > At 4:29 PM +0100 2/21/11, Henry Story wrote: >> (Just a summary of what I understood of this thread, and a few new = ideas) >>=20 >> On 20 Feb 2011, at 23:58, Paul Hoffman wrote: >>=20 >>> On 2/20/11 2:51 PM, Paul Wouters wrote: >>>> The whole point is we do not want to identify a cert. We want to = identify a key. >>>=20 >>> That's not the case currently, at least for many of us. Given that = the only thing that can be used in TLS to identify the server is a = certificate, most of us want to identify that certificate (or a trust = anchor that the certificate chains to). >>=20 >> One needs to go beyond appearances a little here. My argument is that = what identifies a server in TLS is a public key. >=20 > Do you mean "identifies" or "authenticates?" I think most folks view = the DNS name (or URL) as the identity of the web site. Partly. The DNS domain name is a name that one could think of as = referring to a set of services, each of those having a name of the form = name:port. The relation between the service name and the public key = forms an identifying description, or I should say a definite = description as it is known in philosophy. I used the following example: name:port knowsPrivateKeyof pubK=20 That sentence does not authenticate, it describes. But it is part of the = TLS authentication protocol. Authentication is the process that uses = that information to prove the authorship of the messages sent down a = socket. > We're debating the mechanics of how to enable a client to verify that = the asserted identity matches the client's expectations, based on the = content of a series of DNS records. Yes, that is what the next part of my e-mail was describing the logic = of. Now in the case of server identity the client knows what it wants = the server's identity to be, since it initiated the call, went to DNS, = found the ip address, and connected. The clienet can then use the public = key found in DNS (or returned by the server) to authenticate the = service it is connected to. >=20 > Steve Social Web Architect http://bblfish.net/ 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 9B44C3A717C for ; Mon, 21 Feb 2011 15:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.369 X-Spam-Level: X-Spam-Status: No, score=-101.369 tagged_above=-999 required=5 tests=[AWL=0.677, 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 sPepNGblnbGm for ; Mon, 21 Feb 2011 15:16:33 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B25D93A6FE6 for ; Mon, 21 Feb 2011 15:16: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 p1LNHEmu004489 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2011 16:17:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D62F27A.4000605@vpnc.org> Date: Mon, 21 Feb 2011 15:17:14 -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: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <4D629711.70300@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 23:16:34 -0000 On 2/21/11 2:16 PM, Stephen Kent wrote: > At 8:47 AM -0800 2/21/11, Paul Hoffman wrote: >> On 2/21/11 4:55 AM, Stephen Kent wrote: >>> At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >>>> #20: Change the format of the two fields to have fewer certificate >>>> types >>>> >>>> To reduce the chance that someone could give a certificate type that >>>> doesn't match the hash type, change the fields as follows: >>>> >>>> o A one-octet value, called "certificate type", specifying the >>>> provided association that will be used to match the target >>>> certificate. This will be an IANA registry in order to make it >>>> easier to add additional certificate types in the future. The >>>> types defined in this document are: >>>> >>>> 1 -- An end-entity certificate >>>> >>>> 2 -- A certification authority's certificate >>> >>> if we're talking about X.509 certs, this distinction is already >>> expressed >>> within the cert itself, via the BasicConstraints extension. Not sure why >>> one would need to express this cert type in the record as well, when a >>> cert (vs. hash) is present). >> >> Simplicity. If you know you are holding an EE cert, you do this; if >> you know you are holding a CA cert, you do that. If we remove the >> differentiation in TLSA protocol, we force every client to do >> something they don't have to do now, namely to disassemble the cert to >> determine the type. That currently happens in the path processing >> software, but that software is usually a black box to the main TLS >> software. If we eliminate the certificate type differentiation, it has >> to happen before certificate comparison can happen. > > Thanks. That's a good rationale. >> >>> Even if a cert hash is the record content, >>> when the >>> relying party matches the hash against the cert, the cert will still say >>> whether it is an E or a CA cert. If we put this info here, it creates an >>> opportunity >>> for a mismatch between the two, and a need to describe (and defend) why >>> one trumps the other. >> >> Fully agree on the possibility of the mismatch, but in that case the >> TLSA association will fail for everyone and the DNS admin will hear >> about it. The cost of the possibility of mismatch should be weighed >> against the cost of making everyone add new ASN.1 parsing code to look >> for the cA bit in the basicConstraints extension. > > The association will fail because we have decided which marking takes > precedence? No, because the cert from TLSA won't match the cert in TLS. If the TLSA cert is an EE cert that is erroneously marked as a CA cert, the TLS client will try to match it against a trust anchor in the chain after the cert offered by the TLS server and won't find it. If the TLSA cert is a CA cert that is erroneously marked as an EE cert, the TLS server won't have the private key for that CA. 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 037F93A7196 for ; Mon, 21 Feb 2011 14:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0zUhzLVdM8w for ; Mon, 21 Feb 2011 14:21:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D0A933A7191 for ; Mon, 21 Feb 2011 14:21:41 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:38956 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pre98-000LNm-Vd; Mon, 21 Feb 2011 17:22:23 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D629711.70300@vpnc.org> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <4D629711.70300@vpnc.org> Date: Mon, 21 Feb 2011 17:16:11 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 22:21:44 -0000 At 8:47 AM -0800 2/21/11, Paul Hoffman wrote: >On 2/21/11 4:55 AM, Stephen Kent wrote: >>At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >>>#20: Change the format of the two fields to have fewer certificate types >>> >>>To reduce the chance that someone could give a certificate type that >>>doesn't match the hash type, change the fields as follows: >>> >>>o A one-octet value, called "certificate type", specifying the >>>provided association that will be used to match the target >>>certificate. This will be an IANA registry in order to make it >>>easier to add additional certificate types in the future. The >>>types defined in this document are: >>> >>>1 -- An end-entity certificate >>> >>>2 -- A certification authority's certificate >> >>if we're talking about X.509 certs, this distinction is already expressed >>within the cert itself, via the BasicConstraints extension. Not sure why >>one would need to express this cert type in the record as well, when a >>cert (vs. hash) is present). > >Simplicity. If you know you are holding an EE cert, you do this; if >you know you are holding a CA cert, you do that. If we remove the >differentiation in TLSA protocol, we force every client to do >something they don't have to do now, namely to disassemble the cert >to determine the type. That currently happens in the path processing >software, but that software is usually a black box to the main TLS >software. If we eliminate the certificate type differentiation, it >has to happen before certificate comparison can happen. Thanks. That's a good rationale. > >>Even if a cert hash is the record content, >>when the >>relying party matches the hash against the cert, the cert will still say >>whether it is an E or a CA cert. If we put this info here, it creates an >>opportunity >>for a mismatch between the two, and a need to describe (and defend) why >>one trumps the other. > >Fully agree on the possibility of the mismatch, but in that case the >TLSA association will fail for everyone and the DNS admin will hear >about it. The cost of the possibility of mismatch should be weighed >against the cost of making everyone add new ASN.1 parsing code to >look for the cA bit in the basicConstraints extension. The association will fail because we have decided which marking takes precedence? 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 103DC3A7193 for ; Mon, 21 Feb 2011 14:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 6GOcmV4OnAOW for ; Mon, 21 Feb 2011 14:21:39 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6BB953A7191 for ; Mon, 21 Feb 2011 14:21:39 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:38956 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pre97-000LNm-1R; Mon, 21 Feb 2011 17:22:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> Date: Mon, 21 Feb 2011 17:13:54 -0500 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: trac@tools.ietf.org, keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 22:21:41 -0000 At 5:37 AM -0800 2/21/11, Phillip Hallam-Baker wrote: >There are two sets of issues: > >1) To distinguish between different types of X.509v3 cert > >2) To distinguish between different types of cert (X.509, SAML, PGP, etc...) > > >The first is covered by the X.509 spec, the second is not. So either >the spec has to say that it only allows use of X.509 keys or there >has to be a mechanism to allow the client to work out what type of >information it is handling. For a non-X.59 cert that does not express CA vs. EE attribute this marking might be useful. What types of certs are benign considered that have these attributes but do not encode it internally? 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 D0AF33A717A for ; Mon, 21 Feb 2011 14:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 gOG4UAnfC3rq for ; Mon, 21 Feb 2011 14:21:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4DC5B3A716D for ; Mon, 21 Feb 2011 14:21:32 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:38956 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pre8u-000LNm-13; Mon, 21 Feb 2011 17:22:08 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> References: <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> Date: Mon, 21 Feb 2011 17:10:53 -0500 To: Henry Story From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 21 Feb 2011 22:21:33 -0000 At 4:29 PM +0100 2/21/11, Henry Story wrote: >(Just a summary of what I understood of this thread, and a few new ideas) > >On 20 Feb 2011, at 23:58, Paul Hoffman wrote: > >> On 2/20/11 2:51 PM, Paul Wouters wrote: >>> The whole point is we do not want to identify a cert. We want to >>>identify a key. >> >> That's not the case currently, at least for many of us. Given that >>the only thing that can be used in TLS to identify the server is a >>certificate, most of us want to identify that certificate (or a >>trust anchor that the certificate chains to). > >One needs to go beyond appearances a little here. My argument is >that what identifies a server in TLS is a public key. Do you mean "identifies" or "authenticates?" I think most folks view the DNS name (or URL) as the identity of the web site. We're debating the mechanics of how to enable a client to verify that the asserted identity matches the client's expectations, based on the content of a series of DNS records. 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 D59233A711E for ; Mon, 21 Feb 2011 14:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 rTrvG8I2yB-x for ; Mon, 21 Feb 2011 14:00:56 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 65B283A6E51 for ; Mon, 21 Feb 2011 14:00:56 -0800 (PST) Received: by bwz12 with SMTP id 12so3049907bwz.27 for ; Mon, 21 Feb 2011 14:01:38 -0800 (PST) Received: by 10.204.68.81 with SMTP id u17mr1768969bki.39.1298325698012; Mon, 21 Feb 2011 14:01:38 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id z18sm4058928bkf.20.2011.02.21.14.01.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 14:01:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <20110220053510.GC7481@odin.mars.sol> Date: Mon, 21 Feb 2011 23:01:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D54E4A9.1020104@gmail.com> <20110220053510.GC7481@odin.mars.sol> To: Scott Schmit X-Mailer: Apple Mail (2.1082) Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] dane-04 trust anchors 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, 21 Feb 2011 22:00:57 -0000 On 20 Feb 2011, at 06:35, Scott Schmit wrote: > On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote: >> On Fri, 11 Feb 2011, Yaron Sheffer wrote: >>> The client MUST obey any constraints included in the trust anchor, >>> including but not limited to: >>> - Validity period. >>=20 >> What to do if that period does not match the DNS TTL/RRSIG period? >=20 > The DNS TTL should be used to determine when the client MUST forget = the > certificate association and refetch the TLSA record if it needs it > again. I think that's the DANE equivalent to revocation (if the TLSA > record is replaced, the old cert was revoked). 1. the DNS Time To Live (TTL) is in WebID the HTTP Expires header 2. In WebID if the public key is no longer listed at the WebID Profile = then the client certificate is revoked. In Dane when the key is removed = from DNSsec the same happens. 3. In WebID there is an interesting twist: the client certificate = not-before, not-after time constraints can be very useful for end users = that are perhaps on less trusted machines and wish to create themselves = a time limited certificate. Those people should get their Social Web = server to create them a 1 hour certificate so that misuse of the = certificate can only last so long. >=20 > The RRSIG period serves a similar role to the Validity period in = X.509, > though it'll be much shorter than we're used to for PKIX. I would = think > that the most restrictive value wins. The notAfter field can always be > set to be never to avoid needing to regenerate the certificate. >=20 > You could probably argue that what I'm saying to use the TTL for is = what > the RRSIG period is for, but in my experience with DNSSEC tools, it's = a > lot more obvious to me how I'd control (without affecting the period = for > other records) the rate a client rechecks the certificate validity via > the TTL. >=20 > --=20 > Scott Schmit > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Social Web Architect http://bblfish.net/ 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 312E53A717A for ; Mon, 21 Feb 2011 13:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 yWHObaHJ+REc for ; Mon, 21 Feb 2011 13:37:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id CBD933A7157 for ; Mon, 21 Feb 2011 13:37:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1LLcB42025193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Feb 2011 22:38:11 +0100 (MET) From: Martin Rex Message-Id: <201102212138.p1LLcAuc027343@fs4113.wdf.sap.corp> To: i.grok@comcast.net (Scott Schmit) Date: Mon, 21 Feb 2011 22:38:10 +0100 (MET) In-Reply-To: <20110220053510.GC7481@odin.mars.sol> from "Scott Schmit" at Feb 20, 11 00:35:10 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] dane-04 trust anchors 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, 21 Feb 2011 21:37:32 -0000 Scott Schmit wrote: > > On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote: > > On Fri, 11 Feb 2011, Yaron Sheffer wrote: > > >The client MUST obey any constraints included in the trust anchor, > > >including but not limited to: > > >- Validity period. > > > > What to do if that period does not match the DNS TTL/RRSIG period? > > The DNS TTL should be used to determine when the client MUST forget the > certificate association and refetch the TLSA record if it needs it > again. I think that's the DANE equivalent to revocation (if the TLSA > record is replaced, the old cert was revoked). There seems to be confusion about the purpose of TTLs in DNS (and and the fact that TTL is _not_ protected by DNSSEC). See previous discussion, e.g. http://www.ietf.org/mail-archive/web/keyassure/current/msg01190.html While expiring cached records at TTL time make sense with or without DNSSEC, one must be aware that an attacker could replay DNSSEC signed records for as long as the RRSIG signature allows. Therefore, TTL can not be considered a revocation mechanism. -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 6B4D53A6F53 for ; Mon, 21 Feb 2011 13:13:16 -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 U16bOhr1yhMO for ; Mon, 21 Feb 2011 13:13:15 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 75EE63A6E6E for ; Mon, 21 Feb 2011 13:13: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 76E7AC50E; Mon, 21 Feb 2011 16:13:57 -0500 (EST) Date: Mon, 21 Feb 2011 16:13:56 -0500 (EST) From: Paul Wouters To: Scott Schmit In-Reply-To: <20110221144527.GB25182@odin.mars.sol> Message-ID: References: <20110221144527.GB25182@odin.mars.sol> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 21 Feb 2011 21:13:16 -0000 On Mon, 21 Feb 2011, Scott Schmit wrote: > So I would suggest (and I have no hat, it's just a suggestion) that the > question of bare keys be put aside for the moment. Agreed. > Looking at some typical certs, here are some sources of conflict I see: > * Subject identification (including alt names) vs domain name [???] > * Validity vs RRSIG period [take the min period] > * Name constraints vs domain name [???] > * CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated] > * CA flag, path length, etc vs the dane-04 cert type [???] I believe for DANE not to be reduced to the security of PKIX, DANE should be able ignore all of these. Otherwise DANE just becomes a vehicle for PKIX extensions like CAA - those might be a useful side effect, but not the main goal of DANE, which is to level DNSSEC for TLS services. But this is easilly done by not specifying those properties in your certificate. It needs no DANE protocol support. When specifying CRLs or OCSP or EV in the certs, and certifying the cert in DANE, these properties become validatable by DANE provided the Issuer can be validated as well - but in this case just DANE should not be enough, as DANE cannot speak for items like EV. > An item for security considerations: > * Now that CAs aren't necessarily issuing these certs, the client needs > to be much more careful in its parsing (the null terminated vs length- > delimited string bug comes to mind) Uhm no. Any code should already have taken everything into account. Such asusmptions caused the wildcard signed cert and the \0 CN. If the client trusted the CAs for this, it was already very broken. It is precisely why some rather trust their DNSOPS then any of the CA orgs, and is the reason why more respected CAs want to limit the impact of less respected CAs using DNSSEC validation. 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 3A99A3A70F9 for ; Mon, 21 Feb 2011 13:10:48 -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 mNzPDvP1kKQM for ; Mon, 21 Feb 2011 13:10:47 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 12AFB3A6F53 for ; Mon, 21 Feb 2011 13:10:47 -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 D4B69C50E; Mon, 21 Feb 2011 16:11:27 -0500 (EST) Date: Mon, 21 Feb 2011 16:11:27 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110221144527.GB25182@odin.mars.sol> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 21 Feb 2011 21:10:48 -0000 On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > On the contrary, > > What he has shown is that the changes to SSL are minor,  after adding in the DNSSEC resolver library > > I just pulled down the Windows binary from http://unbound.net/, it is 5.3 Mb. That's the server. If you want to compare raw sizes (which is silly to begin with but ok), then use: -rwxr-xr-x. 1 root root 807880 Jan 25 17:19 /usr/lib64/libunbound.so.2.8.0 On windows, I assume that a DNSSEC resolver library will come with the OS in the near future, so no additional bytes are added. Anyway, Henry Story also did a nice write up showing code complexity is a red herring when it comes to supporting bare public keys - because that was your argument, that a new format of bare public keys couldn't be done because the already complicated addition of DNSSEC validation in a TLS stack that has to support 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 F37983A716D for ; Mon, 21 Feb 2011 11:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 lCqs8EtfSdtf for ; Mon, 21 Feb 2011 11:48:16 -0800 (PST) Received: from mail-bw0-f42.google.com (mail-bw0-f42.google.com [209.85.214.42]) by core3.amsl.com (Postfix) with ESMTP id E40D63A7114 for ; Mon, 21 Feb 2011 11:48:15 -0800 (PST) Received: by bwz13 with SMTP id 13so4106495bwz.15 for ; Mon, 21 Feb 2011 11:48: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=JdIvt0gqJAAwU6muauTN61YrQQo8vYfZsFK/npe6UPI=; b=wHewI8UXolWoy7imx4uIa+Yx8Jfeo/S9qQKscLYGlHBiYdhrDnPcgqYupCcfraNJtg IRwF+xwpqwlTlznbTl0BexupMQr5sMaHMH8pSn4H3SGuXtZv9KwkgpEF/FkyPYAEqZMq ZUE3tnDRnP6Dy9uyeJXhpgIlkuPrbHIZCcLW8= 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=iwLbQd1NooNAg/vaUzGJq9DTJ3LzEMzHg5zxE2AUVW2e78xYC01MftN1z/REYz2pdA +0aIVBz3WMHY96BbCI5R13knATTK+x7LdiiwHem8c/SiI2f7CvdQP+xV2ShNqHUliAgG 32aEG0O9ChbmodNCruyWuMTJgeIPP20Df7chs= MIME-Version: 1.0 Received: by 10.204.129.83 with SMTP id n19mr1688250bks.207.1298317729420; Mon, 21 Feb 2011 11:48:49 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 11:48:49 -0800 (PST) In-Reply-To: References: <20110221144527.GB25182@odin.mars.sol> Date: Mon, 21 Feb 2011 11:48:49 -0800 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=00151747c070115596049cd02776 Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 21 Feb 2011 19:48:18 -0000 --00151747c070115596049cd02776 Content-Type: text/plain; charset=ISO-8859-1 On the contrary, What he has shown is that the changes to SSL are minor, *after adding in the DNSSEC resolver library* I just pulled down the Windows binary from http://unbound.net/, it is 5.3 Mb. Now that may not seem complex to you but it certainly does to me. And it is still going to be a lot of additional complexity if that can be reduced to the 50kb or so that is round about where it should be. security/nss/README.dane | 78 +++++++++++++ security/nss/cmd/tstclnt/tstclnt.c | 7 +- security/nss/lib/ssl/config.mk | 3 + security/nss/lib/ssl/manifest.mn | 1 + security/nss/lib/ssl/ssl.def | 6 + security/nss/lib/ssl/ssl.h | 3 + security/nss/lib/ssl/sslauth.c | 9 ++ security/nss/lib/ssl/ssldane.c | 218 ++++++++++++++++++++++++++++++++++++ security/nss/lib/ssl/sslerr.h | 7 + security/nss/lib/ssl/sslimpl.h | 4 + security/nss/lib/ssl/sslsecur.c | 26 +++++ security/nss/lib/ssl/sslsock.c | 1 + 12 files changed, 362 insertions(+), 1 deletions(-) diff --git a/security/nss/README.dane b/security/nss/README.dane new file mode 100644 index 0000000..ecbf442 --- /dev/null +++ b/security/nss/README.dane @@ -0,0 +1,78 @@ +This modified version of NSS contains a proof-of-concept implementation of the +draft DANE protocol (see https://tools.ietf.org/wg/dane/) for DNSSEC-based +authentication of TLS services. The implementation uses the libunbound DNSSEC +stub resolver (http://unbound.net/). It is far from ready for production or +upstream consideration, but it should be fun for experimentation. On Mon, Feb 21, 2011 at 11:35 AM, Paul Wouters wrote: > On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > > Adding DNSSEC into the code base is going to be a big enough increase in >> code complexity as it is. >> > > https://mattmccutchen.net/cryptid/nss-dane-20110215.patch > > 12 files changed, 362 insertions(+), 1 deletions(-) > > Matt showed it was far from complex. > > Paul > -- Website: http://hallambaker.com/ --00151747c070115596049cd02776 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
<=
font class=3D"Apple-style-span" face=3D"'times new roman', serif">O=
n the contrary,
What he has=
 shown is that the changes to SSL are minor, =A0after adding in the DNSS=
EC resolver library
I just pull=
ed down the Windows binary from http://unbo=
und.net/, it is 5.3 Mb.
Now that ma=
y not seem complex to you but it certainly does to me. And it is still goin=
g to be a lot of additional complexity if that can be reduced to the 50kb o=
r so that is round about where it should be.

security/nss/README.dane           |   78 +++++++++=
++++
 security/nss/cmd/tstclnt/tstclnt.c |    7 +-
 security/nss/lib/ssl/config.mk     |    3=
 +
 security/nss/lib/ssl/manifest.mn   |   =
 1 +
 security/nss/lib/ssl/ssl.def       |    6 +
 security/nss/lib/ssl/ssl.h         |    3 +
 security/nss/lib/ssl/sslauth.c     |    9 ++
 security/nss/lib/ssl/ssldane.c     |  218 ++++++++++++++++++++++++++++++++=
++++
 security/nss/lib/ssl/sslerr.h      |    7 +
 security/nss/lib/ssl/sslimpl.h     |    4 +
 security/nss/lib/ssl/sslsecur.c    |   26 +++++
 security/nss/lib/ssl/sslsock.c     |    1 +
 12 files changed, 362 insertions(+), 1 deletions(-)

diff --git a/security/nss/README.dane b/security/nss/README.dane
new file mode 100644
index 0000000..ecbf442
--- /dev/null
+++ b/security/nss/README.dane
@@ -0,0 +1,78 @@
+This modified version of NSS contains a proof-of-concept implementation of=
 the
+draft DANE protocol (see https=
://tools.ietf.org/wg/dane/) for DNSSEC-based
+authentication of TLS services.  The implementation uses the libunbound DN=
SSEC
+stub resolver (http://unbound.net/).  =
It is far from ready for production or
+upstream consideration, but it should be fun for experimentation.

On Mon, Feb 21, 2011 at 11:35 AM, Paul W= outers <paul@xel= erance.com> wrote:
On Mon, 21 Feb 2011, Phil= lip Hallam-Baker wrote:

Adding DNSSEC into the code base is going to be a big enough increase in co= de complexity as it is.

https://mattmccutchen.net/cryptid/nss-dane-20110215.patc= h

12 files changed, 362 insertions(+), 1 deletions(-)

Matt showed it was far from complex.

Paul



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

--00151747c070115596049cd02776-- 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 92A973A7166 for ; Mon, 21 Feb 2011 11:34:56 -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 N275Lh2B95lo for ; Mon, 21 Feb 2011 11:34:52 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id CD2AF3A7169 for ; Mon, 21 Feb 2011 11:34:51 -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 88925C50E; Mon, 21 Feb 2011 14:35:32 -0500 (EST) Date: Mon, 21 Feb 2011 14:35:32 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <20110221144527.GB25182@odin.mars.sol> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Scott Schmit , keyassure@ietf.org Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 21 Feb 2011 19:34:56 -0000 On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote: > Adding DNSSEC into the code base is going to be a big enough increase in code complexity as it is. https://mattmccutchen.net/cryptid/nss-dane-20110215.patch 12 files changed, 362 insertions(+), 1 deletions(-) Matt showed it was far from complex. 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 B41FB3A70D6 for ; Mon, 21 Feb 2011 09:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.022, 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 8k3TkJ17RBSI for ; Mon, 21 Feb 2011 09:38: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 3F2013A6FE0 for ; Mon, 21 Feb 2011 09:38:37 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1LHdE22022186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Feb 2011 18:39:14 +0100 (MET) From: Martin Rex Message-Id: <201102211739.p1LHdDTA012923@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Mon, 21 Feb 2011 18:39:13 +0100 (MET) In-Reply-To: from "Stephen Kent" at Feb 21, 11 07:55:31 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: keyassure@ietf.org, trac@tools.ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the 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, 21 Feb 2011 17:38:39 -0000 Stephen Kent wrote: > > At 7:59 PM +0000 2/20/11, dane issue tracker wrote: > >#20: Change the format of the two fields to have fewer certificate types > > > > To reduce the chance that someone could give a certificate type that > > doesn't match the hash type, change the fields as follows: > > > > o A one-octet value, called "certificate type", specifying the > > provided association that will be used to match the target > > certificate. This will be an IANA registry in order to make it > > easier to add additional certificate types in the future. The > > types defined in this document are: > > > > 1 -- An end-entity certificate > > > > 2 -- A certification authority's certificate > > if we're talking about X.509 certs, this distinction is already expressed > within the cert itself, via the BasicConstraints extension. Not sure > why one would need to express this cert type in the record as well, > when a cert (vs. hash) is present). Simplicity and robustness. When simple public keys for servers are to be used with DANE, these will usually be X.509v1 certificates, which do not contain a BasicConstraints extension. Based on X.509 itself, a certificate without the BasisConstraints extension "cA=FALSE" is _not_ limited to be an end-entity cert. The requirement that a CA certificate is required to contain a "BasicConstraints cA=TRUE" marked critical extension is specific to PKIX (rfc-5280 and predecessors). But the CA-certificate conveyed through dane is more of a trust anchor than a CA to an rfc5280 path validation, so it may be difficult to enforce the Basic Constraints attribute check. Keep in mind that even "renowned" commercial CAs get this wrong !! My Firefox 3.5.13 contains a Trust Anchor called "Entrust.net Certification Authority (2048)" that does not carry a BasicConstraints extension. I know that Entrust is (or has been) issuing Web Server certificates under this TA, because I received a few customer problems where our software rejected server credentials under this rootCA due to its lack of the BasicConstraints extension in an X.509v3(!) certificate. -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 5F7BA3A6FF0 for ; Mon, 21 Feb 2011 08:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.357 X-Spam-Level: X-Spam-Status: No, score=-101.357 tagged_above=-999 required=5 tests=[AWL=0.689, 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 MGomisRuJ3zy for ; Mon, 21 Feb 2011 08:49:55 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8AC493A6FEF for ; Mon, 21 Feb 2011 08:49: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 p1LGoaBY064612 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2011 09:50:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6297DC.1030901@vpnc.org> Date: Mon, 21 Feb 2011 08:50:36 -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: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> <4D617535.9040404@vpnc.org> 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-04.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: Mon, 21 Feb 2011 16:49:56 -0000 On 2/21/11 4:57 AM, Stephen Kent wrote: > At 12:10 PM -0800 2/20/11, Paul Hoffman wrote: >> On 2/19/11 8:21 PM, Scott Schmit wrote: >>> Some of these are nits, some not: >> >> And all are appreciated. >> >>> Abstract: >>> --------- >>> >>>> 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. >>> >>> I would argue that in DNSSEC, each zone operator is a CA, just not a >>> PKIX CA. >> >> I would disagree. It is a trust anchor, not a certification authority. >> Yes, most users today don't understand the difference, but we should >> still be fairly precise in our language because some do. In specific, >> certification authorities do many things that are unimportant to most >> users but are definitely not done by zone operators. For example, zone >> operators probably do not do proof-of-possession checks for the the >> private key paired to the public key in the certificate, whereas most >> CAs do. > > I agree that the info in the record could be a TA, and not a CA, but not if > the format of the data is an X.509 cert. The data might not always be an X.509 cert. TLS might be extended to use bare keys in the server's certificate message, and/or using OpenPGP certificates might end up being a standard, and/or other certification methods might appear in the future. I don't think that limiting TLSA to PKIX now is good planning for the future. > Also, will not performing PoP > be a good outcome? What would be the security reason for a DNS admin who has been told "please announce this certificate for this domain name" to need to learn about proof-of-possession? 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 191533A6FE0 for ; Mon, 21 Feb 2011 08:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.345 X-Spam-Level: X-Spam-Status: No, score=-101.345 tagged_above=-999 required=5 tests=[AWL=0.701, 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 bujFd3yCNi0y for ; Mon, 21 Feb 2011 08:46:37 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 414B93A6DC6 for ; Mon, 21 Feb 2011 08:46: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 p1LGlEIG064478 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 09:47:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D629711.70300@vpnc.org> Date: Mon, 21 Feb 2011 08:47: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: Stephen Kent References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, dane issue tracker Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 16:46:38 -0000 On 2/21/11 4:55 AM, Stephen Kent wrote: > At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >> #20: Change the format of the two fields to have fewer certificate types >> >> To reduce the chance that someone could give a certificate type that >> doesn't match the hash type, change the fields as follows: >> >> o A one-octet value, called "certificate type", specifying the >> provided association that will be used to match the target >> certificate. This will be an IANA registry in order to make it >> easier to add additional certificate types in the future. The >> types defined in this document are: >> >> 1 -- An end-entity certificate >> >> 2 -- A certification authority's certificate > > if we're talking about X.509 certs, this distinction is already expressed > within the cert itself, via the BasicConstraints extension. Not sure why > one would need to express this cert type in the record as well, when a > cert (vs. hash) is present). Simplicity. If you know you are holding an EE cert, you do this; if you know you are holding a CA cert, you do that. If we remove the differentiation in TLSA protocol, we force every client to do something they don't have to do now, namely to disassemble the cert to determine the type. That currently happens in the path processing software, but that software is usually a black box to the main TLS software. If we eliminate the certificate type differentiation, it has to happen before certificate comparison can happen. > Even if a cert hash is the record content, > when the > relying party matches the hash against the cert, the cert will still say > whether it is an E or a CA cert. If we put this info here, it creates an > opportunity > for a mismatch between the two, and a need to describe (and defend) why > one trumps the other. Fully agree on the possibility of the mismatch, but in that case the TLSA association will fail for everyone and the DNS admin will hear about it. The cost of the possibility of mismatch should be weighed against the cost of making everyone add new ASN.1 parsing code to look for the cA bit in the basicConstraints extension. 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 9D1353A6FEF for ; Mon, 21 Feb 2011 08:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 kIytJV+btgSl for ; Mon, 21 Feb 2011 08:35:53 -0800 (PST) Received: from mail-bw0-f42.google.com (mail-bw0-f42.google.com [209.85.214.42]) by core3.amsl.com (Postfix) with ESMTP id 1C5F83A6E0F for ; Mon, 21 Feb 2011 08:35:52 -0800 (PST) Received: by bwz13 with SMTP id 13so3899398bwz.15 for ; Mon, 21 Feb 2011 08:36:34 -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=NrdZkdifqpjUt2goAS1PWQnQBYCchiLI5p6uhk5+zrU=; b=DwwA3GOoZtAElvPdrK9sel7SYee9MWN4uzNCCwQfX+NtnWq6cvJ8/sJJzZXX5FVmcV ByiT3kCU0fNs0YUVAOEHGbanBT0B+NizZBxWwL/yClVfJse4EkK9yfDBTwZhRcSPxi8w E8Yhhq74BOTQyZ7gB/J3qeSwyqcnLKNHqyuZU= 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=e4l/lZpWbBPsYOB2pe1mGY+dUcsCvL0laX1Z1LcnDz0uiiE7T7BDozVR4ssPr1FMu6 CAdPexU53osh5ed/0fJxtNuotzAZSemzynL/2JyLXetxUNRT/CBaOzSQJXHc15J/kuyy j8Bsha9lOJAVEqKMndKePW3K7Zgyr4MkF8QVA= MIME-Version: 1.0 Received: by 10.204.24.135 with SMTP id v7mr1052420bkb.99.1298306193486; Mon, 21 Feb 2011 08:36:33 -0800 (PST) Received: by 10.204.14.139 with HTTP; Mon, 21 Feb 2011 08:36:33 -0800 (PST) In-Reply-To: <20110221144527.GB25182@odin.mars.sol> References: <20110221144527.GB25182@odin.mars.sol> Date: Mon, 21 Feb 2011 08:36:33 -0800 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org Content-Type: multipart/alternative; boundary=00032555ae8278f4fd049ccd7795 Cc: Scott Schmit Subject: Re: [keyassure] Interpreting certificates (and summary) 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, 21 Feb 2011 16:35:57 -0000 --00032555ae8278f4fd049ccd7795 Content-Type: text/plain; charset=ISO-8859-1 There is plenty of ambiguity in PKI, but it comes from the complexity of the tasks and the constraints of the implementations. The idea that these issues are going to go away because of a syntax change or a move to DNSSEC is wishful thinking. We had this particular fight fifteen years ago. I was on the other side at the time. The last time there was a serious effort to make a change was in 1999 when VeriSign commissioned me to write an XML based spec for certs that eventually became the foundation for SAML. Having seen implementation of SAML grow to at least the same degree of complexity as PKI, this strikes me as a profoundly pointless exercise. At best it is going to add an option to the spec which Peter has already indicated he has no interest in implementing or maintaining. Since he is the maintainer of the main code base here and this issue is primarily one of code complexity, I think this is rather more his call than that of the group. Adding DNSSEC into the code base is going to be a big enough increase in code complexity as it is. On Mon, Feb 21, 2011 at 6:45 AM, Scott Schmit wrote: > [Partly a summary, partly an attempt to re-focus the conversation.] > > I think we can all appreciate that complexity is the antithesis of > security, and simpler is better. There have been a significant number of > vulnerabilities in ASN.1 and X.509 parsing, and there will probably be > more. And I've also seen expressed (though I can no longer find the > webpage that went through the problems) that X.509 is a disaster because > rules for parsing and certificate generation are so ambiguous or > inconsistent that clients must violate the spec to work in the real > world. Even if the specs have been fixed, there is almost certainly > still stuff out there that hasn't changed. > > So, it's entirely believable that some people decided that this was just > too much trouble and came up with their own solution (e.g., SSH). With > DNSSEC providing a secure place to associate keys with nodes, one could > imagine future protocols (or existing ones) being interested in using > the DNS, and DANE seems like a good mechanism for that. > > And this is is the attraction of bare keys--in DNSSEC, you have a chain > of DS records and DNSKEY records linked to some domain name, all > authenticated using RRSIG records. So clearly, DNSSEC already can do > certificates (in the sense of a binding of a name to a key), we just > need a generic way for applications to use that mechanism. > > While our current focus is TLS/DTLS, general but simple solutions are > usually the better ones, so that's another reason for the call for bare > keys--it seems so much simpler. > > Even if you accept all that (and you may not), TLS/DTLS uses X.509 > certs. Listening to Peter, I have a better appreciation now that > because the TLS protocol has no native way to say "here's my key, check > out of band to see if you trust it", the existing code doesn't provide > the right kind of capabilities or interfaces for the programmer to do > that reliably, as there was no requirement at the time for such a > feature. > > If we want to see DANE adopted in the near future (or at all) in > protocols that already exist (i.e. using TLS), we must respect that a > lot of people aren't going to see the security benefits of DANE being > worth starting from scratch or significantly rewriting existing, working > security libraries (and all the risks that implies). That said, the > error paths of those libraries are going to take more of a beating, now > that CAs with a reputation to protect aren't sanitizing the certificate > fields. > > Even if we reuse pieces of what's there, they're still invasive changes > to ASN.1/X.509 parsing code--the very stuff that has had all those > problems. Also, the non-DANE case isn't going away overnight, so both > cases must still be covered (complicating the logic), and the more > difficult DANE is to adopt, the less overnight it'll be. > > So I would suggest (and I have no hat, it's just a suggestion) that the > question of bare keys be put aside for the moment. To go with PKIX > certificates, we need to deal with the problem that PKIX certificates > have fields that duplicate what DNSSEC is telling the relying party. > And duplication of information means an opportunity for that information > to conflict. > > Looking at some typical certs, here are some sources of conflict I see: > * Subject identification (including alt names) vs domain name [???] > * Validity vs RRSIG period [take the min period] > * Name constraints vs domain name [???] > * CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated] > * CA flag, path length, etc vs the dane-04 cert type [???] > > Other tricky things to resolve: > * How do EV certs fit in? (Whatever rules we come up with to process > subjects can't break the link to EV certs or make it over-permissive) > * Are there any other PKIX fields that clients use and trust, but are > only trustworthy if issued by a third party? > * Are the changes to certificate validation required to made DANE > meaningful just as bad as or worse than adding support for bare keys? > (This won't be evident until we answer the above, which is part of why > I suggest setting aside the bare key question.) > > An item for security considerations: > * Now that CAs aren't necessarily issuing these certs, the client needs > to be much more careful in its parsing (the null terminated vs length- > delimited string bug comes to mind) > > I'm sure there are other issues, too, but that's a start. > > [I hope this helps & fairly represents everyone's positions.] > > -- > Scott Schmit > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --00032555ae8278f4fd049ccd7795 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is plenty of ambiguity in PKI, but it comes from the complexity of th= e tasks and the constraints of the implementations.

The = idea that these issues are going to go away because of a syntax change or a= move to DNSSEC is wishful thinking.


We had this particular fight fifteen yea= rs ago. I was on the other side at the time. The last time there was a seri= ous effort to make a change was in 1999 when VeriSign=A0commissioned=A0me t= o write an XML based spec for certs that eventually became the foundation f= or SAML.=A0

Having seen implementation of SAML grow to at least the= same degree of complexity as PKI, this strikes me as a profoundly pointles= s exercise.

At best it is going to add an option t= o the spec which Peter has already indicated he has no interest in implemen= ting or maintaining. Since he is the maintainer of the main code base here = and this issue is primarily one of code complexity, I think this is rather = more his call than that of the group.

Adding DNSSEC into the code base is going to be a big e= nough increase in code complexity as it is.



On Mon, Feb 21, 2011 at 6:45 AM, Sc= ott Schmit <i.gr= ok@comcast.net> wrote:
[Partly a summary, partly an attempt to re-= focus the conversation.]

I think we can all appreciate that complexity is the antithesis of
security, and simpler is better. There have been a significant number of vulnerabilities in ASN.1 and X.509 parsing, and there will probably be
more. And I've also seen expressed (though I can no longer find the
webpage that went through the problems) that X.509 is a disaster because rules for parsing and certificate generation are so ambiguous or
inconsistent that clients must violate the spec to work in the real
world. Even if the specs have been fixed, there is almost certainly
still stuff out there that hasn't changed.

So, it's entirely believable that some people decided that this was jus= t
too much trouble and came up with their own solution (e.g., SSH). With
DNSSEC providing a secure place to associate keys with nodes, one could
imagine future protocols (or existing ones) being interested in using
the DNS, and DANE seems like a good mechanism for that.

And this is is the attraction of bare keys--in DNSSEC, you have a chain
of DS records and DNSKEY records linked to some domain name, all
authenticated using RRSIG records. So clearly, DNSSEC already can do
certificates (in the sense of a binding of a name to a key), we just
need a generic way for applications to use that mechanism.

While our current focus is TLS/DTLS, general but simple solutions are
usually the better ones, so that's another reason for the call for bare=
keys--it seems so much simpler.

Even if you accept all that (and you may not), TLS/DTLS uses X.509
certs. =A0Listening to Peter, I have a better appreciation now that
because the TLS protocol has no native way to say "here's my key, = check
out of band to see if you trust it", the existing code doesn't pro= vide
the right kind of capabilities or interfaces for the programmer to do
that reliably, as there was no requirement at the time for such a
feature.

If we want to see DANE adopted in the near future (or at all) in
protocols that already exist (i.e. using TLS), we must respect that a
lot of people aren't going to see the security benefits of DANE being worth starting from scratch or significantly rewriting existing, working security libraries (and all the risks that implies). =A0That said, the
error paths of those libraries are going to take more of a beating, now
that CAs with a reputation to protect aren't sanitizing the certificate=
fields.

Even if we reuse pieces of what's there, they're still invasive cha= nges
to ASN.1/X.509 parsing code--the very stuff that has had all those
problems. Also, the non-DANE case isn't going away overnight, so both cases must still be covered (complicating the logic), and the more
difficult DANE is to adopt, the less overnight it'll be.

So I would suggest (and I have no hat, it's just a suggestion) that the=
question of bare keys be put aside for the moment. To go with PKIX
certificates, we need to deal with the problem that PKIX certificates
have fields that duplicate what DNSSEC is telling the relying party.
And duplication of information means an opportunity for that information to conflict.

Looking at some typical certs, here are some sources of conflict I see:
* Subject identification (including alt names) vs domain name [???]
* Validity vs RRSIG period [take the min period]
* Name constraints vs domain name [???]
* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
* CA flag, path length, etc vs the dane-04 cert type [???]

Other tricky things to resolve:
* How do EV certs fit in? (Whatever rules we come up with to process
=A0subjects can't break the link to EV certs or make it over-permissiv= e)
* Are there any other PKIX fields that clients use and trust, but are
=A0only trustworthy if issued by a third party?
* Are the changes to certificate validation required to made DANE
=A0meaningful just as bad as or worse than adding support for bare keys? =A0(This won't be evident until we answer the above, which is part of = why
=A0I suggest setting aside the bare key question.)

An item for security considerations:
* Now that CAs aren't necessarily issuing these certs, the client needs=
=A0to be much more careful in its parsing (the null terminated vs length-<= br> =A0delimited string bug comes to mind)

I'm sure there are other issues, too, but that's a start.

[I hope this helps & fairly represents everyone's positions.]

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



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

--00032555ae8278f4fd049ccd7795-- 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 EBD523A7115 for ; Mon, 21 Feb 2011 07:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_64=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 psvoXcbuvDw5 for ; Mon, 21 Feb 2011 07:28:59 -0800 (PST) Received: from mail-bw0-f42.google.com (mail-bw0-f42.google.com [209.85.214.42]) by core3.amsl.com (Postfix) with ESMTP id 31D613A6DD8 for ; Mon, 21 Feb 2011 07:28:57 -0800 (PST) Received: by bwz13 with SMTP id 13so3820828bwz.15 for ; Mon, 21 Feb 2011 07:29:39 -0800 (PST) Received: by 10.204.114.72 with SMTP id d8mr1473887bkq.68.1298302175332; Mon, 21 Feb 2011 07:29:35 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id f20sm3795021bkf.4.2011.02.21.07.29.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 07:29:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4D619C94.8090702@vpnc.org> Date: Mon, 21 Feb 2011 16:29:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> References: <4D619C94.8090702@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: WebID Incubator Group WG , keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 21 Feb 2011 15:29:01 -0000 (Just a summary of what I understood of this thread, and a few new = ideas) On 20 Feb 2011, at 23:58, Paul Hoffman wrote: > On 2/20/11 2:51 PM, Paul Wouters wrote: >> The whole point is we do not want to identify a cert. We want to = identify a key. >=20 > That's not the case currently, at least for many of us. Given that the = only thing that can be used in TLS to identify the server is a = certificate, most of us want to identify that certificate (or a trust = anchor that the certificate chains to). One needs to go beyond appearances a little here. My argument is that = what identifies a server in TLS is a public key. That this comes in a = certificate is a distraction, which ends up creating a lot of mail on = formats and makes it difficult to concentrate on the key point. I will = put forward the argument why this is so in a semi formal way, and then = look at the pros and cons I noticed that came up on this thread 1. A connection by a client C to a TLS service domain:port enables the = service to prove to C that it has access to the private key privK of the = corresponding public key pubK. 2. After the client C has stepped through the protocol it knows that = the service it is connected to, which it hopes is domain:port knows the = private key of pubK . Call the handle it has on the service _connSrvc, = in order to distinguish it from the real referent of domain:port . So C = knows _connSrvc knowsPrivateKeyOf pubK . [0] But what it wants to know is=20 _connSrvc =3D=3D domain:port . [1] If knowsPrivateKeyOf is an identifying description - which it is - then = what C wants to know is domain:port knowsPrivateKeyOf pubK . [2] =46rom [2] and [0] it can deduce [1]. The advantage of [2] is that it = contains no local variable such as _connSrvc, ie it can be published = globally. 2.1 CAs =20 Currently that is what a certificate signed by a CA does. It = essentially says CAx saysAndSigns "domain:port knowsPrivateKeyOf pubK. " Because C trusts CAx it ends up concluding [2] and then [1] above. 2.2 DNSsec lookup DNSSec lookup works in a similar way, with a twist. The owner of a = DNS domain can define the meaning of terms in his namespace. So he can = say of any services under his domain what properties they have. The = client asking the domain will know, because of the hierarchy of DNSsec = signatures that domainOwner saysAndSigns "domain:port knowsPrivateKeyOf pubK" . This is definitional. The domain owner is the one who is allowed to = specify the meaning of the namespace. He can even specify what the ip = addresses of the domain is. To use those DNS names is to agree to that: = each player is the definer of the meaning of the names under his domain, = which he can the delegate subdomains to other players. Pros and Cons ------------- 1. Verification of possession of private key Writing the above out made me understand Paul Hoffman's point=20 =20 "In specific, certification authorities do many things that are = unimportant to most users but are definitely not done by zone operators. = For example, zone operators probably do not do proof-of-possession = checks for the the private key paired to the public key in the = certificate, whereas most CAs do." http://www.ietf.org/mail-archive/web/keyassure/current/msg01881.html Yes, so when I sent my CA a certificate they asked me to send them a = self signed certificate containing a Domain Name. They then made a DNS = lookup to find the Administrator's e-mail listed there, where they sent = the CA signed certificate with that domain name. As I was the = administrator and the e-mail was correct, I ended up correctly receiving = the cert for which I had the matching private key. In the situation described in 2.2 it would be possible for me to get = the public key from the Amazon.com certificate, and put it into my = bblfish.com DNSsec entry where I would also enter Amazon.com's ip = addresses (if I entered other IP addresses, then connections to port 443 = of bblfish.com would of course fail). So then it may be thought that = people coming to bblfish.com would end up on Amazon.com's site. Their = browser would do the DNSsec verification described in 2.2 and be = satisfied that bblfish.com had been contacted. Their users might thing = bblfish.com was an excellent book store, which oddly enough had = amazon.com written all over it (the issue is less fun if my domain is = amzon.com). =46rom time to time I could change the ip addresses and = point them to my credit card collection server. And that is frightening. BUT! It's not that simple. On connecting the browser supporting the = algorithm 2.2, must simply be required to use the 1.2 TLS server_name = extension which was designed to support virtual hosting. Then the server = will refuse the connection if the domain it is serving does not match = the one requested. Furthermore at present, since the server is sending = a certificate containing the domain name, the client can also verify = what the server wishes to be known as. So possession of private key = verification does not seem to be needed. 2. On difficulty of comparing ECC keys Peter Gutmann made an interesting point that ECC public keys can be = expressed in a number of equivalent ways which are mathematically = difficult to compare for equivalence. http://www.ietf.org/mail-archive/web/keyassure/current/msg01849.html =20 possible answer: I suppose that using the public ECC in the the = proof of the TLS connection would be ok, but that would push the = verification very low.=20 It looks like the Java does equality between X509 key objects based = on their DER encoding. So my guess is that, unless the internal object = encodings are somehow canonicalised, then there could be a problem. The = bouncycastle class has what looks like a mathematically detailed proof = procedure for testing equality = http://www.docjar.com/html/api/org/bouncycastle/jce/provider/JCEECPublicKe= y.java.html If one of them can do it, then it all the rest can do it. ECC is = still new, and I don't know of many applications that use it. For a = programmer using the library in the end it will just be a one method = call=20 pk.equals(pk2). We have not found it difficult to do RSA comparisons. One just needs = to compare a couple of Big Integers. In fact I think it is good for = people to get out of the certificate magic, and learn how public keys = really work. If it is really impossible to do ECC key comparison, then = that's important to know. I would like a few ECC keys that I can prove = somehow are equal and see what these libraries do. =20 3. Size of keys public keys are going to be bigger than signatures, but smaller = than certificates. I am still not sure what the difference is, and have = heard different claims here. Of course we should look at minimal, self = signed certificates and compare those to the public key and to the = signature and work out what the packet size difference is when it's = wrapped into the DNSsec wrapper. I know that the main criticism of the = Dan Bernstein of DNSsec was the size of the packets and how this could = be used for denial of service attacks. See his talk "High-speed = high-security cryptography: encrypting and authenticating the whole = Internet" http://www.youtube.com/watch?v=3Dljt1cxUcZMM . Dan Kaminsky = had a long response to it http://dankaminsky.com/2011/01/05/djb-ccc/ but I still think one should = be careful not to increase the opening here if possible. 4. X509 richness in extensibility =20 Peter Gutmann wrote: = http://www.ietf.org/mail-archive/web/keyassure/current/msg01864.html "Another reason to stick with X.509 as key bags is that eventually = you're going to want to put policy in the DNS ("must connect with TLS", "must use EV certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS algorithms", and so on). Guess what X.509v3 key bags were specifically designed for?" =20 That makes sense, but I am not sure how hypothetical those extensions = are.=20 It is true for example that the SAN extension in X509 would allow a = WebID to be placed there, that would for example allow the service to be = described somewhere on the web in more webby, easier to understand and = to extend manner. That would then furthermore be linkeable, so that one = could develop linked webs of trust much more easily. For example the SAN = of a service could point to a profile https://amazon.com/srv/443 which = could contain in N3/Turtle co:ownedBy = ... And other things describing the service.... Well at least one should = consider that the extensibility need not be placed inside the X509 cert, = making it therefore smaller and the DNSsec less prone to attacks. 5. Complexity of code This is I think the weakest argument against raw public keys. - I showed that it takes 2 lines of code with existing java = libraries to parse an X509 public key = http://www.ietf.org/mail-archive/web/keyassure/current/msg01878.html - Yaron Sheffer and Paul Wouters point to existing protocols that = use public keys = http://www.ietf.org/mail-archive/web/keyassure/current/msg01811.html >=20 > As one of the document editors, if the WG says that it also wants to = have keys as targets, I will also need (a) a rationale for why this is = wanted=20 At present I think a lot depends on the difference in size of the keys = and the load on DNS. Keys can just be more useful than signatures. But = the extensibility of X509 is a point in its favour too. > and (b) text explaining how to make a certificate association between = the key and the certificate that comes from the TLS server. I have asked = a few times for these, with no luck so far. I don't know that the WG can = actually decide to add bare keys without knowing how they will be used. That is perfectly reasonable. But before giving text out it was useful = to understand the problem space. I'll leave it at this for the moment. = This was a very useful conversation, thanks a lot. Henry > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Social Web Architect http://bblfish.net/ 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 A5A853A7119 for ; Mon, 21 Feb 2011 06:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.911 X-Spam-Level: X-Spam-Status: No, score=-101.911 tagged_above=-999 required=5 tests=[AWL=0.688, 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 O4m0eeo-oR3x for ; Mon, 21 Feb 2011 06:44:51 -0800 (PST) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 9392E3A7110 for ; Mon, 21 Feb 2011 06:44:51 -0800 (PST) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Aek01g0021bwxycA8elZbc; Mon, 21 Feb 2011 14:45:33 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta18.emeryville.ca.mail.comcast.net with comcast id AelU1g01e00PQ6U8eelW9p; Mon, 21 Feb 2011 14:45:32 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1LEjSjB030993 for ; Mon, 21 Feb 2011 09:45:28 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1LEjRYT030991 for keyassure@ietf.org; Mon, 21 Feb 2011 09:45:27 -0500 Date: Mon, 21 Feb 2011 09:45:27 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110221144527.GB25182@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [keyassure] Interpreting certificates (and summary) 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, 21 Feb 2011 14:44:52 -0000 [Partly a summary, partly an attempt to re-focus the conversation.] I think we can all appreciate that complexity is the antithesis of security, and simpler is better. There have been a significant number of vulnerabilities in ASN.1 and X.509 parsing, and there will probably be more. And I've also seen expressed (though I can no longer find the webpage that went through the problems) that X.509 is a disaster because rules for parsing and certificate generation are so ambiguous or inconsistent that clients must violate the spec to work in the real world. Even if the specs have been fixed, there is almost certainly still stuff out there that hasn't changed. So, it's entirely believable that some people decided that this was just too much trouble and came up with their own solution (e.g., SSH). With DNSSEC providing a secure place to associate keys with nodes, one could imagine future protocols (or existing ones) being interested in using the DNS, and DANE seems like a good mechanism for that. And this is is the attraction of bare keys--in DNSSEC, you have a chain of DS records and DNSKEY records linked to some domain name, all authenticated using RRSIG records. So clearly, DNSSEC already can do certificates (in the sense of a binding of a name to a key), we just need a generic way for applications to use that mechanism. While our current focus is TLS/DTLS, general but simple solutions are usually the better ones, so that's another reason for the call for bare keys--it seems so much simpler. Even if you accept all that (and you may not), TLS/DTLS uses X.509 certs. Listening to Peter, I have a better appreciation now that because the TLS protocol has no native way to say "here's my key, check out of band to see if you trust it", the existing code doesn't provide the right kind of capabilities or interfaces for the programmer to do that reliably, as there was no requirement at the time for such a feature. If we want to see DANE adopted in the near future (or at all) in protocols that already exist (i.e. using TLS), we must respect that a lot of people aren't going to see the security benefits of DANE being worth starting from scratch or significantly rewriting existing, working security libraries (and all the risks that implies). That said, the error paths of those libraries are going to take more of a beating, now that CAs with a reputation to protect aren't sanitizing the certificate fields. Even if we reuse pieces of what's there, they're still invasive changes to ASN.1/X.509 parsing code--the very stuff that has had all those problems. Also, the non-DANE case isn't going away overnight, so both cases must still be covered (complicating the logic), and the more difficult DANE is to adopt, the less overnight it'll be. So I would suggest (and I have no hat, it's just a suggestion) that the question of bare keys be put aside for the moment. To go with PKIX certificates, we need to deal with the problem that PKIX certificates have fields that duplicate what DNSSEC is telling the relying party. And duplication of information means an opportunity for that information to conflict. Looking at some typical certs, here are some sources of conflict I see: * Subject identification (including alt names) vs domain name [???] * Validity vs RRSIG period [take the min period] * Name constraints vs domain name [???] * CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated] * CA flag, path length, etc vs the dane-04 cert type [???] Other tricky things to resolve: * How do EV certs fit in? (Whatever rules we come up with to process subjects can't break the link to EV certs or make it over-permissive) * Are there any other PKIX fields that clients use and trust, but are only trustworthy if issued by a third party? * Are the changes to certificate validation required to made DANE meaningful just as bad as or worse than adding support for bare keys? (This won't be evident until we answer the above, which is part of why I suggest setting aside the bare key question.) An item for security considerations: * Now that CAs aren't necessarily issuing these certs, the client needs to be much more careful in its parsing (the null terminated vs length- delimited string bug comes to mind) I'm sure there are other issues, too, but that's a start. [I hope this helps & fairly represents everyone's positions.] -- Scott Schmit 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 582BF3A6F2B for ; Mon, 21 Feb 2011 06:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8pDSsogLJ3P for ; Mon, 21 Feb 2011 06:03:42 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id 6C6803A6F00 for ; Mon, 21 Feb 2011 06:03:42 -0800 (PST) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id 2D5D613B919; Mon, 21 Feb 2011 16:04:23 +0200 (EET) Received: from emh07.mail.saunalahti.fi ([62.142.5.117]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A0565026B46; Mon, 21 Feb 2011 16:04:23 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 389891C638C; Mon, 21 Feb 2011 16:04:17 +0200 (EET) Date: Mon, 21 Feb 2011 16:03:54 +0200 From: Ilari Liusvaara To: Lawrence Conroy Message-ID: <20110221140354.GA13829@LK-Perkele-VI.localdomain> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> <63A2DA28-60CC-4256-B33B-03F517EB67A2@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <63A2DA28-60CC-4256-B33B-03F517EB67A2@insensate.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 14:03:43 -0000 On Mon, Feb 21, 2011 at 01:14:20PM +0000, Lawrence Conroy wrote: > On 21 Feb 2011, at 12:55, Stephen Kent wrote: > > Will there ever be more than one DANE record at the owner? > If so, and there are two such records, might one refer to one cert with the other refers to a different cert? > If that happens, might it be useful for a client to be able to scan the records without processing the certs themselves. > [e.g. if the client is interested only in end entity certs] ("Ceritificate" here means certificate in the sense TLS defines it). Yes. Some usecases: - Certificate rollover (to avoid getting into trouble with TTLs)[1]. - Multiple (quad-)A records pointing at different hosts having different keys. - Multiple certificates (hashes, TLS certificate types, etc...)[2] [1] This should do the trick: 1) Insert TLSA record for new certificate 2) Wait at least one positive TTL. 3) Change the certificate webserver sends. 4) Remove the old TLSA record. [2] These certificates can share the key if it is strong enough, because TLS key usage is certificate format independent (key usage is implicit in TLS 1.0/1.1, and implicit with extensions to override defaults in TLS 1.2). -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 2D1063A6F00 for ; Mon, 21 Feb 2011 06:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 bnDHgpll9+Tz for ; Mon, 21 Feb 2011 06:02:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id E0F2E3A70F7 for ; Mon, 21 Feb 2011 06:02:05 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p1LE2kMS026195 for ; Mon, 21 Feb 2011 06:02:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1298296966; bh=qA80hHCW1M67jX96WzzvX7j9Mlc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Ekfe9DShL022mNXTMirpi8kTyVe9L2SG6ApcgAv0m5ABaHL/xU7Le4Zoi0Kj7jFYm /wPrDGJSbNkza4VkP/i4Q== Received: from vxc34 (vxc34.prod.google.com [10.241.33.162]) by kpbe13.cbf.corp.google.com with ESMTP id p1LE2iwJ018946 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 21 Feb 2011 06:02:44 -0800 Received: by vxc34 with SMTP id 34so355670vxc.27 for ; Mon, 21 Feb 2011 06:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GxAWdFmZ0OVaVL18Co09n90GgVh9tIm1Z7NsWwCCqA8=; b=C0ZN8zU8jEDwINlHl9tB+uBDCLg8Avbf0CHTEkwmPS8N9afGvP2/YL2LkB/vU3RAw2 F0DSMcGlSrUaXZT0eekA== 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=BKqBRYXmbSDICkelnqgmkmwgF0Lquefhim3UcNzf8RLZOM+R64fDDEhwchrMb6L5qj lqxEtFKXiU4B0sHoLu4g== MIME-Version: 1.0 Received: by 10.52.160.66 with SMTP id xi2mr1895685vdb.108.1298296963713; Mon, 21 Feb 2011 06:02:43 -0800 (PST) Received: by 10.220.88.137 with HTTP; Mon, 21 Feb 2011 06:02:43 -0800 (PST) In-Reply-To: References: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> <4D617535.9040404@vpnc.org> Date: Mon, 21 Feb 2011 06:02:43 -0800 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Mon, 21 Feb 2011 14:02:07 -0000 On 21 February 2011 04:57, Stephen Kent wrote: > At 12:10 PM -0800 2/20/11, Paul Hoffman wrote: >> >> On 2/19/11 8:21 PM, Scott Schmit wrote: >>> >>> Some of these are nits, some not: >> >> And all are appreciated. >> >>> Abstract: >>> --------- >>> >>>> =A0TLS and DTLS use certificates for authenticating the server. =A0Use= rs >>>> =A0want their applications to verify that the certificate provided by >>>> =A0the TLS server is in fact associated with the domain name they >>>> =A0expect. =A0Instead of trusting a certification authority to have ma= de >>> >>> =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^ >>>> >>>> =A0this association correctly, the user might instead trust the >>> >>> =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>> =A0authoritative DNS server for the domain name to make that >>>> =A0association. =A0This document describes how to use secure DNS to >>>> =A0associate the TLS server's certificate with the the intended domain >>>> =A0name. >>> >>> I would argue that in DNSSEC, each zone operator is a CA, just not a >>> PKIX CA. >> >> I would disagree. It is a trust anchor, not a certification authority. >> Yes, most users today don't understand the difference, but we should sti= ll >> be fairly precise in our language because some do. In specific, >> certification authorities do many things that are unimportant to most us= ers >> but are definitely not done by zone operators. For example, zone operato= rs >> probably do not do proof-of-possession checks for the the private key pa= ired >> to the public key in the certificate, whereas most CAs do. > > I agree that the info in the record could be a TA, and not a CA, but not = if > the format of the data is an X.509 cert. You said a minute ago: "if you issue an X.509 cert under which other certs will be validated, you are a CA." This sounds correct to me. However, mostly what's being done here is _not_ the issuing of X.509 certs under which other certs will be validated (though it is an option), so most times the zone operator is not a CA. In any case it does seem worth making clear when we are talking about a PKIX CA vs. any other kind. > Also, will not performing PoP be a > good outcome? What would be the point of proving to myself that I own a key? 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 1514D3A70EA for ; Mon, 21 Feb 2011 05:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 yplzmiYE8KPt for ; Mon, 21 Feb 2011 05:36:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 565773A6FA3 for ; Mon, 21 Feb 2011 05:36:38 -0800 (PST) Received: by iwl42 with SMTP id 42so3027924iwl.31 for ; Mon, 21 Feb 2011 05:37: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=HpmTK76mJ3jaxY0Ai9L2nuVRLZqeK5I8LCW3VVNJ3ig=; b=TZY6SV2gmV4kn5hg8hN1mnLeTeaTQUCoDEcuc5ZGAYZO7LI/5n6JPICPNgWYccDdpC Oo6AM7xGX2nYiuA0uoJxITbhShvDHsry4JG9jHZfec259zp8KP3XmLt7KbrMZbOfQq+o uWE4USe2e5JmWAlTN3vz1aMNy6WI1biYV0c28= 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=vcKicGb/mrtQuaWnmrPf3MT1eq2X3xxzMXNtRsPF6tG/v0voWwuZ5SivNaAWFwEKZW npxqF3q1zicK9OCeopQIwHz/UObFoJKvP2EtuqMYb4GyM0z9uZLOyX+5vtOlYZ4Ny1/L 39NyZAfQlsnoyMP1alPA39mguZRf4G28mR7v8= MIME-Version: 1.0 Received: by 10.42.227.2 with SMTP id iy2mr1912491icb.405.1298295439607; Mon, 21 Feb 2011 05:37:19 -0800 (PST) Received: by 10.42.211.138 with HTTP; Mon, 21 Feb 2011 05:37:19 -0800 (PST) In-Reply-To: References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> Date: Mon, 21 Feb 2011 05:37:19 -0800 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=20cf30549e937dc975049ccaf6e9 Cc: keyassure@ietf.org, trac@tools.ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 13:36:41 -0000 --20cf30549e937dc975049ccaf6e9 Content-Type: text/plain; charset=ISO-8859-1 There are two sets of issues: 1) To distinguish between different types of X.509v3 cert 2) To distinguish between different types of cert (X.509, SAML, PGP, etc...) The first is covered by the X.509 spec, the second is not. So either the spec has to say that it only allows use of X.509 keys or there has to be a mechanism to allow the client to work out what type of information it is handling. On Sun, Feb 20, 2011 at 12:15 PM, Peter Gutmann wrote: > > To reduce the chance that someone could give a certificate type that > > doesn't match the hash type, change the fields as follows: > > > > o A one-octet value, called "certificate type", specifying the > > provided association that will be used to match the target > > certificate. This will be an IANA registry in order to make it > > easier to add additional certificate types in the future. The > > types defined in this document are: > > > > 1 -- An end-entity certificate > > 2 -- A certification authority's certificate > > What's the thinking behind this? If I'm looking up a cert by a unique key, > the hash value, then anything else is superfluous. How, as an implementer, > am > I supposed to use the certificate type? > > Peter. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --20cf30549e937dc975049ccaf6e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are two sets of issues:

1) To distinguish between = different types of X.509v3 cert

2) To distinguish = between different types of cert (X.509, SAML, PGP, etc...)


The first is covered by the X.509 spec, the secon= d is not. So either the spec has to say that it only allows use of X.509 ke= ys or there has to be a mechanism to allow the client to work out what type= of information it is handling.


On Sun, Feb 20, 2011 at = 12:15 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> To reduce the chance that someone could give a certi= ficate type that
> doesn't match the hash type, change the fields as follows:
>
> o =A0A one-octet value, called "certificate type", specifyin= g the
> =A0 =A0provided association that will be used to match the target
> =A0 =A0certificate. =A0This will be an IANA registry in order to make = it
> =A0 =A0easier to add additional certificate types in the future. =A0Th= e
> =A0 =A0types defined in this document are:
>
> =A0 =A0 =A0 1 -- An end-entity certificate
> =A0 =A0 =A0 2 -- A certification authority's certificate

What's the thinking behind this? =A0If I'm looking up a cert = by a unique key,
the hash value, then anything else is superfluous. =A0How, as an implemente= r, am
I supposed to use the certificate type?

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



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

--20cf30549e937dc975049ccaf6e9-- 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 530B43A70F6 for ; Mon, 21 Feb 2011 05:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 DPLiQr1ktaDU for ; Mon, 21 Feb 2011 05:13:41 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 155213A707F for ; Mon, 21 Feb 2011 05:13:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 59ACC1B7D71; Mon, 21 Feb 2011 13:14:21 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uik5xRB5dBEQ; Mon, 21 Feb 2011 13:14:21 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 088F91B7D66; Mon, 21 Feb 2011 13:14:21 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Mon, 21 Feb 2011 13:14:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <63A2DA28-60CC-4256-B33B-03F517EB67A2@insensate.co.uk> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 13:13:42 -0000 On 21 Feb 2011, at 12:55, Stephen Kent wrote: > At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >> #20: Change the format of the two fields to have fewer certificate = types >>=20 >> To reduce the chance that someone could give a certificate type that >> doesn't match the hash type, change the fields as follows: >>=20 >> o A one-octet value, called "certificate type", specifying the >> provided association that will be used to match the target >> certificate. This will be an IANA registry in order to make it >> easier to add additional certificate types in the future. The >> types defined in this document are: >>=20 >> 1 -- An end-entity certificate >>=20 >> 2 -- A certification authority's certificate >=20 > if we're talking about X.509 certs, this distinction is already = expressed > within the cert itself, via the BasicConstraints extension. Not sure = why one would need to express this cert type in the record as well, when = a cert (vs. hash) is present). Even if a cert hash is the record = content, when the > relying party matches the hash against the cert, the cert will still = say whether it is an E or a CA cert. If we put this info here, it = creates an opportunity > for a mismatch between the two, and a need to describe (and defend) = why > one trumps the other. >=20 > Steve To which I reply, hesitantly: This may be a really stupid comment, but ... Will there ever be more than one DANE record at the owner? If so, and there are two such records, might one refer to one cert with = the other refers to a different cert? If that happens, might it be useful for a client to be able to scan = the records without processing the certs themselves. [e.g. if the client is interested only in end entity certs] With apologies for the lack of clue ... 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 14BF33A6F17 for ; Mon, 21 Feb 2011 05:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 uz+VfjAB5aaK for ; Mon, 21 Feb 2011 05:04:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 41BB43A7105 for ; Mon, 21 Feb 2011 05:04:37 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40171 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrVS2-000Kbe-I1; Mon, 21 Feb 2011 08:05:18 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D617535.9040404@vpnc.org> References: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> <4D617535.9040404@vpnc.org> Date: Mon, 21 Feb 2011 07:57:18 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Mon, 21 Feb 2011 13:04:38 -0000 At 12:10 PM -0800 2/20/11, Paul Hoffman wrote: >On 2/19/11 8:21 PM, Scott Schmit wrote: >>Some of these are nits, some not: > >And all are appreciated. > >>Abstract: >>--------- >> >>> 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. >> >>I would argue that in DNSSEC, each zone operator is a CA, just not a >>PKIX CA. > >I would disagree. It is a trust anchor, not a certification >authority. Yes, most users today don't understand the difference, >but we should still be fairly precise in our language because some >do. In specific, certification authorities do many things that are >unimportant to most users but are definitely not done by zone >operators. For example, zone operators probably do not do >proof-of-possession checks for the the private key paired to the >public key in the certificate, whereas most CAs do. I agree that the info in the record could be a TA, and not a CA, but not if the format of the data is an X.509 cert. Also, will not performing PoP be a good outcome? 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 7F8133A6F17 for ; Mon, 21 Feb 2011 05:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk24Xnfow8M7 for ; Mon, 21 Feb 2011 05:04:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9A96E3A7104 for ; Mon, 21 Feb 2011 05:04:36 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40171 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrVS0-000Kbe-PH; Mon, 21 Feb 2011 08:05:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> References: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> Date: Mon, 21 Feb 2011 07:55:31 -0500 To: "dane issue tracker" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 13:04:37 -0000 At 7:59 PM +0000 2/20/11, dane issue tracker wrote: >#20: Change the format of the two fields to have fewer certificate types > > To reduce the chance that someone could give a certificate type that > doesn't match the hash type, change the fields as follows: > > o A one-octet value, called "certificate type", specifying the > provided association that will be used to match the target > certificate. This will be an IANA registry in order to make it > easier to add additional certificate types in the future. The > types defined in this document are: > > 1 -- An end-entity certificate > > 2 -- A certification authority's certificate if we're talking about X.509 certs, this distinction is already expressed within the cert itself, via the BasicConstraints extension. Not sure why one would need to express this cert type in the record as well, when a cert (vs. hash) is present). Even if a cert hash is the record content, when the relying party matches the hash against the cert, the cert will still say whether it is an E or a CA cert. If we put this info here, it creates an opportunity for a mismatch between the two, and a need to describe (and defend) why one trumps the other. 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 F00DB3A70F8 for ; Mon, 21 Feb 2011 05:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 VGRlpUqJnUSQ for ; Mon, 21 Feb 2011 05:04:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3BCD63A70F6 for ; Mon, 21 Feb 2011 05:04:30 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40171 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrVRv-000Kbe-8m; Mon, 21 Feb 2011 08:05:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110220042133.GB7481@odin.mars.sol> References: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> Date: Mon, 21 Feb 2011 07:48:18 -0500 To: Scott Schmit From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: keyassure@ietf.org Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Mon, 21 Feb 2011 13:04:31 -0000 At 11:21 PM -0500 2/19/11, Scott Schmit wrote: >On Thu, Feb 10, 2011 at 02:45:02PM -0800, Internet-Drafts@ietf.org wrote: >> Title : Using Secure DNS to Associate Certificates >>with Domain Names For TLS >> Author(s) : P. Hoffman, J. Schlyter >> Filename : draft-ietf-dane-protocol-04.txt >> Pages : 11 >> Date : 2011-02-10 > >Some of these are nits, some not: > >Abstract: >--------- > >> 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. > >I would argue that in DNSSEC, each zone operator is a CA, just not a >PKIX CA. If you issue an X.509 cert under which other certs will be validated, you are a CA. 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 05E733A6F9A for ; Sun, 20 Feb 2011 22:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[AWL=0.803, 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 IYLdDC7TJxQC for ; Sun, 20 Feb 2011 22:25:52 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id 6E2C33A6F96 for ; Sun, 20 Feb 2011 22:25:51 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta15.emeryville.ca.mail.comcast.net with comcast id AWPb1g0021ZMdJ4AFWSYu6; Mon, 21 Feb 2011 06:26:32 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta16.emeryville.ca.mail.comcast.net with comcast id AWSW1g00r00PQ6U8cWSXbw; Mon, 21 Feb 2011 06:26:32 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1L6QTU6026977 for ; Mon, 21 Feb 2011 01:26:29 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1L6QTVd026975 for keyassure@ietf.org; Mon, 21 Feb 2011 01:26:29 -0500 Date: Mon, 21 Feb 2011 01:26:29 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110221062629.GA25182@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <4D617A67.40100@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D617A67.40100@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 21 Feb 2011 06:26:02 -0000 On Sun, Feb 20, 2011 at 12:32:39PM -0800, Paul Hoffman wrote keyassure: > On 2/20/11 12:15 PM, Peter Gutmann wrote: > >>To reduce the chance that someone could give a certificate type that > >>doesn't match the hash type, change the fields as follows: > >> > >>o A one-octet value, called "certificate type", specifying the > >> provided association that will be used to match the target > >> certificate. This will be an IANA registry in order to make it > >> easier to add additional certificate types in the future. The > >> types defined in this document are: > >> > >> 1 -- An end-entity certificate > >> 2 -- A certification authority's certificate > > > >What's the thinking behind this? If I'm looking up a cert by a unique key, > >the hash value, then anything else is superfluous. How, as an implementer, am > >I supposed to use the certificate type? > > Unless we mandate one or more hash functions, we cannot assume a > hash value. Once we mandate one or more hash functions, getting them > changed later will cause a gap interoperability. Allowing the full > cert as one of the identity types allows DNS admins who want to > assure maximum interop to be able to identify the certificates, at > the cost of larger DNS responses. I don't think that was the question that Peter was asking. Instead, he was asking how the certificate type is used. dane-04 section 2.3 specifies that for EE certs, the cert/hash is required to match the first cert in the chain. For CA certs, the cert/hash is required to match anything but the first cert in the chain. The draft doesn't explicitly say what use cases these cover, but presumably the purpose of the EE cert case is to simply state what cert the server is expected to use (and allow for the simple case: a self-signed cert). In the CA cert case, the TLSA record asserts what CA cert is expected to validate the EE cert. This can be done to maintain compatibility to non-DANE clients while excluding other CAs from being able to issue false certificates for DANE clients. Alternatively, it can provide trust to an internal CA in a way not unlike the EE cert case. Another question Peter is probably asking is "who cares?" Does the TLSA record really need to say one way or another? The certificate already identifies if it's a CA or EE certificate (or even both, but the chain sent by the TLS server will say how it's being used). So, in the case of a certificate, this is yet another case where the data in the DNS could contradict the data in the certificate (and thus is something for us to describe how to handle). And if your choice of hash algorithm allows an attacker to find a collision and substitute one for another, you shouldn't be using that algorithm anymore. On the other hand, a bare key isn't going to make that assertion by itself (unless you include more pieces of the certificate structure, which slides you toward "just use certificates and save everybody the trouble"), unless the TLSA record says. But the more I think about it, the more I'm not even sure it needs to--if I as an attacker could use the EE-intended key in a CA cert, I don't need to bother (I have the key, just use it!) and vice versa. Is there an attack I'm missing? Another (probably better) use for the cert type field is to distinguish between X.509 certificate in DER encoding, OpenPGP, bare key, etc. I think we want adoption of DANE to be quick and widespread, we must support the first. The others could be added later. To support later growth, we'd still need the field, even though it would only have one assigned value (other than private use). -- Scott Schmit 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 B727C3A6D52 for ; Sun, 20 Feb 2011 18:42:22 -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 P8hhHrq2UiIY for ; Sun, 20 Feb 2011 18:42:21 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 6D3DD3A6F57 for ; Sun, 20 Feb 2011 18:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298256182; x=1329792182; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20paul@xelerance.com|Subject:=20 Re:=20[keyassure]=20publishing=20the=20public=20key|Cc: =20keyassure@ietf.org|In-Reply-To:=20|Message-Id:=20 |Date:=20Mo n,=2021=20Feb=202011=2015:42:52=20+1300; bh=pSTq/tKrMrMhECOCV6JjxOtp7nNiDT0W2yTmEq+t1x4=; b=APyTgf0iZcvM0Xw7vlymg+nOrqLVaXysAW44NM7gm6Tj8O9tcoFN++Pf PDRAP5Q5UVX/PsmU3X1i+oEOvzN/gmayqewB9EYsMwKrt6PKzxzO0C9XQ BI3jCyNil2fWoGovpHY99LKd6ZWEj7/hMUPcxqVvabtOoeqOdborp2Xym c=; X-IronPort-AV: E=Sophos;i="4.62,197,1296990000"; d="scan'208";a="47074700" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Feb 2011 15:42:52 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PrLjg-000811-Hp; Mon, 21 Feb 2011 15:42:52 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PrLjg-00071d-FO; Mon, 21 Feb 2011 15:42:52 +1300 From: Peter Gutmann To: hallam@gmail.com, paul@xelerance.com In-Reply-To: Message-Id: Date: Mon, 21 Feb 2011 15:42:52 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 21 Feb 2011 02:42:22 -0000 Phillip Hallam-Baker writes: >You do not make code simpler by introducing additional code paths. You only >make code simpler if you remove them. The way to make this code base simpler >is to remove the code path that you are proposing. Couldn't have put it better myself. To respond to the OP, instead of guessing what implementers might in theory do if you bothered to ask them, why not actually ask them? As a TLS implementer myself, I have absolutely zero interest in supporting yet another arbitrary key format (and the ensuing increase in complexity and attack surface), particularly one that serves no purpose that I've been able to identify. Peter. 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 79E1A3A6E5B for ; Sun, 20 Feb 2011 15:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 OGLvoxtKQGqy for ; Sun, 20 Feb 2011 15:58:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id EB8B43A6E02 for ; Sun, 20 Feb 2011 15:58:54 -0800 (PST) Received: by iyj8 with SMTP id 8so42050iyj.31 for ; Sun, 20 Feb 2011 15:59:35 -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=uQFeiwIFIDRNaD+VsquKwlZIXmohy8zYu8DmogL8V5c=; b=EZL+NW7oKTTMQClGAnuVOSk8Cm3r5tuBkXNQ9aP8lN5YHhpncRHoWkTWNzKv9pcgq5 TrHpbFoE0EW97vzY0VBOLT7qj4iQsLiMFVhXcJdBOpFN2f0DzO8aEg7BB3P8w+uQ/14F EEiw+yYiC2P4oWoTJV1JwFGMnWlICO9ZWh8pI= 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=vzfSFyN+pvd4pirQwBJ8Pj0qGekqy+7ZR0UyUAwKyTjlDQquXk8v7CEf057D5caOBB uCNBp0+J6IQhR9CUyVeM/ykLbGq6xg+YlRL70FxGlwjgg2Pbmtgy8PCHxYZzvRBiYYtt JSpSNmFHboFeWkzELkynOa9ySVu5cCdQ8JyCU= MIME-Version: 1.0 Received: by 10.42.227.2 with SMTP id iy2mr1078057icb.405.1298246375064; Sun, 20 Feb 2011 15:59:35 -0800 (PST) Received: by 10.42.211.138 with HTTP; Sun, 20 Feb 2011 15:59:35 -0800 (PST) In-Reply-To: References: Date: Sun, 20 Feb 2011 15:59:35 -0800 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=20cf30549e930445f5049cbf8a4c Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 20 Feb 2011 23:58:56 -0000 --20cf30549e930445f5049cbf8a4c Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 20, 2011 at 2:57 PM, Paul Wouters wrote: > On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote: > > The problem with this approach is that it means that we are going to at >> best be exercising new code paths in existing >> code. At worst we are going to force people to write new code. >> >> It is impossible to run TLS without X.509 code in the stack. Everything >> else is superfluous. >> >> This is really bikeshedding. It is not going to simplify implementation by >> an iota and it is going to create yet another >> special case to support. >> >> I don't think the crypto community wants to support yet another key >> format. Even if that format is 'merely' a subset of >> an existing format. >> > > The alternative is shipping a bunch of nonsense fields for eternity. If > you assume that the self signed certs will migrate to DNSSEC validation, > then that would be the vast majority of certificates out there. The > crypto community should not want that either, though I don't claim to > represent them. Just like the useless Edison light bulb screw fitting that has been the standard here for over a century despite better options, the existing standards will continue until there is a paradigm shift that cannot be accommodated in a backwards compatible manner (e.g. halogen bulbs). What is being discussed here is not such a paradigm shift. There are many things in the world that are bad and worth changing. ASN.1 is bad, but it is not one of them. You do not make code simpler by introducing additional code paths. You only make code simpler if you remove them. The way to make this code base simpler is to remove the code path that you are proposing. -- Website: http://hallambaker.com/ --20cf30549e930445f5049cbf8a4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 20, 2011 at 2:57 PM, Paul Wo= uters <paul@xele= rance.com> wrote:
On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote:

The problem with this approach is that it means that we are going to at bes= t be exercising new code paths in existing
code. At worst we are going to force people to write new code.

It is impossible to run TLS without X.509 code in the stack. Everything els= e is superfluous.

This is really bikeshedding. It is not going to simplify implementation by = an iota and it is going to create yet another
special case to support.=A0

I don't think the crypto community wants to support yet another key for= mat. Even if that format is 'merely' a subset of
an existing format.

The alternative is shipping a bunch of nonsense fields for eternity. If
you assume that the self signed certs will migrate to DNSSEC validation, then that would be the vast majority of certificates out there. The
crypto community should not want that either, though I don't claim to represent them.


Just like th= e useless Edison light bulb screw fitting that has been the standard here f= or over a century despite better options, the existing standards will conti= nue until there is a paradigm shift that cannot be accommodated in a backwa= rds compatible manner (e.g. halogen bulbs).

What is being discussed here is not such a paradigm shi= ft.


There are many things in the wo= rld that are bad and worth changing. ASN.1 is bad, but it is not one of the= m.=A0

You do not make code simpler by introducing additional = code paths. You only make code simpler if you remove them. The way to make = this code base simpler is to remove the code path that you are proposing.



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

--20cf30549e930445f5049cbf8a4c-- 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 405BB3A6F1C for ; Sun, 20 Feb 2011 15:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.332 X-Spam-Level: X-Spam-Status: No, score=-101.332 tagged_above=-999 required=5 tests=[AWL=0.714, 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 gLb+upQi6Ryf for ; Sun, 20 Feb 2011 15:31:35 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7ED733A6DDA for ; Sun, 20 Feb 2011 15:31:35 -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 p1KNWEE2024351 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 16:32:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D61A47E.7090603@vpnc.org> Date: Sun, 20 Feb 2011 15:32:14 -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: Paul Wouters References: <4D619C94.8090702@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] publishing the public key 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, 20 Feb 2011 23:31:36 -0000 On 2/20/11 3:16 PM, Paul Wouters wrote: > On Sun, 20 Feb 2011, Paul Hoffman wrote: > >> On 2/20/11 2:51 PM, Paul Wouters wrote: >>> The whole point is we do not want to identify a cert. We want to >>> identify a key. >> >> That's not the case currently, at least for many of us. > > I'm unclear if you mean "currently with CAs" or "currently within the > DANE draft". Neither: I mean "currently with the WG, as far as this discussion has gone". >> Given that the only thing that can be used in TLS to identify the >> server is a certificate, most of us want to identify that certificate >> (or a trust anchor that the certificate chains to). > > You confuse me here too. We have an RRlabel, which replaces the > validated CN= > and the key (blob or hash) that replaces the public key part of the cert. Quite true. But we don't have any text that says that. >> As one of the document editors, if the WG says that it also wants to >> have keys as targets, I will also need (a) a rationale for why this is >> wanted and (b) text explaining how to make a certificate association >> between the key and the certificate that comes from the TLS server. I >> have asked a few times for these, with no luck so far. I don't know >> that the WG can actually decide to add bare keys without knowing how >> they will be used. > > I will get that to you before Prague. Ah! So we will. If someone comes up with text before then, great, but if not, can we put this discussion on hold until we have something concrete to discuss? 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 DC68D3A6D2B for ; Sun, 20 Feb 2011 15:15:31 -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 yyX11qvArTLK for ; Sun, 20 Feb 2011 15:15:31 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 006003A6CFB for ; Sun, 20 Feb 2011 15:15: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 A9B56C59C; Sun, 20 Feb 2011 18:16:10 -0500 (EST) Date: Sun, 20 Feb 2011 18:16:10 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D619C94.8090702@vpnc.org> Message-ID: References: <4D619C94.8090702@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] publishing the public key 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, 20 Feb 2011 23:15:31 -0000 On Sun, 20 Feb 2011, Paul Hoffman wrote: > On 2/20/11 2:51 PM, Paul Wouters wrote: >> The whole point is we do not want to identify a cert. We want to >> identify a key. > > That's not the case currently, at least for many of us. I'm unclear if you mean "currently with CAs" or "currently within the DANE draft". > Given that the only > thing that can be used in TLS to identify the server is a certificate, most > of us want to identify that certificate (or a trust anchor that the > certificate chains to). You confuse me here too. We have an RRlabel, which replaces the validated CN= and the key (blob or hash) that replaces the public key part of the cert. > As one of the document editors, if the WG says that it also wants to have > keys as targets, I will also need (a) a rationale for why this is wanted and > (b) text explaining how to make a certificate association between the key and > the certificate that comes from the TLS server. I have asked a few times for > these, with no luck so far. I don't know that the WG can actually decide to > add bare keys without knowing how they will be used. I will get that to you before Prague. 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 C21C13A6D21 for ; Sun, 20 Feb 2011 14:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.407 X-Spam-Level: X-Spam-Status: No, score=-100.407 tagged_above=-999 required=5 tests=[AWL=-0.220, 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 rLzVle8ilyMm for ; Sun, 20 Feb 2011 14:57:48 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D962D3A6CD6 for ; Sun, 20 Feb 2011 14:57: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 p1KMwSdd023447 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 20 Feb 2011 15:58:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D619C94.8090702@vpnc.org> Date: Sun, 20 Feb 2011 14:58: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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 20 Feb 2011 22:57:49 -0000 On 2/20/11 2:51 PM, Paul Wouters wrote: > The whole point is we do not want to identify a cert. We want to > identify a key. That's not the case currently, at least for many of us. Given that the only thing that can be used in TLS to identify the server is a certificate, most of us want to identify that certificate (or a trust anchor that the certificate chains to). As one of the document editors, if the WG says that it also wants to have keys as targets, I will also need (a) a rationale for why this is wanted and (b) text explaining how to make a certificate association between the key and the certificate that comes from the TLS server. I have asked a few times for these, with no luck so far. I don't know that the WG can actually decide to add bare keys without knowing how they will be used. 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 791923A6DF1 for ; Sun, 20 Feb 2011 14:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xbrQTYEIhG43 for ; Sun, 20 Feb 2011 14:56:21 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id A711D3A6CD6 for ; Sun, 20 Feb 2011 14:56: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 2AE55C59D; Sun, 20 Feb 2011 17:57:01 -0500 (EST) Date: Sun, 20 Feb 2011 17:57:00 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 20 Feb 2011 22:56:23 -0000 On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote: > The problem with this approach is that it means that we are going to at best be exercising new code paths in existing > code. At worst we are going to force people to write new code. > > It is impossible to run TLS without X.509 code in the stack. Everything else is superfluous. > > This is really bikeshedding. It is not going to simplify implementation by an iota and it is going to create yet another > special case to support.  > > I don't think the crypto community wants to support yet another key format. Even if that format is 'merely' a subset of > an existing format. The alternative is shipping a bunch of nonsense fields for eternity. If you assume that the self signed certs will migrate to DNSSEC validation, then that would be the vast majority of certificates out there. The crypto community should not want that either, though I don't claim to represent them. 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 3FBFA3A6D21 for ; Sun, 20 Feb 2011 14:51:10 -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 EEpVmmvTR6bd for ; Sun, 20 Feb 2011 14:51:09 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3CB1C3A6CD6 for ; Sun, 20 Feb 2011 14:51:09 -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 1F786C59D; Sun, 20 Feb 2011 17:51:48 -0500 (EST) Date: Sun, 20 Feb 2011 17:51:46 -0500 (EST) From: Paul Wouters To: Peter Gutmann 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, paul.hoffman@vpnc.org Subject: Re: [keyassure] publishing the public key 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, 20 Feb 2011 22:51:10 -0000 On Sat, 19 Feb 2011, Peter Gutmann wrote: > It's not impossible, but close to it (and for ECC algos it may well be > impossible). This is a really, really bad way to identify a cert. The whole point is we do not want to identify a cert. We want to identify a key. > cert, for which you call memcmp(), thus the "all" in quotes above). For ECC > keys there are so many ways to store the same key (different parameter > encodings, optional parameters, different ways of identifying the same > parameters and in different formats) that in general there's no really > reliable way to compare them. Even with the simplest key type, RSA, it was > hard enough, I've got code that mostly works most of the time and that's way > more complicated than it has to be. But such a method can be standardised in an RFC? And possibly be re-used for other standards - like DNSKEY. > If you want to uniquely identify a certificate, use the SHA-1 hash like > everything else does. Sure. That's one of the options in the TLSA draft right now. 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 153E73A6D2B for ; Sun, 20 Feb 2011 12:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[AWL=0.736, 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 EWJcGtkt9IJ1 for ; Sun, 20 Feb 2011 12:32:06 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E691A3A6C68 for ; Sun, 20 Feb 2011 12:32: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 p1KKWdgw019412 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 13:32:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D617A67.40100@vpnc.org> Date: Sun, 20 Feb 2011 12:32:39 -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: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, trac@tools.ietf.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 20 Feb 2011 20:32:07 -0000 On 2/20/11 12:15 PM, Peter Gutmann wrote: >> To reduce the chance that someone could give a certificate type that >> doesn't match the hash type, change the fields as follows: >> >> o A one-octet value, called "certificate type", specifying the >> provided association that will be used to match the target >> certificate. This will be an IANA registry in order to make it >> easier to add additional certificate types in the future. The >> types defined in this document are: >> >> 1 -- An end-entity certificate >> 2 -- A certification authority's certificate > > What's the thinking behind this? If I'm looking up a cert by a unique key, > the hash value, then anything else is superfluous. How, as an implementer, am > I supposed to use the certificate type? Unless we mandate one or more hash functions, we cannot assume a hash value. Once we mandate one or more hash functions, getting them changed later will cause a gap interoperability. Allowing the full cert as one of the identity types allows DNS admins who want to assure maximum interop to be able to identify the certificates, at the cost of larger DNS responses. 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 3F92A3A6D60 for ; Sun, 20 Feb 2011 12:14:30 -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 I4HAJwm3Hpqa for ; Sun, 20 Feb 2011 12:14:29 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 075813A6CCA for ; Sun, 20 Feb 2011 12:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298232909; x=1329768909; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20paul.hoffman@vpnc.org,=20trac@tools.ietf.org |Subject:=20Re:=20[keyassure]=20[dane]=20protocol=20#20 =20(new):=20Change=20the=20format=20of=20the=20two=20fiel ds=20to=20have=20fewer=20certificate=20types|Cc:=20keyass ure@ietf.org|In-Reply-To:=20<060.5bc0916f7a7af369e6e8f5d5 0dda22c5@tools.ietf.org>|Message-Id:=20|Date:=20Mon,=2021=20Feb=2020 11=2009:15:05=20+1300; bh=BNjYe0Jk9TrTrRrdHlpk6l3aexiH7bpEqZ/L+Y3Jy3o=; b=HgcKQc867VBXuOY0+FFPw+FjyHeTmKwlcY2LMXWJOqojKFIFSHProZdx Ni3PPOjiz0hVbYAoyuv6bg7snDzBZzswUW1z6594p3ToJBHc5OfLMHav1 LVgI/7KwLg4h4EvmDIooUiU5iwC30WNhF4vdwjp3hmrCqukaK5U8OaZ+E k=; X-IronPort-AV: E=Sophos;i="4.62,195,1296990000"; d="scan'208";a="46992541" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Feb 2011 09:15:06 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PrFgP-00007g-J5; Mon, 21 Feb 2011 09:15:05 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PrFgP-0003VK-S2; Mon, 21 Feb 2011 09:15:05 +1300 From: Peter Gutmann To: paul.hoffman@vpnc.org, trac@tools.ietf.org In-Reply-To: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> Message-Id: Date: Mon, 21 Feb 2011 09:15:05 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate 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, 20 Feb 2011 20:14:30 -0000 > To reduce the chance that someone could give a certificate type that > doesn't match the hash type, change the fields as follows: > > o A one-octet value, called "certificate type", specifying the > provided association that will be used to match the target > certificate. This will be an IANA registry in order to make it > easier to add additional certificate types in the future. The > types defined in this document are: > > 1 -- An end-entity certificate > 2 -- A certification authority's certificate What's the thinking behind this? If I'm looking up a cert by a unique key, the hash value, then anything else is superfluous. How, as an implementer, am I supposed to use the certificate type? Peter. 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 AAA043A6CFB for ; Sun, 20 Feb 2011 12:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.295 X-Spam-Level: X-Spam-Status: No, score=-101.295 tagged_above=-999 required=5 tests=[AWL=0.751, 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 6UdprpcRCsxZ for ; Sun, 20 Feb 2011 12:09:51 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6EFBA3A6CCA for ; Sun, 20 Feb 2011 12: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 p1KKATu3018821 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 20 Feb 2011 13:10:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D617535.9040404@vpnc.org> Date: Sun, 20 Feb 2011 12:10:29 -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: <20110210224502.31025.53023.idtracker@localhost> <20110220042133.GB7481@odin.mars.sol> In-Reply-To: <20110220042133.GB7481@odin.mars.sol> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Sun, 20 Feb 2011 20:09:52 -0000 On 2/19/11 8:21 PM, Scott Schmit wrote: > Some of these are nits, some not: And all are appreciated. > Abstract: > --------- > >> 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. > > I would argue that in DNSSEC, each zone operator is a CA, just not a > PKIX CA. I would disagree. It is a trust anchor, not a certification authority. Yes, most users today don't understand the difference, but we should still be fairly precise in our language because some do. In specific, certification authorities do many things that are unimportant to most users but are definitely not done by zone operators. For example, zone operators probably do not do proof-of-possession checks for the the private key paired to the public key in the certificate, whereas most CAs do. > > How does this sound instead? > > 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. DNSSEC provides a mechanism for a zone operator to sign DNS > information directly. This way, bindings of keys to domains are > asserted not by external entities, but by the entities that operate > the DNS. This document describes how to use secure DNS to associate > the TLS server's certificate with the the intended domain name. > > (I used the text from the charter, I figured that's the least > controversial option). That new text seems fine, and does not assert that DNS operators are CAs :-). Having the abstract actually use the words from the charter also seems like a good idea. > Section 2.2: > ------------ > > I'm not the first to mention this, but I think the overlap between the > certificate type and hash type is a bad idea. It allows nonsensical > combinations to be expressed with all the problems that go with it. > > It would make much more sense for the certificate type to only indicate > the kind of certificate that is referenced, and the second field > indicates how that reference is formatted in the RDATA. This would > change the text to something like: > > o A one-octet value, called "certificate type", specifying the > provided association that will be used to match the target > certificate. This will be an IANA registry in order to make it > easier to add additional certificate types in the future. The > types defined in this document are: > > 1 -- An end-entity certificate > > 2 -- A certification authority's certificate > > o A one-octet value, called "reference type", specifying how the > certificate association is presented. This value is defined in a > new IANA registry. The types defined in this document are: > > 0 -- Full certificate in DER encoding > > 1 -- SHA-1 hash of the certificate in DER encoding > > 2 -- SHA-256 hash of the certificate in DER encoding > > 3 -- SHA-384 hash of the certificate in DER encoding > > Using the same hash algorithm as is used in the signature in the > certificate will make it more likely that the TLS client will > understand this TLSA data. > > Unless these are all MUSTs, the document needs to indicate which are > required and which are not. Hrm. I like the addition of the 0 type for reference type; it definitely solves the silly-state problem. Given that this is an on-the-wire change, it needs to be discussed more. I have opened issue #20 for it. > Section 3: > ---------- > > Should "If the application receives zero usable certificate > associations, it processes TLS in the normal fashion." be a MUST? It could be, but it doesn't need to be, because that is already covered in the TLS spec. > The last statement in section three should probably be: > > "If no match between the usable certificate association(s) and the > server's end entity certificate in TLS is found, the TLS client MUST > abort the handshake with an "unknown_ca" error." > > This adds "usable" to make clear the distinction between this and the > "continue as usual" case. Good catch. Fixed. > Also, I changed access_denied to unknown_ca. > According to RFC 5246: > >> unknown_ca >> A valid certificate chain or partial chain was received, but the >> certificate was not accepted because the CA certificate could not >> be located or couldn't be matched with a known, trusted CA. This >> message is always fatal. >> >> access_denied >> A valid certificate was received, but when access control was >> applied, the sender decided not to proceed with negotiation. This >> message is always fatal. > > To me, unknown_ca looks like the correct error -- DANE is about allowing > DNSSEC to redefine what the trusted CAs are. However, unknown_ca requires that a chain or partial chain be received, and one might not have been sent. For access_denied, you don't need a chain. > Section 4.2/4.3: > ---------------- > > Value 255 is unspecified. Is this a typo, or was that intended to be > reserved as experimental? The latter, and yet we forgot to add that to the draft. FWIW, I strongly prefer "private use" to "experimental". Fixed in the next version. > We need to specify which algorithms are required, optional, etc. Yes we do, but people wanted to push that off to later. I think it is still good to delay it until we are sure about the format and so on. I have opened this as issue #21 on the tracker. > I don't think the registry policies are sufficiently restrictive to > prevent using up the available space. At minimum it should require > expert review if not IETF Review. Otherwise, the only limitation on > registration is an independent RFC. There has been a not great track record with "expert review" for registries that have only occasional additions. (Ask Phill about his long-delayed request for a new RRtype...) > Just to demonstrate how quickly the hash type (or whatever it turns > into) could be used up, NIST is currently holding a competition to > decide what algorithm will become SHA-3. They are now on their final > round of competition, and there are no further opportunities for tweaks > to the algorithms. So, all those algorithms are permanent and readily > available. That is an overstatement. NIST has made it clear that it might make changes in whatever algorithm it decides. > So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4 > Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3), > SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and > the existing entries from dane-04, and you have 37 entries--about 1/7th > of the available space. And yet none of the SHA-3 candidates have been proposed as hash algorithms for this protocol (or any IETF protocol that I know of). If the registry starts to fill up, the IETF can decide to tighten the registration rules at that time. There is no need to over-tighten now. > Section 5: > ---------- > > You have two references to just A records and three to A/AAAA records. > That's probably incomplete editing to change them all to the latter. Good catch; done. > Also, I don't understand this paragraph: > >> A DNS administrator who goes rogue and changes both the A and TLSA >> records for a domain name can cause the user to go to an unauthorized >> server that will appear authorized, unless the client performs >> certificate validation and rejects the certificate. That >> administrator could probably get a certificate issued anyway, so this >> is not an additional threat. > > What certificate validation is the client going to do that would detect > this attack? There is none. The Security Considerations section is for all considerations, not just ones that can be easily caught. > The good news about this kind of attack is that it can be detected (by > machine, admittedly) since all the certificates/associations are > published in the DNS (unlike a rogue PKIX CA). *Might* be caught: an attacker can give different answers to different DNS requests. This seems too far down the rathole to want to write about, I think, but others might want it. > Maybe this is a lack of operational experience, but I'm not sure I > understand why adding or changing TLSA information would be less > protected than for A/AAAA records? It isn't: they are identical. > Hope this helps. It does indeed. As we move through the open issues, it will be interesting to see how the WG feels about the new ones. 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 A2FF13A6D60 for ; Sun, 20 Feb 2011 12:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-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 mlXBZyHh0rBz for ; Sun, 20 Feb 2011 12:01:20 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B442F3A6D2B for ; Sun, 20 Feb 2011 12:01:20 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrFTj-0002Ux-GY; Sun, 20 Feb 2011 12:01:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: paul.hoffman@vpnc.org X-Trac-Project: dane Date: Sun, 20 Feb 2011 20:01:59 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/21 Message-ID: <060.7d08a09e8dc701e85028c142516ecaa0@tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: paul.hoffman@vpnc.org, keyassure@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: [keyassure] [dane] protocol #21 (new): Need to specify which crypto algorithms and certificate types are mandatory to implement X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 20:01:21 -0000 #21: Need to specify which crypto algorithms and certificate types are mandatory to implement Currently, the draft is silent on which crypto algorithms and certificate types must be implemented for interoperability. It should be specific before the document is finished. -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: dane 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 784E93A6D2B for ; Sun, 20 Feb 2011 11:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-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 1wa8eE703Mmm for ; Sun, 20 Feb 2011 11:58:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B836C3A6CCA for ; Sun, 20 Feb 2011 11:58:47 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrFRH-0004jo-9S; Sun, 20 Feb 2011 11:59:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: paul.hoffman@vpnc.org X-Trac-Project: dane Date: Sun, 20 Feb 2011 19:59:26 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/20 Message-ID: <060.5bc0916f7a7af369e6e8f5d50dda22c5@tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: paul.hoffman@vpnc.org, keyassure@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 19:58:48 -0000 #20: Change the format of the two fields to have fewer certificate types To reduce the chance that someone could give a certificate type that doesn't match the hash type, change the fields as follows: o A one-octet value, called "certificate type", specifying the provided association that will be used to match the target certificate. This will be an IANA registry in order to make it easier to add additional certificate types in the future. The types defined in this document are: 1 -- An end-entity certificate 2 -- A certification authority's certificate o A one-octet value, called "reference type", specifying how the certificate association is presented. This value is defined in a new IANA registry. The types defined in this document are: 0 -- Full certificate in DER encoding 1 -- SHA-1 hash of the certificate in DER encoding 2 -- SHA-256 hash of the certificate in DER encoding 3 -- SHA-384 hash of the certificate in DER encoding Using the same hash algorithm as is used in the signature in the certificate will make it more likely that the TLS client will understand this TLSA data.  -- -----------------------------------+---------------------------------------- Reporter: paul.hoffman@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: protocol | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: dane 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 161253A6FAB for ; Sun, 20 Feb 2011 05:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 iqAkuLF8vV5d for ; Sun, 20 Feb 2011 05:15:02 -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 3EEBF3A6B62 for ; Sun, 20 Feb 2011 05:15:02 -0800 (PST) Received: by fxm15 with SMTP id 15so1621466fxm.31 for ; Sun, 20 Feb 2011 05:15:40 -0800 (PST) Received: by 10.223.72.6 with SMTP id k6mr469747faj.46.1298207740420; Sun, 20 Feb 2011 05:15:40 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id a6sm925263fak.1.2011.02.20.05.15.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Feb 2011 05:15:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Sun, 20 Feb 2011 14:15:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Cc: WebID Incubator Group WG Subject: Re: [keyassure] publishing the public key 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, 20 Feb 2011 13:15:04 -0000 [[ I am CCing this to the WebID XG Group because it is also relevant = there to ISSUE-39: "Simplify how public keys are expressed" which is discussing something very similar to this issue http://www.w3.org/2005/Incubator/webid/track/issues/39=20 =20 For people on that list the thread here is http://www.ietf.org/mail-archive/web/keyassure/current/msg01874.html ]] =20 On 20 Feb 2011, at 04:01, Peter Gutmann wrote: > Henry Story writes: >=20 >> Is that the same as X509?=20 >=20 > It *is* X.509, just used as a key bag (with optional attributes). A bag with only one key though. Sounds more like a singleton. Just reading RFC5280, I don't see the option of putting more than one = key in there=20 https://datatracker.ietf.org/doc/rfc5280/ (Though I suppose extensions could be designed for that, though to what = purpose?...) Anyway here is how we Dane define the public key. Exactly as in rfc5280 SubjectPublicKeyInfo ::=3D SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } Then one just does as they do and point people to more rfcs [[ 4.1.2.7. Subject Public Key Info This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in Section 4.1.1.2. The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [RFC3279], [RFC4055], and [RFC4491]. ]] >=20 >> The code to select the subset is going to be at most a few lines. >=20 > How do you get from CertCreateContext() to = turn-this-encoded-blob-into-a- > public-key-context? Hey, that's a clever way to get free programming time from people: Taunt = them that they can't do something :-) And you get the added pleasure of = forcing me to learn ASN.1, which I have been trying to avoid...=20 Note how decoding the key is three lines of code. So here it goes in Scala (requires Sun JVM). // // create an RSA Key // import java.security.spec._ import java.math.BigInteger val keySpec =3D new RSAPublicKeySpec(new = BigInteger("""E394D1B3CE644D809D8A85B6816E22F6C7741B9A294D2E4CB477733C16FE= C0C9B346B26078944148114234393CF634A742947E264D1D22A55CF6B5E98ADACD897B9896= FCDE5836008BBBC8463057F67848F5A31B41B032E4765CD546A1DD7DE3FC2423C88EAC7233= 2AC9174E0BCA4E9FE973D90C3C622617C0CEA69B45C01CFBA90F247C26E1BCE419A251BC46= 287F7B00EDC34B538066CC2A285BB99B423012942768D619D261C1B668EC847E56CCF621D8= B15E860FC2109317A8261F7AF894F0490703AFF323E88EAD45C4F6B8B34684D81575BF2A78= AC842FD12AAE5D8EE52C9858087BE3EB8C8C7A0CA9C7ED05EBF411145E20D654A70118D586= C25332A9""",16), new BigInteger("65537")) import java.security.KeyFactory; import java.security.interfaces._ val keyFactory =3D KeyFactory.getInstance("RSA") val rsaKey =3D = keyFactory.generatePublic(keySpec).asInstanceOf[RSAPublicKey] // // Base64 encode it, ready for publication=20 // import sun.misc.BASE64Encoder new BASE64Encoder().encode( rsaKey.getEncoded ) // In pastebin ( http://pastebin.com/TEpMBJK5 ) // you will see this returns // // = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA45TRs85kTYCdioW2gW4i9sd0G5opTS= 5M // = tHdzPBb+wMmzRrJgeJRBSBFCNDk89jSnQpR+Jk0dIqVc9rXpitrNiXuYlvzeWDYAi7vIRjBX9n= hI // = 9aMbQbAy5HZc1Uah3X3j/CQjyI6scjMqyRdOC8pOn+lz2Qw8YiYXwM6mm0XAHPupDyR8JuG85B= mi // = UbxGKH97AO3DS1OAZswqKFu5m0IwEpQnaNYZ0mHBtmjshH5WzPYh2LFehg/CEJMXqCYfeviU8E= kH // = A6/zI+iOrUXE9rizRoTYFXW/KnishC/RKq5djuUsmFgIe+PrjIx6DKnH7QXr9BEUXiDWVKcBGN= WG // wlMyqQIDAQAB // // // Decode the key, which could have been found in DNSsec // import sun.security.util.DerValue val der =3D new DerValue( rsaKey.getEncoded ) val newKey =3D X509Key.parse(der) The output from the scala shell is shown in=20 http://pastebin.com/TEpMBJK5 >=20 >> Currently we are not asking to remove the other options. Just to see = if this >> option is possible, and to work out what the advantages and = disadvantages >> would be. >=20 > Well I'm OK with that, as long as it's made optional so implementers = can > ignore it at their leisure. Putting it in a seperate RFC would make = this even > easier. Now I think that the argument that this is so difficult has been shown = to be wrong, I think we can perhaps push the discussion further on this. = The reasons for or against this here won't be the same as on the WebID = XG, but it should be instructive none the less. >=20 > Peter. Social Web Architect http://bblfish.net/ 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 DA7D63A70A3 for ; Sat, 19 Feb 2011 21:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.602, 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 rCNriL97OV+t for ; Sat, 19 Feb 2011 21:34:34 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id D66BC3A70A1 for ; Sat, 19 Feb 2011 21:34:33 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta14.westchester.pa.mail.comcast.net with comcast id A5aq1g0020QuhwU5E5bCQz; Sun, 20 Feb 2011 05:35:12 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta02.westchester.pa.mail.comcast.net with comcast id A5bC1g00H00PQ6U3N5bCji; Sun, 20 Feb 2011 05:35:12 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1K5ZAPp012031 for ; Sun, 20 Feb 2011 00:35:10 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1K5ZAaI012029 for keyassure@ietf.org; Sun, 20 Feb 2011 00:35:10 -0500 Date: Sun, 20 Feb 2011 00:35:10 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110220053510.GC7481@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <4D54E4A9.1020104@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] dane-04 trust anchors 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, 20 Feb 2011 05:34:36 -0000 On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote: > On Fri, 11 Feb 2011, Yaron Sheffer wrote: > >The client MUST obey any constraints included in the trust anchor, > >including but not limited to: > >- Validity period. > > What to do if that period does not match the DNS TTL/RRSIG period? The DNS TTL should be used to determine when the client MUST forget the certificate association and refetch the TLSA record if it needs it again. I think that's the DANE equivalent to revocation (if the TLSA record is replaced, the old cert was revoked). The RRSIG period serves a similar role to the Validity period in X.509, though it'll be much shorter than we're used to for PKIX. I would think that the most restrictive value wins. The notAfter field can always be set to be never to avoid needing to regenerate the certificate. You could probably argue that what I'm saying to use the TTL for is what the RRSIG period is for, but in my experience with DNSSEC tools, it's a lot more obvious to me how I'd control (without affecting the period for other records) the rate a client rechecks the certificate validity via the TTL. -- Scott Schmit 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 E29CD3A70A1 for ; Sat, 19 Feb 2011 21:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 B5bo0inl6Epq for ; Sat, 19 Feb 2011 21:22:05 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 823F63A709E for ; Sat, 19 Feb 2011 21:22:04 -0800 (PST) X-CheckPoint: {4D60A521-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1K5MbF5019009; Sun, 20 Feb 2011 07:22:37 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Sun, 20 Feb 2011 07:22:37 +0200 From: Yoav Nir To: Scott Schmit Date: Sun, 20 Feb 2011 07:22:37 +0200 Thread-Topic: [keyassure] The SSL Proxy Issue Thread-Index: AcvQvi9NPFTUEdizTQqJ12nEmpQ/dg== Message-ID: References: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> <4D6029E8.9020203@vpnc.org> <20110219214226.GC23898@odin.mars.sol> In-Reply-To: <20110219214226.GC23898@odin.mars.sol> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] The SSL Proxy Issue 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, 20 Feb 2011 05:22:06 -0000 On Feb 19, 2011, at 11:42 PM, Scott Schmit wrote: > On Sat, Feb 19, 2011 at 12:36:56PM -0800, Paul Hoffman wrote keyassure: >> On 2/19/11 10:49 AM, Steingruebl, Andy wrote: >>>> -----Original Message----- >>>> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] O= n >>>> Behalf Of Paul Hoffman >>>>=20 >>>> Regardless of the number of use cases, why is it an issue for TLSA? >>>> Given that they are meant to be invisible to the users, isn't that inv= isibility the >>>> same with or without TLSA? >>>=20 >>> In the current CA/Browser (other code also) model there is not exclusio= n for trust-anchors. Any trust anchor can make claims for any name. With = the advent of DANE/TLSA records, the situation changes. Please see the oth= er mail I just sent... >>=20 >> I'm not understanding you. TLSA is not looking to replace the >> current trust anchors by removing them from the browser unless the >> user (or, in the case in question, the user's administrator) wants >> to remove them. With an SSL proxy, the user has a universal trust >> anchor added to their browser, and TLSA doesn't affect that at all, >> if I understand the issue you are raising. >=20 > TLSA very much affects that -- reread section 3 of the DANE protocol > draft. A straightforward implementation of DANE will result in the > client looking up example.com, getting back a TLSA record saying that > the it should be expecting a particular cert, which is then checked > against the cert it gets back when connecting via TLS. >=20 > Except that with the proxy in the way, the client will receive the > proxy-manufactured cert. Since the two don't match, the connection > fails. It doesn't matter if the proxy is a TA in the client, because > DANE overrides that. >=20 > In the general case, this is by design and desirable. In the specific > case of managed environments, there are ways around it: >=20 > The SSL proxy (or another supporting device) could also proxy DNS by > stripping out all DNSSEC from responses (and configuring the hosts to > disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it > (and that the internal network/proxy is secure). This disables DANE on > the internal network (though the proxy could use DANE when talking > externally). I'm not sure that would work. DNS clients tend to cache a lot. So if I acce= ss mail.google.com a lot, my browser will have a cache of all the DNS respo= nses, including the DANE response. By the time I try to access gmail from m= y workplace, I'm not making and DNS queries. Instead, I just begin a TLS ha= ndshake, and get the wrong certificate.=20 Until now, browser makers did not accommodate the SSL proxies in anyway. It= was up to the SSL proxies to work around the browsers. I don't think Micro= soft, Mozilla, Google and Opera will suddenly have the motivation to play a= long with what is essentially a man-in-the-middle attack. 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 455EE3A7090 for ; Sat, 19 Feb 2011 20:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[AWL=0.803, 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 XovQv6Rz3ega for ; Sat, 19 Feb 2011 20:20:59 -0800 (PST) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id D75423A6D9C for ; Sat, 19 Feb 2011 20:20:59 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta10.emeryville.ca.mail.comcast.net with comcast id A4Mc1g0011smiN4AA4MdP9; Sun, 20 Feb 2011 04:21:37 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta20.emeryville.ca.mail.comcast.net with comcast id A4Mc1g00400PQ6U8g4Mcde; Sun, 20 Feb 2011 04:21:37 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1K4LZXw011480 for ; Sat, 19 Feb 2011 23:21:35 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1K4LXlw011478 for keyassure@ietf.org; Sat, 19 Feb 2011 23:21:33 -0500 Date: Sat, 19 Feb 2011 23:21:33 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110220042133.GB7481@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <20110210224502.31025.53023.idtracker@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110210224502.31025.53023.idtracker@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Sun, 20 Feb 2011 04:21:01 -0000 On Thu, Feb 10, 2011 at 02:45:02PM -0800, Internet-Drafts@ietf.org wrote: > Title : Using Secure DNS to Associate Certificates with Domain Names For TLS > Author(s) : P. Hoffman, J. Schlyter > Filename : draft-ietf-dane-protocol-04.txt > Pages : 11 > Date : 2011-02-10 Some of these are nits, some not: Abstract: --------- > 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. I would argue that in DNSSEC, each zone operator is a CA, just not a PKIX CA. How does this sound instead? 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. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the the intended domain name. (I used the text from the charter, I figured that's the least controversial option). Section 2.2: ------------ I'm not the first to mention this, but I think the overlap between the certificate type and hash type is a bad idea. It allows nonsensical combinations to be expressed with all the problems that go with it. It would make much more sense for the certificate type to only indicate the kind of certificate that is referenced, and the second field indicates how that reference is formatted in the RDATA. This would change the text to something like: o A one-octet value, called "certificate type", specifying the provided association that will be used to match the target certificate. This will be an IANA registry in order to make it easier to add additional certificate types in the future. The types defined in this document are: 1 -- An end-entity certificate 2 -- A certification authority's certificate o A one-octet value, called "reference type", specifying how the certificate association is presented. This value is defined in a new IANA registry. The types defined in this document are: 0 -- Full certificate in DER encoding 1 -- SHA-1 hash of the certificate in DER encoding 2 -- SHA-256 hash of the certificate in DER encoding 3 -- SHA-384 hash of the certificate in DER encoding Using the same hash algorithm as is used in the signature in the certificate will make it more likely that the TLS client will understand this TLSA data. Unless these are all MUSTs, the document needs to indicate which are required and which are not. Section 3: ---------- Should "If the application receives zero usable certificate associations, it processes TLS in the normal fashion." be a MUST? The last statement in section three should probably be: "If no match between the usable certificate association(s) and the server's end entity certificate in TLS is found, the TLS client MUST abort the handshake with an "unknown_ca" error." This adds "usable" to make clear the distinction between this and the "continue as usual" case. Also, I changed access_denied to unknown_ca. According to RFC 5246: > unknown_ca > A valid certificate chain or partial chain was received, but the > certificate was not accepted because the CA certificate could not > be located or couldn't be matched with a known, trusted CA. This > message is always fatal. > > access_denied > A valid certificate was received, but when access control was > applied, the sender decided not to proceed with negotiation. This > message is always fatal. To me, unknown_ca looks like the correct error -- DANE is about allowing DNSSEC to redefine what the trusted CAs are. Section 4.2/4.3: ---------------- Value 255 is unspecified. Is this a typo, or was that intended to be reserved as experimental? We need to specify which algorithms are required, optional, etc. I don't think the registry policies are sufficiently restrictive to prevent using up the available space. At minimum it should require expert review if not IETF Review. Otherwise, the only limitation on registration is an independent RFC. Just to demonstrate how quickly the hash type (or whatever it turns into) could be used up, NIST is currently holding a competition to decide what algorithm will become SHA-3. They are now on their final round of competition, and there are no further opportunities for tweaks to the algorithms. So, all those algorithms are permanent and readily available. So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4 Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3), SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and the existing entries from dane-04, and you have 37 entries--about 1/7th of the available space. Section 5: ---------- You have two references to just A records and three to A/AAAA records. That's probably incomplete editing to change them all to the latter. Also, I don't understand this paragraph: > A DNS administrator who goes rogue and changes both the A and TLSA > records for a domain name can cause the user to go to an unauthorized > server that will appear authorized, unless the client performs > certificate validation and rejects the certificate. That > administrator could probably get a certificate issued anyway, so this > is not an additional threat. What certificate validation is the client going to do that would detect this attack? The good news about this kind of attack is that it can be detected (by machine, admittedly) since all the certificates/associations are published in the DNS (unlike a rogue PKIX CA). Maybe this is a lack of operational experience, but I'm not sure I understand why adding or changing TLSA information would be less protected than for A/AAAA records? Hope this helps. -- Scott Schmit 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 888913A6CBA for ; Sat, 19 Feb 2011 19:01:19 -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 ahbFFu7TaMgn for ; Sat, 19 Feb 2011 19:01:18 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 123213A6D85 for ; Sat, 19 Feb 2011 19:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298170916; x=1329706916; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20henry.story@bblfish.net,=20pgut001@cs.auckland.ac. nz|Subject:=20Re:=20[keyassure]=20publishing=20the=20publ ic=20key|Cc:=20keyassure@ietf.org|In-Reply-To:=20|Message-Id:=20 |Date:=20Su n,=2020=20Feb=202011=2016:01:53=20+1300; bh=dBUbUsTCeLKBA+T89xB9BSm1UWwkhOgS53cC7vN52Qo=; b=YeNKh7TYY7pcafM+SdGB9O8PsJq+8UL86tt5QdfU8n46Vn/3T0s7HfI+ kZxXCVLmmZ0qMiKAr8OVcZ03z9VcDgzBwSGNRI+2oaME5vAvMa+2ZQqbz EYCBCj0xd8pH2j87qLsBygIgQDOqVzqzzsnWNX8DziE8IWPqSIVp196pO 8=; X-IronPort-AV: E=Sophos;i="4.62,193,1296990000"; d="scan'208";a="46943825" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Feb 2011 16:01:53 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqzYX-0004ci-Gf; Sun, 20 Feb 2011 16:01:53 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqzYX-0001rl-3u; Sun, 20 Feb 2011 16:01:53 +1300 From: Peter Gutmann To: henry.story@bblfish.net, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Sun, 20 Feb 2011 16:01:53 +1300 Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 20 Feb 2011 03:01:19 -0000 Henry Story writes: >Is that the same as X509? It *is* X.509, just used as a key bag (with optional attributes). >The code to select the subset is going to be at most a few lines. How do you get from CertCreateContext() to turn-this-encoded-blob-into-a- public-key-context? >Currently we are not asking to remove the other options. Just to see if this >option is possible, and to work out what the advantages and disadvantages >would be. Well I'm OK with that, as long as it's made optional so implementers can ignore it at their leisure. Putting it in a seperate RFC would make this even easier. Peter. 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 29DC53A7051 for ; Sat, 19 Feb 2011 17:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.551 X-Spam-Level: X-Spam-Status: No, score=-100.551 tagged_above=-999 required=5 tests=[AWL=0.006, 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 ZgIYzhTTf6aF for ; Sat, 19 Feb 2011 17:15:27 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8221B3A6A6E for ; Sat, 19 Feb 2011 17:15: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 p1K1G4da049799 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 19 Feb 2011 18:16:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D606B54.1020402@vpnc.org> Date: Sat, 19 Feb 2011 17:16: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: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> <4D6029E8.9020203@vpnc.org> <20110219214226.GC23898@odin.mars.sol> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] The SSL Proxy Issue 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, 20 Feb 2011 01:15:28 -0000 On 2/19/11 4:59 PM, Phillip Hallam-Baker wrote: > It really depends on the browser providers. If they consider this to be > an essential market requirement then it is going to be supported and I > would prefer for support to be made explicit rather than be something > buried in the small print. If they don't consider it to be a market > requirement it is merely something to note in the security considerations. For now, we'll put it in the Security Considerations. If the WG wants to do something more, we'll need an open issue with one or more proposals for how to do it technically. 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 E9E7B3A7038 for ; Sat, 19 Feb 2011 16:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065, 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 nETJX+QHGiws for ; Sat, 19 Feb 2011 16:59:22 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 956F73A6AB9 for ; Sat, 19 Feb 2011 16:59:22 -0800 (PST) Received: by iwl42 with SMTP id 42so1724151iwl.31 for ; Sat, 19 Feb 2011 17:00: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=gwETjkWXhIQchBwNN7G/7oZsNyw9UqFaKHyjl6P8aY4=; b=X/r9QeUVZyh0DnPeyeJXIBgjBSTIMPV+GISAOE5UsJPJRgzd+4oYjn4DCLcoUs75zf SyN2KThlh/icPcL8SrGpRKxvG7js87U3H9L0eLUWR38RTTt8hKrj58L3a8t45ztpJN7c BmcHUqzwJJBfMSANCqIqppK4BlIlEAOF1EiSs= 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=Lky/FfioHaGV0xUxx4EWGRrZeKbv0upYsuLL7AH3EVwzUFfknQAq6Hkb5a0nu7rJ0C qqS9JwP5tmTi6nwD67ze6twsY9Wl2T/9EioIeMfgPift6rTzWzGiGTetKDHVlPQ2qID2 aLO1mHGYmkVCjCMO9D6XnSXuifBjUdOQLm49U= MIME-Version: 1.0 Received: by 10.42.213.138 with SMTP id gw10mr3042920icb.35.1298163599969; Sat, 19 Feb 2011 16:59:59 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 16:59:59 -0800 (PST) In-Reply-To: <20110219214226.GC23898@odin.mars.sol> References: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> <4D6029E8.9020203@vpnc.org> <20110219214226.GC23898@odin.mars.sol> Date: Sat, 19 Feb 2011 16:59:59 -0800 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org Content-Type: multipart/alternative; boundary=20cf303349393c8f8a049cac440a Subject: Re: [keyassure] The SSL Proxy Issue 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, 20 Feb 2011 00:59:24 -0000 --20cf303349393c8f8a049cac440a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 19, 2011 at 1:42 PM, Scott Schmit wrote: > > Or Phillip's idea, that the client plays along and makes an exception to > the DANE processing rules for the proxy. Of course, if you're going to > do that, it might just be simpler to turn DANE support off in the client > altogether, since you aren't actually using it. Though perhaps with > laptops where the proxy isn't always in the way, it could be useful. > Anyway, this exception would be a violation of the protocol unless we > codified it (as the draft is currently written). To be precise, it was one option. The other was to decide that this is not going to be supported. It really depends on the browser providers. If they consider this to be an essential market requirement then it is going to be supported and I would prefer for support to be made explicit rather than be something buried in the small print. If they don't consider it to be a market requirement it is merely something to note in the security considerations. -- Website: http://hallambaker.com/ --20cf303349393c8f8a049cac440a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 19, 2011 at 1:42 PM, Scott S= chmit <i.grok@co= mcast.net> wrote:

Or Phillip's idea, that the client plays along and makes an exception t= o
the DANE processing rules for the proxy. Of course, if you're going to<= br> do that, it might just be simpler to turn DANE support off in the client altogether, since you aren't actually using it. Though perhaps with
laptops where the proxy isn't always in the way, it could be useful. Anyway, this exception would be a violation of the protocol unless we
codified it (as the draft is currently written).

To be precise, it was one option.

The other = was to decide that this is not going to be supported.


It really depends on the browser providers. If they con= sider this to be an essential market requirement then it is going to be sup= ported and I would prefer for support to be made explicit rather than be so= mething buried in the small print. If they don't consider it to be a ma= rket requirement it is merely something to note in the security considerati= ons.
=A0

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

--20cf303349393c8f8a049cac440a-- 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 A8D7F3A6F7F for ; Sat, 19 Feb 2011 15:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.28 X-Spam-Level: X-Spam-Status: No, score=-101.28 tagged_above=-999 required=5 tests=[AWL=0.766, 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 S6+w5DMvQHZ0 for ; Sat, 19 Feb 2011 15:51:01 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2A45A3A6CC3 for ; Sat, 19 Feb 2011 15:50: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 p1JNpZNR047448 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 19 Feb 2011 16:51:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D605787.8090705@vpnc.org> Date: Sat, 19 Feb 2011 15:51: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: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> <4D6029E8.9020203@vpnc.org> <20110219214226.GC23898@odin.mars.sol> In-Reply-To: <20110219214226.GC23898@odin.mars.sol> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 23:51:02 -0000 On 2/19/11 1:42 PM, Scott Schmit wrote: > TLSA very much affects that -- reread section 3 of the DANE protocol > draft. A straightforward implementation of DANE will result in the > client looking up example.com, getting back a TLSA record saying that > the it should be expecting a particular cert, which is then checked > against the cert it gets back when connecting via TLS. > > Except that with the proxy in the way, the client will receive the > proxy-manufactured cert. Since the two don't match, the connection > fails. It doesn't matter if the proxy is a TA in the client, because > DANE overrides that. Thank you, that explains what I was missing. I was assuming that someone behind a proxy would be configured not to issue DANE requests for the very reason you give, but now I see that this is possibly not under the control of the admin who shoves in the universal trust anchor that is used by the proxy. > In the general case, this is by design and desirable. In the specific > case of managed environments, there are ways around it: > > The SSL proxy (or another supporting device) could also proxy DNS by > stripping out all DNSSEC from responses (and configuring the hosts to > disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it > (and that the internal network/proxy is secure). This disables DANE on > the internal network (though the proxy could use DANE when talking > externally). > > The SSL proxy could also proxy DNSSEC by re-signing all responses with a > single DNSKEY (and configuring the hosts to use the proxy's key as the > root TA). Exactly right. Both have the same (ugly) properties of the current proxy. > Or Phillip's idea, that the client plays along and makes an exception to > the DANE processing rules for the proxy. Of course, if you're going to > do that, it might just be simpler to turn DANE support off in the client > altogether, since you aren't actually using it. Though perhaps with > laptops where the proxy isn't always in the way, it could be useful. > Anyway, this exception would be a violation of the protocol unless we > codified it (as the draft is currently written). And I will now agree with the others who have said that we don't want to put in exceptions like this. It's similar to putting exceptions in PKIX that say "or you just might shove in your own TA": there is no good reason to say that. 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 8FE4A3A6CD6 for ; Sat, 19 Feb 2011 13:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.394 X-Spam-Level: X-Spam-Status: No, score=-101.394 tagged_above=-999 required=5 tests=[AWL=1.205, 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 bqAGrde51B2H for ; Sat, 19 Feb 2011 13:41:52 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 0B4713A6C9C for ; Sat, 19 Feb 2011 13:41:52 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 9xdY1g0021afHeLA4xiVP1; Sat, 19 Feb 2011 21:42:29 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta17.emeryville.ca.mail.comcast.net with comcast id 9xiT1g00b00PQ6U8dxiU78; Sat, 19 Feb 2011 21:42:29 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1JLgQaH006978 for ; Sat, 19 Feb 2011 16:42:26 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1JLgQMO006976 for keyassure@ietf.org; Sat, 19 Feb 2011 16:42:26 -0500 Date: Sat, 19 Feb 2011 16:42:26 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110219214226.GC23898@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> <4D6029E8.9020203@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6029E8.9020203@vpnc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 21:41:53 -0000 On Sat, Feb 19, 2011 at 12:36:56PM -0800, Paul Hoffman wrote keyassure: > On 2/19/11 10:49 AM, Steingruebl, Andy wrote: > >>-----Original Message----- > >>From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > >>Behalf Of Paul Hoffman > >> > >>Regardless of the number of use cases, why is it an issue for TLSA? > >>Given that they are meant to be invisible to the users, isn't that invisibility the > >>same with or without TLSA? > > > >In the current CA/Browser (other code also) model there is not exclusion for trust-anchors. Any trust anchor can make claims for any name. With the advent of DANE/TLSA records, the situation changes. Please see the other mail I just sent... > > I'm not understanding you. TLSA is not looking to replace the > current trust anchors by removing them from the browser unless the > user (or, in the case in question, the user's administrator) wants > to remove them. With an SSL proxy, the user has a universal trust > anchor added to their browser, and TLSA doesn't affect that at all, > if I understand the issue you are raising. TLSA very much affects that -- reread section 3 of the DANE protocol draft. A straightforward implementation of DANE will result in the client looking up example.com, getting back a TLSA record saying that the it should be expecting a particular cert, which is then checked against the cert it gets back when connecting via TLS. Except that with the proxy in the way, the client will receive the proxy-manufactured cert. Since the two don't match, the connection fails. It doesn't matter if the proxy is a TA in the client, because DANE overrides that. In the general case, this is by design and desirable. In the specific case of managed environments, there are ways around it: The SSL proxy (or another supporting device) could also proxy DNS by stripping out all DNSSEC from responses (and configuring the hosts to disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it (and that the internal network/proxy is secure). This disables DANE on the internal network (though the proxy could use DANE when talking externally). The SSL proxy could also proxy DNSSEC by re-signing all responses with a single DNSKEY (and configuring the hosts to use the proxy's key as the root TA). Or Phillip's idea, that the client plays along and makes an exception to the DANE processing rules for the proxy. Of course, if you're going to do that, it might just be simpler to turn DANE support off in the client altogether, since you aren't actually using it. Though perhaps with laptops where the proxy isn't always in the way, it could be useful. Anyway, this exception would be a violation of the protocol unless we codified it (as the draft is currently written). 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 28F753A6DC0 for ; Sat, 19 Feb 2011 13:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 iwCpLE2YJACV for ; Sat, 19 Feb 2011 13:38:55 -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 36EAF3A6D24 for ; Sat, 19 Feb 2011 13:38:55 -0800 (PST) Received: by fxm15 with SMTP id 15so1288263fxm.31 for ; Sat, 19 Feb 2011 13:39:31 -0800 (PST) Received: by 10.223.83.199 with SMTP id g7mr2151360fal.97.1298151571500; Sat, 19 Feb 2011 13:39:31 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id j12sm1721977fax.33.2011.02.19.13.39.28 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Feb 2011 13:39:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-56--130696425 From: Henry Story In-Reply-To: Date: Sat, 19 Feb 2011 22:39:26 +0100 Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 21:38:57 -0000 --Apple-Mail-56--130696425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Feb 2011, at 21:34, Phillip Hallam-Baker wrote: > I agree with Peter here. >=20 > Folk who are bike-shedding this one need to understand that he is the = person they need to persuade to write the code. >=20 > At RSA he demonstrated a large number of issues with PKI that largely = come from it giving more options than people care to know what to do = with. DNSSEC is already more complex than X.509 was at a similar stage = of deployment. Well that is why the idea of using a subset of X509 could hit a sweet = spot. It requires no new tools, but could also reduce the complexity even further. The publication of a subset of X509 would = be simpler than X509 to implement, and so reduce the problems with it. > What appears to be a simpler mechanism to implement is only going to = save time and effort if it REPLACES the existing mechanism completely = and ELIMINATES the need to code for it. >=20 >=20 > Comparison to the design choices in FOAF is not very helpful since 1) = FOAF has something of a traction/deployment problem in itself and 2) use = in FOAF does not disrupt an existing deployed infrastructure. There are probably a lot more foaf files out there now than CA signed = TLS signed end points now. And I think those are just going to grow. = But that was not the point of my bringing foaf into the discussion. It = was just that naturally a few people we were working with thought of = using a subset of X509 to solve their problem.=20 >=20 > Predicting the security implications for a design change for a = security protocol deployed for 16 years is going to be very error prone. Not if you use a subset of what you are already using. In fact that is = why I am arguing for it. I don't like complexity. So for me in public = key cryptography it is the public keys that are key [sic]. The question = should be: =20 - why not serve the minimal information needed - what advantage does one get by serving the full X509 - what (dis)advantage of both - why not the public key rather than the signature? =20 The debate is not a either/or debate here. You already have 4 options in = section 2.2 of http://tools.ietf.org/html/draft-ietf-dane-protocol-04 If = it were to be an either/or, it could be between the options of = publishing the signature and the option of publishing the public key. It = seems to me that the public key is a lot more useful.=20 Henry >=20 >=20 > On Sat, Feb 19, 2011 at 11:46 AM, Peter Gutmann = wrote: > Henry Story writes: >=20 > >My question is: what do people use now to pass public keys? >=20 > X.509 key bags. >=20 > >I know an X509 cert contains the public key, though I don't know if = it can > >contain ECC keys. >=20 > It can contain any kind of key for any algorithm likely to be used = with TLS. >=20 > >If it does then there is another simple answer: extract the part of = that > >document that contains both the type of the key and the details of = it, and > >use that. >=20 > In that case why not just stick with X.509? This is bizarre, you have = a > universally-agreed-on, universally-supported format, and you're = proposing to > extract a subset of that requiring custom coding in each = implementation to > support and use that? >=20 > Another reason to stick with X.509 as key bags is that eventually = you're going > to want to put policy in the DNS ("must connect with TLS", "must use = EV > certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS > algorithms", and so on). Guess what X.509v3 key bags were = specifically > designed for? >=20 > The end result is that you'll end up reinventing X.509 as a container = format, > only it'll be some homebrew parallel format that needs custom code to = support > and endless kludging as things get bolted on that'd be automatically = supported > in the X.509 key bag format. It's reinventing the wheel, but making = it square > just to be different. >=20 > Peter. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 Social Web Architect http://bblfish.net/ --Apple-Mail-56--130696425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I agree with Peter here.

Folk who are = bike-shedding this one need to understand that he is the person they = need to persuade to write the code.

At RSA he = demonstrated a large number of issues with PKI that largely come from it = giving more options than people care to know what to do with. DNSSEC is = already more complex than X.509 was at a similar stage of = deployment.

Well that is why the = idea of using a subset of X509 could hit a sweet spot. It requires no = new tools, but could also reduce
the complexity even further. = The publication of a subset of X509 would be simpler than X509 to = implement, and so reduce the
problems with = it.

What appears to be a simpler mechanism to implement is only going = to save time and effort if it REPLACES the existing mechanism completely = and ELIMINATES the need to code for it.


Comparison to the design choices in FOAF is not very = helpful since 1) FOAF has something of a traction/deployment problem in = itself and 2) use in FOAF does not disrupt an existing deployed = infrastructure.

There are probably = a lot  more foaf files out there now than CA signed TLS signed end = points now. And I think those are just going to grow.  But that was = not the point of my bringing foaf into the discussion. It was just that = naturally a few people we were working with thought of using a subset of = X509 to solve their problem. 


Predicting the security implications for a design = change for a security protocol deployed for 16 years is going to be very = error prone.

Not if you use a = subset of what you are already using. In fact that is why I am arguing = for it. I don't like complexity. So for me in public key cryptography it = is the public keys that are key [sic]. The question should = be:
 
 - why not serve the minimal = information needed
 - what advantage does one get by = serving the full X509
 - what (dis)advantage of = both
 - why not the public key rather than the = signature?
 
The debate is not a either/or = debate here. You already have 4 options in section 2.2 of http://too= ls.ietf.org/html/draft-ietf-dane-protocol-04 If it were to be = an either/or, it could be between the options of  publishing the = signature and the option of publishing the public key. It seems to me = that the public key is a lot more = useful. 

Henry



On Sat, = Feb 19, 2011 at 11:46 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>= ; wrote:
Henry= Story <henry.story@bblfish.net> = writes:

>My question is: what do people use now to pass public keys?

X.509 key bags.

>I know an X509 cert contains the public key, though I don't know if = it can
>contain ECC keys.

It can contain any kind of key for any algorithm likely to be used = with TLS.

>If it does then there is another simple answer: extract the part of = that
>document that contains both the type of the key and the details of = it, and
>use that.

In that case why not just stick with X.509?  This is bizarre, = you have a
universally-agreed-on, universally-supported format, and you're = proposing to
extract a subset of that requiring custom coding in each implementation = to
support and use that?

Another reason to stick with X.509 as key bags is that eventually you're = going
to want to put policy in the DNS ("must connect with TLS", "must use = EV
certs", "must use a PFS algorithm like DH/ECDH", "cannot use = non-FIPS
algorithms", and so on).  Guess what X.509v3 key bags were = specifically
designed for?

The end result is that you'll end up reinventing X.509 as a container = format,
only it'll be some homebrew parallel format that needs custom code to = support
and endless kludging as things get bolted on that'd be automatically = supported
in the X.509 key bag format.  It's reinventing the wheel, but = making it square
just to be different.

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



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


Social = Web Architect
http://bblfish.net/

= --Apple-Mail-56--130696425-- 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 8BE383A6FBE for ; Sat, 19 Feb 2011 13:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 vp82mW3wxn2H for ; Sat, 19 Feb 2011 13:24:41 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C489C3A6F39 for ; Sat, 19 Feb 2011 13:24:40 -0800 (PST) Received: by bwz13 with SMTP id 13so1411887bwz.31 for ; Sat, 19 Feb 2011 13:25:17 -0800 (PST) Received: by 10.204.32.216 with SMTP id e24mr1971854bkd.204.1298150714857; Sat, 19 Feb 2011 13:25:14 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id v25sm2540317bkt.6.2011.02.19.13.25.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Feb 2011 13:25:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Sat, 19 Feb 2011 22:25:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Gutmann X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 21:24:45 -0000 On 19 Feb 2011, at 20:46, Peter Gutmann wrote: > Henry Story writes: >=20 >> My question is: what do people use now to pass public keys? >=20 > X.509 key bags Is that the same as X509? If not is there a specification one can look = that up on? >=20 >> I know an X509 cert contains the public key, though I don't know if = it can >> contain ECC keys. >=20 > It can contain any kind of key for any algorithm likely to be used = with TLS. great! So we at least no longer have the problem of the encoding. >=20 >> If it does then there is another simple answer: extract the part of = that >> document that contains both the type of the key and the details of = it, and >> use that. >=20 > In that case why not just stick with X.509? This is bizarre, you have = a > universally-agreed-on, universally-supported format, and you're = proposing to > extract a subset of that requiring custom coding in each = implementation to > support and use that? If the parsers for X509 are already written, then parsers for a subset of X509 are already written. It's going to be easy to use the same = tools. At least I think one should not dismiss that possibility. The code to = select the subset is going to be at most a few lines. > Another reason to stick with X.509 as key bags is that eventually = you're going > to want to put policy in the DNS ("must connect with TLS", "must use = EV > certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS > algorithms", and so on). Guess what X.509v3 key bags were = specifically > designed for? That is a reason for the argument to allowing the current options that = enable the DNS to also send full X509 documents. Btw. I have not really = looked at policy that much, can you point me to a human readable = document I can understand this part of X.509 more? (use cases and such) > The end result is that you'll end up reinventing X.509 as a container = format, Not at all, since we are selecting a piece of it. It would be as if you had a parser for atom documents [1] which = contain elements. The someone comes along and says that they = have a use case for documents containing documents only. The = problem of parsing those documents is not going to be an issue, neither = is the semantics of entry, at least for anyone who already has a parser = for > only it'll be some homebrew parallel format that needs custom code to = support > and endless kludging as things get bolted on that'd be automatically = supported > in the X.509 key bag format. It's reinventing the wheel, but making = it square > just to be different. There is no re-inventing the wheel here at all.=20 The advantage would bet that you are giving a format where you express = the key (so to speak) information. So that is why initially I was asking = what the benefits in terms of packets sent on the wire would be between = just sending the key in this subset of X509 and sending the full X509. = For sites like Google this could make an important difference. That is = something that is measurable, and could let us know if there is an = advantage at all of considering this.=20 Currently we are not asking to remove the other options. Just to see if = this option is possible, and to work out what the advantages and = disadvantages would be. Henry [1] http://www.ietf.org/rfc/rfc4287.txt >=20 > Peter. Social Web Architect http://bblfish.net/ 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 85CC03A6D75 for ; Sat, 19 Feb 2011 12:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 XuF+HOG20sgC for ; Sat, 19 Feb 2011 12:51:44 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2A1FE3A6CF4 for ; Sat, 19 Feb 2011 12:51:44 -0800 (PST) Received: by iwl42 with SMTP id 42so1609379iwl.31 for ; Sat, 19 Feb 2011 12:52:21 -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=iwH+rLZDHVc0+htIQyRMxb8osnFF9DX+g/ZGziagQg4=; b=wqa9zsYqf1Fz6oCQkIdX0nqgX5F5MIqrclY3AEZ9NrQKI8Wz5ONGH61DCCVvwy6/uB 03GuVaSYZzoK965knfKcJn346IxW4BP6Rzqr9zPqbM4uSrKSZnmcVYHFn5kjiTclOCzX Cn5sok7T6Y3V7zz9wKPvWOy9cp+FxhLwGBNfw= 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=cRFOwf2hBnaxvYji6leRqjJpM1h3mo+F12lnqLlqxnRnDtnINjyowU0pzuLGXyWNtj 6DZCiMzbJ+oaV4Z9wonYMy/b5aSIL0PtZooGV34HPjnBVjxJeqG94GnS6TC1o/2A7PA1 znZFD2UeuuwFJ6b5eMpt4sWMo7RJu1X8cfYZo= MIME-Version: 1.0 Received: by 10.42.213.138 with SMTP id gw10mr2816119icb.35.1298148740257; Sat, 19 Feb 2011 12:52:20 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 12:52:20 -0800 (PST) In-Reply-To: <4D6029E8.9020203@vpnc.org> References: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> <4D6029E8.9020203@vpnc.org> Date: Sat, 19 Feb 2011 12:52:20 -0800 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf30334939875731049ca8ceaf Cc: keyassure@ietf.org Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 20:51:45 -0000 --20cf30334939875731049ca8ceaf Content-Type: text/plain; charset=ISO-8859-1 I am starting to think that the only way this 'requirement' can be handled is if the browsers decide that they are going to explicitly support it and write code appropriately. That is, it is acceptable for a browser provider to either: 1) Say that SSL proxies are going to break because it is a clueless idea and they want them to break, die, die die. or 2) Say that an SSL proxy is only going to work if a root is added to the browser that is explicitly marked as being an SSL proxy root and having proxy capabilities. Note that in either case the ability to perform covert wiretap is lost. Merely having a root in the browser is not going to be sufficient to perform the attack, the root has to be marked as being proxy-authorized. On Sat, Feb 19, 2011 at 12:36 PM, Paul Hoffman wrote: > On 2/19/11 10:49 AM, Steingruebl, Andy wrote: > >> -----Original Message----- >>> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On >>> Behalf Of Paul Hoffman >>> >>> Regardless of the number of use cases, why is it an issue for TLSA? >>> Given that they are meant to be invisible to the users, isn't that >>> invisibility the >>> same with or without TLSA? >>> >> >> In the current CA/Browser (other code also) model there is not exclusion >> for trust-anchors. Any trust anchor can make claims for any name. With the >> advent of DANE/TLSA records, the situation changes. Please see the other >> mail I just sent... >> > > I'm not understanding you. TLSA is not looking to replace the current trust > anchors by removing them from the browser unless the user (or, in the case > in question, the user's administrator) wants to remove them. With an SSL > proxy, the user has a universal trust anchor added to their browser, and > TLSA doesn't affect that at all, if I understand the issue you are raising. > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --20cf30334939875731049ca8ceaf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am starting to think that the only way this 'requirement' can be = handled is if the browsers decide that they are going to explicitly support= it and write code appropriately.

That is, it is accepta= ble for a browser provider to either:

1) Say that SSL proxies are going to break because it i= s a clueless idea and they want them to break, die, die die.

=
or

2) Say that an SSL proxy is only goi= ng to work if a root is added to the browser that is explicitly marked as b= eing an SSL proxy root and having proxy capabilities.


Note that in either case the ability to = perform covert wiretap is lost. Merely having a root in the browser is not = going to be sufficient to perform the attack, the root has to be marked as = being proxy-authorized.



On Sat, Feb 19, 2011= at 12:36 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 2/19/11 10:49 AM, Steingruebl, Andy wrote:
-----Original Message-----
From: keyas= sure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On
Behalf Of Paul Hoffman

Regardless of the number of use cases, why is it an issue for TLSA?
Given that they are meant to be invisible to the users, isn't that invi= sibility the
same with or without TLSA?

In the current CA/Browser (other code also) model there is not exclusion fo= r trust-anchors. =A0Any trust anchor can make claims for any name. =A0With = the advent of DANE/TLSA records, the situation changes. =A0Please see the o= ther mail I just sent...

I'm not understanding you. TLSA is not looking to replace the current t= rust anchors by removing them from the browser unless the user (or, in the = case in question, the user's administrator) wants to remove them. With = an SSL proxy, the user has a universal trust anchor added to their browser,= and TLSA doesn't affect that at all, if I understand the issue you are= raising.

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



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

--20cf30334939875731049ca8ceaf-- 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 090BD3A6FB9 for ; Sat, 19 Feb 2011 12:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=0.798, 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 IpHDN3MYgq93 for ; Sat, 19 Feb 2011 12:36:20 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4EA6F3A6FB2 for ; Sat, 19 Feb 2011 12:36: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 p1JKau2K041411 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 19 Feb 2011 13:36:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6029E8.9020203@vpnc.org> Date: Sat, 19 Feb 2011 12:36:56 -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: <4D600FF8.3050002@vpnc.org> <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 20:36:21 -0000 On 2/19/11 10:49 AM, Steingruebl, Andy wrote: >> -----Original Message----- >> From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On >> Behalf Of Paul Hoffman >> >> Regardless of the number of use cases, why is it an issue for TLSA? >> Given that they are meant to be invisible to the users, isn't that invisibility the >> same with or without TLSA? > > In the current CA/Browser (other code also) model there is not exclusion for trust-anchors. Any trust anchor can make claims for any name. With the advent of DANE/TLSA records, the situation changes. Please see the other mail I just sent... I'm not understanding you. TLSA is not looking to replace the current trust anchors by removing them from the browser unless the user (or, in the case in question, the user's administrator) wants to remove them. With an SSL proxy, the user has a universal trust anchor added to their browser, and TLSA doesn't affect that at all, if I understand the issue you are raising. 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 0D38D3A6FB9 for ; Sat, 19 Feb 2011 12:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 FqTSjbOEXz7o for ; Sat, 19 Feb 2011 12:33:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8CCB03A6FA1 for ; Sat, 19 Feb 2011 12:33:38 -0800 (PST) Received: by iwl42 with SMTP id 42so1600033iwl.31 for ; Sat, 19 Feb 2011 12:34:15 -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=vBEJCnsDV92mTUD2/tkBfN30uISjlru+M2Rcivdxelg=; b=ALInhwb0fEm7l+BMbke5fBdZMELApJrm09ycJ3TZcCZTeYrkeet8Karho4QryBBQaO PiyIXDDvtVbFatNiv89aUj9R3FXrx4mMRKith7WpfJsXcX1JfNmRU62ntI49Km/2+q1/ u73SME4d8mbqD9bxESwdQ1ugVciTvVsBAgv34= 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=vxl8DSvfBV8Adw3XEfIRV3bIKesO+q2BfRaWGAM8u0yTbCufIWVVsfLiK8JeFOteZ9 w0NztUKi160tCkZ54PtzgqtRI5iOpIlaMvOfl3QbjKr9Qt02dNy6kte/mvQbpeRiXZOh ppwKOjj8s3ZUTzZGQFC5Ik3P5o/9DtTBYMx/E= MIME-Version: 1.0 Received: by 10.42.4.1 with SMTP id 1mr2724355icq.370.1298147655365; Sat, 19 Feb 2011 12:34:15 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 12:34:15 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Feb 2011 12:34:15 -0800 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016e68f67d8dd363e049ca88d2e Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 20:33:40 -0000 --0016e68f67d8dd363e049ca88d2e Content-Type: text/plain; charset=ISO-8859-1 I agree with Peter here. Folk who are bike-shedding this one need to understand that he is the person they need to persuade to write the code. At RSA he demonstrated a large number of issues with PKI that largely come from it giving more options than people care to know what to do with. DNSSEC is already more complex than X.509 was at a similar stage of deployment. What appears to be a simpler mechanism to implement is only going to save time and effort if it REPLACES the existing mechanism completely and ELIMINATES the need to code for it. Comparison to the design choices in FOAF is not very helpful since 1) FOAF has something of a traction/deployment problem in itself and 2) use in FOAF does not disrupt an existing deployed infrastructure. Predicting the security implications for a design change for a security protocol deployed for 16 years is going to be very error prone. On Sat, Feb 19, 2011 at 11:46 AM, Peter Gutmann wrote: > Henry Story writes: > > >My question is: what do people use now to pass public keys? > > X.509 key bags. > > >I know an X509 cert contains the public key, though I don't know if it can > >contain ECC keys. > > It can contain any kind of key for any algorithm likely to be used with > TLS. > > >If it does then there is another simple answer: extract the part of that > >document that contains both the type of the key and the details of it, and > >use that. > > In that case why not just stick with X.509? This is bizarre, you have a > universally-agreed-on, universally-supported format, and you're proposing > to > extract a subset of that requiring custom coding in each implementation to > support and use that? > > Another reason to stick with X.509 as key bags is that eventually you're > going > to want to put policy in the DNS ("must connect with TLS", "must use EV > certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS > algorithms", and so on). Guess what X.509v3 key bags were specifically > designed for? > > The end result is that you'll end up reinventing X.509 as a container > format, > only it'll be some homebrew parallel format that needs custom code to > support > and endless kludging as things get bolted on that'd be automatically > supported > in the X.509 key bag format. It's reinventing the wheel, but making it > square > just to be different. > > Peter. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e68f67d8dd363e049ca88d2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Peter here.

Folk who are bike-shedding this= one need to understand that he is the person they need to persuade to writ= e the code.


At RSA he demonstrated = a large number of issues with PKI that largely come from it giving more opt= ions than people care to know what to do with. DNSSEC is already more compl= ex than X.509 was at a similar stage of deployment.

What appears to be a simpler mechanism to implement is = only going to save time and effort if it REPLACES the existing mechanism co= mpletely and ELIMINATES the need to code for it.


Comparison to the design choices in FOAF is not very helpful= since 1) FOAF has something of a traction/deployment problem in itself and= 2) use in FOAF does not disrupt an existing deployed infrastructure.

Predicting the security implications for a design chang= e for a security protocol deployed for 16 years is going to be very error p= rone.


On Sat, Feb 1= 9, 2011 at 11:46 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:<= br>
Henry Story <henry.story@bblfish.net> writes:=

>My question is: what do people use now to pass public keys?

X.509 key bags.

>I know an X509 cert contains the public key, though I don't know if= it can
>contain ECC keys.

It can contain any kind of key for any algorithm likely to be used wi= th TLS.

>If it does then there is another simple answer: extract the part of tha= t
>document that contains both the type of the key and the details of it, = and
>use that.

In that case why not just stick with X.509? =A0This is bizarre, you h= ave a
universally-agreed-on, universally-supported format, and you're proposi= ng to
extract a subset of that requiring custom coding in each implementation to<= br> support and use that?

Another reason to stick with X.509 as key bags is that eventually you'r= e going
to want to put policy in the DNS ("must connect with TLS", "= must use EV
certs", "must use a PFS algorithm like DH/ECDH", "canno= t use non-FIPS
algorithms", and so on). =A0Guess what X.509v3 key bags were specifica= lly
designed for?

The end result is that you'll end up reinventing X.509 as a container f= ormat,
only it'll be some homebrew parallel format that needs custom code to s= upport
and endless kludging as things get bolted on that'd be automatically su= pported
in the X.509 key bag format. =A0It's reinventing the wheel, but making = it square
just to be different.

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



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

--0016e68f67d8dd363e049ca88d2e-- 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 C52F03A6D6A for ; Sat, 19 Feb 2011 11:45:36 -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 YamOMBrEkdh9 for ; Sat, 19 Feb 2011 11:45:35 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A9F4E3A6E28 for ; Sat, 19 Feb 2011 11:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298144772; x=1329680772; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20henry.story@bblfish.net,=20keyassure@ietf.org |Subject:=20Re:=20[keyassure]=20publishing=20the=20public =20key|In-Reply-To:=20|Message-Id:=20|Date:=20Sun,=2020=20Feb=202011=2008:4 6:08=20+1300; bh=hK/7t3JDPksvDPytjLFERHGIdzLpkdDx654c+9phUOw=; b=j0PDMB5zDpOIGwmK5kzW6jkyOMQbgntAtD5qmRmVcJQnzgeAjfbh7ljy f68AacDT/0qAGXYrXzaOx86k6CFqu57U6stUQXT4z1ZazVeiSCDDEwN8Z x8Xg+OBMarexsvY4M00E9wrRD6DTPAkXfd7eUMFOlnN3AYidX55PPZFA9 M=; X-IronPort-AV: E=Sophos;i="4.62,192,1296990000"; d="scan'208";a="46927781" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Feb 2011 08:46:09 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Pqskq-0000gd-IE; Sun, 20 Feb 2011 08:46:08 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Pqskq-0004pb-JY; Sun, 20 Feb 2011 08:46:08 +1300 From: Peter Gutmann To: henry.story@bblfish.net, keyassure@ietf.org In-Reply-To: Message-Id: Date: Sun, 20 Feb 2011 08:46:08 +1300 Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 19:45:36 -0000 Henry Story writes: >My question is: what do people use now to pass public keys? X.509 key bags. >I know an X509 cert contains the public key, though I don't know if it can >contain ECC keys. It can contain any kind of key for any algorithm likely to be used with TLS. >If it does then there is another simple answer: extract the part of that >document that contains both the type of the key and the details of it, and >use that. In that case why not just stick with X.509? This is bizarre, you have a universally-agreed-on, universally-supported format, and you're proposing to extract a subset of that requiring custom coding in each implementation to support and use that? Another reason to stick with X.509 as key bags is that eventually you're going to want to put policy in the DNS ("must connect with TLS", "must use EV certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS algorithms", and so on). Guess what X.509v3 key bags were specifically designed for? The end result is that you'll end up reinventing X.509 as a container format, only it'll be some homebrew parallel format that needs custom code to support and endless kludging as things get bolted on that'd be automatically supported in the X.509 key bag format. It's reinventing the wheel, but making it square just to be different. Peter. 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 5A9F43A6FB3 for ; Sat, 19 Feb 2011 11:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 HJlOJvYiKKLM for ; Sat, 19 Feb 2011 11:05:42 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 22D7F3A6FB0 for ; Sat, 19 Feb 2011 11:05:41 -0800 (PST) X-CheckPoint: {4D6014AA-20000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1JJ6GLc011619; Sat, 19 Feb 2011 21:06:16 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([194.29.34.26]) with mapi; Sat, 19 Feb 2011 21:06:16 +0200 From: Yoav Nir To: Phillip Hallam-Baker Date: Sat, 19 Feb 2011 21:06:14 +0200 Thread-Topic: [keyassure] The SSL Proxy Issue Thread-Index: AcvQaBUeplOKSxMrQISBJiEkx4j5TQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Langley , "keyassure@ietf.org" Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 19:05:43 -0000 On Feb 19, 2011, at 8:16 PM, Phillip Hallam-Baker wrote: > OK and I assume that this means that this would certainly not be EV compa= tible (unless the signer is breaching the EV requirements) >=20 > There are two use cases that I can see would drive this: >=20 > 1) Enterprises that are required to track internal communications.=20 What do you mean by "are required to"? Lots of times this comes from eithe= r a "security officer" or an auditor who says, "there's this tool in the to= olbox. Why aren't you using it?" The legitimate use can be that the company has some application firewall th= at blocks HTTP based attacks. Without an SSL proxy, you can't block the att= acks if they're over HTTPS. >=20 > 2) Governments looking to perform covert surveillance. >=20 >=20 > I only recognize one of these use cases as legitimate. The other is reall= y an anti-use case (attack). I agree. An attack is an attack, even if the attacker works for the good gu= ys. Even if the attacker is doing it for my own good. > The only difference I can see in these use cases is the 'covert' part. I = think it is OK to have a hole, provided the users know that there is a hole= . Well, it's the employer's computer and the employer's SSL proxy. The trust = anchor store is controlled by the employer through the operating system's r= emote management tools. The employee need never know, so I'm not sure if th= is doesn't fall under 'covert' as well. 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 1A0873A6F9C for ; Sat, 19 Feb 2011 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kmCoyJVo1fhi for ; Sat, 19 Feb 2011 10:48:48 -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 4A2643A6D2A for ; Sat, 19 Feb 2011 10:48:48 -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: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=W1elnvVVT8PSoe5FkbxyzTo5pqXKMyHwty3I6Sc2nbFcciYtUzZ+zqh0 hgUh225cdsczo3V4wbNKkbhDSUDAlCxUAa3+bbJjlqi0OKJH+cWWvcQ74 N/oaMVJVcKQDWTK; 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=1298141366; x=1329677366; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Hoffman=20,=20" keyassure@ietf.org"=0D=0A=09|Date:=20 Sat,=2019=20Feb=202011=2011:49:25=20-0700|Subject:=20RE: =20[keyassure]=20The=20SSL=20Proxy=20Issue|Message-ID:=20 <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001 .corp.ebay.com>|References:=20=0D=0A=09=0D =0A=09=0D=0A=20<4D600FF8.3050002@vpnc.org> |In-Reply-To:=20<4D600FF8.3050002@vpnc.org> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=wbMmaRWAgktuXHiePC2e87e5IunRGLbtPRZL1vH6uok=; b=jfGQkXs3zsm6+HIpHqCKdI5KuKKxbUnYJP7fot2g6ASlZUeE0949xUbe xQOElXRmr88NSC8n7a7UlaGR6IdJbc0Ws+js4zODFGMFdZwKIE+PE+bpM sqg01C6UQhWo4Zo; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.62,192,1297065600"; d="scan'208";a="1293035" 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; 19 Feb 2011 10:49:25 -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; Sat, 19 Feb 2011 11:49:25 -0700 From: "Steingruebl, Andy" To: Paul Hoffman , "keyassure@ietf.org" Date: Sat, 19 Feb 2011 11:49:25 -0700 Thread-Topic: [keyassure] The SSL Proxy Issue Thread-Index: AcvQZU/um5s6fSpfT4OWfi+TuZ2CrQAAENyA Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D9@DEN-MEXMS-001.corp.ebay.com> References: <4D600FF8.3050002@vpnc.org> In-Reply-To: <4D600FF8.3050002@vpnc.org> 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: wF19b394D7C5c2+R6F9xwQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 18:48:49 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Paul Hoffman >=20 > Regardless of the number of use cases, why is it an issue for TLSA? > Given that they are meant to be invisible to the users, isn't that invisi= bility the > same with or without TLSA? In the current CA/Browser (other code also) model there is not exclusion fo= r trust-anchors. Any trust anchor can make claims for any name. With the = advent of DANE/TLSA records, the situation changes. Please see the other m= ail I just sent... - 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 78E9C3A6F9C for ; Sat, 19 Feb 2011 10:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[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 UXICJJjFbVkg for ; Sat, 19 Feb 2011 10:47:24 -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 4A9263A6D2A for ; Sat, 19 Feb 2011 10:47:24 -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: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=L9/Z/O+3IoTQaQoHioanEwRU7uox0+JDDfldII1hAQ1D5jhOhpVEKzwV qoxe+BqR8KydMNd2OvQwUKoEIBEpv0FINbUPACD0rbZ45JynJH8BFVlmk UuEDn/F4PK3hL57; 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=1298141282; x=1329677282; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20"keyassure@ietf.org"=20 |Date:=20Sat,=2019=20Feb=202011=2011:48:01=20-0700 |Subject:=20RE:=20[keyassure]=20The=20SSL=20Proxy=20Issue |Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D 8@DEN-MEXMS-001.corp.ebay.com>|References:=20 =0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB3AAD71CA@DEN- MEXMS-001.corp.ebay.com>|In-Reply-To:=20<5EE049BA3C653840 9BBE6F1760F328ABEB3AAD71CA@DEN-MEXMS-001.corp.ebay.com> |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=W+ARIfOQgVGtz+kPPEkbALm/780jdUApym7cSPS3n4k=; b=oJnS6yZYmwN0uhvyGgUwEp869wfDk95z5T/1qxr5yhTVhYVbdIBZiSG7 lNC8duA6Q0zzr/dr31p9p+SiOy4qH25SOb4anth6RADckK0s11tF0UWh4 xcJz9HMow/3yHKe; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.62,192,1297065600"; d="scan'208";a="1293030" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 19 Feb 2011 10:48:01 -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; Sat, 19 Feb 2011 11:48:01 -0700 From: "Steingruebl, Andy" To: "keyassure@ietf.org" Date: Sat, 19 Feb 2011 11:48:01 -0700 Thread-Topic: [keyassure] The SSL Proxy Issue Thread-Index: AcvQWIElMGT8Xag1SRWJOGdhXCM3agABK/AQAAH5q1A= Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71D8@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71CA@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71CA@DEN-MEXMS-001.corp.ebay.com> 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: nR2ren5O6J5L+R7+Zgz+uw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 18:47:25 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Steingruebl, Andy >=20 > I'm personally in favor of a combination of #2/#3 as a long-term fix beca= use if > we don't specify a way to do this use case, people are going to bastardiz= e the > existing protocols in insecure ways that make a mess of things, just like= has > happened with the existing transparent proxy architectures in existence i= n > many places. We can't easily get people to get rid of those without prov= iding > them a solution, and absent a well-defined solution we're going to get > overloading of other functionality that will be ugly and insecure. Apologies for replying to my own post, but I fear my previous note could ha= ve been read as me advocating or at least not disapproving on inspecting ga= teways, etc. Far from it. I'd like these types of network inspections mad= e explicit and accounted for in our security models, and users to opt-in if= necessary. There are going to be networks that want to do admission contr= ol though for a diversity of clients, and their temptation will be to abuse= /augment existing protocols rather than inventing something new and/or usin= g a complicated protocol instead of a simpler one that gets them what they = want, consequences be damned. We should press back firmly on that, and I t= hink we need to do so proactively rather than just reactively. - 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 B22F03A6D2A for ; Sat, 19 Feb 2011 10:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.322 X-Spam-Level: X-Spam-Status: No, score=-100.322 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 oTFKhR8v1j+K for ; Sat, 19 Feb 2011 10:45:40 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1AB3F3A6DAD for ; Sat, 19 Feb 2011 10:45:40 -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 p1JIkG9t037541 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 19 Feb 2011 11:46:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D600FF8.3050002@vpnc.org> Date: Sat, 19 Feb 2011 10:46: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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 18:45:40 -0000 On 2/19/11 10:16 AM, Phillip Hallam-Baker wrote: > There are two use cases that I can see would drive this: > > 1) Enterprises that are required to track internal communications. > > 2) Governments looking to perform covert surveillance. There are actually many more. SSL proxies have become hammers that enterprises look at as universal tools. Regardless of the number of use cases, why is it an issue for TLSA? Given that they are meant to be invisible to the users, isn't that invisibility the same with or without TLSA? 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 6A3FD3A6DF7 for ; Sat, 19 Feb 2011 10:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.234 X-Spam-Level: X-Spam-Status: No, score=-101.234 tagged_above=-999 required=5 tests=[AWL=0.812, 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 JJ3rmfeDAFkH for ; Sat, 19 Feb 2011 10:41:14 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 977E53A6D2A for ; Sat, 19 Feb 2011 10:41: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 p1JIfoCG037323 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 19 Feb 2011 11:41:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D600EEE.4010509@vpnc.org> Date: Sat, 19 Feb 2011 10:41: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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 18:41:15 -0000 On 2/19/11 9:09 AM, Phillip Hallam-Baker wrote: > The problem with this approach is that it means that we are going to at > best be exercising new code paths in existing code. At worst we are > going to force people to write new code. Fully agree on both. I have yet to see what I asked for early on, which is any text that explains how a TLS client who gets a bare key would use it in TLS. If there is later a standards-track extension to TLS that handles bare public keys, that format can be added to TLSA at that time. It would use the exact same format so that clients can do exact matching without having to process either the key data from TLSA/DNS or the key data from the TLS handshake. I'm still open to hearing *why* adding bare keys would help TLSA, but I would also want to see text about how the processing would go so that I could weigh the benefit against the cost. 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 07F473A6DAD for ; Sat, 19 Feb 2011 10:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[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 2UnpomFcCvQc for ; Sat, 19 Feb 2011 10:19:05 -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 E6DDF3A6D3C for ; Sat, 19 Feb 2011 10:19:04 -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: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=LVlnB5K5EUgvNEomiBc4ZcfiFBaHGmEk3LcPkTEQYYCGCVlOibUBbXPn vlyl9B31eEpZWDErCEq9GaHjw9VvNmJP+Wvp5xsBvE2uHpNfJEN2u/8V/ JGf01e4Wy3QzgLL; 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=1298139582; x=1329675582; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Phillip=20Hallam-Baker=20, =20"keyassure@ietf.org"=0D=0A=09,=20D an=20Kaminsky=20|Date:=20Sat,=2019=20F eb=202011=2011:19:39=20-0700|Subject:=20RE:=20[keyassure] =20The=20SSL=20Proxy=20Issue|Message-ID:=20<5EE049BA3C653 8409BBE6F1760F328ABEB3AAD71CA@DEN-MEXMS-001.corp.ebay.com >|References:=20|In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=q5iZHZOCKv/t2oK/8h84UaSuqBbgKn6ijOuffIc0eNA=; b=lwC2w8H+uzBdKxbDAjprlk9xxLtv1uQ4/CX7U21a6bZqukbX5Wd0ld+A yMBYNT+xjrwLQ+qSIM6xdpMOIFIuWRzXLPPyFSYHbNs4+RxxDdhRQTJ6/ Ju1wBQ83h+AA7nt; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.62,192,1297065600"; d="scan'208";a="1292922" 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; 19 Feb 2011 10:19:41 -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; Sat, 19 Feb 2011 11:19:41 -0700 From: "Steingruebl, Andy" To: Phillip Hallam-Baker , "keyassure@ietf.org" , Dan Kaminsky Date: Sat, 19 Feb 2011 11:19:39 -0700 Thread-Topic: [keyassure] The SSL Proxy Issue Thread-Index: AcvQWIElMGT8Xag1SRWJOGdhXCM3agABK/AQ Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB3AAD71CA@DEN-MEXMS-001.corp.ebay.com> References: 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: SJq0VcfaykHnQMRB3aRPlQ== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 18:19:06 -0000 > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On B= ehalf Of Phillip Hallam-Baker >Could someone explain exactly how SSL MITM proxies are=A0 > 1) Being supported in existing browsers? To the best of my knowledge based on any/all documents I've ever seen, they= simply require an enterprise to install a new root-CA to each client machi= ne, and then they create new certs on the fly for each site a browser tries= to connect. Roughly the same technique that local web security testing to= ols such as Fiddler, Burp, etc. do it as well. > 2) Should be supported in DANE? Because the existing model (Multiple CAs all equally trusted) doesn't have = exclusion, the existing MITM SSL/TLS architecture can work. Now that one o= f the main features on DANE is a single trust root, I see only a few option= s to making this interception architecture still work, and they are all ugl= y. A few ideas on what we should do about it: =20 1. We should actually specify this use case somewhere, if not in the spec t= hen in a guidelines document. 2. We should explicitly make it hard to do as we don't think this type of n= etwork inspection is legitimate. 3. We should work on creating a new technology somewhere lower in the stack= that tells clients the rules/properties for a network. This problem is al= ready raising its ugly head because of HSTS in the presence of middlebox ar= chitectures such as those at hotels, coffee shops, etc. I'm personally in favor of a combination of #2/#3 as a long-term fix becaus= e if we don't specify a way to do this use case, people are going to bastar= dize the existing protocols in insecure ways that make a mess of things, ju= st like has happened with the existing transparent proxy architectures in e= xistence in many places. We can't easily get people to get rid of those wi= thout providing them a solution, and absent a well-defined solution we're g= oing to get overloading of other functionality that will be ugly and insecu= re. - 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 25AD73A6DAD for ; Sat, 19 Feb 2011 10:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 NnhzYN2roI4g for ; Sat, 19 Feb 2011 10:16:09 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C9DEE3A6D3C for ; Sat, 19 Feb 2011 10:16:09 -0800 (PST) Received: by iwl42 with SMTP id 42so1526059iwl.31 for ; Sat, 19 Feb 2011 10:16: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=iP0vNhjzZq37j15gNTLj+g79b9MmFpJySJAQE+HTlZw=; b=QtXAn88XZx5w0S2tbS7XN1oGM6J6oQJIb2DV2s7YlOAuSrWbxsvJlf2dlvcA7xey9P tmPzK7/xWihItyN4BrYtubjEpzJAuXhTiGF/gM2PJhIsg8TAW/LoYNH0LGUlS+rjT5U3 IYJ17sChqutiNV6J2pRegphbXjIiSzaSf55+M= 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=bGos9ZkJDIf3BZTIB8179oHBxv99MtZ6Nez+S+i0zXWkRqOv+ptIWXryc7RwFEzCO+ 4HuwPDz0dE0BDWV2tbwF1RU2TliYNLrcOyDOmVB4fzj53gZWX2Br7kTDC5shZGCCH+En XC8mG4Vo25/0rbuTLwWTm+T0wOYsvwvV98yWY= MIME-Version: 1.0 Received: by 10.42.240.196 with SMTP id lb4mr2662221icb.102.1298139405384; Sat, 19 Feb 2011 10:16:45 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 10:16:45 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Feb 2011 10:16:45 -0800 Message-ID: From: Phillip Hallam-Baker To: Adam Langley Content-Type: multipart/alternative; boundary=20cf30549b53207cec049ca6a215 Cc: keyassure@ietf.org Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 18:16:11 -0000 --20cf30549b53207cec049ca6a215 Content-Type: text/plain; charset=ISO-8859-1 OK and I assume that this means that this would certainly not be EV compatible (unless the signer is breaching the EV requirements) There are two use cases that I can see would drive this: 1) Enterprises that are required to track internal communications. 2) Governments looking to perform covert surveillance. I only recognize one of these use cases as legitimate. The other is really an anti-use case (attack). The only difference I can see in these use cases is the 'covert' part. I think it is OK to have a hole, provided the users know that there is a hole. I don't want NSA employees having private conversations from NSA machines that can't be tracked by the NSA. On Sat, Feb 19, 2011 at 9:57 AM, Adam Langley wrote: > On Sat, Feb 19, 2011 at 12:14 PM, Phillip Hallam-Baker > wrote: > > Could someone explain exactly how SSL MITM proxies are > > 1) Being supported in existing browsers? > > There is no explicit support. The proxy's signing certificate is > configured as a root on the client and the browser sees every site > signed by that root. > > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > -- Website: http://hallambaker.com/ --20cf30549b53207cec049ca6a215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OK and I assume that this means that this would certainly not be EV co= mpatible (unless the signer is breaching the EV requirements)
There are two use cases that I can see would drive this:

1) Enterprises that are required to track internal communication= s.=A0

2) Governments looking to perform covert sur= veillance.


I only recognize one of = these use cases as legitimate. The other is really an anti-use case (attack= ).

The only difference I can see in these use cases is the= 'covert' part. I think it is OK to have a hole, provided the users= know that there is a hole. I don't want NSA employees having private c= onversations from NSA machines that can't be tracked by the NSA.



On Sat, Feb 19, 2011= at 9:57 AM, Adam Langley <agl@imperialviolet.org> wrote:
On Sat, Feb 19, 2011 at 12:14 PM, Phillip Hallam-Baker &l= t;hallam@gmail.com> wrote:
> Could someone explain exactly how SSL MITM proxies are
> 1) Being supported in existing browsers?

There is no explicit support. The proxy's signing certificate is<= br> configured as a root on the client and the browser sees every site
signed by that root.


AGL

--
Adam Langley agl@imperialviolet.o= rg http://w= ww.imperialviolet.org



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

--20cf30549b53207cec049ca6a215-- 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 3EE143A6E83 for ; Sat, 19 Feb 2011 09:57:18 -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 Pkxr1noeLHX9 for ; Sat, 19 Feb 2011 09:57:17 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2E28C3A6E17 for ; Sat, 19 Feb 2011 09:57:17 -0800 (PST) Received: by iwl42 with SMTP id 42so1514949iwl.31 for ; Sat, 19 Feb 2011 09:57:54 -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=R2MfJ8ZpyIAs7gnwFivLuVvTl3aiW9wOZcEUMD9Iq8c=; b=dNObfSgLgp1CEtEAPq2GjCgnp6IFYWvAFN6AzBHRIlVzL/x317vMA+JtPnAWwctdmN 09mY1pgwAe+ij4dWA1wbpdaQ7z3Nh0V2AyoeOhbp7GlRqApvhi56uQfR9VsLRq3S35pS xdzEm18ZhPKV8mFtN2xkgkA9VdY2dDda73XQE= 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=qQqhWEFnNq3DPppoWB1GdOgdSILSFipm+XKMQyuF4V567US3PMfNuKtfuNFS+GInGJ ZoUFLOrfnKCKVkWKyho/lee7c8ok3V1nDdfhKjP0jq87hC1yk1jjEt7d7R90naUHzprt PT0FRkmuhCKDMnSGHIBsARv8LibJhu6SfeuOc= MIME-Version: 1.0 Received: by 10.42.179.138 with SMTP id bq10mr2643004icb.79.1298138273662; Sat, 19 Feb 2011 09:57:53 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.222.130 with HTTP; Sat, 19 Feb 2011 09:57:53 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Feb 2011 12:57:53 -0500 X-Google-Sender-Auth: eNgdf7H1yt0bzE-Mfv5LjyLnBfE Message-ID: From: Adam Langley To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org, Dan Kaminsky Subject: Re: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 17:57:18 -0000 On Sat, Feb 19, 2011 at 12:14 PM, Phillip Hallam-Baker wrote: > Could someone explain exactly how SSL MITM proxies are > 1) Being supported in existing browsers? There is no explicit support. The proxy's signing certificate is configured as a root on the client and the browser sees every site signed by that root. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 AD91E3A6AFD for ; Sat, 19 Feb 2011 09:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=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 MpNtlJgyyuGm for ; Sat, 19 Feb 2011 09:31:45 -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 6CFAA3A6C7D for ; Sat, 19 Feb 2011 09:31:44 -0800 (PST) Received: by fxm15 with SMTP id 15so1174483fxm.31 for ; Sat, 19 Feb 2011 09:32:20 -0800 (PST) Received: by 10.223.70.142 with SMTP id d14mr2699245faj.110.1298136739718; Sat, 19 Feb 2011 09:32:19 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id n2sm1640917fam.28.2011.02.19.09.32.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Feb 2011 09:32:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-54--145528025 From: Henry Story In-Reply-To: Date: Sat, 19 Feb 2011 18:32:15 +0100 Message-Id: <8D45B291-1E01-4986-A186-A33F5CACCB80@bblfish.net> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 17:31:46 -0000 --Apple-Mail-54--145528025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Feb 2011, at 18:09, Phillip Hallam-Baker wrote: > The problem with this approach is that it means that we are going to = at best be exercising new code paths in existing code. At worst we are = going to force people to write new code. >=20 >=20 > It is impossible to run TLS without X.509 code in the stack. = Everything else is superfluous. >=20 > This is really bikeshedding. It is not going to simplify = implementation by an iota and it is going to create yet another special = case to support.=20 >=20 > I don't think the crypto community wants to support yet another key = format. Even if that format is 'merely' a subset of an existing format. I don't think that is a problem. On the foaf-protocols list we were = discussing not so long ago using the public key element of X.509 only. = in DER format. So that instead of writing :me cert:publicKey [ rsa:modulus "..."; rsa:exponent "..." ] people could write :me cert:publicKey "SDFSDFJSRUSFZJLSDF"^^cert:derEncoded . People using python, perl, javascript found no problem with the parsing = of this. The javascript people even went so far as to write a javascript ASN.1 parsing library. https://github.com/digitalbazaar/forge/blob/master/js/asn1.js I am kind of against that more because it is silly to embed an ASN.1 DER = syntax inside an XML syntax. It just creates twice the work and no real benefit (only the illusory benefit that you = have 1 string, whereas in fact you then have to parse it with some other parse to get the two numbers out of it)=20 But I think that since you believe it has to be X509, then ASN.1 should = be the road for you. And I think that people working at the DNS level should have no trouble working with those tools, = especially the consumers such as browser vendors. Henry >=20 > On Sat, Feb 19, 2011 at 1:51 AM, Henry Story = wrote: > I had received your mails Peter. Your mail is also available in the = archives. >=20 > http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html >=20 > Ilari Liusvaara came up with a format for raw keys in what seems to be = C >=20 > http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html >=20 > (though I am not sure that C is progress over ASN.1 for such a = specification) >=20 > My question is: what do people use now to pass public keys? I know an = X509 cert > contains the public key, though I don't know if it can contain ECC = keys. > If it does then there is another simple answer: extract the part of = that document > that contains both the type of the key and the details of it, and use = that. >=20 > So in the XML world the xmldsig spec defines the KeyInfo element > http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo > which specified the following keys >=20 > * http://www.w3.org/2000/09/xmldsig#DSAKeyValue > * http://www.w3.org/2000/09/xmldsig#RSAKeyValue > * http://www.w3.org/2000/09/xmldsig#X509Data > * http://www.w3.org/2000/09/xmldsig#PGPData > * http://www.w3.org/2000/09/xmldsig#SPKIData > * http://www.w3.org/2000/09/xmldsig#MgmtData >=20 > So there one could just take the KeyInfo Element, and use that as a = document format to place the > keys in. Of course one would remove X509, PGP keys, and one would have = to define an xml structure for > elliptic curve keys. I am not recomending this option >=20 > So essentially there has to be a way of having a structure a bit more = general than the following > that can encode all the needed keys and that is extensible >=20 >=20 > RSAPublicKey ::=3D SEQUENCE { > modulus INTEGER, -- n > publicExponent INTEGER -- e > } >=20 >=20 > So there does not seem to be a lack of solutions. The trick I suppose = is finding the one that is the most likely to be adopted. I suppose some = ASN.1 DER encoding is the one most tools are ready for. >=20 > Henry >=20 > On 19 Feb 2011, at 02:24, Peter Gutmann wrote: >=20 > > [Several of my posts didn't make it to the list, these are re-posts = of earlier > > messages] > > > > Paul Wouters writes: > >> On Tue, 15 Feb 2011, Peter Gutmann wrote: > >>>> The public key's type and raw blob will be obtained from DNSSEC, = so this is > >>>> no longer required to be conveyed to the client from the server = via a PKIX > >>>> certificate or other ASN.1 structures. > >>> > >>> But what format is the "type and raw blob" in? You need some way = of encoding > >>> it, and if it's not the standard ASN.1 format what are you going = to use? > >> > >> I'm not sure I understand your question. > > > > A public key contains a number of components and options. For = example for ECC > > there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, = n, h for > > binary curves), an indication of the underlying field (prime or = binary), the > > point format, whether point compression is used, polynomial vs. = normal basis, > > whether fixed domain parameters are used, and probably some other = stuff I've > > forgotten. How is all this stuff communicated? > > > >> The key would encoded in DNS, likely in a format similar to DNSKEY. > > > > DNSKEY (RFC 3757) just specifies an opaque value labelled "public = key". If > > you mean RFC 4034: > > > > RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED > > Diffie-Hellman [DH] n [RFC2539] - > > DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL > > Elliptic Curve [ECC] TBA - > > RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY > > > > this (a) ain't gonna cut it because it doesn't cover what's required = by TLS > > and (b) requires that your TLS implementation speak DNSSEC (or at = least the > > DNSKEY part of DNSSEC) just to get a key. I can't see TLS = implementors being > > too enthusiastic about this. > > > > Peter. > > _______________________________________________ > > keyassure mailing list > > keyassure@ietf.org > > https://www.ietf.org/mailman/listinfo/keyassure >=20 > Social Web Architect > http://bblfish.net/ >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 Social Web Architect http://bblfish.net/ --Apple-Mail-54--145528025 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The problem with this approach is that it means that we = are going to at best be exercising new code paths in existing code. At = worst we are going to force people to write new = code.


It is impossible to run TLS = without X.509 code in the stack. Everything else is = superfluous.

This is really bikeshedding. It is not = going to simplify implementation by an iota and it is going to create = yet another special case to support. 

I = don't think the crypto community wants to support yet another key = format. Even if that format is 'merely' a subset of an existing = format.

 I don't = think that is a problem. On the foaf-protocols list we were discussing = not so long ago using the public key element of X.509 only. in DER = format.  So that instead of writing

:me = cert:publicKey [ rsa:modulus "..."; rsa:exponent "..." = ]

people could = write

:me cert:publicKey = "SDFSDFJSRUSFZJLSDF"^^cert:derEncoded .

People = using python, perl, javascript found no problem with the parsing of = this. The javascript people even went so
far as to write a = javascript ASN.1 parsing library.

<= br>
I am kind of against that more because it is silly to = embed an ASN.1 DER syntax inside an XML syntax. It just = creates
twice the work and no real benefit (only the illusory = benefit that you have 1 string, whereas in fact you then have = to
parse it with some other parse to get the two numbers out = of it) 
But I think that since you believe it has to be = X509, then ASN.1 should be the road for you. And I think that = people working
at the DNS level should have no trouble working = with those tools, especially the consumers such as browser = vendors.

Henry



On Sat, Feb 19, 2011 at 1:51 AM, Henry Story <henry.story@bblfish.net> wrote:
I had received your mails Peter.  Your mail is also available in = the archives.

  http://www.ietf.org/mail-archive/web/keyassure/current/m= sg01846.html

Ilari Liusvaara came up with a format for raw keys in what seems to be = C

  http://www.ietf.org/mail-archive/web/keyassure/current/m= sg01803.html

(though I am not sure that C is progress over ASN.1 for such a = specification)

My question is: what do people use now to pass public keys? I know an = X509 cert
contains the public key, though I don't know if it can contain ECC = keys.
If it does then there is another simple answer: extract the part of that = document
that contains both the type of the key and the details of it, and use = that.

So in the XML world the xmldsig spec defines the KeyInfo element
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
which specified the following keys

  * http://www.w3.org/2000/09/xmldsig#DSAKeyValue
  * http://www.w3.org/2000/09/xmldsig#RSAKeyValue
  * http://www.w3.org/2000/09/xmldsig#X509Data
  * http://www.w3.org/2000/09/xmldsig#PGPData
  * http://www.w3.org/2000/09/xmldsig#SPKIData
  * http://www.w3.org/2000/09/xmldsig#MgmtData

So there one could just take the KeyInfo Element, and use that as a = document format to place the
keys in. Of course one would remove X509, PGP keys, and one would have = to define an xml structure for
elliptic curve keys. I am not recomending this option

So essentially there has to be a way of having a structure a bit more = general than the following
that can encode all the needed keys and that is extensible


 RSAPublicKey ::=3D SEQUENCE {
   modulus           INTEGER, =  -- n
   publicExponent    INTEGER   -- e
 }


So there does not seem to be a lack of solutions. The trick I suppose is = finding the one that is the most likely to be adopted. I suppose some = ASN.1 DER encoding is the one most tools are ready for.

Henry

On 19 Feb 2011, at 02:24, Peter Gutmann wrote:

> [Several of my posts didn't make it to the list, these are re-posts = of earlier
> messages]
>
> Paul Wouters <paul@xelerance.com> = writes:
>> On Tue, 15 Feb 2011, Peter Gutmann wrote:
>>>> The public key's type and raw blob will be obtained = from DNSSEC, so this is
>>>> no longer required to be conveyed to the client from = the server via a PKIX
>>>> certificate or other ASN.1 structures.
>>>
>>> But what format is the "type and raw blob" in?  You = need some way of encoding
>>> it, and if it's not the standard ASN.1 format what are you = going to use?
>>
>> I'm not sure I understand your question.
>
> A public key contains a number of components and options. For = example for ECC
> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, = n, h for
> binary curves), an indication of the underlying field (prime or = binary), the
> point format, whether point compression is used, polynomial vs. = normal basis,
> whether fixed domain parameters are used, and probably some other = stuff I've
> forgotten.  How is all this stuff communicated?
>
>> The key would encoded in DNS, likely in a format similar to = DNSKEY.
>
> DNSKEY (RFC 3757) just specifies an opaque value labelled "public = key".  If
> you mean RFC 4034:
>
>  RSA/MD5 [RSAMD5]         n     =  [RFC2537]  NOT RECOMMENDED
>  Diffie-Hellman [DH]      n     =  [RFC2539]   -
>  DSA/SHA-1 [DSA]          y   =    [RFC2536]  OPTIONAL
>  Elliptic Curve [ECC]           =    TBA       -
>  RSA/SHA-1 [RSASHA1]      y     =  [RFC3110]  MANDATORY
>
> this (a) ain't gonna cut it because it doesn't cover what's = required by TLS
> and (b) requires that your TLS implementation speak DNSSEC (or at = least the
> DNSKEY part of DNSSEC) just to get a key. I can't see TLS = implementors being
> too enthusiastic about this.
>
> Peter.
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/

_______________________________________________



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


Social = Web Architect
http://bblfish.net/

= --Apple-Mail-54--145528025-- 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 5D35A3A6F85 for ; Sat, 19 Feb 2011 09:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.089, 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 IO7eKViz+KNp for ; Sat, 19 Feb 2011 09:14:02 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3FBE63A6F83 for ; Sat, 19 Feb 2011 09:14:02 -0800 (PST) Received: by iwl42 with SMTP id 42so1490312iwl.31 for ; Sat, 19 Feb 2011 09:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=e33GpaZiK17yOz7Zm+S8hwk562e4zmnD81UoFCm8SLo=; b=ZgmeAtlCWV21ydcBvOuyjPIV6QNWXjx+Uf/Y/okU+nKdF6ZWaU87H7SBLprT3JOq5d EkGHLfPvJjAhaLWsNWMXkGGxESu7X17VulRh3UZAqT8U0Z5X6Og7JY8xwmpBFQptcWaJ gYXBYrbFcW7xslaxAZNC+Z9ZAJth1hAuMuQ38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dnKZ3B0zWeoLhaBagJCdIDNTe/vQh7Y43nWP5spzk0JKlg4KPqRelrDJwpvxd6xUL5 0OsZQ12vzvzi1et4b9uZttI+jxJpVmWQ6AeRNCKleyCmtp2zksbda5sZjipbkGL/ztSt jQCfeKwEHbF2XJ+RI4jhSQ2KrTH7lJ2fyJTGw= MIME-Version: 1.0 Received: by 10.42.240.196 with SMTP id lb4mr2600108icb.102.1298135678936; Sat, 19 Feb 2011 09:14:38 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 09:14:38 -0800 (PST) Date: Sat, 19 Feb 2011 09:14:38 -0800 Message-ID: From: Phillip Hallam-Baker To: keyassure@ietf.org, Dan Kaminsky Content-Type: multipart/alternative; boundary=20cf30549b5303690f049ca5c462 Subject: [keyassure] The SSL Proxy Issue 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, 19 Feb 2011 17:14:03 -0000 --20cf30549b5303690f049ca5c462 Content-Type: text/plain; charset=ISO-8859-1 Could someone explain exactly how SSL MITM proxies are 1) Being supported in existing browsers? 2) Should be supported in DANE? Note that I am not interested in answers of the form 'read XYZ spec' unless it is coming from someone who knows the code matches that spec. I know that there are descriptions of what the behavior should be, but what I want to know is what the behavior is. I really worry that there is another Kaminsky type bug in there. The reason that bug existed for so long was that the protocol was known to be defective and there was little interest in determining exactly how defective. -- Website: http://hallambaker.com/ --20cf30549b5303690f049ca5c462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could someone explain exactly how SSL MITM proxies are=A0

1) Being supported in existing browsers?
2) Should be supported in DA= NE?

Note that I am not interested in answers of th= e form 'read XYZ spec' unless it is coming from someone who knows t= he code matches that spec. I know that there are descriptions of what the b= ehavior should be, but what I want to know is what the behavior is.

I really worry that there is another Kaminsky type bug = in there. The reason that bug existed for so long was that the protocol was= known to be defective and there was little interest in determining exactly= how defective.

--20cf30549b5303690f049ca5c462-- 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 AC7FA3A6F7C for ; Sat, 19 Feb 2011 09:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.098, 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 sSTvYOflHo4Y for ; Sat, 19 Feb 2011 09:08:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id CFEBD3A6F7A for ; Sat, 19 Feb 2011 09:08:54 -0800 (PST) Received: by iym1 with SMTP id 1so4884576iym.31 for ; Sat, 19 Feb 2011 09:09:31 -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=vyaZ62fok90ImONs8e37QbiYp0pG9t8iecnfUq7HzX4=; b=tXrrLOSBm9WqGxbFvxFE5+AGaYmhnVCydhEuCsxNmMb88Ylwcy3ciwsS/r9WyqHtsd ulVcZ5dhFvyBII2icF1LzxO6bt4e1JtpnA/d+EIR+9Nr864ghgTbixXyPTfGNWJr41TC XMSoRmY4yJwdwgn3Wjm1LC6Tx9DzONFXWoAGE= 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=KZyXMDhWfLsB1/eUttzoqwGH55HrqjUoX83T7vLjBJo75BDPE7HxkHiuWv/QOyuveA wpANCpwAvxrxSTVFSakW75lpMAgTolK/V34aVDh/ZriTxFWxms/svhAVgJLC2rl150NA 6i6+HGT9E+g6EJYHwc/XlLPDPOYLPfLnXJ3sw= MIME-Version: 1.0 Received: by 10.42.222.202 with SMTP id ih10mr2578947icb.236.1298135371352; Sat, 19 Feb 2011 09:09:31 -0800 (PST) Received: by 10.42.215.140 with HTTP; Sat, 19 Feb 2011 09:09:31 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Feb 2011 09:09:31 -0800 Message-ID: From: Phillip Hallam-Baker To: Henry Story Content-Type: multipart/alternative; boundary=20cf3054ab2bae0ceb049ca5b14e Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 17:08:56 -0000 --20cf3054ab2bae0ceb049ca5b14e Content-Type: text/plain; charset=ISO-8859-1 The problem with this approach is that it means that we are going to at best be exercising new code paths in existing code. At worst we are going to force people to write new code. It is impossible to run TLS without X.509 code in the stack. Everything else is superfluous. This is really bikeshedding. It is not going to simplify implementation by an iota and it is going to create yet another special case to support. I don't think the crypto community wants to support yet another key format. Even if that format is 'merely' a subset of an existing format. On Sat, Feb 19, 2011 at 1:51 AM, Henry Story wrote: > I had received your mails Peter. Your mail is also available in the > archives. > > http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html > > Ilari Liusvaara came up with a format for raw keys in what seems to be C > > http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html > > (though I am not sure that C is progress over ASN.1 for such a > specification) > > My question is: what do people use now to pass public keys? I know an X509 > cert > contains the public key, though I don't know if it can contain ECC keys. > If it does then there is another simple answer: extract the part of that > document > that contains both the type of the key and the details of it, and use that. > > So in the XML world the xmldsig spec defines the KeyInfo element > http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo > which specified the following keys > > * http://www.w3.org/2000/09/xmldsig#DSAKeyValue > * http://www.w3.org/2000/09/xmldsig#RSAKeyValue > * http://www.w3.org/2000/09/xmldsig#X509Data > * http://www.w3.org/2000/09/xmldsig#PGPData > * http://www.w3.org/2000/09/xmldsig#SPKIData > * http://www.w3.org/2000/09/xmldsig#MgmtData > > So there one could just take the KeyInfo Element, and use that as a > document format to place the > keys in. Of course one would remove X509, PGP keys, and one would have to > define an xml structure for > elliptic curve keys. I am not recomending this option > > So essentially there has to be a way of having a structure a bit more > general than the following > that can encode all the needed keys and that is extensible > > > RSAPublicKey ::= SEQUENCE { > modulus INTEGER, -- n > publicExponent INTEGER -- e > } > > > So there does not seem to be a lack of solutions. The trick I suppose is > finding the one that is the most likely to be adopted. I suppose some ASN.1 > DER encoding is the one most tools are ready for. > > Henry > > On 19 Feb 2011, at 02:24, Peter Gutmann wrote: > > > [Several of my posts didn't make it to the list, these are re-posts of > earlier > > messages] > > > > Paul Wouters writes: > >> On Tue, 15 Feb 2011, Peter Gutmann wrote: > >>>> The public key's type and raw blob will be obtained from DNSSEC, so > this is > >>>> no longer required to be conveyed to the client from the server via a > PKIX > >>>> certificate or other ASN.1 structures. > >>> > >>> But what format is the "type and raw blob" in? You need some way of > encoding > >>> it, and if it's not the standard ASN.1 format what are you going to > use? > >> > >> I'm not sure I understand your question. > > > > A public key contains a number of components and options. For example for > ECC > > there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h > for > > binary curves), an indication of the underlying field (prime or binary), > the > > point format, whether point compression is used, polynomial vs. normal > basis, > > whether fixed domain parameters are used, and probably some other stuff > I've > > forgotten. How is all this stuff communicated? > > > >> The key would encoded in DNS, likely in a format similar to DNSKEY. > > > > DNSKEY (RFC 3757) just specifies an opaque value labelled "public key". > If > > you mean RFC 4034: > > > > RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED > > Diffie-Hellman [DH] n [RFC2539] - > > DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL > > Elliptic Curve [ECC] TBA - > > RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY > > > > this (a) ain't gonna cut it because it doesn't cover what's required by > TLS > > and (b) requires that your TLS implementation speak DNSSEC (or at least > the > > DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors > being > > too enthusiastic about this. > > > > Peter. > > _______________________________________________ > > keyassure mailing list > > keyassure@ietf.org > > https://www.ietf.org/mailman/listinfo/keyassure > > Social Web Architect > http://bblfish.net/ > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --20cf3054ab2bae0ceb049ca5b14e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The problem with this approach is that it means that we are going to at bes= t be exercising new code paths in existing code. At worst we are going to f= orce people to write new code.


It is impo= ssible to run TLS without X.509 code in the stack. Everything else is super= fluous.

This is really bikeshedding. It is not going to simplif= y implementation by an iota and it is going to create yet another special c= ase to support.=A0

I don't think the crypto co= mmunity wants to support yet another key format. Even if that format is = 9;merely' a subset of an existing format.



On Sat, Feb 19, 2011= at 1:51 AM, Henry Story <henry.story@bblfish.net> wrote:
I had received your mails Peter. =A0Your mail is also available in the arch= ives.

=A0 http://www.ietf.org/mail-archive/web/keyassure= /current/msg01846.html

Ilari Liusvaara came up with a format for raw keys in what seems to be C
=A0 http://www.ietf.org/mail-archive/web/keyassure= /current/msg01803.html

(though I am not sure that C is progress over ASN.1 for such a specificatio= n)

My question is: what do people use now to pass public keys? I know an X509 = cert
contains the public key, though I don't know if it can contain ECC keys= .
If it does then there is another simple answer: extract the part of that do= cument
that contains both the type of the key and the details of it, and use that.=

So in the XML world the xmldsig spec defines the KeyInfo element
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
which specified the following keys

=A0 * http://www.w3.org/2000/09/xmldsig#DSAKeyValue
=A0 * http://www.w3.org/2000/09/xmldsig#RSAKeyValue
=A0 * http://www.w3.org/2000/09/xmldsig#X509Data
=A0 * http://www.w3.org/2000/09/xmldsig#PGPData
=A0 * http://www.w3.org/2000/09/xmldsig#SPKIData
=A0 * http://www.w3.org/2000/09/xmldsig#MgmtData

So there one could just take the KeyInfo Element, and use that as a documen= t format to place the
keys in. Of course one would remove X509, PGP keys, and one would have to d= efine an xml structure for
elliptic curve keys. I am not recomending this option

So essentially there has to be a way of having a structure a bit more gener= al than the following
that can encode all the needed keys and that is extensible


=A0RSAPublicKey ::=3D SEQUENCE {
=A0 =A0modulus =A0 =A0 =A0 =A0 =A0 INTEGER, =A0-- n
=A0 =A0publicExponent =A0 =A0INTEGER =A0 -- e
=A0}


So there does not seem to be a lack of solutions. The trick I suppose is fi= nding the one that is the most likely to be adopted. I suppose some ASN.1 D= ER encoding is the one most tools are ready for.

Henry

On 19 Feb 2011, at 02:24, Peter Gutmann wrote:

> [Several of my posts didn't make it to the list, these are re-post= s of earlier
> messages]
>
> Paul Wouters <paul@xelerance.= com> writes:
>> On Tue, 15 Feb 2011, Peter Gutmann wrote:
>>>> The public key's type and raw blob will be obtained fr= om DNSSEC, so this is
>>>> no longer required to be conveyed to the client from the s= erver via a PKIX
>>>> certificate or other ASN.1 structures.
>>>
>>> But what format is the "type and raw blob" in? =A0Yo= u need some way of encoding
>>> it, and if it's not the standard ASN.1 format what are you= going to use?
>>
>> I'm not sure I understand your question.
>
> A public key contains a number of components and options. For example = for ECC
> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, = h for
> binary curves), an indication of the underlying field (prime or binary= ), the
> point format, whether point compression is used, polynomial vs. normal= basis,
> whether fixed domain parameters are used, and probably some other stuf= f I've
> forgotten. =A0How is all this stuff communicated?
>
>> The key would encoded in DNS, likely in a format similar to DNSKEY= .
>
> DNSKEY (RFC 3757) just specifies an opaque value labelled "public= key". =A0If
> you mean RFC 4034:
>
> =A0RSA/MD5 [RSAMD5] =A0 =A0 =A0 =A0 n =A0 =A0 =A0[RFC2537] =A0NOT RECO= MMENDED
> =A0Diffie-Hellman [DH] =A0 =A0 =A0n =A0 =A0 =A0[RFC2539] =A0 -
> =A0DSA/SHA-1 [DSA] =A0 =A0 =A0 =A0 =A0y =A0 =A0 =A0[RFC2536] =A0OPTION= AL
> =A0Elliptic Curve [ECC] =A0 =A0 =A0 =A0 =A0 =A0 =A0TBA =A0 =A0 =A0 - > =A0RSA/SHA-1 [RSASHA1] =A0 =A0 =A0y =A0 =A0 =A0[RFC3110] =A0MANDATORY<= br> >
> this (a) ain't gonna cut it because it doesn't cover what'= s required by TLS
> and (b) requires that your TLS implementation speak DNSSEC (or at leas= t the
> DNSKEY part of DNSSEC) just to get a key. I can't see TLS implemen= tors being
> too enthusiastic about this.
>
> Peter.
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/
_______________________________________________



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

--20cf3054ab2bae0ceb049ca5b14e-- 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 41C903A6E08 for ; Sat, 19 Feb 2011 07:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-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 nFuao-sbyM1A for ; Sat, 19 Feb 2011 07:20:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8556D3A6E02 for ; Sat, 19 Feb 2011 07:20:47 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pqocd-00025H-1j; Sat, 19 Feb 2011 07:21:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Sat, 19 Feb 2011 15:21:22 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/3#comment:2 Message-ID: <065.1bcc2baf515256b7f61537e00154e819@tools.ietf.org> References: <056.b19e9c0b5b8b436b994966a1b4fc8484@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <056.b19e9c0b5b8b436b994966a1b4fc8484@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #3 (closed): Format of the record. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 15:20:48 -0000 #3: Format of the record. Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: Consensus called as: We will be using a new RR type. -- --------------------------------+------------------------------------------- Reporter: warren@… | Owner: Type: task | Status: closed Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: dane 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 CAE303A6E08 for ; Sat, 19 Feb 2011 07:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=0.875, 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 l04tZwZtCY0Z for ; Sat, 19 Feb 2011 07:16:22 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 08EE43A6DF6 for ; Sat, 19 Feb 2011 07:16:21 -0800 (PST) Received: from [172.19.118.186] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 39D7D1B40FA1; Sat, 19 Feb 2011 10:16:57 -0500 (EST) Message-Id: <63DFD4EB-F560-491E-9B22-888105041798@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: Sat, 19 Feb 2011 10:16:53 -0500 References: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> X-Mailer: Apple Mail (2.936) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #3: Format of the record. 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, 19 Feb 2011 15:16:22 -0000 Okey dokey -- it seems that we are all happy with using "a new RR type (used in draft-ietf-dane-protocol-00)" and so I'm calling it.... W On Feb 13, 2011, at 2:47 PM, Paul Wouters wrote: > On Thu, 10 Feb 2011, Warren Kumari wrote: > >> We have "Issue #3: Format of the record" with the description: >> >> -------------------- >> Format of the record: >> a subtype of CERT (as was used in early drafts) >> a new RRtype (used in draft-ietf-dane-protocol-00) >> a TXT record with _prefix. >> >> Hopefully this is just a representation issue and can be worked on >> after larger decisions have been made. >> >> ---------------------- >> >> I think that we have settled on using a new RRtype (as shown in >> draft-ietf-dane-protocol-00), but I realize that we haven't >> explicitly had a consensus call on this, so I am (with all >> reverence) donning the bells and ribbons, stepping over the clay >> pipes, smacking myself smartly with the stick and beginning the >> consensus call... > > Yes, a new RRTYPE. > > 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 CEF823A6FD5 for ; Sat, 19 Feb 2011 01:50:43 -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 kty4XihGC4W8 for ; Sat, 19 Feb 2011 01:50:42 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E7B5D3A6EAA for ; Sat, 19 Feb 2011 01:50:41 -0800 (PST) Received: by bwz13 with SMTP id 13so1064898bwz.31 for ; Sat, 19 Feb 2011 01:51:17 -0800 (PST) Received: by 10.204.126.138 with SMTP id c10mr1581427bks.156.1298109075284; Sat, 19 Feb 2011 01:51:15 -0800 (PST) Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id x38sm2090097bkj.13.2011.02.19.01.51.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Feb 2011 01:51:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Henry Story In-Reply-To: Date: Sat, 19 Feb 2011 10:51:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 09:50:44 -0000 I had received your mails Peter. Your mail is also available in the = archives. http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html Ilari Liusvaara came up with a format for raw keys in what seems to be C =20 http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html (though I am not sure that C is progress over ASN.1 for such a = specification) My question is: what do people use now to pass public keys? I know an = X509 cert contains the public key, though I don't know if it can contain ECC keys.=20= If it does then there is another simple answer: extract the part of that = document that contains both the type of the key and the details of it, and use = that. So in the XML world the xmldsig spec defines the KeyInfo element=20 http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo which specified the following keys * http://www.w3.org/2000/09/xmldsig#DSAKeyValue * http://www.w3.org/2000/09/xmldsig#RSAKeyValue * http://www.w3.org/2000/09/xmldsig#X509Data * http://www.w3.org/2000/09/xmldsig#PGPData * http://www.w3.org/2000/09/xmldsig#SPKIData * http://www.w3.org/2000/09/xmldsig#MgmtData So there one could just take the KeyInfo Element, and use that as a = document format to place the keys in. Of course one would remove X509, PGP keys, and one would have = to define an xml structure for elliptic curve keys. I am not recomending this option So essentially there has to be a way of having a structure a bit more = general than the following that can encode all the needed keys and that is extensible RSAPublicKey ::=3D SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e } So there does not seem to be a lack of solutions. The trick I suppose is = finding the one that is the most likely to be adopted. I suppose some = ASN.1 DER encoding is the one most tools are ready for. Henry On 19 Feb 2011, at 02:24, Peter Gutmann wrote: > [Several of my posts didn't make it to the list, these are re-posts of = earlier > messages] >=20 > Paul Wouters writes: >> On Tue, 15 Feb 2011, Peter Gutmann wrote: >>>> The public key's type and raw blob will be obtained from DNSSEC, so = this is >>>> no longer required to be conveyed to the client from the server via = a PKIX >>>> certificate or other ASN.1 structures. >>>=20 >>> But what format is the "type and raw blob" in? You need some way of = encoding >>> it, and if it's not the standard ASN.1 format what are you going to = use? >>=20 >> I'm not sure I understand your question. >=20 > A public key contains a number of components and options. For example = for ECC > there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, = h for > binary curves), an indication of the underlying field (prime or = binary), the > point format, whether point compression is used, polynomial vs. normal = basis, > whether fixed domain parameters are used, and probably some other = stuff I've > forgotten. How is all this stuff communicated? >=20 >> The key would encoded in DNS, likely in a format similar to DNSKEY. >=20 > DNSKEY (RFC 3757) just specifies an opaque value labelled "public = key". If > you mean RFC 4034: >=20 > RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED > Diffie-Hellman [DH] n [RFC2539] - > DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL > Elliptic Curve [ECC] TBA - > RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY >=20 > this (a) ain't gonna cut it because it doesn't cover what's required = by TLS > and (b) requires that your TLS implementation speak DNSSEC (or at = least the > DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors = being > too enthusiastic about this. >=20 > Peter. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Social Web Architect http://bblfish.net/ 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 0DC893A6CEF for ; Fri, 18 Feb 2011 17:41:15 -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 ncmhKPBuBMND for ; Fri, 18 Feb 2011 17:41:14 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id BAEF83A6C77 for ; Fri, 18 Feb 2011 17:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298079709; x=1329615709; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20keyassure@ietf.org,=20paul.hoffman@vpnc.org |Subject:=20Re:=20[keyassure]=20publishing=20the=20public =20key|In-Reply-To:=20<4D5A9C2F.6050205@vpnc.org> |Message-Id:=20|Date:=20Sat,=2019=20Feb=202011=2014:41:47=20+1300; bh=ao8H5hRi42B2yGvcgl7YoSM9430XZBO2U0LuT3GDJ18=; b=BMQGVoa/HUjyDtDsaydIvA8dmuv8ZpS8jban6lTFP06XITzhoLW8TPQK w83fYQB7n7PwM4E6TjQ2DDD9UjZYpjmotAEDy24I0KppI0wWD3/Jtronq 8fEVhWK/mZthCIZeBexs0/p8FfiWXf9CWw6IqWgiw1nKuqdt7zhhv6NX4 Q=; X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46882521" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 14:41:47 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqbpT-0004G9-IO; Sat, 19 Feb 2011 14:41:47 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqbpT-0000pd-Kz; Sat, 19 Feb 2011 14:41:47 +1300 From: Peter Gutmann To: keyassure@ietf.org, paul.hoffman@vpnc.org In-Reply-To: <4D5A9C2F.6050205@vpnc.org> Message-Id: Date: Sat, 19 Feb 2011 14:41:47 +1300 Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 01:41:15 -0000 Paul Hoffman writes: >I disagree that us using bare keys for identifying TLS server certificates is >impossible. It's not impossible, but close to it (and for ECC algos it may well be impossible). This is a really, really bad way to identify a cert. For relatively simple algorithms like RSA "all" you need to do is decode the key in the cert (assuming your PKI API actually gives you access to it, if it just treats the cert as a blob used for signing or encryption then you may not be able to get to it), decode the key in DNS, canonicalise the two in some manner, and then compare the components (as opposed to storing a hash of the cert, for which you call memcmp(), thus the "all" in quotes above). For ECC keys there are so many ways to store the same key (different parameter encodings, optional parameters, different ways of identifying the same parameters and in different formats) that in general there's no really reliable way to compare them. Even with the simplest key type, RSA, it was hard enough, I've got code that mostly works most of the time and that's way more complicated than it has to be. If you want to uniquely identify a certificate, use the SHA-1 hash like everything else does. Peter. 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 43BB93A6F52 for ; Fri, 18 Feb 2011 17:24:02 -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 tUnGV0h8-QLH for ; Fri, 18 Feb 2011 17:24:01 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id EFDDD3A6EDE for ; Fri, 18 Feb 2011 17:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298078676; x=1329614676; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20keyassure@ietf.org|Subject:=20Re:=20[keyassure]=20 publishing=20the=20public=20key|Message-Id:=20|Date:=20Sat,=2019=20F eb=202011=2014:24:35=20+1300; bh=mjF1W3gMfrsKhVGgIWhvKXLAyDaPO06qqxhUIdez8ug=; b=kR57CqoH1ms1i2C5pWOxe18Ybj4FLmaWTfBnpSQF0bOLHthAZiR1liBL Dc5WE5yIobQ6MB2vQNBO0uJUPH4CSul3oJQvrHzGPQ7ULrYU6dAGjTzVY Y4Nrx+4FMxiXX1G8exr0nqCqYf6r9XBRPVKRnJxuhA065er7amCddyp+5 4=; X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46881848" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 14:24:35 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqbYp-0003lx-Hg for keyassure@ietf.org; Sat, 19 Feb 2011 14:24:35 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqbYp-0008EI-Dx for keyassure@ietf.org; Sat, 19 Feb 2011 14:24:35 +1300 From: Peter Gutmann To: keyassure@ietf.org Message-Id: Date: Sat, 19 Feb 2011 14:24:35 +1300 Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 01:24:02 -0000 [Several of my posts didn't make it to the list, these are re-posts of earlier messages] Paul Wouters writes: >On Tue, 15 Feb 2011, Peter Gutmann wrote: >>> The public key's type and raw blob will be obtained from DNSSEC, so this is >>> no longer required to be conveyed to the client from the server via a PKIX >>> certificate or other ASN.1 structures. >> >> But what format is the "type and raw blob" in? You need some way of encoding >> it, and if it's not the standard ASN.1 format what are you going to use? > >I'm not sure I understand your question. A public key contains a number of components and options. For example for ECC there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h for binary curves), an indication of the underlying field (prime or binary), the point format, whether point compression is used, polynomial vs. normal basis, whether fixed domain parameters are used, and probably some other stuff I've forgotten. How is all this stuff communicated? >The key would encoded in DNS, likely in a format similar to DNSKEY. DNSKEY (RFC 3757) just specifies an opaque value labelled "public key". If you mean RFC 4034: RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED Diffie-Hellman [DH] n [RFC2539] - DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL Elliptic Curve [ECC] TBA - RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY this (a) ain't gonna cut it because it doesn't cover what's required by TLS and (b) requires that your TLS implementation speak DNSSEC (or at least the DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors being too enthusiastic about this. Peter. 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 50DC63A6F4A for ; Fri, 18 Feb 2011 17:23:30 -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 lO3LGCEQvySu for ; Fri, 18 Feb 2011 17:23:29 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id EBFAE3A6EDE for ; Fri, 18 Feb 2011 17:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298078644; x=1329614644; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20henry.story@bblfish.net,,=20keyassure@ietf.org,=20 mrex@sap.com,|Subject:=20Re:=20[keyassure]=20publishing =20the=20public=20key|Message-Id:=20|Date:=20Sat,=2019=20Feb=202011 =2014:24:03=20+1300; bh=7TBLq19VPmiCtj+fztwk/YqIS7OiSEOx4mkZQ4hpD7I=; b=AJ48fX8BRvUFu7bOxj/NjHAmi84W/h/q/Y43v8gzhbqefV9Nm/Bw4JrC IwuHOb+LCJKY58KfCYRc2i2ryT4abma1LpKn3x11wOLURgjiizUR7raW0 zYHB3znGXdoo0KZsW7dqhAxoYnymdBzUvgyQuDJxmjIunL7fowbeQ2FUB g=; X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46881834" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 14:24:03 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqbYJ-0003kr-HC; Sat, 19 Feb 2011 14:24:03 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqbYJ-0008E9-93; Sat, 19 Feb 2011 14:24:03 +1300 From: Peter Gutmann To: henry.story@bblfish.net,, keyassure@ietf.org, mrex@sap.com, Message-Id: Date: Sat, 19 Feb 2011 14:24:03 +1300 Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 01:23:30 -0000 [Several of my posts didn't make it to the list, these are re-posts of earlier messages] Henry Story writes: >And I think Browser Vendors will be very keen to implement this, as well as >DNSSEC of course, given the terrible state of DNS. Have any browser vendors actually expressed this opinion? Given their well- established track record of responding with PKI-me-harder in response to existing PKI problems, are you sure they're going to rush to embrace this? (Don't get me wrong, I think it's a really neat idea, I just can't see browser vendors embracing it, given their current track record). Peter. 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 437783A6ECB for ; Fri, 18 Feb 2011 17:15:10 -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 Q-tBdrv5JLHg for ; Fri, 18 Feb 2011 17:15:08 -0800 (PST) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id AA22F3A6D9C for ; Fri, 18 Feb 2011 17:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298078144; x=1329614144; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20henry.story@bblfish.net,,=20keyassure@ietf.org |Subject:=20Re:=20[keyassure]=20publishing=20the=20public =20key|Message-Id:=20|Date:=20Sat,=2019=20Feb=202011=2014:15:35=20+1 300; bh=NQlNBYBQqUeav2hn+2q9rN8JAkUHeVV2rivVICBEpDE=; b=NpAIy7WyR6tCrV5GpfArGJCv37RXvsgEbgGNPqmgwU5w0NFr/XS9Zv0E NPwa5JQiU0rvTBdvLWZAeIfcRH2i94vdlDZ7SFx7hEBlbVUciyyFYtuoL lByRGpFMAUZjZSc2ubzMQ32VgifFAIvpuaXiKALmKFd4978PYZBE06zU6 M=; X-IronPort-AV: E=Sophos;i="4.62,190,1296990000"; d="scan'208";a="46881582" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Feb 2011 14:15:36 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PqbQ7-0003Wn-HZ; Sat, 19 Feb 2011 14:15:35 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1PqbQ7-0007aF-Cy; Sat, 19 Feb 2011 14:15:35 +1300 From: Peter Gutmann To: henry.story@bblfish.net,, keyassure@ietf.org Message-Id: Date: Sat, 19 Feb 2011 14:15:35 +1300 Subject: Re: [keyassure] publishing the public key 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, 19 Feb 2011 01:15:10 -0000 [Several of my posts didn't make it to the list, these are re-posts of earlier messages] Henry Story writes: >In draft-dane-04 [1] one can currently only publish either a signature or a >certificate in the DNS. That is the only allowed formats of the resource >record are as specified in section 2.2 > >[...] > >Why not publish the only piece of the certificate that is important in public >key cryptography: the public key. Whatever format gets used, could we restrict things to just a single form, or at most two forms? At the moment we've got two types of certs, two hashes of certs, and a raw public key (or, most likely, two of them). In practice there's going to be some de facto standard that everyone uses (e.g. SHA-1 hashes of certs for "fingerprints", which every browser seems to support even though there isn't even a standard specifying them), and adding a whole pile of formats is going to reduce interoperability or (more likely) lead to implementors ignoring all but whatever ends up as the de facto standard. I'd use the cert fingerprint (which is already the de facto universal identifier) as a MUST and leave the rest as options. TLS already requires that you send the full cert, TLS implementations already generate a cert fingerprint, so all that's left to implement besides (shudder) the res_query() lookup is a memcmp(). Peter. 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 9498F3A6C8B for ; Thu, 17 Feb 2011 05:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, 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 SX7lDYF2MKsT for ; Thu, 17 Feb 2011 05:55:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id EE9353A6CC6 for ; Thu, 17 Feb 2011 05:55:39 -0800 (PST) Received: by iym1 with SMTP id 1so2546180iym.31 for ; Thu, 17 Feb 2011 05:56:11 -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=QkptAeFabf9q11+3eyjvHOOMcK5Q7fJ2epyjqJ2MTUI=; b=dMLPcw67Y1+iOf+sEkAWZ5iDmKkZ2RzDYfj18yH2v+ejgJudSpDkVweWkyhhceREH9 NUL4dDx1ls+KQ8VfV7k+A4AXy09G31mNqyzbg7ziR56jgWnFiNMTbKoD7lXFsNCVAtzY PUSPfSljrwmOcXhxckL9qnGXyr0FpsdYAH9PE= 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=GehdICTF3vVIIpI/diDDw+kZFTm7eFkovqO2o+jPD3Ki3fGyP46oQZWpSV6R1O2LQk gbxL3/XIyy/hpYOe5+ETjadSUykURUMFH15lJDFOSOLVX539aXwz63d2wClDBcFD9U3l rVs+Q39vgKZn9gp4YKpesPZrrROwNKf6ZAQKY= MIME-Version: 1.0 Received: by 10.42.173.194 with SMTP id s2mr2787870icz.169.1297950970427; Thu, 17 Feb 2011 05:56:10 -0800 (PST) Received: by 10.42.215.140 with HTTP; Thu, 17 Feb 2011 05:56:10 -0800 (PST) In-Reply-To: <67AE67DA-4EDD-48AF-BF15-2F86DD63EA68@checkpoint.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <67AE67DA-4EDD-48AF-BF15-2F86DD63EA68@checkpoint.com> Date: Thu, 17 Feb 2011 05:56:10 -0800 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=90e6ba6e866887386f049c7ac26b Cc: Adam Langley , "keyassure@ietf.org" Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 17 Feb 2011 13:55:41 -0000 --90e6ba6e866887386f049c7ac26b Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 16, 2011 at 11:24 AM, Yoav Nir wrote: > > On Feb 16, 2011, at 6:48 PM, Adam Langley wrote: > > > On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters > wrote: > >> But it is not the vendors that would need to make that change? It's just > the > >> browser people and the entity deploying SSL proxies? > > > > Ah, I understand what you are suggesting. Indeed you could do that > > with just action by the proxy admins. However, I still feel that those > > people will be very slow in changing. > > I disagree. While my company doesn't make SSL proxies, we do make > firewalls, and it's always up to us to accommodate whatever browsers > customers are using. 10 years ago it turned out that our firewall was > blocking Netscape browsers on Mac OS 9.2. We had to change our firewall. > > So if some new version of a popular browser starts getting blocked behind > the SSL proxy, then the proxy vendor will be pressured to fix it. It's a > competitive market, and you don't get to say, "oh, we don't support Chrome > 11. Maybe we will next year" But you do get to say 'we don't support a specific feature of Chrome 11'. Having run firewalls as an outsourced service, I know that a huge fraction of the installed base is misconfigured and has obsolete configurations. A non trivial fraction of firewalls being brought under management turn out to be configured for pass through of all protocols (The $250,000 ethernet cable configuration). I think we need to have a document that sets out what the specific issues with these proxies are and we need to decide which to support and which to not support. SSL is not 'designed' to prevent MITM attacks, the whole PURPOSE of SSL is to prevent MITM attacks. So I think we need to decide which issues to support and which not to support. I strongly suspect that the MITM proxy ssl capabilities are underspecified to say the least. They were originally a feature that was thrown into Netscape Navigator for expediency with zero discussion outside the company. I know that it is the type of feature that IETF types have traditionally preferred to ignore. I certainly have felt no inclination to look at that type of feature. It was put in the specs against my protests as a fait accompli. But that is a pretty bad situation from a security point of view and there is a huge risk here of creating a massive hole in SSL of Kaminsky proportions if people decide that they can simply follow the same approach because they have a particular view of what CAs do and they can remove controls that they personally don't think matter. I think we are going to either have to decide that this scheme is not going to support SSL proxies at all or it is going to have to have a first class mechanism designed to support the SSL proxy use case. Handwaving arguments about security protocols are a recipe for disaster. In particular the argument that 'its ok we already do this without disaster' has led to a number of notorious security protocol failures. -- Website: http://hallambaker.com/ --90e6ba6e866887386f049c7ac26b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 16, 2011 at 11:24 AM, Yoav N= ir <ynir@checkp= oint.com> wrote:

On Feb 16, 2011, at 6:48 PM, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters <paul@xelerance.com> wrote:
>> But it is not the vendors that would need to make that change? It&= #39;s just the
>> browser people and the entity deploying SSL proxies?
>
> Ah, I understand what you are suggesting. Indeed you could do that
> with just action by the proxy admins. However, I still feel that those=
> people will be very slow in changing.

I disagree. While my company doesn't make SSL proxies, we do make= firewalls, and it's always up to us to accommodate whatever browsers c= ustomers are using. 10 years ago it turned out that our firewall was blocki= ng Netscape browsers on Mac OS 9.2. We had to change our firewall.

So if some new version of a popular browser starts getting blocked behind t= he SSL proxy, then the proxy vendor will be pressured to fix it. It's a= competitive market, and you don't get to say, "oh, we don't s= upport Chrome 11. Maybe we will next year"

But you do get to say 'we don't support a speci= fic feature of Chrome 11'.

Having run firewall= s as an outsourced service, I know that a huge fraction of the installed ba= se is misconfigured and has obsolete configurations. A non trivial fraction= of firewalls being brought under management turn out to be configured for = pass through of all protocols (The $250,000 ethernet cable configuration).<= /div>


I think we need to have a document that = sets out what the specific issues with these proxies are and we need to dec= ide which to support and which to not support.

SSL is not 'designed' to prevent MITM attacks, the whole PURPOSE of= SSL is to prevent MITM attacks. So I think we need to decide which issues = to support and which not to support.


I strongly suspect that the MITM proxy ssl capabilities are underspeci= fied to say the least. They were originally a feature that was thrown into = Netscape Navigator for expediency with zero discussion outside the company.=

I know that it is the type of feature that IETF types h= ave traditionally preferred to ignore. I certainly have felt no inclination= to look at that type of feature. It was put in the specs against my protes= ts as a fait accompli.

But that is a pretty bad situation from a security poin= t of view and there is a huge risk here of creating a massive hole in SSL o= f Kaminsky proportions if people decide that they can simply follow the sam= e approach because they have a particular view of what CAs do and they can = remove controls that they personally don't think matter.

I think we are going to either have to decide that this= scheme is not going to support SSL proxies at all or it is going to have t= o have a first class mechanism designed to support the SSL proxy use case.= =A0


Handwaving arguments about security prot= ocols are a recipe for disaster. In particular the argument that 'its o= k we already do this without disaster' has led to a number of notorious= security protocol failures.



=A0
--
Web= site: http://hallambaker.com/
--90e6ba6e866887386f049c7ac26b-- 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 0554C3A6DB3 for ; Thu, 17 Feb 2011 00:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 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 cEenxkE8Nhtg for ; Thu, 17 Feb 2011 00:55:26 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id BB2973A6CDE for ; Thu, 17 Feb 2011 00:55:25 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 05EF6C9433; Thu, 17 Feb 2011 08:55:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 75939216C3D; Thu, 17 Feb 2011 08:55:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DFC8AA46F9E; Thu, 17 Feb 2011 19:55:36 +1100 (EST) To: "Richard L. Barnes" From: Mark Andrews References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <20110216232044.0CECAA3FFB9@drugs.dv.isc.org> <0A9E7F7C-DD32-403C-A207-A0FE54D7B3EA@bbn.com> In-reply-to: Your message of "Thu, 17 Feb 2011 00:45:16 CDT." <0A9E7F7C-DD32-403C-A207-A0FE54D7B3EA@bbn.com> Date: Thu, 17 Feb 2011 19:55:36 +1100 Message-Id: <20110217085536.DFC8AA46F9E@drugs.dv.isc.org> Cc: Adam Langley , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 17 Feb 2011 08:55:27 -0000 In message <0A9E7F7C-DD32-403C-A207-A0FE54D7B3EA@bbn.com>, "Richard L. Barnes" writes: > Actually, I don't think it would be that hard to spoof the root zone, = > assuming your clients are provisioned with an alternate TA (i.e., the = > one you hold). =20 > > In the worst case, you have to re-sign the root zone, then create keys = > and signatures down the hierarchy to the record you want to spoof. =20 > > My DNSSEC foo is a little hazy on this one, but I wonder if you could = > even just return signed records as if they came directly out of the = > root. I seem to recall a certain root node doing something like this = > (returning A records, but no DNSSEC) last March or so. > > I'm not saying this is a *good* idea, but technically, it does work. = > I'm not that hot on SSL middleboxes either, but they need to be handled = > properly. > > --Richard You would have to sign every response and remove all trace of zone cuts to use normal validators internally. This assumes that you want to intercept all communications. If you just want to intercept some then you would still need to make those paths appear to be in the root zone. You could delegate away the paths you don't care about. > On Feb 16, 2011, at 6:20 PM, Mark Andrews wrote: > > >=20 > > In message , "Richard L. = > Barnes"=20 > > writes: > >> Transparent SSL proxies really are a problem from a security = > perspective. It > >> 's always a bad idea to design protocols that accommodate them = > without client > >> configuration -- because then you end up accommodating malicious MitM = > entiti > >> es as well. > >>=20 > >> What is worth thinking through is what sort of client configuration = > changes a > >> re necessary to accommodate transparent SSL proxies. In the current, = > X.509-b > >> ased environment, the critical change is to add a trust anchor to the = > client=20 > >> SSL verification system. This enables the proxy (holding the private = > key tha > >> t goes with the TA) to issue certs for sites that clients visit. > >>=20 > >> The corresponding process for DANE would just change X.509 to DNSSEC: = > Clients > >> would have an additional DNSSEC TA (i.e., in addition to the root), = > so that=20 > >> the proxy could assert trust chains that bind keys under its control = > to names > >> that clients are interested in. > >>=20 > >> I wasn't kidding when I said that proxies would need to MitM the DNS = > traffic=20 > >> as well :) > >>=20 > >> --Richard > >=20 > > Adding a alternate root trust anchor won't work. The root key only > > signs the root zone. 99.999% percent of spoofed anwers won't be > > from the root zone. > >=20 > > It needs to be a key that is use as a alternative verification > > source or you need to trust "AD" and not validate yourself. > >=20 > > Mark > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org 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 3F3993A6CDB for ; Wed, 16 Feb 2011 21:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 k+oVMJxZwXMw for ; Wed, 16 Feb 2011 21:44:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0C4CB3A6CD1 for ; Wed, 16 Feb 2011 21:44:55 -0800 (PST) Received: from [128.89.253.76] (port=49494 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ppwg6-000A6j-Qx; Thu, 17 Feb 2011 00:45:23 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <20110216232044.0CECAA3FFB9@drugs.dv.isc.org> Date: Thu, 17 Feb 2011 00:45:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0A9E7F7C-DD32-403C-A207-A0FE54D7B3EA@bbn.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <20110216232044.0CECAA3FFB9@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 17 Feb 2011 05:44:56 -0000 Actually, I don't think it would be that hard to spoof the root zone, = assuming your clients are provisioned with an alternate TA (i.e., the = one you hold). =20 In the worst case, you have to re-sign the root zone, then create keys = and signatures down the hierarchy to the record you want to spoof. =20 My DNSSEC foo is a little hazy on this one, but I wonder if you could = even just return signed records as if they came directly out of the = root. I seem to recall a certain root node doing something like this = (returning A records, but no DNSSEC) last March or so. I'm not saying this is a *good* idea, but technically, it does work. = I'm not that hot on SSL middleboxes either, but they need to be handled = properly. --Richard On Feb 16, 2011, at 6:20 PM, Mark Andrews wrote: >=20 > In message , "Richard L. = Barnes"=20 > writes: >> Transparent SSL proxies really are a problem from a security = perspective. It >> 's always a bad idea to design protocols that accommodate them = without client >> configuration -- because then you end up accommodating malicious MitM = entiti >> es as well. >>=20 >> What is worth thinking through is what sort of client configuration = changes a >> re necessary to accommodate transparent SSL proxies. In the current, = X.509-b >> ased environment, the critical change is to add a trust anchor to the = client=20 >> SSL verification system. This enables the proxy (holding the private = key tha >> t goes with the TA) to issue certs for sites that clients visit. >>=20 >> The corresponding process for DANE would just change X.509 to DNSSEC: = Clients >> would have an additional DNSSEC TA (i.e., in addition to the root), = so that=20 >> the proxy could assert trust chains that bind keys under its control = to names >> that clients are interested in. >>=20 >> I wasn't kidding when I said that proxies would need to MitM the DNS = traffic=20 >> as well :) >>=20 >> --Richard >=20 > Adding a alternate root trust anchor won't work. The root key only > signs the root zone. 99.999% percent of spoofed anwers won't be > from the root zone. >=20 > It needs to be a key that is use as a alternative verification > source or you need to trust "AD" and not validate yourself. >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org 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 DFB4D3A6C2F for ; Wed, 16 Feb 2011 19:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 fGdbrjXo5X7l for ; Wed, 16 Feb 2011 19:31:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 251BD3A6C21 for ; Wed, 16 Feb 2011 19:31:45 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:59257 helo=[192.168.1.10]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpubG-000C8c-Pz; Wed, 16 Feb 2011 22:32:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <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> <5EE049BA3C6538409BBE6F1760F328ABEB1A2F1A36@DEN-MEXMS-001.corp.ebay.com> Date: Wed, 16 Feb 2011 19:23:06 -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, 17 Feb 2011 03:31:46 -0000 Sorry for the very tardy reply. > > -----Original Message----- >> 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.. Thanks for the clarification of the TLS problem generated by virtual hosting, used with older versions of WIndows. In DANE there is no issuance cost for having a lot of SANs in the server cert, or for changing the cert to add or remove SANs, but I admit that it could get big if there are a lot of sites hosted on the same machine. If there are no attacks that arise if we ignore the name in a cert, then we could do so as a way of avoiding this problem, and so I understand your motivation. However, if the goal of DANE is to provide a cert to be used as a TA, to verify an EE cert for a web site, this is a problem, as it would interfere with cert chaining from the TA to the EE cert. So we do have some tradeoffs to consider. 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 8CE083A6CE4 for ; Wed, 16 Feb 2011 15:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[AWL=0.157, 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 a1OHAflVO6SV for ; Wed, 16 Feb 2011 15:36:46 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id 99F173A6AB9 for ; Wed, 16 Feb 2011 15:36:46 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p1GNarCA011216; Wed, 16 Feb 2011 15:36:53 -0800 Message-Id: <201102162336.p1GNarCA011216@new.toad.com> To: Mark Andrews In-reply-to: <20110216232044.0CECAA3FFB9@drugs.dv.isc.org> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <20110216232044.0CECAA3FFB9@drugs.dv.isc.org> Comments: In-reply-to Mark Andrews message dated "Thu, 17 Feb 2011 10:20:43 +1100." Date: Wed, 16 Feb 2011 15:36:53 -0800 From: John Gilmore Cc: Adam Langley , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 23:36:47 -0000 > Transparent SSL proxies really are a problem from a security perspective. If DANE anchoring of SSL is properly implemented, then anyone who sticks a MITM (of any sort) in the middle is going to have it detected and rejected. No communication. Even if it's corporate policy to watch everything in the clear in some great-wall-of-Intel or whatever. When that little LOCK icon turns on, you'll damn well know that you're talking to the server of the domain name you typed - and nobody else. It could only come from IETF...security protocols that actually work, despite corporate policies against actual security! John 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 2F0993A6DDE for ; Wed, 16 Feb 2011 15:20:30 -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 9c6EB48Il3zS for ; Wed, 16 Feb 2011 15:20:28 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id EED463A6DDF for ; Wed, 16 Feb 2011 15:20:27 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id CE537C9421; Wed, 16 Feb 2011 23:20:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4663F216C22; Wed, 16 Feb 2011 23:20:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0CECAA3FFB9; Thu, 17 Feb 2011 10:20:44 +1100 (EST) To: "Richard L. Barnes" From: Mark Andrews References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> In-reply-to: Your message of "Wed, 16 Feb 2011 11:50:15 CDT." Date: Thu, 17 Feb 2011 10:20:43 +1100 Message-Id: <20110216232044.0CECAA3FFB9@drugs.dv.isc.org> Cc: Adam Langley , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 23:20:30 -0000 In message , "Richard L. Barnes" writes: > Transparent SSL proxies really are a problem from a security perspective. It > 's always a bad idea to design protocols that accommodate them without client > configuration -- because then you end up accommodating malicious MitM entiti > es as well. > > What is worth thinking through is what sort of client configuration changes a > re necessary to accommodate transparent SSL proxies. In the current, X.509-b > ased environment, the critical change is to add a trust anchor to the client > SSL verification system. This enables the proxy (holding the private key tha > t goes with the TA) to issue certs for sites that clients visit. > > The corresponding process for DANE would just change X.509 to DNSSEC: Clients > would have an additional DNSSEC TA (i.e., in addition to the root), so that > the proxy could assert trust chains that bind keys under its control to names > that clients are interested in. > > I wasn't kidding when I said that proxies would need to MitM the DNS traffic > as well :) > > --Richard Adding a alternate root trust anchor won't work. The root key only signs the root zone. 99.999% percent of spoofed anwers won't be from the root zone. It needs to be a key that is use as a alternative verification source or you need to trust "AD" and not validate yourself. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org 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 3F6FB3A6D52 for ; Wed, 16 Feb 2011 13:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, 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 qx1k7HJMEsUL for ; Wed, 16 Feb 2011 13:01:29 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 1EE033A6D2A for ; Wed, 16 Feb 2011 13:01:28 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1GL1vQw028365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 22:01:57 +0100 (MET) From: Martin Rex Message-Id: <201102162101.p1GL1uae001327@fs4113.wdf.sap.corp> To: ajs@shinkuro.com (Andrew Sullivan) Date: Wed, 16 Feb 2011 22:01:56 +0100 (MET) In-Reply-To: <20110216193443.GB27859@shinkuro.com> from "Andrew Sullivan" at Feb 16, 11 02:34:43 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] Bootstrapping Dane Adoption 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, 16 Feb 2011 21:01:30 -0000 Andrew Sullivan wrote: > > On Wed, Feb 16, 2011 at 11:50:15AM -0500, Richard L. Barnes wrote: > > > > The corresponding process for DANE would just change X.509 to > > DNSSEC: Clients would have an additional DNSSEC TA (i.e., in > > addition to the root), so that the proxy could assert trust chains > > that bind keys under its control to names that clients are > > interested in. > > > > I wasn't kidding when I said that proxies would need to MitM the DNS > > traffic as well :) > > You're suggesting that the client uses an intermediate resolver for > which it has a TA configured. The intermediate resolver, when > responding to {all|some class of} queries, intercepts the answers, > creates new RRSIGs and DS records and so on, and synthesizes those as > part of the answer returned to the client? I guess if you reproduce > the whole chain of trust all the way down, it could work. I'd want to > work through it completely. But do I have the idea right? One possible hack for a HTTP CONNECT proxy would be to perform all DANE-relevant DNSSEC lookups for the given URL and put the responses in their entire beauty into Mime-Headers of the HTTP CONNECT response... -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 1718F3A6DE8 for ; Wed, 16 Feb 2011 12:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.221 X-Spam-Level: X-Spam-Status: No, score=-10.221 tagged_above=-999 required=5 tests=[AWL=0.028, 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 hGTjunZl06W6 for ; Wed, 16 Feb 2011 12:34:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 002D23A6D73 for ; Wed, 16 Feb 2011 12:34:24 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1GKYqaB021705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 21:34:52 +0100 (MET) From: Martin Rex Message-Id: <201102162034.p1GKYqld029682@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Wed, 16 Feb 2011 21:34:52 +0100 (MET) In-Reply-To: from "Paul Wouters" at Feb 16, 11 11:39:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@imperialviolet.org, keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 20:34:26 -0000 Paul Wouters wrote: > > > > In order to get off the ground I feel that it's important that clients > > not be broken so that sites don't feel pressure not to publish DNS > > cert information. > > You could disable DANE lookups if a proxy for SSL is configured? > > I guess that leaves transparent SSL proxies still as a problem. Transparent SSL proxies ought not to be a problem, since they do not affect DNS lookups at all. But _configured_ SSL proxies may be an indicator that a browser itself lives in a seperate DNS universe (not that uncommon in sensibly firewalled company networks), so that no DNS or DNSSEC records from the internet are accessible for the browser. There used to be a number of broken clients, though being HTTP or HTTPS proxy capable, were still trying to resolve hostnames locally even when connecting through the proxy and failed badly if the DNS lookup failed. It appeared to be common breakage in Java applets a decade ago, but it also affected the OpenSUSE 11.1 network installer. A common workaround for such breakage is to add the offending hostname with a random ip to the local hosts file and retry... -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 350193A6D3D for ; Wed, 16 Feb 2011 11:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvRgF4WRvMDu for ; Wed, 16 Feb 2011 11:34:18 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 230553A69A6 for ; Wed, 16 Feb 2011 11:34:17 -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 6CECB1ECB420 for ; Wed, 16 Feb 2011 19:34:45 +0000 (UTC) Date: Wed, 16 Feb 2011 14:34:43 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110216193443.GB27859@shinkuro.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> 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] Bootstrapping Dane Adoption 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, 16 Feb 2011 19:34:19 -0000 On Wed, Feb 16, 2011 at 11:50:15AM -0500, Richard L. Barnes wrote: > > The corresponding process for DANE would just change X.509 to > DNSSEC: Clients would have an additional DNSSEC TA (i.e., in > addition to the root), so that the proxy could assert trust chains > that bind keys under its control to names that clients are > interested in. > > I wasn't kidding when I said that proxies would need to MitM the DNS > traffic as well :) You're suggesting that the client uses an intermediate resolver for which it has a TA configured. The intermediate resolver, when responding to {all|some class of} queries, intercepts the answers, creates new RRSIGs and DS records and so on, and synthesizes those as part of the answer returned to the client? I guess if you reproduce the whole chain of trust all the way down, it could work. I'd want to work through it completely. But do I have the idea right? 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 3C2FE3A6D5F for ; Wed, 16 Feb 2011 11:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.547 X-Spam-Level: X-Spam-Status: No, score=-10.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 38UkFIEWPeue for ; Wed, 16 Feb 2011 11:23:36 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 9A3963A6D5E for ; Wed, 16 Feb 2011 11:23:35 -0800 (PST) X-CheckPoint: {4D5C2453-20002-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1GJO3cO031704; Wed, 16 Feb 2011 21:24:03 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 16 Feb 2011 21:24:03 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 16 Feb 2011 21:24:03 +0200 From: Yoav Nir To: Adam Langley Date: Wed, 16 Feb 2011 21:24:02 +0200 Thread-Topic: [keyassure] Bootstrapping Dane Adoption Thread-Index: AcvODxGs35aKEAiSTxWJ26yU+opBtA== Message-ID: <67AE67DA-4EDD-48AF-BF15-2F86DD63EA68@checkpoint.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "keyassure@ietf.org" Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 19:23:38 -0000 On Feb 16, 2011, at 6:48 PM, Adam Langley wrote: > On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters wrote= : >> But it is not the vendors that would need to make that change? It's just= the >> browser people and the entity deploying SSL proxies? >=20 > Ah, I understand what you are suggesting. Indeed you could do that > with just action by the proxy admins. However, I still feel that those > people will be very slow in changing. I disagree. While my company doesn't make SSL proxies, we do make firewalls= , and it's always up to us to accommodate whatever browsers customers are u= sing. 10 years ago it turned out that our firewall was blocking Netscape br= owsers on Mac OS 9.2. We had to change our firewall. So if some new version of a popular browser starts getting blocked behind t= he SSL proxy, then the proxy vendor will be pressured to fix it. It's a com= petitive market, and you don't get to say, "oh, we don't support Chrome 11.= Maybe we will next year" 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 351CF3A6D33 for ; Wed, 16 Feb 2011 11:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.54 X-Spam-Level: X-Spam-Status: No, score=-10.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, 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 I+tTTds6zmuU for ; Wed, 16 Feb 2011 11:18:59 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E6EF63A6D4C for ; Wed, 16 Feb 2011 11:18:58 -0800 (PST) X-CheckPoint: {4D5C233F-20001-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p1GJJJfW031015; Wed, 16 Feb 2011 21:19:22 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 16 Feb 2011 21:19:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 16 Feb 2011 21:19:20 +0200 From: Yoav Nir To: Paul Wouters Date: Wed, 16 Feb 2011 21:19:18 +0200 Thread-Topic: [keyassure] Bootstrapping Dane Adoption Thread-Index: AcvODmjfMM6L2hXFRN6ghksGXf+Cpw== Message-ID: <42C8B298-FC9F-4981-BEB3-8DAF924EE003@checkpoint.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Langley , "keyassure@ietf.org" Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 19:19:00 -0000 On Feb 16, 2011, at 8:51 PM, Paul Wouters wrote: > On Wed, 16 Feb 2011, Adam Langley wrote: >=20 >> I don't believe that it does. What I'm suggesting is this: >>=20 >> The set of root CAs shipped by default for Firefox and Microsoft is >> known. We know that these aren't MITM certificates. So, if we get a CA >> certificate rooted at one of those certs, and information from the DNS >> which contradicts that, we can reject the certificate. This means that >> you can't fool a CA into issuing a certificate and attack users. >>=20 >> However, if a certificate validates, but isn't rooted at a standard >> root, then it's been signed by a root that has been manually added. In >> this case, there's a good chance that it's a MITM proxy and we skip >> the DNS check. Thus the only roots which can override DNS information >> are those which have been manually added. >=20 > Ahh I see. I did not realise the browsers kept a difference between manua= lly > added and shipped per default. This would work then, except if the MITM > proxy is signed with public CA shipped with a browser. Do people not do t= hat? > I thought perhaps MITM proxies did this to already reduce popups. No, the commercial CAs don't sell you certificates with Basic Constraints s= et to true. the MitM proxies have their own CA certificates, and the user (= or her administrator) have to install the MitM certificate to get it to wor= k. That way they know that they can be attacked. It's also news to me that browsers differentiate between TAs that were ship= ped as opposed to TAs that were added.= 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 A66853A6EF6 for ; Wed, 16 Feb 2011 10:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YAV+WkwSZkQb for ; Wed, 16 Feb 2011 10:51:08 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id BF8FC3A6E25 for ; Wed, 16 Feb 2011 10:51: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 DD8B1C57C; Wed, 16 Feb 2011 13:51:35 -0500 (EST) Date: Wed, 16 Feb 2011 13:51:35 -0500 (EST) From: Paul Wouters To: Adam Langley In-Reply-To: Message-ID: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.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] Bootstrapping Dane Adoption 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, 16 Feb 2011 18:51:09 -0000 On Wed, 16 Feb 2011, Adam Langley wrote: > I don't believe that it does. What I'm suggesting is this: > > The set of root CAs shipped by default for Firefox and Microsoft is > known. We know that these aren't MITM certificates. So, if we get a CA > certificate rooted at one of those certs, and information from the DNS > which contradicts that, we can reject the certificate. This means that > you can't fool a CA into issuing a certificate and attack users. > > However, if a certificate validates, but isn't rooted at a standard > root, then it's been signed by a root that has been manually added. In > this case, there's a good chance that it's a MITM proxy and we skip > the DNS check. Thus the only roots which can override DNS information > are those which have been manually added. Ahh I see. I did not realise the browsers kept a difference between manually added and shipped per default. This would work then, except if the MITM proxy is signed with public CA shipped with a browser. Do people not do that? I thought perhaps MITM proxies did this to already reduce popups. 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 699E33A6D27 for ; Wed, 16 Feb 2011 10:05:36 -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 VctXfwfqqgLi for ; Wed, 16 Feb 2011 10:05:35 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 51D813A6A57 for ; Wed, 16 Feb 2011 10:05:35 -0800 (PST) Received: by iwc10 with SMTP id 10so1691114iwc.31 for ; Wed, 16 Feb 2011 10:05:53 -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=X/qZzJPuLQ5VOplEH06s5Ju9vs8EtGRHkjzZoGRN+PA=; b=VUF/55M2NYIhBn8R0ErmQD1eW1zO3Pti26GUzlS+xE6maOoCoD82c2tOcO2lTfOn+Q 00UPqiV3TfHi5v2ajsjt7/EY/SMoBDrqXXfhjgPPV8vBEF5KJBqhkAzFrlPRaDL89ZpL b4U/lAdnWMw3ZrDE80P1759HayZ7cR+MyUsio= 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=ZrTQNhFrWVjq4iInIrwqx6SuDShRkKbkdt9PsFDg86fZkS0Ay9Y6QHp7axLvHN/ggu oOu3bcW7M+QblvQQsGVu4mcmlvh3j0yQY8bvbKeLJu5XZYxwjApYl/BoUFe63UW9FOoT KyPaiI0jGA/+V5kXnJx1lJyxdn0M0k9p03Lhc= MIME-Version: 1.0 Received: by 10.42.218.137 with SMTP id hq9mr1336030icb.481.1297879553335; Wed, 16 Feb 2011 10:05:53 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.222.130 with HTTP; Wed, 16 Feb 2011 10:05:53 -0800 (PST) In-Reply-To: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> Date: Wed, 16 Feb 2011 13:05:53 -0500 X-Google-Sender-Auth: Xu_lS4p62o7eCxioF-eTayrTEOI Message-ID: From: Adam Langley To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 18:05:36 -0000 On Wed, Feb 16, 2011 at 12:31 PM, Paul Wouters wrote: > This reduces DANE back to the case where every CA on the planet can MITM. > That would not be good. At least make it a config option that can be > changed, and then we can argue about when is the right time to switch it. I don't believe that it does. What I'm suggesting is this: The set of root CAs shipped by default for Firefox and Microsoft is known. We know that these aren't MITM certificates. So, if we get a CA certificate rooted at one of those certs, and information from the DNS which contradicts that, we can reject the certificate. This means that you can't fool a CA into issuing a certificate and attack users. However, if a certificate validates, but isn't rooted at a standard root, then it's been signed by a root that has been manually added. In this case, there's a good chance that it's a MITM proxy and we skip the DNS check. Thus the only roots which can override DNS information are those which have been manually added. It will fail if there are MITM proxies that use intermediate CA certificates that root at a standard root. I very much hope, for many reasons, that such a proxy doesn't exist. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 75CEA3A6EE8 for ; Wed, 16 Feb 2011 10:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ZKsOq1--fSKp for ; Wed, 16 Feb 2011 10:01:34 -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 4F0C33A6D27 for ; Wed, 16 Feb 2011 10:01:34 -0800 (PST) Received: by gyd12 with SMTP id 12so791423gyd.31 for ; Wed, 16 Feb 2011 10:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=4ck1matOeSLLZnvQnl2swYFxT/tjVl7sT2MxoSerkR0=; b=aFCDTpgCUDgkrFMclKd9hMSB4dQQNo/7ASHBIIXffjaNpBQofZstlux5g9NrUogHMJ hU613vb+yZ/mURFrYYPocmCCbARqLfqCv3mjj+uMIQuk2wT04ajuFCCVlyBpV3Se7z1r BAuSk9znwVzBE9E9kiJWHSDvm85FiTc9F2Bas= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=qzBIS94FbvVSbQSNDle98zvWZUUqFfkR+fqIdeFW8G4DBUFYOwBwZ7m27IiwSeB2yd hO9gIGhRaw9hq/s1eLW/BH3cEj3P0aWGcBzklKpLbo4YiXxX4nlrsGEZsHOXffaCjOXD 8tcb+T+TkZWvYcPz/aB4TXhSFrRSRWxDx0VzI= Received: by 10.150.135.18 with SMTP id i18mr1093456ybd.278.1297879322090; Wed, 16 Feb 2011 10:02:02 -0800 (PST) Received: from [10.31.190.225] ([166.205.139.98]) by mx.google.com with ESMTPS id w24sm3402906ybk.21.2011.02.16.10.01.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Feb 2011 10:02:00 -0800 (PST) References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> In-Reply-To: <20110214124617.GA31136@LK-Perkele-VI.localdomain> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9FD85E34-EDB8-4901-915B-E7560C87954A@gmail.com> X-Mailer: iPad Mail (8C148) From: Phillip Hallam-Baker Date: Wed, 16 Feb 2011 10:01:49 -0800 To: Ilari Liusvaara Cc: "keyassure@ietf.org" Subject: Re: [keyassure] publishing the public key 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, 16 Feb 2011 18:01:35 -0000 A much better saving is to use the tls option that allows for fast rekey by m= eans of a kerberos like ticket stored on the client side. That approach means the client does one key exchange and that is leveraged o= ver multiple http sessions. The cert is only a kb, self signed certs are less and your main saving would= be not having the signature. Looking at the tls key exchange, what matters i= s packets, not really bytes. I dont think you will find certs vs keys saves a= packet. Sent from my iPad On Feb 14, 2011, at 4:46, Ilari Liusvaara wrot= e: > On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote: >> Hi, >>=20 >> In draft-dane-04 [1] one can currently only publish either a signature >> or a certificate in the DNS. That is the only allowed formats of the >> resource record are as specified in section 2.2 >>=20 >> 1 -- Hash of an end-entity certificate >> 2 -- Full end-entity certificate in DER encoding >> 3 -- Hash of an certification authority's certificate >> 4 -- Full certification authority's certificate in DER encoding >>=20 >> Why not publish the only piece of the certificate that is important in >> public key cryptography: the public key. ( This is what WebID does >> currently ) This should be shorter than the certificate, and though it >> will be longer than the signature, it will be a lot more useful, tying >> the publisher much less to a particular serialisation format. So you >> reduce the PGP/X509 disagreements. >=20 > Unfortunately TLS requires sending the full certificate. Yes, one could > define a new certificate type that contained just the public key, but > that would require a IETF consensus (RFC through TLS working > group[1]). >=20 > Then one would define new DANE ceritifcate type (3 [2] or 5/6) to > match that. >=20 > >=20 > I don't think that would be possible to use without new certificate > type either. >=20 > As for bandwidth, sure it would save some. One can send well-secured > key in roughly 80 bytes total (including CertificateType extension). > Modern X.509 certs are far larger[3], even if restricted to bare > minimum fields. >=20 > As for what this would be useful for: If the raw key format would > be easily parsed, it would save lots of tricky ASN.1 and X.509 > parsing (yes, there are libraries for that) >=20 >=20 >=20 >=20 > [1] Not entierely accurate, it is RFC approved by IESG (and they'll > consult TLS WG). >=20 > [2] Since those 4 types could be collapsed to 2 (2 of those require > second byte to be zero and 2 require nonzero second byte) >=20 > [3] There's also subtle performance issue there. Those certificates > can be so large that TCP windows get overflowed. As consequence, > either one has to break TCP spec (many sites do this) or suffer > a latency hit. >=20 > -Ilari > _______________________________________________ > 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 782EE3A6EB0 for ; Wed, 16 Feb 2011 09:31:24 -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 CkDNaU2e9h8B for ; Wed, 16 Feb 2011 09:31:23 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 804F23A6EA9 for ; Wed, 16 Feb 2011 09:31:23 -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 D7210C590; Wed, 16 Feb 2011 12:31:50 -0500 (EST) Date: Wed, 16 Feb 2011 12:31:50 -0500 (EST) From: Paul Wouters To: Adam Langley In-Reply-To: Message-ID: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.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] Bootstrapping Dane Adoption 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, 16 Feb 2011 17:31:24 -0000 On Wed, 16 Feb 2011, Adam Langley wrote: > For transparent proxies I suspect that we'll need to skip them when > the certificate is correctly signed by a root which has been added to > the system. This reduces DANE back to the case where every CA on the planet can MITM. That would not be good. At least make it a config option that can be changed, and then we can argue about when is the right time to switch it. 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 E6FFC3A6CD0 for ; Wed, 16 Feb 2011 08:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 HNbKVnMv+tEU for ; Wed, 16 Feb 2011 08:51:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 977433A6CB0 for ; Wed, 16 Feb 2011 08:51:00 -0800 (PST) Received: from [128.89.253.126] (port=63137 helo=[10.45.1.166]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpkbA-0002kY-9z; Wed, 16 Feb 2011 11:51:28 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 16 Feb 2011 11:51:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 16:51:03 -0000 Of course, Adam's idea to allow locally-configured X.509 TAs to override = DANE would work as well. That's just forcing the client back into the = old world, which is a good thing in this case. --Richard On Feb 16, 2011, at 11:50 AM, Richard L. Barnes wrote: > Transparent SSL proxies really are a problem from a security = perspective. It's always a bad idea to design protocols that = accommodate them without client configuration -- because then you end up = accommodating malicious MitM entities as well. >=20 > What is worth thinking through is what sort of client configuration = changes are necessary to accommodate transparent SSL proxies. In the = current, X.509-based environment, the critical change is to add a trust = anchor to the client SSL verification system. This enables the proxy = (holding the private key that goes with the TA) to issue certs for sites = that clients visit. >=20 > The corresponding process for DANE would just change X.509 to DNSSEC: = Clients would have an additional DNSSEC TA (i.e., in addition to the = root), so that the proxy could assert trust chains that bind keys under = its control to names that clients are interested in. >=20 > I wasn't kidding when I said that proxies would need to MitM the DNS = traffic as well :) >=20 > --Richard >=20 >=20 >=20 > On Feb 16, 2011, at 11:39 AM, Paul Wouters wrote: >=20 >> On Wed, 16 Feb 2011, Adam Langley wrote: >>=20 >>> On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters = wrote: >>>> Couldn't the MITM SSL proxy register their cert in the DNS entry = associated >>>> with their name or reverse ? That way, it becomes a "DANE = certified" MITM, >>>> so 1) if the user configured a MITM proxy and 2) the DANE cert = matches, then >>>> don't warn the user... >>>>=20 >>>> Now people with a MITM SSL proxy are protected against other MITM = entities. >>>=20 >>> Pressure can be applied to the vendors to make changes but, in my >>> experience, they move very slowly and customer update firmware even >>> more slowly. >>=20 >> But it is not the vendors that would need to make that change? It's = just the >> browser people and the entity deploying SSL proxies? >>=20 >>> In order to get off the ground I feel that it's important that = clients >>> not be broken so that sites don't feel pressure not to publish DNS >>> cert information. >>=20 >> You could disable DANE lookups if a proxy for SSL is configured? >>=20 >> I guess that leaves transparent SSL proxies still as a problem. >>=20 >> Paul >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >=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 A82653A6CB0 for ; Wed, 16 Feb 2011 08:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 AfHVVa8J+neT for ; Wed, 16 Feb 2011 08:49:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9E7FA3A6B7C for ; Wed, 16 Feb 2011 08:49:50 -0800 (PST) Received: from [128.89.253.126] (port=63134 helo=[10.45.1.166]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ppka2-0002jK-AO; Wed, 16 Feb 2011 11:50: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: Wed, 16 Feb 2011 11:50:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: Adam Langley , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 16:49:51 -0000 Transparent SSL proxies really are a problem from a security = perspective. It's always a bad idea to design protocols that = accommodate them without client configuration -- because then you end up = accommodating malicious MitM entities as well. What is worth thinking through is what sort of client configuration = changes are necessary to accommodate transparent SSL proxies. In the = current, X.509-based environment, the critical change is to add a trust = anchor to the client SSL verification system. This enables the proxy = (holding the private key that goes with the TA) to issue certs for sites = that clients visit. The corresponding process for DANE would just change X.509 to DNSSEC: = Clients would have an additional DNSSEC TA (i.e., in addition to the = root), so that the proxy could assert trust chains that bind keys under = its control to names that clients are interested in. I wasn't kidding when I said that proxies would need to MitM the DNS = traffic as well :) --Richard On Feb 16, 2011, at 11:39 AM, Paul Wouters wrote: > On Wed, 16 Feb 2011, Adam Langley wrote: >=20 >> On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters = wrote: >>> Couldn't the MITM SSL proxy register their cert in the DNS entry = associated >>> with their name or reverse ? That way, it becomes a "DANE certified" = MITM, >>> so 1) if the user configured a MITM proxy and 2) the DANE cert = matches, then >>> don't warn the user... >>>=20 >>> Now people with a MITM SSL proxy are protected against other MITM = entities. >>=20 >> Pressure can be applied to the vendors to make changes but, in my >> experience, they move very slowly and customer update firmware even >> more slowly. >=20 > But it is not the vendors that would need to make that change? It's = just the > browser people and the entity deploying SSL proxies? >=20 >> In order to get off the ground I feel that it's important that = clients >> not be broken so that sites don't feel pressure not to publish DNS >> cert information. >=20 > You could disable DANE lookups if a proxy for SSL is configured? >=20 > I guess that leaves transparent SSL proxies still as a problem. >=20 > Paul > _______________________________________________ > 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 B621B3A6CB0 for ; Wed, 16 Feb 2011 08:48:01 -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 kQbIHneIVm1L for ; Wed, 16 Feb 2011 08:48:00 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 94B913A6B7C for ; Wed, 16 Feb 2011 08:48:00 -0800 (PST) Received: by iwc10 with SMTP id 10so1612147iwc.31 for ; Wed, 16 Feb 2011 08:48:29 -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=vptvq6U/M0GldGss7fmVkYUR1xZuXxY4e7D3cmoEzF0=; b=H4nz/aj0gFUM7EJl5thG4zg1/SVpi77JFYcbLfO0WSByuFePIEj8Ex3j7McXaWLPfd At4FpFIC0GXu4R/XYzZz6ccx7EXSc/NXGIl0B8FNU3uNzo920VIdlE5tUvyCqX8SkPgG dAGDVMLvP6XrC9qrwK57UsPLC30WeP8Kjte8k= 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=FKYD5dIEZ2E5xyIyB7qNyFbxd9+06n4S8aoOhkQwDBZdo7eywDmyRBFwJ5zYKEf+KY jylpjavE5RcO3o3R6tKxW9ZiWSZAzB+eKX+kaE4PXElEtwX1Nwp+EgY+PnlpC6O+Dijp LtWSJ+yBh5bwuNX9F1vLjRayibbUQ5JO7aL+4= MIME-Version: 1.0 Received: by 10.42.218.137 with SMTP id hq9mr1192992icb.481.1297874909049; Wed, 16 Feb 2011 08:48:29 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.222.130 with HTTP; Wed, 16 Feb 2011 08:48:29 -0800 (PST) In-Reply-To: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> Date: Wed, 16 Feb 2011 11:48:29 -0500 X-Google-Sender-Auth: zRbp4pd13CZw8aFhgdQi9KZkL6c Message-ID: From: Adam Langley To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 16:48:01 -0000 On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters wrote: > But it is not the vendors that would need to make that change? It's just the > browser people and the entity deploying SSL proxies? Ah, I understand what you are suggesting. Indeed you could do that with just action by the proxy admins. However, I still feel that those people will be very slow in changing. > You could disable DANE lookups if a proxy for SSL is configured? > > I guess that leaves transparent SSL proxies still as a problem. Skipping additional checks when a proxy is configured is a good idea. For transparent proxies I suspect that we'll need to skip them when the certificate is correctly signed by a root which has been added to the system. But, in the end, we'll have to try our best and discover what works via bug reports. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 6BA913A6E80 for ; Wed, 16 Feb 2011 08:38:35 -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 rXnNPo0I9wa9 for ; Wed, 16 Feb 2011 08:38:34 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 793293A6E82 for ; Wed, 16 Feb 2011 08:38:34 -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 4AEF1C57C; Wed, 16 Feb 2011 11:39:02 -0500 (EST) Date: Wed, 16 Feb 2011 11:39:01 -0500 (EST) From: Paul Wouters To: Adam Langley In-Reply-To: Message-ID: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.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] Bootstrapping Dane Adoption 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, 16 Feb 2011 16:38:35 -0000 On Wed, 16 Feb 2011, Adam Langley wrote: > On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters wrote: >> Couldn't the MITM SSL proxy register their cert in the DNS entry associated >> with their name or reverse ? That way, it becomes a "DANE certified" MITM, >> so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then >> don't warn the user... >> >> Now people with a MITM SSL proxy are protected against other MITM entities. > > Pressure can be applied to the vendors to make changes but, in my > experience, they move very slowly and customer update firmware even > more slowly. But it is not the vendors that would need to make that change? It's just the browser people and the entity deploying SSL proxies? > In order to get off the ground I feel that it's important that clients > not be broken so that sites don't feel pressure not to publish DNS > cert information. You could disable DANE lookups if a proxy for SSL is configured? I guess that leaves transparent SSL proxies still as 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 55B743A6E6B for ; Wed, 16 Feb 2011 08:28:57 -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 P2r0CwwyyUTd for ; Wed, 16 Feb 2011 08:28:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9CF5B3A6E66 for ; Wed, 16 Feb 2011 08:28:55 -0800 (PST) Received: by iym1 with SMTP id 1so1469421iym.31 for ; Wed, 16 Feb 2011 08:29:24 -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=gxpRWl2MlIBJyhpsr9W5EAsE1o/0TrBWzANM14LWGLA=; b=ZIvqi+uf4DZqYmpHtc6EEY73sagTONiNXZYzmk5ZtmR/PDF5Hda7totVftRiVF30Qm 08LiDC7LWdREaljX3Ge3d7ey4wj39oZclDU3AQBldzTlpNUIt6pFT0zOsbURpKx0/huL l8dWEVuKGd1PPsOvxxPaDfKgmkswfr2G13ZaM= 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=EBUMmBiUIDSZVPbCSSCw7FljHhTSxPf4/SpasDkKS8bDuBJByYvDkZ/d/kPetf3EVt u60t61qCVqZ+xYKapObwv6BA2ChcZm0BgRonyoV2Nv8LZL+5WMWBNLtYt52MClZfEYvL qFMpWbhghW40o8HpWqL/zdkw5HbETUnuJS1JU= MIME-Version: 1.0 Received: by 10.42.132.73 with SMTP id c9mr1061666ict.414.1297873762625; Wed, 16 Feb 2011 08:29:22 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.222.130 with HTTP; Wed, 16 Feb 2011 08:29:22 -0800 (PST) In-Reply-To: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> Date: Wed, 16 Feb 2011 11:29:22 -0500 X-Google-Sender-Auth: dMkA5Xv_Bb9ICUVwPSFCkvfIm4k Message-ID: From: Adam Langley To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 16:28:57 -0000 On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters wrote: > Couldn't the MITM SSL proxy register their cert in the DNS entry associated > with their name or reverse ? That way, it becomes a "DANE certified" MITM, > so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then > don't warn the user... > > Now people with a MITM SSL proxy are protected against other MITM entities. Pressure can be applied to the vendors to make changes but, in my experience, they move very slowly and customer update firmware even more slowly. In order to get off the ground I feel that it's important that clients not be broken so that sites don't feel pressure not to publish DNS cert information. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 84CB13A6E6D for ; Wed, 16 Feb 2011 08:23:34 -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 mcBFQzAEiIak for ; Wed, 16 Feb 2011 08:23:32 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 330E53A6E6B for ; Wed, 16 Feb 2011 08:23: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 B23DFC57C; Wed, 16 Feb 2011 11:23:59 -0500 (EST) Date: Wed, 16 Feb 2011 11:23:59 -0500 (EST) From: Paul Wouters To: Adam Langley In-Reply-To: Message-ID: References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.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] Bootstrapping Dane Adoption 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, 16 Feb 2011 16:23:34 -0000 On Wed, 16 Feb 2011, Adam Langley wrote: > On Wed, Feb 16, 2011 at 4:17 AM, Henry Story wrote: >> With even a few million such entries it would then be very easy to >> convince browser manufacturers of the use of adding support for DANE. > > Nope, because it would break everyone behind a MITM SSL proxy. Couldn't the MITM SSL proxy register their cert in the DNS entry associated with their name or reverse ? That way, it becomes a "DANE certified" MITM, so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then don't warn the user... Now people with a MITM SSL proxy are protected against other MITM entities. 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 0CF763A6D21 for ; Wed, 16 Feb 2011 07:55:53 -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 C1g52LQtZnhg for ; Wed, 16 Feb 2011 07:55:52 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E2A143A6CC7 for ; Wed, 16 Feb 2011 07:55:51 -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 1CCEBC590; Wed, 16 Feb 2011 10:56:19 -0500 (EST) Date: Wed, 16 Feb 2011 10:56:18 -0500 (EST) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1297833665.2455.6.camel@mattlaptop2.local> Message-ID: References: <1297833665.2455.6.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] Proof-of-concept implementation for NSS 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, 16 Feb 2011 15:55:53 -0000 On Wed, 16 Feb 2011, Matt McCutchen wrote: > Surprise! > > I have a proof-of-concept implementation of DANE for NSS working against > TLSA data on mattmccutchen.net. Firefox even runs with the modified > NSS, though it shows unverified certificate details. Only SHA-1 hashes > of end-entity certificates are supported, following the format in > draft-ietf-dane-protocol-04. The NSS patch, which includes > documentation, will be maintained at: > > https://mattmccutchen.net/cryptid/#nss-dane This is awesome! I will test these and update my tools to generate TLSA with prefixes and let you know! 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 92E803A6D2B for ; Wed, 16 Feb 2011 07:43:39 -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 M0ITKQz8hs+p for ; Wed, 16 Feb 2011 07:43:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4ECFF3A6D21 for ; Wed, 16 Feb 2011 07:43:38 -0800 (PST) Received: by iwc10 with SMTP id 10so1544689iwc.31 for ; Wed, 16 Feb 2011 07:44:06 -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=sryGtUli8uvnow0EZAf7ZGlAn89O3tDJ4SsxmzU3J6I=; b=aMHfUHT5hzkEvUMUOXrA170xwY0Inf8eghXDo8/t1hYATNEbw70fUesmN/5LTgX9+O 98ZUaGODGnMeoHVu1W++xmgb57QhWpG8yTRkuekj1SLVrn+zxQGXzxFcqYXmT9LFcyo6 XEG8AALRBfbgjxJFF23XRJBT3onXrmlmmkPM4= 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=sDXIxV5sN/dY+f4aRM2PS1I+3H81CPGMhMGGF4lWGHv/OFRJhd3iUuiVvS4yIouUZx VW6/9LhrLcBujWFlDkyawbP21NnbrPTcvCHwpBFUHOO75LT8n/odeVJP025F9VtNbo37 J68z8j5ZlVeVmJVXmZLgmbbGJpIGt8y+rNRiA= MIME-Version: 1.0 Received: by 10.42.225.198 with SMTP id it6mr1060760icb.12.1297871046359; Wed, 16 Feb 2011 07:44:06 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.222.130 with HTTP; Wed, 16 Feb 2011 07:44:06 -0800 (PST) In-Reply-To: <2BCABFB7-74D0-4E9C-AF6C-8560423A46FB@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> <2BCABFB7-74D0-4E9C-AF6C-8560423A46FB@bblfish.net> Date: Wed, 16 Feb 2011 10:44:06 -0500 X-Google-Sender-Auth: QTYjaFA7t1LPcB-g6VOGzav7rDg Message-ID: From: Adam Langley To: Henry Story Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 15:43:39 -0000 On Wed, Feb 16, 2011 at 10:34 AM, Henry Story wro= te: > =C2=A0Step 1. is this certificate signed by a trusted CA, or can I build = a chain to a trusted CA? > =C2=A0- If yes, it's a good connection. Proceed with browsing experience. We're solving different problems. You want to enable certificates to validate without being CA signed. I understand that, although, given that StartCom gives out free certs I feel that this is mostly a large organisation problem. I'm talking about sites which are worried about CAs misissuing certificates. Either because the CA was fooled (*), or because an intermediate CA cert was misused. These sites have CA signed certs but they want to publish information which excludes other CAs, or other certificates. That leads to the chicken-and-egg problem that I described. AGL --=20 Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 B20A13A6D2B for ; Wed, 16 Feb 2011 07:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 2ttmOh9+p+o1 for ; Wed, 16 Feb 2011 07:33:58 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 365F43A6A25 for ; Wed, 16 Feb 2011 07:33:57 -0800 (PST) Received: by bwz12 with SMTP id 12so1778367bwz.31 for ; Wed, 16 Feb 2011 07:34:25 -0800 (PST) Received: by 10.204.1.132 with SMTP id 4mr607375bkf.41.1297870465094; Wed, 16 Feb 2011 07:34:25 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id f20sm223317bkf.4.2011.02.16.07.34.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Feb 2011 07:34:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: Date: Wed, 16 Feb 2011 16:34:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BCABFB7-74D0-4E9C-AF6C-8560423A46FB@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> To: Adam Langley X-Mailer: Apple Mail (2.1082) Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 15:33:59 -0000 On 16 Feb 2011, at 15:43, Adam Langley wrote: > On Wed, Feb 16, 2011 at 8:43 AM, Henry Story = wrote: >> Yes, sorry. I was not proposing more UI warnings for the browser = user. >> Rather I was thinking of having the DNS provider send an email = suggesting >> to its clients to add public keys using dane to DNSsec. >=20 > If DNS information is to be used as an additional source of > certificate verification then you have a chicken and egg problem: > * Sites won't publish the information in DNS because it'll break > capable clients behind MITM proxies. Why would publishing a public key in DNS break capable clients behind MITM proxies?=20 1- for current browsers it makes no difference, since they don't look in DNS for that information 2- for the yet to be built browsers it will depend on how MITM proxies=20= work and how the algorithm for chosen for selecting legitimate = certificate.=20 How do MITM proxies work? I am told ( http://bit.ly/g4jt5P ) that = either a. companies simply place the MITM certificate in their employees = browsers as trusted root certificates b. there seems to be something as a "Proxy Certificates" which I have = not enough information for. So the case we are looking at for the moment is a situation such as = 2a, and the trick is to specify an algorithm where browsers work behind good = proxies, but not behind evil proxies such as the ones in an internet caf=E9. We also want = browsers 2a to allow legitimate self signed certificates. It seems to me that = this is an easy algorithm to write down. The User Agent on receiving a = certificate follows this procedure Step 1. is this certificate signed by a trusted CA, or can I build a = chain to a trusted CA?=20 - If yes, it's a good connection. Proceed with browsing experience. Note that since legitimate Proxy certificates appear in the trusted = CA list as explained in a above (and I imagine something similar works = for what is known as "Proxy Certificates") this deals with legitimate = proxies. Illegitimate proxies won't be able to be tied to the trusted CA = roots, and the DNS lookup described in step 2 won't work either, so they = will fail) - else go to 2. =20 Step 2. Is this a self signed certificate, or one that it makes sense = to look up in DNSsec?=20 - If yes, look it up, and if tests succeeds then it's a good = connection. Continue with browsing experience.=20 - else show ugly monster to user so he understand this is dangerous. > * MITM proxies won't change until the pressure is overwhelming. I think there is no need for them to change. Well if I thought about it, = perhaps I could come up with ways to improve them, but that would be a = different topic. >=20 > (`Sites' here means sites that have valid certificate, but are worried > about mis-issuance by CAs, mistaken or otherwise.) >=20 > I'm not suggesting that MITM proxies are a good thing but the reality > is that a) they exist in numbers large enough that we can't ignore > them b) they're very slow to change. >=20 >> You mean assume it's a Good MITM box and skip the check? That would = completely >> defeat the whole point of TLS. I think you must be thinking of = something else. >=20 > Yes that's what I'm suggesting as a way to break the deadlock = described above. So how does that not break all of TLS at the same time? Henry >=20 >=20 > AGL >=20 > --=20 > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org Social Web Architect http://bblfish.net/ 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 1B1033A6E3C for ; Wed, 16 Feb 2011 06:43:04 -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 DAyViUS9bq1h for ; Wed, 16 Feb 2011 06:43:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 023683A6E48 for ; Wed, 16 Feb 2011 06:43:02 -0800 (PST) Received: by iym1 with SMTP id 1so1363603iym.31 for ; Wed, 16 Feb 2011 06:43:31 -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=2m53pD9r3E0qrcUqYRV5U8tuxU0tP9T6CwToExyNrgM=; b=O0HJeqDtkXOWFcNnGemI16hA6ODGH0gkrTpD4kd04TTwi3BP/I0Iq8+WFNUI1rkjQr WIeKmQP6c/tL0OdWarawf6L5MfbSarI2BHHWc+GgUlpNWVToIdKI2l8ueJRfyVykXRAY dHeygbVJA/Wm3q1OJ6X4FPROQ+8mS4qrrJwY8= 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=F6q4EguFqZwtEU+33PBtjP6yVTZqOq/mgCjEfp5wx6OgYNA8I4lOFrwSHMXgWhNh7r jgWhK1lE2vxnylKYn7qgoB+9A95o6hiFrW3rdVgVY6cqDJ2AaPd1rMmLUeE83m0hnH4T asTIm9jY4tsblnlYD78rAsPMPKMmyoNZ6NPEU= MIME-Version: 1.0 Received: by 10.42.225.198 with SMTP id it6mr929456icb.12.1297867411202; Wed, 16 Feb 2011 06:43:31 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.222.130 with HTTP; Wed, 16 Feb 2011 06:43:31 -0800 (PST) In-Reply-To: <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> Date: Wed, 16 Feb 2011 09:43:31 -0500 X-Google-Sender-Auth: M-kW2oQqH4GBkgkJFnELFIlJjsU Message-ID: From: Adam Langley To: Henry Story Content-Type: text/plain; charset=UTF-8 Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 14:43:04 -0000 On Wed, Feb 16, 2011 at 8:43 AM, Henry Story wrote: > Yes, sorry. I was not proposing more UI warnings for the browser user. > Rather I was thinking of having the DNS provider send an email suggesting > to its clients to add public keys using dane to DNSsec. If DNS information is to be used as an additional source of certificate verification then you have a chicken and egg problem: * Sites won't publish the information in DNS because it'll break capable clients behind MITM proxies. * MITM proxies won't change until the pressure is overwhelming. (`Sites' here means sites that have valid certificate, but are worried about mis-issuance by CAs, mistaken or otherwise.) I'm not suggesting that MITM proxies are a good thing but the reality is that a) they exist in numbers large enough that we can't ignore them b) they're very slow to change. > You mean assume it's a Good MITM box and skip the check? That would completely > defeat the whole point of TLS. I think you must be thinking of something else. Yes that's what I'm suggesting as a way to break the deadlock described above. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 D2F8D3A6D44 for ; Wed, 16 Feb 2011 06:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 95Ii4Z-dwwYZ for ; Wed, 16 Feb 2011 06:33:53 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id C0F2E3A6D1B for ; Wed, 16 Feb 2011 06:33:53 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id C83A659806E for ; Wed, 16 Feb 2011 06:34:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=DafCCgKm3eg4V4MFLNnCIttyskQVIj/aoe5j+TfWa3Q dQ8lN7ol8eZv3h34jT55Jmx+H+kL/YFNu0ZFpz/Zpma79sbRe8ESBXlxRrSm5Exm H0jALBmQJXoIWmearYi4FGD2Y/3vO+a+3aqC3OMkBB9l1El3vhRqAT0iW6cmNjik = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=/apxzWm49otGxOrK1Y6DN8EYz/E=; b=Ohi9XCjy5s /IC+MkoyLKQnvsCnlYxnyri1Us8xiVa0AszO+qgFb/jwZxmMqQTQ+BhgP/LEcXOD x0GRVGud4L+s0NgFQtkgSjPJhtYxNKDE9LYzaFCJ/2suh3zRneBaQ0oOGZuz+Lud jsbyHh05eZhwYIHCfxHXUfvlWY/SciYdY= Received: from [10.108.64.61] (unknown [129.2.129.80]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id 8A65659806B for ; Wed, 16 Feb 2011 06:34:19 -0800 (PST) From: Matt McCutchen To: keyassure@ietf.org In-Reply-To: <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Feb 2011 09:33:59 -0500 Message-ID: <1297866839.2602.5.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 14:33:54 -0000 On Wed, 2011-02-16 at 14:43 +0100, Henry Story wrote: > On 16 Feb 2011, at 14:03, Adam Langley wrote: > > Rather I suspect that the answer will be in the form: "If this cert is > > accepted by the verifier but is rooted at a non-default CA, then > > assume it's a MITM box and skip the check". That's been on my todo > > list for a while now in Chrome. > > You mean assume it's a Good MITM box and skip the check? That would completely > defeat the whole point of TLS. I think you must be thinking of something else. The proposal is to exempt "non-default" trusted CAs from DANE exclusion, but I don't think "non-default", whatever it means, is what we want. We probably want a separate trust bit. Let's just hope Mozilla doesn't start handing it out to public CAs. -- 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 F0BA53A6D14 for ; Wed, 16 Feb 2011 05:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 turAK-mG7DW9 for ; Wed, 16 Feb 2011 05:59:56 -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 3F1583A6CC8 for ; Wed, 16 Feb 2011 05:59:56 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 79ABE63406E for ; Wed, 16 Feb 2011 06:00:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=B2kvN3DFo0E99LVFmUEhN62waarlgolLoeLOPglcnL6 I5Ah/nk25ueM90Zd5Q9P7zZsL139tr6OEw3macKnRQDOCaBpJEDRNsUgjRwlfi1u bc5lisvEXl227FN0Ecwuxm0pelC9/6v8xBHsSzMAogtGGru2LyrAfVSEY94hLQAw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Spz3D02bMimr3+fGW7na651M45c=; b=o3YTO/rP+1 xQvi8faKMnRxsxIYVrHkNu/lEBoR5ycfgfdy/CG8O1HSq1nVu1WSAfTXcvvaEt0C 1v+EcViKUKzjp4zjZnoC/ltNsC6BNBBfg2T2add33B4+rcTSFde9wsCXKfMufDSo FN6oAkZOQrIYBba8+88MpMBLEA/HWXZ2w= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 284B963406C for ; Wed, 16 Feb 2011 06:00:24 -0800 (PST) From: Matt McCutchen To: keyassure@ietf.org In-Reply-To: <2883FEA8-071A-414C-9000-3F5F30A5E5E7@bbn.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <2883FEA8-071A-414C-9000-3F5F30A5E5E7@bbn.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Feb 2011 09:00:22 -0500 Message-ID: <1297864822.2602.1.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 13:59:58 -0000 On Wed, 2011-02-16 at 08:39 -0500, Richard L. Barnes wrote: > Presumably the MITM SSL proxy vendors just need to start MITM-ing the DNS traffic now too? Yep. Let them fork the world all the way up to the root zone trust anchor. -- 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 4069C3A6D19 for ; Wed, 16 Feb 2011 05:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 GFgTI4iPRbrc for ; Wed, 16 Feb 2011 05:43:17 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A31B83A6E16 for ; Wed, 16 Feb 2011 05:43:16 -0800 (PST) Received: by bwz12 with SMTP id 12so1660195bwz.31 for ; Wed, 16 Feb 2011 05:43:44 -0800 (PST) Received: by 10.204.122.198 with SMTP id m6mr476339bkr.186.1297863824071; Wed, 16 Feb 2011 05:43:44 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id z18sm144124bkf.20.2011.02.16.05.43.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Feb 2011 05:43:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Wed, 16 Feb 2011 14:43:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8936EE33-DE11-4BBD-8B8F-E8904ED6DF22@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> To: Adam Langley X-Mailer: Apple Mail (2.1082) Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 13:43:18 -0000 On 16 Feb 2011, at 14:03, Adam Langley wrote: > On Wed, Feb 16, 2011 at 7:52 AM, Henry Story = wrote: >> Ok. So it could automatically alert the user, and ask him if he would >> like this to happen by confirming securely his intention. Oops. Sorry I think I sent my reply above too quickly. I was thinking = you were speaking of the DNSsec provider having a MITM problem, and so my = solution was geared towards asking the domain admin to verify that. But in fact you were thinking of this from the = end-user-behind-his-browser experience, and the issue you are thinking of is not just any MITM TLS = proxy,=20 but legitimate ones such as those that are behind HTTPS company = firewalls.=20 As it happens we just had a discussion of this on the WebID mailing = list=20 ISSUE-28: "How does the WebID protocol (foaf+ssl) interact with TLS = proxies" http://www.w3.org/2005/Incubator/webid/track/issues/28 So if I understand correctly from that discussion and thanks to the = clear=20 contribution by Yngve from Opera ( http://bit.ly/g4jt5P ) companies that use these proxies would put the proxy root certificate into their = employees=20 browsers. They would be foolish if they did not, because if they did not they would be training their users not to take care of security alerts. What the proposal of allowing people to place self signed certs into = DNSsec using Dane is designed to do, is to allow browsers to distinguish = between the millions of legitimate self signed certs and the non legitimate = ones. As a result browser warnings will be a lot more meaningful. What you are bringing up is another subset of self signed certificates=20= usages: those by legitimate TLS proxies. For those it seems there is the existing solution described above. Yngve also mentioned something about "Proxy Certificates" though I don't know much about those.=20 >=20 > Adding more UI warnings is a classic trap that smart people fall into. > Although it suffices for experts, it's worse than useless for 99.9% of > users. Yes, sorry. I was not proposing more UI warnings for the browser user. Rather I was thinking of having the DNS provider send an email = suggesting=20 to its clients to add public keys using dane to DNSsec. I was in fact trying to reduce the case of legitimate end user warnings by allowing the browser to distinguish between legitimate and=20 illegitimate self signed certificates by allowing legitimate web sites to place keys in DNSsec. >=20 > Rather I suspect that the solution will have to be more messy than > this. If we had a list of the Issuer names that MITM boxes used, then > we could skip the check in those cases. But we don't and finding out > will be painful for some users. There seems to be something called "Proxy certificates" according to = Yngve. But he did not give further pointers, so I don't know how those work. > Rather I suspect that the answer will be in the form: "If this cert is > accepted by the verifier but is rooted at a non-default CA, then > assume it's a MITM box and skip the check". That's been on my todo > list for a while now in Chrome. You mean assume it's a Good MITM box and skip the check? That would = completely defeat the whole point of TLS. I think you must be thinking of something = else. Henry >=20 >=20 > AGL >=20 > --=20 > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org Social Web Architect http://bblfish.net/ 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 0F24D3A6CC8 for ; Wed, 16 Feb 2011 05:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 RK1idlrTzHP5 for ; Wed, 16 Feb 2011 05:39:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D74A63A6CB8 for ; Wed, 16 Feb 2011 05:39:36 -0800 (PST) Received: from [128.89.253.107] (port=62129 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pphbw-000PtM-8p; Wed, 16 Feb 2011 08:40:04 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 16 Feb 2011 08:39:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2883FEA8-071A-414C-9000-3F5F30A5E5E7@bbn.com> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> To: Adam Langley X-Mailer: Apple Mail (2.1082) Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 13:39:38 -0000 Presumably the MITM SSL proxy vendors just need to start MITM-ing the = DNS traffic now too? Honestly, this seems like a security plus to me -- out-of-band = verification of keys! --Richard On Feb 16, 2011, at 7:21 AM, Adam Langley wrote: > On Wed, Feb 16, 2011 at 4:17 AM, Henry Story = wrote: >> With even a few million such entries it would then be very easy to >> convince browser manufacturers of the use of adding support for DANE. >=20 > Nope, because it would break everyone behind a MITM SSL proxy. >=20 >=20 > AGL >=20 > --=20 > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > 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 07F003A6CCD for ; Wed, 16 Feb 2011 05:03:16 -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 ke0NeEfR6Doj for ; Wed, 16 Feb 2011 05:03:14 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id BE48D3A6CC6 for ; Wed, 16 Feb 2011 05:03:14 -0800 (PST) Received: by qyk34 with SMTP id 34so3343386qyk.10 for ; Wed, 16 Feb 2011 05:03:42 -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=10xXBo+tAzDWQjYArn2JzCaa85dmLmrA36iDCa7vlig=; b=NuPlv2EkEI45Eaq+v0W3jl5k7wcUYoZ0+VL7gdwSQitZP+/oyRuTNiC/RkqU1Y3QuR lVHHCRCA5xh0Wz+mikF9G14Fh8zIIYholP4a9E/gtFFs0srRSFC/wkRKeZZDquOGNSVp 7XRmJMEPDMbsuP5iGqg5rXiFRnq/VCL0y2ma0= 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=Pwpc3zFgPZF9bje/m3YNZ+nj/xV/XocCC4GJT32p1JtnGSYUvJY2mnjiHPZjyfx6Sn sK1Rqf3HMRYtvp/97kDqzLBGP1RD6+f8SrV44fYS3o17EYuKUfcw0s6XDgdJ1svfdoZk wLCHAEtbgzX5M8543XTITVlcCgAz/l8ZWDrb0= MIME-Version: 1.0 Received: by 10.224.11.143 with SMTP id t15mr761574qat.18.1297861419259; Wed, 16 Feb 2011 05:03:39 -0800 (PST) Sender: alangley@gmail.com Received: by 10.229.248.76 with HTTP; Wed, 16 Feb 2011 05:03:39 -0800 (PST) In-Reply-To: <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> Date: Wed, 16 Feb 2011 08:03:39 -0500 X-Google-Sender-Auth: LxQRlBEMxOBvldHUaLup1TdEW1E Message-ID: From: Adam Langley To: Henry Story Content-Type: text/plain; charset=UTF-8 Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 13:03:16 -0000 On Wed, Feb 16, 2011 at 7:52 AM, Henry Story wrote: > Ok. So it could automatically alert the user, and ask him if he would > like this to happen by confirming securely his intention. Adding more UI warnings is a classic trap that smart people fall into. Although it suffices for experts, it's worse than useless for 99.9% of users. Rather I suspect that the solution will have to be more messy than this. If we had a list of the Issuer names that MITM boxes used, then we could skip the check in those cases. But we don't and finding out will be painful for some users. Rather I suspect that the answer will be in the form: "If this cert is accepted by the verifier but is rooted at a non-default CA, then assume it's a MITM box and skip the check". That's been on my todo list for a while now in Chrome. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 0DC6E3A6CBF for ; Wed, 16 Feb 2011 04:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 kvPqJo4WJTCr for ; Wed, 16 Feb 2011 04:52:29 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8E5A73A6CB3 for ; Wed, 16 Feb 2011 04:52:29 -0800 (PST) Received: by bwz12 with SMTP id 12so1609768bwz.31 for ; Wed, 16 Feb 2011 04:52:56 -0800 (PST) Received: by 10.204.68.9 with SMTP id t9mr437025bki.173.1297860775387; Wed, 16 Feb 2011 04:52:55 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id z18sm111872bkf.20.2011.02.16.04.52.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Feb 2011 04:52:53 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Wed, 16 Feb 2011 13:52:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E342450-717E-4CD8-BA18-8943C52D6623@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> To: Adam Langley X-Mailer: Apple Mail (2.1082) Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 12:52:31 -0000 On 16 Feb 2011, at 13:21, Adam Langley wrote: > On Wed, Feb 16, 2011 at 4:17 AM, Henry Story = wrote: >> With even a few million such entries it would then be very easy to >> convince browser manufacturers of the use of adding support for DANE. >=20 > Nope, because it would break everyone behind a MITM SSL proxy. Ok. So it could automatically alert the user, and ask him if he would like this to happen by confirming securely his intention.=20 Perhaps a link to a browser plugin initially would be useful, so that people can see where this is leading. Henry >=20 >=20 > AGL >=20 > --=20 > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org Social Web Architect http://bblfish.net/ 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 92F823A6E4B for ; Wed, 16 Feb 2011 04:20:36 -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 RWP8gvCSYgt8 for ; Wed, 16 Feb 2011 04:20:34 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8FE843A6E3E for ; Wed, 16 Feb 2011 04:20:34 -0800 (PST) Received: by qwi2 with SMTP id 2so1316991qwi.31 for ; Wed, 16 Feb 2011 04:21:02 -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=yoHJtCIIYMFuvux1l0kytF6Yru3eKUq43pEL9X7dBnA=; b=GrgdgNw7BzOivTru++Z34zx792SixI5Mh6muCDk9X8n3hNpaMNudjSXCbEZWOGNd6Q Zc/pQVIiyrQaxdIcbRJzDdEYjc+CkqHX8vlUKN4+itOsJup2CcG3Ug45SP2o8tvUDAOp za0UTLM4kxzFuq5a2dvqLWTm/N7eDWbxEkGBY= 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=HmFtPLEyYPpPa77TrX8gHx+9WT7SyjNh8blfqDKOWH1oYxjst8xhJAZH//yLTLlUNc 55sZX1+/DEfCkWagpBexsz4qBhhcpKbNDIcYBT6jBgGjN0SyAYf8NSO3N5ACY1PgC+zj pJH3VG7pDHJIVzdmgjZHvYhlOb+eqy6N2QmTA= MIME-Version: 1.0 Received: by 10.229.97.1 with SMTP id j1mr593118qcn.212.1297858862177; Wed, 16 Feb 2011 04:21:02 -0800 (PST) Sender: alangley@gmail.com Received: by 10.229.248.76 with HTTP; Wed, 16 Feb 2011 04:21:02 -0800 (PST) In-Reply-To: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> References: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> Date: Wed, 16 Feb 2011 07:21:02 -0500 X-Google-Sender-Auth: 3JSuJgdUYvSqogKxcshFiZwf0Xs Message-ID: From: Adam Langley To: Henry Story Content-Type: text/plain; charset=UTF-8 Cc: John Gilmore , keyassure@ietf.org Subject: Re: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 12:20:36 -0000 On Wed, Feb 16, 2011 at 4:17 AM, Henry Story wrote: > With even a few million such entries it would then be very easy to > convince browser manufacturers of the use of adding support for DANE. Nope, because it would break everyone behind a MITM SSL proxy. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 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 0E7043A6D63 for ; Wed, 16 Feb 2011 01:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 0a0-WtOdhmxw for ; Wed, 16 Feb 2011 01:17:02 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BEB533A6DDA for ; Wed, 16 Feb 2011 01:17:01 -0800 (PST) Received: by bwz12 with SMTP id 12so1433785bwz.31 for ; Wed, 16 Feb 2011 01:17:28 -0800 (PST) Received: by 10.204.15.83 with SMTP id j19mr264742bka.105.1297847848413; Wed, 16 Feb 2011 01:17:28 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id u23sm3275558bkw.21.2011.02.16.01.17.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Feb 2011 01:17:26 -0800 (PST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Feb 2011 10:17:23 +0100 Message-Id: <43743AB7-2208-46AB-9F59-B8862BC39034@bblfish.net> To: John Gilmore Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: [keyassure] Bootstrapping Dane Adoption 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, 16 Feb 2011 09:17:03 -0000 (just pursuing the conversation on a thread that with a name that is = more=20 related to the topic, since this has no more that much to do with = publishing bare public keys ) On 15 Feb 2011, at 22:58, John Gilmore wrote in the thread archived at http://www.ietf.org/mail-archive/web/keyassure/current/msg01810.html >> I can't remember if in their presentation they tell us how many = valid self >> signed certs they found out there... >=20 > According to Chris Palmer of EFF, the SSL Observatory found 7 million > self-signed certs (and 4.3 million with other certs). But none of the > self-signed certs were considered "valid self-signed certs" because > the definition of "valid" was "with a valid signature chain, according > to at least one browser", and of course browsers consider self-signed > certs invalid. >=20 > It appears that securing your web site with crypto is about three > times as popular as obtaining a certificate from a certifying > authority. >=20 > So, providing a simple way in DNS for those 7 million web > administrators to securely anchor their website's public keys to their > domain names, without dealing with a certificate authority, would > provide significant benefits to literally millions of people. Yes.=20 It occurred to me that DNSsec providers could easily bootstrap the adoption of Dane by pinging port 443 of their clients hosts, getting the=20= X509 Cert if it is there, verify it is correct, and if it is self signed add the cert or public key to the DNSsec entry. With even a few million such entries it would then be very easy to=20 convince browser manufacturers of the use of adding support for DANE. Henry > 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 CE2DD3A6D48 for ; Tue, 15 Feb 2011 21:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 2dO7RYH1U9z4 for ; Tue, 15 Feb 2011 21:20:39 -0800 (PST) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id D650E3A6D41 for ; Tue, 15 Feb 2011 21:20:39 -0800 (PST) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 150E63BC062 for ; Tue, 15 Feb 2011 21:21:07 -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=c74VHln w1TEKJTD+ck7kp0Dlr9ZiH6SispMZQRbycRTNZhG4EwihB/fnfhAZCBez1G0l0cw vFnrkF1S4ZFisjTh9RyHITsSWBa5fKKTXmY3rYcuwvFp168Y6b4EmKMV6KQSJQRo 27thiffYt6R1JRS3ATLNxPcF0eWMRI/e4iqE= 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=R0jlIHtxzWg7B 07+Tx5xUe5HmtY=; b=jceO2LUU0nfAdDmNeG1HuKitqCNEhp7hwFg+io5ii2NN4 E7uW2HnkQMhYRN61rbAtap+r/S61zgmf7IF1/HhHW0rsxfj7MVTMDwubDodnSX0w le89jgXdV60YR4Jx4TcMuQF25JcS8f3VwvKGA24YESZkL7VcEhGbXc+tu8Htfs= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id B6B5F3BC059 for ; Tue, 15 Feb 2011 21:21:06 -0800 (PST) From: Matt McCutchen To: keyassure Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Feb 2011 00:21:05 -0500 Message-ID: <1297833665.2455.6.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [keyassure] Proof-of-concept implementation for NSS 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, 16 Feb 2011 05:20:40 -0000 Surprise! I have a proof-of-concept implementation of DANE for NSS working against TLSA data on mattmccutchen.net. Firefox even runs with the modified NSS, though it shows unverified certificate details. Only SHA-1 hashes of end-entity certificates are supported, following the format in draft-ietf-dane-protocol-04. The NSS patch, which includes documentation, will be maintained at: https://mattmccutchen.net/cryptid/#nss-dane Have fun. -- 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 29B4B3A6DE3 for ; Tue, 15 Feb 2011 14:30:55 -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 XpcGWcVEE81O for ; Tue, 15 Feb 2011 14:30:54 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 238663A6D7C for ; Tue, 15 Feb 2011 14:30: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 4818FC57C; Tue, 15 Feb 2011 17:31:19 -0500 (EST) Date: Tue, 15 Feb 2011 17:31:18 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <4D5AC35C.3010807@gmail.com> Message-ID: References: <4D5AC35C.3010807@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] publishing the public key 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, 15 Feb 2011 22:30:55 -0000 On Tue, 15 Feb 2011, Yaron Sheffer wrote: > Just for the record, IKEv2 does support bare public keys (though I don't > think they are often used). > > The exact RFC 5996 wording regarding the format is: > > "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-encoded > RSAPublicKey structure (see [RSA > ] and [PKCS1 > ]). > > > Yes, it's ASN.1, but it's well defined. Let's not forget that there have been > security vulnerabilities related to the on-the-wire format of pubic keys in > the past. Openswan (IPsec for Linux) supports raw RSA keys for IKEv1 and IKEv2. 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 7B6333A6AFF for ; Tue, 15 Feb 2011 13:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGtIgDlKqN5v for ; Tue, 15 Feb 2011 13:57:54 -0800 (PST) Received: from new.toad.com (new.toad.com [209.237.225.253]) by core3.amsl.com (Postfix) with ESMTP id D22BD3A6AB9 for ; Tue, 15 Feb 2011 13:57:54 -0800 (PST) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id p1FLwFiR027918; Tue, 15 Feb 2011 13:58:15 -0800 Message-Id: <201102152158.p1FLwFiR027918@new.toad.com> To: Henry Story In-reply-to: <4487480D-900D-4416-8437-583693908163@bblfish.net> References: <201102141829.p1EITKHc009151@fs4113.wdf.sap.corp> <4487480D-900D-4416-8437-583693908163@bblfish.net> Comments: In-reply-to Henry Story message dated "Mon, 14 Feb 2011 20:07:04 +0100." Date: Tue, 15 Feb 2011 13:58:15 -0800 From: John Gilmore Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 21:57:55 -0000 > I can't remember if in their presentation they tell us how many valid self > signed certs they found out there... According to Chris Palmer of EFF, the SSL Observatory found 7 million self-signed certs (and 4.3 million with other certs). But none of the self-signed certs were considered "valid self-signed certs" because the definition of "valid" was "with a valid signature chain, according to at least one browser", and of course browsers consider self-signed certs invalid. It appears that securing your web site with crypto is about three times as popular as obtaining a certificate from a certifying authority. So, providing a simple way in DNS for those 7 million web administrators to securely anchor their website's public keys to their domain names, without dealing with a certificate authority, would provide significant benefits to literally millions of people. 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 34B4C3A6DD8 for ; Tue, 15 Feb 2011 13:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=-0.144, 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 kYAxbIQcxopA for ; Tue, 15 Feb 2011 13:55:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5791B3A6DB1 for ; Tue, 15 Feb 2011 13:55:07 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:56192 helo=[10.84.131.124]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpSrt-000HQ2-M0; Tue, 15 Feb 2011 16:55:33 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <201101211645.p0LGjqVu023472@fs4113.wdf.sap.corp> References: <201101211645.p0LGjqVu023472@fs4113.wdf.sap.corp> Date: Tue, 15 Feb 2011 14:24:54 -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, 15 Feb 2011 21:55:11 -0000 Sorry to be so late in replying, but travel, vacation, etc. >... >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. agreed > > 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. buggy code exists. I don't suggest that we contort extant specs to accommodate such code, but we also should be mindful of pervasive limitations when developing new specs. >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. Using an AIA to locate a CA cert is exactly what we intended when that extension was defined, to compensate for a lack of directory access/data. i agree that AIA chasing can be evil, but it can be use for good as well :-). >The straight-forward way for making cert path validation work >in cross certification scenarios is to distribute cross-certs >as trust anchors. One could do that, but it ought not be necessary. > > 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. >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. if DANE wants to define such an extension, and if the TLS WG agrees, then that would be one way to address this issue. >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. >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. we disagree on the history here, but we should not pursue the discussion on this list. >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. This is a re-statement of what I suggested in the 1997 MILCOM paper I cited in a previous message. 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 34B893A6C32 for ; Tue, 15 Feb 2011 11:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=1.373, 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 uBs8lIqgKbYv for ; Tue, 15 Feb 2011 11:42:05 -0800 (PST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id C6C5B3A6D69 for ; Tue, 15 Feb 2011 11:42:04 -0800 (PST) Received: by bwz12 with SMTP id 12so854758bwz.27 for ; Tue, 15 Feb 2011 11:42:29 -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=U0qatTzIA41gGYo69wrLSpwqwpb7KSGyYHgAcSoaA/0=; b=dANqz4WwjiHZL2MhZkyRFTVtwd5xXkmJbrMsB1/vyf14uqA1OYxIt8karBM6Sr5Z2Z ns0WCPXamFj+C/6HeYcvzV213V/y+WwGR3OubVSjWwf8y7N2DkQ3ER2gvlpOi1y11OJM cfrTCFXAYolvFalv8a+D2N8YThZxEyPlkLV1M= 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=rTW5KJq5buvCTa/NjHebocPlrMKJ5r/m0GwDiBLUF+jebNa0VR9OV0YYtezY5hi1g0 RVIQsBfZnhUjf2T4xzKX/B+93e6ZMNMi+hVM25/VH1Q9lUuicWeT+fjrIAuqFNF3P6dS bP3JtvVQoO0x5ryk8s3HmkdGnsK8fdQ9I5cT4= Received: by 10.204.55.65 with SMTP id t1mr9191028bkg.140.1297798948219; Tue, 15 Feb 2011 11:42:28 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id x38sm2865478bkj.1.2011.02.15.11.42.24 (version=SSLv3 cipher=OTHER); Tue, 15 Feb 2011 11:42:26 -0800 (PST) Message-ID: <4D5AD71D.1080105@gmail.com> Date: Tue, 15 Feb 2011 21:42:21 +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: Ilari Liusvaara References: <4D5AC35C.3010807@gmail.com> <20110215190718.GA24175@LK-Perkele-VI.localdomain> In-Reply-To: <20110215190718.GA24175@LK-Perkele-VI.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 19:42:06 -0000 Hi Ilari, What I had in mind was this padding attack: http://www.openssl.org/news/secadv_20030319.txt Thanks, Yaron On 02/15/2011 09:07 PM, Ilari Liusvaara wrote: > On Tue, Feb 15, 2011 at 08:18:04PM +0200, Yaron Sheffer wrote: > > > > Yes, it's ASN.1, but it's well defined. Let's not forget that there > > have been security vulnerabilities related to the on-the-wire format > > of pubic keys in the past. > > Letting factors outside the signed blocks interfere with interpretation > of stuff inside signature? Signed blocks with multiple interpretations? > > What else? Got summary of some of the issues (just for reference, quick > googling doesn't yield anything relvant)? > > -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 A40263A6C32 for ; Tue, 15 Feb 2011 11:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ej0iyOeB01iD for ; Tue, 15 Feb 2011 11:07:06 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id BE7BD3A6AB3 for ; Tue, 15 Feb 2011 11:07:04 -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 B0EB213BAF0; Tue, 15 Feb 2011 21:07:29 +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 A07008944B8; Tue, 15 Feb 2011 21:07:29 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 9C376E51A9; Tue, 15 Feb 2011 21:07:27 +0200 (EET) Date: Tue, 15 Feb 2011 21:07:18 +0200 From: Ilari Liusvaara To: Yaron Sheffer Message-ID: <20110215190718.GA24175@LK-Perkele-VI.localdomain> References: <4D5AC35C.3010807@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D5AC35C.3010807@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 19:07:06 -0000 On Tue, Feb 15, 2011 at 08:18:04PM +0200, Yaron Sheffer wrote: > > Yes, it's ASN.1, but it's well defined. Let's not forget that there > have been security vulnerabilities related to the on-the-wire format > of pubic keys in the past. Letting factors outside the signed blocks interfere with interpretation of stuff inside signature? Signed blocks with multiple interpretations? What else? Got summary of some of the issues (just for reference, quick googling doesn't yield anything relvant)? -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 16B953A6D2A for ; Tue, 15 Feb 2011 10:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.19 X-Spam-Level: X-Spam-Status: No, score=-101.19 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 vu841jTX0+9P for ; Tue, 15 Feb 2011 10:17:51 -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 0AE533A6D33 for ; Tue, 15 Feb 2011 10:17:50 -0800 (PST) Received: by fxm9 with SMTP id 9so563602fxm.31 for ; Tue, 15 Feb 2011 10:18:16 -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=MMqfNWD694h+ojtvtC/Rf5+2lA1tyegXohHyV2247ng=; b=uVwMRMhiSxSv52rMfM3ustRkV7tpae5gXOJq7vK9JIhgDHdQtpexBr0I3RKyXWQfcg Au2iSyIuPCQqHQRm/amVxWlPCxVosmMovYsRVzZEljkQ3xzu/LPxubTPNFNtB/hFw9jV LzNxgZ6JONfLUBMac0PFJPRm5LlxydYT4FAGU= 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=NIqpHPUZa+318Ui1JJUPU+eUIswv0mjarZ03sz7XOKayT0YKZECDIEAvQ7F72zMuiO PCi1gJTNoFYW4lM55gfJfdvzwPXgrk8jzIGKiru24kdBK868ydfNoUsReww+sm6ChNKu pBmoyrNnkA2G2SXN/DF+avBKOaPA0FVAApmHE= Received: by 10.223.74.206 with SMTP id v14mr6536668faj.66.1297793887793; Tue, 15 Feb 2011 10:18:07 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id n3sm1813123fax.7.2011.02.15.10.18.06 (version=SSLv3 cipher=OTHER); Tue, 15 Feb 2011 10:18:07 -0800 (PST) Message-ID: <4D5AC35C.3010807@gmail.com> Date: Tue, 15 Feb 2011 20:18:04 +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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 18:17:52 -0000 Just for the record, IKEv2 does support bare public keys (though I don't think they are often used). The exact RFC 5996 wording regarding the format is: "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-encoded RSAPublicKey structure (see [RSA ] and [PKCS1 ]). Yes, it's ASN.1, but it's well defined. Let's not forget that there have been security vulnerabilities related to the on-the-wire format of pubic keys in the past. Thanks, Yaron > Message: 4 > Date: Mon, 14 Feb 2011 18:35:23 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] Issue #14 - publishing the public key > To: keyassure@ietf.org > Message-ID:<4D59E66B.1090808@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Personally, I don't see much use for bare public keys, but I hear that > many people do, and I don't see much harm in adding them. > > However, if the WG wants to add them, I would want to see some wording > for how the on-the-wire format would look. That is, you can't just put > the bits of the public key there: you also have to say what the > signature algorithm is and, if the algorithm requires parameters, what > the parameters are. > > Any of the folks who seem most in favor of this: please suggest some > wording here. You need to say what the format is and how the TLS client > would compare the value gotten from the TLSA RR with the certificate > they get in the TLS handshake. 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 367033A6C38 for ; Tue, 15 Feb 2011 08:19:00 -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 h8uY5dfzu-OS for ; Tue, 15 Feb 2011 08:18:59 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 5C1163A6C30 for ; Tue, 15 Feb 2011 08:18: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 01759C57C; Tue, 15 Feb 2011 11:19:23 -0500 (EST) Date: Tue, 15 Feb 2011 11:19:22 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D5A9C2F.6050205@vpnc.org> Message-ID: References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> <20110215022103.GA2874@odin.mars.sol> <4D59F233.7080708@vpnc.org> <4D5A9C2F.6050205@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] publishing the public key 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, 15 Feb 2011 16:19:00 -0000 On Tue, 15 Feb 2011, Paul Hoffman wrote: >> So please don't call bare public key out of scope yet. > > Paul, saying that is ridiculous. In the message that preceded the one you > replied to, I actually supported bare keys as long as proponents can propose > wording that the WG would support on how they should be included. Sorry, I should have been more clear. I did not mean you personally with that statement. I meant in general for the keyassure list to keep bare keys under consideration when continuing to work out the DANE protocol. 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 A3C363A6E92 for ; Tue, 15 Feb 2011 07:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_40=-0.185, 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 Ea8jWQAA-7T1 for ; Tue, 15 Feb 2011 07:30:30 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DD0EF3A6BA0 for ; Tue, 15 Feb 2011 07:30:30 -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 p1FFUtlN099714 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2011 08:30:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D5A9C2F.6050205@vpnc.org> Date: Tue, 15 Feb 2011 07:30:55 -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: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> <20110215022103.GA2874@odin.mars.sol> <4D59F233.7080708@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 15:30:31 -0000 On 2/14/11 9:12 PM, Paul Wouters wrote: > On Mon, 14 Feb 2011, Paul Hoffman wrote: > >>> Why does TLS service have to send cert/cert chain? >> >> Because that is what is required by the TLS standard. We should not be >> trying to modify the TLS spec in this WG. > > I understand, but there IS a relationship here. With DANE, you have an > alternative to PKIX-TLS. So such a change would affect TLS, but would > require DANE. I disagree that us using bare keys for identifying TLS server certificates is impossible. > Similarly, the TLS group could say "we won't add bare > public key because there is no validation for it" and they'd send me > back to DANE. They could say that, but you have not even asked the TLS WG, have you? > So please don't call bare public key out of scope yet. Paul, saying that is ridiculous. In the message that preceded the one you replied to, I actually supported bare keys as long as proponents can propose wording that the WG would support on how they should be included. 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 691B83A691B for ; Tue, 15 Feb 2011 04:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=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 gcJFDPax8iHU for ; Tue, 15 Feb 2011 04:16:06 -0800 (PST) Received: from emh05.mail.saunalahti.fi (emh05.mail.saunalahti.fi [62.142.5.111]) by core3.amsl.com (Postfix) with ESMTP id 1299A3A6CAE for ; Tue, 15 Feb 2011 04:16:06 -0800 (PST) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh05-2.mail.saunalahti.fi (Postfix) with SMTP id 06A9D8C5A3; Tue, 15 Feb 2011 14:16:30 +0200 (EET) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A0273900B74; Tue, 15 Feb 2011 14:16:30 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 1036241BEE; Tue, 15 Feb 2011 14:16:26 +0200 (EET) Date: Tue, 15 Feb 2011 14:16:21 +0200 From: Ilari Liusvaara To: Paul Wouters Message-ID: <20110215121621.GA19250@LK-Perkele-VI.localdomain> References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> <20110215022103.GA2874@odin.mars.sol> <4D59F233.7080708@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, Paul Hoffman Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 12:16:07 -0000 On Tue, Feb 15, 2011 at 12:12:08AM -0500, Paul Wouters wrote: > > I understand, but there IS a relationship here. With DANE, you have an > alternative to PKIX-TLS. So such a change would affect TLS, but would > require DANE. Similarly, the TLS group could say "we won't add bare > public key because there is no validation for it" and they'd send me > back to DANE. > > So please don't call bare public key out of scope yet. There are actual technical reasons why putting raw TLS keys in DNS is a bad idea. - The problems it causes with TLS library APIs. - The problems it causes with multiple A/AAAA records. - The problem of not being able to use the sceme for client-to-server. You need a new TLS certtype anyway. I say it is much better way to define new raw key TLS certtype and then assure those via DANE. BTW: Here's one format for raw keys (no ASN.1): General conventions: * uint is n-bit (padding by zeroes on most signficant bits of first octet to be next multiple of an octet) big-endian number. * poly is an element of GF(2^L) given in polynomial basis (again padding on most signficant bits of the first octet with zeroes to be next multiple of an octet). struct rawkey_certificate { //TLS HashAlgorithm registry, MUST NOT be 0 (unhashed) nor 1 (MD5). SHOULD //NOT be 2 (SHA-1). uint<8> tls_hash_algorithm; //Key type uint<16> key_type; switch(key_type) { case 0: //RSA uint<16> L_rsa_n; uint<16> L_rsa_e; uint rsa_n; uint rsa_e; case 1: //DSA uint<16> L_dsa_p; uint<8> L_dsa_q; uint dsa_p; uint dsa_g; uint dsa_y; uint dsa_q; case 2...20: //Prime ECDSA public key (see the table of curves). uint ecdsa_Y_x; uint ecdsa_Y_y; case 21...30: //Binary ECDSA public key (see the table of curves). poly ecdsa_Y_x; poly ecdsa_Y_y; //Other key_types to be defined. } } Constraints for certificate length (L_cert) with different keytypes: RSA: L_cert >= 7 + ceil(L_rsa_n / 8) + ceil(L_rsa_e / 8) DSA: L_cert >= 6 + 3 * ceil(L_dsa_p / 8) + ceil(L_dsa_q / 8) fixed-curve ECDSA: L_cert >= 3 + 2 * ceil(L / 8). The reason why I did not define arbitrary ECDSA curves is that PKIX forbids those and defining full elliptic curve format is actually much more involved than just using a slew of ready-made curves (it could be done, just allocate a key_type for that). I didn't do point compression because ECC points are small anyway and unpacking those if p = 4k + 1 (like NIST P-curves have) is a bit nasty. Table of curves: Keytype: Type: L: Curve: -------- ----- -- ------ 2 Prime 192 NIST P-192 3 Prime 224 NIST P-224 4 Prime 256 NIST P-256 5 Prime 384 NIST P-384 6 Prime 521 NIST P-521 7 Prime 160 Brainpool P160r1 8 Prime 192 Brainpool P192r1 9 Prime 224 Brainpool P224r1 10 Prime 256 Brainpool P256r1 11 Prime 320 Brainpool P320r1 12 Prime 384 Brainpool P384r1 13 Prime 512 Brainpool P512r1 14 Prime 160 Brainpool P160t1 15 Prime 192 Brainpool P192t1 16 Prime 224 Brainpool P224t1 17 Prime 256 Brainpool P256t1 18 Prime 320 Brainpool P320t1 19 Prime 384 Brainpool P384t1 20 Prime 512 Brainpool P512t1 21 Binary 163 NIST B-163 22 Binary 233 NIST B-233 23 Binary 271 NIST B-271 24 Binary 409 NIST B-409 25 Binary 571 NIST B-571 26 Binary 163 NIST K-163 27 Binary 233 NIST K-233 28 Binary 271 NIST K-271 29 Binary 409 NIST K-409 30 Binary 571 NIST K-571 [1] (EC)DSA has no indication what hash type is used. -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 15D513A6CB0 for ; Tue, 15 Feb 2011 03:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 FtnKlQ2jzyHw for ; Tue, 15 Feb 2011 03:46:16 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id C9E6C3A6CAE for ; Tue, 15 Feb 2011 03:46:15 -0800 (PST) Received: by bwz12 with SMTP id 12so382007bwz.31 for ; Tue, 15 Feb 2011 03:46:40 -0800 (PST) Received: by 10.204.46.154 with SMTP id j26mr26022891bkf.134.1297770398910; Tue, 15 Feb 2011 03:46:38 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id x38sm2518642bkj.13.2011.02.15.03.46.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Feb 2011 03:46:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Tue, 15 Feb 2011 12:46:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 11:46:17 -0000 On 15 Feb 2011, at 02:35, Paul Wouters wrote: > On Tue, 15 Feb 2011, Peter Gutmann wrote: >=20 >>> The public key's type and raw blob will be obtained from DNSSEC, so = this is >>> no longer required to be conveyed to the client from the server via = a PKIX >>> certificate or other ASN.1 structures. >>=20 >> But what format is the "type and raw blob" in? You need some way of = encoding >> it, and if it's not the standard ASN.1 format what are you going to = use? >=20 > I'm not sure I understand your question. The key would encoded in DNS, = likely in a > format similar to DNSKEY. Or you just put the key info in ASN.1 format (Abstract Syntax Notation = 1). ASN.1=20 is just like XML in this respect - both are syntaxes. Instead of URIs = for namespaces=20 they use registered numbers. And there is part of the X509 tree of = information a subtree for describing public keys. Just take that subtree. =20 I don't know where that is defined though, though I think I came across = it last year. Henry >=20 > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Social Web Architect http://bblfish.net/ 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 E135F3A6C8B for ; Tue, 15 Feb 2011 03:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 Y4z+EQ+58y+6 for ; Tue, 15 Feb 2011 03:32:24 -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 BA3FA3A6B74 for ; Tue, 15 Feb 2011 03:32:24 -0800 (PST) Received: by gyd12 with SMTP id 12so22533gyd.31 for ; Tue, 15 Feb 2011 03:32:49 -0800 (PST) Received: by 10.150.200.20 with SMTP id x20mr5882760ybf.56.1297769569671; Tue, 15 Feb 2011 03:32:49 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id r24sm2390434yba.6.2011.02.15.03.32.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Feb 2011 03:32:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Tue, 15 Feb 2011 12:32:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3481D436-8F39-472C-BD8A-1F67415C44A2@bblfish.net> References: To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, paul.hoffman@vpnc.org Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 11:32:26 -0000 On 15 Feb 2011, at 03:49, Paul Wouters wrote: > On Tue, 15 Feb 2011, Peter Gutmann wrote: ( Btw, I could not find the thread of this discussion in context, and = this may be reflected in my reply. It would help to point to the web archive=20= if it's an older post that is being replied to here. ) >=20 >> A public key contains a number of components and options. For example = for ECC >> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, = h for >> binary curves), an indication of the underlying field (prime or = binary), the >> point format, whether point compression is used, polynomial vs. = normal basis, >> whether fixed domain parameters are used, and probably some other = stuff I've >> forgotten. How is all this stuff communicated? >=20 > I see. At the simplest, can one not just take the public key part of the ASN.1 = that comes in an X.509 certificate, and pop that DER encoded in the yet = to be named value field?=20 Pro: it clearly is defined Con: there is a bit of remaining ASN.1, but it's a lot less than before = :-) At least that shows that there is one easy solution.=20 >=20 >> this (a) ain't gonna cut it because it doesn't cover what's required = by TLS >> and (b) requires that your TLS implementation speak DNSSEC (or at = least the >> DNSKEY part of DNSSEC) just to get a key. I can't see TLS = implementors being >> too enthusiastic about this. >=20 > Okay. Assuming this discussion is about publishing a public key in DNSSEC - = let's not care about the format - I would reply the following (a) not sure why this answer was made (b) Using the public key published in DNSSEC does not require that the = TLS=20 implementation speak DNSSEC. Current browsers that deal with millions of = self signed certificates on the internet will show ugly dialogs as they do = now. But future browser that are DNSSEC aware could use keyassure to give a = better dialog. They might not get EV certificate dialog, but at least they will = know that they have connected to the correct service. They can do (b) whether the certificate is published in DNSSEC or = whether the public key is published there. It does not matter. After all the = certificate contains the public key, plus extra information. Henry >=20 > I'll have to do some more reading to ensure I understand everything, = and I'll > write up something for this for you to check. >=20 > Thanks! >=20 > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure Social Web Architect http://bblfish.net/ 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 1F68B3A6E36 for ; Mon, 14 Feb 2011 21:11:48 -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 QOGb1hoJXHKK for ; Mon, 14 Feb 2011 21:11:47 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1377D3A6D93 for ; Mon, 14 Feb 2011 21:11: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 77ABBC504; Tue, 15 Feb 2011 00:12:09 -0500 (EST) Date: Tue, 15 Feb 2011 00:12:08 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D59F233.7080708@vpnc.org> Message-ID: References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> <20110215022103.GA2874@odin.mars.sol> <4D59F233.7080708@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] publishing the public key 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, 15 Feb 2011 05:11:48 -0000 On Mon, 14 Feb 2011, Paul Hoffman wrote: >> Why does TLS service have to send cert/cert chain? > > Because that is what is required by the TLS standard. We should not be trying > to modify the TLS spec in this WG. I understand, but there IS a relationship here. With DANE, you have an alternative to PKIX-TLS. So such a change would affect TLS, but would require DANE. Similarly, the TLS group could say "we won't add bare public key because there is no validation for it" and they'd send me back to DANE. So please don't call bare public key out of scope yet. 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 A990C3A6E24 for ; Mon, 14 Feb 2011 19:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.015 X-Spam-Level: X-Spam-Status: No, score=-100.015 tagged_above=-999 required=5 tests=[AWL=-0.569, 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 M5qTxNSU9RBQ for ; Mon, 14 Feb 2011 19:25:15 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D4F823A6E21 for ; Mon, 14 Feb 2011 19:25:15 -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 p1F3PdUn071742 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Feb 2011 20:25:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D59F233.7080708@vpnc.org> Date: Mon, 14 Feb 2011 19:25:39 -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: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> <20110215022103.GA2874@odin.mars.sol> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 03:25:19 -0000 On 2/14/11 6:46 PM, Paul Wouters wrote: > Why does TLS service have to send cert/cert chain? Because that is what is required by the TLS standard. We should not be trying to modify the TLS spec in this WG. 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 5545E3A6C2B for ; Mon, 14 Feb 2011 18:49:25 -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 r3OAWtAtwRaA for ; Mon, 14 Feb 2011 18:49:24 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4771D3A6C27 for ; Mon, 14 Feb 2011 18:49: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 3009DC57C; Mon, 14 Feb 2011 21:49:48 -0500 (EST) Date: Mon, 14 Feb 2011 21:49:47 -0500 (EST) From: Paul Wouters To: Peter Gutmann 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, paul.hoffman@vpnc.org Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 02:49:25 -0000 On Tue, 15 Feb 2011, Peter Gutmann wrote: > A public key contains a number of components and options. For example for ECC > there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h for > binary curves), an indication of the underlying field (prime or binary), the > point format, whether point compression is used, polynomial vs. normal basis, > whether fixed domain parameters are used, and probably some other stuff I've > forgotten. How is all this stuff communicated? I see. > this (a) ain't gonna cut it because it doesn't cover what's required by TLS > and (b) requires that your TLS implementation speak DNSSEC (or at least the > DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors being > too enthusiastic about this. Okay. I'll have to do some more reading to ensure I understand everything, and I'll write up something for this for you to check. Thanks! 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 14DFE3A6E18 for ; Mon, 14 Feb 2011 18:46: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 60eacWxH1zhQ for ; Mon, 14 Feb 2011 18:46:04 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id EBD733A6E0F for ; Mon, 14 Feb 2011 18:46:03 -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 D92C7C57C; Mon, 14 Feb 2011 21:46:26 -0500 (EST) Date: Mon, 14 Feb 2011 21:46:26 -0500 (EST) From: Paul Wouters To: Scott Schmit In-Reply-To: <20110215022103.GA2874@odin.mars.sol> Message-ID: References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> <20110215022103.GA2874@odin.mars.sol> 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] publishing the public key 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, 15 Feb 2011 02:46:05 -0000 On Mon, 14 Feb 2011, Scott Schmit wrote: > > > People keep saying that, but I don't think it's true. This is always an > option: > > In some order: > * Client looks up bare key in DNS > * Client connects to TLS service, TLS service sends cert/cert chain Why does TLS service have to send cert/cert chain? The client already has all it needs to know, the bare public key and the DNSSEC validation asserting the key is validated for use. > Then, instead of comparing the key/hash of key to the whole cert, the > client picks out the public key and compares them (or their hashes). If > they match, use the cert as before. the problem is if cert now contains a CN=www.paypal.com. Browser vendors do not want to ever display information that has no been validated, and for DANE public keys, none of the certificate is validated. This is why its better not to drag in these things to begin with. > There are problems with this approach, but I'd rather the conversation > not stop with "it's impossible to put bare keys in DNS until TLS > supports it directly!" Instead, I'd prefer we discuss the problems that > a bare key approach would need to deal with. I suspect most of them are > at least related to the question of what cert fields to pay attention > to. I'd be in favour of this, though I also understand people don't want to add types for vapourware. > Some issues that would need to be understood/resolved: > * the bare key doesn't tell you anything about the algorithm it's for > (or how to interpret it, really) The RRTYPE would need to tell you. Currently, we only have the "hash type" (section 2.2) though that could perhaps be expanded to also contain the public key type. Or alternatively, we add another field similar to how DNSKEY describes the key algorithm (and possibly using the same values) > * a hacker could potentially alter the certificate in some unexpected > way (usually only affects EE certs if the TA certs are well-protected) > from what the service owner expected -- whether this matters depends on > what you were getting out of the other cert fields. This is why "bare public key" has no PKIX container. 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 6DD3C3A6E0F for ; Mon, 14 Feb 2011 18:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.035 X-Spam-Level: X-Spam-Status: No, score=-100.035 tagged_above=-999 required=5 tests=[AWL=-0.589, 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 chIk-LC5Lj1w for ; Mon, 14 Feb 2011 18:35:00 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9A2943A6C0B for ; Mon, 14 Feb 2011 18:35: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 p1F2ZONO070271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Feb 2011 19:35:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D59E66B.1090808@vpnc.org> Date: Mon, 14 Feb 2011 18:35: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: <276E4E98-EAB9-4C11-9FD1-08B6B7F73FFE@kumari.net> In-Reply-To: <276E4E98-EAB9-4C11-9FD1-08B6B7F73FFE@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #14 - publishing the public key 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, 15 Feb 2011 02:35:01 -0000 Personally, I don't see much use for bare public keys, but I hear that many people do, and I don't see much harm in adding them. However, if the WG wants to add them, I would want to see some wording for how the on-the-wire format would look. That is, you can't just put the bits of the public key there: you also have to say what the signature algorithm is and, if the algorithm requires parameters, what the parameters are. Any of the folks who seem most in favor of this: please suggest some wording here. You need to say what the format is and how the TLS client would compare the value gotten from the TLSA RR with the certificate they get in the TLS handshake. --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 1678C3A6E19 for ; Mon, 14 Feb 2011 18:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 dIpPvCVwO1Bu for ; Mon, 14 Feb 2011 18:25:53 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 0AA093A6C39 for ; Mon, 14 Feb 2011 18:25:52 -0800 (PST) Received: from [172.26.49.198] (unknown [72.14.228.1]) by vimes.kumari.net (Postfix) with ESMTPSA id 7D3C01B40921; Mon, 14 Feb 2011 21:26:16 -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, 14 Feb 2011 21:26:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <276E4E98-EAB9-4C11-9FD1-08B6B7F73FFE@kumari.net> References: To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [keyassure] Issue #14 - publishing the public key 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, 15 Feb 2011 02:25:54 -0000 [ Subject updated to include the issue number - apologies if this makes = your MUA crazy. ]=20 We have this particular item listed as an issue in the issue tracker so = I figured that we might as well keep track of the progress we are making = on this, so let's discuss it an issue and figure out how / what we would = like to do about it[0]... (Also known as, issue #14 is officially open = :-)) W [0]: Yes, I realize that we are already discussing it, but I'm trying = hard to use the issue tracker to actually work through the open issues, = track what we are deciding, etc. I have seen it being used very = effectively, especially to help newcomers understand what has been = discussed and what has been decided. On Feb 14, 2011, at 8:35 PM, Paul Wouters wrote: > On Tue, 15 Feb 2011, Peter Gutmann wrote: >=20 >>> The public key's type and raw blob will be obtained from DNSSEC, so = this is >>> no longer required to be conveyed to the client from the server via = a PKIX >>> certificate or other ASN.1 structures. >>=20 >> But what format is the "type and raw blob" in? You need some way of = encoding >> it, and if it's not the standard ASN.1 format what are you going to = use? >=20 > I'm not sure I understand your question. The key would encoded in DNS, = likely in a > format similar to DNSKEY. >=20 > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=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 0A9B03A6E14 for ; Mon, 14 Feb 2011 18:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.19 X-Spam-Level: X-Spam-Status: No, score=-100.19 tagged_above=-999 required=5 tests=[AWL=2.410, 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 fbUiPktDv9Zt for ; Mon, 14 Feb 2011 18:20:41 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 17B9D3A6E12 for ; Mon, 14 Feb 2011 18:20:41 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id 820E1g0031c6gX8562M61X; Tue, 15 Feb 2011 02:21:06 +0000 Received: from olympia.mars.sol ([68.33.77.0]) by omta23.westchester.pa.mail.comcast.net with comcast id 82M51g00400PQ6U3j2M5U6; Tue, 15 Feb 2011 02:21:05 +0000 Received: from olympia.mars.sol (localhost [127.0.0.1]) by olympia.mars.sol (8.14.4/8.14.3) with ESMTP id p1F2L3hN014884 for ; Mon, 14 Feb 2011 21:21:03 -0500 Received: (from draco@localhost) by olympia.mars.sol (8.14.4/8.14.4/Submit) id p1F2L3hp014882 for keyassure@ietf.org; Mon, 14 Feb 2011 21:21:03 -0500 Date: Mon, 14 Feb 2011 21:21:03 -0500 From: Scott Schmit To: keyassure@ietf.org Message-ID: <20110215022103.GA2874@odin.mars.sol> Mail-Followup-To: keyassure@ietf.org References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110214124617.GA31136@LK-Perkele-VI.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [keyassure] publishing the public key 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, 15 Feb 2011 02:20:45 -0000 On Mon, Feb 14, 2011 at 02:46:17PM +0200, Ilari Liusvaara wrote keyassure: > On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote: > > Hi, > > > > In draft-dane-04 [1] one can currently only publish either a signature > > or a certificate in the DNS. That is the only allowed formats of the > > resource record are as specified in section 2.2 > > > > 1 -- Hash of an end-entity certificate > > 2 -- Full end-entity certificate in DER encoding > > 3 -- Hash of an certification authority's certificate > > 4 -- Full certification authority's certificate in DER encoding > > > > Why not publish the only piece of the certificate that is important in > > public key cryptography: the public key. ( This is what WebID does > > currently ) This should be shorter than the certificate, and though it > > will be longer than the signature, it will be a lot more useful, tying > > the publisher much less to a particular serialisation format. So you > > reduce the PGP/X509 disagreements. > > Unfortunately TLS requires sending the full certificate. Yes, one could > define a new certificate type that contained just the public key, but > that would require a IETF consensus (RFC through TLS working > group[1]). > People keep saying that, but I don't think it's true. This is always an option: In some order: * Client looks up bare key in DNS * Client connects to TLS service, TLS service sends cert/cert chain Then, instead of comparing the key/hash of key to the whole cert, the client picks out the public key and compares them (or their hashes). If they match, use the cert as before. If later the TLS WG develops a bare key option to TLS, this should transparently support that (the processing changes, but otherwise, it's the same). There are problems with this approach, but I'd rather the conversation not stop with "it's impossible to put bare keys in DNS until TLS supports it directly!" Instead, I'd prefer we discuss the problems that a bare key approach would need to deal with. I suspect most of them are at least related to the question of what cert fields to pay attention to. Some issues that would need to be understood/resolved: * the bare key doesn't tell you anything about the algorithm it's for (or how to interpret it, really) * a hacker could potentially alter the certificate in some unexpected way (usually only affects EE certs if the TA certs are well-protected) from what the service owner expected -- whether this matters depends on what you were getting out of the other cert fields. 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 4C51D3A6DF7 for ; Mon, 14 Feb 2011 17:34:56 -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 fR3LM9UUzeVL for ; Mon, 14 Feb 2011 17:34:55 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E9C633A6A0C for ; Mon, 14 Feb 2011 17:34: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 72D00C504; Mon, 14 Feb 2011 20:35:17 -0500 (EST) Date: Mon, 14 Feb 2011 20:35:16 -0500 (EST) From: Paul Wouters To: Peter Gutmann 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] publishing the public key 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, 15 Feb 2011 01:34:56 -0000 On Tue, 15 Feb 2011, Peter Gutmann wrote: >> The public key's type and raw blob will be obtained from DNSSEC, so this is >> no longer required to be conveyed to the client from the server via a PKIX >> certificate or other ASN.1 structures. > > But what format is the "type and raw blob" in? You need some way of encoding > it, and if it's not the standard ASN.1 format what are you going to use? I'm not sure I understand your question. The key would encoded in DNS, likely in a format similar to DNSKEY. 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 6085F3A6D9B for ; Mon, 14 Feb 2011 11:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 3BSB8XBnmrbO for ; Mon, 14 Feb 2011 11:06:46 -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 313573A6D9A for ; Mon, 14 Feb 2011 11:06:45 -0800 (PST) Received: by fxm9 with SMTP id 9so6054335fxm.31 for ; Mon, 14 Feb 2011 11:07:09 -0800 (PST) Received: by 10.223.100.2 with SMTP id w2mr5048588fan.115.1297710428813; Mon, 14 Feb 2011 11:07:08 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id a6sm1091486fak.1.2011.02.14.11.07.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 11:07:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201102141829.p1EITKHc009151@fs4113.wdf.sap.corp> Date: Mon, 14 Feb 2011 20:07:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4487480D-900D-4416-8437-583693908163@bblfish.net> References: <201102141829.p1EITKHc009151@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 19:06:48 -0000 On 14 Feb 2011, at 19:29, Martin Rex wrote: > Henry Story wrote: >>=20 >>> The current approach of admins to run a TLS server with a bare = public >>> key is to generate themselves a self-signed (X.509v1) Certificate. >>> That is probably what many folks are doing when protecting Web = access to >>> their HomeNAS, Home DSL-router, Home DVB-s receiver, etc. >>>=20 >>> This works with the installed base, in particular with the installed >>> base of servers. Though it doesn't work that well with Web Browsers >>> as clients. In particular, many recent browers are pretty badly = broken >>> when it comes to a sensible UI for servers using a self-signed cert. >>=20 >> Indeed, and this is why keyassure is going to be so useful for those = people.=20 >> They must just be itching to pop their public keys in DNSSEC as soon = as the=20 >> first browser vendors implement it. So you are guaranteed a large = community >> to spread the word and give you feedback. And I think Browser Vendors = will >> be very keen to implement this, as well as DNSSEC of course, given = the >> terrible state of DNS. I was thinking of the issue brought up by the EFF SSL Observatory = project,=20 that they presented at the Choas Communication Congress in Berlin right after Christmas 2010 in a talk entitled "Is the SSLiverse a safe place?" https://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html And you can get video on youtube. In particular if you look at slide 10 = (of 56) =20 = http://www.youtube.com/watch?v=3DVUKCDm04AqI&feature=3Dplayer_detailpage#t= =3D631s They point out that of the 16.2 Million servers listening to port 443 , = only 11.3 Million started an SSL handshake, and only 4.3 Million had a valid cert chain. = So that means that there are immediately 7 Million servers which could be helped if getting = an SSL certificate could be made a lot easier. And this is not counting how many others = would start deploying SSL if it was easier to do. I can't remember if in their presentation they tell us how many valid = self signed certs they found out there... One couls download the DB you query = it locally... > Not at all. The average Home user (private home DSL subscriber) is > not a DNS admin, let alone a DNSSEC admin. So for accessing the = Web-UIs > Home devices/equipment/gadgets, DANE will be mostly irrelevant. Ah you mean for accessing the SSL protected internal servers.... >=20 > But maybe some of the Browser maintainers fix their UIs and start > to distinguish direct access to local resources on private networks > (such as 192.169.x.x and 10.x.x.x and hostnames without domains = attached) > from access to resources on the internet. And stop behaving like = nagware > for commercial CAs. I see what you are getting at... Interesting thought. It's tricky as to how one should do that correctly = without there being a danger in large organisations of people putting up evil SSL = proxies. Perhaps the following could work. Imagine that these devices come = shipping with DNSSEC servers that work internally to resolve those = addresses, and which use keyassure to publish the public key... Perhaps = there is something at the DNSSEC level that can be done there...?=20 Henry >=20 > -Martin Social Web Architect http://bblfish.net/ 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 E3C153A6D7B for ; Mon, 14 Feb 2011 10:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.197 X-Spam-Level: X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 ttN20pp16rIu for ; Mon, 14 Feb 2011 10:29:00 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4891F3A6D4D for ; Mon, 14 Feb 2011 10:28:59 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1EITKCF008726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2011 19:29:21 +0100 (MET) From: Martin Rex Message-Id: <201102141829.p1EITKHc009151@fs4113.wdf.sap.corp> To: henry.story@bblfish.net (Henry Story) Date: Mon, 14 Feb 2011 19:29:20 +0100 (MET) In-Reply-To: from "Henry Story" at Feb 14, 11 06:59:33 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] publishing the public key 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, 14 Feb 2011 18:29:02 -0000 Henry Story wrote: > > > The current approach of admins to run a TLS server with a bare public > > key is to generate themselves a self-signed (X.509v1) Certificate. > > That is probably what many folks are doing when protecting Web access to > > their HomeNAS, Home DSL-router, Home DVB-s receiver, etc. > > > > This works with the installed base, in particular with the installed > > base of servers. Though it doesn't work that well with Web Browsers > > as clients. In particular, many recent browers are pretty badly broken > > when it comes to a sensible UI for servers using a self-signed cert. > > Indeed, and this is why keyassure is going to be so useful for those people. > They must just be itching to pop their public keys in DNSSEC as soon as the > first browser vendors implement it. So you are guaranteed a large community > to spread the word and give you feedback. And I think Browser Vendors will > be very keen to implement this, as well as DNSSEC of course, given the > terrible state of DNS. Not at all. The average Home user (private home DSL subscriber) is not a DNS admin, let alone a DNSSEC admin. So for accessing the Web-UIs Home devices/equipment/gadgets, DANE will be mostly irrelevant. But maybe some of the Browser maintainers fix their UIs and start to distinguish direct access to local resources on private networks (such as 192.169.x.x and 10.x.x.x and hostnames without domains attached) from access to resources on the internet. And stop behaving like nagware for commercial CAs. -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 055B63A6D5C for ; Mon, 14 Feb 2011 09:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 cl6Lu0e9wP7Z for ; Mon, 14 Feb 2011 09:59:19 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 62AC93A6AB3 for ; Mon, 14 Feb 2011 09:59:19 -0800 (PST) Received: by bwz12 with SMTP id 12so6281624bwz.31 for ; Mon, 14 Feb 2011 09:59:42 -0800 (PST) Received: by 10.204.14.6 with SMTP id e6mr1052082bka.9.1297706381856; Mon, 14 Feb 2011 09:59:41 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id w3sm1909873bkt.5.2011.02.14.09.59.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 09:59:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201102141733.p1EHXFfR005827@fs4113.wdf.sap.corp> Date: Mon, 14 Feb 2011 18:59:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201102141733.p1EHXFfR005827@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 17:59:21 -0000 On 14 Feb 2011, at 18:33, Martin Rex wrote: > Paul Wouters wrote: >>=20 >> On Mon, 14 Feb 2011, Henry Story wrote: >>>=20 >>> Why not publish the only piece of the certificate that is important >>> in public key cryptography: the public key. >>=20 >> Yes. This was asked by others including me as well. People thought it = would >> be no problem to add this to dane once a bare public key TLS method = exists. >>=20 >>> An important question is of course: how much bandwidth does one = save? >>=20 >> Bandwidth does not really matter. What matters is latency >> (less round trips) and a riddance of ASN.1 parsing. >=20 > The current approach of admins to run a TLS server with a bare public > key is to generate themselves a self-signed (X.509v1) Certificate. > That is probably what many folks are doing when protecting Web access = to > their HomeNAS, Home DSL-router, Home DVB-s receiver, etc. >=20 > This works with the installed base, in particular with the installed > base of servers. Though it doesn't work that well with Web Browsers > as clients. In particular, many recent browers are pretty badly = broken > when it comes to a sensible UI for servers using a self-signed cert. Indeed, and this is why keyassure is going to be so useful for those = people.=20 They must just be itching to pop their public keys in DNSSEC as soon as = the=20 first browser vendors implement it. So you are guaranteed a large = community to spread the word and give you feedback. And I think Browser Vendors = will be very keen to implement this, as well as DNSSEC of course, given the = terrible state of DNS. =46rom WebID's perspective we love keyassure, because it will make = deployment of https=20 so much easier, and so make it much easier to create the Secure = Decentralised=20 Social Web which we want to build. In fact we have an issue open there = to follow=20 your work here http://www.w3.org/2005/Incubator/webid/track/issues/5 It also permits "Turning every Web Server into a CA" http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html which is pretty cool I think. So all of the above will work as keyassure is written out now, but I do=20= think that if one can reduce the bandwidth used by DNSSEC as much as = possible as well as get the best value for the bits used - which I think the = public key does - all the better. That will reduce the talk of DNS as a Denial of = Serice=20 Attack amplifier. Henry >=20 > -Martin Social Web Architect http://bblfish.net/ 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 62C7C3A6AC1 for ; Mon, 14 Feb 2011 09:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.192 X-Spam-Level: X-Spam-Status: No, score=-10.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 xPAD0kHTKizH for ; Mon, 14 Feb 2011 09:32: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 5AA6F3A6D6D for ; Mon, 14 Feb 2011 09:32:56 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p1EHXGpb027480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Feb 2011 18:33:16 +0100 (MET) From: Martin Rex Message-Id: <201102141733.p1EHXFfR005827@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Mon, 14 Feb 2011 18:33:15 +0100 (MET) In-Reply-To: from "Paul Wouters" at Feb 14, 11 09:19:32 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] publishing the public key 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, 14 Feb 2011 17:32:57 -0000 Paul Wouters wrote: > > On Mon, 14 Feb 2011, Henry Story wrote: > > > > Why not publish the only piece of the certificate that is important > > in public key cryptography: the public key. > > Yes. This was asked by others including me as well. People thought it would > be no problem to add this to dane once a bare public key TLS method exists. > > > An important question is of course: how much bandwidth does one save? > > Bandwidth does not really matter. What matters is latency > (less round trips) and a riddance of ASN.1 parsing. The current approach of admins to run a TLS server with a bare public key is to generate themselves a self-signed (X.509v1) Certificate. That is probably what many folks are doing when protecting Web access to their HomeNAS, Home DSL-router, Home DVB-s receiver, etc. This works with the installed base, in particular with the installed base of servers. Though it doesn't work that well with Web Browsers as clients. In particular, many recent browers are pretty badly broken when it comes to a sensible UI for servers using a self-signed cert. -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 8E4F53A6D4D for ; Mon, 14 Feb 2011 08:37:22 -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 JyEjB9W0566Q for ; Mon, 14 Feb 2011 08:37:21 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id AFC613A6D4C for ; Mon, 14 Feb 2011 08: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 CF7ADC57C; Mon, 14 Feb 2011 11:37:43 -0500 (EST) Date: Mon, 14 Feb 2011 11:37:43 -0500 (EST) From: Paul Wouters To: Peter Gutmann 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] publishing the public key 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, 14 Feb 2011 16:37:22 -0000 On Tue, 15 Feb 2011, Peter Gutmann wrote: >> If you want to help writing a bare public key TLS variant, please contact me. > > There is no such thing as a "bare public key". Public keys have complex > composite structures, and to encode that you need something like ASN.1 (unless > you want to invent your own format, which is going to make things even > uglier). At this point you're duplicating a significant chunk of ASN.1- > parsing code outside the certificate code that would normally handle it. This > does not seem like a good direction to go in. The public key's type and raw blob will be obtained from DNSSEC, so this is no longer required to be conveyed to the client from the server via a PKIX certificate or other ASN.1 structures. No other certificate information is desired. Perhaps some other mode is required if the client needs to be authenticated by the server, but the use we are talking about here is for unauthenticated clients, eg the currently deployed "https" mode without user certs/credentials. 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 9407B3A6B77 for ; Mon, 14 Feb 2011 07:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-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 rX8q4gmJzbws for ; Mon, 14 Feb 2011 07:29:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DC25F3A6C0A for ; Mon, 14 Feb 2011 07:29:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pp0NY-0004T9-Il; Mon, 14 Feb 2011 07:30:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: henry.story@bblfish.net X-Trac-Project: dane Date: Mon, 14 Feb 2011 15:30:20 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/14#comment:1 Message-ID: <064.9c2a9e6ce3b5118bc3ea04af167c417c@tools.ietf.org> References: <055.52e849c52f563625a28428b98f4ca55c@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <055.52e849c52f563625a28428b98f4ca55c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henry.story@bblfish.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #14 (new): Bare Public Keys X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 15:29:59 -0000 #14: Bare Public Keys Comment(by henry.story@…): There is also a longer thread from Febuary 14th 2011 on the subject [http://www.ietf.org/mail-archive/web/keyassure/current/msg01780.html publishing the public key] -- --------------------------------+------------------------------------------- Reporter: mlepinsk@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: protocol | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: dane 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 C79903A6BCD for ; Mon, 14 Feb 2011 07:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.079 X-Spam-Level: X-Spam-Status: No, score=-100.079 tagged_above=-999 required=5 tests=[AWL=-0.633, 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 LZyUHzIFzOOG for ; Mon, 14 Feb 2011 07:24:00 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1B8C23A6D20 for ; Mon, 14 Feb 2011 07:24: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 p1EFOMF8045257 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Feb 2011 08:24:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D594927.2010604@vpnc.org> Date: Mon, 14 Feb 2011 07:24: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: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <9A1C69DD-0AA3-470A-AA7A-A1629E94440C@bblfish.net> In-Reply-To: <9A1C69DD-0AA3-470A-AA7A-A1629E94440C@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 15:24:00 -0000 On 2/14/11 6:54 AM, Henry Story wrote: > Sorry. I don't have a good picture of the web of specs that dane is tied into. Please read the TLSA document. It is "tied" to TLS and DTLS only. 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 1F07F3A6D20 for ; Mon, 14 Feb 2011 07:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.103 X-Spam-Level: X-Spam-Status: No, score=-100.103 tagged_above=-999 required=5 tests=[AWL=-0.657, 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 fq8KSHaUIs1u for ; Mon, 14 Feb 2011 07:17:32 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 751153A6B53 for ; Mon, 14 Feb 2011 07:17: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 p1EFHskg045015 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 14 Feb 2011 08:17:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D5947A3.8080602@vpnc.org> Date: Mon, 14 Feb 2011 07:17:55 -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: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> In-Reply-To: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 15:17:33 -0000 On 2/14/11 2:20 AM, Henry Story wrote: > Why not publish the only piece of the certificate that is important > in public key cryptography: the public key. There is an open issue for this question. See #14 in . When the chairs want to open that for discussion, there will certainly be lots of opinions on it. 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 1ACB03A6A97 for ; Mon, 14 Feb 2011 06:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.656 X-Spam-Level: X-Spam-Status: No, score=-3.656 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 GRTju6yM8zkn for ; Mon, 14 Feb 2011 06:54:40 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8FAB43A6D50 for ; Mon, 14 Feb 2011 06:54:40 -0800 (PST) Received: by bwz12 with SMTP id 12so6079547bwz.31 for ; Mon, 14 Feb 2011 06:55:02 -0800 (PST) Received: by 10.204.52.138 with SMTP id i10mr3503785bkg.23.1297695301706; Mon, 14 Feb 2011 06:55:01 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id rc9sm1832745bkb.14.2011.02.14.06.54.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 06:55:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Henry Story In-Reply-To: Date: Mon, 14 Feb 2011 15:54:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1C69DD-0AA3-470A-AA7A-A1629E94440C@bblfish.net> References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 14:54:42 -0000 On 14 Feb 2011, at 15:19, Paul Wouters wrote: > On Mon, 14 Feb 2011, Henry Story wrote: >=20 >> In draft-dane-04 [1] one can currently only publish either a = signature or a certificate in the DNS. That is the only allowed formats = of the resource record are as specified in section 2.2 >>=20 >> 1 -- Hash of an end-entity certificate >> 2 -- Full end-entity certificate in DER encoding >> 3 -- Hash of an certification authority's certificate >> 4 -- Full certification authority's certificate in DER encoding >>=20 >> Why not publish the only piece of the certificate that is important = in public key cryptography: the public key. ( This is what WebID does = currently ) This should be shorter than the certificate, and though it = will be longer than the signature, it will be a lot more useful, tying = the publisher much less to a particular serialisation format. So you = reduce the PGP/X509 disagreements. >=20 > Yes. This was asked by others including me as well. People thought it = would be no > problem to add this to dane once a bare public key TLS method exists. >=20 >> An important question is of course: how much bandwidth does one = save? >=20 > Bandwidth does not really matter. What matters is latency (less round = trips) and a riddance of ASN.1 > parsing. >=20 > If you want to help writing a bare public key TLS variant, please = contact me. What do you mean by a bare public key TLS variant? You mean start an = IETF group to spec out how the client and the server should communicate in a TLS = variant that would not require the server to send a certificate? Or is this = something that one needs to do to explain how a User Agent can prove authenticity of = the server from a public key alone? (That's so simple it's a bit difficult to even see = how to write it) Or is it just that one needs to specify text for dane? Or is dane a = subproject of=20 keyassure, and this is referring to some other project here? Or is do we just need to specify some text that is going to go into dane? Sorry. I don't have a good picture of the web of specs that dane is tied = into. If its longer project I probably won't have time to do this myself as I = am already=20 quite tied up with WebID. But if I know what is needed we could write up = a little=20 note on the W3C WebID Incubator Group ( http://tinyurl.com/webidxg ) for = our final=20 report on what browser improvements would be helpful, and why. Hopefully = this will=20 be something that the browser vendors at the W3C could have a closer = look at. But it really depends on how long the project is. Perhaps there are people = on our list who have more time to participate. Perhaps this won't take so long to do... Henry >=20 > Paul Social Web Architect http://bblfish.net/ 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 0E5913A6D52 for ; Mon, 14 Feb 2011 06:19:13 -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 Pw7RCxPgGUbX for ; Mon, 14 Feb 2011 06:19:12 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 3EF693A6D4A for ; Mon, 14 Feb 2011 06:19:11 -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 190C3C57C; Mon, 14 Feb 2011 09:19:33 -0500 (EST) Date: Mon, 14 Feb 2011 09:19:32 -0500 (EST) From: Paul Wouters To: Henry Story In-Reply-To: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> Message-ID: References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.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] publishing the public key 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, 14 Feb 2011 14:19:13 -0000 On Mon, 14 Feb 2011, Henry Story wrote: > In draft-dane-04 [1] one can currently only publish either a signature or a certificate in the DNS. That is the only allowed formats of the resource record are as specified in section 2.2 > > 1 -- Hash of an end-entity certificate > 2 -- Full end-entity certificate in DER encoding > 3 -- Hash of an certification authority's certificate > 4 -- Full certification authority's certificate in DER encoding > > Why not publish the only piece of the certificate that is important in public key cryptography: the public key. ( This is what WebID does currently ) This should be shorter than the certificate, and though it will be longer than the signature, it will be a lot more useful, tying the publisher much less to a particular serialisation format. So you reduce the PGP/X509 disagreements. Yes. This was asked by others including me as well. People thought it would be no problem to add this to dane once a bare public key TLS method exists. > An important question is of course: how much bandwidth does one save? Bandwidth does not really matter. What matters is latency (less round trips) and a riddance of ASN.1 parsing. If you want to help writing a bare public key TLS variant, please contact me. 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 AA6C73A6D48 for ; Mon, 14 Feb 2011 06:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 xHavxuKCQgj8 for ; Mon, 14 Feb 2011 06:02:02 -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 1DA4D3A6D45 for ; Mon, 14 Feb 2011 06:02:02 -0800 (PST) Received: by gyd12 with SMTP id 12so2313841gyd.31 for ; Mon, 14 Feb 2011 06:02:24 -0800 (PST) Received: by 10.236.110.6 with SMTP id t6mr1397531yhg.17.1297692144680; Mon, 14 Feb 2011 06:02:24 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id z10sm1575913yhz.24.2011.02.14.06.02.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 06:02:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <20110214124617.GA31136@LK-Perkele-VI.localdomain> Date: Mon, 14 Feb 2011 15:02:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BADC4EE-F761-4AD7-8FED-A75F46FEC5E2@bblfish.net> References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> <20110214124617.GA31136@LK-Perkele-VI.localdomain> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 14:02:04 -0000 On 14 Feb 2011, at 13:46, Ilari Liusvaara wrote: > On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote: >> Hi, >>=20 >> In draft-dane-04 [1] one can currently only publish either a = signature >> or a certificate in the DNS. That is the only allowed formats of the >> resource record are as specified in section 2.2 >>=20 >> 1 -- Hash of an end-entity certificate >> 2 -- Full end-entity certificate in DER encoding >> 3 -- Hash of an certification authority's certificate >> 4 -- Full certification authority's certificate in DER encoding >>=20 >> Why not publish the only piece of the certificate that is important = in >> public key cryptography: the public key. ( This is what WebID does >> currently ) This should be shorter than the certificate, and though = it >> will be longer than the signature, it will be a lot more useful, = tying >> the publisher much less to a particular serialisation format. So you >> reduce the PGP/X509 disagreements. >=20 > Unfortunately TLS requires sending the full certificate. Yes, one = could > define a new certificate type that contained just the public key, but > that would require a IETF consensus (RFC through TLS working > group[1]). As you certainly know, but as you don't know what I know let me be = specific, TLS does not currently make any claims as to what should be published=20 in DNS. In fact TLS requires(?) that the client will look to see if it = can=20 build a chain of certificates from the server cert to a trusted=20 Certificate Authority (CA), and show that the CA authenticates each = element in the chain. =20 keyassure (or is it dane?) will, as I understand, allow another way for = trust=20 to be established by tying the identity of the server to DNS, rather = than=20 (or in addition to) tying it to a CA.=20 So a User Agent (UA) that is keyassure enabled connecting to a TLS = server =20 should receive as all UAs now do an X509 certificate. What will be = unusual is that this certificate could be self-signed.=20 In the TLS negotiation the UA will have proof that the server knows the = private=20 key of the public key sent in the certificate, following existing TLS = specs. But=20 since the Certificate will be self signed the UA will not be able to get = confirmation from a CA that the service that knows that private key is the service = that has global identity alice.example:443 . An evil agent known as Eve could = have create a=20 public/private key pair and generate a self signed certificate = asserting that it=20 is the certificate of service alice.example:443 but place that on the = server she likes to think of as eve.example:443 . So what do we really need? We just need a trusted service to tell us = that=20 alice.example:443 is indeed the knower of the given private key. DNS is = of course the=20 perfect place to get that information, especially when the information = can be trusted. So what we need is DNS to say the following: knowsPrivateKeyOfPublicKey [ a RSAPublicKey; ... = ] . Once that is said, all is said. My point after that is that so much is said there, that the server would = not even need to send the certificate anymore (saving yet more bandwidth) > Then one would define new DANE ceritifcate type (3 [2] or 5/6) to > match that. ok, so it is possible to do it.=20 But I think one should investigate a bit more if one cannot get = consensus that one does not really needs anything more than the public key. After all = this is public key cryptography we are using! >=20 > >=20 > I don't think that would be possible to use without new certificate > type either. I think you could just use the ASN.1 public key object, and DER encode it. I think that is even specified somewhere. But ok, if the certificate=20= type is important... Note that the object does not even have to be = signed (DNSSEC signs things) > As for bandwidth, sure it would save some. One can send well-secured > key in roughly 80 bytes total (including CertificateType extension). > Modern X.509 certs are far larger[3], even if restricted to bare > minimum fields. The important calculation would have to be: how many packets does one = save when sending: - a hash of an entity certificate - a public key only - a pretty minimal certificate - a usual key=20 =20 And here one would need two figures:=20 a the size of the information b the size after the DNSSEC wrappers that have to be added to the = message. Where the second size is more important of course > As for what this would be useful for: If the raw key format would > be easily parsed, it would save lots of tricky ASN.1 and X.509 > parsing (yes, there are libraries for that) Indeed. That is partly what my thought experiment was getting at: you=20 could even remove the ASN.1 from the server, by not having it send = server certs. Though perhaps to bring this up here is to risk confusing issues. >=20 > [1] Not entierely accurate, it is RFC approved by IESG (and they'll > consult TLS WG). >=20 > [2] Since those 4 types could be collapsed to 2 (2 of those require > second byte to be zero and 2 require nonzero second byte) >=20 > [3] There's also subtle performance issue there. Those certificates > can be so large that TCP windows get overflowed. As consequence, > either one has to break TCP spec (many sites do this) or suffer > a latency hit. >=20 > -Ilari Social Web Architect http://bblfish.net/ 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 EE1BD3A6D1B for ; Mon, 14 Feb 2011 04:47:27 -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 oLJDjHKLfH+g for ; Mon, 14 Feb 2011 04:47:27 -0800 (PST) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by core3.amsl.com (Postfix) with ESMTP id 9D4F43A6D10 for ; Mon, 14 Feb 2011 04:47:26 -0800 (PST) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh04-2.mail.saunalahti.fi (Postfix) with SMTP id 9C5CF13B54F; Mon, 14 Feb 2011 14:47:47 +0200 (EET) Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A018938C967; Mon, 14 Feb 2011 14:47:47 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 5DE402BD48; Mon, 14 Feb 2011 14:47:45 +0200 (EET) Date: Mon, 14 Feb 2011 14:46:17 +0200 From: Ilari Liusvaara To: Henry Story Message-ID: <20110214124617.GA31136@LK-Perkele-VI.localdomain> References: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure@ietf.org Subject: Re: [keyassure] publishing the public key 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, 14 Feb 2011 12:47:28 -0000 On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote: > Hi, > > In draft-dane-04 [1] one can currently only publish either a signature > or a certificate in the DNS. That is the only allowed formats of the > resource record are as specified in section 2.2 > > 1 -- Hash of an end-entity certificate > 2 -- Full end-entity certificate in DER encoding > 3 -- Hash of an certification authority's certificate > 4 -- Full certification authority's certificate in DER encoding > > Why not publish the only piece of the certificate that is important in > public key cryptography: the public key. ( This is what WebID does > currently ) This should be shorter than the certificate, and though it > will be longer than the signature, it will be a lot more useful, tying > the publisher much less to a particular serialisation format. So you > reduce the PGP/X509 disagreements. Unfortunately TLS requires sending the full certificate. Yes, one could define a new certificate type that contained just the public key, but that would require a IETF consensus (RFC through TLS working group[1]). Then one would define new DANE ceritifcate type (3 [2] or 5/6) to match that. I don't think that would be possible to use without new certificate type either. As for bandwidth, sure it would save some. One can send well-secured key in roughly 80 bytes total (including CertificateType extension). Modern X.509 certs are far larger[3], even if restricted to bare minimum fields. As for what this would be useful for: If the raw key format would be easily parsed, it would save lots of tricky ASN.1 and X.509 parsing (yes, there are libraries for that) [1] Not entierely accurate, it is RFC approved by IESG (and they'll consult TLS WG). [2] Since those 4 types could be collapsed to 2 (2 of those require second byte to be zero and 2 require nonzero second byte) [3] There's also subtle performance issue there. Those certificates can be so large that TCP windows get overflowed. As consequence, either one has to break TCP spec (many sites do this) or suffer a latency hit. -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 81A823A6CA3 for ; Mon, 14 Feb 2011 02:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 Rnh5aoQmxyno for ; Mon, 14 Feb 2011 02:20:15 -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 51A933A6CAA for ; Mon, 14 Feb 2011 02:20:14 -0800 (PST) Received: by fxm9 with SMTP id 9so5503012fxm.31 for ; Mon, 14 Feb 2011 02:20:36 -0800 (PST) Received: by 10.223.85.204 with SMTP id p12mr796833fal.146.1297678835968; Mon, 14 Feb 2011 02:20:35 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id e17sm958977fak.10.2011.02.14.02.20.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Feb 2011 02:20:35 -0800 (PST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2011 11:20:33 +0100 Message-Id: <928BE494-C59D-4FFF-9390-C459A4BC2107@bblfish.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [keyassure] publishing the public key 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, 14 Feb 2011 10:20:17 -0000 Hi, In draft-dane-04 [1] one can currently only publish either a signature = or a certificate in the DNS. That is the only allowed formats of the = resource record are as specified in section 2.2 1 -- Hash of an end-entity certificate 2 -- Full end-entity certificate in DER encoding 3 -- Hash of an certification authority's certificate 4 -- Full certification authority's certificate in DER encoding Why not publish the only piece of the certificate that is important in = public key cryptography: the public key. ( This is what WebID does = currently ) This should be shorter than the certificate, and though it = will be longer than the signature, it will be a lot more useful, tying = the publisher much less to a particular serialisation format. So you = reduce the PGP/X509 disagreements. There is no need to send a full certificate. Many users will only need = to tie a name to a public key and to have a guarantee of the integrity = of the information. But the integrity is itself assured by DNSSEC. The = tying of the name to the public key is done by the lookup in DNS, as = with eg: _443._tcp.www.example.com ) So all that is really required is = to return the public key - the type (RSA, DSA, ...) and the fields. This = can be done in ASN.1. The following use case may help: Imagine a future revision of TLS, = which permits the server to not send the server certificate, a bit as = the client_certificate_url extension of TLS 1.2 allows the client to = send a URL to a location of his certificate, instead of sending his = certificate in order to save bandwidth. Here the server just tells the = client to look up his public key in DNSSEC . This would then save = bandwidth at both ends: the server would not need to send his = certificate and DNSSEC would just send the minimal information needed to = confirm.=20 The public key by itself would not be able to contain the types of = restrictions on usage of the key of course: only use for signing, ... = that are available in X509.=20 An important question is of course: how much bandwidth does one save? Henry [1] http://tools.ietf.org/html/draft-ietf-dane-protocol-04 Social Web Architect http://bblfish.net/ 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 AF0183A6B6F for ; Sun, 13 Feb 2011 15:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.140, 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 9OD-jTKXmFJG for ; Sun, 13 Feb 2011 15:53:28 -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 8A8093A69A7 for ; Sun, 13 Feb 2011 15:53:28 -0800 (PST) Received: by ywk9 with SMTP id 9so2052368ywk.31 for ; Sun, 13 Feb 2011 15:53: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=KbnhOq0oDGWFnEM8jRPcdBJFNKBEvPAsX+uvLogqxKE=; b=mXAfFK2DIhpEMKfduJ5y4Zmsqub2r+VH3Z6k5cFZuCJAOjYV6p4x7/sALTszoy2dYo /5V+UFtfY5O+tfpeFrhA3AIRcixh52sWkcktHEqjzdjO4jEyWLA0sGGeSpgoRUXqZE9d p6r+BwDW1UBwlo54ydqRnZwxee2ZSocnYgwWc= 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=JiwcQj0p+2IbosXSi271jezfNE1iXFw91K2Pya+/FZCvNrph+zoB0UQlJM3M4d4gEC FoS4TJ2w5Ak7IumVskbMeEL92uNMJK27oqJLITKqO2GbA9ZupIlIQqU6TO5DOOzNJrMz 6xGSdcDNT1LcpRZyWCfcvyCB18udBBRGBRC8g= MIME-Version: 1.0 Received: by 10.100.167.18 with SMTP id p18mr1313933ane.6.1297641227794; Sun, 13 Feb 2011 15:53:47 -0800 (PST) Received: by 10.100.244.38 with HTTP; Sun, 13 Feb 2011 15:53:47 -0800 (PST) In-Reply-To: <1297620910.1890.28.camel@mattlaptop2.local> References: <1297620910.1890.28.camel@mattlaptop2.local> Date: Sun, 13 Feb 2011 18:53:47 -0500 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=001485f6d1ae6db88c049c32a49e Cc: keyassure Subject: Re: [keyassure] Binding to full TLS encapsulation or STARTTLS 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, 13 Feb 2011 23:53:30 -0000 --001485f6d1ae6db88c049c32a49e Content-Type: text/plain; charset=ISO-8859-1 That openeth a can of worms. While it would be nice to be able to simply open a TLS session rather than start raw and negotiate an upgrade, that is hard to support on the server side unless the server has separate port assignments for raw and TLS service. That works for HTTP, NNTP and a few others. But the IAB and IESG clamped down on dual port assignments and so that scheme only works in some cases. HTTPS is not quite the same thing as HTTP with inband upgrade to SSL. I am not even sure how widely supported the inband upgrade is for HTTP. Not trying to be difficult here, I have really no good scheme for fixing this. On Sun, Feb 13, 2011 at 1:15 PM, Matt McCutchen wrote: > I realized that TLSA as we are currently discussing does not bind keys > to the use of full TLS encapsulation or STARTTLS. I'm thinking this is > OK because it would be pretty ridiculous to multiplex different services > based on the use of full encapsulation or STARTTLS, and clients > generally do not ascribe security significance to the use of one or the > other. E.g., if I bind a key to _3141._tcp.example.com for a service > that uses STARTTLS, I can't think of any scenario in which a client > trying to use full encapsulation would be harmed if a MITM allowed it to > succeed by performing the STARTTLS part directly with the server. It > might be nice to prevent web browsers from talking to STARTTLS services, > but that would be far from a complete solution to the problem of > browsers being a loose cannon for arbitrary connections, nor is it our > responsibility to solve that problem here. > > Sanity check? > > -- > Matt > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001485f6d1ae6db88c049c32a49e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That openeth a can of worms.

While it would be nice to b= e able to simply open a TLS session rather than start raw and negotiate an = upgrade, that is hard to support on the server side unless the server has s= eparate port assignments for raw and TLS service.

That works for HTTP, NNTP and a few others. But the IAB= and IESG clamped down on dual port assignments and so that scheme only wor= ks in some cases.


HTTPS is not quit= e the same thing as HTTP with inband upgrade to SSL.

I am not even sure how widely supported the inband upgr= ade is for HTTP.


Not trying to be d= ifficult here, I have really no good scheme for fixing this.

On Sun, Feb 13, 2011 at 1:15 PM, Matt McCutchen <matt@mattmccutchen.net> = wrote:
I realized that TLSA as we are currently discussing does not bind keys
to the use of full TLS encapsulation or STARTTLS. =A0I'm thinking this = is
OK because it would be pretty ridiculous to multiplex different services based on the use of full encapsulation or STARTTLS, and clients
generally do not ascribe security significance to the use of one or the
other. =A0E.g., if I bind a key to _3141._tcp.example.com for a service
that uses STARTTLS, I can't think of any scenario in which a client
trying to use full encapsulation would be harmed if a MITM allowed it to succeed by performing the STARTTLS part directly with the server. =A0It
might be nice to prevent web browsers from talking to STARTTLS services, but that would be far from a complete solution to the problem of
browsers being a loose cannon for arbitrary connections, nor is it our
responsibility to solve that problem here.

Sanity check?

--
Matt


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



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

--001485f6d1ae6db88c049c32a49e-- 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 7110F3A6B6F for ; Sun, 13 Feb 2011 15:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.218 X-Spam-Level: X-Spam-Status: No, score=-100.218 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_40=-0.185, 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 rX1Uy5pRGxv6 for ; Sun, 13 Feb 2011 15:49:23 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7DFE73A69A7 for ; Sun, 13 Feb 2011 15:49:23 -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 p1DNniA0009589 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 13 Feb 2011 16:49:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D586E17.3030601@vpnc.org> Date: Sun, 13 Feb 2011 15:49:43 -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: <4D584EDC.3040909@gmail.com> <4D585826.10205@cs.tcd.ie> In-Reply-To: <4D585826.10205@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] dane-04 trust anchors 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, 13 Feb 2011 23:49:24 -0000 On 2/13/11 2:16 PM, Stephen Farrell wrote: >> From my personal p-o-v, (i.e. no hats) I don't see that DANE's > handing of additional TA inputs (compared to the things 5280 > needs) can be driven by 5280 since 5280 is silent on the topic. > Equally, I don't think the (sometimes not so great) browser > implementations of TA handling ought drive everything DANE > does. So DANE should decide what it wants basically. Treat the > info as a 5280 TA, as a bare key, as some kind of TAMP-like > thing, whatever meets the use cases, and can be secure enough. This seems like a good way to dissect the topic, except that there is obvious disagreement about what a "5280 TA" is. I would say that treating the TLSA info as a bare key is the clearest statement. 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 CA3233A6C3C for ; Sun, 13 Feb 2011 15:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.4 X-Spam-Level: X-Spam-Status: No, score=-101.4 tagged_above=-999 required=5 tests=[AWL=0.646, 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 wd0yCQsfYfUB for ; Sun, 13 Feb 2011 15:46:31 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DED563A6C42 for ; Sun, 13 Feb 2011 15:46:31 -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 p1DNkp92009511 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 13 Feb 2011 16:46:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D586D6B.2060302@vpnc.org> Date: Sun, 13 Feb 2011 15:46: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: <4D584EDC.3040909@gmail.com> In-Reply-To: <4D584EDC.3040909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] dane-04 trust anchors 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, 13 Feb 2011 23:46:32 -0000 On 2/13/11 1:36 PM, Yaron Sheffer wrote: >> Please re-read section 6.1.1, particularly element (d) there. Your list >> would fall under (d)(4), which is explicitly listed as optional. >> > I believe this characterization is incorrect. 6.1.1.d.4 discusses > "public key parameters", which are never defined, but seem to refer to > actual mathematical parameters of the public key, such as algebraic > groups, generators etc. As you say, they are not defined, so you could be right. However, that doesn't make much sense because I would doubt that needed parameters such as those would be optional; this is why I assumed that they were parameters such as "how long is this key good for" and "what can this key be used for" and so on. > I agree that RFC 5280 is essentially silent about the semantics of > anything in the TA, when it is provided as a self-signed cert. I would > appear that the authors of RFC 2459 (back in Jan. 1999) considered the > self-signed cert that wraps the public key as extraneous. I'm glad we agree here. > However if a > modern browser were to ignore the validity period on a Verisign > top-level CA cert, this would be considered a bug. ...by you, but not by the spec. > I accept that I confused the processing of EE certs with trust anchors. Good. > But it would seem that modern practice diverges *a lot* from RFC 5280. That might be true, but I'm not sure how it is relevant to what we make as MUST-level considerations in the TLSA document. > Moreover, people expect certain behavior from TLS self-signed CA certs > and we should ensure that such behavior (to the extent it is formally > specified) is also followed by a conformant DANE RP. We disagree here: just because people might expect something that is wrong, I do not see why institutionalizing it makes it right. > All the items on my list can appear in intermediate certs, and sometimes > do (with the possible exception of name constraints). So applications > should behave sanely when presented with them. Fully agree. In an intermediate certificate in a chain from a trust anchor, the full PKIX non-TA semantics need to be used. That's not what we are talking about in this thread, 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 859CE3A6C3C for ; Sun, 13 Feb 2011 15:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.163, 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 WxUV8fkXqUKt for ; Sun, 13 Feb 2011 15:09:30 -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 BB9003A6C38 for ; Sun, 13 Feb 2011 15:09:29 -0800 (PST) Received: by gyd12 with SMTP id 12so2040816gyd.31 for ; Sun, 13 Feb 2011 15:09: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=vsPu4B+lJ13db6xl4NTCaKp1qyac1lV0LOE/FoG4wok=; b=RgDuoXW/p/l7Yx3EEie0Fxfriww3pEihp0MaTC1vg4ILloaKBNyfldxxSL0PfDmTXL /iR3ulLgXdG3dYRTHZ9A6kvWqsqciFDJr0+45BEmkLfNaQFu3SeXLBTIfDdQWB3LfpIu lfh5ug8KLxO2BaJXFW14jv1Wx7hZT6cgezFHM= 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=XQqX0w/bg+ipL/m0rncXP2fDD2FyK1xPozOhYywCM7SyW7rPmuXiu3IUEEZsp3KnaX 7wIfQnw9K2+GKJWln9K6lpgIwGA2q2F7+loA3Npo6barwlk6elYgrkHQ1/Pfp2mMfKpI cpt24ZZai6DCCb0FzQDmgL/wKUmKsVrT+GWY8= MIME-Version: 1.0 Received: by 10.100.167.18 with SMTP id p18mr1303874ane.6.1297638588958; Sun, 13 Feb 2011 15:09:48 -0800 (PST) Received: by 10.100.244.38 with HTTP; Sun, 13 Feb 2011 15:09:48 -0800 (PST) In-Reply-To: <8F17098F-0270-4241-AEA9-D6120A27C408@kirei.se> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> <8F17098F-0270-4241-AEA9-D6120A27C408@kirei.se> Date: Sun, 13 Feb 2011 18:09:48 -0500 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=001485f6d1ae2449cf049c32072e Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 13 Feb 2011 23:09:31 -0000 --001485f6d1ae2449cf049c32072e Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 13, 2011 at 1:49 PM, Jakob Schlyter wrote: > On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote: > > > The RFC published in 2006 > > > > The idea does not appear to have found much success, I am not aware of > any application that obtains S/MIME certs in that fashion. > > > > I think those facts suggest that the DNS is not a good choice for > per-user information. > > I acknowledge it has not found much success, but I would suspect that is > also due to the limited email address to DNS domain name mapping used. On > the other hand, no other email address to certificate services has found > much success either. > > > While that approach may work for small time personal domains, the DNS as > deployed and administered does not make that approach a practical one for an > organization of even moderate size. > > Given a better method to provide information on how to perform the mapping > between email address and DNS domain name (e.g. all certs for > username@kirei.se can be found at username._users.kirei.se), I believe > this is scalable even for large organizations. If we have that, a protocol > like DANE could be quite useful. > > jakob > > As I said originally: DNS is an appropriate mechanism to use to discover a service that can resolve the 'user' portion for 'example.com' There is already a W3C recommendation that does precisely that - XKMS. It even has SRV prefixes defined for that exact purpose. -- Website: http://hallambaker.com/ --001485f6d1ae2449cf049c32072e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 13, 2011 at 1:49 PM, Jakob S= chlyter <jakob@kirei= .se> wrote:
On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote:

> The RFC published in 2006
>
> The idea does not appear to have found much success, I am not aware of= any application that obtains S/MIME certs in that fashion.
>
> I think those facts suggest that the DNS is not a good choice for per-= user information.

I acknowledge it has not found much success, but I would suspect that= is also due to the limited email address to DNS domain name mapping used. = On the other hand, no other email address to certificate services has found= much success either.

> While that approach may work for small time personal domains, the DNS = as deployed and administered does not make that approach a practical one fo= r an organization of even moderate size.

Given a better method to provide information on how to perform the ma= pping between email address and DNS domain name (e.g. all certs for username@kirei.se can be found at usernam= e._users.kirei.se),= I believe this is scalable even for large organizations. If we have that, = a protocol like DANE could be quite useful.

=A0 =A0 =A0 =A0jakob


As I said originally:

DNS is an appropriate mechanism to use to discover a service = that can resolve the 'user' portion for 'example.com<= /a>'


There is already a W3C recommendation that does prec= isely that - XKMS. It even has SRV prefixes defined for that exact purpose.=
--001485f6d1ae2449cf049c32072e-- 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 F18953A6A31 for ; Sun, 13 Feb 2011 14:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.599, 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 YtkheWgooWII for ; Sun, 13 Feb 2011 14:15:56 -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 71D843A6C2E for ; Sun, 13 Feb 2011 14:15:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3CF0C3E407C; Sun, 13 Feb 2011 22:16:12 +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=1297635370; bh=8PwbcHu0zfyWjN 16Ex9rDeR2lM3yNxLWyyfUXYIFF6Y=; b=IoXEWlm9sjIl8IzGkTNFRcSZjXuldM VYfnaWpsM+Kba84/elxvf4jo3dtN/VWBGAg+MXsjVE5/bnxgNSTILZ7bFRWDauVJ y5F9cycKzv/EzXFqd4NSv8PFGao8Y1ZsEY9ymcjt03heLbo9cbQef8JxVUMWbEzw v8ifQLBEh2VBKINC2Sbcz7HmE6hkl2B+gvjuDTv7WVEBQXPgIsB1k9H+mlqIKp20 jad8jDue08MTMvf2ywWwjhz3HTM7T9UAzBZLCN7jK6cm49BRW/3jOd8GcsbeOeGe oONqVPBYY3U31xrE2T8oRcdUiPu86eN3JN6ot1lss/fMFOZUGEZwSa9g== 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 RHHhemWh+e8S; Sun, 13 Feb 2011 22:16:10 +0000 (GMT) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 89B8D3E4077; Sun, 13 Feb 2011 22:16:07 +0000 (GMT) Message-ID: <4D585826.10205@cs.tcd.ie> Date: Sun, 13 Feb 2011 22:16:06 +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: Yaron Sheffer References: <4D584EDC.3040909@gmail.com> In-Reply-To: <4D584EDC.3040909@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] dane-04 trust anchors 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, 13 Feb 2011 22:15:58 -0000 Hiya, On 13/02/11 21:36, Yaron Sheffer wrote: > Hi Paul, > > please see my response below. > > Thanks, > Yaron > >> Date: Sun, 13 Feb 2011 08:59:49 -0800 >> From: Paul Hoffman >> Subject: Re: [keyassure] dane-04 trust anchors >> To: keyassure@ietf.org >> Message-ID:<4D580E05.7070107@vpnc.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 2/11/11 12:40 PM, Yaron Sheffer wrote: >>> Having read and enjoyed numerous posts by Steve Kent, and skimmed (I >>> don't know who might have actually read) Sec. 6.1 of RFC 5280, I still >>> don't see your problem with my example list, nor any statement by Kent >>> that contradicts it. >> >> Please re-read section 6.1.1, particularly element (d) there. Your list >> would fall under (d)(4), which is explicitly listed as optional. >> > I believe this characterization is incorrect. 6.1.1.d.4 discusses > "public key parameters", which are never defined, but seem to refer to > actual mathematical parameters of the public key, such as algebraic > groups, generators etc. Right. > I agree that RFC 5280 is essentially silent about the semantics of > anything in the TA, Right. > when it is provided as a self-signed cert. Or in any other way. 5280 just says TA info "may" be in an SSC and that was quite deliberate. (Smartcards for example didn't use SSC's much - they disliked those extra useless signature bits as I recall:-) PKIX did a bunch more on this with TAMP afterwards as well so there's plenty of mail and RFC text to argue from. >From my personal p-o-v, (i.e. no hats) I don't see that DANE's handing of additional TA inputs (compared to the things 5280 needs) can be driven by 5280 since 5280 is silent on the topic. Equally, I don't think the (sometimes not so great) browser implementations of TA handling ought drive everything DANE does. So DANE should decide what it wants basically. Treat the info as a 5280 TA, as a bare key, as some kind of TAMP-like thing, whatever meets the use cases, and can be secure enough. S. > I would > appear that the authors of RFC 2459 (back in Jan. 1999) considered the > self-signed cert that wraps the public key as extraneous. However if a > modern browser were to ignore the validity period on a Verisign > top-level CA cert, this would be considered a bug. > >>> All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well >>> as even more wondrous beasts. The list is non-normative, serving as an >>> example of the kind of validation that RFC 5280 mandates. >> >> There are two problems here. You said: >> >>>>> The client MUST obey any constraints included in the trust anchor, >>>>> including but not limited to: >>>>> - Validity period. >>>>> - Key usage fields. >>>>> - Path length constraints. >>>>> - Name constraints. >>>>> The normal rules of RFC 5280 apply. >> >> I don't see now a "MUST obey" can be considered "non-normative". >> >> Further, you are simply incorrect that RFC 5280 mandates any of those, >> given that RFC 5280 says that they are optional. >> >> One of the reasons I am pushing hard against this is that the DANE WG >> should not be propagating myths about PKIX. Another is that some of the >> things that you are trying to mandate are often done poorly in PKIX >> certificate-writing implementations. >> >> You have still not said what the security advantage of following that >> these optional parts of trust anchors is. For example, if a >> certificate-writing application does a typically stupid thing with key >> usage, what security advantage is there to either the TLS server or >> client for the client to not be able to communicate with the server >> securely for that one reason? Note that I am not arguing against >> following PKIX for normal path processing: we are talking about trust >> anchors only here. You seem to confuse the parts of the validation >> algorithm that are for end-entity certificates and intermediate CAs with >> trust anchors, and that is very bad here. > > I accept that I confused the processing of EE certs with trust anchors. > But it would seem that modern practice diverges *a lot* from RFC 5280. > Moreover, people expect certain behavior from TLS self-signed CA certs > and we should ensure that such behavior (to the extent it is formally > specified) is also followed by a conformant DANE RP. > > All the items on my list can appear in intermediate certs, and sometimes > do (with the possible exception of name constraints). So applications > should behave sanely when presented with them. > _______________________________________________ > 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 AE6F63A6C2A for ; Sun, 13 Feb 2011 13:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.599 X-Spam-Level: X-Spam-Status: No, score=-93.599 tagged_above=-999 required=5 tests=[AWL=-10.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, URIBL_BLACK=20, 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 qMF8wzYadVZi for ; Sun, 13 Feb 2011 13:44:40 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 30FB53A6878 for ; Sun, 13 Feb 2011 13:44:40 -0800 (PST) Received: by bwz12 with SMTP id 12so5374381bwz.31 for ; Sun, 13 Feb 2011 13:45:00 -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=hgGZCafd7KMOS6k69jol/w/LwaLcCR2dnNKajcz4XWA=; b=o7MiYfYvH3y8Whj31YWCDvE0fPMzhwG0d6cyPAiEiSm+ZeC0OAbUH8+REvqmdEG4jH djLMAdnUGx2zNUKEv5dAK+3d3klAVFq68CeS/VGAJMmPJJOZBaZmkYFQQlfhmfSJ/Bdc kqnwvIXy/95eEkEIJBq4JVCIvQkvE8MHuwJEM= 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=xh9YjxlLn16EROlBOxqfZYL61Y7/FUcpOp1WJZzVh2nKZwja1X8yuCGEP6oZKEwE5M UbuYRk0EmIhnNMk3F9puQ7EEqhOiYCeKrA5HQD5kgbeA8mfhM6otrnIcdIgb9kTogBCS xnLO3tUiU3jfBSAA+9SZ3T6XxaffJPI4F432k= Received: by 10.204.135.217 with SMTP id o25mr2738710bkt.15.1297633499554; Sun, 13 Feb 2011 13:44:59 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id v25sm1341242bkt.6.2011.02.13.13.44.57 (version=SSLv3 cipher=OTHER); Sun, 13 Feb 2011 13:44:59 -0800 (PST) Message-ID: <4D5850D7.9010407@gmail.com> Date: Sun, 13 Feb 2011 23:44:55 +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: Paul Wouters References: <4D54E4A9.1020104@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] dane-04 trust anchors 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, 13 Feb 2011 21:44:41 -0000 Hi Paul, please see my comments below. Thanks, Yaron On 02/13/2011 09:58 PM, Paul Wouters wrote: > On Fri, 11 Feb 2011, Yaron Sheffer wrote: > >> My reference scenario is this: I am a phisher. I'd like to trick >> BigBank's customers, so I acquire bigbang.com (an easy misspelling). >> Now I can get a certificate that they will use as a trust anchor, and >> include whatever I want in it, such as the Subject field, "Your >> trusted BigBank". > > This is another reason for a "bare public key" type. This is indeed an > issue > that browser vendors have to deal with now. > I am all in favor of bare public keys. But if people insist on having a self-signed certificate instead, we should specify what its semantics are. >> Client treatment of any non-key information included in the trust >> anchor is a matter of local policy. It is noted that this >> specification does not mandate that such information be inspected or >> validated by the domain registrar. > > Why mention "domain registrar"? Those are not a party at all in anything > here. > Some person/organization signs the TLSA record. I would like to mention explicitly that this person/organization does not validate anything that is referenced from this record. >> The client MUST obey any constraints included in the trust anchor, >> including but not limited to: >> - Validity period. > > What to do if that period does not match the DNS TTL/RRSIG period? > I guess the more constrained validity prevails. >> - Key usage fields. >> - Path length constraints. >> - Name constraints. >> The normal rules of RFC 5280 apply. > > I'd rather see something saying everything except the public key should > be "local > policy", and no "MUST obey" items are present. "Local policy" is an OK statement for intra-enterprise deployment. It makes little sense in consumer cases. Do we want each browser to have its own security policy? > > Especially since that reduces the amount of ASN.1 parsing. Remember, now > we don't > even have the flawed SSL providers sanity checks on anything. Again, if the application is given a cert, it should parse it. It cannot just ignore it. If we say that bare public keys are the RECOMMENDED option, fine with me. > > 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 E760E3A6C27 for ; Sun, 13 Feb 2011 13:36:14 -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 gBXVN3S1W+ig for ; Sun, 13 Feb 2011 13:36:13 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7B3623A6878 for ; Sun, 13 Feb 2011 13:36:13 -0800 (PST) Received: by bwz12 with SMTP id 12so5369928bwz.31 for ; Sun, 13 Feb 2011 13:36:33 -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=nrYzJOXwM6dUbEZxlDC43bYXjge1hYgJP9KCdVaq9KQ=; b=wx16yp6miG2FGVZwogET33tdvrct1wwZF9S0pa7NWsaLeWxS9DQ29KOldNehIHwAYj /JCn9cQUK54ymvd8DdMfWvsYCiorMZPV04prZoOakQ6jY2sawabP74hoiUo9e083DqR1 /RoqbfmnFngxkNGVcX6hOIEKj/33ftvmgygug= 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=BYXpjFPm/yXhSoFk/aJpQ4WbnpSufvxhi0v0oIPsc6hfnJ1gbVZWfivsqme7CJDeC4 n8+FH9YOGcXD5S75R/tiZGBlgZkwCP06XHgWIQw9B02hM2WSwmG1nkEeQBpBY2zKC/TJ ReCqKoOGuhicsoNkLVQOboctoYoolri1BP4oY= Received: by 10.204.117.71 with SMTP id p7mr24468009bkq.187.1297632993718; Sun, 13 Feb 2011 13:36:33 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id rc9sm1334829bkb.14.2011.02.13.13.36.31 (version=SSLv3 cipher=OTHER); Sun, 13 Feb 2011 13:36:32 -0800 (PST) Message-ID: <4D584EDC.3040909@gmail.com> Date: Sun, 13 Feb 2011 23:36:28 +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] dane-04 trust anchors 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, 13 Feb 2011 21:36:15 -0000 Hi Paul, please see my response below. Thanks, Yaron > Date: Sun, 13 Feb 2011 08:59:49 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] dane-04 trust anchors > To: keyassure@ietf.org > Message-ID:<4D580E05.7070107@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/11/11 12:40 PM, Yaron Sheffer wrote: >> Having read and enjoyed numerous posts by Steve Kent, and skimmed (I >> don't know who might have actually read) Sec. 6.1 of RFC 5280, I still >> don't see your problem with my example list, nor any statement by Kent >> that contradicts it. > > Please re-read section 6.1.1, particularly element (d) there. Your list > would fall under (d)(4), which is explicitly listed as optional. > I believe this characterization is incorrect. 6.1.1.d.4 discusses "public key parameters", which are never defined, but seem to refer to actual mathematical parameters of the public key, such as algebraic groups, generators etc. I agree that RFC 5280 is essentially silent about the semantics of anything in the TA, when it is provided as a self-signed cert. I would appear that the authors of RFC 2459 (back in Jan. 1999) considered the self-signed cert that wraps the public key as extraneous. However if a modern browser were to ignore the validity period on a Verisign top-level CA cert, this would be considered a bug. >> All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well >> as even more wondrous beasts. The list is non-normative, serving as an >> example of the kind of validation that RFC 5280 mandates. > > There are two problems here. You said: > >>>> The client MUST obey any constraints included in the trust anchor, >>>> including but not limited to: >>>> - Validity period. >>>> - Key usage fields. >>>> - Path length constraints. >>>> - Name constraints. >>>> The normal rules of RFC 5280 apply. > > I don't see now a "MUST obey" can be considered "non-normative". > > Further, you are simply incorrect that RFC 5280 mandates any of those, > given that RFC 5280 says that they are optional. > > One of the reasons I am pushing hard against this is that the DANE WG > should not be propagating myths about PKIX. Another is that some of the > things that you are trying to mandate are often done poorly in PKIX > certificate-writing implementations. > > You have still not said what the security advantage of following that > these optional parts of trust anchors is. For example, if a > certificate-writing application does a typically stupid thing with key > usage, what security advantage is there to either the TLS server or > client for the client to not be able to communicate with the server > securely for that one reason? Note that I am not arguing against > following PKIX for normal path processing: we are talking about trust > anchors only here. You seem to confuse the parts of the validation > algorithm that are for end-entity certificates and intermediate CAs with > trust anchors, and that is very bad here. I accept that I confused the processing of EE certs with trust anchors. But it would seem that modern practice diverges *a lot* from RFC 5280. Moreover, people expect certain behavior from TLS self-signed CA certs and we should ensure that such behavior (to the extent it is formally specified) is also followed by a conformant DANE RP. All the items on my list can appear in intermediate certs, and sometimes do (with the possible exception of name constraints). So applications should behave sanely when presented with them. 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 4F06A3A6A1A for ; Sun, 13 Feb 2011 11:58:17 -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 EZJFJf20d2X7 for ; Sun, 13 Feb 2011 11:58:10 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 0CDEB3A69B8 for ; Sun, 13 Feb 2011 11:58: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 82489C504; Sun, 13 Feb 2011 14:58:30 -0500 (EST) Date: Sun, 13 Feb 2011 14:58:29 -0500 (EST) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <4D54E4A9.1020104@gmail.com> Message-ID: References: <4D54E4A9.1020104@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] dane-04 trust anchors 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, 13 Feb 2011 19:58:17 -0000 On Fri, 11 Feb 2011, Yaron Sheffer wrote: > My reference scenario is this: I am a phisher. I'd like to trick BigBank's > customers, so I acquire bigbang.com (an easy misspelling). Now I can get a > certificate that they will use as a trust anchor, and include whatever I want > in it, such as the Subject field, "Your trusted BigBank". This is another reason for a "bare public key" type. This is indeed an issue that browser vendors have to deal with now. > Client treatment of any non-key information included in the trust anchor is a > matter of local policy. It is noted that this specification does not mandate > that such information be inspected or validated by the domain registrar. Why mention "domain registrar"? Those are not a party at all in anything here. > The client MUST obey any constraints included in the trust anchor, including > but not limited to: > - Validity period. What to do if that period does not match the DNS TTL/RRSIG period? > - Key usage fields. > - Path length constraints. > - Name constraints. > The normal rules of RFC 5280 apply. I'd rather see something saying everything except the public key should be "local policy", and no "MUST obey" items are present. Especially since that reduces the amount of ASN.1 parsing. Remember, now we don't even have the flawed SSL providers sanity checks on anything. 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 7932C3A6AC9 for ; Sun, 13 Feb 2011 11:47:34 -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 h65hv84oEgxL for ; Sun, 13 Feb 2011 11:47:33 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8E6CC3A6AC8 for ; Sun, 13 Feb 2011 11:47: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 A81ECC504; Sun, 13 Feb 2011 14:47:52 -0500 (EST) Date: Sun, 13 Feb 2011 14:47:52 -0500 (EST) From: Paul Wouters To: Warren Kumari In-Reply-To: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> Message-ID: References: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@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 #3: Format of the record. 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, 13 Feb 2011 19:47:34 -0000 On Thu, 10 Feb 2011, Warren Kumari wrote: > We have "Issue #3: Format of the record" with the description: > > -------------------- > Format of the record: > a subtype of CERT (as was used in early drafts) > a new RRtype (used in draft-ietf-dane-protocol-00) > a TXT record with _prefix. > > Hopefully this is just a representation issue and can be worked on after larger decisions have been made. > > ---------------------- > > I think that we have settled on using a new RRtype (as shown in draft-ietf-dane-protocol-00), but I realize that we haven't explicitly had a consensus call on this, so I am (with all reverence) donning the bells and ribbons, stepping over the clay pipes, smacking myself smartly with the stick and beginning the consensus call... Yes, a new RRTYPE. 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 3946A3A6A19 for ; Sun, 13 Feb 2011 10:49:27 -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 mAxzZGShbRt8 for ; Sun, 13 Feb 2011 10:49:26 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 8BF0A3A69B8 for ; Sun, 13 Feb 2011 10:49:25 -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=bSWK55BacGLYCJBqqiZTuYOQqwJFh50cVXvA/9wR6SU=; b=zjG6zL/DMNAYLZ3yeAoY8sAznI92Otv4Xi8EkyxG0eLF7A2zbLXqAY6Fpne266jUUE11oI+5MYYDo DJFtZTNNRfoQHcZtD6xFo0lWcDAk6PW4nyji3SVxJ0H3adgNMz2igXgi8MytcNvDjgmK9xcErL7Twc 4zm/WDpN0YXwiA9A= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 13 Feb 2011 19:49:41 +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, 13 Feb 2011 19:49:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F17098F-0270-4241-AEA9-D6120A27C408@kirei.se> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 13 Feb 2011 18:49:27 -0000 On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote: > The RFC published in 2006 >=20 > The idea does not appear to have found much success, I am not aware of = any application that obtains S/MIME certs in that fashion. >=20 > I think those facts suggest that the DNS is not a good choice for = per-user information. I acknowledge it has not found much success, but I would suspect that is = also due to the limited email address to DNS domain name mapping used. = On the other hand, no other email address to certificate services has = found much success either. > While that approach may work for small time personal domains, the DNS = as deployed and administered does not make that approach a practical one = for an organization of even moderate size. Given a better method to provide information on how to perform the = mapping between email address and DNS domain name (e.g. all certs for = username@kirei.se can be found at username._users.kirei.se), I believe = this is scalable even for large organizations. If we have that, a = protocol like DANE could be quite useful. 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 49CBF3A6ABD for ; Sun, 13 Feb 2011 10:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 CKkRQxnluMPW for ; Sun, 13 Feb 2011 10:14:51 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 5521A3A67BD for ; Sun, 13 Feb 2011 10:14:51 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 2494534806A for ; Sun, 13 Feb 2011 10:15:12 -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=U6pY7W5 8MY+8J/gGsOicWcj33PRAhBMkFq8G6OjToCbjQS8FoRoFsdXsincefHWf7T/dCIp a+6udxPQM6pKxRLXWIpwp6XMq7M8SWVS9nagnEIWGqUgjUSM7fuppUZ2isEdvxoS ro/jqfOexgc5xv6X/7LUQHLuos95e16Dp5qY= 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=Rol6a+izD55VO iCBHjg9Zp68xIA=; b=YiQzUysn4bM+zXvOQfs+Ss6uFQ1mDQfUOQG3C1QH4UIfd 1CKloYnI414qyhNcujIT4XJCTOUbv4cCocNYtt+boofT4hjFlEQQjtHiYcFvp5WX /PPw7VwDd5L4Pb3HxdT9A5SiVoe5Jm+G8CXcK75B/s/eoZ9J67jv0+8fk1RUg8= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id E3B53348062 for ; Sun, 13 Feb 2011 10:15:11 -0800 (PST) From: Matt McCutchen To: keyassure Content-Type: text/plain; charset="UTF-8" Date: Sun, 13 Feb 2011 13:15:10 -0500 Message-ID: <1297620910.1890.28.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [keyassure] Binding to full TLS encapsulation or STARTTLS 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, 13 Feb 2011 18:14:52 -0000 I realized that TLSA as we are currently discussing does not bind keys to the use of full TLS encapsulation or STARTTLS. I'm thinking this is OK because it would be pretty ridiculous to multiplex different services based on the use of full encapsulation or STARTTLS, and clients generally do not ascribe security significance to the use of one or the other. E.g., if I bind a key to _3141._tcp.example.com for a service that uses STARTTLS, I can't think of any scenario in which a client trying to use full encapsulation would be harmed if a MITM allowed it to succeed by performing the STARTTLS part directly with the server. It might be nice to prevent web browsers from talking to STARTTLS services, but that would be far from a complete solution to the problem of browsers being a loose cannon for arbitrary connections, nor is it our responsibility to solve that problem here. Sanity check? -- 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 1240C3A69A6 for ; Sun, 13 Feb 2011 08:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.659 X-Spam-Level: X-Spam-Status: No, score=-100.659 tagged_above=-999 required=5 tests=[AWL=-0.102, 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 J3xHDPSpiyfk for ; Sun, 13 Feb 2011 08:59:34 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 011533A6A00 for ; Sun, 13 Feb 2011 08:59: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 p1DGxoUD097877 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 13 Feb 2011 09:59:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D580E05.7070107@vpnc.org> Date: Sun, 13 Feb 2011 08:59:49 -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: <4D559ED7.3050505@gmail.com> In-Reply-To: <4D559ED7.3050505@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] dane-04 trust anchors 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, 13 Feb 2011 16:59:35 -0000 On 2/11/11 12:40 PM, Yaron Sheffer wrote: > Having read and enjoyed numerous posts by Steve Kent, and skimmed (I > don't know who might have actually read) Sec. 6.1 of RFC 5280, I still > don't see your problem with my example list, nor any statement by Kent > that contradicts it. Please re-read section 6.1.1, particularly element (d) there. Your list would fall under (d)(4), which is explicitly listed as optional. > All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well > as even more wondrous beasts. The list is non-normative, serving as an > example of the kind of validation that RFC 5280 mandates. There are two problems here. You said: >>> The client MUST obey any constraints included in the trust anchor, >>> including but not limited to: >>> - Validity period. >>> - Key usage fields. >>> - Path length constraints. >>> - Name constraints. >>> The normal rules of RFC 5280 apply. I don't see now a "MUST obey" can be considered "non-normative". Further, you are simply incorrect that RFC 5280 mandates any of those, given that RFC 5280 says that they are optional. One of the reasons I am pushing hard against this is that the DANE WG should not be propagating myths about PKIX. Another is that some of the things that you are trying to mandate are often done poorly in PKIX certificate-writing implementations. You have still not said what the security advantage of following that these optional parts of trust anchors is. For example, if a certificate-writing application does a typically stupid thing with key usage, what security advantage is there to either the TLS server or client for the client to not be able to communicate with the server securely for that one reason? Note that I am not arguing against following PKIX for normal path processing: we are talking about trust anchors only here. You seem to confuse the parts of the validation algorithm that are for end-entity certificates and intermediate CAs with trust anchors, and that is very bad 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 A2DF53A6A41 for ; Sat, 12 Feb 2011 13:38:07 -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 jsPjQnve9Y0j for ; Sat, 12 Feb 2011 13:38:06 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 7C3F13A6A3C for ; Sat, 12 Feb 2011 13:38:06 -0800 (PST) Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id CE6676A437; Sat, 12 Feb 2011 13:38:24 -0800 (PST) From: "Jim Schaad" To: "'Paul Hoffman'" , References: <4D54E4A9.1020104@gmail.com> <4D556759.7010609@vpnc.org> In-Reply-To: <4D556759.7010609@vpnc.org> Date: Sat, 12 Feb 2011 13:58:12 -0800 Message-ID: <020001cbcaff$f201b320$d6051960$@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: AQIO0bB8c7BVvtdJ2UT8bT+JeRWdOAJTxNy7k2W9wRA= Content-Language: en-us Subject: Re: [keyassure] dane-04 trust anchors 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, 12 Feb 2011 21:38:07 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Paul Hoffman > Sent: Friday, February 11, 2011 8:44 AM > To: keyassure@ietf.org > Subject: Re: [keyassure] dane-04 trust anchors > > On 2/10/11 11:26 PM, Yaron Sheffer wrote: > > the new text is a major improvement over the previous version. But it > > is still missing some necessary guidance. > > > > My reference scenario is this: I am a phisher. I'd like to trick > > BigBank's customers, so I acquire bigbang.com (an easy misspelling). > > Now I can get a certificate that they will use as a trust anchor, and > > include whatever I want in it, such as the Subject field, "Your > > trusted BigBank". > > Good scenario. > > > Moreover, even if I am the rightful owner, the current text does not > > allow me to restrict the certificate's use. > > Correct. That is on purpose. > > > So I propose the following text added: > > > > Client treatment of any non-key information included in the trust > > anchor is a matter of local policy. It is noted that this > > specification does not mandate that such information be inspected or > > validated by the domain registrar. > > Sounds good to me. > > > The client MUST obey any constraints included in the trust anchor, > > including but not limited to: > > - Validity period. > > - Key usage fields. > > - Path length constraints. > > - Name constraints. > > The normal rules of RFC 5280 apply. > > As Steve Kent pointed out earlier on the list, the normal rules of RFC > 5280 for trust anchors disagrees with that list you gave. I would prefer to follow > the normal rules of RFC 5280 for trust anchors, and not come up with ones of > our own. I think that it is perfectly reasonable to say that the information is to be extracted from the provided certificate and used as the starting conditions for the certificate validation process. This does not change the rules for 5280 trust anchors as the information can come in from an external configuration. Many systems already will seed that initial configuration of the other variables used in the process from the data contained in the trust anchor, allowing for it to be changed or overridden by either system or trust administrators. Jim > _______________________________________________ > 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 458FE3A6A21 for ; Fri, 11 Feb 2011 16:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.448 X-Spam-Level: X-Spam-Status: No, score=-4.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2, 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 lfBHtqNWtQ05 for ; Fri, 11 Feb 2011 16:29:30 -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 0AC293A69D1 for ; Fri, 11 Feb 2011 16:29:29 -0800 (PST) Received: by wyf23 with SMTP id 23so3252799wyf.31 for ; Fri, 11 Feb 2011 16:29:45 -0800 (PST) Received: by 10.216.13.134 with SMTP id b6mr1218026web.25.1297470585099; Fri, 11 Feb 2011 16:29:45 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id r6sm683826weq.20.2011.02.11.16.29.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Feb 2011 16:29:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-6--811697351 From: Henry Story In-Reply-To: Date: Sat, 12 Feb 2011 01:29:26 +0100 Message-Id: References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> <393D6173-9DFE-4A39-A117-F81D3418D929@bblfish.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 12 Feb 2011 00:29:32 -0000 --Apple-Mail-6--811697351 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 Feb 2011, at 22:24, Phillip Hallam-Baker wrote: > On Fri, Feb 11, 2011 at 10:06 AM, Henry Story = wrote: >=20 >> Let's start from first principles. As far as internet users are = concerned, an Internet user identifier is user@example.com >=20 > In WebID we consider essentially an http url such as = http://bblfish.net/#me as it is immediately dereferenceable, >=20 >=20 >=20 > dereference, desmesherence. >=20 > What matters to the user is that they have a simple identifier that = they can give to other people, put on letterhead, business cards, read = over the telephone. Yes, and I have no problem with that. They can use e-mail addresses, = home page urls or other identifiers. No problem.=20 >=20 > Tim didn't intended the URLs to even be visible to the end user. The = address bar was an ad-hoc invention that appeared in Mosaic. In the = original NeXTstep browser you had to dig into a menu to find the url. If you look at the "WebID creation and use in 4 mintues" http://www.youtube.com/watch?v=3DS4dlMTZhUDc you will see that the end user need have absolutely no understanding of = the concept of a URI at all. This is completely in line with Tim Berners = Lee's vision, and he has in fact sponsored a lot of research on WebID = such as "RDF Policy-based URI Access Control for Content Authoring on = the Social Semantic Web" http://dig.csail.mit.edu/2009/presbrey/UAP.pdf = to just give one example.=20 What people give to their friends is a completely different issue. They = could give friends e-mail addresses, which could be resolved via Web = Finger or other protocols = http://blogs.sun.com/bblfish/entry/web_finger_proposals_overview to the profile document. Or they could use search engines, etc... Those = are user interface issues that one should not confuse with issues of = logic.=20 > If you are proposing infrastructure then make it work for the user = first and only then think about the hacks you might employ for backwards = compatibility. Yes, I do recommend you watch my pretty bad and very clearly amateur = screen cast "WebID creation and use in 4 mintues" http://www.youtube.com/watch?v=3DS4dlMTZhUDc With some help we can do better. >=20 > Here we have the DNS, there is a discovery mechanism that was = originally designed to resolve user@example.com, use it the way it was = designed. >=20 >=20 > If keys are going to be of the slightest use as end user keys they = have to bind to SMTP and Jabber addresses in any case. >=20 > What you have here is a URI scheme itself. You should think in terms = of the canonical form being: >=20 > webid:user@example.com=20 >=20 > The URL you gave might be something that ended up being a mapping = returned for retrieval/resolution purposes but that is all. I don't think it wrong to use e-mail URLs to identify users. WebFinger = does that, and I think they even use DNS to do that - which is better = than when they use the .well-known file in http.=20 It does not in fact matter how many URIs identify a user. Things can be = named by different names. There is a town in Germany the Germans call = M=FCnchen, the French and english call Munich. As Frege pointed out in = the 19th century Hesperus was known as the Evening Star, Phosphorus as = the Morning Star, and it was only recently in human history that these = names were shown to all refer to Venus. I have a few different URIs = identify me: http://bblfish.net/#me http://bblfish.net/people/henry/card/#me ... So these approaches are all compatible.=20 I was trying to show how at the protocol level that keyassure and webid = are compatible. This does come to confirm your point that we could place = as you suggest webid: URLs in the SAN too if we defined a protocol for = webid: dereferencing. This has been proposed on the WebID mailing list, = and I am not against it. I just start with the http:// URL example which = is easier to understand (once you understand that it requires no typing) Hope that helps. But don't forget the issue I raised of placing a public key in the = DNSSEC.=20 Henry =20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 Social Web Architect http://bblfish.net/ --Apple-Mail-6--811697351 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, Feb 11, 2011 at 10:06 AM, Henry Story <henry.story@bblfish.net> wrote:

Let's start = from first principles. As far as internet users are concerned, an = Internet user identifier is user@example.com

In WebID we consider essentially = an http url such as http://bblfish.net/#me as it is immediately = dereferenceable,
=


dere= ference, desmesherence.

What matters to the = user is that they have a simple identifier that they can give to other = people, put on letterhead, business cards, read over the = telephone.

Yes, and I have = no problem with that. They can use e-mail addresses, home page urls or = other identifiers. No problem. 


Tim didn't intended the URLs to even be visible to = the end user. The address bar was an ad-hoc invention that appeared in = Mosaic. In the original NeXTstep browser you had to dig into a menu to = find the url.


If you = look at the "WebID creation and use in 4 mintues"
http://www.youtube.c= om/watch?v=3DS4dlMTZhUDc
you will see that the end user need have = absolutely no understanding of the concept of a URI at all. This is = completely in line with Tim Berners Lee's vision, and he has in fact = sponsored a lot of research on WebID such as "RDF Policy-based URI = Access Control for Content Authoring on the Social Semantic = Web" http://dig.csail.mit.edu/2009/presbrey/UAP.pdf to just = give one example. 

What people give to their friends is = a completely different issue. They could give friends e-mail addresses, = which could be resolved via Web Finger or other = protocols http://blogs.sun.com/bblfish/entry/web_finger_proposals_ove= rview
to the profile document. Or they could use search engines, = etc... Those are user interface issues that one should not confuse with = issues of logic. 


If you are proposing infrastructure then make it work for the user = first and only then think about the hacks you might employ for backwards = compatibility.


Yes, I do = recommend you watch my pretty bad and very clearly amateur screen = cast "WebID creation and use in 4 mintues"

http://www.youtube.c= om/watch?v=3DS4dlMTZhUDc

With some help we can do = better.


Here we have the DNS, there is = a discovery mechanism that was originally designed to resolve user@example.com, use it the way it = was designed.


If keys are going to be of the = slightest use as end user keys they have to bind to SMTP and Jabber = addresses in any case.

What you have here is a = URI scheme itself. You should think in terms of the canonical form = being:


The URL you gave might be something that = ended up being a mapping returned for retrieval/resolution purposes but = that is all.


I = don't think it wrong to use e-mail URLs to identify users. WebFinger = does that, and I think they even use DNS to do that - which is = better than when they use the .well-known file in = http. 

It does not in fact matter how many URIs = identify a user. Things can be named by different names. There is a = town in Germany the Germans call M=FCnchen, the French and english call = Munich. As Frege pointed out in the 19th century Hesperus was known = as the Evening Star, Phosphorus as the Morning Star, and it was = only recently in human history that these names were shown to all refer = to Venus. I have a few different URIs identify me:

http://bblfish.net/#me
http://bblfi= sh.net/people/henry/card/#me
...

So these approaches are all = compatible. 

I was trying to show how at = the protocol level that keyassure and webid are compatible. This = does come to confirm your point that we could place as you suggest = webid: URLs in the SAN too if we defined a protocol for webid: = dereferencing. This has been proposed on the WebID mailing list, and I = am not against it. I just start with the http:// URL example which is = easier to understand (once you understand that it requires no = typing)

Hope that = helps.

   But don't forget the issue = I raised of placing a public key in the = DNSSEC. 

Henry =  



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


Social = Web Architect
http://bblfish.net/

= --Apple-Mail-6--811697351-- 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 51BFC3A69EA for ; Fri, 11 Feb 2011 15:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 wbAlUOX24x67 for ; Fri, 11 Feb 2011 15:19:49 -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 9B57C3A6838 for ; Fri, 11 Feb 2011 15:19:49 -0800 (PST) Received: by gwb20 with SMTP id 20so1434469gwb.31 for ; Fri, 11 Feb 2011 15:20: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=KWNtx+4/S6z1Gcnwqi4Tk4KbfOv3RV/akqTXlT0i68k=; b=hO+dX6Gdkex4BNTyj1kxeC3apfMKIpokGwyr1jf1evyR2QHG3OwnlzyjqNpMWLmcbf gvGAKJmJecfUzj+tA8NKezY+xYudOfoBYjOEUZPAvtl2gbZ/0RxHYLU7kkSlNO1elL5q NwM2q47GCPcFw9KS0jmOhXSGkmGCoQbWXplGI= 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=POEVOTfkj0khKY1bFHQwKCnkgLUiE8Z8Vtw7q7R332T/CiHEzUny91iOKmjRHGM5o5 6kJhPPkmYlg12WubQoyhMaZ2aFNNK+RJvt5q/4OHQdLcwCbhT0PpOST4H3yjHi2MLMHE 3JWyG75HaAjRJ9BBx98ZaGSa+qXs3UD35YUXc= MIME-Version: 1.0 Received: by 10.100.168.17 with SMTP id q17mr482875ane.40.1297466405208; Fri, 11 Feb 2011 15:20:05 -0800 (PST) Received: by 10.100.244.38 with HTTP; Fri, 11 Feb 2011 15:20:05 -0800 (PST) In-Reply-To: References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> Date: Fri, 11 Feb 2011 18:20:05 -0500 Message-ID: From: Phillip Hallam-Baker To: Jakob Schlyter Content-Type: multipart/alternative; boundary=0016e6441dce30c2f6049c09f09c Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 23:19:51 -0000 --0016e6441dce30c2f6049c09f09c Content-Type: text/plain; charset=ISO-8859-1 The RFC published in 2006 The idea does not appear to have found much success, I am not aware of any application that obtains S/MIME certs in that fashion. I think those facts suggest that the DNS is not a good choice for per-user information. While that approach may work for small time personal domains, the DNS as deployed and administered does not make that approach a practical one for an organization of even moderate size. On Fri, Feb 11, 2011 at 6:10 PM, Jakob Schlyter wrote: > On 11 feb 2011, at 15.14, Phillip Hallam-Baker wrote: > > > DNS is not an appropriate place to store attributes specific to ' > user@example.com'. > > IMHO, that's a pretty strong statement - RFC 4398 (section 3.2) does not > agree with you at all. > > jakob > > -- Website: http://hallambaker.com/ --0016e6441dce30c2f6049c09f09c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The RFC published in 2006

The idea does not a= ppear to have found much success, I am not aware of any application that ob= tains S/MIME certs in that fashion.

I think those = facts suggest that the DNS is not a good choice for per-user information.


While that approach may work for small t= ime personal domains, the DNS as deployed and administered does not make th= at approach a practical one for an organization of even moderate size.


On Fri, Feb 11, 2011 at 6:10 PM, Ja= kob Schlyter <jakob@= kirei.se> wrote:
On 11 feb 2011, at 15.14, Phillip Hallam-Baker wrote:

> DNS is not an appropriate place to store attri= butes specific to 'user@example.com= '.

IMHO, that's a pretty strong statement - RFC 4398 (section 3.2) d= oes not agree with you at all.

=A0 =A0 =A0 =A0jakob




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

--0016e6441dce30c2f6049c09f09c-- 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 09CF83A69F0 for ; Fri, 11 Feb 2011 15:10:29 -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 wd+Uzn5ZIh4I for ; Fri, 11 Feb 2011 15:10:23 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 0BFC23A69EA for ; Fri, 11 Feb 2011 15:10: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=UdX25ZDEYLqQPIXxaP8X8NGNn304Ronm2vzEK8PRIq0=; b=oTUasZBysWq9Lk3+/EFMbesEiYeJdZbMiKaxEAYlIrAO5RYg5vNnQlmORl4KHKL7gYt7feiZ0EDkU cqvE11ySvaGJZSXw6TOu0Qjpd9948Zi/QjterthsiU4q2T/cy7BrtC57xUvgZoPuPXYPH5r4T2pMpl QYOJ8rLqDfLFHpPE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Sat, 12 Feb 2011 00:10:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Sat, 12 Feb 2011 00:10:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 23:10:29 -0000 On 11 feb 2011, at 15.14, Phillip Hallam-Baker wrote: > DNS is not an appropriate place to store attributes specific to = 'user@example.com'. IMHO, that's a pretty strong statement - RFC 4398 (section 3.2) does not = agree with you at all. 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 D46BD3A69CA for ; Fri, 11 Feb 2011 13:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Mzcg514dlN1Y for ; Fri, 11 Feb 2011 13:24:43 -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 7BD763A699F for ; Fri, 11 Feb 2011 13:24:43 -0800 (PST) Received: by gwb20 with SMTP id 20so1396475gwb.31 for ; Fri, 11 Feb 2011 13:24:58 -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=WTjH5Qcl8lnx6HMQ5gSx6A/cx7KaonFT1kmOh7G7xAU=; b=u8E6Ypvssr8tDd8gSJMCf/V4sd6JaethBKVzWAQOnS82s7Cu0D8SrFEDX1Z8PkrPHs WsDClfxUZEKxZxjadIDI1AM09XeczugTtszTopobNyJDMkFM99Onut7gXMZWCBva4nNk X0iUZf1xV1enb/68XJdsjOArjr/uZ7A2rR28k= 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=pONaPTwvg+urHvjJDhd/0HZ3CHhdO4G+D6B9m+pzdgq4GrK6BMijGNe6Gi98PtZZVm M3Iee2HZbQ4DbYE4BRnMRikw7Q3Q529d5YFo7w+n7u6D0MtXJMVTKQO4HCWp56YNThDN qC56V+c1UiDFGxMx/P8MIGBcYZuVcrpF4NsJs= MIME-Version: 1.0 Received: by 10.100.206.17 with SMTP id d17mr258813ang.74.1297459497983; Fri, 11 Feb 2011 13:24:57 -0800 (PST) Received: by 10.100.244.38 with HTTP; Fri, 11 Feb 2011 13:24:57 -0800 (PST) In-Reply-To: <393D6173-9DFE-4A39-A117-F81D3418D929@bblfish.net> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> <393D6173-9DFE-4A39-A117-F81D3418D929@bblfish.net> Date: Fri, 11 Feb 2011 16:24:57 -0500 Message-ID: From: Phillip Hallam-Baker To: Henry Story Content-Type: multipart/alternative; boundary=001636b432477ce002049c0854ab Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 21:24:44 -0000 --001636b432477ce002049c0854ab Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 11, 2011 at 10:06 AM, Henry Story wrote: > > > Let's start from first principles. As far as internet users are concerned, > an Internet user identifier is user@example.com > > > In WebID we consider essentially an http url such as > http://bblfish.net/#me as it is immediately dereferenceable, > > dereference, desmesherence. What matters to the user is that they have a simple identifier that they can give to other people, put on letterhead, business cards, read over the telephone. Tim didn't intended the URLs to even be visible to the end user. The address bar was an ad-hoc invention that appeared in Mosaic. In the original NeXTstep browser you had to dig into a menu to find the url. If you are proposing infrastructure then make it work for the user first and only then think about the hacks you might employ for backwards compatibility. Here we have the DNS, there is a discovery mechanism that was originally designed to resolve user@example.com, use it the way it was designed. If keys are going to be of the slightest use as end user keys they have to bind to SMTP and Jabber addresses in any case. What you have here is a URI scheme itself. You should think in terms of the canonical form being: webid:user@example.com The URL you gave might be something that ended up being a mapping returned for retrieval/resolution purposes but that is all. -- Website: http://hallambaker.com/ --001636b432477ce002049c0854ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 11, 2011 at 10:06 AM, Henry = Story <henr= y.story@bblfish.net> wrote:

<= blockquote type=3D"cite">
Let's start from first principles. As far= as internet users are concerned, an Internet user identifier is user@example.com

In WebID we consider essentially an = http url such as http:= //bblfish.net/#me as it is immediately dereferenceable,



deref= erence, desmesherence.

What matters to the user is= that they have a simple identifier that they can give to other people, put= on letterhead, business cards, read over the telephone.

Tim didn't intended the URLs to even be visible to = the end user. The address bar was an ad-hoc invention that appeared in Mosa= ic. In the original NeXTstep browser you had to dig into a menu to find the= url.


If you are proposing infrastructure then= make it work for the user first and only then think about the hacks you mi= ght employ for backwards compatibility.

Here we ha= ve the DNS, there is a discovery mechanism that was originally designed to = resolve user@example.com, use it th= e way it was designed.


If keys are going to be of the slightest= use as end user keys they have to bind to SMTP and Jabber addresses in any= case.

What you have here is a URI scheme itself. = You should think in terms of the canonical form being:


The URL you gave might be= something that ended up being a mapping returned for retrieval/resolution = purposes but that is all.


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

--001636b432477ce002049c0854ab-- 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 061693A6925 for ; Fri, 11 Feb 2011 12:40:46 -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 JDwTQHbFCGUw for ; Fri, 11 Feb 2011 12:40:44 -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 9E4EC3A67B3 for ; Fri, 11 Feb 2011 12:40:44 -0800 (PST) Received: by fxm9 with SMTP id 9so3589327fxm.31 for ; Fri, 11 Feb 2011 12:40:59 -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=P75wCa/kcFkBmzr4ZliGoZoKk5PdYgPRDIRSRsxm+WE=; b=VUpDaJYD4iOEXNNn6CtecHgivyNHG8FnHAOTd+wZXLQ1dugfwzuIKYzqtnR39319h+ AkHHOFDMVoult5AZFVlNI7JCR6ixI5oUvok4UBQc8XP+5zLO1YSYEEdkj/mK/9aGE88z XrYQp/8vhBVYxknT2vzFlvJDNKEirBDv8Q6Tc= 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=G1W/qz3PYwcKV9YSfRKhLjWXmy/fpzz5hgUj6S4aJBc7GLZdF1GqYU5vQQbaOxpJXH OrW0/28lUESPaIbU9wq2LIHbA8bQYw8ayunXx7D5WohR8hPGpYPAGjPaqRfUgu8YT9TB MjCsHnriV/RExxTWX4tmRmYGHkdjhYtAuxr5s= Received: by 10.223.83.201 with SMTP id g9mr3680871fal.140.1297456859642; Fri, 11 Feb 2011 12:40:59 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id e6sm602819fav.32.2011.02.11.12.40.57 (version=SSLv3 cipher=OTHER); Fri, 11 Feb 2011 12:40:58 -0800 (PST) Message-ID: <4D559ED7.3050505@gmail.com> Date: Fri, 11 Feb 2011 22:40:55 +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] dane-04 trust anchors 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, 11 Feb 2011 20:40:46 -0000 Hi Paul, Having read and enjoyed numerous posts by Steve Kent, and skimmed (I don't know who might have actually read) Sec. 6.1 of RFC 5280, I still don't see your problem with my example list, nor any statement by Kent that contradicts it. All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well as even more wondrous beasts. The list is non-normative, serving as an example of the kind of validation that RFC 5280 mandates. Thanks, Yaron > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 08:44:09 -0800 > From: Paul Hoffman > Subject: Re: [keyassure] dane-04 trust anchors > To: keyassure@ietf.org > Message-ID:<4D556759.7010609@vpnc.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/10/11 11:26 PM, Yaron Sheffer wrote: >> the new text is a major improvement over the previous version. But it is >> still missing some necessary guidance. >> >> My reference scenario is this: I am a phisher. I'd like to trick >> BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now >> I can get a certificate that they will use as a trust anchor, and >> include whatever I want in it, such as the Subject field, "Your trusted >> BigBank". > > Good scenario. > >> Moreover, even if I am the rightful owner, the current text does not >> allow me to restrict the certificate's use. > > Correct. That is on purpose. > >> So I propose the following text added: >> >> Client treatment of any non-key information included in the trust anchor >> is a matter of local policy. It is noted that this specification does >> not mandate that such information be inspected or validated by the >> domain registrar. > > Sounds good to me. > >> The client MUST obey any constraints included in the trust anchor, >> including but not limited to: >> - Validity period. >> - Key usage fields. >> - Path length constraints. >> - Name constraints. >> The normal rules of RFC 5280 apply. > > As Steve Kent pointed out earlier on the list, the normal rules of RFC > 5280 for trust anchors disagrees with that list you gave. I would prefer > to follow the normal rules of RFC 5280 for trust anchors, and not come > up with ones of our own. > > > ------------------------------ > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > > > End of keyassure Digest, Vol 7, Issue 24 > **************************************** 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 BFBE53A679C for ; Fri, 11 Feb 2011 08:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.483 X-Spam-Level: X-Spam-Status: No, score=-101.483 tagged_above=-999 required=5 tests=[AWL=0.563, 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 Kck4lU+riY+H for ; Fri, 11 Feb 2011 08:43:53 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BD44F3A6778 for ; Fri, 11 Feb 2011 08:43: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 p1BGi8aU003034 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 Feb 2011 09:44:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D556759.7010609@vpnc.org> Date: Fri, 11 Feb 2011 08:44: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: <4D54E4A9.1020104@gmail.com> In-Reply-To: <4D54E4A9.1020104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] dane-04 trust anchors 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, 11 Feb 2011 16:43:54 -0000 On 2/10/11 11:26 PM, Yaron Sheffer wrote: > the new text is a major improvement over the previous version. But it is > still missing some necessary guidance. > > My reference scenario is this: I am a phisher. I'd like to trick > BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now > I can get a certificate that they will use as a trust anchor, and > include whatever I want in it, such as the Subject field, "Your trusted > BigBank". Good scenario. > Moreover, even if I am the rightful owner, the current text does not > allow me to restrict the certificate's use. Correct. That is on purpose. > So I propose the following text added: > > Client treatment of any non-key information included in the trust anchor > is a matter of local policy. It is noted that this specification does > not mandate that such information be inspected or validated by the > domain registrar. Sounds good to me. > The client MUST obey any constraints included in the trust anchor, > including but not limited to: > - Validity period. > - Key usage fields. > - Path length constraints. > - Name constraints. > The normal rules of RFC 5280 apply. As Steve Kent pointed out earlier on the list, the normal rules of RFC 5280 for trust anchors disagrees with that list you gave. I would prefer to follow the normal rules of RFC 5280 for trust anchors, and not come up with ones of our own. 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 EC8E63A6989 for ; Fri, 11 Feb 2011 08:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.576 X-Spam-Level: X-Spam-Status: No, score=-100.576 tagged_above=-999 required=5 tests=[AWL=-0.389, 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 ZuaeVxm9LRUW for ; Fri, 11 Feb 2011 08:38:39 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 28AD03A6405 for ; Fri, 11 Feb 2011 08:38:39 -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 p1BGcrxG002826 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 Feb 2011 09:38:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D55661E.8010604@vpnc.org> Date: Fri, 11 Feb 2011 08:38:54 -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: <4D54A5FD.8060809@vpnc.org> <1297395379.1903.29.camel@mattlaptop2.local> <4D54B619.1070903@vpnc.org> <87zkq36qf6.fsf@latte.josefsson.org> In-Reply-To: <87zkq36qf6.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one.... 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, 11 Feb 2011 16:38:40 -0000 On 2/10/11 10:22 PM, Simon Josefsson wrote: >>>> A TLS client conforming to this protocol MUST treat the certificate >>>> for association in a TLSA resource record for a domain name as a >>>> trust anchor for that domain name at the specific port number and >>>> transport name that was queried. This trust anchor MUST only be used >>>> for the domain name of the resource record. >>> >>> And port number and transport protocol name. >> >> Why should we put on that requirement? That is, if I get a trust >> anchor for _443._tcp.www.example.com, what is the security issue if I >> also want to use it for TLS on port 4443? There is no attack that an >> MITM can mount on 4443 that they cannot also mount on 443. > > You may want to run a commercial CA on port 443 to get good interop with > deployed https clients, but you may want to use a trustworthy CA on port > 4443 to get good security for some other services. Absolutely. > Having the > commercial CA be able to MITM the connection on 4443 sounds counter to > what I perceive DANE is aiming to achieve. Quite right, but that is not what the text in the document says. A highly-cautious client would not want to use the 443-trust-anchor for any other port, but I do not see the reason to force that policy on them, particularly if they want to reduce DNS round trips. It makes sense to force them to only use the trust anchor on the domain name given, because that sets the administrative boundary to the administrator of the domain name service; however, beyond that, it should be a client policy option. Would you be OK if we left this as-is and put in a security consideration with the scenario you give? --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 A06BC3A68C0 for ; Fri, 11 Feb 2011 08:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.47 X-Spam-Level: X-Spam-Status: No, score=-101.47 tagged_above=-999 required=5 tests=[AWL=0.576, 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 vgKJ5+AYEfpb for ; Fri, 11 Feb 2011 08:34:45 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 530193A6778 for ; Fri, 11 Feb 2011 08:34: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 p1BGYxhT002658 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 11 Feb 2011 09:35:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D556534.8080502@vpnc.org> Date: Fri, 11 Feb 2011 08:35: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: <4D3F2B84.1090205@vpnc.org> <90CE8613-F809-4F0F-97C4-B823F3CBC117@princeton.edu> In-Reply-To: <90CE8613-F809-4F0F-97C4-B823F3CBC117@princeton.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] 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: Fri, 11 Feb 2011 16:34:46 -0000 On 2/10/11 9:49 PM, Steve Schultze wrote: > Sorry I missed this when you first posted. > > I feel that Matt's proposed language for Section 3 is clearer as to > what is done in different scenarios: > http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html It went into more scenarios, but I didn't see much agreement on the scenarios at the time, or since then. > For example, the current language in Section 3 does not make clear > what is done in the case of no records or a DNSSEC response of > "bogus" . I like the way Matt's language clearly lays out all of the > possible cases and the results. Laying out the possible cases is good, as long as we can agree with the results. For example, there was disagreement about what to do in the case of a bogus result; what he proposed at the time causes a new and easy-to-mount denial-of-service attack on TLS. > The one issue with his language is that it assumes the client is > doing DNSSEC validation, but our current language permits "a remote > nameserver to which one has a secured channel of communication." If > we are permitting that, we may have to rephrase some of his specific > references to DNSSEC result status' like "bogus" to be more generic. There is more than that one issue, I believe. If someone (you or Matt) want to suggest some wording as a change to the current draft, that would be helpful to maybe a new open issue. However, please consider splitting the wording into different parts, since the earlier wording had disagreement about different parts, and the WG might want to adopt some but not all of a proposal. 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 5CC913A6A19 for ; Fri, 11 Feb 2011 07:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 yAX-ho0RvySV for ; Fri, 11 Feb 2011 07:06:18 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3160A3A694F for ; Fri, 11 Feb 2011 07:06:18 -0800 (PST) Received: by bwz12 with SMTP id 12so3588814bwz.31 for ; Fri, 11 Feb 2011 07:06:32 -0800 (PST) Received: by 10.204.114.81 with SMTP id d17mr1415829bkq.135.1297436792414; Fri, 11 Feb 2011 07:06:32 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id j11sm536618bka.0.2011.02.11.07.06.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Feb 2011 07:06:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--845477204 From: Henry Story In-Reply-To: Date: Fri, 11 Feb 2011 16:06:26 +0100 Message-Id: <393D6173-9DFE-4A39-A117-F81D3418D929@bblfish.net> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 15:06:21 -0000 --Apple-Mail-4--845477204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Feb 2011, at 15:14, Phillip Hallam-Baker wrote: > [Before reading this in the context of 'PKI vendor speaks', I would = like to point out to people on the list that Comodo is now an announced = provider of DNS services under the brand DNS.com.] >=20 >=20 > It is not very clear to me what is being proposed here. I was not proposing anything to start of with, other than to show at = what level the protocols are similar. That of course cannot be a = proposal, only a point of interest.=20 Noticing that similarity was useful in helping me understand what = keyassure is doing. And understanding that similarity also led me to = ask why you don't also allow one to publish the plain and simple public = key in addition perhaps to the 4 methods listed in section 2.2 of = draft-4. My point there was that that should be enough to do a lot of = what you want. See the =3D=3DIDEA=3D=3D section. The supporting evidence = for this is that this is enough for us at the WebID level.=20 > Let's start from first principles. As far as internet users are = concerned, an Internet user identifier is user@example.com In WebID we consider essentially an http url such as = http://bblfish.net/#me as it is immediately dereferenceable, > I know that there are people trying to peddle URIs as user identifiers = but the success of that approach is evidenced by the fact that OpenID = support is contracting rather than expanding. There are many reasons why OpenId is having trouble. The main one being = that the user has to remember what to type, and has to type it. With = WebID this is integrated into the SSL layer, so the user only needs to = point and click. There is a 4 minute video on http://bblfish.net/ (the = second one) that demonstrates this.=20 There is a whole list of other reasons why TLS works better, many of = them I have gathered here = http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_wa= nt_distributed_identity.3F >=20 > Given user@example.com as the identifier,=20 >=20 > DNS is an appropriate mechanism to resolve attributes bound to the = 'example.com' portion. exactly. DNS is the Canonical lookup method for a DNS name :-) >=20 > DNS is an appropriate mechanism to use to discover a service that can = resolve the 'user' portion for 'example.com yes (though if it can be avoided then that can be better) But it gives = some useful flexibility. > DNS is not an appropriate place to store attributes specific to = 'user@example.com'. Completely agree.=20 >=20 >=20 > We already have a Web Service that is designed to serve as a key = centric distribution mechanism for per-user data and it happens to be a = W3C recommendation - XKMS. Thanks for pointing that one out. It looks like one of the SOAPy specs. = This should be useful. WebID is working within the linked data architectural space, where you = put things at their URI location, and you try to restrict yourself to = the RESTful verbs (GET, PUT, POST, DELETE) >=20 > I think it would be entirely appropriate to use DNS assured keys to = validate an XKMS service.=20 > We could also take the XKMS schema and use it within FOAF. yes, so with WebID we use the DNS assured keys, to power up TLS, so that = https becomes a way to validate the foaf document returned - that it has = not been corrupted on the way. So that way we have part of the work of = what XKMS does, but using simple HTTP. (Need to study XKMS in more = detail) > I think that there are many possibilities here. But they are way off = topic for this group.=20 Yes. > Would it be possible for people interested in this area to Bar BoF in = Prague? (I am in Paris btw. But let me know). Don't forget the issue that I raised that is relevant to this group, = namely the idea of putting the public keys in DNS, without all the extra = stuff. Henry >=20 > On Fri, Feb 11, 2011 at 7:19 AM, Henry Story = wrote: >=20 > On 11 Feb 2011, at 01:48, Paul Hoffman wrote: >=20 > > On 2/10/11 2:41 PM, Henry Story wrote: > >> Keyassure will probably use the DNS-ID typed subject alternative = name > >> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 = certifactes > >> to identify the server as suggested is good practice by > >> = http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section= -2.3 > > > > In your earlier message, you said: > > > >> (I have not seen a draft spec yet, and am going from the group > >> description). > > > > Please do read the draft. What you say here, which predicates the = rest > > of your message about similarities with the WebID work, is not at = all > > correct. >=20 > Yes, I just read the draft dane 4 > http://tools.ietf.org/html/draft-ietf-dane-protocol-04 >=20 > I don't think I was far off, but still perhaps too cryptic. In section = 2.2 it states that there are four types of things that can be published = in the TLSA record >=20 > 1 -- Hash of an end-entity certificate > 2 -- Full end-entity certificate in DER encoding > 3 -- Hash of an certification authority's certificate > 4 -- Full certification authority's certificate in DER encoding >=20 > So if in 2 the certificate is a DER encoded X509 cert, then if it is a = server certificate it should contain according to draft-saintandre the = Domain Name in the SAN field. There are a few different types of SAN = fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is = a lot closer to what you are specifying in the RDATA format. (Though it = looks like that RFC could be improved to allow port numbers to be = specified, as you do) >=20 > So if someone came across such a certificate with such a SRV-ID, they = could after finding the SAN do a lookup in DNSSEC and verify that this = is indeed the correct/current certificate. In some ways this is similar = to finding an html page with a > > You could use it to lookup the current version of the page. What you = have in your hand is a cached copy. >=20 > Now if you do one more little conceptual jump and you allow that one = can name things including agents with an http(s) URI then he can put = that URI in the SAN field. So I have a WebID >=20 > http://bblfish.net/people/henry/card#me >=20 > Doing a lookup using HTTP will get the meaning of that URI - and so a = description of me. That URI could return a PEM certificate too, just as = you do in the DNS lookup (we are discussing allowing this in addition to = RDF/XML, rdfa, or other XML representations) >=20 > Good so I think we have two protocols - yours and WebID - that both = can do the following and that are very similar in those respect: >=20 > 1. place an identifier in the X.509 SAN field. > - for keyassure this is a service identifier (SRV-ID) > - for webid this is a URI identifier > 2. dereference the ID to get the latest version > - using DNS lookup for keyassure > - using HTTP/HTTPS/ftp... lookup for WebID > 3. Proving authenticity > both protocols use the information retrieved canonically at the = identifier to prove authenticity. > - with WebID the relying party uses the public key published = there to verify that the agent connecting to it is indeed named by that = URI. He is if he could prove in the TLS handshake that he knew the = corresponding private key. > - with keyassure by proving that there is the appropriate link = between the keys/signature published in 1-4 and the certificate sent by = the TLS server. >=20 > Essentially point 3 - proving authenticity - works because of what = you name a trust anchor. I am just pointing out that this trust anchor = is tied to a naming system and a canonical lookup procedure in both = cases. >=20 > Ok, so I think that demonstrates quite clearly that there are a lot = of similarities. So what is the use of knowing that? >=20 > Well I think for me that helps confirm my WebID intuitions. When I = spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a few = years ago, the possibility of something like keyassure helped me feel we = could bypass the most damaging of his critiques against the current PKI = setup. WebID does not need CAs, and with keyassure web servers won't = need them either. We are still left with the clumsy ASN.1 format, but = that can be solved over time with better parsers, or, since TLS allows = it, to some better defined format such as binary xml perhaps. >=20 > Another advantage of having two very similar protocols developing, = especially as they are not stepping on each others toes, is that we may = be able to learn a few tricks from one another. So here is one initial = idea that occurred to me reading your spec today. >=20 > =3D=3D IDEA =3D=3D >=20 > Currently you are publishing either a signature or a certificate in = the DNS. Why not publish the only piece of the certificate that is = important: the public key. This is what WebID does. This should be = shorter than the certificate, and though it will be longer than the = signature, it will be a lot more useful, tying you much less to a = particular serialisation format. >=20 > There is no need to send a full certificate. All you need is to tie a = name to a public key and to guarantee to the end user the integrity of = the information. But the integrity is itself assured by DNSSEC. The = tying of the name to the public key is done by the lookup in DNS. So all = that is really required is to return the public key - the type and the = fields. >=20 > One could then even imagine a TLS improvement where the server would = not need to send his certificate either. All the TLS server would need = to do is prove that he can encrypt something with his private key. The = public key would be fetched from the DNS. So at that point we will have = gotten rid of ASN.1 or at least just kept the minimum needed. This would = be the server equivalent of the client_certificate_url extension of TLS = 1.2 where the client can send a URL to a location of his certificate, = instead of sending his certificate. Here the server would not need to = send his certificate, and for self signed certificates, the DNS sending = the public key would be enough anyway. >=20 > So I hope this helps clarify the similarities of the two protocols as = well as the usefulness of our interaction. >=20 > > This is not to say that what WebID is doing can't work with the DANE = effort, just that we are doing completely different things. DANE is = about getting a temporary trust anchor for a particular = port/transport/domainname triple for a server, whereas WebID is about = identifying clients through an HTTPS lookup. There has been discussion = of using DANE to get a temporary trust anchor for S/MIME clients, and = that might be extended to doing so for TLS clients, but it would be done = using the DNS protocol. >=20 > yes, that is where each of us understanding the other could help see = where some of these things would fit best. S/MIME it seems to me is = closer to client authentication, and so would better fit in with WebID. >=20 > Henry Story >=20 > [1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009 >=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 --Apple-Mail-4--845477204 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[Before reading this in the context of 'PKI vendor = speaks', I would like to point out to people on the list that Comodo is = now an announced provider of DNS services under the brand = DNS.com.]


It is not very clear to me what is being proposed = here.

I was not proposing anything to = start of with, other than to show at what level the protocols are = similar. That of course cannot be a proposal, only a point of = interest. 

Noticing that similarity was = useful in helping me understand what keyassure is doing.  And = understanding that similarity also led me to ask why you don't also = allow one to publish the plain and simple public key  in addition = perhaps to the 4 methods listed in section 2.2 of draft-4. My point = there was that that should be enough to do a lot of what you want. See = the =3D=3DIDEA=3D=3D section. The supporting evidence for this is that = this is enough for us at the WebID = level. 



Let's start from first principles. As far as internet = users are concerned, an Internet user identifier is user@example.com

In WebID we consider essentially an http url such as = http://bblfish.net/#me as it is = immediately dereferenceable,

I know that there are people trying to peddle URIs as user = identifiers but the success of that approach is evidenced by the fact = that OpenID support is contracting rather than = expanding.

There are many reasons = why OpenId is having trouble. The main one being that the user has to = remember what to type, and has to type it. With WebID this is integrated = into the SSL layer, so the user only needs to point and click. There is = a 4 minute video on http://bblfish.net/ (the second one) = that demonstrates this. 

There is a whole = list of other reasons why TLS works better, many of them I have gathered = here



Given user@example.com = as the identifier, 

DNS is an appropriate = mechanism to resolve attributes bound to the 'example.com' = portion.

exactly. DNS is the = Canonical lookup method for a DNS name :-)


DNS is an appropriate mechanism to use to discover a = service that can resolve the 'user' portion for 'example.com

yes (though if it can be avoided then that can be better) But = it gives some useful flexibility.

DNS is not an appropriate place to store attributes = specific to 'user@example.com'.
=

Completely agree. 



We already have a Web = Service that is designed to serve as a key centric distribution = mechanism for per-user data and it happens to be a W3C recommendation - = XKMS.

Thanks for pointing that one = out. It looks like one of the SOAPy specs. This should be = useful.
WebID is working within the linked data architectural = space, where you put things at their URI location, and you try to = restrict yourself to the RESTful verbs (GET, PUT, POST, = DELETE)


I think it would be entirely appropriate to use DNS = assured keys to validate an XKMS service. 
We could also = take the XKMS schema and use it within = FOAF.

yes, so with WebID we use = the DNS assured keys, to power up TLS, so that https becomes a way to = validate the foaf document returned - that it has not been corrupted on = the way. So that way we have part of the work of what XKMS does, but = using simple HTTP. (Need to study XKMS in more = detail)

I think that there are = many possibilities here. But they are way off topic for this = group. 

Yes.


Would it be possible for people = interested in this area to Bar BoF in = Prague?

(I am in Paris btw. But = let me know).

Don't forget the issue that I = raised that is relevant to this group, namely the idea of putting the = public keys in DNS, without all the extra = stuff.

Henry



On Fri, Feb 11, 2011 at 7:19 AM, Henry = Story <henry.story@bblfish.net> wrote:

On 11 Feb 2011, at 01:48, Paul Hoffman wrote:

> On 2/10/11 2:41 PM, Henry Story wrote:
>> Keyassure will probably use the DNS-ID typed subject = alternative name
>> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 = certifactes
>> to identify the server as suggested is good practice by
>> http://tools.ietf.org/html/draft-saintandre-tls-server-i= d-check-14#section-2.3
>
> In your earlier message, you said:
>
>> (I have not seen a draft spec yet, and am going from the = group
>> description).
>
> Please do read the draft. What you say here, which predicates the = rest
> of your message about similarities with the WebID work, is not at = all
> correct.

Yes, I just read the draft dane 4
http://tools.ietf.org/html/draft-ietf-dane-protocol-04

I don't think I was far off, but still perhaps too cryptic. In section = 2.2 it states that there are four types of things that can be published = in the TLSA record

 1 -- Hash of an end-entity certificate
 2 -- Full end-entity certificate in DER encoding
 3 -- Hash of an certification authority's certificate
 4 -- Full certification authority's certificate in DER = encoding

So if in 2 the certificate is a DER encoded X509 cert, then if it is a = server certificate it should contain according to draft-saintandre the = Domain Name in the SAN field. There are a few different types of SAN = fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is = a lot closer to what you are specifying in the RDATA format. (Though it = looks like that RFC could be improved to allow port numbers to be = specified, as you do)

So if someone came across such a certificate with such a SRV-ID, they = could after finding the SAN do a lookup in DNSSEC and verify that this = is indeed the correct/current certificate. In some ways this is similar = to finding an html page with a
   <link rel=3D"self" href=3D"http://bblfish.net/"/>
You could use it to lookup the current version of the page. What you = have in your hand is a cached copy.

Now if you do one more little conceptual jump and you allow that one can = name things including agents with an http(s) URI then he can put that = URI in the SAN field. So I have a WebID

  http://bblfish.net/people/henry/card#me

Doing a lookup using HTTP will get the meaning of that URI - and so a = description of me. That URI could return a PEM certificate too, just as = you do in the DNS lookup (we are discussing allowing this in addition to = RDF/XML, rdfa, or other XML representations)

  Good so I think we have two protocols - yours and WebID - that = both can do the following and that are very similar in those = respect:

  1. place an identifier in the X.509 SAN field.
     - for keyassure this is a service identifier = (SRV-ID)
     - for webid this is a URI identifier
  2. dereference the ID to get the latest version
     - using DNS lookup for keyassure
     - using HTTP/HTTPS/ftp... lookup for WebID
  3. Proving authenticity
  both protocols use the information retrieved canonically at the = identifier to prove authenticity.
     - with WebID the relying party uses the public key = published there to verify that the agent connecting to it is indeed = named by that URI. He is if he could prove in the TLS handshake that he = knew the corresponding private key.
     - with keyassure by proving that there is the = appropriate link between the keys/signature published in 1-4 and the = certificate sent by the TLS server.

  Essentially point 3 - proving authenticity - works because of = what you name a trust anchor. I am just pointing out that this trust = anchor is tied to a naming system and a canonical lookup procedure in = both cases.

  Ok, so I think that demonstrates quite clearly that there are a = lot of similarities. So what is the use of knowing that?

  Well I think for me that helps confirm my WebID intuitions. When = I spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a = few years ago, the possibility of something like keyassure helped me = feel we could bypass the most damaging of his critiques against the = current PKI setup. WebID does not need CAs, and with keyassure web = servers won't need them either. We are still left with the clumsy ASN.1 = format, but that can be solved over time with better parsers, or, since = TLS allows it, to some better defined format such as binary xml = perhaps.

  Another advantage of having two very similar protocols = developing, especially as they are not stepping on each others toes, is = that we may be able to learn a few tricks from one another. So here is = one initial idea that occurred to me reading your spec today.

  =3D=3D IDEA =3D=3D

  Currently you are publishing either a signature or a certificate = in the DNS. Why not publish the only piece of the certificate that is = important: the public key. This is what WebID does. This should be = shorter than the certificate, and though it will be longer than the = signature, it will be a lot more useful, tying you much less to a = particular serialisation format.

 There is no need to send a full certificate. All you need is to = tie a name to a public key and to guarantee to the end user the = integrity of the information. But the integrity is itself assured by = DNSSEC. The tying of the name to the public key is done by the lookup in = DNS. So all that is really required is to return the public key - the = type and the fields.

 One could then even imagine a TLS improvement where the server = would not need to send his certificate either. All the TLS server would = need to do is prove that he can encrypt something with his private key. = The public key would be fetched from the DNS. So at that point we will = have gotten rid of ASN.1 or at least just kept the minimum needed. This = would be the server equivalent of the client_certificate_url extension = of TLS 1.2 where the client can send a URL to a location of his = certificate, instead of sending his certificate. Here the server would = not need to send his certificate, and for self signed certificates, the = DNS sending the public key would be enough anyway.

 So I hope this helps clarify the similarities of the two = protocols as well as the usefulness of our interaction.

> This is not to say that what WebID is doing can't work with the = DANE effort, just that we are doing completely different things. DANE is = about getting a temporary trust anchor for a particular = port/transport/domainname triple for a server, whereas WebID is about = identifying clients through an HTTPS lookup. There has been discussion = of using DANE to get a temporary trust anchor for S/MIME clients, and = that might be extended to doing so for TLS clients, but it would be done = using the DNS protocol.

yes, that is where each of us understanding the other could help = see where some of these things would fit best. S/MIME it seems to me is = closer to client authentication, and so would better fit in with = WebID.

       Henry Story

[1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_a= t_har2009

<= /blockquote>



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


= --Apple-Mail-4--845477204-- 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 4A2913A69A5 for ; Fri, 11 Feb 2011 06:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=0.245, 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 zRVxTrOhBp9e for ; Fri, 11 Feb 2011 06:14: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 D95823A6A19 for ; Fri, 11 Feb 2011 06:14:22 -0800 (PST) Received: by yie19 with SMTP id 19so1207957yie.31 for ; Fri, 11 Feb 2011 06:14:37 -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=dnD5KIyIG0GcPfiR+6+QSyR8fpL5c88N1IkaGEQY5io=; b=CdKRmviw8x7hJh1THkCTCfJH6XwNt8tUSE6K0QOQU0/amGqmGHX/Nl0Na3rjd6se3F ODYik57STuMlkfdnJ4XdW2ZNlsaMz/l5Gkew0UexxgRldtzYIRmggssPl9QF6fCEDrkY qL1/1ClaGpN+RLJ49vo1+ZIIgQxBgh3MUga80= 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=hCf1TlHtjoKmD0QCJ/Or6EHq861VWllD1WJ1ELqJBuWTIX/TCso2ED60gNyUNjvIri 54vxQn5SRev4kB/QNLlDrKHOf805gVOkcUldgZUHTCsqgGurRMOnffH1nIbFjUh8/mGG Ui5YOzEfH5b7cjWlodJSTOWT65EAHbfGHkQrc= MIME-Version: 1.0 Received: by 10.100.206.17 with SMTP id d17mr64274ang.74.1297433677552; Fri, 11 Feb 2011 06:14:37 -0800 (PST) Received: by 10.100.244.38 with HTTP; Fri, 11 Feb 2011 06:14:37 -0800 (PST) In-Reply-To: <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> Date: Fri, 11 Feb 2011 09:14:37 -0500 Message-ID: From: Phillip Hallam-Baker To: Henry Story Content-Type: multipart/alternative; boundary=001636b43247785b9a049c0251b0 Cc: keyassure@ietf.org, Paul Hoffman Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 14:14:25 -0000 --001636b43247785b9a049c0251b0 Content-Type: text/plain; charset=ISO-8859-1 [Before reading this in the context of 'PKI vendor speaks', I would like to point out to people on the list that Comodo is now an announced provider of DNS services under the brand DNS.com.] It is not very clear to me what is being proposed here. Let's start from first principles. As far as internet users are concerned, an Internet user identifier is user@example.com I know that there are people trying to peddle URIs as user identifiers but the success of that approach is evidenced by the fact that OpenID support is contracting rather than expanding. Given user@example.com as the identifier, DNS is an appropriate mechanism to resolve attributes bound to the ' example.com' portion. DNS is an appropriate mechanism to use to discover a service that can resolve the 'user' portion for 'example.com' DNS is not an appropriate place to store attributes specific to ' user@example.com'. We already have a Web Service that is designed to serve as a key centric distribution mechanism for per-user data and it happens to be a W3C recommendation - XKMS. I think it would be entirely appropriate to use DNS assured keys to validate an XKMS service. We could also take the XKMS schema and use it within FOAF. I think that there are many possibilities here. But they are way off topic for this group. Would it be possible for people interested in this area to Bar BoF in Prague? On Fri, Feb 11, 2011 at 7:19 AM, Henry Story wrote: > > On 11 Feb 2011, at 01:48, Paul Hoffman wrote: > > > On 2/10/11 2:41 PM, Henry Story wrote: > >> Keyassure will probably use the DNS-ID typed subject alternative name > >> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes > >> to identify the server as suggested is good practice by > >> > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3 > > > > In your earlier message, you said: > > > >> (I have not seen a draft spec yet, and am going from the group > >> description). > > > > Please do read the draft. What you say here, which predicates the rest > > of your message about similarities with the WebID work, is not at all > > correct. > > Yes, I just read the draft dane 4 > http://tools.ietf.org/html/draft-ietf-dane-protocol-04 > > I don't think I was far off, but still perhaps too cryptic. In section 2.2 > it states that there are four types of things that can be published in the > TLSA record > > 1 -- Hash of an end-entity certificate > 2 -- Full end-entity certificate in DER encoding > 3 -- Hash of an certification authority's certificate > 4 -- Full certification authority's certificate in DER encoding > > So if in 2 the certificate is a DER encoded X509 cert, then if it is a > server certificate it should contain according to draft-saintandre the > Domain Name in the SAN field. There are a few different types of SAN fields: > DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot > closer to what you are specifying in the RDATA format. (Though it looks like > that RFC could be improved to allow port numbers to be specified, as you do) > > So if someone came across such a certificate with such a SRV-ID, they could > after finding the SAN do a lookup in DNSSEC and verify that this is indeed > the correct/current certificate. In some ways this is similar to finding an > html page with a > > You could use it to lookup the current version of the page. What you have > in your hand is a cached copy. > > Now if you do one more little conceptual jump and you allow that one can > name things including agents with an http(s) URI then he can put that URI in > the SAN field. So I have a WebID > > http://bblfish.net/people/henry/card#me > > Doing a lookup using HTTP will get the meaning of that URI - and so a > description of me. That URI could return a PEM certificate too, just as you > do in the DNS lookup (we are discussing allowing this in addition to > RDF/XML, rdfa, or other XML representations) > > Good so I think we have two protocols - yours and WebID - that both can > do the following and that are very similar in those respect: > > 1. place an identifier in the X.509 SAN field. > - for keyassure this is a service identifier (SRV-ID) > - for webid this is a URI identifier > 2. dereference the ID to get the latest version > - using DNS lookup for keyassure > - using HTTP/HTTPS/ftp... lookup for WebID > 3. Proving authenticity > both protocols use the information retrieved canonically at the > identifier to prove authenticity. > - with WebID the relying party uses the public key published there to > verify that the agent connecting to it is indeed named by that URI. He is if > he could prove in the TLS handshake that he knew the corresponding private > key. > - with keyassure by proving that there is the appropriate link between > the keys/signature published in 1-4 and the certificate sent by the TLS > server. > > Essentially point 3 - proving authenticity - works because of what you > name a trust anchor. I am just pointing out that this trust anchor is tied > to a naming system and a canonical lookup procedure in both cases. > > Ok, so I think that demonstrates quite clearly that there are a lot of > similarities. So what is the use of knowing that? > > Well I think for me that helps confirm my WebID intuitions. When I spoke > to Dan Kaminsky after his talk "X509 considered harmful" [1] a few years > ago, the possibility of something like keyassure helped me feel we could > bypass the most damaging of his critiques against the current PKI setup. > WebID does not need CAs, and with keyassure web servers won't need them > either. We are still left with the clumsy ASN.1 format, but that can be > solved over time with better parsers, or, since TLS allows it, to some > better defined format such as binary xml perhaps. > > Another advantage of having two very similar protocols developing, > especially as they are not stepping on each others toes, is that we may be > able to learn a few tricks from one another. So here is one initial idea > that occurred to me reading your spec today. > > == IDEA == > > Currently you are publishing either a signature or a certificate in the > DNS. Why not publish the only piece of the certificate that is important: > the public key. This is what WebID does. This should be shorter than the > certificate, and though it will be longer than the signature, it will be a > lot more useful, tying you much less to a particular serialisation format. > > There is no need to send a full certificate. All you need is to tie a name > to a public key and to guarantee to the end user the integrity of the > information. But the integrity is itself assured by DNSSEC. The tying of the > name to the public key is done by the lookup in DNS. So all that is really > required is to return the public key - the type and the fields. > > One could then even imagine a TLS improvement where the server would not > need to send his certificate either. All the TLS server would need to do is > prove that he can encrypt something with his private key. The public key > would be fetched from the DNS. So at that point we will have gotten rid of > ASN.1 or at least just kept the minimum needed. This would be the server > equivalent of the client_certificate_url extension of TLS 1.2 where the > client can send a URL to a location of his certificate, instead of sending > his certificate. Here the server would not need to send his certificate, and > for self signed certificates, the DNS sending the public key would be enough > anyway. > > So I hope this helps clarify the similarities of the two protocols as well > as the usefulness of our interaction. > > > This is not to say that what WebID is doing can't work with the DANE > effort, just that we are doing completely different things. DANE is about > getting a temporary trust anchor for a particular port/transport/domainname > triple for a server, whereas WebID is about identifying clients through an > HTTPS lookup. There has been discussion of using DANE to get a temporary > trust anchor for S/MIME clients, and that might be extended to doing so for > TLS clients, but it would be done using the DNS protocol. > > yes, that is where each of us understanding the other could help see where > some of these things would fit best. S/MIME it seems to me is closer to > client authentication, and so would better fit in with WebID. > > Henry Story > > [1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009 > > > > > > > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636b43247785b9a049c0251b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[Before reading this in the context of 'PKI vendor speaks', I = would like to point out to people on the list that Comodo is now an announc= ed provider of DNS services under the brand DNS.com.]


It is not very clear to me what is being proposed here.
=
Let's start from first principles. As far as internet us= ers are concerned, an Internet user identifier is user@example.com

I know that there are people trying to peddle URIs as u= ser identifiers but the success of that approach is evidenced by the fact t= hat OpenID support is contracting rather than expanding.


Given user@ex= ample.com as the identifier,=A0

DNS is an appr= opriate mechanism to resolve attributes bound to=A0the 'example.com' portion.

DNS is an appropriate mechanism= to use to discover a service that can resolve the 'user' portion f= or 'example.com'

<= /div>
DNS is not an appropriate place to store attributes specific to '<= a href=3D"mailto:user@example.com">user@example.com'.

We already have a Web Service that is designed t= o serve as a key centric distribution mechanism for per-user data and it ha= ppens to be a W3C recommendation - XKMS.

I think it would be entirely appropriate to use DNS ass= ured keys to validate an XKMS service.=A0

We could= also take the XKMS schema and use it within FOAF.


I think that there are many possibilities here. But they are= way off topic for this group.=A0

Would it be poss= ible for people interested in this area to Bar BoF in Prague?

On Fri, Feb 11, 2011 at 7:19 AM, Henry Story= <henry.sto= ry@bblfish.net> wrote:

On 11 Feb 2011, at 01:48, Paul Hoffman wrote:

> On 2/10/11 2:41 PM, Henry Story wrote:
>> Keyassure will probably use the DNS-ID typed subject alternative n= ame
>> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifac= tes
>> to identify the server as suggested is good practice by
>> http://tools.ietf.org/html/draft= -saintandre-tls-server-id-check-14#section-2.3
>
> In your earlier message, you said:
>
>> (I have not seen a draft spec yet, and am going from the group
>> description).
>
> Please do read the draft. What you say here, which predicates the rest=
> of your message about similarities with the WebID work, is not at all<= br> > correct.

Yes, I just read the draft dane 4
http://tools.ietf.org/html/draft-ietf-dane-protocol-04

I don't think I was far off, but still perhaps too cryptic. In section = 2.2 it states that there are four types of things that can be published in = the TLSA record

=A01 -- Hash of an end-entity certificate
=A02 -- Full end-entity certificate in DER encoding
=A03 -- Hash of an certification authority's certificate
=A04 -- Full certification authority's certificate in DER encoding

So if in 2 the certificate is a DER encoded X509 cert, then if it is a serv= er certificate it should contain according to draft-saintandre the Domain N= ame in the SAN field. There are a few different types of SAN fields: DNS-ID= , SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot closer to = what you are specifying in the RDATA format. (Though it looks like that RFC= could be improved to allow port numbers to be specified, as you do)

So if someone came across such a certificate with such a SRV-ID, they could= after finding the SAN do a lookup in DNSSEC and verify that this is indeed= the correct/current certificate. In some ways this is similar to finding a= n html page with a
=A0 =A0<link rel=3D"self" href=3D"http://bblfish.net/"/>
You could use it to lookup the current version of the page. What you have i= n your hand is a cached copy.

Now if you do one more little conceptual jump and you allow that one can na= me things including agents with an http(s) URI then he can put that URI in = the SAN field. So I have a WebID

=A0 = http://bblfish.net/people/henry/card#me

Doing a lookup using HTTP will get the meaning of that URI - and so a descr= iption of me. That URI could return a PEM certificate too, just as you do i= n the DNS lookup (we are discussing allowing this in addition to RDF/XML, r= dfa, or other XML representations)

=A0 Good so I think we have two protocols - yours and WebID - that both ca= n do the following and that are very similar in those respect:

=A0 1. place an identifier in the X.509 SAN field.
=A0 =A0 =A0- for keyassure this is a service identifier (SRV-ID)
=A0 =A0 =A0- for webid this is a URI identifier
=A0 2. dereference the ID to get the latest version
=A0 =A0 =A0- using DNS lookup for keyassure
=A0 =A0 =A0- using HTTP/HTTPS/ftp... lookup for WebID
=A0 3. Proving authenticity
=A0 both protocols use the information retrieved canonically at the identi= fier to prove authenticity.
=A0 =A0 =A0- with WebID the relying party uses the public key published th= ere to verify that the agent connecting to it is indeed named by that URI. = He is if he could prove in the TLS handshake that he knew the corresponding= private key.
=A0 =A0 =A0- with keyassure by proving that there is the appropriate link = between the keys/signature published in 1-4 and the certificate sent by the= TLS server.

=A0 Essentially point 3 - proving authenticity - works because of what you= name a trust anchor. I am just pointing out that this trust anchor is tied= to a naming system and a canonical lookup procedure in both cases.

=A0 Ok, so I think that demonstrates quite clearly that there are a lot of= similarities. So what is the use of knowing that?

=A0 Well I think for me that helps confirm my WebID intuitions. When I spo= ke to Dan Kaminsky after his talk "X509 considered harmful" [1] a= few years ago, the possibility of something like keyassure helped me feel = we could bypass the most damaging of his critiques against the current PKI = setup. WebID does not need CAs, and with keyassure web servers won't ne= ed them either. We are still left with the clumsy ASN.1 format, but that ca= n be solved over time with better parsers, or, since TLS allows it, to some= better defined format such as binary xml perhaps.

=A0 Another advantage of having two very similar protocols developing, esp= ecially as they are not stepping on each others toes, is that we may be abl= e to learn a few tricks from one another. So here is one initial idea that = occurred to me reading your spec today.

=A0 =3D=3D IDEA =3D=3D

=A0 Currently you are publishing either a signature or a certificate in th= e DNS. Why not publish the only piece of the certificate that is important:= the public key. This is what WebID does. This should be shorter than the c= ertificate, and though it will be longer than the signature, it will be a l= ot more useful, tying you much less to a particular serialisation format.
=A0There is no need to send a full certificate. All you need is to tie a n= ame to a public key and to guarantee to the end user the integrity of the i= nformation. But the integrity is itself assured by DNSSEC. The tying of the= name to the public key is done by the lookup in DNS. So all that is really= required is to return the public key - the type and the fields.

=A0One could then even imagine a TLS improvement where the server would no= t need to send his certificate either. All the TLS server would need to do = is prove that he can encrypt something with his private key. The public key= would be fetched from the DNS. So at that point we will have gotten rid of= ASN.1 or at least just kept the minimum needed. This would be the server e= quivalent of the client_certificate_url extension of TLS 1.2 where the clie= nt can send a URL to a location of his certificate, instead of sending his = certificate. Here the server would not need to send his certificate, and fo= r self signed certificates, the DNS sending the public key would be enough = anyway.

=A0So I hope this helps clarify the similarities of the two protocols as w= ell as the usefulness of our interaction.

> This is not to say that what WebID is doing can't work with the DA= NE effort, just that we are doing completely different things. DANE is abou= t getting a temporary trust anchor for a particular port/transport/domainna= me triple for a server, whereas WebID is about identifying clients through = an HTTPS lookup. There has been discussion of using DANE to get a temporary= trust anchor for S/MIME clients, and that might be extended to doing so fo= r TLS clients, but it would be done using the DNS protocol.

yes, that is where each of us understanding the other could help see = where some of these things would fit best. S/MIME it seems to me is closer = to client authentication, and so would better fit in with WebID.

=A0 =A0 =A0 =A0Henry Story

[1] http://blogs.sun.com/bblfish/entry/camping_and_hac= king_at_har2009








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



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

--001636b43247785b9a049c0251b0-- 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 453253A69FF for ; Fri, 11 Feb 2011 06:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.271 X-Spam-Level: X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.327, 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 K-guj4DbJ1FS for ; Fri, 11 Feb 2011 06:01:26 -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 DB16D3A6964 for ; Fri, 11 Feb 2011 06:01:25 -0800 (PST) Received: by gxk27 with SMTP id 27so1198791gxk.31 for ; Fri, 11 Feb 2011 06:01: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=MMi4Z6x5su2Oby4+tDGK63l/YbnUmJivX28kNPJxtfg=; b=BPN2jPFH7C08nv3shOryJEKB0RO+RrI6o7Q4rlz5jkRf974+amq4mrhio3vB0LSNBt VdgIB0J25E7HJLT/JNPtASBLnq39cic11401+pStMmQW8lGt87n05Z+x2Anv2RQzdTbM FYPz2SXb39M81sfeiEpcIf97fm17mJOO1/71c= 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=KYCZkgtpRcfY+uCSJQt2cfL57z9k1ocgMJ7/vV96a7Fp8L/ffhcPVXP2VP/dsHOT9S lCs6Gj2wNRCBc0sDompwodpHnmJMKDiR2KxZX4AHjxmAVzUfLlAy3Iyw79RfN6bCp8S2 3zo4bqyCWBpI8RiB87EyQB6K0x5C/AO7Y/Snw= MIME-Version: 1.0 Received: by 10.100.168.20 with SMTP id q20mr221242ane.244.1297432899744; Fri, 11 Feb 2011 06:01:39 -0800 (PST) Received: by 10.100.244.38 with HTTP; Fri, 11 Feb 2011 06:01:39 -0800 (PST) In-Reply-To: <4D54E4A9.1020104@gmail.com> References: <4D54E4A9.1020104@gmail.com> Date: Fri, 11 Feb 2011 09:01:39 -0500 Message-ID: From: Phillip Hallam-Baker To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016e64402141bf5c0049c022327 Cc: keyassure@ietf.org Subject: Re: [keyassure] dane-04 trust anchors 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, 11 Feb 2011 14:01:27 -0000 --0016e64402141bf5c0049c022327 Content-Type: text/plain; charset=ISO-8859-1 This is an issue, but a fairly easy one to deal with and one that is already dealt with when dealing with self-signed certs. The browser writers know this stuff already. Some of the people who were doing security code in 1995 were clueless. In fact we all pretty much were (but in different ways). But that has not been an issue since Netscape hired Taher and the brothers Weinstein. There is a very simple principle here: DNS cannot extend any positive claims beyond the DNS name itself DNS can however extend negative claims and restrictions. A domain can't say 'trust me I am a bank' but it can say 'take extra security precautions, in case I am a bank' On Fri, Feb 11, 2011 at 2:26 AM, Yaron Sheffer wrote: > Hi, > > the new text is a major improvement over the previous version. But it is > still missing some necessary guidance. > > My reference scenario is this: I am a phisher. I'd like to trick BigBank's > customers, so I acquire bigbang.com (an easy misspelling). Now I can get a > certificate that they will use as a trust anchor, and include whatever I > want in it, such as the Subject field, "Your trusted BigBank". > > Moreover, even if I am the rightful owner, the current text does not allow > me to restrict the certificate's use. > > So I propose the following text added: > > Client treatment of any non-key information included in the trust anchor is > a matter of local policy. It is noted that this specification does not > mandate that such information be inspected or validated by the domain > registrar. > > The client MUST obey any constraints included in the trust anchor, > including but not limited to: > - Validity period. > - Key usage fields. > - Path length constraints. > - Name constraints. > The normal rules of RFC 5280 apply. > > Thanks, > Yaron > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e64402141bf5c0049c022327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is an issue, but a fairly easy one to deal with and one that is alread= y dealt with when dealing with self-signed certs. The browser writers know = this stuff already.

Some of the people who were doing se= curity code in 1995 were clueless. In fact we all pretty much were (but in = different ways). But that has not been an issue since Netscape hired Taher = and the brothers Weinstein.


There is a very simple principle here:

DNS cannot extend any positive claims beyond the DN= S name itself

DNS can however extend negative clai= ms and restrictions.

A domain can't say 'trust me I am a bank' b= ut it can say 'take extra security precautions, in case I am a bank'= ;



On Fri, Feb 11, 2011 at 2:26 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wro= te:
Hi,

the new text is a major improvement over the previous version. But it is st= ill missing some necessary guidance.

My reference scenario is this: I am a phisher. I'd like to trick BigBan= k's customers, so I acquire bigbang.com (an easy misspelling). Now I can get a certificate th= at they will use as a trust anchor, and include whatever I want in it, such= as the Subject field, "Your trusted BigBank".

Moreover, even if I am the rightful owner, the current text does not allow = me to restrict the certificate's use.

So I propose the following text added:

Client treatment of any non-key information included in the trust anchor is= a matter of local policy. It is noted that this specification does not man= date that such information be inspected or validated by the domain registra= r.

The client MUST obey any constraints included in the trust anchor, includin= g but not limited to:
- Validity period.
- Key usage fields.
- Path length constraints.
- Name constraints.
The normal rules of RFC 5280 apply.

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



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

--0016e64402141bf5c0049c022327-- 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 298BA3A6823 for ; Fri, 11 Feb 2011 04:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ITuzEBNkn91q for ; Fri, 11 Feb 2011 04:19:54 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3D4CB3A688C for ; Fri, 11 Feb 2011 04:19:53 -0800 (PST) Received: by bwz12 with SMTP id 12so3418091bwz.31 for ; Fri, 11 Feb 2011 04:20:08 -0800 (PST) Received: by 10.204.14.6 with SMTP id e6mr383659bka.9.1297426807369; Fri, 11 Feb 2011 04:20:07 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id 12sm424811bki.19.2011.02.11.04.19.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Feb 2011 04:19:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4D54876A.4090302@vpnc.org> Date: Fri, 11 Feb 2011 13:19:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E533869-1CCF-4256-84D4-E15578BAE4E1@bblfish.net> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> <4D54876A.4090302@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 12:19:59 -0000 On 11 Feb 2011, at 01:48, Paul Hoffman wrote: > On 2/10/11 2:41 PM, Henry Story wrote: >> Keyassure will probably use the DNS-ID typed subject alternative name >> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes >> to identify the server as suggested is good practice by >> = http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section= -2.3 >=20 > In your earlier message, you said: >=20 >> (I have not seen a draft spec yet, and am going from the group >> description). >=20 > Please do read the draft. What you say here, which predicates the rest > of your message about similarities with the WebID work, is not at all > correct. Yes, I just read the draft dane 4=20 http://tools.ietf.org/html/draft-ietf-dane-protocol-04 I don't think I was far off, but still perhaps too cryptic. In section = 2.2 it states that there are four types of things that can be published = in the TLSA record 1 -- Hash of an end-entity certificate 2 -- Full end-entity certificate in DER encoding 3 -- Hash of an certification authority's certificate 4 -- Full certification authority's certificate in DER encoding So if in 2 the certificate is a DER encoded X509 cert, then if it is a = server certificate it should contain according to draft-saintandre the = Domain Name in the SAN field. There are a few different types of SAN = fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is = a lot closer to what you are specifying in the RDATA format. (Though it = looks like that RFC could be improved to allow port numbers to be = specified, as you do) So if someone came across such a certificate with such a SRV-ID, they = could after finding the SAN do a lookup in DNSSEC and verify that this = is indeed the correct/current certificate. In some ways this is similar = to finding an html page with a=20 =20 You could use it to lookup the current version of the page. What you = have in your hand is a cached copy. Now if you do one more little conceptual jump and you allow that one can = name things including agents with an http(s) URI then he can put that = URI in the SAN field. So I have a WebID=20 http://bblfish.net/people/henry/card#me Doing a lookup using HTTP will get the meaning of that URI - and so a = description of me. That URI could return a PEM certificate too, just as = you do in the DNS lookup (we are discussing allowing this in addition to = RDF/XML, rdfa, or other XML representations) Good so I think we have two protocols - yours and WebID - that both = can do the following and that are very similar in those respect: 1. place an identifier in the X.509 SAN field.=20 - for keyassure this is a service identifier (SRV-ID) - for webid this is a URI identifier 2. dereference the ID to get the latest version - using DNS lookup for keyassure - using HTTP/HTTPS/ftp... lookup for WebID 3. Proving authenticity=20 both protocols use the information retrieved canonically at the = identifier to prove authenticity. - with WebID the relying party uses the public key published there = to verify that the agent connecting to it is indeed named by that URI. = He is if he could prove in the TLS handshake that he knew the = corresponding private key. - with keyassure by proving that there is the appropriate link = between the keys/signature published in 1-4 and the certificate sent by = the TLS server. Essentially point 3 - proving authenticity - works because of what = you name a trust anchor. I am just pointing out that this trust anchor = is tied to a naming system and a canonical lookup procedure in both = cases.=20 Ok, so I think that demonstrates quite clearly that there are a lot = of similarities. So what is the use of knowing that? Well I think for me that helps confirm my WebID intuitions. When I = spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a few = years ago, the possibility of something like keyassure helped me feel we = could bypass the most damaging of his critiques against the current PKI = setup. WebID does not need CAs, and with keyassure web servers won't = need them either. We are still left with the clumsy ASN.1 format, but = that can be solved over time with better parsers, or, since TLS allows = it, to some better defined format such as binary xml perhaps. Another advantage of having two very similar protocols developing, = especially as they are not stepping on each others toes, is that we may = be able to learn a few tricks from one another. So here is one initial = idea that occurred to me reading your spec today. =3D=3D IDEA =3D=3D Currently you are publishing either a signature or a certificate in = the DNS. Why not publish the only piece of the certificate that is = important: the public key. This is what WebID does. This should be = shorter than the certificate, and though it will be longer than the = signature, it will be a lot more useful, tying you much less to a = particular serialisation format. There is no need to send a full certificate. All you need is to tie a = name to a public key and to guarantee to the end user the integrity of = the information. But the integrity is itself assured by DNSSEC. The = tying of the name to the public key is done by the lookup in DNS. So all = that is really required is to return the public key - the type and the = fields. One could then even imagine a TLS improvement where the server would = not need to send his certificate either. All the TLS server would need = to do is prove that he can encrypt something with his private key. The = public key would be fetched from the DNS. So at that point we will have = gotten rid of ASN.1 or at least just kept the minimum needed. This would = be the server equivalent of the client_certificate_url extension of TLS = 1.2 where the client can send a URL to a location of his certificate, = instead of sending his certificate. Here the server would not need to = send his certificate, and for self signed certificates, the DNS sending = the public key would be enough anyway. So I hope this helps clarify the similarities of the two protocols as = well as the usefulness of our interaction. > This is not to say that what WebID is doing can't work with the DANE = effort, just that we are doing completely different things. DANE is = about getting a temporary trust anchor for a particular = port/transport/domainname triple for a server, whereas WebID is about = identifying clients through an HTTPS lookup. There has been discussion = of using DANE to get a temporary trust anchor for S/MIME clients, and = that might be extended to doing so for TLS clients, but it would be done = using the DNS protocol. yes, that is where each of us understanding the other could help see = where some of these things would fit best. S/MIME it seems to me is = closer to client authentication, and so would better fit in with WebID. Henry Story [1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009 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 CB2EB3A6B19 for ; Thu, 10 Feb 2011 23:26:23 -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 tNLXvWFi9OLh for ; Thu, 10 Feb 2011 23:26:22 -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 DB6443A6AFC for ; Thu, 10 Feb 2011 23:26:21 -0800 (PST) Received: by fxm9 with SMTP id 9so2775789fxm.31 for ; Thu, 10 Feb 2011 23:26:35 -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:content-type:content-transfer-encoding; bh=uLjEpOvO5AWhGDttlEIrXFBEnHrBa5MDCFCjZzv8iwI=; b=bxGzOet7IbnpQqXGC3U6RrT3h5PRbs1EAc0tPc7KP3S4bTc+iY4B4liy9ejBhAgIxI XBycA/aCKLyi7+//fsciw/qRHcYFNyI5wSZLU+hioeMTEYwl/n2Gk542q83oqeYAD+Mm aIJW9Us07tOaAoz8/QGTRkkwCAfE1BU2HzvKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=IbYkJd/D2LVyouH+cLvcfIjJVzuT2pq23zTRch/yQPtPGId7jxmqipjRZQ+xkPDSTN IYPDcEEXDta4/z1+qWsIFiH6oeSNxvP/tTrtVTaTAUNlEDjegXfY1U5rICPEZZFqiW83 FsmxbIHK3Cf8tv6Z+2L+O19cDWd8Az0Wbilz8= Received: by 10.223.107.133 with SMTP id b5mr168880fap.87.1297409195273; Thu, 10 Feb 2011 23:26:35 -0800 (PST) Received: from [10.0.0.1] (bzq-79-179-49-128.red.bezeqint.net [79.179.49.128]) by mx.google.com with ESMTPS id 17sm180571far.19.2011.02.10.23.26.34 (version=SSLv3 cipher=OTHER); Thu, 10 Feb 2011 23:26:34 -0800 (PST) Message-ID: <4D54E4A9.1020104@gmail.com> Date: Fri, 11 Feb 2011 09:26:33 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [keyassure] dane-04 trust anchors 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, 11 Feb 2011 07:26:23 -0000 Hi, the new text is a major improvement over the previous version. But it is still missing some necessary guidance. My reference scenario is this: I am a phisher. I'd like to trick BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now I can get a certificate that they will use as a trust anchor, and include whatever I want in it, such as the Subject field, "Your trusted BigBank". Moreover, even if I am the rightful owner, the current text does not allow me to restrict the certificate's use. So I propose the following text added: Client treatment of any non-key information included in the trust anchor is a matter of local policy. It is noted that this specification does not mandate that such information be inspected or validated by the domain registrar. The client MUST obey any constraints included in the trust anchor, including but not limited to: - Validity period. - Key usage fields. - Path length constraints. - Name constraints. The normal rules of RFC 5280 apply. Thanks, 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 0DF6C3A6B92 for ; Thu, 10 Feb 2011 22:23: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=-1.000, 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 g9iX4v+c+tNG for ; Thu, 10 Feb 2011 22:22: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 556613A6870 for ; Thu, 10 Feb 2011 22:22:48 -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 p1B6MsXO006603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Feb 2011 07:22:56 +0100 From: Simon Josefsson To: Paul Hoffman References: <4D54A5FD.8060809@vpnc.org> <1297395379.1903.29.camel@mattlaptop2.local> <4D54B619.1070903@vpnc.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110211:keyassure@ietf.org::m9Zo4Ee7gH7/XTiK:3d22 X-Hashcash: 1:22:110211:paul.hoffman@vpnc.org::7F0FA4PaYBN0/bRx:IfcX Date: Fri, 11 Feb 2011 07:22:53 +0100 In-Reply-To: <4D54B619.1070903@vpnc.org> (Paul Hoffman's message of "Thu, 10 Feb 2011 20:07:53 -0800") Message-ID: <87zkq36qf6.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] Special, four issues (#2, #9, #13, #18) for the price of one.... 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, 11 Feb 2011 06:23:05 -0000 Paul Hoffman writes: > On 2/10/11 7:36 PM, Matt McCutchen wrote: >> On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote: >>> Jakob and I would definitely like to hear more on this. If we need to >>> say more about what a trust anchor is, we can do that. If people think >>> we have over-restricted it in -04, that's good input as well. >> >> I haven't fully considered the issue, I just have two nits to pick: >> >>> The -04 >>> text in question is: >>> >>> A TLS client conforming to this protocol MUST treat the certificate >>> for association in a TLSA resource record for a domain name as a >>> trust anchor for that domain name at the specific port number and >>> transport name that was queried. This trust anchor MUST only be used >>> for the domain name of the resource record. >> >> And port number and transport protocol name. > > Why should we put on that requirement? That is, if I get a trust > anchor for _443._tcp.www.example.com, what is the security issue if I > also want to use it for TLS on port 4443? There is no attack that an > MITM can mount on 4443 that they cannot also mount on 443. You may want to run a commercial CA on port 443 to get good interop with deployed https clients, but you may want to use a trustworthy CA on port 4443 to get good security for some other services. Having the commercial CA be able to MITM the connection on 4443 sounds counter to what I perceive DANE is aiming to achieve. /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 A058B3A6884 for ; Thu, 10 Feb 2011 21:49:36 -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=[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 MIQRtccDLrQR for ; Thu, 10 Feb 2011 21:49:35 -0800 (PST) Received: from ppa03.princeton.edu (ppa03.Princeton.EDU [128.112.128.214]) by core3.amsl.com (Postfix) with ESMTP id 8F7913A687A for ; Thu, 10 Feb 2011 21:49:35 -0800 (PST) Received: from csgsmtp200l.Princeton.EDU (csgsmtp200l.Princeton.EDU [128.112.130.131]) by ppa03.princeton.edu (8.14.3/8.14.3) with ESMTP id p1B5nnQF028024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 11 Feb 2011 00:49:49 -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 p1B5nmaw024945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 11 Feb 2011 00:49:49 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Steve Schultze In-Reply-To: <4D3F2B84.1090205@vpnc.org> Date: Fri, 11 Feb 2011 00:49:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <90CE8613-F809-4F0F-97C4-B823F3CBC117@princeton.edu> References: <4D3F2B84.1090205@vpnc.org> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) X-Proofpoint-Virus-Version: vendor=nai engine=5400 definitions=6253 signatures=656543 X-Proofpoint-Spam-Details: rule=quarantine_outbound_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-1102100266 Subject: Re: [keyassure] 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: Fri, 11 Feb 2011 05:49:36 -0000 Sorry I missed this when you first posted.=20 I feel that Matt's proposed language for Section 3 is clearer as to what = is done in different scenarios: http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html For example, the current language in Section 3 does not make clear what = is done in the case of no records or a DNSSEC response of "bogus" . I = like the way Matt's language clearly lays out all of the possible cases = and the results. The one issue with his language is that it assumes the client is doing = DNSSEC validation, but our current language permits "a remote nameserver = to which one has a secured channel of communication." If we are = permitting that, we may have to rephrase some of his specific references = to DNSSEC result status' like "bogus" to be more generic. 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 623E63A6B16 for ; Thu, 10 Feb 2011 21:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[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 1bGRmTOqtjTw for ; Thu, 10 Feb 2011 21:36:08 -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 325793A6848 for ; Thu, 10 Feb 2011 21:36:08 -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=TN/qdAPmEkhYZ6b639buXgUEVHJuWSVCQy+vFvjUSwwZymCZ3Dyf2Cpf 7jDJElv5NONFpkCVm+b1H+QqCEFOJvxe5zb5qngj4xtpkPYHykRBucvkm /Z5phEinCh6fMPO; 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=1297402583; x=1328938583; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Nicholas=20Weaver=20,=20Phillip=20Hallam-Baker=0D=0A=09 |CC:=20"keyassure@ietf.org"=20|Date: =20Thu,=2010=20Feb=202011=2022:36:18=20-0700|Subject:=20R E:=20[keyassure]=20Issue=20#3:=20Format=20of=20the=20reco rd.|Message-ID:=20<5EE049BA3C6538409BBE6F1760F328ABEB3A92 206B@DEN-MEXMS-001.corp.ebay.com>|References:=20<93E6A078 -130F-4CE9-A50F-9A48EEAE3867@kumari.net>=0D=0A=09=0D =0A=20<89E349F1-A6E4-4DC9-AD96-487132B4A4E4@icsi.berkeley .edu>|In-Reply-To:=20<89E349F1-A6E4-4DC9-AD96-487132B4A4E 4@icsi.berkeley.edu>|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0; bh=EBXuleMApGwdjxnhhi0Ts4G/rBX5I13h93EvMsQd/Qs=; b=pXG1omX7snJNUPrSrgLbWoyi6nPr8Nw0xg/R0GEgXGKHS01ihr6u16mF s2x6xV9u/kBzaUynZR10Tj1pA7iI5vDbu0Jm+cqSQILUTJWuheD2G+ix+ yt/48IB0+8JCGps; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,454,1291622400"; d="scan'208";a="1172555" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 10 Feb 2011 21:36:21 -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, 10 Feb 2011 22:36:21 -0700 From: "Steingruebl, Andy" To: Nicholas Weaver , Phillip Hallam-Baker Date: Thu, 10 Feb 2011 22:36:18 -0700 Thread-Topic: [keyassure] Issue #3: Format of the record. Thread-Index: AcvJoyBcffRPJkkERZS3cCl9oIk0/wACk3mA Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB3A92206B@DEN-MEXMS-001.corp.ebay.com> References: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> <89E349F1-A6E4-4DC9-AD96-487132B4A4E4@icsi.berkeley.edu> In-Reply-To: <89E349F1-A6E4-4DC9-AD96-487132B4A4E4@icsi.berkeley.edu> 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: egIprgbde82yRf515u1gdw== 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 #3: Format of the record. 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, 11 Feb 2011 05:36:09 -0000 > -----Original Message----- > From: keyassure-bounces@ietf.org [mailto:keyassure-bounces@ietf.org] On > Behalf Of Nicholas Weaver > And attempting to use a TXT record instead of a new RR is effectively no > more reliable in practice from a delivery perspective. Can you clarify this? I saw Adam Langley's data on lookups of new random R= R types and the failure rates. I hadn't seen data on lookup failures for o= ther types of records, but I could have just overlooked it. Thanks - 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 42C053A684B for ; Thu, 10 Feb 2011 20:20:58 -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 R57LkH3y4HhF for ; Thu, 10 Feb 2011 20:20:57 -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 1269B3A6848 for ; Thu, 10 Feb 2011 20:20:56 -0800 (PST) Received: by yxt33 with SMTP id 33so1011493yxt.31 for ; Thu, 10 Feb 2011 20:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=FlcLwGNnxza8KWu0KJnCW+1uHFS6L4hEDHcGO2Ao5YI=; b=rrpUVp6Wf+N2HGeJvPBtMggYSr3P8NUGFbP9YsPiZh3Dc32e0FxEAjgmfd/mh3cAbI 8+NDiHhyIGTsfCUGB1IJkaSdMDvqcAHRFlaYB+ydIGLYZxtMCXsWoVW5GcWTHhEcisc7 BN8KJMM+P51XxCTRfnDIz2L1jF/ubvDWL9VEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qEo7tobt/9B7Ciw10sW3Tnrw4GZET479n8VkhnUGQyidSziqXlTKtQoApVJFSDMOo7 RVnjWLu4hpa5k/3vDGM5UjcZbP9zjz8GJK1QyJQALzJqeYnWp2uJ2bRZw/fyzbCPl7tQ N5EdStbtsCqTl3oIZS+/8oiN/4bR4MmTd1WNA= Received: by 10.100.112.20 with SMTP id k20mr16050anc.43.1297398070580; Thu, 10 Feb 2011 20:21:10 -0800 (PST) Received: from wl-dy-169-228-179-101.ucsd.edu (wl-dy-169-228-179-101.ucsd.edu [169.228.179.101]) by mx.google.com with ESMTPS id w6sm414587anf.26.2011.02.10.20.21.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Feb 2011 20:21:09 -0800 (PST) Sender: Nicholas Weaver Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 10 Feb 2011 20:21:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <89E349F1-A6E4-4DC9-AD96-487132B4A4E4@icsi.berkeley.edu> References: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #3: Format of the record. 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, 11 Feb 2011 04:20:58 -0000 On Feb 10, 2011, at 8:16 PM, Phillip Hallam-Baker wrote: > Since there is no value in these records without DNSSEC and since this = is a standards track effort, I see no reason not to use a new RR. >=20 > Reuse of an existing RR will make the protocol more complex and harder = to use. >=20 > All infrastructure that will pass and handle DNSSEC will support new = RRs. >=20 > Attempting to use a prefix to the TXT record will not bypass DNSEXT. And attempting to use a TXT record instead of a new RR is effectively no = more reliable in practice from a delivery perspective. > So it has to be at least one new RR. Agreed. 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 9B6DA3A6848 for ; Thu, 10 Feb 2011 20:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=0.490, 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 qSXzb8QAfBQH for ; Thu, 10 Feb 2011 20:16:10 -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 5642E3A684D for ; Thu, 10 Feb 2011 20:16:10 -0800 (PST) Received: by yxt33 with SMTP id 33so1010202yxt.31 for ; Thu, 10 Feb 2011 20:16:23 -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=3z6TSUdVCdhUgptDGsUHi7nOxhIRxGOoVZ46w3+TFVU=; b=kOTR0vCPyNre+M/dNWaxeV9hoLCHqbo4Ptc4ZS8oW+ntmBZqhO5djpFHqNmaOgdenB rMGCpfewd7+1Uj0r4pq8J03siCQ8mwC9dIrwDMExIduvfLO24FbxG4k/s68GbglRzMt/ 1dz+Ve4c4bdlGv1xN3HhjeG9y8dZY9auvXXR4= 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=KjBFvlBIk96JObiV6aNeKZtTxsp6mPPS5qWUbQbRchYMTksM0pyrjOttfZ9rOLY5DS Z8OuPLZbGIjYkZbotCxkKxX4qap5th867fe+iwYzGor+3IJ6itNzbXfA1durGUmezmwq +DijAtYcAKy5A/w/Ut6+z6/ng1GjZNH36Qa+I= MIME-Version: 1.0 Received: by 10.100.168.20 with SMTP id q20mr2095ane.244.1297397783722; Thu, 10 Feb 2011 20:16:23 -0800 (PST) Received: by 10.100.244.38 with HTTP; Thu, 10 Feb 2011 20:16:23 -0800 (PST) In-Reply-To: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> References: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> Date: Thu, 10 Feb 2011 23:16:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Warren Kumari Content-Type: multipart/alternative; boundary=0016e644021407fd4a049bf9f65f Cc: keyassure@ietf.org Subject: Re: [keyassure] Issue #3: Format of the record. 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, 11 Feb 2011 04:16:11 -0000 --0016e644021407fd4a049bf9f65f Content-Type: text/plain; charset=ISO-8859-1 Since there is no value in these records without DNSSEC and since this is a standards track effort, I see no reason not to use a new RR. Reuse of an existing RR will make the protocol more complex and harder to use. All infrastructure that will pass and handle DNSSEC will support new RRs. Attempting to use a prefix to the TXT record will not bypass DNSEXT. So it has to be at least one new RR. On Thu, Feb 10, 2011 at 9:28 PM, Warren Kumari wrote: > Hello all, > > We have "Issue #3: Format of the record" with the description: > > -------------------- > Format of the record: > a subtype of CERT (as was used in early drafts) > a new RRtype (used in draft-ietf-dane-protocol-00) > a TXT record with _prefix. > > Hopefully this is just a representation issue and can be worked on after > larger decisions have been made. > > ---------------------- > > I think that we have settled on using a new RRtype (as shown in > draft-ietf-dane-protocol-00), but I realize that we haven't explicitly had a > consensus call on this, so I am (with all reverence) donning the bells and > ribbons, stepping over the clay pipes, smacking myself smartly with the > stick and beginning the consensus call... > > W > > P.S: I have not consulted my co-chair on this, if I have completely > misjudged the groups views, the fault is all mine... > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e644021407fd4a049bf9f65f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since there is no value in these records without DNSSEC and since this is a= standards track effort, I see no reason not to use a new RR.

Reuse of an existing RR will make the protocol more complex and harde= r to use.

All infrastructure that will pass and handle DNSSEC wil= l support new RRs.

Attempting to use a prefix to t= he TXT record will not bypass DNSEXT.


So it has to be at least one new RR.


On Thu, Feb 10, 2011 at 9:28 PM, Warren Kumari <warren@kumari.net>= wrote:
Hello all,

We have "Issue #3: Format of the record" with the description:
--------------------
Format of the record:
a subtype of CERT (as was used in early drafts)
a new RRtype (used in draft-ietf-dane-protocol-00)
a TXT record with _prefix.

Hopefully this is just a representation issue and can be worked on after la= rger decisions have been made.

----------------------

I think that we have settled on using a new RRtype (as shown in draft-ietf-= dane-protocol-00), but I realize that we haven't explicitly had a conse= nsus call on this, so I am (with all reverence) donning the bells and ribbo= ns, stepping over the clay pipes, smacking myself smartly with the stick an= d beginning the consensus call...

W

P.S: I have not consulted my co-chair on this, if I have completely misjudg= ed the groups views, the fault is all mine...
_______________________________________________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e644021407fd4a049bf9f65f-- 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 868BE3A6A7D for ; Thu, 10 Feb 2011 20:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 yiew3wVdoJq2 for ; Thu, 10 Feb 2011 20:07:40 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CB4FC3A6A40 for ; Thu, 10 Feb 2011 20:07:40 -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 p1B47rMh070373 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 21:07:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D54B619.1070903@vpnc.org> Date: Thu, 10 Feb 2011 20: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: <4D54A5FD.8060809@vpnc.org> <1297395379.1903.29.camel@mattlaptop2.local> In-Reply-To: <1297395379.1903.29.camel@mattlaptop2.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one.... 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, 11 Feb 2011 04:07:41 -0000 On 2/10/11 7:36 PM, Matt McCutchen wrote: > On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote: >> Jakob and I would definitely like to hear more on this. If we need to >> say more about what a trust anchor is, we can do that. If people think >> we have over-restricted it in -04, that's good input as well. > > I haven't fully considered the issue, I just have two nits to pick: > >> The -04 >> text in question is: >> >> A TLS client conforming to this protocol MUST treat the certificate >> for association in a TLSA resource record for a domain name as a >> trust anchor for that domain name at the specific port number and >> transport name that was queried. This trust anchor MUST only be used >> for the domain name of the resource record. > > And port number and transport protocol name. Why should we put on that requirement? That is, if I get a trust anchor for _443._tcp.www.example.com, what is the security issue if I also want to use it for TLS on port 4443? There is no attack that an MITM can mount on 4443 that they cannot also mount on 443. >> The trust anchor MUST NOT >> be loaded for longer than the TTL on the TSLA record. > > I think you want the RRSIG validity. Requiring that clients limit the > trust anchor to the TTL would be false security. However, clients would > be allowed to do so. Good call. I'm not sure I agree, but it should definitely be discussed. --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 967D33A682D for ; Thu, 10 Feb 2011 19:36:13 -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 1t3Z8AHMdNIC for ; Thu, 10 Feb 2011 19:36:06 -0800 (PST) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id B9B203A69F8 for ; Thu, 10 Feb 2011 19:36:06 -0800 (PST) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 8DCC5280065 for ; Thu, 10 Feb 2011 19:36:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=VnDvfC+smhXc9wWLtUwblvblZqOgu+HJHXRmeXrKsw1 AvvBjBENVnMjWnWaBtA+agtXoNgDgg1hP40DsOW0ivk5Jo6OwYomqp3TuS4AbDlE No/Ru263FQVmX2SLIWkCN3Nu7JRJgxrifj9ppFv7VpANcAcQ7vxio4zCW+5Uuznw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=daK5ZV8WSwdknBpbVtYdL40lBTs=; b=IHNMVRM1uB eav1y8AJ+A8szjVx6yqzeMfUSfUX659WMwWFSefOgclAtDNYSKlkzJ+UIN3zRd9F SEUn5h+kU3nFkKBTSfGmiWhV0Y4KPkiiUgksW4I7G/5mBPjD3A393bfDgLkNAvOX HmVXeXsvGthnFYLMbet/CwTwXLrnProto= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id 5849B280063 for ; Thu, 10 Feb 2011 19:36:20 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <4D54A5FD.8060809@vpnc.org> References: <4D54A5FD.8060809@vpnc.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 22:36:19 -0500 Message-ID: <1297395379.1903.29.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one.... 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, 11 Feb 2011 03:36:13 -0000 On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote: > Jakob and I would definitely like to hear more on this. If we need to=20 > say more about what a trust anchor is, we can do that. If people think=20 > we have over-restricted it in -04, that's good input as well. I haven't fully considered the issue, I just have two nits to pick: > The -04=20 > text in question is: >=20 > A TLS client conforming to this protocol MUST treat the certificate > for association in a TLSA resource record for a domain name as a > trust anchor for that domain name at the specific port number and > transport name that was queried. This trust anchor MUST only be used > for the domain name of the resource record. And port number and transport protocol name. > The trust anchor MUST NOT > be loaded for longer than the TTL on the TSLA record.=EF=BB=BF I think you want the RRSIG validity. Requiring that clients limit the trust anchor to the TTL would be false security. However, clients would be allowed to do so. --=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 EAD423A69AD for ; Thu, 10 Feb 2011 19:29:45 -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 0XP+2zCj2065 for ; Thu, 10 Feb 2011 19:29:40 -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 395A93A682D for ; Thu, 10 Feb 2011 19:29:40 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 1DD9063406C for ; Thu, 10 Feb 2011 19:29:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=n/wNqs5W3VV+msGol9sID5+8VqphxXt7MOeOZ2T/dSz 4KzEK7W7eD0vDI7E7y4Sy71fKj3v5bMCb42Ycap8R7K/Eu3b3okE89/H2yo1ZQGR Z+hOxLkAN5s08nDImU6lop63GRp4B3xzzM8NrlXzFZeEilopEu0Y4/H/on3xbw58 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=XC3GylRdXUMXft9OUOYPEu1GVcw=; b=gszehZnQie zcNniLjEECyx/JIfcoRBIgLtLglr+VGd1My1Zcr6Oa5VJLmKL5ftme7Xn3v5zjmh V5oGPxF3MA5BFNJ/VVPKwuVssGS54l2+j25Rhzpl/HWkWqQbh5BVEuXnUmTqpsoQ LEcnIy1N/JBKxiA3JtAAOLvRNQoXxTe3k= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id DD494634064 for ; Thu, 10 Feb 2011 19:29:53 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> References: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 22:29:52 -0500 Message-ID: <1297394992.1903.24.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #3: Format of the record. 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, 11 Feb 2011 03:29:46 -0000 On Thu, 2011-02-10 at 21:28 -0500, Warren Kumari wrote: > We have "Issue #3: Format of the record" with the description: > > -------------------- > Format of the record: > a subtype of CERT (as was used in early drafts) > a new RRtype (used in draft-ietf-dane-protocol-00) > a TXT record with _prefix. > > Hopefully this is just a representation issue and can be worked on after larger decisions have been made. > > ---------------------- > > I think that we have settled on using a new RRtype (as shown in > draft-ietf-dane-protocol-00), but I realize that we haven't explicitly > had a consensus call on this, so I am (with all reverence) donning the > bells and ribbons, stepping over the clay pipes, smacking myself > smartly with the stick and beginning the consensus call... I prefer the new RRtype. It would be OK to use a new CERT subtype, but I don't find there to be much conceptual economy in doing so. RFC 4398 section 7 suggests that some clients might use DNSSEC-protected CERT records without traditional validation, but there is nothing precise; in contrast, TLSA makes a precise assertion. Furthermore, TLSA clients aren't interested in the other CERT subtypes, so it is cleaner not to fetch them and have to sort through them. TXT at a prefix would only make sense if the RR content is text. I prefer binary for the slightly better performance, unless interop issues with new RRtypes are shown to still be real. A key-value format like DKIM or Kaminsky's KEY1 is extensible via new keys, but we don't care about that assuming we are going to bite off TLSA and deal separately with the myriad other hints we might want to give clients. -- 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 DF73F3A69DB for ; Thu, 10 Feb 2011 18:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.641 X-Spam-Level: X-Spam-Status: No, score=-100.641 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 ZmgtpEdAhKHA for ; Thu, 10 Feb 2011 18:58:57 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 35C123A682D for ; Thu, 10 Feb 2011 18:58: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 p1B2x9ZU067302 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 19:59:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D54A5FD.8060809@vpnc.org> Date: Thu, 10 Feb 2011 18:59: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: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one.... 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, 11 Feb 2011 02:58:58 -0000 On 2/10/11 6:43 PM, Warren Kumari wrote: > Hello again. > > It appears to me that the current wording on trust anchors neatly resolves a bunch of issues namely: > #2: Relying parties policies (http://trac.tools.ietf.org/wg/dane/trac/ticket/2) > #9: Self-Signed Certificates (http://trac.tools.ietf.org/wg/dane/trac/ticket/9) > #13: Hostnames in Certificates (http://trac.tools.ietf.org/wg/dane/trac/ticket/13) > #18: Certificate Properties and Relationship with PKIX (http://trac.tools.ietf.org/wg/dane/trac/ticket/18) > > I would like to hear your views on this -- if you have substantive comments on any of the issues *please* start a new thread so that we can keep the discussions separate and organized. Jakob and I would definitely like to hear more on this. If we need to say more about what a trust anchor is, we can do that. If people think we have over-restricted it in -04, that's good input as well. The -04 text in question is: A TLS client conforming to this protocol MUST treat the certificate for association in a TLSA resource record for a domain name as a trust anchor for that domain name at the specific port number and transport name that was queried. This trust anchor MUST only be used for the domain name of the resource record. The trust anchor MUST NOT be loaded for longer than the TTL on the TSLA record. --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 1504D3A682B for ; Thu, 10 Feb 2011 18:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yndohZR4dSgh for ; Thu, 10 Feb 2011 18:43:05 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 160F93A67F4 for ; Thu, 10 Feb 2011 18:43:04 -0800 (PST) Received: from [10.67.11.82] (64.1.210.2.ptr.us.xo.net [64.1.210.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 028D91B40FA9; Thu, 10 Feb 2011 21:43:17 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Feb 2011 21:43:16 -0500 Message-Id: To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one.... 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, 11 Feb 2011 02:43:06 -0000 Hello again. It appears to me that the current wording on trust anchors neatly = resolves a bunch of issues namely: #2: Relying parties policies = (http://trac.tools.ietf.org/wg/dane/trac/ticket/2) #9: Self-Signed Certificates = (http://trac.tools.ietf.org/wg/dane/trac/ticket/9) #13: Hostnames in Certificates = (http://trac.tools.ietf.org/wg/dane/trac/ticket/13)=20 #18: Certificate Properties and Relationship with PKIX = (http://trac.tools.ietf.org/wg/dane/trac/ticket/18) I would like to hear your views on this -- if you have substantive = comments on any of the issues *please* start a new thread so that we can = keep the discussions separate and organized. W (Not donning the shirt and baldricks as this is not an official = consensus call or opening of an issue).= 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 75AAA3A67C1 for ; Thu, 10 Feb 2011 18:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jiw8lMrIx6PT for ; Thu, 10 Feb 2011 18:28:19 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id B74213A676A for ; Thu, 10 Feb 2011 18:28:19 -0800 (PST) Received: from [10.67.11.82] (64.1.210.2.ptr.us.xo.net [64.1.210.2]) by vimes.kumari.net (Postfix) with ESMTPSA id C15651B40FA9; Thu, 10 Feb 2011 21:28:32 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Feb 2011 21:28:31 -0500 Message-Id: <93E6A078-130F-4CE9-A50F-9A48EEAE3867@kumari.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [keyassure] Issue #3: Format of the record. 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, 11 Feb 2011 02:28:20 -0000 Hello all, We have "Issue #3: Format of the record" with the description: -------------------- Format of the record: a subtype of CERT (as was used in early drafts) a new RRtype (used in draft-ietf-dane-protocol-00) a TXT record with _prefix. Hopefully this is just a representation issue and can be worked on after = larger decisions have been made. ---------------------- I think that we have settled on using a new RRtype (as shown in = draft-ietf-dane-protocol-00), but I realize that we haven't explicitly = had a consensus call on this, so I am (with all reverence) donning the = bells and ribbons, stepping over the clay pipes, smacking myself smartly = with the stick and beginning the consensus call... W P.S: I have not consulted my co-chair on this, if I have completely = misjudged the groups views, the fault is all mine...= 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 80C1C3A67C1 for ; Thu, 10 Feb 2011 18:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, NO_RELAYS=-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 WfgmDOUp-3l8 for ; Thu, 10 Feb 2011 18:15:26 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D1C3D3A676A for ; Thu, 10 Feb 2011 18:15:26 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PniXs-0008HG-4r; Thu, 10 Feb 2011 18:15:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Fri, 11 Feb 2011 02:15:40 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/17#comment:1 Message-ID: <065.60f02fba72ffd5e7d6c6972faa74f4e6@tools.ietf.org> References: <056.534f3ec35086e995318eaaebe4d70a8d@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <056.534f3ec35086e995318eaaebe4d70a8d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Thu, 10 Feb 2011 18:44:39 -0800 Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] protocol #17 (closed): Should draft-ietf-dane-protocol support TLS only or be more ambitious? X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 02:15:27 -0000 #17: Should draft-ietf-dane-protocol support TLS only or be more ambitious? Changes (by warren@…): * status: new => closed * resolution: => fixed Comment: Consensus: The initial document (draft-ietf-dane-protocol) will support only TLS / DTLS. -- --------------------------------+------------------------------------------- Reporter: warren@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: protocol | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: dane 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 43A5F3A69D3 for ; Thu, 10 Feb 2011 18:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk1+kTCxpziE for ; Thu, 10 Feb 2011 18:14:34 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 3D7393A69BA for ; Thu, 10 Feb 2011 18:14:34 -0800 (PST) Received: from [10.67.11.82] (64.1.210.2.ptr.us.xo.net [64.1.210.2]) by vimes.kumari.net (Postfix) with ESMTPSA id 99D291B40B76 for ; Thu, 10 Feb 2011 21:14:47 -0500 (EST) Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Apple Message framework v1081) From: Warren Kumari In-Reply-To: Date: Thu, 10 Feb 2011 21:14:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <735BEA77-87A6-46CF-86B8-077339D0EBAE@kumari.net> References: <4D42EF85.30004@nic.cz> <87bp31gcvr.fsf@latte.josefsson.org> <4D43079A.20005@vpnc.org> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) 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, 11 Feb 2011 02:14:35 -0000 While going through the issue tracker I realized that we hadn't marked = this issue as closed. There have been no followups, and so I am officially waving the dead = chicken and pulling the big lever marked "Consensus Achieved" -- I know = y'all think I just make this stuff up, but I believe in keeping the old = traditions alive.... The consensus is, as Ondrej stated:=20 The initial document (draft-ietf-dane-protocol) will support only TLS / = DTLS. W On Jan 28, 2011, at 1:26 PM, Warren Kumari wrote: >=20 > On Jan 28, 2011, at 1:14 PM, Paul Hoffman wrote: >=20 >> On 1/28/11 9:24 AM, Simon Josefsson wrote: >>> Ond=F8ej Sur=FD writes: >>>=20 >>>> Hi all, >>>>=20 >>>> upon discussion with my fellow co-chair I hereby call for consensus = on >>>> issue #17. >>>>=20 >>>> The consensus would be that the initial document >>>> (draft-ietf-dane-protocol) would support only TLS. >>>=20 >>> Does this exclude DTLS? >=20 > No... Good catch though! >=20 > 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. >=20 > I have a procmail rule that I pass outgoing mail through that does = 'sed/exmaple.com/example.com' on outgoing mail, perhaps I should add = 's/TLS/TLS\/DTLS/' :-) >=20 >>> DTLS is not the same protocol as TLS. >>=20 >> 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. >=20 > Nope, I believe it is perfectly clear in the doc (clear enough that I = automatically see the implied DTLS) >=20 > W >> _______________________________________________ >> keyassure mailing list >> keyassure@ietf.org >> https://www.ietf.org/mailman/listinfo/keyassure >>=20 >=20 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure >=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 83EB53A6823 for ; Thu, 10 Feb 2011 16:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 mDVjFKBcOrgi for ; Thu, 10 Feb 2011 16:48:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CA8F83A6B18 for ; Thu, 10 Feb 2011 16:48: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 p1B0mgDL062329 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 17:48:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D54876A.4090302@vpnc.org> Date: Thu, 10 Feb 2011 16:48:42 -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: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> In-Reply-To: <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] WebID at W3C and keyassure 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, 11 Feb 2011 00:48:30 -0000 On 2/10/11 2:41 PM, Henry Story wrote: > Keyassure will probably use the DNS-ID typed subject alternative name > (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes > to identify the server as suggested is good practice by > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3 In > your earlier message, you said: > (I have not seen a draft spec yet, and am going from the group > description). Please do read the draft. What you say here, which predicates the rest of your message about similarities with the WebID work, is not at all correct. This is not to say that what WebID is doing can't work with the DANE effort, just that we are doing completely different things. DANE is about getting a temporary trust anchor for a particular port/transport/domainname triple for a server, whereas WebID is about identifying clients through an HTTPS lookup. There has been discussion of using DANE to get a temporary trust anchor for S/MIME clients, and that might be extended to doing so for TLS clients, but it would be done using the DNS 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 F07FF3A6B16 for ; Thu, 10 Feb 2011 16:20:13 -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 saqgsclDPI3z for ; Thu, 10 Feb 2011 16:20:13 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 1109C3A6AFA for ; Thu, 10 Feb 2011 16:20:13 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 6E96020806C for ; Thu, 10 Feb 2011 16:20:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=V+Eo/ffJ/CXaT6W5C+59u9v9CknfYZNJvPhKnRyJjWi 76YV+8V3l4BDnT7eLD2TfSJmW6VTKgL15WSIgKDLjm5PkAazzmijXkfKXYWVWbp5 jSyl+44uqpi/+GxgOIrjCCd0rDjoEyFOCM0ng1QlZC7bTDjqCYIiIODy+aEzTs+s = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=QfDLdokF3Z33BdIlV2gxI9AZQy8=; b=b9vP2iFTRG DPbSkRbKyo70lRlntfFz7lyy7kREe//SybEXOs5n3EgJqoB+5fAYGZhAyyGOVafD k8ScmJ+XjJralF/DvjL32nUYMsu2YGz+13q2G/yvNqp5AxSD5fpfEGKiNAgKOnWF U2r7qQEoI2VoXdOpLMAsfa++xVLpeteBE= Received: from [128.8.208.170] (128-8-208-170.wireless.umd.edu [128.8.208.170]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 2B86620806A for ; Thu, 10 Feb 2011 16:20:26 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <20110210233124.GA22821@LK-Perkele-VI.localdomain> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@shinkuro.com> <20110209214440.GG56498@shinkuro.com> <1297376455.1820.80.camel@mattlaptop2.local> <20110210233124.GA22821@LK-Perkele-VI.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 19:20:25 -0500 Message-ID: <1297383625.1820.91.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 11 Feb 2011 00:20:14 -0000 On Fri, 2011-02-11 at 01:31 +0200, Ilari Liusvaara wrote: > On Thu, Feb 10, 2011 at 05:20:55PM -0500, Matt McCutchen wrote: > > > > I don't know where you got that. My goal with "null TLSA" is to prevent > > public CAs from fabricating a TLS service that I do not offer. E.g., I > > do not operate a site at https://secure.mattmccutchen.net, but if a > > public CA spoofed it into existence and invited users to visit it, they > > would be inclined to assume that I endorse the content. > > That attack doesn't work too well: Clients will try to resolve A/AAAA > records for secure.mattmccutchen.net, ending up with authenticated > NXDOMAIN and then complain about unknown host. I forgot about that, but see my previous message on the subject: http://www.ietf.org/mail-archive/web/keyassure/current/msg01679.html > Now, this attack could actually work between ports (but would require > MITMing on mass scale). MITMing is what all of this is about... -- 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 8F6AE3A6B04 for ; Thu, 10 Feb 2011 15:31:56 -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 LwmR1v6JDxdB for ; Thu, 10 Feb 2011 15:31:55 -0800 (PST) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by core3.amsl.com (Postfix) with ESMTP id 22C1D3A6AF7 for ; Thu, 10 Feb 2011 15:31:55 -0800 (PST) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh03-2.mail.saunalahti.fi (Postfix) with SMTP id C577BEBE91; Fri, 11 Feb 2011 01:32:06 +0200 (EET) Received: from emh01.mail.saunalahti.fi ([62.142.5.107]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A02302BED46; Fri, 11 Feb 2011 01:32:06 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 812F84033; Fri, 11 Feb 2011 01:32:04 +0200 (EET) Date: Fri, 11 Feb 2011 01:31:24 +0200 From: Ilari Liusvaara To: Matt McCutchen Message-ID: <20110210233124.GA22821@LK-Perkele-VI.localdomain> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@shinkuro.com> <20110209214440.GG56498@shinkuro.com> <1297376455.1820.80.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1297376455.1820.80.camel@mattlaptop2.local> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 23:31:56 -0000 On Thu, Feb 10, 2011 at 05:20:55PM -0500, Matt McCutchen wrote: > > I don't know where you got that. My goal with "null TLSA" is to prevent > public CAs from fabricating a TLS service that I do not offer. E.g., I > do not operate a site at https://secure.mattmccutchen.net, but if a > public CA spoofed it into existence and invited users to visit it, they > would be inclined to assume that I endorse the content. That attack doesn't work too well: Clients will try to resolve A/AAAA records for secure.mattmccutchen.net, ending up with authenticated NXDOMAIN and then complain about unknown host. Now, this attack could actually work between ports (but would require MITMing on mass scale). -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 DCA773A67D2 for ; Thu, 10 Feb 2011 14:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.189 X-Spam-Level: X-Spam-Status: No, score=-100.189 tagged_above=-999 required=5 tests=[AWL=-0.743, 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 12YgaNa+uVlb for ; Thu, 10 Feb 2011 14:49:39 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 334253A67CF for ; Thu, 10 Feb 2011 14:49:39 -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 p1AMnpti057981 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 15:49:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D546B8F.2020600@vpnc.org> Date: Thu, 10 Feb 2011 14:49: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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [keyassure] New -04 issued 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, 10 Feb 2011 22:49:40 -0000 Greetings again. Jakob and I updated the draft to reflect the consensus on issue #1 and to clarify the trust anchor issue that was added in -03. The previous message announces the draft; the diffs are at . We look forward to more open issues being discussed and resolved before the Prague meeting! --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 1C8793A6ADE; Thu, 10 Feb 2011 14:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D7tegNLb+Mw; Thu, 10 Feb 2011 14:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0F33A6AD9; Thu, 10 Feb 2011 14: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.12 Message-ID: <20110210224502.31025.53023.idtracker@localhost> Date: Thu, 10 Feb 2011 14:45:02 -0800 Cc: keyassure@ietf.org Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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: Thu, 10 Feb 2011 22:45: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-04.txt Pages : 11 Date : 2011-02-10 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-10143327.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 7FE7A3A6ADE for ; Thu, 10 Feb 2011 14:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 Dnf1-Pr6BIzM for ; Thu, 10 Feb 2011 14:41:26 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 971963A6AAC for ; Thu, 10 Feb 2011 14:41:25 -0800 (PST) Received: by bwz12 with SMTP id 12so2863078bwz.31 for ; Thu, 10 Feb 2011 14:41:37 -0800 (PST) Received: by 10.204.62.132 with SMTP id x4mr4202646bkh.30.1297377697237; Thu, 10 Feb 2011 14:41:37 -0800 (PST) Received: from bblfish.home (ALagny-751-1-9-11.w83-112.abo.wanadoo.fr [83.112.80.11]) by mx.google.com with ESMTPS id 12sm44154bki.7.2011.02.10.14.41.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Feb 2011 14:41:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201102102017.p1AKH7iR028493@new.toad.com> Date: Thu, 10 Feb 2011 23:41:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <19409B47-4FB1-4705-B670-5D2570EBE76B@bblfish.net> References: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> <201102102017.p1AKH7iR028493@new.toad.com> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [keyassure] WebID at W3C and keyassure 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, 10 Feb 2011 22:41:27 -0000 John Gilmore rightly pointed out that I was not clear in my mail to the = list, so I answered his questions in more detail below. On 10 Feb 2011, at 21:17, John Gilmore wrote: >> Where keyassure is attempting to identify a server using uniquely >> identifying information in the DNS, WebID is identifying an end >> user (human, robot or agency), via a profile document containing >> cryptographically uniquely identifying information placed in the >> web. >=20 > I understand this. >=20 >> Keyassure coul probably use the dns typed subject >> alternative name to identify the verify X509 certifactes, WebID >> uses the SAN (and IAN) with https IDs to identify the agent. We >> are both using canonical referential lookups to get the meaning >> of a name (Domain Name with keyassure, HTTP+TLS with WebID) which >> we can then use to prove referential integrity (authentication). >=20 > This is so much gobbledygook to me. Can you explain in English? Ok, sorry I did type that a bit too quickly yesterday, and it would have = done with a bit more editing before pressing the send button. Let me = just rewrite this with spelling mistakes fixed and in less terse style. Also here is a quick UML Sequence diagram for how this works http://www.w3.org/wiki/Foaf%2Bssl#How_does_it_work.3F So let me try again: Keyassure will probably use the DNS-ID typed subject alternative name = (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes to = identify the server as suggested is good practice by=20 = http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section= -2.3 WebID uses the SAN (and IAN) with https IDs to identify the agent of a = *client* certificate. We are both using canonical referential lookups to get the meaning of a = name. In the case of keyassure the name is a domain name. The canonical = way to look up the meaning of a domain name is to look in the DNS. The = canoncial way to look up the meaning of an ftp:// URL (think of a URL as = a name) is to use the ftp protocol. So the canoncial way to look up an = http or https URL is to use HTTP+TLS, which is what WebID does. So if I understand correctly, in the future a browser will be able to = verify from DNSSEC that a self signed server certificate is indeed able = to authenticate the server. >=20 > I see zero point in working on this WebID thing if the actual goal is > to actually identify me on the web. You should of course have a choice to authenticate or be anonymous. Web = Browsers should show you with what identity you have authenticated and = allow you to logout in one click. If we can get together on issues like = this to put some pressure on browser vendors, I'd be happy to help. I = know of a few security holes that really need some external pressure. > I don't want the vast majority of web sites to be able to identify me = on the web -- and I think this goal is shared by a large, possibly = majority, fraction of web users. Yes, you should be anonymous by default.=20 > To the extent that "WebID" becomes standard, if it makes it easier for > websites to demand that people "identify themselves" before > "publishing" information (publishing =3D distributing "to the public", > not to individual identified people), then it will be destructive of > the kind of Web that I want to continue to exist. I want ordinary > un-identified people and browsers to continue to have broad access to > everything published on the web. I refuse to use sites like the New > York Times that demand that I login "to a free account" merely so they > can track what I'm reading. It is going to be very easy to create a WebID: one click of a button. = And you can have as many as you want, on as many sites as you want. It = should be easy to create throw away webids too. There is no need to go = to any government agency, no need to prove anything. WebIDs are built to = enable a web of trust. But you don't need to participate in a web of = trust, and if you do, you don't need to reveal it to anyone else than = those you trust. > To the extent that "WebID" makes it harder for people to use a > different pseudonym with each current website that "demands" > identifying information, it will be destructive. WebID allows you to authenticate on sites in a very decentralised way. = You can have any number of IDs and place them wherever you want. So it = is not restrictive.=20 > To the extent that "WebID" makes it impossible for sites like > bugmenot.com or mailinator.com to exist and function well, it will be > destructive. They could provide temporal WebIDs as an additional service, without = problem. >=20 > To the extent that "WebID" works like "OpenID", it will never catch on > anyway. The extent to which it is different to OpenID is detailed here = http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_wa= nt_distributed_identity.3F =46rom the user perspective it is a lot easier to use. > I use OpenID with exactly one site, because they demand it and > offer no alternative. And it's incredibly cumbersome, harder than = just > logging in like other sites require. Yes, WebID is point and click. No typing. See the short video I put = together here http://bblfish.net/ >=20 > Now if somebody at W3C actually automated bugmenot.com in a new > protocol, so that ordinary people could just set their web browser to > pretend to be randomly generated other people on sites that demand > their identities, I'd be much more interested in it. =20 It would be very easy to do. You can get yourself a WebID at=20 http://foaf.me/ in a few clicks. The UI should definitively be improved.=20= > But after > a brief look at: >=20 > http://www.w3.org/2005/Incubator/webid/spec/ >=20 > that doesn't seem at all to be what's happening. Instead it's more > totalitarian bullshit wrapped in X.509 encoding. It's certainly not. (Perhaps it's a good thing that it looks like that, = ...) Anyway, what in particular makes you think that in the wording or = presentation? We are working on the spec.=20 Btw. has this group got a draft spec I could look at? Henry Story >=20 > John Gilmore Social Web Architect http://bblfish.net/ 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 7A9EA3A6838 for ; Thu, 10 Feb 2011 14:37:13 -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 5F3NRjMFXVnq for ; Thu, 10 Feb 2011 14:37:09 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 987D23A67F6 for ; Thu, 10 Feb 2011 14:37:09 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id CFF2057807B for ; Thu, 10 Feb 2011 14:37:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=MSFZdj/jPkcfJz2R6EJFFBjZOv/UreiBg9C164gmae+ Y4bczy4GuMs1eh9TBCohhB92+URV2rF6+jThmXwbmqHhmt+V3cVoCtJg+sXLMomm kP+vEJ4HJgioMGp3h+dufZo4d9StKmJcVGmpwhRu79RF1i561Xg8uQcawpxJWn1A = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=0oQ1L6R8pL/cHDuW2+lYRuEcbpo=; b=ixUCgoSWsU OpgdN1sq3v/1Bf9eVXBDfZfYVbGGgv05x9L+iOzOV7hrUd9C0W4wtOegzz4rp451 0MilF92Sf8cAGeN+9NQrdxHlnu7cmabVkeoGEmh9HirUAkEKSuSkUTvlmO8VdVKw lQ+Y7hbRA+pKPQoSFjePEgPmw3BGFujHw= Received: from [129.2.142.129] (unknown [129.2.142.129]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 984E0578077 for ; Thu, 10 Feb 2011 14:37:22 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110210174507.GA19969@LK-Perkele-VI.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 17:37:20 -0500 Message-ID: <1297377440.1820.89.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 22:37:13 -0000 On Thu, 2011-02-10 at 14:54 -0500, Phillip Hallam-Baker wrote: > > > On Thu, Feb 10, 2011 at 12:45 PM, Ilari Liusvaara > wrote: > On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-Baker > wrote: > > > > I believe I can support the following criteria with no > compromise to any of > > them. > > > > > Based on this list, it looks like scheme that satisifes all of > these would > be godawfully complicated (interoperability problems) and > require loads > of code to implement (bugs, or in worst case, security bugs) > > > Let us judge the complexity of the actual proposals rather than the > presumed complexity of the requirements. > > > SAML is based on a design that supports the whole of PKIX in less than > 20 pages. > > > I have pretty good metrics for the relative complexity of my scheme vs > others based on the number of states and transitions. I will believe it when I see it. And if it means being exposed to Etisalat for an extra six months while we haggle over the design, I'm not interested. (Of course, the WG chairs make the decision, not me.) -- 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 6C7F63A6A98 for ; Thu, 10 Feb 2011 14:20:51 -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 O-Oo6NfH5v6e for ; Thu, 10 Feb 2011 14:20:50 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 5D74D3A6A9D for ; Thu, 10 Feb 2011 14:20:50 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id A53D0598077 for ; Thu, 10 Feb 2011 14:21:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Q4AQCOxmnhCFZpGLEx2nP4UvnbKSBwgdecDy9k5WicP bfcn/78ootNNbs3BUsqggx4SXec/7NJ/NOrhdGz4rUBSULYBGl86gZ5EtS5n8cE5 HNw/IJbMGZt9wmcHSX1MQz589PsAO7fBzAWeinTRwEETtJ/lfpegpRX7H1A+PzuE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=cVoUHmn6bp29KrRxJdW8ThMMqBo=; b=MTB3AWLK9K kJx04Qtp+7KrtoJyQ7Gc5RBYXR+HuDnKLSkN7gjDbHK8qnx5UzkhuizZVyKCu1Sv gUc/Srv+kDyBPBbWcmvt12gGogqzisjJgOYEOZOzZyMJPALBxEEpiVYu9K2YYfoU c12UQby1/pc3pmr9z9exvRZImWD87IvZg= Received: from [129.2.142.129] (unknown [129.2.142.129]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id 65C1259806B for ; Thu, 10 Feb 2011 14:21:03 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@shinkuro.com> <20110209214440.GG56498@shinkuro.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 17:20:55 -0500 Message-ID: <1297376455.1820.80.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 22:20:51 -0000 On Wed, 2011-02-09 at 22:11 -0500, Paul Wouters wrote: > On Wed, 9 Feb 2011, Andrew Sullivan wrote: > > > Ah, I get what you're arguing. Hrm. > > > > So what you want, I think, is a three-value state: > > > > - zone positively has record > > This amounts to an affirmation by the zone admin that it > > supports the feature. > > Yes. > > > - zone asserts it does not have record > > This is an indeterminate state with respect to the new > > feature, because the the signed absence of a record is not a > > meaningful assertion. > > Well, the absense tells you no DANE based TLS is there. There could still be > TLS backed by PKIX. Correct. > > - zone has record asserting no support > > This is the zone admin asserting that it does _not_ support > > the feature. > > This would be the "null TLSA" record? I find that record unneccessary. The record asserts that there is no TLS service at the name, in particular not a PKIX-authenticated service. > We > also don't have a "null PKIX" record. Is there a desire to create one > for those as well? Not sure what you mean. PKIX-based TLS authentication by its nature does not support exclusion. > Frankly, adding infrastructure to better support insecure protocols makes > no sense to me. Especailly because we are hard on our way on killing > port 80, and the last group of clients on port 80 will be those not > supporting any new RRTYPE anyway. I don't know where you got that. My goal with "null TLSA" is to prevent public CAs from fabricating a TLS service that I do not offer. E.g., I do not operate a site at https://secure.mattmccutchen.net, but if a public CA spoofed it into existence and invited users to visit it, they would be inclined to assume that I endorse the content. (And browsers would be inclined to let it set cookies for .mattmccutchen.net and confuse my web apps. This issue deserves a proper solution, but for now I am avoiding it by not handing out subdomains.) Null TLSA might help some clients find a plaintext service more quickly, but that is not the point. -- 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 8ED243A69F6 for ; Thu, 10 Feb 2011 13:53:42 -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 Ak32wZaF-agn for ; Thu, 10 Feb 2011 13:53:41 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 744CE3A6A14 for ; Thu, 10 Feb 2011 13:53:41 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id A080734806C for ; Thu, 10 Feb 2011 13:53:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=gmYqrnXeGVI1yL6Cr8hAD3JZ+Pl2OQGHJ29OxiMcuxf bzws2sACeFYvmxTrXt90k8xOTFJWxxTbV5dwTpkAvaJS7qw5Hg5SxtDIciENWkT8 1Y/6D6mgn2/BwztlybCPLBXzm3yDDn/LrjNCXmRD47llfPQfXmxKMLQKRgOAJ1OI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=rQo4aBuYDTb1QAIOlnHjNT/PDxg=; b=nka+3PV0Ac dvbIkQ6qJnGI2azoimaRI3yAkYtB9M0SUW3rZA0fDvHSbjWqRJKNpoMklXGtg3mA oUaFzUzprW1BHUpywdTpe9BzL98n99lva2TDg7DMJGjaVrtEX64fTiHQM2/K2Cn4 HpbN5whI6HvIlgc7xbW0j9nn9m7FLt1Vk= Received: from [129.2.142.129] (unknown [129.2.142.129]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 61D5634806B for ; Thu, 10 Feb 2011 13:53:54 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Thu, 10 Feb 2011 16:53:52 -0500 Message-ID: <1297374832.1820.59.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 21:53:42 -0000 On Wed, 2011-02-09 at 17:39 +0100, Martin Rex wrote: > I should have been more explicit on this: > > There is a client with a desire to communicate, and a preference/intend > for TLS-protection. But with most protocols, there is a fallback > strategy to communicate without TLS. It could be that the initial > reference does not even imply TLS, and its only the client who is > looking for clues in DNS whether TLS is available. > > So I'm still wondering: what message should an empty list convey? Just what I said: there is no TLS service associated with the host/transport/port. > A pre-DANE client might fallback to non-TLS if TLS doesn't work, > or it might not try TLS at all. > > What should a DANE-aware client, that is wildly determined to communicate > do when finding an empty TLSA record? Go straight for the unprotected > communication (which is what such a record would imply), or bother > the user with an annoying popup before doing the fallback on unprotected > communication. > > I doubt that "not communicating at all" is a workable solution for such > clients, because it is likely to be perceived as a usability problem > by a non-marginal fraction of the user base. > > > Most "Web users" think that "the Web" == "the Internet" and are so completely > accustomed to trust everyone with everything over completely insecure > communication channels (commonly described with "http://") > that it is going to be hard to turn back time on this. Any fallback that clients may perform is a separate issue, and we will need separate mechanisms to control it. Even considering my proposal in isolation, I don't see how asserting the absence of a TLS service leaves clients with fallback worse off. The only difference it makes is that they fall back in cases in which they would otherwise make a TLS connection to an impostor. At least they know they are not getting a secure connection if anyone cares to check. > > > DANE-unaware clients will continue trying to use TLS. > > > What is your rationale for making DANE-aware clients exhibit > > > a different behaviour and entirely stop trying to use TLS? > > > > I assert that I do not offer the TLS service, so there is no point in > > DANE clients trying to connect to it. In particular, I do not want them > > to connect to some fake service with a certificate from a public CA. > > There is nothing I can do about the DANE-unaware clients. > > While there are a few clients of the type "TLS or refuse to connect", > the vast majority of clients will happily connect without TLS instead, > and end users have been conditioned over more than a decade that > fallbacks are OK. That may be true at a high level, considering how users react to various situations. At the level of individual transactions, all of the major HTTP clients follow "TLS or refuse to connect" for https URLs, and all of the major mail clients have a checkbox to enable this behavior. This is the level I am focused on securing now. -- 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 679F23A69B9 for ; Thu, 10 Feb 2011 11:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 l9KCAfbbyR6c for ; Thu, 10 Feb 2011 11:54:31 -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 634B33A67B3 for ; Thu, 10 Feb 2011 11:54:31 -0800 (PST) Received: by gxk27 with SMTP id 27so842656gxk.31 for ; Thu, 10 Feb 2011 11:54:43 -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=eKq1454TcgX97fIYxd2c6r3gizH90VUPHYEbuMu42kw=; b=qvE72OYaXUeARKbsU6YXMZVa8H1IHa3QJvzXW+vVvIGBUFh5+ZJflf5pyHmtL6lbxn EZcu24A+QyXDMUWXK2WyXcoYnEEBNhvuolJ+u8fboevkWtNk4miIFehBoySqn73nOQ9k 0gRQqjoU6dkYPliB/eIECxTYbcN+mlhsmUXMI= 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=GoTVwwpjsUN0+2ov+s603Gim967r/DO1JT4fuUVyhhrinhaq65HDJb2VWKkDR4GMAT gaI35samjZATRIIBAra8+NTlutszNZBl3cRPcZDv/0SJ973/GrmOiIVnEeQQnhM/tpk1 h3QqjGzvY5s64UV6q0YXytTuqE5gjcaZmStn4= MIME-Version: 1.0 Received: by 10.100.168.17 with SMTP id q17mr12358822ane.40.1297367682391; Thu, 10 Feb 2011 11:54:42 -0800 (PST) Received: by 10.100.244.38 with HTTP; Thu, 10 Feb 2011 11:54:42 -0800 (PST) In-Reply-To: <20110210174507.GA19969@LK-Perkele-VI.localdomain> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110210174507.GA19969@LK-Perkele-VI.localdomain> Date: Thu, 10 Feb 2011 14:54:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=0016e6441dceda1ed7049bf2f386 Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 19:54:32 -0000 --0016e6441dceda1ed7049bf2f386 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 10, 2011 at 12:45 PM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-Baker wrote: > > > > I believe I can support the following criteria with no compromise to any > of > > them. > > > > Based on this list, it looks like scheme that satisifes all of these would > be godawfully complicated (interoperability problems) and require loads > of code to implement (bugs, or in worst case, security bugs) > Let us judge the complexity of the actual proposals rather than the presumed complexity of the requirements. SAML is based on a design that supports the whole of PKIX in less than 20 pages. I have pretty good metrics for the relative complexity of my scheme vs others based on the number of states and transitions. -- Website: http://hallambaker.com/ --0016e6441dceda1ed7049bf2f386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 10, 2011 at 12:45 PM, I= lari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-= Baker wrote:
>
> I believe I can support the following criteria with no compromise to a= ny of
> them.

<snip long list>

Based on this list, it looks like scheme that satisifes all of these would<= br> be godawfully complicated (interoperability problems) and require loads
of code to implement (bugs, or in worst case, security bugs)

Let us judge the complexity of the actual proposals r= ather than the presumed complexity of the requirements.

SAML is based on a design that supports the whole of PKIX in les= s than 20 pages.

I have pretty good metrics for th= e relative complexity of my scheme vs others based on the number of states = and transitions.
=A0
--
Website: htt= p://hallambaker.com/

--0016e6441dceda1ed7049bf2f386-- 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 4AB7B3A6A5A for ; Thu, 10 Feb 2011 09:45:37 -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 YqbAbcNH+5kW for ; Thu, 10 Feb 2011 09:45:36 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by core3.amsl.com (Postfix) with ESMTP id 62BF53A6A58 for ; Thu, 10 Feb 2011 09:45:36 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh02-2.mail.saunalahti.fi (Postfix) with SMTP id 74E58EF5A6; Thu, 10 Feb 2011 19:45:47 +0200 (EET) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A033B846D5D; Thu, 10 Feb 2011 19:45:47 +0200 Received: from LK-Perkele-VI (a88-112-55-20.elisa-laajakaista.fi [88.112.55.20]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id D6E9A41BE3; Thu, 10 Feb 2011 19:45:43 +0200 (EET) Date: Thu, 10 Feb 2011 19:45:07 +0200 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20110210174507.GA19969@LK-Perkele-VI.localdomain> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> 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] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 17:45:37 -0000 On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-Baker wrote: > > I believe I can support the following criteria with no compromise to any of > them. Based on this list, it looks like scheme that satisifes all of these would be godawfully complicated (interoperability problems) and require loads of code to implement (bugs, or in worst case, security bugs) Remember, this isn't enterprise-only stuff. This needs to be usable by small scale software and services. -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 C22D43A69DC for ; Thu, 10 Feb 2011 07:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 rilVxyBMQKNI for ; Thu, 10 Feb 2011 07:46:37 -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 3C32C3A69C8 for ; Thu, 10 Feb 2011 07:46:37 -0800 (PST) Received: by yxt33 with SMTP id 33so711700yxt.31 for ; Thu, 10 Feb 2011 07:46: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=a4bDRWyQBjY1YvvG1NCBUp/dxwmJcCiR8vnRj3CupcU=; b=RVuDib3iBfjEfvqQsPSaQLAP5u0jPRAYkWCYolWDQfkDYyiaIfKOoYvVEgY8W9dRyj xMay6BPdaV2tLWJsy3NT4ZwwGvrNIMS5C23xLGRwtUzgkLfioM1CZJ0GmR8XAHAWrNc9 lwdH4E2X/wp3XBc7rWtJixp8UQxw4tR/etLFY= 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=x1Uw7vpMKTOB/lrz57cxONpCQT92VsRwdRPOE6OzLTZrnFT+QKABpHiomeqRuyP/Cd 9cn3NIDpz7fO7w89XvtmMQbXP/uGuqV8Yyl0i/l91FfJPItRhVnL/FUfNMPLC+lJoK7B tqqPbBQGpN49QgE3NiLFLuOVLQKzCrXp6bK/E= MIME-Version: 1.0 Received: by 10.101.125.16 with SMTP id c16mr12035777ann.210.1297352809275; Thu, 10 Feb 2011 07:46:49 -0800 (PST) Received: by 10.100.244.38 with HTTP; Thu, 10 Feb 2011 07:46:49 -0800 (PST) In-Reply-To: References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> Date: Thu, 10 Feb 2011 10:46:49 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=001636ed72565861e5049bef7d23 Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 15:46:38 -0000 --001636ed72565861e5049bef7d23 Content-Type: text/plain; charset=ISO-8859-1 Yes, I am working on the draft right now. As you might expect it is an extension of the concepts in CAA and ESRV using the extension mechanism anticipated in CAA. I believe I can support the following criteria with no compromise to any of them. 1) Correct and predictable interaction with CNAME and wildcards 2) Support for publication of attributes that are specific to a particular protocol or apply to a whole domain. 3) Ability to prevent downgrade attack by specifying that protocols are always offered or must be used. 4) Ability to prevent trust substitution attacks such as unauthorized issue of certificates by CA or use of unauthorized certificates in an application. 5) Ability to advertise end entity keys specific to a domain name or domain name and protocol 6) Ability to advertise local trust anchors specific to a domain name 7) Support but not require use of service discovery schemes such as SRV, NAPTR, URI and future schemes as they are developed. 8) Allow for compact implementation. Service discovery must be performed by every device on the network, including devices whose performance does not even support a full IP stack. Code complexity must be kept to a minimum. 9) Enable simplified administration by allowing administrative tasks to be automated. The above can all be supported in a manner that is completely protocol neutral with no special cases called out in the mechanism. (i.e. not specific to PKIX, TLS, application protocol). However in order to use the mechanism with a particular protocol it is likely going to be necessary to write up a separate draft for that particular binding (like we did in SAML). so while I would design the mechanism to be completely neutral wrt the PKI and security protocol, I would only consider writing security bindings for PKIX and TLS and application bindings for HTTP, SMTP, IMAP, POP3 and Jabber. There is one specific protocol that I think we are going to need to special case and that is HTTP for Web browsing where the latency issues have a critical impact on the user experience. The design constraint here being that use of prefix records will inevitably degrade latency performance even if an attempt is made to pre-fetch records before the canonical name of the service is known. 10) Support discovery for attributes relating to interactive HTTP in a single round trip. If people like the above set of requirements, I can provide a design that meets them all with a minimum of mechanism. If there are other requirements, I may be able to support those in addition. On Wed, Feb 9, 2011 at 10:12 PM, Paul Wouters wrote: > On Wed, 9 Feb 2011, Paul Wouters wrote: > > So can you suggest a format for a new "unified" TLSA/HASTLS record? >> > > Just to make it clear. I would be happy with such a unified record. > However, > I'd rather not spend another 9 months on that discussion again, because I > fear it would dig up the whole PKIX vs DANE again. > > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --001636ed72565861e5049bef7d23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I am working on the draft right now. As you might expect it is an exte= nsion of the concepts in CAA and ESRV using the extension mechanism anticip= ated in CAA.

I believe I can support the following crite= ria with no compromise to any of them.

1) Correct and predictable interaction with CNAME and w= ildcards

2) Support for publication of attributes = that are specific to a particular protocol or apply to a whole domain.

3) Ability to prevent downgrade attack by specifying th= at protocols are always offered or must be used.

4= ) Ability to prevent trust substitution attacks such as unauthorized issue = of certificates by CA or use of unauthorized certificates in an application= .

5) Ability to advertise end entity keys specific to a d= omain name or domain name and protocol

6) Ability = to advertise local trust anchors specific to a domain name

7) Support but not require use of service discovery schemes such= as SRV, NAPTR, URI and future schemes as they are developed.
8) Allow for compact implementation. Service discovery must be = performed by every device on the network, including devices whose performan= ce does not even support a full IP stack. Code complexity must be kept to a= minimum.

9) Enable simplified administration by allowing adminis= trative tasks to be automated.


The = above can all be supported in a manner that is completely protocol neutral = with no special cases called out in the mechanism. (i.e. not specific to PK= IX, TLS, application protocol).

However in order to use the mechanism with a particular= protocol it is likely going to be necessary to write up a separate draft f= or that particular binding (like we did in SAML). so while I would design t= he mechanism to be completely neutral wrt the PKI and security protocol, I = would only consider writing security bindings for PKIX and TLS and applicat= ion bindings for HTTP, SMTP, IMAP, POP3 and Jabber.


There is one specific protocol that I th= ink we are going to need to special case and that is HTTP for Web browsing = where the latency issues have a critical impact on the user experience.

The design constraint here being that use of prefix rec= ords will inevitably degrade latency performance even if an attempt is made= to pre-fetch records before the canonical name of the service is known.

10) Support discovery for attributes relating to intera= ctive HTTP in a single round trip.


If people l= ike the above set of requirements, I can provide a design that meets them a= ll with a minimum of mechanism.

If there are other requirements, I may be able to suppo= rt those in addition.



On Wed, Feb 9, 2011 at 10:12 PM, Paul Wouters <paul@xelerance.com&g= t; wrote:
On Wed, 9 Feb 2011, Paul = Wouters wrote:

So can you suggest a format for a new "unified" TLSA/HASTLS recor= d?

Just to make it clear. I would be happy with such a unified record. However= ,
I'd rather not spend another 9 months on that discussion again, because= I
fear it would dig up the whole PKIX vs DANE again.


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



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

--001636ed72565861e5049bef7d23-- 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 A817E3A6824 for ; Wed, 9 Feb 2011 19:12:21 -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 Q1E94llC53mp for ; Wed, 9 Feb 2011 19:12:21 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id C6F443A680C for ; Wed, 9 Feb 2011 19:12:20 -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 70BF4C570 for ; Wed, 9 Feb 2011 22:12:31 -0500 (EST) Date: Wed, 9 Feb 2011 22:12:31 -0500 (EST) From: Paul Wouters To: keyassure@ietf.org In-Reply-To: Message-ID: References: <201102091639.p19GdWLP029306@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 Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 03:12:21 -0000 On Wed, 9 Feb 2011, Paul Wouters wrote: > So can you suggest a format for a new "unified" TLSA/HASTLS record? Just to make it clear. I would be happy with such a unified record. However, I'd rather not spend another 9 months on that discussion again, because I fear it would dig up the whole PKIX vs DANE again. 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 11FBA3A684D for ; Wed, 9 Feb 2011 19:10:55 -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 YRYT2rHIv5BN for ; Wed, 9 Feb 2011 19:10:53 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 5FB003A683F for ; Wed, 9 Feb 2011 19:10: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 48509C570; Wed, 9 Feb 2011 22:11:03 -0500 (EST) Date: Wed, 9 Feb 2011 22:11:02 -0500 (EST) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20110209214440.GG56498@shinkuro.com> Message-ID: References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@shinkuro.com> <20110209214440.GG56498@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] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 03:10:57 -0000 On Wed, 9 Feb 2011, Andrew Sullivan wrote: > Ah, I get what you're arguing. Hrm. > > So what you want, I think, is a three-value state: > > - zone positively has record > This amounts to an affirmation by the zone admin that it > supports the feature. Yes. > - zone asserts it does not have record > This is an indeterminate state with respect to the new > feature, because the the signed absence of a record is not a > meaningful assertion. Well, the absense tells you no DANE based TLS is there. There could still be TLS backed by PKIX. > - zone has record asserting no support > This is the zone admin asserting that it does _not_ support > the feature. This would be the "null TLSA" record? I find that record unneccessary. We also don't have a "null PKIX" record. Is there a desire to create one for those as well? Frankly, adding infrastructure to better support insecure protocols makes no sense to me. Especailly because we are hard on our way on killing port 80, and the last group of clients on port 80 will be those not supporting any new RRTYPE anyway. 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 7D13F3A683F for ; Wed, 9 Feb 2011 19:05:24 -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 R2rKd0zBSSzA for ; Wed, 9 Feb 2011 19:05:23 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 8F8C63A6806 for ; Wed, 9 Feb 2011 19:05:23 -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 A46B5C570; Wed, 9 Feb 2011 22:05:32 -0500 (EST) Date: Wed, 9 Feb 2011 22:05:31 -0500 (EST) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <201102091639.p19GdWLP029306@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] Asserting DANE exclusivity for an entire domain 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, 10 Feb 2011 03:05:24 -0000 On Wed, 9 Feb 2011, Phillip Hallam-Baker wrote: > So what we are going to end up with here by splitting TLSA and HASTLS is a scheme that requires two separate records and discovery > patterns and is considerably less efficient than a scheme that was designed to support both from the start. So can you suggest a format for a new "unified" TLSA/HASTLS record? > In my view the requirement for 'must use TLS' has far deeper support amongst the client vendors than the requirements DANE is apparently > trying to meet. Unfortunately, whenever I suggest a "must use TLS" bit, I'm told you can't dictate policy in DNS. > Thus if DANE does not think about how to work well with HASTLS it is likely to be irrelevant. I'd be interested in seeing your suggestion for a unified record. 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 469C73A684F for ; Wed, 9 Feb 2011 14:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 NZ7MQqOjRYro for ; Wed, 9 Feb 2011 14:23:19 -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 12CC23A682D for ; Wed, 9 Feb 2011 14:23:18 -0800 (PST) Received: by gwb20 with SMTP id 20so334224gwb.31 for ; Wed, 09 Feb 2011 14:23: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=DgUkJuEk8d0MWs3iK2e9R+O9TVhBv4ljUZ7HXoUz3o4=; b=mMIJJ5noipOZqk8sCwy7n87n4C5lxmyET3U5ISKLwaWGpHg4vneNVae4CKM2j6hwVT TlqnRogkpH+mZrGLb3Scfjf4bspqjHbfd8c+b3AxeFXUiDx8EP7zq5d5N9HVsKDrYQr4 eAaq17MsBeZp8xeknbkC06jfhCm00wgH0trdw= 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=cOpdf2L+a350+et+8SgwECOxjNmYbKJFmNOotzWf+tC0nX+pj5ZbrRSh7qZ3aLssBp G5IiByPvym+lXynoGNtY0gQZIKuhx4+iKsW4bT0Rz4mV5/0LwRuqZKO4DI0IOzkzuOjX P8DThtEWlshSDz4+0+aWjZlb5jHTFygh9cIxI= MIME-Version: 1.0 Received: by 10.100.131.17 with SMTP id e17mr11536014and.74.1297290209257; Wed, 09 Feb 2011 14:23:29 -0800 (PST) Received: by 10.100.244.38 with HTTP; Wed, 9 Feb 2011 14:23:29 -0800 (PST) In-Reply-To: References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> Date: Wed, 9 Feb 2011 17:23:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=0016e645ab5617ea9d049be0eaa7 Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 22:23:20 -0000 --0016e645ab5617ea9d049be0eaa7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 9, 2011 at 12:34 PM, Paul Wouters wrote: > > What's wrong with an NSEC record for the TLSA/HASTLS record saying that? What is wrong is that we are designing two separate mechanisms here when we should really have one. This would not matter so much if not for the fact that the design of key assure is being constrained by attempts to support performance requirements. So what we are going to end up with here by splitting TLSA and HASTLS is a scheme that requires two separate records and discovery patterns and is considerably less efficient than a scheme that was designed to support both from the start. In my view the requirement for 'must use TLS' has far deeper support amongst the client vendors than the requirements DANE is apparently trying to meet. Thus if DANE does not think about how to work well with HASTLS it is likely to be irrelevant. It is very easy to glom a key publication scheme onto a policy record. Working the other way is rather harder. -- Website: http://hallambaker.com/ --0016e645ab5617ea9d049be0eaa7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 9, 2011 at 12:34 PM, Paul Wouters=A0<= paul@xelerance.com>=A0w= rote:
What's wrong with an NSEC record for the TLSA/HASTLS record saying that= ?



What is wr= ong is that we are designing two separate mechanisms here when we should re= ally have one.

This would not matter so much if not for the fact that the d= esign of key assure is being constrained by attempts to support performance= requirements.


So what we are going= to end up with here by splitting TLSA and HASTLS is a scheme that requires= two separate records and discovery patterns and is considerably less effic= ient than a scheme that was designed to support both from the start.

In my view the requirement for 'must use TLS' h= as far deeper support amongst the client vendors than the requirements DANE= is apparently trying to meet.

Thus if DANE does n= ot think about how to work well with HASTLS it is likely to be irrelevant. = It is very easy to glom a key publication scheme onto a policy record. Work= ing the other way is rather harder.
--0016e645ab5617ea9d049be0eaa7-- 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 B75503A6899 for ; Wed, 9 Feb 2011 14:09:21 -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 URbEptud+eYA for ; Wed, 9 Feb 2011 14:09:18 -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 1F2C13A6823 for ; Wed, 9 Feb 2011 14:09:17 -0800 (PST) Received: by wyf23 with SMTP id 23so733856wyf.31 for ; Wed, 09 Feb 2011 14:09:28 -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=uBQWy9dir9XKuNNPvUQNytevKhobFZehbqVAfE+xEEI=; b=XajrCwRww72fXosgVjJiDPJGusj/3VCOvBmCHTsFvWD/8RVDyYXX+Wg5Yzeok4cK33 UH+9gqnEaE//Z8uR3k2YaqcIUDk/pTyhqPpnueJSGUlurrNUzXsiNhCCc0nrd2BV2ePx TcfDjAGF08KJk04Ha/W9NQVuZfvhNBA2PUK+o= 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=MuUOQtNnTQPo03mZE0fKj0r4CGCxRTy5lgF3bMMUpp5ungoiAz0Ww3y2eUx5f514vD 1sgOukzLLGkpSdPnQmnWqmxQ5Fn4wr9BGzWHjDq7oWCeLYeVeA2wM/qA/ZqvbeLlYTmF D/dZukIeokW6JP7/kIodB8/pmLiUqYnlodR88= MIME-Version: 1.0 Received: by 10.227.134.144 with SMTP id j16mr14455691wbt.70.1297289367832; Wed, 09 Feb 2011 14:09:27 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Wed, 9 Feb 2011 14:09:27 -0800 (PST) In-Reply-To: <20110209214440.GG56498@shinkuro.com> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@shinkuro.com> <20110209214440.GG56498@shinkuro.com> Date: Wed, 9 Feb 2011 14:09:27 -0800 X-Google-Sender-Auth: AjEMLQOMC3eTSgmyV9qnlTd5ONc Message-ID: From: Zack Weinberg To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 22:09:21 -0000 On Wed, Feb 9, 2011 at 1:44 PM, Andrew Sullivan wrote: > Ah, I get what you're arguing. =C2=A0Hrm. > > So what you want, I think, is a three-value state: > > =C2=A0 =C2=A0- zone positively has record > =C2=A0 =C2=A0 =C2=A0 =C2=A0This amounts to an affirmation by the zone adm= in that it > =C2=A0 =C2=A0 =C2=A0 =C2=A0supports the feature. > > =C2=A0 =C2=A0- zone asserts it does not have record > =C2=A0 =C2=A0 =C2=A0 =C2=A0This is an indeterminate state with respect to= the new > =C2=A0 =C2=A0 =C2=A0 =C2=A0feature, because the the signed absence of a r= ecord is not a > =C2=A0 =C2=A0 =C2=A0 =C2=A0meaningful assertion. > > =C2=A0 =C2=A0- zone has record asserting no support > =C2=A0 =C2=A0 =C2=A0 =C2=A0This is the zone admin asserting that it does = _not_ support > =C2=A0 =C2=A0 =C2=A0 =C2=A0the feature. Yeah. > Is that right? =C2=A0If it's what you're arguing for, it's a little odd, > because we don't normally require this for other protocols. =C2=A0That is= , > if I'm adding (say) an SMTP extension, your rejection of the extension > says nothing about your awareness of the extension. =C2=A0Now, you seem t= o > be arguing in this case that provable non-existence of the record is > not the same as saying you positively don't support the feature, but > I'm not sure I see the additional value in the distinction. =C2=A0(As a f= an > of intuitionistic logic, however, I confess that the three-value > approach has appeal to me personally.) I am personally only arguing for a weaker position: _if_ "saying that you positively don't support a feature" is considered to be a use case worth including in the specification, _then_ that statement must not be expressed via "zone asserts it does not have record". Concretely, I'd be okay with TLSA not having a way to say "this domain positively does not provide any TLS-secured services". That was Matt McCutchen's feature request; I can see the use but if it's not considered valuable enough to include I'd be fine with that. What I'm not fine with is being forced to add TLSA records for all secured services in a zone just so I can start signing it. 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 C55723A686E for ; Wed, 9 Feb 2011 13:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P+l65LJs4+C for ; Wed, 9 Feb 2011 13:44:32 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C18E43A6839 for ; Wed, 9 Feb 2011 13:44:32 -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 744311ECB408; Wed, 9 Feb 2011 21:44:42 +0000 (UTC) Date: Wed, 9 Feb 2011 16:44:40 -0500 From: Andrew Sullivan To: Zack Weinberg Message-ID: <20110209214440.GG56498@shinkuro.com> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@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] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 21:44:33 -0000 On Wed, Feb 09, 2011 at 12:27:27PM -0800, Zack Weinberg wrote: > Basically what I am saying is we cannot treat a zone as having > affirmatively opted in to any new application/transport layer > semantics just because their zone is signed. We have to have a > successful secure lookup of at least one new record. Ah, I get what you're arguing. Hrm. So what you want, I think, is a three-value state: - zone positively has record This amounts to an affirmation by the zone admin that it supports the feature. - zone asserts it does not have record This is an indeterminate state with respect to the new feature, because the the signed absence of a record is not a meaningful assertion. - zone has record asserting no support This is the zone admin asserting that it does _not_ support the feature. Is that right? If it's what you're arguing for, it's a little odd, because we don't normally require this for other protocols. That is, if I'm adding (say) an SMTP extension, your rejection of the extension says nothing about your awareness of the extension. Now, you seem to be arguing in this case that provable non-existence of the record is not the same as saying you positively don't support the feature, but I'm not sure I see the additional value in the distinction. (As a fan of intuitionistic logic, however, I confess that the three-value approach has appeal to me personally.) 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 80D423A67AE for ; Wed, 9 Feb 2011 12:27:19 -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 miSCQrbYHwjN for ; Wed, 9 Feb 2011 12:27:18 -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 619CE3A67AA for ; Wed, 9 Feb 2011 12:27:18 -0800 (PST) Received: by wyf23 with SMTP id 23so634684wyf.31 for ; Wed, 09 Feb 2011 12:27:28 -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=6EEAQQO1fAA7fvnrzxz2G608p9IzXJdR9oJ8bvahTYc=; b=Y/3vQv60pVjuAyKve0UQQNN0fmyeSXtSQDMdBRfpROsb6/m/GuysKaZCi7uuGXs1sd fQk5CQFdqh2DQ+zulzzL8XLPJb5b8YzhAwh68KXucHFZN2o4CQpsV7a7x4ZE44yvgQ1H foYZ1SPVXV9dcDx+1biRRNseo2MO9yBW8lgpg= 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=r+HB8FMqd49t1bLWP0KoMgeeGbOS+GxznN5PhrKiaON2ejm4uQkHb+4GcXaxBEMY+j dJ0OMPU5TtmY4/lfP4yRRgcxDuuRlvUI4UOAXI06jljT1Gujq5BknB6vnjqywAsMCgG+ i7MYI9JQBPK2dehLSvGpcGZwx3f0wLtK8gytg= MIME-Version: 1.0 Received: by 10.227.134.144 with SMTP id j16mr14323816wbt.70.1297283247855; Wed, 09 Feb 2011 12:27:27 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Wed, 9 Feb 2011 12:27:27 -0800 (PST) In-Reply-To: <20110209200305.GB56498@shinkuro.com> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> <20110209200305.GB56498@shinkuro.com> Date: Wed, 9 Feb 2011 12:27:27 -0800 X-Google-Sender-Auth: 7rKL5YIm-5-IK70kcbpEL_X3KhI Message-ID: From: Zack Weinberg To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 20:27:19 -0000 On Wed, Feb 9, 2011 at 12:03 PM, Andrew Sullivan wrote: > On Wed, Feb 09, 2011 at 11:39:33AM -0800, Zack Weinberg wrote: > >> NSEC for any new DNS record MUST mean "behave as you would have prior >> to the invention of the new DNS record". =C2=A0To do otherwise would >> require a flag day for the entire Internet and therefore jeopardize >> not only the transition to whatever new DNS record is suggested, but >> the transition to DNSSEC itself. > > I don't understand what that means. > > An NSEC record with a negative response to a query is a cryptographic > proof that the record doesn't exist. =C2=A0So in this sense, an NSEC reco= rd > for the new DNS RRTYPE works exactly the same way as any other RRTYPE. Right. > But obviously, the _semantics_ of such provable non-existence is > altogether a different matter, for the very same reason that the > semantics of a new RRTYPE could be different for each such type. =C2=A0No= ? No. Individual zone administrators should be able to sign their zone _without making any other changes_ and have everything continue to work as before. That means the semantics of provable non-existence needs to be identical to the semantics of "insecure/indeterminate" (in the RFC 4033 sense) non-existence in all cases, and that in turn has to be legacy compatibility behavior. Basically what I am saying is we cannot treat a zone as having affirmatively opted in to any new application/transport layer semantics just because their zone is signed. We have to have a successful secure lookup of at least one new record. 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 DA9CD3A69F2 for ; Wed, 9 Feb 2011 12:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpnpTlbDqyAd for ; Wed, 9 Feb 2011 12:02:58 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 0CFE13A69F1 for ; Wed, 9 Feb 2011 12:02:58 -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 CBAA71ECB408 for ; Wed, 9 Feb 2011 20:03:07 +0000 (UTC) Date: Wed, 9 Feb 2011 15:03:06 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110209200305.GB56498@shinkuro.com> References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> 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] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 20:02:58 -0000 On Wed, Feb 09, 2011 at 11:39:33AM -0800, Zack Weinberg wrote: > NSEC for any new DNS record MUST mean "behave as you would have prior > to the invention of the new DNS record". To do otherwise would > require a flag day for the entire Internet and therefore jeopardize > not only the transition to whatever new DNS record is suggested, but > the transition to DNSSEC itself. I don't understand what that means. An NSEC record with a negative response to a query is a cryptographic proof that the record doesn't exist. So in this sense, an NSEC record for the new DNS RRTYPE works exactly the same way as any other RRTYPE. But obviously, the _semantics_ of such provable non-existence is altogether a different matter, for the very same reason that the semantics of a new RRTYPE could be different for each such type. No? > (However, a "bogus" DNSSEC validation state for any lookup at all can > and should be treated as a MUST-refuse-to-proceed condition.) That is in fact what it's supposed to mean in the DNS, yes. 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 A73093A69F1 for ; Wed, 9 Feb 2011 11:39:27 -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 29uYBxGlP2vO for ; Wed, 9 Feb 2011 11:39:26 -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 8A3643A69E2 for ; Wed, 9 Feb 2011 11:39:26 -0800 (PST) Received: by wwa36 with SMTP id 36so564802wwa.13 for ; Wed, 09 Feb 2011 11:39:36 -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=n4pX/7RrHY/rzXhMkzQY9nnUvY1uffkRCzUGhyUB24o=; b=MUTVIV24GbNxm9V8ttne8K4J+tPDlTd4YCbjvHDttomIDmIO/WJGS+Q3DLQkAlUwCm 4YaJJw9eLwsI3e1jYfjkdymn7zqZmH9Ot5uNY4Qa+m03e6I+xb4HrXzkJ0I4szxxqyM0 GdyLQSivTpan7Q2dSbze6ne+wV+mTxK0SWCpg= 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=TEUadfrqV6pkHgH9/KbjweSi6nMP6Td27ZQ9mnA44jWmw9g/9tgVuZp00JFEvhdUqp uq7oBhHILFxw8+H0ds27lWr2JwxPtdT7LcfsGWCJSXfuF4/ZXLlqs7iJHQxv4GtjOSoC 3EEyM1QYbkbGhdT6+vq6mTr6Zr7c2NuhVMTl8= MIME-Version: 1.0 Received: by 10.227.182.142 with SMTP id cc14mr1785448wbb.215.1297280375714; Wed, 09 Feb 2011 11:39:35 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Wed, 9 Feb 2011 11:39:33 -0800 (PST) In-Reply-To: References: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> Date: Wed, 9 Feb 2011 11:39:33 -0800 X-Google-Sender-Auth: cf4EgojKqS4i6ZzxqSlmhyUU2M4 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] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 19:39:27 -0000 On Wed, Feb 9, 2011 at 9:34 AM, Paul Wouters wrote: > On Wed, 9 Feb 2011, Martin Rex wrote: > >>>>> I agree with this, but the question is how do you present an empty >>>>> list. >>>> >>>> What exactly would you want to convey with an empty list? >>>> >>>> =C2=A0"I won't respond to TLS, so don't even bother trying" >>> >>> More precisely, "there is no TLS service associated with this DNS >>> name/transport/port". =C2=A0Therefore, general-purpose clients that ref= er to >>> TLS services by DNS name/transport/port will not be able to make a >>> connection. > > What's wrong with an NSEC record for the TLSA/HASTLS record saying that? NSEC for any new DNS record MUST mean "behave as you would have prior to the invention of the new DNS record". To do otherwise would require a flag day for the entire Internet and therefore jeopardize not only the transition to whatever new DNS record is suggested, but the transition to DNSSEC itself. (However, a "bogus" DNSSEC validation state for any lookup at all can and should be treated as a MUST-refuse-to-proceed condition.) 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 9D3403A67D1 for ; Wed, 9 Feb 2011 09:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 jBkXGD2gWdnB for ; Wed, 9 Feb 2011 09:37:49 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3B0CC3A67A5 for ; Wed, 9 Feb 2011 09:37:49 -0800 (PST) Received: by ewy8 with SMTP id 8so295312ewy.31 for ; Wed, 09 Feb 2011 09:37:58 -0800 (PST) Received: by 10.216.2.68 with SMTP id 46mr16708302wee.71.1297273078229; Wed, 09 Feb 2011 09:37:58 -0800 (PST) Received: from bblfish.home (ALagny-751-1-13-24.w83-112.abo.wanadoo.fr [83.112.208.24]) by mx.google.com with ESMTPS id i80sm320026wej.4.2011.02.09.09.37.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 09:37:55 -0800 (PST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 18:37:52 +0100 Message-Id: <57722B1C-F0AE-42D9-8ABE-30223D4F0D51@bblfish.net> To: keyassure@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [keyassure] WebID at W3C and keyassure 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, 09 Feb 2011 17:37:50 -0000 Hi, The W3C has started the WebID incubator group = http://tinyurl.com/webidxg which is continuing work previously known as = foaf+ssl in a more formal setting. I bring this to your attention = because the foaf+ssl protocol [1], is conceptually very similar to what = I believe keyassure is setting out to do. (I have not seen a draft spec = yet, and am going from the group description). Where keyassure is attempting to identify a server using uniquely = identifying information in the DNS, WebID is identifying an end user = (human, robot or agency), via a profile document containing = cryptographically uniquely identifying information placed in the web. = Keyassure coul probably use the dns typed subject alternative name to = identify the verify X509 certifactes, WebID uses the SAN (and IAN) with = https IDs to identify the agent. We are both using canonical referential = lookups to get the meaning of a name (Domain Name with keyassure, = HTTP+TLS with WebID) which we can then use to prove referential = integrity (authentication). So this parallel would by itself be enough to bring this to your = attention. But it turns out that WebID could become all the easier to = deploy and use if keyassure works, since TLS on the server will become = much easier to deploy. Furthermore it makes some very interesting things = possible, as discussed for example in "Turning every Web Server into a = CA",=20 http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html For this use case, I think it would help there if the full public key = were in the DNS.=20 WebID is really about enabling a distributed secure social web. [3] In any case I think it would be very useful to make sure we track each = other's work. I am subscribed to this mailing list now, and our = conversations are fully public too. Joining the mailing list is easy = http://lists.w3.org/Archives/Public/public-xg-webid/=20 and we welcome contributions. It is quite easy to join the XG also, if = you feel a desire to participate more actively. :-) Henry Story [1] in development here http://www.w3.org/2005/Incubator/webid/spec/ [2] "How does Secure Authentication Work in FOAF+SSL" has an = illustration that helps see the parallel. = http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_= with_FOAF.2BSSL.3F [3] see the videos posted on my home page: Social Web Architect http://bblfish.net/ 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 39B913A67FB for ; Wed, 9 Feb 2011 09:34:44 -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 RYOfwFFLAxhx for ; Wed, 9 Feb 2011 09:34:43 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id EE93C3A67BD for ; Wed, 9 Feb 2011 09:34:42 -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 5778EC570; Wed, 9 Feb 2011 12:34:51 -0500 (EST) Date: Wed, 9 Feb 2011 12:34:51 -0500 (EST) From: Paul Wouters To: Martin Rex In-Reply-To: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> Message-ID: References: <201102091639.p19GdWLP029306@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] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 17:34:44 -0000 On Wed, 9 Feb 2011, Martin Rex wrote: >>>> I agree with this, but the question is how do you present an empty list. >>> >>> What exactly would you want to convey with an empty list? >>> >>> "I won't respond to TLS, so don't even bother trying" >> >> More precisely, "there is no TLS service associated with this DNS >> name/transport/port". Therefore, general-purpose clients that refer to >> TLS services by DNS name/transport/port will not be able to make a >> connection. What's wrong with an NSEC record for the TLSA/HASTLS record saying that? > I should have been more explicit on this: > > There is a client with a desire to communicate, and a preference/intend > for TLS-protection. But with most protocols, there is a fallback > strategy to communicate without TLS. It could be that the initial > reference does not even imply TLS, and its only the client who is > looking for clues in DNS whether TLS is available. This is why in HASTLS, you can state whether or not there is a fallback you may use. > So I'm still wondering: what message should an empty list convey? > > A pre-DANE client might fallback to non-TLS if TLS doesn't work, > or it might not try TLS at all. > > What should a DANE-aware client, that is wildly determined to communicate > do when finding an empty TLSA record? Go straight for the unprotected > communication (which is what such a record would imply), or bother > the user with an annoying popup before doing the fallback on unprotected > communication. An empty TLSA record offers nothing more over an NSEC record. > I doubt that "not communicating at all" is a workable solution for such > clients, because it is likely to be perceived as a usability problem > by a non-marginal fraction of the user base. Yet, that is what security will require. If a TLSA record states there is TLS, or a DNSSEC error occurs trying to get a TLS related record, you SHOULD NOT fallback to plaintext. The usability issue is in running legacy port 80..... Fix that and your problem will go away. Then at most the user will see a bad/hacked cert with a popup, hopefully preventing the user from connecting. > Most "Web users" think that "the Web" == "the Internet" and are so completely > accustomed to trust everyone with everything over completely insecure > communication channels (commonly described with "http://") > that it is going to be hard to turn back time on this. HASTLS and STS are bascially the start of the end of port 80. > I'm currently quite annoyed of my EMail provider, because their Web-Mail > interface completely refuses to serve a login page via HTTPS: > They do "POST" to a HTTPS url on their Login-Page, but that page itself > is accessible only through HTTP (on a host that does not listen on 443). Tell them that is unacceptable. 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 029ED3A67AE for ; Wed, 9 Feb 2011 08:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 bTcVOe6VvYCM for ; Wed, 9 Feb 2011 08:39:25 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CB9243A67A7 for ; Wed, 9 Feb 2011 08:39:24 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p19GdW0g028355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Feb 2011 17:39:33 +0100 (MET) From: Martin Rex Message-Id: <201102091639.p19GdWLP029306@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Wed, 9 Feb 2011 17:39:32 +0100 (MET) In-Reply-To: <1296796158.9001.112.camel@mattlaptop2.local> from "Matt McCutchen" at Feb 4, 11 00:09:18 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] Asserting DANE exclusivity for an entire domain 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, 09 Feb 2011 16:39:26 -0000 Matt McCutchen wrote: > > On Tue, 2011-02-01 at 23:42 +0100, Martin Rex wrote: > > Zack Weinberg wrote: > > > > > > > If there is a DANE record, then any wise client should interpret that > > > > as an exclusive list of allowed TLS certificates > > > > > > I agree with this, but the question is how do you present an empty list. > > > > What exactly would you want to convey with an empty list? > > > > "I won't respond to TLS, so don't even bother trying" > > More precisely, "there is no TLS service associated with this DNS > name/transport/port". Therefore, general-purpose clients that refer to > TLS services by DNS name/transport/port will not be able to make a > connection. This does not preclude the admin to run a TLS server for > some special purpose, to accept connections only from specially > configured clients, but in most cases it will make sense to use DANE. > > > > > The only time when such an information becomes interesting is when > > you have a client with a strong desire to communicate with a target > > and intent/preference for using TLS-protection on that communication. I should have been more explicit on this: There is a client with a desire to communicate, and a preference/intend for TLS-protection. But with most protocols, there is a fallback strategy to communicate without TLS. It could be that the initial reference does not even imply TLS, and its only the client who is looking for clues in DNS whether TLS is available. So I'm still wondering: what message should an empty list convey? A pre-DANE client might fallback to non-TLS if TLS doesn't work, or it might not try TLS at all. What should a DANE-aware client, that is wildly determined to communicate do when finding an empty TLSA record? Go straight for the unprotected communication (which is what such a record would imply), or bother the user with an annoying popup before doing the fallback on unprotected communication. I doubt that "not communicating at all" is a workable solution for such clients, because it is likely to be perceived as a usability problem by a non-marginal fraction of the user base. Most "Web users" think that "the Web" == "the Internet" and are so completely accustomed to trust everyone with everything over completely insecure communication channels (commonly described with "http://") that it is going to be hard to turn back time on this. I'm currently quite annoyed of my EMail provider, because their Web-Mail interface completely refuses to serve a login page via HTTPS: They do "POST" to a HTTPS url on their Login-Page, but that page itself is accessible only through HTTP (on a host that does not listen on 443). > > > DANE-unaware clients will continue trying to use TLS. > > What is your rationale for making DANE-aware clients exhibit > > a different behaviour and entirely stop trying to use TLS? > > I assert that I do not offer the TLS service, so there is no point in > DANE clients trying to connect to it. In particular, I do not want them > to connect to some fake service with a certificate from a public CA. > There is nothing I can do about the DANE-unaware clients. While there are a few clients of the type "TLS or refuse to connect", the vast majority of clients will happily connect without TLS instead, and end users have been conditioned over more than a decade that fallbacks are 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 7151E3A684F for ; Tue, 8 Feb 2011 11:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=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 y4UDH1lCsoI6 for ; Tue, 8 Feb 2011 11:46:18 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by core3.amsl.com (Postfix) with ESMTP id 2EC463A6849 for ; Tue, 8 Feb 2011 11:46:18 -0800 (PST) Received: from dhcp-172-31-153-30.sfo.corp.google.com (unknown [72.14.229.84]) by vimes.kumari.net (Postfix) with ESMTPSA id 5408A1B40047; Tue, 8 Feb 2011 14:46:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: <4D481576.3040008@nic.cz> Date: Tue, 8 Feb 2011 14:46:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D481576.3040008@nic.cz> To: keyassure@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [keyassure] Call for consensus on #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, 08 Feb 2011 19:46:19 -0000 Ok, we are calling consensus on #1 -- We will be using a name with a = prefix.... I have just opened a new issue (Issue #19 - = http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) to finalize the = format of the prefix. I realize that we have already had a fair bit of discussion on what = Issue #19 discusses, and I don't want us to forget the progress that we = have made on it.=20 Closing #1 and opening #19 is partly an administrative move, but also = allows us to focus our discussions and all understand where on the page = we are... I'd like to once again thank folk for all of their hard work and ongoing = discussions. W On Feb 1, 2011, at 9:15 AM, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I would like to call for consensus on issue #1. >=20 > The consensus would be that the draft-dane-protocol would define = lookup on TLSA records as query for a name prefixed with a port or port = and proto. >=20 > Possible examples (no preference here for issue #1): > _443.www.example.com > _443._tcp.example.com > _tcp_443.example.com. >=20 > I will open separate issue# for the particular solution for querying = (proto or not, fallback or not, etc.), since I don't think we have = consensus on that yet. (And I think we should step forward constantly = even in small steps.) >=20 > Ondrej > --=20 > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > 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 D72B23A6A55 for ; Sat, 5 Feb 2011 12:45:16 -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 R28iq6bUZyiw for ; Sat, 5 Feb 2011 12:45:15 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id A46F43A6A40 for ; Sat, 5 Feb 2011 12:45:15 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id EC93B57806C for ; Sat, 5 Feb 2011 12:48:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=vXSxaGpNYW4lQrJVO38WcXiS4mcUHDBsIR278G+yfbn ypxXY5aerDQ1r/I8oFqS0ejG8pmjzu74bI+IJlp+NrH/mbtFIoTBBKcuyp71Mq39 NbnVSNhWXl4hGA0TG3GvJAhO2bDCjeojVUMMPYDVtGUAGBOurJ8w9FybuVVBDB/Y = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=EWIzogj4cjbcmqZ84oyzk+59Jg4=; b=nHYnW7IJi1 ypHAoc7nrgUdNNFOc1MczXWltba/cR9weArdXQ4QeokvBirD1hQLe/K+QHNXqUCb F05xVTJqJv15RzkWg6EmxAkbRbZ4KnzmNLR20ydbewpe+BIJ3G+fQRswGebIPX/g q9ZZO8l35o/TWfjLkeyUIFdbawMsJcK8A= Received: from [192.168.1.40] (pool-96-231-14-47.washdc.east.verizon.net [96.231.14.47]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 94CDE578059 for ; Sat, 5 Feb 2011 12:48:43 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> <1296792674.9001.75.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Sat, 05 Feb 2011 15:48:41 -0500 Message-ID: <1296938921.1862.52.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 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, 05 Feb 2011 20:45:16 -0000 On Sat, 2011-02-05 at 12:53 -0500, Phillip Hallam-Baker wrote: > I think this solution can be made to work, but it is not the best > solution that we can achieve. > > In addition to the IPv4 exhaustion issue, the IETF has been facing a > port exhaustion issue as well for some time. And so there has been a > push to move to use DNS protocol prefixes to fix that problem. [...] > As far as mechanism goes, I see two distinct conditions to support > > 1) Where the connection is established by the DNS name directly > > 2) Where a prefixed discovery mechanism is involved. > > The scheme I propose has essentially the same performance > characteristics as Matt's, I just have slightly different semantics, > instead of always looking for the prefix record, I always look for a > record at the unprefixed domain that may tell me that advanced > discovery (SRV, NAPTR, URI) is in use and that there is more detailed > data available or may tell me that there is no additional data to be > found. > > It is of course still possible to perform optimistic pre-fetching of > the prefixed records at the start of discovery under my scheme as > well. > > I don't see this as a 'grand design', I just see it as fitting in with > the existing DNS discovery architecture rather than complicating it. I > give the administrator a straightforward binary choice, either do not > differentiate between trust criteria for services at all, or > alternatively employ advanced discovery to do so. I agree that there are problems to be solved with discovery. What I don't understand is what you hope to gain by entangling discovery with DANE. In my view, binding credentials to the hostname+transport+port tuple to which the client connects is ideal because: 1. All clients we care about, including generic tools like stunnel and openssl s_client, go through this stage. It will be straightforward to modify them to pass the information to the TLS library. The library could even have a single API call "dane_tls_connect(hostname, port)" that both connects the socket and saves the endpoint info for later checking, giving us the "secure TCP" primitive we never had (likewise for other transports), but I suspect there must be reasons why this approach is not already taken with the hostname. 2. With current SNI, this tuple is exactly what is available to the server when it chooses a credential to present. Thus, in the absence of active attacks, the set of credentials that clients might see when making a connection is a function only of this tuple. Finer distinctions cannot meaningfully be made in DANE. If people want to virtual-host multiple service types for the same hostname on the same port and demultiplex them at the TLS level, that would require support for service types in both SNI and DANE, but I highly doubt that will become important. Can you point to any concrete use cases that would benefit from your proposal? > The clients that are going to make use of these keys are going to have > to have custom code anyway. Not really. All one would have to do, using NSS as an example, is modify SSL_SetURL (a misnomer; it takes only the hostname) to also take the transport and port and modify the applications to pass that information. > One issue I do see with the port prefix approach is that it does not > make much sense with the existing scheme employed to support > multi-homing of Web hosts - multiple A records. For example, if > example.com has four hosts, it will have something like: > > $origin example.com > www CNAME example.com > . A 10.0.0.1 > . A 10.0.0.2 > . A 10.0.0.3 > . A 10.0.0.4 > > So now we add a record > > _80._http TLSA (whatever) > > Which binds to a specific port on a non specific IP address. That does > not make much sense to me. Agreed, that is a little goofy. But it's not a reason to prefer your combined DANE + discovery proposal because SRV in combination with DANE as I propose will solve the problem equally well. And I don't think it's worth bending over backwards to solve this in DANE if the application is not prepared to adopt a discovery mechanism. -- 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 A423A3A69E0 for ; Sat, 5 Feb 2011 09:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.625 X-Spam-Level: X-Spam-Status: No, score=-3.625 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 ra2-PoaFzGpG for ; Sat, 5 Feb 2011 09:50:19 -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 44A503A6985 for ; Sat, 5 Feb 2011 09:50:14 -0800 (PST) Received: by gwb20 with SMTP id 20so1459091gwb.31 for ; Sat, 05 Feb 2011 09:53: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=RFmQzyweF/Gta2ZXz1cyDCOl7myMFIhLb4jNWvyHLFA=; b=V1hzqAt99j/I6DCcpAziFB7T+/aWotAPQ7R3I9lVluVhuMkDLYC9VieUKxBaGDK5GH 70FHZjciLRZQv2OJWpjqZ07HmAB36eiYtHGuJvlgeqYeS71jMua4792AylDEqJ2j796k Fiz4GXy2i+tJc9tQtqtjCP9tZyB5TzfAamX1c= 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=n/PUTGfBorMT2w7QOIfZjbcNw8O2QUXqUcUwYm5pZ8g0SlOJiuUOQix6Cst7sjFN9t 1y2x/kiESQ6U+Z41pP6wa3L0BgPfqb+nNG6nOoUvMO9PDWRws22+Tb1Mm21B6tHApBDG A352bqlLYUgZ+DURk/0yDuEq7b6Ld+hjZqDM8= MIME-Version: 1.0 Received: by 10.100.6.7 with SMTP id 7mr8317866anf.256.1296928419129; Sat, 05 Feb 2011 09:53:39 -0800 (PST) Received: by 10.100.242.14 with HTTP; Sat, 5 Feb 2011 09:53:39 -0800 (PST) In-Reply-To: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> <1296792674.9001.75.camel@mattlaptop2.local> Date: Sat, 5 Feb 2011 12:53:39 -0500 Message-ID: From: Phillip Hallam-Baker To: James Cloos Content-Type: multipart/alternative; boundary=0016e642d3bab8aa34049b8cadef Cc: keyassure 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, 05 Feb 2011 17:50:21 -0000 --0016e642d3bab8aa34049b8cadef Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 4, 2011 at 7:38 PM, James Cloos wrote: > >>>>> "MM" == Matt McCutchen writes: > > >> Those are not awful. They probably make prefixes usable. > >> > >> (And perhaps should be used for existing SRV usages, too.) > > MM> That's what I was hoping to achieve. I appreciate the vote > MM> of confidence. :) > > I wanted to think about it some more, but I do agree that what you > propose is the right solution. I think this solution can be made to work, but it is not the best solution that we can achieve. In addition to the IPv4 exhaustion issue, the IETF has been facing a port exhaustion issue as well for some time. And so there has been a push to move to use DNS protocol prefixes to fix that problem. I see two very distinct sets of requirements by application protocol: 1) How to deal with widely deployed legacy protocols requiring low latency connection establishment. 2) How to deal with new protocols and protocols that do not require optimization The first is essentially use of HTTP for Web browsing. There are other protocols in use, but none where the impact of DNS connection establishment is anywhere near a dominant impact on performance. So it really is quite appropriate to treat HTTP as a special case, indeed HTTP specifically for use in Web Browsing as opposed to using it as a Web Services transport, firewall bypass protocol or whatever. As far as mechanism goes, I see two distinct conditions to support 1) Where the connection is established by the DNS name directly 2) Where a prefixed discovery mechanism is involved. The scheme I propose has essentially the same performance characteristics as Matt's, I just have slightly different semantics, instead of always looking for the prefix record, I always look for a record at the unprefixed domain that may tell me that advanced discovery (SRV, NAPTR, URI) is in use and that there is more detailed data available or may tell me that there is no additional data to be found. It is of course still possible to perform optimistic pre-fetching of the prefixed records at the start of discovery under my scheme as well. I don't see this as a 'grand design', I just see it as fitting in with the existing DNS discovery architecture rather than complicating it. I give the administrator a straightforward binary choice, either do not differentiate between trust criteria for services at all, or alternatively employ advanced discovery to do so. The clients that are going to make use of these keys are going to have to have custom code anyway. One issue I do see with the port prefix approach is that it does not make much sense with the existing scheme employed to support multi-homing of Web hosts - multiple A records. For example, if example.com has four hosts, it will have something like: $origin example.com www CNAME example.com . A 10.0.0.1 . A 10.0.0.2 . A 10.0.0.3 . A 10.0.0.4 So now we add a record _80._http TLSA (whatever) Which binds to a specific port on a non specific IP address. That does not make much sense to me. Of course we are trying to get away from using round robin discovery, it is not a very good approach for load balancing. But the port prefix approach is not playing nice with the existing proposed alternatives. -- Website: http://hallambaker.com/ --0016e642d3bab8aa34049b8cadef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 4, 2011 at 7:38 PM, James Cl= oos <cloos@jhcloo= s.com> wrote:
>>>>> "MM" =3D=3D Matt McCutchen= <matt@mattmccutchen.net&g= t; writes:

>> Those are not awful. =A0They probably make= prefixes usable.
>>
>> (And perhaps should be used for existing SRV usages, too.)

MM> That's what I was hoping to achieve. =A0I appreciate the v= ote
MM> of confidence. =A0:)

I wanted to think about it some more, but I do agree that what you
propose is the right solution.


I think this solution can be made to work, but it is not the best soluti= on that we can achieve.

In addition to the IPv4 ex= haustion issue, the IETF has been facing a port exhaustion issue as well fo= r some time. And so there has been a push to move to use DNS protocol prefi= xes to fix that problem.

I see two very distinct sets of requirements by applica= tion protocol:


1) How to deal with = widely deployed legacy protocols requiring low latency connection establish= ment.

2) =A0How to deal with new protocols and protocols that= do not require optimization=A0
=A0

The = first is essentially use of HTTP for Web browsing. There are other protocol= s in use, but none where the impact of DNS connection establishment is anyw= here near a dominant impact on performance.

So it really is quite appropriate to treat HTTP as a sp= ecial case, indeed HTTP specifically for use in Web Browsing as opposed to = using it as a Web Services transport, firewall bypass protocol or whatever.=


As far as mechanism goes, I see two dist= inct conditions to support

1) Where the connection= is established by the DNS name directly

2) Where = a prefixed discovery mechanism is involved.


The scheme I propose has essentially the= same performance characteristics as Matt's, I just have slightly diffe= rent semantics, instead of always looking for the prefix record, I always l= ook for a record at the unprefixed domain that may tell me that advanced di= scovery (SRV, NAPTR, URI) is in use and that there is more detailed data av= ailable or may tell me that there is no additional data to be found.

It is of course still possible to perform optimistic pr= e-fetching of the prefixed records at the start of discovery under my schem= e as well.


I don't see this as = a 'grand design', I just see it as fitting in with the existing DNS= discovery architecture rather than complicating it. I give the administrat= or a straightforward binary choice, either do not differentiate between tru= st criteria for services at all, or alternatively employ advanced discovery= to do so.

The clients that are going to make use of these keys ar= e going to have to have custom code anyway.


One issue I do see with the port prefix approach is that it does n= ot make much sense with the existing scheme employed to support multi-homin= g of Web hosts - multiple A records. For example, if example.com has four hosts, it will have something like:

$origin example.com<= /div>
www =A0CNAME example.com
=
. =A0 =A0A 10.0.0.1
. =A0 =A0A 10.0.= 0.2
. =A0 =A0A 10.0.0.3
. =A0 =A0A 10.0.0.4

So now we add a recor= d

_80._http =A0TLSA =A0(whatever)

Which binds to a specific port on a non specific IP address. That = does not make much sense to me.

Of course we are trying to get away from using round ro= bin discovery, it is not a very good approach for load balancing. But the p= ort prefix approach is not playing nice with the existing proposed alternat= ives.


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

--0016e642d3bab8aa34049b8cadef-- 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 656AA3A67BD for ; Fri, 4 Feb 2011 19:40:21 -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 QQbQeRo7jiYB for ; Fri, 4 Feb 2011 19:40:20 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 601983A67B3 for ; Fri, 4 Feb 2011 19:40:20 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id A5A9B208069 for ; Fri, 4 Feb 2011 19:43:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=q4Cz5NSmV59p7sKLquUK3NzRAkoXwdqeiN2GzLrsCUI rQGb0XpORZPqBCA7H4PFnLbdrUxarAxfeVtSuVsgxbvKo7vO8PY0oy+a/tBXT9kC oepS4kdZd2Q0bdVt1oFUdGq2Z83CsrJApzm1xHfxDdLXDvFIbkFn3jdnWcFsxXnw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=YPOIfSlOh0vqKoqwCjLJn+lz5IQ=; b=kCT5sJ5TAd tnqyZ31sCAVlWFfrlYNTNAqUfcRehhIJVcWocaXOlTJDAVZPCxFHF3Xvfl2UZrpq 4faApZosO8eUUvTfCtCbZ7uctgFjG4x0UolZfTATfIHVjidL5T3xnNi7tX5LdAvI rW22BxJAq2GIVQwz0b1OEbKnxzQXmLpVM= Received: from [192.168.1.40] (pool-96-231-14-47.washdc.east.verizon.net [96.231.14.47]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 4A229208064 for ; Fri, 4 Feb 2011 19:43:46 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <201102042006.p14K6BKA011190@fs4113.wdf.sap.corp> References: <201102042006.p14K6BKA011190@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 22:43:44 -0500 Message-ID: <1296877424.2777.99.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services 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, 05 Feb 2011 03:40:21 -0000 On Fri, 2011-02-04 at 21:06 +0100, Martin Rex wrote: > Matt McCutchen wrote: > > > > On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote: > > > using the same certificate for multiple services at the > > > same name exposes you to cross-protocol attacks. > > > > To clarify: even if the services are at the same security level, the > > case in which a MITM diverts the connection to a service other than the > > one the client wanted should be caught at the TLS level. > > > > TLS is designed to be capable of providing a strong guarantee: if your > > connection goes through, you are talking to the service you wanted. > > Let's not weaken this by being sloppy with the naming. > > You're confusing two things here: [...] I did not intend to do so. I understand that naming and certificate acceptance criteria are outside the scope of TLS per se. By the "TLS level", I meant the facility that provides TLS connections with server authentication to applications. > TLSA records of the form > > _443._tcp.www.example.com TLSA (server-cert|server-cert-hash) > > would allow to distinguish server endpoints at the granularity > (port+protocol+hostname). With this scheme it is possible > to prevent "cross-protocol attacks" by assigning distinct > credentials to distinct protocols. (There is no protection > if the services share a single credential, though). Right. If SNI would include the transport+port, having the server check that information would be another way to prevent the attacks. However, I'm thinking it may be better design for each service to have a credential valid only for the name+transport+port combinations it is capable of serving. This will hopefully be less of a PITA to arrange with DANE than under the traditional public CA system. -- 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 AF95F3A69E4 for ; Fri, 4 Feb 2011 19:23:21 -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 2ldTJzts0hj3 for ; Fri, 4 Feb 2011 19:23:20 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 354773A69DF for ; Fri, 4 Feb 2011 19:23:20 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id A93B94011B; Sat, 5 Feb 2011 03:26:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296876405; bh=KTG2HklzwYdROQ3069I2XSDh+OBFG8SNn+VnGRTQWBg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=PXVqiUP3djaRQUCjqHpRQaWPrn7Rf4L/VIoaVM1wgBCtieA54Xdf+BvshjNEuELK3 LIEyrbYNcBr14/alGmbRIfDXZGZLoZY3bBnM3t9Axbc64FacBy5f4WwD/HhABEyWvx 4wK7FfJn1eSbvZJ2t5D8tVKFS/eAsudTXEYdcxlU= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 53BBC360029; Sat, 5 Feb 2011 00:38:41 +0000 (UTC) From: James Cloos To: Matt McCutchen In-Reply-To: <1296792674.9001.75.camel@mattlaptop2.local> (Matt McCutchen's message of "Thu, 03 Feb 2011 23:11:14 -0500") References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> <1296792674.9001.75.camel@mattlaptop2.local> 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, 04 Feb 2011 19:38:41 -0500 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110205:matt@mattmccutchen.net::WwMIBO5EoZ5MGq+e:00000000000000000000000000000000000000OGr8c X-Hashcash: 1:30:110205:keyassure@ietf.org::gkGfOh6SIt2jAFv+:0000000000000000000000000000000000000000003mDtp Cc: keyassure 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, 05 Feb 2011 03:23:21 -0000 >>>>> "MM" == Matt McCutchen writes: >> Those are not awful. They probably make prefixes usable. >> >> (And perhaps should be used for existing SRV usages, too.) MM> That's what I was hoping to achieve. I appreciate the vote MM> of confidence. :) I wanted to think about it some more, but I do agree that what you propose is the right solution. -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 B14163A6AB5 for ; Fri, 4 Feb 2011 15:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Gaahps11Ob3H for ; Fri, 4 Feb 2011 15:49:33 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id D02BB3A6AB3 for ; Fri, 4 Feb 2011 15:49: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 2D470C541; Fri, 4 Feb 2011 18:52:57 -0500 (EST) Date: Fri, 4 Feb 2011 18:52:56 -0500 (EST) From: Paul Wouters To: Mark Andrews In-Reply-To: <20110204205330.A2BBE9B1931@drugs.dv.isc.org> Message-ID: References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> <1296792934.9001.78.camel@mattlaptop2.local><20110204131258.GC33857@shinkuro.com> <20110204205330.A2BBE9B1931@drugs.dv.isc.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] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 23:49:33 -0000 On Sat, 5 Feb 2011, Mark Andrews wrote: > SOA/NS not answered by GLB's. Cisco should fix that :) 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 F00903A67C1 for ; Fri, 4 Feb 2011 13:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 v4OeQiZkU0RT for ; Fri, 4 Feb 2011 13:28:08 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id B7CCF3A694A for ; Fri, 4 Feb 2011 13:28:07 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 3D5644011B; Fri, 4 Feb 2011 21:31:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296855092; bh=KHPCH6b/5swNUH5bddRHpFVqCdYIUUukZ06rABoFOXI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=QJIT/qtfroB9kiCkjBwADjf7EYsTgSwvO+XTCu7fGSSpXyDOgM9IsDkXDs13aN5Dr E2LuorljzGI1yCuBg1sHqu0NtRvNBAqVC6ZnbPbmtY0Xs5lqD+7mnCC6AKZeVnuWif GOInvTvXoMHT7XhtLuyCzmFTjGOHDxafTM1gaV6k= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 17862360029; Fri, 4 Feb 2011 19:36:22 +0000 (UTC) From: James Cloos To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= In-Reply-To: <1296799247.9001.135.camel@mattlaptop2.local> (Matt McCutchen's message of "Fri, 04 Feb 2011 01:00:47 -0500") References: <4D481576.3040008@nic.cz> <1296799247.9001.135.camel@mattlaptop2.local> 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, 04 Feb 2011 14:36:21 -0500 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110204:ondrej.sury@nic.cz::A70Uxks0adEzeRP9:000000000000000000000000000000000000000000JwfQN X-Hashcash: 1:30:110204:keyassure@ietf.org::u+87zBqoust+VlRg:0000000000000000000000000000000000000000007LYuG X-Hashcash: 1:30:110204:matt@mattmccutchen.net::1/OIEyWDh9bgv+J7:00000000000000000000000000000000000000eKSFn Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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: Fri, 04 Feb 2011 21:28:09 -0000 After further thought, provided that Matt's proposal to deal with CNAME and wildcard issues is used, I agree that prefixed lookups are best. All of the arguments for prefixes are good, and his proposal deals well with the prefix vs ( CNAME | wildcard ) issues which would otherwise contraindicate prefixes. -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 AFF313A69A9 for ; Fri, 4 Feb 2011 13:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 4O7wZmAEzkf3 for ; Fri, 4 Feb 2011 13:12:17 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 07DA63A69D3 for ; Fri, 4 Feb 2011 13:12:17 -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 1FFF81ECB421 for ; Fri, 4 Feb 2011 21:15:42 +0000 (UTC) Date: Fri, 4 Feb 2011 16:15:40 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110204211540.GG33857@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> <20110204205330.A2BBE9B1931@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110204205330.A2BBE9B1931@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 21:12:18 -0000 On Sat, Feb 05, 2011 at 07:53:30AM +1100, Mark Andrews wrote: > > DS don't exist with islands of trust. Right, but in that case you have a DNSKEY with no DS at the parent. > DNSKEY doesn't exist with non-signed zones. Non-signed zones aren't a consideration here, because they're never going to be candidates for any of the DANE output. Normally, it's a problem, but not in this case. > SOA/NS not answered by GLB's. Yes. But we don't care, because the DS/DNSKEY point is the one we need. Either you have a DS through which you can build a chain, or you have a TA matching the DNSKEY, or you don't use the data from this zone (for these purposes). 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 5B95D3A6AB3 for ; Fri, 4 Feb 2011 12:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 xmxebghpY4b8 for ; Fri, 4 Feb 2011 12:50:25 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 45C113A6A5A for ; Fri, 4 Feb 2011 12:50:25 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 772675F983B; Fri, 4 Feb 2011 20:53:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3DCFB216C22; Fri, 4 Feb 2011 20:53:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A2BBE9B1931; Sat, 5 Feb 2011 07:53:30 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> <1296792934.9001.78.camel@mattlaptop2.local><20110204131258.GC33857@shinkuro.com> In-reply-to: Your message of "Fri, 04 Feb 2011 08:12:59 CDT." <20110204131258.GC33857@shinkuro.com> Date: Sat, 05 Feb 2011 07:53:30 +1100 Message-Id: <20110204205330.A2BBE9B1931@drugs.dv.isc.org> Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 20:50:26 -0000 In message <20110204131258.GC33857@shinkuro.com>, Andrew Sullivan writes: > On Thu, Feb 03, 2011 at 11:15:34PM -0500, Matt McCutchen wrote: > > > > Not any more than the DNSKEY RRset does. Either RRset will be cached by > > the ISP as soon as one client cares about it. > > I think you mean the DS, since the DNSKEY isn't at the parent. But > that's not the only case anyway. As I understand it, the idea here is > that you're going to crawl up and look to see whether the parent > includes a record "covering" the policy in the child. TLDs won't have > such a record, which will mean that they'll get a lot of queries for > things they don't have. Negative caches don't last long. > > This is why I claim that the only sensible way to look for the zone > cut, if that's what we're going to do, is to use the DS record itself, > because you're guaranteed to need it or a configured trust anchor for > this scheme to work. Give the amount of broken DNS implementations out there you can't do this reliably with any query. SOA and NS should be in every zone but they are not. DS don't exist with islands of trust. DNSKEY doesn't exist with non-signed zones. SOA/NS not answered by GLB's. Mark > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org 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 8997A3A692E for ; Fri, 4 Feb 2011 12:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.155 X-Spam-Level: X-Spam-Status: No, score=-10.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 uthMkQhgUaFd for ; Fri, 4 Feb 2011 12:02:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 6C1D53A68AF for ; Fri, 4 Feb 2011 12:02:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p14K6CL7027020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Feb 2011 21:06:13 +0100 (MET) From: Martin Rex Message-Id: <201102042006.p14K6BKA011190@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 4 Feb 2011 21:06:11 +0100 (MET) In-Reply-To: <1296783030.9001.26.camel@mattlaptop2.local> from "Matt McCutchen" at Feb 3, 11 08:30:30 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 #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: Fri, 04 Feb 2011 20:02:50 -0000 Matt McCutchen wrote: > > On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote: > > using the same certificate for multiple services at the > > same name exposes you to cross-protocol attacks. > > To clarify: even if the services are at the same security level, the > case in which a MITM diverts the connection to a service other than the > one the client wanted should be caught at the TLS level. > > TLS is designed to be capable of providing a strong guarantee: if your > connection goes through, you are talking to the service you wanted. > Let's not weaken this by being sloppy with the naming. You're confusing two things here: Per section 1. Introduction, last sentence of all existing TLS specs, the TLS protocol is completely agnositc about naming, and technically, completely agnostic about PKIX, X.509 certs and certificate paths. Many implementations of TLS go far beyond the TLS protocol spec and provide complimentary code to applications that performs server endpoint identification as described in rfc-2818 and performs PKIX cert path validation per default, offering application callers possibilities to obtain details and override negative results from PKIX processing. If there is a possibility for cross-protocol attacks, then this is not a result of a failure within TLS, but a failure of the apps in correctly identifying and distinguishing TLS server endpoints. In the traditional approach of server endpoint identification described in rfc-2818, endpoints are distinguished and identified at the granularity of "hostname". TLSA records of the form _443._tcp.www.example.com TLSA (server-cert|server-cert-hash) would allow to distinguish server endpoints at the granularity (port+protocol+hostname). With this scheme it is possible to prevent "cross-protocol attacks" by assigning distinct credentials to distinct protocols. (There is no protection if the services share a single credential, though). The big advantage of doing this in DNS rather than within the server/service certificate is that it is easier on the admin side--you don't have to rekey the service when you want to run it on a different port. TCP ports are a very limited resource that is assigned on a first-come-first-served basis, and it is not uncommon to have multiple distinct instances of a particular service/protocol listening on distinct ports of a single host(name). -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 AD39C3A6BBA for ; Fri, 4 Feb 2011 05:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 M8WbcRsBZ0cL for ; Fri, 4 Feb 2011 05:09:41 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9F8123A6BCC for ; Fri, 4 Feb 2011 05:09:36 -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 E8F451ECB41F for ; Fri, 4 Feb 2011 13:13:00 +0000 (UTC) Date: Fri, 4 Feb 2011 08:12:59 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110204131258.GC33857@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> <1296792934.9001.78.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1296792934.9001.78.camel@mattlaptop2.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 13:09:42 -0000 On Thu, Feb 03, 2011 at 11:15:34PM -0500, Matt McCutchen wrote: > > Not any more than the DNSKEY RRset does. Either RRset will be cached by > the ISP as soon as one client cares about it. I think you mean the DS, since the DNSKEY isn't at the parent. But that's not the only case anyway. As I understand it, the idea here is that you're going to crawl up and look to see whether the parent includes a record "covering" the policy in the child. TLDs won't have such a record, which will mean that they'll get a lot of queries for things they don't have. Negative caches don't last long. This is why I claim that the only sensible way to look for the zone cut, if that's what we're going to do, is to use the DS record itself, because you're guaranteed to need it or a configured trust anchor for this scheme to work. 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 26BBC3A6867 for ; Thu, 3 Feb 2011 21:57:26 -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 vosPgW3wLdu5 for ; Thu, 3 Feb 2011 21:57:24 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id C95DA3A6778 for ; Thu, 3 Feb 2011 21:57:24 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 0E133208063 for ; Thu, 3 Feb 2011 22:00:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=V+mdIoL9vczG2SFwuhkRML3L+/xxIrkzr5H7vbZvFC/ d2WHv0y2rsyBSWOHPitDCotTOKngmfySlCcZs4JGRCrrTR/otYxP6ueIPGw79YVP hvr3disC4EX20WXQqGtyjws2jESRsC/XLoEi6wuwAvAtUX/wV021nDJsZjjzv1Kk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=rrpyGPukFBmrN7yAFyJAz6KmMYs=; b=s+rsGherKf /HvgjIJw0PuF1F411NdETy85v1sk1uFryrD+os07wGQA1PepFD086ciG0vXBjXKr XqL5jljry8p7oRaytouuYBEskEPKN2U3qQC4CU71dvdGk/xi+e+p61r3ExLo0cpM SG4T20CzuhGEEkgbZDw/yjWkYBuNVlfoA= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id C2146208061 for ; Thu, 3 Feb 2011 22:00:48 -0800 (PST) From: Matt McCutchen To: keyassure@ietf.org In-Reply-To: References: <4D481576.3040008@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 01:00:47 -0500 Message-ID: <1296799247.9001.135.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Call for consensus on #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: Fri, 04 Feb 2011 05:57:26 -0000 On Wed, 2011-02-02 at 15:30 -0500, James Cloos wrote: > Or it would need to specify the zone's own root CA (by IRI and hash) > which can then specify how much trust whatever it signs should have. > The only restriction we should specify in that case is that our RR only > implies that said CA can be trusted for names which are the same "zone"? > as the > one where the CA pointer was found. (For this purpose, a name such as > foo.bar.example.net. should be considered (in) a sub-zone of > example.net. only iff there is a DS RR in the trust path. In other > words, the '.'s don't make the boundries, only DS RRs do. We should > point that out explictly, no matter what else we do.) You are right, an organization with an existing internal CA will typically want to designate it for the entire zone, just like I want to assert DANE exclusivity for my entire zone. (Though they should also be able to designate it just for the example.com host if they want.) We can use the same design for both kinds of zone-wide assertion. > I just thought of another possbile wording. We could just say that our > lookup should be for whatever the (DNS) client is already going to look > up. If it is about to do an AorAAAA lookup on 'example.com.', then it > should also do a DANE lookup on 'example.com.'. And if it is about to > do a SRV lookup on '_sip._tcp.example.org.' then its DANE lookup should > also be on '_sip._tcp.example.org.'. I prefer the design in which the DANE lookup is always on the host/port the client will connect to and any SRV discovery is done first. This way, there is only one kind of DANE lookup, stunnel can do it, and if you do load balancing with SRV, you can designate a different key for each target server rather than pile them all at the source name. The one thing to watch out for is that the SRV becomes security-critical, but I'd find it hard to argue that the current practice of issuing a cert with the source name to the target machine is any more secure. -- 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 C8FB73A6B12 for ; Thu, 3 Feb 2011 21:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 UaDSQ1CYEIgg for ; Thu, 3 Feb 2011 21:21:04 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id BA4163A6AF8 for ; Thu, 3 Feb 2011 21:21:04 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 02FBF25C064; Thu, 3 Feb 2011 21:24:29 -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=vrSe52mQFIVciqYBH/vdPDkQa04PQXD8OBQ6PAYkV7f tgpaNfdh21hu5IL6Dq2miZCyHmUFnE8NaFjzKPlnQ9T/9zWE1Ej2Vi0DZmYaDf/f nz+8+/j4X0g/cdV+jflu1hD0oXLXWaCrWAMAboW/Zff62554B8E1r1biAzT/2Qqs = 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=tDEtTPixP3QzsS/aIQpT1oWNA74=; b=n7WDzQGFxx eibG/m6iWI03iyOPJH8MNSHQ/YYZ5ndBI0UpLTM4dSnvQ9aXyyOQ0j4JtxD7Hn+G ckrRlOy5inSXVyHa/W65gW5C4coPVWCtoQVl6ni8pWuqluTjd/l21oZk1HZ7KsJN /fWNMLZUnN9UBd1gQfIoC25pFOeMJqljM= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id 9166E25C063; Thu, 3 Feb 2011 21:24:28 -0800 (PST) From: Matt McCutchen To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4D491C9E.8020508@nic.cz> References: <4D481576.3040008@nic.cz> <1296575329.1888.26.camel@mattlaptop2.local> <4D491C9E.8020508@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 00:24:26 -0500 Message-ID: <1296797066.9001.115.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] Call for consensus on #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: Fri, 04 Feb 2011 05:21:05 -0000 On Wed, 2011-02-02 at 09:58 +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 1.2.2011 16:48, Matt McCutchen wrote: > > I don't feel strongly about the syntax, but I like the consistency of > > _443._tcp.example.com with SRV. >=20 > So you agree with the proposal to use prefix labels? Yes. (I didn't realize you meant to solicit consensus, not just declare it. Maybe that helps explain my previous message.) --=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 1D1C93A6AAF for ; Thu, 3 Feb 2011 21:18:29 -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 ujv1k19q2KGQ for ; Thu, 3 Feb 2011 21:18:28 -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 1037B3A6853 for ; Thu, 3 Feb 2011 21:18:27 -0800 (PST) Received: by wyf23 with SMTP id 23so1979640wyf.31 for ; Thu, 03 Feb 2011 21:21:51 -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=LSNdUI1TiOvCNGJhiraIZWewR3GjFbdeXqxHaJatoP4=; b=H4eFz2HQ6HM08f1oOsS1/AoWNV21q3Q74yT3sFslM7aPKJF8Hw40Hsc8u9qGvRKNpa ndan3JMQpixCmoZqK8h9lUcSu23D1C/pd9R6AzNvbK0QbLmDG5Xny3tFMEn4mfW0q6Et s3FlEG7fUTN7Bp5j1TqLUTNlDIU9K2ttcqX9o= 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=PW4oFjswohV+2v+7dgZ00kxUQbbW9OeB/F49ZWASaiTm9K9xT79IWlfPV7807FY9pA +1GjtSFTM7wZnOzeKZVeRydvZoq405sMiBPdtb/h1Q1hGem5wf/wLzReQHx9Htvc/lL7 rycaHBTGfByW+Kj6VXmXr+NthyY9Or86TuNAc= MIME-Version: 1.0 Received: by 10.227.137.85 with SMTP id v21mr11560264wbt.157.1296796911270; Thu, 03 Feb 2011 21:21:51 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Thu, 3 Feb 2011 21:21:51 -0800 (PST) In-Reply-To: <1296794287.9001.90.camel@mattlaptop2.local> References: <1296575340.1888.27.camel@mattlaptop2.local> <1296794287.9001.90.camel@mattlaptop2.local> Date: Thu, 3 Feb 2011 21:21:51 -0800 X-Google-Sender-Auth: xRKHl7KQz1_zmVnTiU1NHej6WA4 Message-ID: From: Zack Weinberg To: Matt McCutchen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 05:18:29 -0000 On Thu, Feb 3, 2011 at 8:38 PM, Matt McCutchen wro= te: >> >> to indicate that 'www.example.com' provides HTTPS service with a >> particular key, but does not provide any other secured service. > > So a single TLSA RR with this sentinel value represents an exclusive > empty set? =C2=A0Sounds good to me. Yah. > If we support nonexclusive TLSA for individual services, we'll probably > want to refactor this to have RRs that just make positive endorsements > of certificates and a special RR that indicates exclusivity. =C2=A0Then, = no > TLSA RRs at all would mean no endorsements and no exclusivity. I'd rather keep that argument out of this thread, but at present I don't see a use case for nonexclusive. 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 E8A013A6850 for ; Thu, 3 Feb 2011 21:05:56 -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 TWO4rVJRFGut for ; Thu, 3 Feb 2011 21:05:56 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 044E13A6AF8 for ; Thu, 3 Feb 2011 21:05:56 -0800 (PST) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id F119725C062 for ; Thu, 3 Feb 2011 21:09:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=uAhzEm5KR+Z7lvz2i79/qfn2iBzHJbjEz64yS/5r7Sm bLiHshIz/drJTWQEvMj0XThIPP3/clIiLR6gM54QDv4HMRQLozm42p+sxwXrQsJM G5z4iMxpEVlhlDZ8plz/h5YZBjmonpCT3ZedMSHU4D0GWVsSFt+WN2vCYR+Y/4yk = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=l8gaTIkBML2KvBhYxrZ4qd2CCa8=; b=pBnttZjd2/ xxlw1kYlbagTvpAP+xroiySnLYODcmD6wLXsgcu1zwvmiSARNthMxq4qDLUpZBRd sDMVYTwKCyZaPdf6qR8GoGiF0yd0LuooxMf2Ba+A2GW4Ycvjsyi+BnvOgagwykrA RxADmV33MVXR81/hBNb2H0E+cZnqVHDFY= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPA id B1E2425C061 for ; Thu, 3 Feb 2011 21:09:19 -0800 (PST) From: Matt McCutchen To: keyassure@ietf.org In-Reply-To: <201102012242.p11MgRgJ025416@fs4113.wdf.sap.corp> References: <201102012242.p11MgRgJ025416@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Feb 2011 00:09:18 -0500 Message-ID: <1296796158.9001.112.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 05:05:57 -0000 On Tue, 2011-02-01 at 23:42 +0100, Martin Rex wrote: > Zack Weinberg wrote: > > > > > If there is a DANE record, then any wise client should interpret that > > > as an exclusive list of allowed TLS certificates > > > > I agree with this, but the question is how do you present an empty list. > > What exactly would you want to convey with an empty list? > > "I won't respond to TLS, so don't even bother trying" More precisely, "there is no TLS service associated with this DNS name/transport/port". Therefore, general-purpose clients that refer to TLS services by DNS name/transport/port will not be able to make a connection. This does not preclude the admin to run a TLS server for some special purpose, to accept connections only from specially configured clients, but in most cases it will make sense to use DANE. > The only time when such an information becomes interesting is when > you have a client with a strong desire to communicate with a target > and intent/preference for using TLS-protection on that communication. > > DANE-unaware clients will continue trying to use TLS. > What is your rationale for making DANE-aware clients exhibit > a different behaviour and entirely stop trying to use TLS? I assert that I do not offer the TLS service, so there is no point in DANE clients trying to connect to it. In particular, I do not want them to connect to some fake service with a certificate from a public CA. There is nothing I can do about the DANE-unaware clients. -- 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 ED2883A6AFF for ; Thu, 3 Feb 2011 20:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQAMUtnM3nC5 for ; Thu, 3 Feb 2011 20:34:44 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id E16C63A69FE for ; Thu, 3 Feb 2011 20:34:44 -0800 (PST) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 164E359806B for ; Thu, 3 Feb 2011 20:38:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=UUsIjNe9SICuseAb3XiWoHi+1UOGE3OHQkvf/T96kAP rhR2ghLxqJ74cyy7X30foA2DF4wlUxtPgdfCNqWK8zOJY7NRIZK8CNfKCq9T+Tb/ eje/arRpW6AzFBqxXT1hqf8/Jk68z2jFnru3NS7U/jpat69C29UfcX9ziAXdNd+E = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=7JKrmbb1Paa7p8IYUavj38adrzg=; b=B3A9wUlfMC tIjQ1D1WSCKK0cZVffcfLFinakp8u+8aIi700U5KZ1gvKsIrl4+gFn4Hezfm66uf zVNj9RQ5PFuby42Fw/Bv1OR2j5sTERaKWoeJPLc5wCTomyO3VN5lesZdET3IUjKs 2udA0HuORl7nWH8CoE9kfH0YQLQPGhPkg= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id D2B37598069 for ; Thu, 3 Feb 2011 20:38:08 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: References: <1296575340.1888.27.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 23:38:07 -0500 Message-ID: <1296794287.9001.90.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 04:34:46 -0000 On Tue, 2011-02-01 at 08:21 -0800, Zack Weinberg wrote: > It occurs to me that there is currently no such thing as a DANE record > that expresses "there are no TLS-secured services provided by this > domain name" (or "...by this port"). Maybe there should be one? I > suggest that the record with hash type 0, cert type 0, and zero bytes > of certificate data could have this meaning. Under the _nnn._tcp.host > proposal being discussed in the other thread, you could then have > > $ORIGIN example.com. > > www A w.x.y.z > _443._tcp.www TLSA ( 1 2 ...hash... ) > *.www TLSA ( 0 0 ) > > to indicate that 'www.example.com' provides HTTPS service with a > particular key, but does not provide any other secured service. So a single TLSA RR with this sentinel value represents an exclusive empty set? Sounds good to me. If we support nonexclusive TLSA for individual services, we'll probably want to refactor this to have RRs that just make positive endorsements of certificates and a special RR that indicates exclusivity. Then, no TLSA RRs at all would mean no endorsements and no exclusivity. -- 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 ED8293A6AFF for ; Thu, 3 Feb 2011 20:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 yl+4KpUA+4Nt for ; Thu, 3 Feb 2011 20:20:37 -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 097413A6B21 for ; Thu, 3 Feb 2011 20:20:37 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 2C9E063406C for ; Thu, 3 Feb 2011 20:24:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Q4HMWSunf7uWpp5odc4hMt+Uu20NDOhVuS0ZL7i8STX U5yFEPDwHtXos4t2+k9IEkbmrGnYPMsguECEvuKjB+jVoCxiYsZ9/U/90eETTIm0 xfIFZ0Bw05pbxYmhdGiH2xdEIXQwRRU4BY3qhHmnD8egdot8vVLClZNoENfeyYKM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=zxwW1injsweVN8bfJGXt+adtgJk=; b=s+FLUhCKU8 eNn0UMJcITroFys4m/ueFqRSlqLKfaS0vbLM6Y5hi5z4aXhKJ6Go49YC+sQr3AkP 7EOm8UpLQONCsYvqe69JWHM9RI/i0Nw2LPspn/u7FwyGL9BEW4hArdsAepAI7kb6 xGeTUfj4ezoUilZETXUBdOdfJUeF6SpBA= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id E8B52634064 for ; Thu, 3 Feb 2011 20:24:00 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <55625D32-1FFF-4D77-BE2A-7E673D8D0E99@kirei.se> References: <1296575340.1888.27.camel@mattlaptop2.local> <55625D32-1FFF-4D77-BE2A-7E673D8D0E99@kirei.se> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 23:23:59 -0500 Message-ID: <1296793439.9001.83.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 04:20:40 -0000 On Wed, 2011-02-02 at 08:31 +0100, Jakob Schlyter wrote: > On 1 feb 2011, at 16.49, Matt McCutchen wrote: > > > I would like to assert DANE exclusivity for the entire domain > > mattmccutchen.net so that, with respect to clients that check DANE first > > and fall back to a mainstream public CA list, a shady CA cannot > > impersonate my existing TLS services /or/ fabricate TLS services I do > > not offer. > > This sounds like the opposite of STS (Strict Transport Security), I don't follow. > i.e. policy and not key association distribution. Gah... Asserting TLSA exclusivity for an entire domain is not fundamentally different from asserting it for a single _port._transport.host, just grander in scale. It's equivalent to a thicket of wildcard exclusive TLSA records with empty certificate sets. Ultimately, any of these directives can be viewed as an assertion or a suggested policy. Of course clients can do as they wish; the idea is that the admin disclaims responsibility for anything bad that might happen to the client as a result of it not following the policy. -- 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 0C0E43A6A31 for ; Thu, 3 Feb 2011 20:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 P6FIVfv40iHE for ; Thu, 3 Feb 2011 20:12:12 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 21FCE3A6A16 for ; Thu, 3 Feb 2011 20:12:12 -0800 (PST) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 11D39208063 for ; Thu, 3 Feb 2011 20:15:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=QvsX/gSsoqAzT2CzDb2r90/nfDIPPVMPKkNN+jAC4ya gxyEguX1hVypwLgw27FdolIRqVmFdrsHuQPw4YmxS4LtotTZkj5udHXSqbclO6rJ XFglqDFiNBSWaOGQTw6uTwm5k2FRH1hjVY5lIdZa0L/VFJNxQz5cewrkO0SIAPvY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=1XHgCyOEZanO7/auHq6TqLT5elE=; b=buvzQkiq3n GH2t67HHWgfjyZ8GER5CD6V4PfNTdD5qkNQYKvvKYQQbMAoX7jEH+/quwnrY/NEH kR9cF1RrJufQtF6mX7RBoNwcMCwReqt/ZleYKpF4swVdL1+7B6DIPUdtz1pg328R oEYPnKSHjC6mePb6nSohyNtOsM3ZQ8beE= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id AC879208061 for ; Thu, 3 Feb 2011 20:15:35 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <20110203170245.GM23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 23:15:34 -0500 Message-ID: <1296792934.9001.78.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 04 Feb 2011 04:12:13 -0000 On Thu, 2011-02-03 at 12:02 -0500, Andrew Sullivan wrote: > there's also the fact > that it imposes load on a parent who ought not to need to participate > in most of this. Not any more than the DNSKEY RRset does. Either RRset will be cached by the ISP as soon as one client cares about 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 187673A6A11 for ; Thu, 3 Feb 2011 20:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 iZHkEjGTWKoA for ; Thu, 3 Feb 2011 20:07:52 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 1DD003A67C1 for ; Thu, 3 Feb 2011 20:07:52 -0800 (PST) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id E74FA70406E; Thu, 3 Feb 2011 20:11:15 -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=NYbmuJZxkCSLMkCzsKXs8LxnBr/ZLY58S1EDI7aVnz4 fneFVwniQTT14pDUaSciONpPTZGuJ8n8NKC5GMHsbXPcpXpo7shf5u3uBf1CDEHl 7miPxAJbI+Ouc2oi4Wl6qyARrqdva0KBnKnIbb9uW9HneHBLCWqKltNrWfM6NARo = 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=rxHmZY8eCvhaIwPuqsMZ9m+JBV8=; b=A1XXXbIoIx bxCiJJRf9/pYn8X2E3mbd+I7JlGkAdJdRlVJEctWVtGzg4S184nqpMj8La1RXq/p qe0oRyD/TFt6ktlRozPx6EJ0/S3+SwImWzHBtAo/aTbzbxoasAuW7OAq3UHM44Il UB3OYBabLSS+bvSueOZOntce7Zv4gN6Jc= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id 9A05170406A; Thu, 3 Feb 2011 20:11:15 -0800 (PST) From: Matt McCutchen To: James Cloos In-Reply-To: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 23:11:14 -0500 Message-ID: <1296792674.9001.75.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure 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, 04 Feb 2011 04:07:53 -0000 On Wed, 2011-02-02 at 15:56 -0500, James Cloos wrote: > >>>>> "MM" == Matt McCutchen writes: > > MM> I would just propose that the client check for CNAME at www.example.com > MM> or TLSA at _443._tcp.www.example.com in unspecified order (they should > MM> not both exist), and if a CNAME at www.example.com is found, query > MM> the prefixed version of the target name. The client would not honor > MM> a CNAME at _443._tcp.www.example.com. DNS admins who want to apply > MM> TLSA to a wildcard set of host names can use a wildcard CNAME first > MM> and then put the TLSA at the target name. > > Those are not awful. They probably make prefixes usable. > > (And perhaps should be used for existing SRV usages, too.) That's what I was hoping to achieve. I appreciate the vote of confidence. :) -- 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 6F77E3A6895 for ; Thu, 3 Feb 2011 17:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtMs0i8IzpBx for ; Thu, 3 Feb 2011 17:27:08 -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 93AFD3A659C for ; Thu, 3 Feb 2011 17:27:08 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 6ADE5634073; Thu, 3 Feb 2011 17:30:32 -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=MLrBR7dkzAHXftIh8u34i/Ym4Gt8Zlm4i12hmPfV9fT AMF/bjU7Y3JCAqqF+7Cs94q8+OWXfoFmwwxt62y9yacMznx8M2nH5bRNMSfb8j2z 5QDf8Q6BDAWIfJC9JJkcx4YddCU6mIVaoSGdroU9H5T06soTH/3ZN/pZs1v3pAP0 = 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=vVzcdoJ0R7m2U0hdRiXcZ1tfP/c=; b=RZPh5VE9kX Rgxy6qARuG7AFM1eTjC18FdjR6O1k6K2QHGBKUekxarfDkRlXr+GwNWCfbp5VtQg A/OTTORgeZGjUBwRAuVZkinlJPMQsmP7r7Rwq1KCvKm7oSMKqlvYJssrLtZFLnWC mU/nswu75H23yYz7BzVUv7/OydrCUm0fc= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 1F88863406F; Thu, 3 Feb 2011 17:30:32 -0800 (PST) From: Matt McCutchen To: Paul Wouters In-Reply-To: <1296782182.9001.22.camel@mattlaptop2.local> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> <1296782182.9001.22.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 20:30:30 -0500 Message-ID: <1296783030.9001.26.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure 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, 04 Feb 2011 01:27:09 -0000 On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote: > using the same certificate for multiple services at the > same name exposes you to cross-protocol attacks. To clarify: even if the services are at the same security level, the case in which a MITM diverts the connection to a service other than the one the client wanted should be caught at the TLS level. TLS is designed to be capable of providing a strong guarantee: if your connection goes through, you are talking to the service you wanted. Let's not weaken this by being sloppy with the naming. -- 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 954C13A68E7 for ; Thu, 3 Feb 2011 17:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 I6eOTWMeXsrp for ; Thu, 3 Feb 2011 17:13:00 -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 80E503A6A01 for ; Thu, 3 Feb 2011 17:13:00 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 18A7A63406E; Thu, 3 Feb 2011 17:16:24 -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=oG9q5H1ZHvdoXXFIEJkR/8qWGkqNbSSamEOUQs2BWIZ w0541qGDLIvAaiLz3469nBNrdkELBdJjV6XKoHIfPF3NEC/6AD0GVHZHuzpKhCym 7d3C472yPe1pPJP8LZrChpYZFQgMFDpQKOa4kqdhwyaMpxIAmgWLMVlJxfHW4R1k = 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=jM9pXmVMIRKnnvRN0PRi5f0j8Lk=; b=aF++fIfbES SphyKHVXPAlMsNKul+rXYu3ldQw9s4jbT/LfIlkGfUvoj+3ezM6OQ+GqGaLpi0XD h7bKc94knrpi/0joIOm9QCbPUEsJNXsgi8V87pMV5DJ4bvzkx+8DLy02hSe+z2M1 lw7a420b1K1ncoLkOezib3n8qvBt/5/1w= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id AA23C63406C; Thu, 3 Feb 2011 17:16:23 -0800 (PST) From: Matt McCutchen To: Paul Wouters In-Reply-To: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Feb 2011 20:16:22 -0500 Message-ID: <1296782182.9001.22.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: keyassure 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, 04 Feb 2011 01:13:01 -0000 On Tue, 2011-02-01 at 13:54 -0500, Paul Wouters wrote: > On Tue, 1 Feb 2011, Matt McCutchen wrote: > > > I am unhappy with 1a. I wouldn't like to build the assumption that > > ports at the same host name are at the same security level into DANE, > > insecure.example.com. IN A 1.2.3.4 > secure.example.com. IN A 1.2.3.4 > insecure.example.com. IN TLSA x snakeoilcert > secure.example.com. IN TLSA x securecert > > Now you have different security levels to the same host on 1.2.3.4, > without the added parsing/complexity/uglyness of _modifiers. - There is no parsing, only construction. The client gets a TLSA record back by virtue of constructing the _port._transport.host string the same way the DNS admin did when publishing the data. - I do not see what is complex or ugly about stating the transport protocol and port number your service listens on. This way, TLSA layers neatly onto our transport protocols to provide the abstraction of an authenticated (D)TLS connection over Foo Transport Protocol to an arbitrary (DNS name, port) pair; generic TLS tools such as stunnel can take advantage of this. In contrast, using subdomain names that are not standardized anywhere and thus liable to be chosen differently for the same service type (smtp.foo.com, mail.bar.com, ...) has the potential to be ugly, and using the same certificate for multiple services at the same name exposes you to cross-protocol attacks. If the admin does not want to type out the _port._transport.host format, surely there will be GUIs like the ones for port forwarding on home routers today that let him pick the transport protocol and service type (assuming the default port) from a menu. But I really don't think this is an imposition. -- 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 BEF1C3A6A46 for ; Thu, 3 Feb 2011 10:17:40 -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 ZslJWo7KHrH7 for ; Thu, 3 Feb 2011 10:17:39 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5CFE93A67B8 for ; Thu, 3 Feb 2011 10:17:39 -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 E4ED71ECB420 for ; Thu, 3 Feb 2011 18:21:01 +0000 (UTC) Date: Thu, 3 Feb 2011 13:20:59 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110203182059.GS23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> <20110203175654.GP23365@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) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 18:17:40 -0000 On Thu, Feb 03, 2011 at 01:08:00PM -0500, Phillip Hallam-Baker wrote: > There is a very strong probability that where there is a separation of > control, there will be a zone cut and a DS record. Well, yes and no. University environments are a good example here: some just do not delegate zones, period; but they do not assert tight administrative control over departments. The effect is that you have separation of control of hosts within department boundaries without zone cuts. That seems to me to be an important use case. The same can be true in some corporate environments, where zone cuts do not correspond very well with administrative control differences. I know some will regard these as artificial examples, but having worked under each I contend that they're real and ought to be considered. > The problem comes the other way, the fact that a DS record is encountered is > a much less reliable indicator of a separation of control. Also yes and no. In some ways, it's _necessarily_ a separation of control: the two sides of a zone cut are as a matter of protocol just independent. The protocol relies on the operators to make them agree. And anyway, a system that uses zone cuts as an indicator of control boundaries need not be a problem: the single operator of both sides already knows how to co-ordinate changes across the cut, so I don't see what the problem there could be. I think this is a red herring. > If something is going to be an administrative convenience rather than an > inconvenience, it has to work almost very close to 100% of the time and in > particular it must not introduce side effects to existing administration > procedures. I fully disagree with the latter claim. _By definition_ a new feature might introduce side effects to existing administration procedures. This is a matter of trade-off, and not one of necessity universally quantified. 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 BAC473A6A32 for ; Thu, 3 Feb 2011 10:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 c6ROpGHZEaHm for ; Thu, 3 Feb 2011 10:05:08 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 443EF3A698E for ; Thu, 3 Feb 2011 10:05:06 -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 59C76C55A; Thu, 3 Feb 2011 13:08:28 -0500 (EST) Date: Thu, 3 Feb 2011 13:08:28 -0500 (EST) From: Paul Wouters To: Nicholas Weaver In-Reply-To: Message-ID: References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> <20110203170437.GN23365@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] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 18:05:08 -0000 On Thu, 3 Feb 2011, Nicholas Weaver wrote: >> I browser should just be able to lookup a TLSA record from the validating >> localhost dns server, without any further knowledge of dnssec or DS records. > > I disagree, strongly. > > a) What APIs currently exist that would allow a TLSA record to be looked up rather than an A record. So new APIs are probably required anyway. > > b) It is the APPLICATION, not the resolver, that needs to know what to do if the DNSSEC portion of the TLSA record fails. > > Doing meaningful DNSSEC-using applications without getting the reason FOR a DNSSEC failure is asking for trouble. That should only be needed for error handling, not for regular succeeding lookups that return either the TLSA record or an NSEC*. Yes, the application will have to deal with various kind of ServFails, but in its regular operation it should just do a lookup, either get a TLSA record or not, and move on. This case surely should not depend on the application knowing about zone cuts or DS 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 59A363A6A5B for ; Thu, 3 Feb 2011 10:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.118, 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 xu4FnLZK2nVr for ; Thu, 3 Feb 2011 10:04:38 -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 E90523A698E for ; Thu, 3 Feb 2011 10:04:37 -0800 (PST) Received: by gxk27 with SMTP id 27so654290gxk.31 for ; Thu, 03 Feb 2011 10:08: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=KeaXivSxYB40fPouGfpbNiASb/S0ed5bgdjyCv4iUCI=; b=NJm2g69hQ9IRp+dmvJzBO4QkDf7sgGZzB8NSj88qTN/MyhHLCkTNK4Wm4+zweMDBpo ZjZoVan/fTnaBY66Lx7hxP/ZUGifJ+5uaBfKPQJ5lmrGNOMRYKiElPQYNKO3li1J1QQ1 G7DNpnVdR/jM/OFR5nWVrbTW4Osimw67E3vDg= 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=Q8w/q66L0ba+bEHZn6/Hyna3TQnRoG95xO1Psiz5l0Yx+5gtW0mv1afaAy4r5WYhlI 0b2y8ZceCAAjwF6WG28luYUOBx/GFjjY6fY8P/OFBGM75HzLIkMX8DrHInZ38WdqXhwY blFEKMdzVNItEgxFuy60ob+Y4B5ZU74kZOR3A= MIME-Version: 1.0 Received: by 10.100.195.12 with SMTP id s12mr7039366anf.18.1296756480569; Thu, 03 Feb 2011 10:08:00 -0800 (PST) Received: by 10.100.242.14 with HTTP; Thu, 3 Feb 2011 10:08:00 -0800 (PST) In-Reply-To: <20110203175654.GP23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> <20110203175654.GP23365@shinkuro.com> Date: Thu, 3 Feb 2011 13:08:00 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e644c630627150049b64a51f Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 18:04:39 -0000 --0016e644c630627150049b64a51f Content-Type: text/plain; charset=ISO-8859-1 There is a very strong probability that where there is a separation of control, there will be a zone cut and a DS record. The problem comes the other way, the fact that a DS record is encountered is a much less reliable indicator of a separation of control. If something is going to be an administrative convenience rather than an inconvenience, it has to work almost very close to 100% of the time and in particular it must not introduce side effects to existing administration procedures. On Thu, Feb 3, 2011 at 12:56 PM, Andrew Sullivan wrote: > On Thu, Feb 03, 2011 at 12:11:55PM -0500, Phillip Hallam-Baker wrote: > > One of the discoveries we made in DKIM was that ephemera such as zone > cuts > > that are visible at the resolver level cannot be relied on to be visible > at > > the client level. > > My memory of that discussion was rather that the DNS geeks kept saying > that zone cuts were a lousy thing to rely on, and you shouldn't do it. > But let's not fight that battle over again. > > > WG consensus that the group would rather prefer performance or certain > forms > > of administrative convenience than meeting these requirements is unlikely > to > > reflect IETF consensus. > > Agreed. But we actually _do_ have a reliable mechanism to detect zone > cuts here, because we _have to_ have one, because without DNSSEC this > entire scheme is a waste of time. The DS record establishes it. I am > not arguing that the zone cut is going to be visible to general > purpose clients, but surely a client that is doing the kind of work > we're talking about can be expected to be more sophisticated than > getaddrinfo(). > > > Crawling the root has been long established as a bad idea. > > Fully agree. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e644c630627150049b64a51f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is a very strong probability that where there is a separation of cont= rol, there will be a zone cut and a DS record.

The probl= em comes the other way, the fact that a DS record is encountered is a much = less reliable indicator of a separation of control.


If something is going to be an administrative= convenience rather than an inconvenience, it has to work almost very close= to 100% of the time and in particular it must not introduce side effects t= o existing administration procedures.


On Thu, Feb 3, 2011 at 1= 2:56 PM, Andrew Sullivan <ajs@shinkuro.com> wrote:
On Thu, Feb 03, 2011 at 12:11:55PM -0500, Phillip Hallam-= Baker wrote:
> One of the discoveries we made in DKIM was that ephemera such as zone = cuts
> that are visible at the resolver level cannot be relied on to be visib= le at
> the client level.

My memory of that discussion was rather that the DNS geeks kept sayin= g
that zone cuts were a lousy thing to rely on, and you shouldn't do it.<= br> But let's not fight that battle over again.

> WG consensus that the group would rather prefer performance or certain= forms
> of administrative convenience than meeting these requirements is unlik= ely to
> reflect IETF consensus.

Agreed. =A0But we actually _do_ have a reliable mechanism to detect z= one
cuts here, because we _have to_ have one, because without DNSSEC this
entire scheme is a waste of time. =A0The DS record establishes it. =A0I am<= br> not arguing that the zone cut is going to be visible to general
purpose clients, but surely a client that is doing the kind of work
we're talking about can be expected to be more sophisticated than
getaddrinfo().

> Crawling the root has been long established as a bad idea.

Fully agree.

A

--
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
_______________________________________________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e644c630627150049b64a51f-- 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 E19743A6A32 for ; Thu, 3 Feb 2011 10:02:12 -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 VSGz4LLvfPU1 for ; Thu, 3 Feb 2011 10:02:12 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 3E85F3A698E for ; Thu, 3 Feb 2011 10:02:12 -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 DDFC91ECB420 for ; Thu, 3 Feb 2011 18:05:34 +0000 (UTC) Date: Thu, 3 Feb 2011 13:05:33 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110203180533.GR23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> <20110203170437.GN23365@shinkuro.com> <20110203180443.GQ23365@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110203180443.GQ23365@shinkuro.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 18:02:13 -0000 On Thu, Feb 03, 2011 at 01:04:43PM -0500, Andrew Sullivan wrote: > The "zone cut" is not the criterion you want, and I assert that it is s/The/Then/. Sorry. -- 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 2D9FE3A6A33 for ; Thu, 3 Feb 2011 10:01:24 -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 iqWHN7XIzuHq for ; Thu, 3 Feb 2011 10:01:23 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2A3F53A6A32 for ; Thu, 3 Feb 2011 10:01:23 -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 3E3331ECB420 for ; Thu, 3 Feb 2011 18:04:45 +0000 (UTC) Date: Thu, 3 Feb 2011 13:04:43 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110203180443.GQ23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> <20110203170437.GN23365@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) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 18:01:24 -0000 On Thu, Feb 03, 2011 at 12:34:42PM -0500, Paul Wouters wrote: > I browser should just be able to lookup a TLSA record from the validating > localhost dns server, without any further knowledge of dnssec or DS records. The "zone cut" is not the criterion you want, and I assert that it is not possible to do anything interesting with the notion of zones for security. We've seen this over and over again. Either the zone cut is important, and you are willing to do the work to detect it reliably, or else inheritance in the DNS itself is not allowed for these security policies. I have repeatedly in the past suggested a sort of meta-info service about the DNS, where zones have the (signed) ability to return a location for policy informaiton. For instance, in this case, one would have SRV-or-whatever pointers off to the policy for a zone that says, "I assert policy for the following zones". The policy document is actually delivered via https or something like that. If and only if the asserted-for zone contains a (validatable) pointer to the same policy, then a client can accept that policy. This gets us out of the mess resulting from trying to infer anything from zone cuts. (The reason this is so general purpose is because it can have other uses too. Think of solving the cookies-in-a-domain problem and the IDNA2008 language-tables policy problems using the same mechanism, for starters.) Unfortunately, every time I have floated this idea, I have been told by application people that they won't use it because they don't have an interface, or because it's too many lookups and will take too long. This out of hand rejection has caused me never to bother to write the needed I-D. On the other hand, it has the conspicuous advantage that it would work where detecting zone cuts won't, which is why I continue to nurture it. If anyone thinks this is not-obviously-stupid now, I will write it up properly. 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 C9D2F3A6A45 for ; Thu, 3 Feb 2011 09:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 FqstSviv2z6e for ; Thu, 3 Feb 2011 09:57:34 -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 5FD7B3A69D9 for ; Thu, 3 Feb 2011 09:57:34 -0800 (PST) Received: by gwb20 with SMTP id 20so649434gwb.31 for ; Thu, 03 Feb 2011 10:00: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=mP0u2AM9h5CZH003EYA87m2rNLnEuhqy2Xuo34ZtIw8=; b=PS6wi5+7BItB02BNLD5W2Q9vA3aJV8Zz1U7ZrUJ8fTk7fwoLMpj63yvI0WuBxlZhyY cmJdeYCAHBj67UYsuXv7PiijU2KpEd2GSQhAFCFku/eskCC6ebxv46hSPAO8yDMDvHmc yoXtn1dxV56JhxMq0Jcd2br3+QCRtrOy7jG5U= 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=Fm6NNjdQQ4jfPH9RbqzfO5iRzuulpuGX8TfjjsYJ3eTl43Dcvti/nXUy26iEeM0AsJ 4vqcg2lAtsII/MU1DdjghAmQUEsk66H9G/JKU45UFj+wiHHE7WMbjW/iLqgYM6jRsqFL 6mXTECd7C4UZ/mtDQVjbwQjPtuCmoE6QAcAYA= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr6924786and.86.1296756056898; Thu, 03 Feb 2011 10:00:56 -0800 (PST) Received: by 10.100.242.14 with HTTP; Thu, 3 Feb 2011 10:00:56 -0800 (PST) In-Reply-To: References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> <20110203170437.GN23365@shinkuro.com> Date: Thu, 3 Feb 2011 13:00:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Nicholas Weaver Content-Type: multipart/alternative; boundary=0016e644c70821bdd2049b648c0c Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 17:57:35 -0000 --0016e644c70821bdd2049b648c0c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 3, 2011 at 12:39 PM, Nicholas Weaver wrote: > > On Feb 3, 2011, at 9:34 AM, Paul Wouters wrote: > > > On Thu, 3 Feb 2011, Andrew Sullivan wrote: > > > >> On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote: > >>> Right... but do DNSSEC client libraries make it easy to access this > >>> information without doing a separate query for the DS record? > >> > >> Client libraries are going to have to learn this if they're going to > >> do meaningful DNSSEC work. > > > > I browser should just be able to lookup a TLSA record from the validating > > localhost dns server, without any further knowledge of dnssec or DS > records. > > I disagree, strongly. > > a) What APIs currently exist that would allow a TLSA record to be looked > up rather than an A record. So new APIs are probably required anyway. > > b) It is the APPLICATION, not the resolver, that needs to know what to do > if the DNSSEC portion of the TLSA record fails. > > Doing meaningful DNSSEC-using applications without getting the reason FOR a > DNSSEC failure is asking for trouble. I think it is necessary to phrase the question in a different way. Instead of assuming that the existing API support is automatically going to improve to support DANE and like proposals, consider instead what applications are going to have to do to circumvent local DNS mechanisms and in what circumstances they should be able to do so. There are two cases of interest to me: 1) An enterprise user using a home machine 2) A home user attempting to gain unrestricted access to the world media regardless of government imposed censorship. In the first case the machine is owned by the enterprise and the enterprise has the right to decide that it does not want it to be connecting to random Internet sites that may be attempting to install malware or negatively impact productivity. Many enterprises do just that by deploying operating systems that allow them to impose configuration restrictions on applications. While certain regimes have attempted this approach to enforce political censorship, it is rather harder to impose. For example, the Iranian government operates what is essentially a warez site from which citizens can download software of their choice - together with government installed backdoors. In practice, it is rather hard to impose that degree of control on a machine that the consumer has acquired independently. Certainly the user is going to be very aware that the controls are being imposed. My view is that if we want to get clean access to the Internet DNS, applications are going to have to be prepared to use libraries that are designed to route around port 53 restrictions if that is what it takes. -- Website: http://hallambaker.com/ --0016e644c70821bdd2049b648c0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 3, 2011 at 12:39 PM, Nichola= s Weaver <nweaver@icsi.berkeley.edu> wrote:

On Feb 3, 2011, at 9:34 AM, Paul Wouters wrote:

> On Thu, 3 Feb 2011, Andrew Sullivan wrote:
>
>> On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote: >>> Right... but do DNSSEC client libraries make it easy to access= this
>>> information without doing a separate query for the DS record?<= br> >>
>> Client libraries are going to have to learn this if they're go= ing to
>> do meaningful DNSSEC work.
>
> I browser should just be able to lookup a TLSA record from the validat= ing
> localhost dns server, without any further knowledge of dnssec or DS re= cords.

I disagree, strongly.

a) =A0What APIs currently exist that would allow a TLSA record to be looked= up rather than an A record. =A0So new APIs are probably required anyway.
b) =A0It is the APPLICATION, not the resolver, that needs to know what to d= o if the DNSSEC portion of the TLSA record fails.

Doing meaningful DNSSEC-using applications without getting the reason FOR a= DNSSEC failure is asking for trouble.

I th= ink it is necessary to phrase the question in a different way. Instead of a= ssuming that the existing API support is automatically going to improve to = support DANE and like proposals, consider instead what applications are goi= ng to have to do to circumvent local DNS mechanisms and in what circumstanc= es they should be able to do so.

There are two cases of interest to me:

1) An enterprise user using a home machine

2) A home user attempting to gain unrestricted access to the world media = regardless of government imposed censorship.


In the first case the machine is owned b= y the enterprise and the enterprise has the right to decide that it does no= t want it to be connecting to random Internet sites that may be attempting = to install malware or negatively impact productivity. Many enterprises do j= ust that by deploying operating systems that allow them to impose configura= tion restrictions on applications.

While certain regimes have attempted this approach to e= nforce political censorship, it is rather harder to impose. For example, th= e Iranian government operates what is essentially a warez site from which c= itizens can download software of their choice - together with government in= stalled backdoors.

In practice, it is rather hard to impose that degree of= control on a machine that the consumer has acquired independently. Certain= ly the user is going to be very aware that the controls are being imposed.<= /div>

=A0
My view is that if we want to get clean a= ccess to the Internet DNS, applications are going to have to be prepared to= use libraries that are designed to route around port 53 restrictions if th= at is what it takes.




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

--0016e644c70821bdd2049b648c0c-- 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 4DB513A6A18 for ; Thu, 3 Feb 2011 09:53:35 -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 XrwUoO+G3q67 for ; Thu, 3 Feb 2011 09:53:34 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6EC3F3A69D9 for ; Thu, 3 Feb 2011 09:53:34 -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 EE88C1ECB420 for ; Thu, 3 Feb 2011 17:56:56 +0000 (UTC) Date: Thu, 3 Feb 2011 12:56:55 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110203175654.GP23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@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) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 17:53:35 -0000 On Thu, Feb 03, 2011 at 12:11:55PM -0500, Phillip Hallam-Baker wrote: > One of the discoveries we made in DKIM was that ephemera such as zone cuts > that are visible at the resolver level cannot be relied on to be visible at > the client level. My memory of that discussion was rather that the DNS geeks kept saying that zone cuts were a lousy thing to rely on, and you shouldn't do it. But let's not fight that battle over again. > WG consensus that the group would rather prefer performance or certain forms > of administrative convenience than meeting these requirements is unlikely to > reflect IETF consensus. Agreed. But we actually _do_ have a reliable mechanism to detect zone cuts here, because we _have to_ have one, because without DNSSEC this entire scheme is a waste of time. The DS record establishes it. I am not arguing that the zone cut is going to be visible to general purpose clients, but surely a client that is doing the kind of work we're talking about can be expected to be more sophisticated than getaddrinfo(). > Crawling the root has been long established as a bad idea. Fully agree. 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 0D02F3A6A37 for ; Thu, 3 Feb 2011 09:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 B4E5RlRO5S-b for ; Thu, 3 Feb 2011 09:35:57 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id 419453A6A32 for ; Thu, 3 Feb 2011 09:35:57 -0800 (PST) Received: from gala.icsi.berkeley.edu (gala.ICSI.Berkeley.EDU [192.150.186.168]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 4666036A405; Thu, 3 Feb 2011 09:39:20 -0800 (PST) References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> <20110203170437.GN23365@shinkuro.com> 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: Thu, 3 Feb 2011 09:39:20 -0800 To: Paul Wouters X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 17:35:58 -0000 On Feb 3, 2011, at 9:34 AM, Paul Wouters wrote: > On Thu, 3 Feb 2011, Andrew Sullivan wrote: >=20 >> On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote: >>> Right... but do DNSSEC client libraries make it easy to access this >>> information without doing a separate query for the DS record? >>=20 >> Client libraries are going to have to learn this if they're going to >> do meaningful DNSSEC work. >=20 > I browser should just be able to lookup a TLSA record from the = validating > localhost dns server, without any further knowledge of dnssec or DS = records. I disagree, strongly. a) What APIs currently exist that would allow a TLSA record to be = looked up rather than an A record. So new APIs are probably required = anyway. b) It is the APPLICATION, not the resolver, that needs to know what to = do if the DNSSEC portion of the TLSA record fails. Doing meaningful DNSSEC-using applications without getting the reason = FOR a DNSSEC failure is asking for trouble. 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 7453C3A6A38 for ; Thu, 3 Feb 2011 09:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 WkHvkA4w1T-6 for ; Thu, 3 Feb 2011 09:31:22 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 95FB83A6A32 for ; Thu, 3 Feb 2011 09:31:22 -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 9D2E8C541; Thu, 3 Feb 2011 12:34:43 -0500 (EST) Date: Thu, 3 Feb 2011 12:34:42 -0500 (EST) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20110203170437.GN23365@shinkuro.com> Message-ID: References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> <20110203170437.GN23365@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] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 17:31:23 -0000 On Thu, 3 Feb 2011, Andrew Sullivan wrote: > On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote: >> Right... but do DNSSEC client libraries make it easy to access this >> information without doing a separate query for the DS record? > > Client libraries are going to have to learn this if they're going to > do meaningful DNSSEC work. I browser should just be able to lookup a TLSA record from the validating localhost dns server, without any further knowledge of dnssec or DS 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 D6E633A69D7 for ; Thu, 3 Feb 2011 09:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.118, 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 o+fYVqUGsmPo for ; Thu, 3 Feb 2011 09:08:32 -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 851303A687D for ; Thu, 3 Feb 2011 09:08:32 -0800 (PST) Received: by yie19 with SMTP id 19so632650yie.31 for ; Thu, 03 Feb 2011 09:11:55 -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=y9gqQa0+lNIdx0UdgGD3uISf6kfcjHQqjpvH8hlGgpY=; b=XNgUoMqx1NtZuXNkoBZl3SWFJ6n2lAVot383TRfeYK9L87wDivD8sTETWxLPGKxez0 kcGCXnHoemw+e4h8N3xnwbAApFgjGCz1hF1o7SADelaKEQBuS2P9muWBMYxVImFzfnfh 92XS1YK/HvYe5dooQ4goWp118zD+TGhPKc2T4= 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=IG7g54LgLA6FSnsNhBdXXATs2vWQFdCP4BHtJZqfLcrf14Xh4Oosutd2ipnYIhAOVO kOloVcBfz5DKuHr1f58At+z32bwdeUM1a/M5v43IdpHkruwWv9N5JX+Txix6ElBNhJlq UJZGGgrzEArAdIO1VB1OAz3o0+PO9lK1Jsrdg= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr6890542and.86.1296753115093; Thu, 03 Feb 2011 09:11:55 -0800 (PST) Received: by 10.100.242.14 with HTTP; Thu, 3 Feb 2011 09:11:55 -0800 (PST) In-Reply-To: <20110203170245.GM23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <20110203170245.GM23365@shinkuro.com> Date: Thu, 3 Feb 2011 12:11:55 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e644c708c959bf049b63dc00 Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 17:08:33 -0000 --0016e644c708c959bf049b63dc00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 3, 2011 at 12:02 PM, Andrew Sullivan wrote: > On Wed, Feb 02, 2011 at 09:36:31AM +0100, Ond=C5=99ej Sur=C3=BD wrote: > > > The crawling up to the root is a call for serious problems. > > Apart from all the good reasons Ond=C5=99ej mentions, there's also the fa= ct > that it imposes load on a parent who ought not to need to participate > in most of this. > One of the discoveries we made in DKIM was that ephemera such as zone cuts that are visible at the resolver level cannot be relied on to be visible at the client level. As a general architectural principle, there has to be orthogonality in the design of a key distribution mechanism. In particular * Deployment in a sub zone must not affect the parent * Deployment in a parent must not affect a sub zone unless this is explicitly desired. * Deployment for protocol X must not cause applications to reject valid key= s for protocol Y unless this is explicitly desired. * Deployment for protocol X must not create a key that applications will accept for protocol Y unless this is explicitly desired. These are exactly the type of architectural principles that people look towards the IESG and IAB to enforce. WG consensus that the group would rather prefer performance or certain form= s of administrative convenience than meeting these requirements is unlikely t= o reflect IETF consensus. Crawling the root has been long established as a bad idea. --=20 Website: http://hallambaker.com/ --0016e644c708c959bf049b63dc00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 3, 2011 at 12:02 PM, Andrew = Sullivan <ajs@shin= kuro.com> wrote:
On Wed, Feb 02, 2011 at 09:36:31AM +0100, Ond=C5=99ej Sur= =C3=BD wrote:

> The crawling up to the root is a call for serious problems.

Apart from all the good reasons Ond=C5=99ej mentions, there's als= o the fact
that it imposes load on a parent who ought not to need to participate
in most of this.

One of the discoveries= we made in DKIM was that ephemera such as zone cuts that are visible at th= e resolver level cannot be relied on to be visible at the client level.


As a general architectural principle, th= ere has to be orthogonality in the design of a key distribution mechanism. = In particular

* Deployment in a sub zone must not = affect the parent

* Deployment in a parent must not affect a sub zone unl= ess this is explicitly desired.

* Deployment for p= rotocol X must not cause applications to reject valid keys for protocol Y u= nless this is explicitly desired.

* Deployment for protocol X must not create a key that = applications will accept for protocol Y unless this is explicitly desired.<= /div>


These are exactly the type of archi= tectural principles that people look towards the IESG and IAB to enforce.

WG consensus that the group would rather prefer perform= ance or certain forms of administrative convenience than meeting these requ= irements is unlikely to reflect IETF consensus.


Crawling the root has been long established as a bad id= ea.

--
Website: http://hal= lambaker.com/

--0016e644c708c959bf049b63dc00-- 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 8F7FF3A699A for ; Thu, 3 Feb 2011 09:01: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 NQ0UmS032I3H for ; Thu, 3 Feb 2011 09:01:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id BF0153A69D5 for ; Thu, 3 Feb 2011 09:01: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 413621ECB420 for ; Thu, 3 Feb 2011 17:04:39 +0000 (UTC) Date: Thu, 3 Feb 2011 12:04:37 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110203170437.GN23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1296688716.2621.20.camel@mattlaptop2.local> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 17:01:17 -0000 On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote: > Right... but do DNSSEC client libraries make it easy to access this > information without doing a separate query for the DS record? Client libraries are going to have to learn this if they're going to do meaningful DNSSEC work. I understand and sympathize with the desire to make the DNS a perfect black box, but if applications want to do interesting things with DNS data, they're going to have to become something less than agnostic about what that data is. 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 8D4323A69D7 for ; Thu, 3 Feb 2011 08:59:27 -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 o5dnvpYy60au for ; Thu, 3 Feb 2011 08:59:25 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 608903A699F for ; Thu, 3 Feb 2011 08:59:25 -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 044051ECB420 for ; Thu, 3 Feb 2011 17:02:46 +0000 (UTC) Date: Thu, 3 Feb 2011 12:02:45 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110203170245.GM23365@shinkuro.com> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D49178F.9060308@nic.cz> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 16:59:27 -0000 On Wed, Feb 02, 2011 at 09:36:31AM +0100, OndÅ™ej Surý wrote: > The crawling up to the root is a call for serious problems. Apart from all the good reasons OndÅ™ej mentions, there's also the fact that it imposes load on a parent who ought not to need to participate in most of this. 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 99E563A69ED for ; Thu, 3 Feb 2011 08:42:57 -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.038, 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 8L108LJSmQlb for ; Thu, 3 Feb 2011 08:42:56 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 3AA2C3A69CF for ; Thu, 3 Feb 2011 08:42:56 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id AF4254011E; Thu, 3 Feb 2011 16:45:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296751577; bh=R5QpzjTjuITotxwiv4rtZXkKHen/8XscfvekY5Ecm5o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=iXl3A00Y+FqohlIJXOYyDTvgytsXQO6evuVvLKyZRQFK6qfCFVYVyFT8iLVUDv9V0 XYJdEp1K+b6fZOQRA15CH4Abf0vT/0dN0snXWg3dfjVcTQXmLPOJNCyWKmkrUtGu9c FCiLg9A3hijHtDEBmxK90McqVFdIDe8auWt1nUwk= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id BE892360038; Thu, 3 Feb 2011 16:45:05 +0000 (UTC) From: James Cloos To: Matt McCutchen In-Reply-To: <1296688716.2621.20.camel@mattlaptop2.local> (Matt McCutchen's message of "Wed, 02 Feb 2011 18:18:36 -0500") References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> <1296688716.2621.20.camel@mattlaptop2.local> 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: Thu, 03 Feb 2011 11:45:05 -0500 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110203:matt@mattmccutchen.net::sgz5/1UoIYiWXYLC:000000000000000000000000000000000000004w8B3 X-Hashcash: 1:30:110203:keyassure@ietf.org::fO2bQbANwWkG/lBS:0000000000000000000000000000000000000000008o2v6 Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 03 Feb 2011 16:42:57 -0000 >>>>> "MM" == Matt McCutchen writes: >> Since we rely on DNSSEC anyway, DS records are the ideal way to >> determine zone cut points. They are grabbed anyway as a matter >> of course and provide all the clue required. MM> Right... but do DNSSEC client libraries make it easy to access this MM> information without doing a separate query for the DS record? Even if they do not, the resolver had to grab the DS as part of the validation, so the round trip for an extra DS lookup by the end client is by definition local, often even same-process. -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 EB9743A6903 for ; Thu, 3 Feb 2011 07:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC9g6QJrwoF4 for ; Thu, 3 Feb 2011 07:06:16 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id 77FF73A695D for ; Thu, 3 Feb 2011 07:06:16 -0800 (PST) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p13F9cOk012245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 3 Feb 2011 16:09:38 +0100 Received: from [192.168.129.39] (192.168.129.39) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Thu, 3 Feb 2011 16:09:38 +0100 Message-ID: <4D4AC548.1080903@sidn.nl> Date: Thu, 3 Feb 2011 16:10:00 +0100 From: Antoin Verschuren 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: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> <4D4AA4E3.1030708@sidn.nl> <4D4ABBA3.5070400@vpnc.org> In-Reply-To: <4D4ABBA3.5070400@vpnc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="UTF-8" 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: Thu, 03 Feb 2011 15:06:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03-02-11 15:28, Paul Hoffman wrote: > Just to be clear: are you proposing that TLSA records can *only* be > returned in SRV requests, and that they can't be requested on their own > using "_port._protocol.host.tld TLSA"? I was only comparing the "_port._protocol.host.tld" vs the "hostname per service offered" as solution for the question OndÅ™ej originally asked about which QNAME to use. Which RRTYPE to use is the next question OndÅ™ej is going to pose I believe: "I was planning to open separate issue# on what to include into DNS name after we get consensus on that we want to have solution based on prefix+hostname in QNAME. As opposed to just having hostname in QNAME, or some interaction with SRV record. I felt that if we slowly narrow the topic it will not divert that much in the mailing list." - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNSsVDAAoJEDqHrM883AgnqYYIAI96F2bRQUlfUez6iD4eG2y3 xouTpbDN405jomibRKrkL+6DHrs3t3MJDWCHqPao2OUKU0f/ru1mzzt3m/fvjWNO yrTNOzwVmoX7GwnEkBvDYVim2GNZ8u99jTpps7Aq/QLbAJX6MP+qni25RPTemfDr UTzN1e+vzhH81Vu5KF1UyxtWXm7odHj4fG1o9IE4i7LKBMCXkpfUB4CjJpIAr8ib TXf9LzHKpuwMCLwY9V7O2j9etj8u++kB92atcJNM1POOH84fGDFDF1/gE9zydxYj hoPbqheKlxLqqkMhLDJa/s6GGoLQ8wqow9JwzLtM3M6MRFR3HcupD1FpvE0fRik= =vz3t -----END PGP SIGNATURE----- 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 ACF553A6974 for ; Thu, 3 Feb 2011 06:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=0.290, 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 MCflXrAAY9Gi for ; Thu, 3 Feb 2011 06:25:30 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 06D4F3A690B for ; Thu, 3 Feb 2011 06:25: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 p13ESpDH055391 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 3 Feb 2011 07:28:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D4ABBA3.5070400@vpnc.org> Date: Thu, 03 Feb 2011 06:28: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: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> <4D4AA4E3.1030708@sidn.nl> In-Reply-To: <4D4AA4E3.1030708@sidn.nl> 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: Thu, 03 Feb 2011 14:25:30 -0000 On 2/3/11 4:51 AM, Antoin Verschuren wrote: > Thinking over it, and hearing the answers, I think I'd vote for the > > _port._protocol.host.tld SRV > > solution. > My rationale: > Everything can be configured both for single hostnames and multiple > ones, but it takes less records in a zone for this sulution compared to > the TLSA solution. > > "good looks", "ugliness" or "readability" are no criteria for me. > Smaller size of the zone is. > > For the SRV solution, I only need 1 A and 2 SRV records makes 3. > For the TLSA sollution, I need 2 A and 2 TLSA records makes 4. Just to be clear: are you proposing that TLSA records can *only* be returned in SRV requests, and that they can't be requested on their own using "_port._protocol.host.tld TLSA"? 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 0FEEB3A6901 for ; Thu, 3 Feb 2011 04:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ceKInsLtczK for ; Thu, 3 Feb 2011 04:48:15 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id CDB8F3A6957 for ; Thu, 3 Feb 2011 04:48:11 -0800 (PST) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p13CpVLf009774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 3 Feb 2011 13:51:31 +0100 Received: from [192.168.129.39] (192.168.129.39) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Thu, 3 Feb 2011 13:51:25 +0100 Message-ID: <4D4AA4E3.1030708@sidn.nl> Date: Thu, 3 Feb 2011 13:51:47 +0100 From: Antoin Verschuren 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: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" 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: Thu, 03 Feb 2011 12:48:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01-02-11 19:54, Paul Wouters wrote: > On Tue, 1 Feb 2011, Matt McCutchen wrote: > >> I am unhappy with 1a. I wouldn't like to build the assumption that >> ports at the same host name are at the same security level into DANE, > > insecure.example.com. IN A 1.2.3.4 > secure.example.com. IN A 1.2.3.4 > insecure.example.com. IN TLSA x snakeoilcert > secure.example.com. IN TLSA x securecert > > Now you have different security levels to the same host on 1.2.3.4, > without the added parsing/complexity/uglyness of _modifiers. Hmm, and what's the canonical hostname for 1.2.3.4 in this case ? Thinking over it, and hearing the answers, I think I'd vote for the _port._protocol.host.tld SRV solution. My rationale: Everything can be configured both for single hostnames and multiple ones, but it takes less records in a zone for this sulution compared to the TLSA solution. "good looks", "ugliness" or "readability" are no criteria for me. Smaller size of the zone is. For the SRV solution, I only need 1 A and 2 SRV records makes 3. For the TLSA sollution, I need 2 A and 2 TLSA records makes 4. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNSqTjAAoJEDqHrM883Agn4/kH/Rzk22knNkIV89wZenVTDA9D khBefTQORbHqVQyf362zCs616yQeIH5N/Pg9nM/1A2goWnse9OIDRAus8pUCIJzC mMl9sHSYpu30pzX7ww8HRqbVU64sEtJ4aGeb/nK2rN6ORDSmLKEZU27jOxOMcMFd EbItKTyOgTGc7ecOz2kcuniNPcOHlk7SvYvd9uNXG2AZlv2uF8cXzs7TjdTfv8f5 eYsfIiTOGs+S4JyOW2IWKW3i+R0SG74VEBUN4UlzihHm887KdWw81J21Qnddxi3w YfYpx5bVIlNig3kiypmXdSxrRqQjSGMWtwCh9ZZhVIHikFILndhwt3mqLPt8G64= =4f/+ -----END PGP SIGNATURE----- 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 339793A6C80 for ; Wed, 2 Feb 2011 15:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 zf2R3mOkgtsF for ; Wed, 2 Feb 2011 15:24:50 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 783B13A6BC2 for ; Wed, 2 Feb 2011 15:24:50 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 5956E51C063 for ; Wed, 2 Feb 2011 15:28:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=c3ckhH5YYkn+/cjTpMVC7z/uH4dBgZsoZJHgosM8OsI i5bLE1DqHZsqMxEMJ6yxKgUqoOhmpzXXm9Uq+DDYCrVVNJ3V34u4C1DiKVaBWR3Q tF1isgeT2G20l1FMODbzNgpmP67rtcmiCE6gyDUodXY5V2nYckO40Lpr4D65oSF8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=cDqc2XSSnoyz7fn0WpPBrW8KGis=; b=iiCOMYmMQ0 b+ttN0z++kqfrDB21PRmcUhFJ3JHBSpj/nDzQEwd/1CyfJfVFZVMQGUWbAOqIWmu k1TN8kfC6zDj943m3CkJTekUzR+BV5M4LIdB4pS/7rpwqBiYIkfPDORVPkFb5pGS M7yoVpV5jYea+5bU3v4gAl3rEawPbVYFI= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id 22A7A51C062 for ; Wed, 2 Feb 2011 15:28:11 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: References: <1296575340.1888.27.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Feb 2011 18:28:09 -0500 Message-ID: <1296689290.2621.28.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 02 Feb 2011 23:24:51 -0000 On Tue, 2011-02-01 at 11:10 -0500, Phillip Hallam-Baker wrote: > Let us assume that you are signing your domain with DNSSEC. > > It follows that clients will be able to determine with certainty that > a specific subdomain does not exist. > > Thus it will be impossible for a client to obtain a valid A record or > SRV record or any other record that would enable a connection to be > made. Excellent point, but I can think of two cases in which this assumption fails: - Using an HTTP proxy - In XMPP server-to-server communication, authenticating the client of the connection More broadly, people have developed the mindset and expectation that no matter how they make a connection, authenticated TLS will cover their backs. So I think the assumption you propose is fragile; I don't wish to make it. It doesn't buy much in terms of reducing the number of wildcard records needed, either. -- 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 43CE73A6BC2 for ; Wed, 2 Feb 2011 15:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 WZlrBqJX-T8i for ; Wed, 2 Feb 2011 15:15:17 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 5EB2E3A6864 for ; Wed, 2 Feb 2011 15:15:17 -0800 (PST) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 3E2C751C06C for ; Wed, 2 Feb 2011 15:18:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Vp+EbRKQ2Tn0ag6ahe22s+6b2GyBBXjKTW95RSb5Qv5 s8+29aSYhnGOnt0j42kgzijwlrF+facG9nu0dV68+YM4O2pyp0CmE33yRWEYXOft kPXujv/ZNSuVx1KdAsKxdOQfyHv9UbLbgVfsVT+sPT/3JsmdCfyNhGdhy4JD41rY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=969Bc9AIKGZyAtP+4TQgWQCKS30=; b=FNiGBMUyBV Bfv5gptNyDZDNp0HbJ370/vrk69nE98gM4F/RNWP0AvMsaJ2kHGqH71zJZsGG+bL fJLHyddvpYfUQ3BD1t1FXMeeW55MizfPI+2eDIh4s8j4BZY9/CLXBneb2suH1qWn lmyz4sR5xGgQslYlf2IphlAqYlf8VvcQ4= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id F31E451C062 for ; Wed, 2 Feb 2011 15:18:37 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Feb 2011 18:18:36 -0500 Message-ID: <1296688716.2621.20.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 02 Feb 2011 23:15:18 -0000 On Wed, 2011-02-02 at 15:58 -0500, James Cloos wrote: > >>>>> "MM" == Matt McCutchen writes: > > MM> If there is an easy way to stop at a zone cut (e.g., by detecting > MM> the SOA record), that would be fine. > > Since we rely on DNSSEC anyway, DS records are the ideal way to > determine zone cut points. They are grabbed anyway as a matter > of course and provide all the clue required. Right... but do DNSSEC client libraries make it easy to access this information without doing a separate query for the DS record? -- 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 5BF4B3A6DBD for ; Wed, 2 Feb 2011 13:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmPOM6I5UGXM for ; Wed, 2 Feb 2011 13:00:39 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id F1C6D3A6DB7 for ; Wed, 2 Feb 2011 13:00:38 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id D04AE400EC; Wed, 2 Feb 2011 21:03:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296680638; bh=Z0xw6MR4LBP/3Hb+f5H+Mk+ZllPJYsS4enodbX6HeHo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mIclqt5kyM69V2qOZnNfin310QLt85ofMtZC3fVsvIxhq16IyV85LqY+Q3RDyl6gJ Z0EF8oaVp38ucekhfzT3K+Es8wOfyIFaIy5XIJQhTilMw2KKNeIX+BfOns7bOE3W91 dAz7RBq61xltU+xptDBOm8tOSBlFg2ufaQkNFQ5U= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id 24D89360029; Wed, 2 Feb 2011 20:58:24 +0000 (UTC) From: James Cloos To: Matt McCutchen In-Reply-To: <1296657079.1889.8.camel@mattlaptop2.local> (Matt McCutchen's message of "Wed, 02 Feb 2011 09:31:19 -0500") References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> <1296657079.1889.8.camel@mattlaptop2.local> 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: Wed, 02 Feb 2011 15:58:24 -0500 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110202:matt@mattmccutchen.net::3AmlpTwIR02+cb2p:00000000000000000000000000000000000000D2AHl X-Hashcash: 1:30:110202:keyassure@ietf.org::au9tTCz1tsEhxU0K:000000000000000000000000000000000000000000EKdVF Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 02 Feb 2011 21:00:40 -0000 >>>>> "MM" == Matt McCutchen writes: MM> If there is an easy way to stop at a zone cut (e.g., by detecting MM> the SOA record), that would be fine. Since we rely on DNSSEC anyway, DS records are the ideal way to determine zone cut points. They are grabbed anyway as a matter of course and provide all the clue required. -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 C92CA3A6D37 for ; Wed, 2 Feb 2011 12:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 sp95qHz3OHS9 for ; Wed, 2 Feb 2011 12:58:11 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id 7F5233A6C42 for ; Wed, 2 Feb 2011 12:58:11 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 03A1F400EC; Wed, 2 Feb 2011 21:01:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296680491; bh=1qTCmYLazlaYcJ8hfzhYPOh5nNt9vgxL2SOyubmijgo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MkxkHznQtH5HqAeFEB/8CKcBdNg0IZcnAZGKQ9zXtnC3W0BQYm9+hBv9T05wxjYgS 0YAmKurZ7SPRNJl4ls/ZSoxLoyx0Nm3XSO0y2UebQBwBk6y4ybwutbW/lhnxrz1kcM lZYVLgilHTyps0XRGBV6HjLy0iHz40Zcy+X22+Ac= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id D654E360029; Wed, 2 Feb 2011 20:56:29 +0000 (UTC) From: James Cloos To: Matt McCutchen In-Reply-To: <1296568884.2012.39.camel@mattlaptop2.local> (Matt McCutchen's message of "Tue, 01 Feb 2011 09:01:23 -0500") References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.camel@mattlaptop2.local> 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: Wed, 02 Feb 2011 15:56:29 -0500 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:110202:matt@mattmccutchen.net::L/uEVYCIKQEKBUbJ:00000000000000000000000000000000000000aLa4D X-Hashcash: 1:30:110202:keyassure@ietf.org::kMdNYEwjGBGaepck:000000000000000000000000000000000000000000f2mwu Cc: keyassure 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: Wed, 02 Feb 2011 20:58:12 -0000 >>>>> "MM" == Matt McCutchen writes: MM> I would just propose that the client check for CNAME at www.example.com MM> or TLSA at _443._tcp.www.example.com in unspecified order (they should MM> not both exist), and if a CNAME at www.example.com is found, query MM> the prefixed version of the target name. The client would not honor MM> a CNAME at _443._tcp.www.example.com. DNS admins who want to apply MM> TLSA to a wildcard set of host names can use a wildcard CNAME first MM> and then put the TLSA at the target name. Those are not awful. They probably make prefixes usable. (And perhaps should be used for existing SRV usages, too.) -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 647CE3A6D1D for ; Wed, 2 Feb 2011 12:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 Qs5iDGqbzTuy for ; Wed, 2 Feb 2011 12:34:02 -0800 (PST) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by core3.amsl.com (Postfix) with ESMTP id DF6623A6D07 for ; Wed, 2 Feb 2011 12:34:01 -0800 (PST) Received: by eagle.jhcloos.com (Postfix, from userid 10) id AD4C34012D; Wed, 2 Feb 2011 20:36:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1296679039; bh=7twHjM+VmEbdL2ulTZaIdS/TRI0AhP/fqj0gLt0SO3M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=E0u5Xv20ORWbuaXjF0SKQlRuAxnqOe2Ie2zGXEv8iYB069qQu6aSLXpAIc9o0ZXiU 0y8z9GbIFzFby+viBOjUgKf/ih5B/rgIyDZ/TGnZpZCfV7JASHvW0V2r4uVo8zcE2L axndxN1DIBvFeqoQoWJPGP+swBBtldMWr0hG8tfE= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id D6D1236002B; Wed, 2 Feb 2011 20:30:26 +0000 (UTC) From: James Cloos To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= In-Reply-To: <4D481576.3040008@nic.cz> (=?utf-8?Q?=22Ond=C5=99ej_Sur=C3=BD?= =?utf-8?Q?=22's?= message of "Tue, 01 Feb 2011 15:15:18 +0100") References: <4D481576.3040008@nic.cz> 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: Wed, 02 Feb 2011 15:30:26 -0500 Message-ID: Lines: 59 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:110202:ondrej.sury@nic.cz::QY4/z0izAk477TEG:0000000000000000000000000000000000000000001DglT X-Hashcash: 1:30:110202:keyassure@ietf.org::onrb1WmOSX4R+qmw:0000000000000000000000000000000000000000000FSQu Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 20:34:04 -0000 >>>>> "OS" == OndÅ™ej Surý writes: OS> The consensus would be that the draft-dane-protocol would define OS> lookup on TLSA records as query for a name prefixed with a port or OS> port and proto. I've read through this entire thread and remain undecided on your (narrow) question. As Phillip pointed out again, using prefixes precludes CNAME and wildcard RRs. That strongly suggests avoiding prefixes. But differentialtion is also necessary. What it comes down to is the need for a discovery mechanism. My suggesting to use NAPTR lookups returned only negative replies. Unfortunate, since that is the optimal solution to all of the discovery needs discussed on this list. That leaves two options that I can see. The DANE RR would need to encode the details for all possible uses at that name. A lookup for example.com. could return an RR which says: * Use cert A for traffic on tcp/sctp port 80 * Use cert B for traffic on tcp port 443 * Use cert C for traffic on tcp port 25 * Use cert C for traffic on tcp port 143 * Use cert D for traffic on tcp/sctp/udp port 5060 Or it would need to specify the zone's own root CA (by IRI and hash) which can then specify how much trust whatever it signs should have. The only restriction we should specify in that case is that our RR only implies that said CA can be trusted for names which are the same as the one where the CA pointer was found. (For this purpose, a name such as foo.bar.example.net. should be considered (in) a sub-zone of example.net. only iff there is a DS RR in the trust path. In other words, the '.'s don't make the boundries, only DS RRs do. We should point that out explictly, no matter what else we do.) If the RR we create supports either option above, then non-prefixed is the way forward. If, however, the consensus is against such detail, the need for both differentiating details and also for CNAME and wildcard RRs makes it a wash. I just thought of another possbile wording. We could just say that our lookup should be for whatever the (DNS) client is already going to look up. If it is about to do an AorAAAA lookup on 'example.com.', then it should also do a DANE lookup on 'example.com.'. And if it is about to do a SRV lookup on '_sip._tcp.example.org.' then its DANE lookup should also be on '_sip._tcp.example.org.'. This got longer than I expected; I hope that all is clear.... -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 33CF73A6D1D for ; Wed, 2 Feb 2011 12:10:52 -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 CeCmEErXIhO0 for ; Wed, 2 Feb 2011 12:10:50 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 31AEE3A6BC1 for ; Wed, 2 Feb 2011 12:10:50 -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 E4C161ECB422 for ; Wed, 2 Feb 2011 20:14:08 +0000 (UTC) Date: Wed, 2 Feb 2011 15:14:07 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110202201406.GC10367@shinkuro.com> References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> <4D494789.60006@sidn.nl> <20110202182403.GQ7903@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) Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 20:10:52 -0000 On Wed, Feb 02, 2011 at 02:35:32PM -0500, Paul Wouters wrote: > Corner cases where one can run weird stuff on weird ports through a corporate > firewall, allowing a TLSA record but not an A record, seems well, weird :) The problem with doing work on the INTERnet is that it has to interoperate in all cases, not just the tidy ones. We have a collective history of ignoring things like NATs that need all manner of tricks, and then later we find ourselves living with much worse designs that happen to work well for one case. I think we should aim to be as broad as feasible, even at the cost of some simplicity. > I am not against any port or transport modifiers, provided we're not > dropping the simple case that will be good enough for the large majority. Surely you're not arguing for _two_ ways to do the same thing? That to me would be extremely objectionable, and actually I'd expect the IESG to complain too. 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 1B44B3A6DAB for ; Wed, 2 Feb 2011 11:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 s9SR1j4bH704 for ; Wed, 2 Feb 2011 11:32:15 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 62C413A6C41 for ; Wed, 2 Feb 2011 11:32: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 7511EC556; Wed, 2 Feb 2011 14:35:33 -0500 (EST) Date: Wed, 2 Feb 2011 14:35:32 -0500 (EST) From: Paul Wouters To: Andrew Sullivan In-Reply-To: <20110202182403.GQ7903@shinkuro.com> Message-ID: References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> <4D494789.60006@sidn.nl> <20110202182403.GQ7903@shinkuro.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-2 Content-Transfer-Encoding: 8BIT Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 19:32:18 -0000 On Wed, 2 Feb 2011, Andrew Sullivan wrote: > On Wed, Feb 02, 2011 at 12:22:55PM -0500, Paul Wouters wrote: >> >> If they are different services, use a different FQDN. > > This seems to require that the person in charge of the services is > also in charge of the naming. In large organizations, that may not be > so. I'd expect you would be asking the same people for a hostname that you are going to inform to add a TLSA record? eg dnsops@corp.com. Corner cases where one can run weird stuff on weird ports through a corporate firewall, allowing a TLSA record but not an A record, seems well, weird :) > Also, it seems to me that this reasoning is not in line with other > patterns of use of the DNS for this sort of information. Consistency > is a good thing. So is simplicity :) I am not against any port or transport modifiers, provided we're not dropping the simple case that will be good enough for the large majority. Since people feel that queries should be send in parallel anyway, that should not cause too much overhead. So for Ondøej, I would prefer no modifiers, but could live with any of the modifier schemes, provided we also support the non-modifier 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 E82A73A6DA0 for ; Wed, 2 Feb 2011 10:20:47 -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 U88cPnYGlCyH for ; Wed, 2 Feb 2011 10:20:47 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id F3E823A6DC4 for ; Wed, 2 Feb 2011 10:20:46 -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 BE7C41ECB422 for ; Wed, 2 Feb 2011 18:24:06 +0000 (UTC) Date: Wed, 2 Feb 2011 13:24:05 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110202182403.GQ7903@shinkuro.com> References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> <4D494789.60006@sidn.nl> 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] Call for consensus on #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: Wed, 02 Feb 2011 18:20:48 -0000 On Wed, Feb 02, 2011 at 12:22:55PM -0500, Paul Wouters wrote: > > If they are different services, use a different FQDN. This seems to require that the person in charge of the services is also in charge of the naming. In large organizations, that may not be so. For instance, I worked at a university where one could get a network connection with full, unfettered access to the world. So I could run anything I wanted on the machine. But there was a one-hostname:1 net[4&6]address policy. I don't know why. Also, it seems to me that this reasoning is not in line with other patterns of use of the DNS for this sort of information. Consistency is a good thing. I don't feel real strongly about this, however. 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 D5DAD3A6D3D for ; Wed, 2 Feb 2011 10:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 5wpeZN17st-P for ; Wed, 2 Feb 2011 10:12:17 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 033BF3A6C11 for ; Wed, 2 Feb 2011 10:12:16 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 1A71F28406E for ; Wed, 2 Feb 2011 10:15:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=IFelEnzYGY8N/VBHmG2ewRx7MypO1QZRNtSJOmnsm7V 5p370kXGdoU56aa6eCtBRNKajSnnuJmvfv+6/+av+/jlo2wSvaM5zTdMAe6D4R54 NErpj8Prz4O0B6R8EGpVpZ2Zux9aaKYgfCA3FlpHV6d4KBuLaHrnhCiTMeKHTRHE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=jY0c1evI2Zhoj1iuoBO0F5/VWTk=; b=V7UuMfpqdP DYmGQHVMcKsy4rfDfxkHAV31mwZ24tTEZv5+iFU2V+jPweenqLSc/cWzqMNVEZXo TKfgO6Lt9S+b+2/xlbKNU1J5C00GecVkrhuYwo2uFXwGbfWI8Xt9GJlF9SsyUJE3 a1aETCMn9vCtObEO1jSVJ6fOhmPKM7XP0= Received: from [129.2.143.85] (129-2-143-85.wireless.umd.edu [129.2.143.85]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id D08B2284076 for ; Wed, 2 Feb 2011 10:15:36 -0800 (PST) From: Matt McCutchen To: keyassure@ietf.org In-Reply-To: <4D49178F.9060308@nic.cz> References: <1296575340.1888.27.camel@mattlaptop2.local> <4D49178F.9060308@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Feb 2011 09:31:19 -0500 Message-ID: <1296657079.1889.8.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 02 Feb 2011 18:12:17 -0000 On Wed, 2011-02-02 at 09:36 +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 1.2.2011 16:49, Matt McCutchen wrote: > > One solution would be to have the client, when no TLSA exists at the > > desired host/transport/port after following CNAMEs, search from the h= ost > > name up for a "DANE options" record with an exclusivity flag (which > > could be on or off). If no such record is found all the way up to th= e > > root zone, the default is "off". Do people think this would be worth > > the implementation effort and the extra queries? >=20 > The crawling up to the root is a call for serious problems. You don't=20 > want the _parent_ zone (at the zone cuts) to decide what's the _child_=20 > zone security policy. If there is an easy way to stop at a zone cut (e.g., by detecting the SOA record), that would be fine. I thought it might be more trouble than it is worth. The case in which this makes a difference is when one zone asserts DANE exclusivity, but its subzones make no statement. Should we assume they use DANE exclusively too or give them the default of no exclusivity? The latter approach has the potential to fail open if an organization splits off some of its DNS space into another zone and forgets to put another exclusive-DANE flag in that zone. > Moreover that are lot of security problems with this type of crawling=20 > (f.e. WPAD vulnerability). The problem with WPAD is that it uses a name that can be registered by untrusted parties. That is not the case with this proposal, which would put the record at the ancestor name. --=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 B73D63A6D82 for ; Wed, 2 Feb 2011 09:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 GgXReLLX7j+Q for ; Wed, 2 Feb 2011 09:19:37 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 499713A6D7E for ; Wed, 2 Feb 2011 09:19: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 B4D46C556; Wed, 2 Feb 2011 12:22:55 -0500 (EST) Date: Wed, 2 Feb 2011 12:22:55 -0500 (EST) From: Paul Wouters To: Antoin Verschuren In-Reply-To: <4D494789.60006@sidn.nl> Message-ID: References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> <4D494789.60006@sidn.nl> 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] Call for consensus on #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: Wed, 02 Feb 2011 17:19:38 -0000 On Wed, 2 Feb 2011, Antoin Verschuren wrote: > Hmm, haven't read the complete thread, but what happens if I want to run > my webserver on a different port than 443, and still want to use a > certificate for encryption ? foo.example.com. IN TLSA x keyblobA bar.example.com. IN TLSA y keyblobB foo.example.com IN A 1.2.3.4 bar.example.com IN A 1.2.3.4 clean and simple. use "bar" for the service on port 443, use "foo" for the service on the other port. > what do I use then, including the fact that I may be running a different > website on port 443 that I also want to publish a different certificate > for ? If they are different services, use a different FQDN. 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 D04D33A714E for ; Wed, 2 Feb 2011 04:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104, 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 ohPl23UtyS3n for ; Wed, 2 Feb 2011 04:11:47 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 61AE33A7129 for ; Wed, 2 Feb 2011 04:11:46 -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=XiqxcKsAxhmEYYtL0iT42+uHsI4itJ+/+QhkWqjcZJM=; b=L/FLYGoDNuQ7uH+ZiLmwAFizzG9tzh7XGoyJTshoDWMb0CB4P4qy6SC1y8x8naiXfp/DqizxfxAVW Fxzzt8ee9MO/zmZT+gYJ8UD3EWELAlpx8RSBeUm5JR1eTxgRLjEMUrzc07eq9VyaGfuzv/dyg8Xxzo 7uBXvX8t0HcNCUv8= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 2 Feb 2011 13:15:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4D494789.60006@sidn.nl> Date: Wed, 2 Feb 2011 13:15:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B63BE16-3AF4-4096-BC46-3D5FA0D75E67@kirei.se> References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> <4D494789.60006@sidn.nl> To: Antoin Verschuren X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 12:11:48 -0000 On 2 feb 2011, at 13.01, Antoin Verschuren wrote: > Hmm, haven't read the complete thread, but what happens if I want to = run > my webserver on a different port than 443, and still want to use a > certificate for encryption ? > what do I use then, including the fact that I may be running a = different > website on port 443 that I also want to publish a different = certificate > for ? You look up TLSA for _1234.tcp.www.example.com, and use the resulting = association for your TLS connection. TLS itself does not care what = protocol you are going to use over the resulting connection. Your client = does care of course, but not for the TLSA lookup. jakob --=20 Jakob Schlyter Kirei AB - http://www.kirei.se/ 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 04CBA3A6CB0 for ; Wed, 2 Feb 2011 03:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLSt1NJCV4Zm for ; Wed, 2 Feb 2011 03:57:34 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by core3.amsl.com (Postfix) with ESMTP id 76D2A3A6C69 for ; Wed, 2 Feb 2011 03:57:33 -0800 (PST) Received: from KAHUBCAS1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id p12C0qCS018864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 2 Feb 2011 13:00:52 +0100 Received: from [192.168.129.39] (192.168.129.39) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.0.702.0; Wed, 2 Feb 2011 13:00:52 +0100 Message-ID: <4D494789.60006@sidn.nl> Date: Wed, 2 Feb 2011 13:01:13 +0100 From: Antoin Verschuren 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: References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> In-Reply-To: <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 11:57:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01-02-11 20:03, Jakob Schlyter wrote: > On 1 feb 2011, at 17.31, Phillip Hallam-Baker wrote: > >> The protocol prefixes can have an unknown number of segments. The port is a single datum. Therefore it makes sense to prefix the port number first before the protocol prefix. > > As the port is a property of the protocol (TCP, UDP and SCTP all have ports, but that may not be true for future protocols), I'd say the protocol (if any) comes first, then any protocol specific identifier. Hmm, haven't read the complete thread, but what happens if I want to run my webserver on a different port than 443, and still want to use a certificate for encryption ? what do I use then, including the fact that I may be running a different website on port 443 that I also want to publish a different certificate for ? - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJNSUeIAAoJEDqHrM883AgnCB0IAMX7vUbxiRdhEyiEd7Tb/qM9 JjCXLPRZNbDXtbI3Fe9F5VXRwTIVxUa77BiNvJ3DmqpOV1ndOG+41C9mUPeyHa8M RwYQfwQ5x4GwMzdZWeng4/RhmfS9s1AEWkrSLs0sF93Q4DqQm3rGP+v2wVB1/qsc DlnDylYZL3PDGuzCujd9OByQXTN7BUzaMd06NxgTdwxHJGQRkd9kIT97NYng0s68 KtAshsiJ2IupPDfmgfJQ+nWjFz6e/TrgZzxCXVsky8Uu/6cBGT5Uye/DaBkLynAQ z0SMthU+XL7su2XSTyfjkiU5PZtQBpOm1WP1ehf9XVeh5DWiy2DHx7SA3FPBxaM= =lhAE -----END PGP SIGNATURE----- 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 3238A3A6BA1 for ; Wed, 2 Feb 2011 02:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, 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 nBQ2VvRcaOde for ; Wed, 2 Feb 2011 02:06: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 1FA4B3A6B64 for ; Wed, 2 Feb 2011 02:06:51 -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 p12AA0kC008297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Feb 2011 11:10:02 +0100 From: Simon Josefsson To: keyassure@ietf.org References: <4D481576.3040008@nic.cz> <4D48652D.9050700@vpnc.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110202:keyassure@ietf.org::Vp2v89ElxGzCr4aS:Fcsw X-Hashcash: 1:22:110202:paul.hoffman@vpnc.org::MXqDICGrFm3yj/lZ:DGCl Date: Wed, 02 Feb 2011 11:10:01 +0100 In-Reply-To: <4D48652D.9050700@vpnc.org> (Paul Hoffman's message of "Tue, 01 Feb 2011 11:55:25 -0800") Message-ID: <8762t23fye.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 Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 10:06:53 -0000 I prefer the _portnum._transport.hostname variant. (My earlier answer on this was written before the decision to support both DTLS and TLS were made, so I wanted to clarify my position.) /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 535EC3A6B75 for ; Wed, 2 Feb 2011 00:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.492 X-Spam-Level: X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[AWL=0.208, 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 jiP9h9cK6+ia for ; Wed, 2 Feb 2011 00:54:52 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 2BC263A7124 for ; Wed, 2 Feb 2011 00:54:51 -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 9E40D7343C8 for ; Wed, 2 Feb 2011 09:58:06 +0100 (CET) Message-ID: <4D491C9E.8020508@nic.cz> Date: Wed, 02 Feb 2011 09:58:06 +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: <4D481576.3040008@nic.cz> <1296575329.1888.26.camel@mattlaptop2.local> In-Reply-To: <1296575329.1888.26.camel@mattlaptop2.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 08:54:53 -0000 On 1.2.2011 16:48, Matt McCutchen wrote: > On Tue, 2011-02-01 at 15:15 +0100, OndÅ™ej Surý wrote: >> I would like to call for consensus on issue #1. >> >> The consensus would be that the draft-dane-protocol would define lookup >> on TLSA records as query for a name prefixed with a port or port and proto. >> >> Possible examples (no preference here for issue #1): >> _443.www.example.com >> _443._tcp.example.com >> _tcp_443.example.com. >> >> I will open separate issue# for the particular solution for querying >> (proto or not, fallback or not, etc.), since I don't think we have >> consensus on that yet. (And I think we should step forward constantly >> even in small steps.) > > Are we going to talk about the specifics next? Yes, as soon as we decide that we have consensus on that sublabeling is the way forward. > I would vote for always including the transport protocol. The client > and DNS admin both know what protocol they are using, so there is no > reason not to include it; having a fallback without the protocol is just > extra complexity. The possibility of having two different services > using different transport protocols with the same port number seems > remote now, but we don't know what the future might hold for transport > protocols so I think we might as well do this right. > > I don't feel strongly about the syntax, but I like the consistency of > _443._tcp.example.com with SRV. So you agree with the proposal to use prefix labels? OndÅ™ej -- 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 EAD973A6B9F for ; Wed, 2 Feb 2011 00:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=0.218, 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 L+kPXFv1WU8D for ; Wed, 2 Feb 2011 00:45: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 7508A3A7133 for ; Wed, 2 Feb 2011 00:45:07 -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 CF9A77343BC for ; Wed, 2 Feb 2011 09:48:25 +0100 (CET) Message-ID: <4D491A59.5020206@nic.cz> Date: Wed, 02 Feb 2011 09:48:25 +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: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Call for consensus on #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: Wed, 02 Feb 2011 08:45:09 -0000 On 1.2.2011 17:31, Phillip Hallam-Baker wrote: > > > On Tue, Feb 1, 2011 at 9:22 AM, Andrew Sullivan > wrote: > > On Tue, Feb 01, 2011 at 03:15:18PM +0100, OndÅ™ej Surý wrote: > > The consensus would be that the draft-dane-protocol would define > lookup > > on TLSA records as query for a name prefixed with a port or port and > > proto. > > > > Possible examples (no preference here for issue #1): > > _443.www.example.com > > _443._tcp.example.com > > _tcp_443.example.com . > > > > I will open separate issue# for the particular solution for querying > > (proto or not, fallback or not, etc.), since I don't think we have > > consensus on that yet. (And I think we should step forward > constantly > > even in small steps.) > > I'm not actually sure that these issues can be separated, since two of > the examples include the proto and one does not. I prefer the 2d > arrangement, personally, because it's cleaner from the DNS point of > view. > > > > I think that it is necessary to decide on the discovery strategy first > before deciding how to prefix labels. [The following paragraph applies to everybody.] The question was if we want to use prefix labels or not. Could you please say simple 'yes', 'no' or 'undecided'? We will decide what to put into the prefix label in separate ticket. OndÅ™ej -- 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 A9B043A6B9F for ; Wed, 2 Feb 2011 00:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.229, 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 CAZTz1-8QYHB for ; Wed, 2 Feb 2011 00:40:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 8BE7A3A6B75 for ; Wed, 2 Feb 2011 00:40: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 10F437343BC for ; Wed, 2 Feb 2011 09:43:19 +0100 (CET) Message-ID: <4D491926.9080804@nic.cz> Date: Wed, 02 Feb 2011 09:43:18 +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> <4D46DAEA.5040606@nic.cz> <87lj21f345.fsf@latte.josefsson.org> <4D47DD21.4020709@nic.cz> <20110201112259.GA27979@LK-Perkele-VI.localdomain> In-Reply-To: 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: Wed, 02 Feb 2011 08:40:01 -0000 On 1.2.2011 19:51, Paul Wouters wrote: > On Tue, 1 Feb 2011, Ilari Liusvaara wrote: > >> If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say, >> ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and >> 995 and 996 for POP3S. >> >> That would give four ports, 80, 443, 995 and 996 with no conflicts >> that would need service labels. >> >> So I don't see any need for service labels unless supporting seriously >> obsolete stuff like tcpmux. Port labels are enough. > > And those can also be avoided by using a separate FQDN for seperate > security level services pointing to the same A record. Yes, they can be avoided, but I don't think we want to push specific work with DNS to the DANE users. > I have not been convinced by the artificially created examples we need > any sub-labelling. I know that you're not. Hence the call for consensus, so we know the opinion of the working group, and we can move forward. OndÅ™ej -- 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 DECFA3A6B9F for ; Wed, 2 Feb 2011 00:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-XC5+A8Nm-p for ; Wed, 2 Feb 2011 00:33: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 5A59A3A6965 for ; Wed, 2 Feb 2011 00:33:14 -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 3A2B07343BC for ; Wed, 2 Feb 2011 09:36:32 +0100 (CET) Message-ID: <4D49178F.9060308@nic.cz> Date: Wed, 02 Feb 2011 09:36:31 +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: <1296575340.1888.27.camel@mattlaptop2.local> In-Reply-To: <1296575340.1888.27.camel@mattlaptop2.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 02 Feb 2011 08:33:17 -0000 On 1.2.2011 16:49, Matt McCutchen wrote: > One solution would be to have the client, when no TLSA exists at the > desired host/transport/port after following CNAMEs, search from the host > name up for a "DANE options" record with an exclusivity flag (which > could be on or off). If no such record is found all the way up to the > root zone, the default is "off". Do people think this would be worth > the implementation effort and the extra queries? The crawling up to the root is a call for serious problems. You don't want the _parent_ zone (at the zone cuts) to decide what's the _child_ zone security policy. Moreover that are lot of security problems with this type of crawling (f.e. WPAD vulnerability). 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 B02173A6C6C for ; Tue, 1 Feb 2011 23:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 PJe4jRGlICkm for ; Tue, 1 Feb 2011 23:28:36 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id F39223A6C00 for ; Tue, 1 Feb 2011 23:28:34 -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=d44bIzrJPGZI7H7mRW0VDSG6FQ9ia4Och8JEeiyvmaE=; b=EV2XyEravF0agFyQ7XMc6+XWL9LBN0Efz6ceHxIE1V4lEIqKQk2DusPobTKQm7Y0zbP7+Bs/eqO+2 rHP0W7LFyRKEGteWoM5eWhpI9zWKsHiJ0g0ql/OcEER7CccHZTW3X/m/Ai5idBYaSMoIstHPT6vWVP tzhIWv80T1IcFqdM= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Wed, 2 Feb 2011 08:31:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <1296575340.1888.27.camel@mattlaptop2.local> Date: Wed, 2 Feb 2011 08:31:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55625D32-1FFF-4D77-BE2A-7E673D8D0E99@kirei.se> References: <1296575340.1888.27.camel@mattlaptop2.local> To: Matt McCutchen X-Mailer: Apple Mail (2.1082) Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 02 Feb 2011 07:28:37 -0000 On 1 feb 2011, at 16.49, Matt McCutchen wrote: > I would like to assert DANE exclusivity for the entire domain > mattmccutchen.net so that, with respect to clients that check DANE = first > and fall back to a mainstream public CA list, a shady CA cannot > impersonate my existing TLS services /or/ fabricate TLS services I do > not offer. This sounds like the opposite of STS (Strict Transport Security), i.e. = policy and not key association distribution. 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 A9A423A6AF9 for ; Tue, 1 Feb 2011 14:42:58 -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 BqFoH-GLz03n for ; Tue, 1 Feb 2011 14:42:58 -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 AA5DA3A6885 for ; Tue, 1 Feb 2011 14:42:57 -0800 (PST) Received: by wyf23 with SMTP id 23so7501913wyf.31 for ; Tue, 01 Feb 2011 14:46:15 -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=vrhGHV2THm1XS6FOG0Y8+pcwN8m5v2MZx8Ab9ccTCew=; b=VfT2HlZYfu+BLkB6scNLg9QXRNnNja7WsSl7eo6cpNLgWhVO5blnqgO01paoTSlkch IsS6tL4hFyUr8vLKakYkP9qtgf1zvuhIMEv23yZbPh7IhHVYeeaaLpNhz4PDXjgFlqEA O/lv82AQCa7Q9DdFHqSf7ijRpfFwOh55Z6So4= 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=JOuLk0hIS8AK4FxscXtHgNoHIyJRhnUqjTZxGxgYU6ofVCw6jUS7kbN8jEBHsU4iQu 9VQifD7e80+iv9x66ckSV7rgABcbUSEBpNLqsN5fiCTHPAk3bWPcpgSJw+DiVNDsv8/M 9/FbeAn2mEpb22NZap8a9R3OiH5wTKiFBKwAU= MIME-Version: 1.0 Received: by 10.227.182.142 with SMTP id cc14mr8298881wbb.215.1296600374936; Tue, 01 Feb 2011 14:46:14 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Tue, 1 Feb 2011 14:46:14 -0800 (PST) In-Reply-To: <201102012242.p11MgRgJ025416@fs4113.wdf.sap.corp> References: <201102012242.p11MgRgJ025416@fs4113.wdf.sap.corp> Date: Tue, 1 Feb 2011 14:46:14 -0800 X-Google-Sender-Auth: wGxRjwjX_scHNxIySlt4G9qXLnc Message-ID: From: Zack Weinberg To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure@ietf.org Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 22:42:58 -0000 On Tue, Feb 1, 2011 at 2:42 PM, Martin Rex wrote: > Zack Weinberg wrote: >> >> > If there is a DANE record, then any wise client should interpret that >> > as an exclusive list of allowed TLS certificates >> >> I agree with this, but the question is how do you present an empty list. > > What exactly would you want to convey with an empty list? > =C2=A0"I won't respond to TLS, so don't even bother trying" Well, this was originally Matt's requirement, not mine. I just suggested how it might be represented in the DNS. Matt, can you expand on why this would be useful to you? 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 AE9BA3A6AF9 for ; Tue, 1 Feb 2011 14:39:16 -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 A60pKIPDlJB7 for ; Tue, 1 Feb 2011 14:39:16 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B7EE73A6885 for ; Tue, 1 Feb 2011 14:39:15 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p11MgRCx020626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 23:42:32 +0100 (MET) From: Martin Rex Message-Id: <201102012242.p11MgRgJ025416@fs4113.wdf.sap.corp> To: zack.weinberg@sv.cmu.edu (Zack Weinberg) Date: Tue, 1 Feb 2011 23:42:27 +0100 (MET) In-Reply-To: from "Zack Weinberg" at Feb 1, 11 01:32:14 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] Asserting DANE exclusivity for an entire domain 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 22:39:16 -0000 Zack Weinberg wrote: > > > If there is a DANE record, then any wise client should interpret that > > as an exclusive list of allowed TLS certificates > > I agree with this, but the question is how do you present an empty list. What exactly would you want to convey with an empty list? "I won't respond to TLS, so don't even bother trying" The only time when such an information becomes interesting is when you have a client with a strong desire to communicate with a target and intent/preference for using TLS-protection on that communication. DANE-unaware clients will continue trying to use TLS. What is your rationale for making DANE-aware clients exhibit a different behaviour and entirely stop trying to use TLS? -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 3DB823A6C4D for ; Tue, 1 Feb 2011 13:28:59 -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 zVDYpgO7cLoD for ; Tue, 1 Feb 2011 13:28:58 -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 079ED3A6856 for ; Tue, 1 Feb 2011 13:28:57 -0800 (PST) Received: by wwa36 with SMTP id 36so8000103wwa.13 for ; Tue, 01 Feb 2011 13:32:15 -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=+fiaz8fP/k7O80oZb2ZhWrEIYSD3v5i6zE50jKTVR1Q=; b=JK0pqjVLVrqCa5DGsHd5NjB2GoavUgFux81B4Vsagcq2plmyxnar07oSksy+tIKISm +zQrPT7fqHanIu+RZ6L8EBICP/7YriltrmjGOfzWUxm496cQazAdP9jOFUiR+cQCOkIj swGgJ3LzoZafVI5Tz/MsO3lIyz7s3MoSY9Sa0= 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=iegS8csXeQuor4Ldn6sgL06wqWmnjcYOEcFwGUdIil5w9oQkI0roRCqVToabVxtGSg n5G5d1Pt1UfqJL5NYNWfqx3c7KF1ZEKH8O4ZgEU7rhMOZlw0ARjZnGx3ndLrPr255ajT 2Qyz5EgZP+LjY/x/jvwQFNOrMsZXwEiix/lCU= MIME-Version: 1.0 Received: by 10.227.182.142 with SMTP id cc14mr8227804wbb.215.1296595935154; Tue, 01 Feb 2011 13:32:15 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Tue, 1 Feb 2011 13:32:14 -0800 (PST) In-Reply-To: References: <1296575340.1888.27.camel@mattlaptop2.local> Date: Tue, 1 Feb 2011 13:32:14 -0800 X-Google-Sender-Auth: wJyYwu5Tgbor_-iWwPn3IQIHv1c Message-ID: From: Zack Weinberg To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 21:28:59 -0000 On Tue, Feb 1, 2011 at 11:03 AM, Paul Wouters wrote: > On Tue, 1 Feb 2011, Zack Weinberg wrote: > >> It occurs to me that there is currently no such thing as a DANE record >> that expresses "there are no TLS-secured services provided by this >> domain name" > > Not having them in a signed zone? And the same for CA based certs. The *absence* of a DANE record in a signed zone has to mean fall back to legacy behavior, otherwise we force people to adopt DANE just so they can sign their zones. So that won't work. > If there is a DANE record, then any wise client should interpret that > as an exclusive list of allowed TLS certificates I agree with this, but the question is how do you present an empty list. 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 21C943A6D00 for ; Tue, 1 Feb 2011 11:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.013 X-Spam-Level: X-Spam-Status: No, score=-101.013 tagged_above=-999 required=5 tests=[AWL=-0.456, 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 D+E3SbeeNROx for ; Tue, 1 Feb 2011 11:52:08 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 75CBE3A6C53 for ; Tue, 1 Feb 2011 11:52:08 -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 p11JtP6P053415 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Feb 2011 12:55:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D48652D.9050700@vpnc.org> Date: Tue, 01 Feb 2011 11:55:25 -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: <4D481576.3040008@nic.cz> In-Reply-To: <4D481576.3040008@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 19:52:09 -0000 Having seen the discussion so far, I am swayed by the argument that proposal #1 (send all records with differentiators for ports) is inferior to #2 (ask for the specific record wanted) because #1 will take up unnecessary bandwidth. I now support #2 more than #1, and prefer either _portnum._transport.hostname or _portnum.hostname over _portnum_transport.hostname. I don't see a strong need for giving the transport, but it seems trivial to do and may prevent some weird problem in the future. 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 240283A6FC9 for ; Tue, 1 Feb 2011 11:00:09 -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 Wn-aVmUbfdA9 for ; Tue, 1 Feb 2011 11:00:08 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 491AA3A6FC4 for ; Tue, 1 Feb 2011 11:00:06 -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 7DDA1C4FA; Tue, 1 Feb 2011 14:03:23 -0500 (EST) Date: Tue, 1 Feb 2011 14:03:23 -0500 (EST) From: Paul Wouters To: Zack Weinberg In-Reply-To: Message-ID: References: <1296575340.1888.27.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] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 19:00:09 -0000 On Tue, 1 Feb 2011, Zack Weinberg wrote: > It occurs to me that there is currently no such thing as a DANE record > that expresses "there are no TLS-secured services provided by this > domain name" Not having them in a signed zone? And the same for CA based certs. If there is a DANE record, then any wise client should interpret that as an exclusive list of allowed TLS certificates, and any certs presented to the browser by SomeCA which is not in DNSSEC should be rejected as false. If you don't do this, DANE becomes as weak as the weakest CA. And that's not very strong. 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 4DC7F3A6EBF for ; Tue, 1 Feb 2011 10:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 vKml7HrmT7bY for ; Tue, 1 Feb 2011 10:59:55 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id 6A1453A6DF4 for ; Tue, 1 Feb 2011 10:59:54 -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=AJ4IJj2lMdTaJCUp+clXY9SKHpsDZAcR3r3izC5QVb4=; b=hxxlRFj5d+GGr0B6ceD/DvF2ILul+pNl19x+EF/dAmtcUGvilvEWXIb4jNnFtrG/Hf5PBruJRkWVq AhQIhQ4OusxnS00im9JeVDH4LgWMoISveNKgVFdg5kdjEmmkxGG5tzfoBAXz7ewXRSCuFgrNbMYJYg 3hG479V9t+18TgO4= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 1 Feb 2011 20:03:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: Date: Tue, 1 Feb 2011 20:03:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B0BFE1F-ABE2-406B-8E85-877951CFDB8E@kirei.se> References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 18:59:56 -0000 On 1 feb 2011, at 17.31, Phillip Hallam-Baker wrote: > The protocol prefixes can have an unknown number of segments. The port = is a single datum. Therefore it makes sense to prefix the port number = first before the protocol prefix. As the port is a property of the protocol (TCP, UDP and SCTP all have = ports, but that may not be true for future protocols), I'd say the = protocol (if any) comes first, then any protocol specific identifier. 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 A0F7F3A6FC9 for ; Tue, 1 Feb 2011 10:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 v5+52qEa7W9w for ; Tue, 1 Feb 2011 10: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 A74803A6844 for ; Tue, 1 Feb 2011 10:52:51 -0800 (PST) Received: by gwb20 with SMTP id 20so3025015gwb.31 for ; Tue, 01 Feb 2011 10:56:09 -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=ycrgHKmwjv5bgmfoi+CE49QeLgj06ZHVagIeimhUWAI=; b=etz+Djy672ym26PFT2j5RADESL2b3oIxGUdc3/UJb9i4rI6z5237I3NOsJfbGrADQl BqRzN99201gYDGi2GLH+/F7Glr6RLNB5ZdHMtSgOXVS3KOXrk+8CrVpmCmYYJr42+jJM zeID/ixa2Dz2P7nHEIyNqGCvCMb9/Aw6QrsC4= 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=JTlD5dfzHJBFmpbSibvkdlfkEKuiMDq1otVhFVVYn6JVCivGjzO66qtYg5oO2t2Bbg sdm9pgFKYUf6cqgpXeMCuuld8yh/nV2DlFzG+jS5n+e9vUYZLI4rimMiXYUiFmcVzXRd NhNJ9xPIcViIP3hi3hg7xe4HNEnZ9H4DU//FQ= MIME-Version: 1.0 Received: by 10.100.6.7 with SMTP id 7mr5086618anf.256.1296586568816; Tue, 01 Feb 2011 10:56:08 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 10:56:08 -0800 (PST) In-Reply-To: <4D484423.8070007@vpnc.org> References: <4D481641.6090604@nic.cz> <4D484423.8070007@vpnc.org> Date: Tue, 1 Feb 2011 13:56:08 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e642d3badad8a2049b3d150f Cc: keyassure@ietf.org Subject: Re: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org 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, 01 Feb 2011 18:52:56 -0000 --0016e642d3badad8a2049b3d150f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The only example I was previously aware of was the namedroppers list which was recently required to change to dnsext despite considerable feeling in the WG against it. >From an administrative point of view it is much easier for the secretariat if the names of the lists are the same as the names of the WGs. I don't think this is a choice in the long term, I would prefer to make a change as soon as possible. On Tue, Feb 1, 2011 at 12:34 PM, Paul Hoffman wrote= : > On 2/1/11 6:18 AM, Ond=C5=99ej Sur=C3=BD wrote: > >> Hi, >> >> I would like to ask the listmaster to rename the mailing list to >> dane@ietf.org to keep it with sync with the WG name. >> >> Any objections? >> >> I'll keep you posted on the dates, etc. when I know more details. >> > > FWIW, other WGs have the list name be different than the WG name due to t= he > same reasons we do. This neatening-up is probably not needed. > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --=20 Website: http://hallambaker.com/ --0016e642d3badad8a2049b3d150f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The only example I was previously aware of was the namedroppers list which = was recently required to change to dnsext despite considerable feeling in t= he WG against it.=C2=A0

From an administrative point of = view it is much easier for the secretariat if the names of the lists are th= e same as the names of the WGs.

I don't think this is a choice in the long term, I = would prefer to make a change as soon as possible.


On Tue, Feb 1, 2011 at 12:34 PM, Paul Hoffman <paul.hoffman@vpnc.or= g> wrote:
On 2/1/11 6:18 AM, Ond=C5= =99ej Sur=C3=BD wrote:
Hi,

I would like to ask the listmaster to rename the mailing list to
dane@ietf.org to kee= p it with sync with the WG name.

Any objections?

I'll keep you posted on the dates, etc. when I know more details.

FWIW, other WGs have the list name be different than the WG name due to the= same reasons we do. This neatening-up is probably not needed.

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



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

--0016e642d3badad8a2049b3d150f-- 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 BE8F73A6FB1 for ; Tue, 1 Feb 2011 10:51:35 -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 mOOUSOpcWSah for ; Tue, 1 Feb 2011 10:51:35 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E9F0F3A6F24 for ; Tue, 1 Feb 2011 10:51:34 -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 1C236C558; Tue, 1 Feb 2011 13:54:52 -0500 (EST) Date: Tue, 1 Feb 2011 13:54:51 -0500 (EST) From: Paul Wouters To: Matt McCutchen In-Reply-To: <1296568884.2012.39.camel@mattlaptop2.local> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <21F13008-0B04-40FB-89D7-4FBA69EEC2DB@kumari.net> <85498CC6-BD0D-4A69-8A12-DA0169AC95B0@kumari.net> <1296568884.2012.39.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] 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, 01 Feb 2011 18:51:35 -0000 On Tue, 1 Feb 2011, Matt McCutchen wrote: > I am unhappy with 1a. I wouldn't like to build the assumption that > ports at the same host name are at the same security level into DANE, insecure.example.com. IN A 1.2.3.4 secure.example.com. IN A 1.2.3.4 insecure.example.com. IN TLSA x snakeoilcert secure.example.com. IN TLSA x securecert Now you have different security levels to the same host on 1.2.3.4, without the added parsing/complexity/uglyness of _modifiers. 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 DCC533A6FC4 for ; Tue, 1 Feb 2011 10:48:00 -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 MtBI4IvM2ctE for ; Tue, 1 Feb 2011 10:48:00 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id E006C3A6F24 for ; Tue, 1 Feb 2011 10:47: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 05611C558; Tue, 1 Feb 2011 13:51:16 -0500 (EST) Date: Tue, 1 Feb 2011 13:51:15 -0500 (EST) From: Paul Wouters To: Ilari Liusvaara In-Reply-To: <20110201112259.GA27979@LK-Perkele-VI.localdomain> Message-ID: References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> <87lj21f345.fsf@latte.josefsson.org> <4D47DD21.4020709@nic.cz> <20110201112259.GA27979@LK-Perkele-VI.localdomain> 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: Tue, 01 Feb 2011 18:48:01 -0000 On Tue, 1 Feb 2011, Ilari Liusvaara wrote: > If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say, > ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and > 995 and 996 for POP3S. > > That would give four ports, 80, 443, 995 and 996 with no conflicts > that would need service labels. > > So I don't see any need for service labels unless supporting seriously > obsolete stuff like tcpmux. Port labels are enough. And those can also be avoided by using a separate FQDN for seperate security level services pointing to the same A record. I have not been convinced by the artificially created examples we need any sub-labelling. 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 E97ED3A6DF4 for ; Tue, 1 Feb 2011 09:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.013 X-Spam-Level: X-Spam-Status: No, score=-101.013 tagged_above=-999 required=5 tests=[AWL=-0.456, 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 CKp1+bk9OQKX for ; Tue, 1 Feb 2011 09:31:20 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 816AE3A6959 for ; Tue, 1 Feb 2011 09:31:11 -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 p11HYR8b032077 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Feb 2011 10:34:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D484423.8070007@vpnc.org> Date: Tue, 01 Feb 2011 09:34: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: <4D481641.6090604@nic.cz> In-Reply-To: <4D481641.6090604@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org 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, 01 Feb 2011 17:31:22 -0000 On 2/1/11 6:18 AM, Ondřej Surý wrote: > Hi, > > I would like to ask the listmaster to rename the mailing list to > dane@ietf.org to keep it with sync with the WG name. > > Any objections? > > I'll keep you posted on the dates, etc. when I know more details. FWIW, other WGs have the list name be different than the WG name due to the same reasons we do. This neatening-up is probably not needed. 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 8B87C3A6DF1 for ; Tue, 1 Feb 2011 09:16:26 -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 kmOwZGbdctpf for ; Tue, 1 Feb 2011 09:16:25 -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 AEB233A6D4F for ; Tue, 1 Feb 2011 09:16:23 -0800 (PST) Received: by wwa36 with SMTP id 36so7725280wwa.13 for ; Tue, 01 Feb 2011 09:19:40 -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=yJ/KqTzMzeUgXraXwgn63LTV1pIGAxODMSV2ZJ47mx8=; b=AHOWP0xDvSj2tvoKN6oboEYbsgEv3qnMxC+SrjISQ30d9TjMHhFKL29Mcr/uCemkPh Ji1ShDtJ4R5rGkQ40BORWauaqCxdCvhBFbU1miuzn9k7dUk98uDgDqJpLIIlEmQOL8hH ebmhR6HA3LoJ5Zuixsva8AiWfVwtwiw7F9rso= 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=hqC+EH2NNBPDO4vn+k6D6UF6e50hNsQ5IpK6Qp8x8YGTnxtxM8JKtN0qqlPVPIQ1Uk WHASfOl+wH7ZkTMd8mwqHaCYsUiwaLaZ1jXLWYqgiiOlSlUPYIjnaCCyHmdolaFaGeMQ ZBUcgPmi//pcdTwg4znwyLFPYTbRTbY1zSX6o= MIME-Version: 1.0 Received: by 10.227.138.15 with SMTP id y15mr7942066wbt.186.1296580780492; Tue, 01 Feb 2011 09:19:40 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Tue, 1 Feb 2011 09:19:40 -0800 (PST) In-Reply-To: <5266FBC6-1B32-4EAD-990C-785F2CD8DB8A@icsi.berkeley.edu> References: <1296575340.1888.27.camel@mattlaptop2.local> <5266FBC6-1B32-4EAD-990C-785F2CD8DB8A@icsi.berkeley.edu> Date: Tue, 1 Feb 2011 09:19:40 -0800 X-Google-Sender-Auth: 5ydBHrI5bpIrHZcsueOYHe76Sm0 Message-ID: From: Zack Weinberg To: Nicholas Weaver Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: keyassure , Phillip Hallam-Baker Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 17:16:26 -0000 On Tue, Feb 1, 2011 at 8:25 AM, Nicholas Weaver wrote: > On Feb 1, 2011, at 8:21 AM, Zack Weinberg wrote: >> It occurs to me that there is currently no such thing as a DANE record >> that expresses "there are no TLS-secured services provided by this >> domain name" (or "...by this port"). =C2=A0Maybe there should be one? [...] > > Stupid question: =C2=A0Couldn't this be done with NSEC/NSEC3 records? I don't think so, because the "secured" (RFC4033-sense) absence of a TLSA record has to mean "fall back to pre-DANE behavior" for compatibility's sake. We don't want to force people to adopt DANE just so they can adopt DNSSEC. 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 7BBA23A67F9 for ; Tue, 1 Feb 2011 08:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 DXiYH3sxXvWR for ; Tue, 1 Feb 2011 08:43:07 -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 DA46B3A679F for ; Tue, 1 Feb 2011 08:43:06 -0800 (PST) Received: by gxk27 with SMTP id 27so2954840gxk.31 for ; Tue, 01 Feb 2011 08:46:24 -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=jTykrhx8NPUI3Mh+F2N1o4morUrDOmOoQ63t0616t40=; b=G+8uWqx51GYusUFmDxyPR2PVNrQy5AyWH4RbuUWAPKcBTjO9tJ8FwagGI/FONsnmel puf9TNpiPO62xiN5wTL7tLKgH7Bm1dKjCmNktROszQprjLwjWlL70DlcatBDr5mNk1qH qWNhhvJ1K43MOheSWb0GHMNECxLKSsBydJf4U= 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=MxwT6a5GxXfCaehbNJ7Z088pBoMZSnHmFxNNK71yMIIQLQpXOk+oq9nrBLxbShb+3F XQGNBMliJFdVKePq/qMA/g+FgNVo64BEeD/UGdTwPMC5DruURh/NPYhyxJ0Kz1ey09go n/Xy8zBdFm5KWEBgs+mxW5XajTA3WPc71sTJI= MIME-Version: 1.0 Received: by 10.100.134.10 with SMTP id h10mr5054027and.86.1296578783910; Tue, 01 Feb 2011 08:46:23 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 08:46:23 -0800 (PST) In-Reply-To: <4D4829E2.9080907@nic.cz> References: <4D481576.3040008@nic.cz> <5C2AE6F6-4FB2-457A-B644-209975676638@insensate.co.uk> <4D4829E2.9080907@nic.cz> Date: Tue, 1 Feb 2011 11:46:23 -0500 Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=0016e644c708d69c64049b3b45ea Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 16:43:08 -0000 --0016e644c708d69c64049b3b45ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 1, 2011 at 10:42 AM, Ond=C5=99ej Sur=C3=BD = wrote: > On 1.2.2011 16:31, Lawrence Conroy wrote: > >> Hi There Ond=C5=99ej, folks, >> did you mean example 3 to have no dot between the _tcp and _443 (i.e. t= o >> be one label, rather than two)? >> > > Yes. > > > I have no problem with example 2 (or example 1), but example 3 is >> confusing and/or less pleasing. >> > > I new I shouldn't add examples there :). > > > On 1.2.2011 16:31, Martin Rex wrote: > > I'm confused; shouldn't this read > > > > a _443.www.example.com > > b _443._tcp.www.example.com > > c _tcp_443.www.example.com > > Yes, it should. > > > > What would be easier on the DNS administration (software, handling > > and understanding): (b) or (c) ? > > I knew I shouldn't add the examples to my call for consensus :-). This > call was only about if: > > a) we want to go the DNS prefix way (_prefix._hostname) > b) something else (just _hostname, SRV, etc.) > > My understanding from reading the thread was that the general opinion > (except Paul W.) was to go the DNS prefix way. DNS Prefixes do not in general work unless the prefix is attached to a canonical name. If the proposal here is that the initial lookup be for a prefixed record, there will be consequences. E.g. if the initial lookup for a key to connect to www.example.com at port 80 is _prefixtbs80.www.example.com That will have the following consequences: 1) It will fail if www.example.com has a CNAME record unless there is also = a CNAME for the prefix record or the prefix is duplicated (thus losing the point of having a CNAME. In particular, it is no longer possible to use CNAME to direct across administrative zones. So if we have a company that is outsourcing their mai= l to mailservice.com, they cannot so so by simply adding a CNAME to their own domain. They have to constantly monitor the destination domain to see if there might have been key records added and create the corresponding CNAME records. 2) DNS Wildcards do not work If there is a wildcard record for *.example.com, there will inevitably be cases where the resolution either cannot provide the appropriate record or there will be ambiguity in the record delivered. There is no DNS wildcard construct for _prefix.*.example.com. Use of DNAME in place of CNAME does not give the desired semantics either. One way round this problem is to require a two stage discovery process. In the first phase the client requests the A record and the prefix record in parallel. Should the A record return a result telling the client that the name is not canonical, a second query is made for the prefix at the canonical name. If you are going to get into multi-step discovery processes, you might as well do the job right as I propose in the other thread. --=20 Website: http://hallambaker.com/ --0016e644c708d69c64049b3b45ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 10:42 AM, Ond=C5= =99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
On 1.2.2011 16:31, Lawrence Conroy wrote:
Hi There Ond=C5=99ej, folks,
=C2=A0did you mean example 3 to have no dot between the _tcp and _443 (i.e= . to be one label, rather than two)?

Yes.


I have no problem with example 2 (or example 1), but example 3 is confusing= and/or less pleasing.

I new I shouldn't add examples there :).


On 1.2.2011 16:31, Martin Rex wrote:
> I'm confused; shouldn't this read
>
> a =C2=A0 _443= .www.example.com
> b =C2=A0 _443._tcp.www.example.com
> c =C2=A0 _tcp_443.www.example.com

Yes, it should.


> What would be easier on the DNS administration (software, handling
> and understanding): (b) or (c) ?

I knew I shouldn't add the examples to my call for consensus :-). =C2= =A0This call was only about if:

a) we want to go the DNS prefix way (_prefix._hostname)
b) something else (just _hostname, SRV, etc.)

My understanding from reading the thread was that the general opinion (exce= pt Paul W.) was to go the DNS prefix way.

D= NS Prefixes do not in general work unless the prefix is attached to a canon= ical name.

If the proposal here is that the initial lookup be for = a prefixed record, there will be consequences. E.g. if the initial lookup f= or a key to connect to www.example.com at port 80 is=C2=A0


That will have the follow= ing consequences:

1) It will fail if www.example.com has a CNAME record unless there i= s also a CNAME for the prefix record or the prefix is duplicated (thus losi= ng the point of having a CNAME.

In particular, it is no longer possible to use CNAME to= direct across administrative zones. So if we have a company that is outsou= rcing their mail to mailservice.com,= they cannot so so by simply adding a CNAME to their own domain. They have = to constantly monitor the destination domain to see if there might have bee= n key records added and create the corresponding CNAME records.


2) DNS Wildcards do not work
<= br>
If there is a wildcard record for *.example.com, there will inevitably be cases where the resolution = either cannot provide the appropriate record or there will be ambiguity in = the record delivered.


There is no DNS wildcard construct for _= prefix.*.example.com.

Use of DNAME in place of CNAME does not give the desired semantics e= ither.


One way round this problem is to require= a two stage discovery process. In the first phase the client requests the = A record and the prefix record in parallel.

Should= the A record return a result telling the client that the name is not canon= ical, a second query is made for the prefix at the canonical name.

If you are going to get into multi-step discovery proce= sses, you might as well do the job right as I propose in the other thread.<= /div>


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

--0016e644c708d69c64049b3b45ea-- 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 20D8A3A6C05 for ; Tue, 1 Feb 2011 08:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=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 tksGr1KQP96g for ; Tue, 1 Feb 2011 08:28:41 -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 806D83A6BFA for ; Tue, 1 Feb 2011 08:28:41 -0800 (PST) Received: by gyd12 with SMTP id 12so2921954gyd.31 for ; Tue, 01 Feb 2011 08:31:58 -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=TF7/L10cjvCClu8kqdVOPCuG80Bf6+CZmdHXNVTKmQs=; b=A4jtm7uLKk43REI2BOSINe/2ONVl1WeG/GBNFf9HZR16TYMgUlw1cx1bM2Ta8ahPLV YtID22dDFp9LYb2BrR1gz8ndIJethUFJ1rR2w1KgqxyqwncW993dNdYhxBPdi40Vex3u rK7jyPaTkj54FY3FNFG2HzHosEP182gjVs8Ks= 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=JMlggK4bQrhNiekBdtFVCGRVnf6N3+9lIhiit1uSFlZm5DBXckoibh8WjAsx0+EoNS M/pLgvUSIxaOPpACi4pF1stIOXSl0vrhWBOz5nw+3vP5P0AHMfjt733I16zxW1hQ8XIH gyI0adcmaao3nRMgAWnUYOWnoO6cDCGY9flyU= MIME-Version: 1.0 Received: by 10.100.4.11 with SMTP id 11mr5118080and.52.1296577918301; Tue, 01 Feb 2011 08:31:58 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 08:31:58 -0800 (PST) In-Reply-To: <20110201142237.GA3135@shinkuro.com> References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> Date: Tue, 1 Feb 2011 11:31:58 -0500 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=0016e646526c3e76a9049b3b1221 Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 16:28:43 -0000 --0016e646526c3e76a9049b3b1221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 1, 2011 at 9:22 AM, Andrew Sullivan wrote: > On Tue, Feb 01, 2011 at 03:15:18PM +0100, Ond=C5=99ej Sur=C3=BD wrote: > > The consensus would be that the draft-dane-protocol would define lookup > > on TLSA records as query for a name prefixed with a port or port and > > proto. > > > > Possible examples (no preference here for issue #1): > > _443.www.example.com > > _443._tcp.example.com > > _tcp_443.example.com. > > > > I will open separate issue# for the particular solution for querying > > (proto or not, fallback or not, etc.), since I don't think we have > > consensus on that yet. (And I think we should step forward constantly > > even in small steps.) > > I'm not actually sure that these issues can be separated, since two of > the examples include the proto and one does not. I prefer the 2d > arrangement, personally, because it's cleaner from the DNS point of > view. I think that it is necessary to decide on the discovery strategy first before deciding how to prefix labels. There are two separate concerns here 1) How to avoid records intended only for service A being used to access service B 2) How to discover the specific records intended for a specific instance of service of type X on host Y on port Z. The first is a security concern. If I have a key being advertised for a low risk protocol (e.g. SMTP for STARTTLS), I do not want a client to accept that for use with a high risk protocol (e.g. interbank transaction settlements). I think that the way to address the first concern is to use SRV prefixes bu= t to express them inside the certificate as use restrictions according to RFC 4985. The second only affects some sites. Use of DNS prefix records involves certain performance issues. Thus it is reasonable to make this an option fo= r those sites that require such certificates to be distinguished. Given the limited scope of use and given that any site that has a hundred services at the same domain label is almost certainly going to require use of SRV or similar to make it practical, I believe that any extended discovery mechanism for keys should map onto the prefixes used in SRV and similar mechanisms. There would thus be three separate phases of resolution, the first two having the potential to trigger an additional round of resolution should it be required. 1) Generic - all protocols and ports www.example.com 2) Canonical name of service prefixed by protocol _http._tcp.example.com 3) Canonical name of host prefixed by protocol+port _http._tcp._80.host1.example.com The protocol prefixes can have an unknown number of segments. The port is a single datum. Therefore it makes sense to prefix the port number first before the protocol prefix. --=20 Website: http://hallambaker.com/ --0016e646526c3e76a9049b3b1221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 9:22 AM, Andrew S= ullivan <ajs@shink= uro.com> wrote:
On Tue, Feb 01, 2011 at 03:15:18PM +0100, Ond=C5=99ej Sur= =C3=BD wrote:
> The consensus would be that the draft-dane-protocol would define looku= p
> on TLSA records as query for a name prefixed with a port or port and > proto.
>
> Possible examples (no preference here for issue #1):
> =C2=A0_443.ww= w.example.com
> =C2=A0_443._tcp.e= xample.com
> =C2=A0_tcp_44= 3.example.com.
>
> I will open separate issue# for the particular solution for querying > (proto or not, fallback or not, etc.), since I don't think we have=
> consensus on that yet. =C2=A0(And I think we should step forward const= antly
> even in small steps.)

I'm not actually sure that these issues can be separated, since t= wo of
the examples include the proto and one does not. =C2=A0I prefer the 2d
arrangement, personally, because it's cleaner from the DNS point of
view.


I think that it is nec= essary to decide on the discovery strategy first before deciding how to pre= fix labels.

There are two separate concerns here

1) How to avoid records intended only for service A bei= ng used to access service B

2) How to discover the= specific records intended for a specific instance of service of type X on = host Y on port Z.


The first is a security concern. If I ha= ve a key being advertised for a low risk protocol (e.g. SMTP for STARTTLS),= I do not want a client to accept that for use with a high risk protocol (e= .g. interbank transaction settlements).

I think that the way to address the first concern is to= use SRV prefixes but to express them inside the certificate as use restric= tions according to RFC 4985.=C2=A0


= The second only affects some sites. Use of DNS prefix records involves cert= ain performance issues. Thus it is reasonable to make this an option for th= ose sites that require such certificates to be distinguished.

Given the limited scope of use and given that any site = that has a hundred services at the same domain label is almost certainly go= ing to require use of SRV or similar to make it practical, I believe that a= ny extended discovery mechanism for keys should map onto the prefixes used = in SRV and similar mechanisms.

There would thus be three separate phases of resolution= , the first two having the potential to trigger an additional round of reso= lution should it be required.

1) Generic - all pro= tocols and ports
=C2=A0=C2=A0 www.example.com

2) Canonical name of service prefixed by protocol
=C2=A0=C2=A0 _http._tcp.example.= com

3) Canonical name of host prefixed by protocol+port
= =C2=A0=C2=A0 _http._tcp._80.host1.e= xample.com

=C2=A0
The protocol prefi= xes can have an unknown number of segments. The port is a single datum. The= refore it makes sense to prefix the port number first before the protocol p= refix.

--
Website: ht= tp://hallambaker.com/

--0016e646526c3e76a9049b3b1221-- 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 CE62F3A6959 for ; Tue, 1 Feb 2011 08:21:47 -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 Wslnm2tZ74vU for ; Tue, 1 Feb 2011 08:21:46 -0800 (PST) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by core3.amsl.com (Postfix) with ESMTP id CCE2F3A6D27 for ; Tue, 1 Feb 2011 08:21:46 -0800 (PST) Received: from albook.hsd1.ca.comcast.net (c-67-164-126-174.hsd1.ca.comcast.net [67.164.126.174]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3AB5A36A017; Tue, 1 Feb 2011 08:25:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Tue, 1 Feb 2011 08:25:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5266FBC6-1B32-4EAD-990C-785F2CD8DB8A@icsi.berkeley.edu> References: <1296575340.1888.27.camel@mattlaptop2.local> To: Zack Weinberg X-Mailer: Apple Mail (2.1082) Cc: Phillip Hallam-Baker , keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 16:21:48 -0000 On Feb 1, 2011, at 8:21 AM, Zack Weinberg wrote: > On Tue, Feb 1, 2011 at 8:10 AM, Phillip Hallam-Baker = wrote: >> Let us assume that you are signing your domain with DNSSEC. >> It follows that clients will be able to determine with certainty that = a >> specific subdomain does not exist. >>=20 >> Thus it will be impossible for a client to obtain a valid A record or = SRV >> record or any other record that would enable a connection to be made. >> It follows that this is not an issue for subdomains that do not = exist. >> For domains that do exist, the administrator can add a CAA or DANE = record to >> express the desired semantics. >=20 > It occurs to me that there is currently no such thing as a DANE record > that expresses "there are no TLS-secured services provided by this > domain name" (or "...by this port"). Maybe there should be one? I > suggest that the record with hash type 0, cert type 0, and zero bytes > of certificate data could have this meaning. Under the _nnn._tcp.host > proposal being discussed in the other thread, you could then have >=20 > $ORIGIN example.com. >=20 > www A w.x.y.z > _443._tcp.www TLSA ( 1 2 ...hash... ) > *.www TLSA ( 0 0 ) >=20 > to indicate that 'www.example.com' provides HTTPS service with a > particular key, but does not provide any other secured service. Stupid question: Couldn't this be done with NSEC/NSEC3 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 34D0C3A6D27 for ; Tue, 1 Feb 2011 08:18:21 -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 4mqZxUHgfFHL for ; Tue, 1 Feb 2011 08:18:20 -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 165F63A6CCE for ; Tue, 1 Feb 2011 08:18:19 -0800 (PST) Received: by wwa36 with SMTP id 36so7664257wwa.13 for ; Tue, 01 Feb 2011 08:21:36 -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=xxZoD3R/vEbp5pD6pgkmBwBQdLY5fZdyOKFwgoCyc7Y=; b=naYKSbr675YxRlrcKmxru3EcBmUrkH4k5mo9bZ0zPsxsaGEgNigVb7a5qQCuO7fS4L 3YGDBrVHyJUvMIvg0/oLqz1BuK0Rmt46zcIcd8HQ1qxd+aypUWTCokQOQLVzqc2iL5k+ /KvbZJc5E84tX7Lor2bRVElCjedRDbnJpgV8Q= 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=oZjy9XXuU2rmHNLyWBGOrrvjfgKgzpWu3eneOns9RVKDqPobg4yVc0jRfZwrXXdJ0E cU4VqDioNrt5A5Bb2zZRSQiRAWz+udW3whOOI0snIcs1UTp7GjwO1AtQFxWGeXYDGze2 i2IPSnJJnZTqojTHbo+EbCisxavuVckZ2+3Qw= MIME-Version: 1.0 Received: by 10.227.2.208 with SMTP id 16mr7285608wbk.128.1296577296718; Tue, 01 Feb 2011 08:21:36 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.227.151.69 with HTTP; Tue, 1 Feb 2011 08:21:36 -0800 (PST) In-Reply-To: References: <1296575340.1888.27.camel@mattlaptop2.local> Date: Tue, 1 Feb 2011 08:21:36 -0800 X-Google-Sender-Auth: NSvdKosnM35kM2It0atgrZD43-k Message-ID: From: Zack Weinberg To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 16:18:21 -0000 On Tue, Feb 1, 2011 at 8:10 AM, Phillip Hallam-Baker wrote: > Let us assume that you are signing your domain with DNSSEC. > It follows that clients will be able to determine with certainty that a > specific subdomain does not exist. > > Thus it will be impossible for a client to obtain a valid A record or SRV > record or any other record that would enable a connection to be made. > It follows that this is not an issue for subdomains that do not exist. > For domains that do exist, the administrator can add a CAA or DANE record to > express the desired semantics. It occurs to me that there is currently no such thing as a DANE record that expresses "there are no TLS-secured services provided by this domain name" (or "...by this port"). Maybe there should be one? I suggest that the record with hash type 0, cert type 0, and zero bytes of certificate data could have this meaning. Under the _nnn._tcp.host proposal being discussed in the other thread, you could then have $ORIGIN example.com. www A w.x.y.z _443._tcp.www TLSA ( 1 2 ...hash... ) *.www TLSA ( 0 0 ) to indicate that 'www.example.com' provides HTTPS service with a particular key, but does not provide any other secured service. 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 063E83A6CCE for ; Tue, 1 Feb 2011 08:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, 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 aFGWBnaT+bjq for ; Tue, 1 Feb 2011 08:07:42 -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 821AA3A6C0B for ; Tue, 1 Feb 2011 08:07:42 -0800 (PST) Received: by yxt33 with SMTP id 33so2906019yxt.31 for ; Tue, 01 Feb 2011 08:10:59 -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=8i+/PgRxz/2KLSNHCXEuxgfHyUb45ZEJzlIppX37tbk=; b=ImSmCtj+Z79g28tw3XtWYQxcJ/fQza9otsNZvk9g5c6q3nALlRDUwCq2UVgyRS6wp+ b0qDkTQlSDEDMkjdDKlfRglXsi4iMCvD8o+/l5U72zcqBroww5nhMDh3xDFW/faYg2Ai 6nYUcBfzOrkVn41dEEI0+SLKEqqWrz/1A5aco= 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=ISP1TxEiBR99YcO03czM440g+P/iXdxH02gHMkk/VS+Ahi/stTa003Jxrv6E0QWWzJ 2lPewxoSYeFLanerkvOr+oDghBwrXQ2jV/3UXboBCZjGDjKx7xckq3wpuZRHICNw5n2s Hdqc1vh9FJBaUkr397ggL9aWqQ27DordqcKjk= MIME-Version: 1.0 Received: by 10.100.4.11 with SMTP id 11mr5101602and.52.1296576659272; Tue, 01 Feb 2011 08:10:59 -0800 (PST) Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 08:10:59 -0800 (PST) In-Reply-To: <1296575340.1888.27.camel@mattlaptop2.local> References: <1296575340.1888.27.camel@mattlaptop2.local> Date: Tue, 1 Feb 2011 11:10:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=0016e646526c3334e0049b3ac756 Cc: keyassure Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 16:07:44 -0000 --0016e646526c3334e0049b3ac756 Content-Type: text/plain; charset=ISO-8859-1 Let us assume that you are signing your domain with DNSSEC. It follows that clients will be able to determine with certainty that a specific subdomain does not exist. Thus it will be impossible for a client to obtain a valid A record or SRV record or any other record that would enable a connection to be made. It follows that this is not an issue for subdomains that do not exist. For domains that do exist, the administrator can add a CAA or DANE record to express the desired semantics. This is certainly an issue for CAA which deals with issue since it is entirely valid for a domain name holder to request a certificate for a subdomain before the subdomain is created. And so the rules for issuer processing of CAA records require a check at the public delegation point should the check at the domain fail. The cost of implementation in a client is rather higher since it has to maintain a list of public delegation points and has to perform verification in at least two places. Maintaining a list of public delegation points in a client is non trivial. In addition to the non trivial problem of adding/deleting points from the list it is necessary to have a means of distribution. On Tue, Feb 1, 2011 at 10:49 AM, Matt McCutchen wrote: > I would like to assert DANE exclusivity for the entire domain > mattmccutchen.net so that, with respect to clients that check DANE first > and fall back to a mainstream public CA list, a shady CA cannot > impersonate my existing TLS services /or/ fabricate TLS services I do > not offer. I know I can achieve that by adding enough wildcard dummy > TLSA records to cover the entire namespace as an automated > postprocessing step, but that is a little ugly. > > One solution would be to have the client, when no TLSA exists at the > desired host/transport/port after following CNAMEs, search from the host > name up for a "DANE options" record with an exclusivity flag (which > could be on or off). If no such record is found all the way up to the > root zone, the default is "off". Do people think this would be worth > the implementation effort and the extra queries? > > -- > Matt > > > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e646526c3334e0049b3ac756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let us assume that you are signing your domain with DNSSEC.

<= div>It follows that clients will be able to determine with certainty that a= specific subdomain does not exist.=A0

Thus it will be im= possible for a client to obtain a valid A record or SRV record or any other= record that would enable a connection to be made.

It follows that this is not an issue for subdomains tha= t do not exist.

For domains that do exist, the adm= inistrator can add a CAA or DANE record to express the desired semantics.


This is certainly an issue for CAA which= deals with issue since it is entirely valid for a domain name holder to re= quest a certificate for a subdomain before the subdomain is created. And so= the rules for issuer processing of CAA records require a check at the publ= ic delegation point should the check at the domain fail.


The cost of implementation in a client i= s rather higher since it has to maintain a list of public delegation points= and has to perform verification in at least two places.

Maintaining a list of public delegation points in a client is no= n trivial. In addition to the non trivial problem of adding/deleting points= from the list it is necessary to have a means of distribution.




On Tue, Feb 1, 2011 at 10:49 AM, Matt McCutchen <matt@mattmccutchen.net>= wrote:
I would like to assert DANE exclusivity for= the entire domain
mattmccutchen.net so that, with respect to clients that check DANE first
and fall back to a mainstream public CA list, a shady CA cannot
impersonate my existing TLS services /or/ fabricate TLS services I do
not offer. =A0I know I can achieve that by adding enough wildcard dummy
TLSA records to cover the entire namespace as an automated
postprocessing step, but that is a little ugly.

One solution would be to have the client, when no TLSA exists at the
desired host/transport/port after following CNAMEs, search from the host name up for a "DANE options" record with an exclusivity flag (whi= ch
could be on or off). =A0If no such record is found all the way up to the root zone, the default is "off". =A0Do people think this would be= worth
the implementation effort and the extra queries?

--
Matt


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



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

--0016e646526c3334e0049b3ac756-- 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 6D5193A6CCE for ; Tue, 1 Feb 2011 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.722 X-Spam-Level: X-Spam-Status: No, score=-0.722 tagged_above=-999 required=5 tests=[AWL=1.278, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 ZGzVsw3HmJ5C for ; Tue, 1 Feb 2011 08:04:59 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by core3.amsl.com (Postfix) with ESMTP id DBE613A6C3D for ; Tue, 1 Feb 2011 08:04:58 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id C135E17AA92; Tue, 1 Feb 2011 17:08:15 +0100 (CET) Received: from [IPv6:2001:610:158:1023:21d:72ff:feac:f5ab] (unknown [IPv6:2001:610:158:1023:21d:72ff:feac:f5ab]) by smtp.os3.nl (Postfix) with ESMTP id 917BE17AA8F; Tue, 1 Feb 2011 17:08:15 +0100 (CET) Message-ID: <4D482FEE.1090905@os3.nl> Date: Tue, 01 Feb 2011 17:08:14 +0100 From: Pieter Lange User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Ben Laurie References: <4D48246D.2040904@os3.nl> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org Subject: Re: [keyassure] Firefox 4 (beta) add-on for certificate validations using DNSSEC 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, 01 Feb 2011 16:05:00 -0000 I'm sorry, we didn't put up a link too clearly on the page. It's also added at the "For developers" section now. You can find our repository at https://os3sec.org/svn/ On 02/01/2011 05:00 PM, Ben Laurie wrote: > You invite people to submit patches, but where's the source? Did I miss a > link somewhere? > > On 1 February 2011 10:19, Pieter Lange wrote: > >> We're students from the System and Network Engineering master at the >> University of Amsterdam and have almost completed our one month project >> under supervision of NLnet. >> The topic was related to issue #8 (securing last hop) and other subjects >> you're discussing here, so we think you might be interested. >> >> During last month we've been following the list, reading your draft for >> securing TLS certificate associations and have implemented an add-on for >> the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC >> validator by NIC.CZ, but does much more. >> >> Actual DNSSEC trust chain validation is performed by implementing >> libunbound[2], unlike the original add-on -- that just checked if the >> 'ad' flag was set and by no means informed users that the 'ad' can be >> faked. >> >> Additionally, the add-on requests TXT and TLSA records for the same >> label. The TXT implementation is based on Dan Kaminsky's spec[3] as it >> is a nice showcase for what's possible. Note that we will remove support >> for TXT record lookup when dane is nearing consensus on all issues. >> >> The add-on currently only supports doing sha1 validation for both TXT >> and TLSA records; full certificates (cert type 2) or 'parent' (cert type >> 3/4) certificates are not supported. And there must be a thousand and >> one more things wrong with it; we are not by any means saying this is a >> proper way to verify certificates yet. Nor do we properly support the >> 'sts' flag in Kaminsky's specification because of a conflicting rule in >> the STS[4] draft specification (doesn't allow self signed certificates). >> >> We are very much aware that you focus on more than just HTTP, but still >> this add-on might prove to be a useful tool to evaluate the current drafts. >> >> Bug reports are very welcome but we haven't yet set up our bugtracker. >> Please have patience and if you have any immediate concerns contact us >> via email. >> >> You can find our add-on at https://os3sec.org, the website of our >> education can be found at https://www.os3.nl >> >> Regards, >> Danny Groenewegen & Pieter Lange >> >> [1] http://www.dnssec-validator.cz >> [2] http://www.unbound.net >> [3] http://dankaminsky.com/2010/12/19/dnssec-ch1/ >> [4] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-00 >> _______________________________________________ >> 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 F05063A6DFC for ; Tue, 1 Feb 2011 08:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 a4RPhhytLGcN for ; Tue, 1 Feb 2011 08:02:38 -0800 (PST) Received: from spg.kirei.se (gomi.kirei.se [91.206.174.9]) by core3.amsl.com (Postfix) with ESMTP id A950E3A6D42 for ; Tue, 1 Feb 2011 08:02:37 -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=fUTAN5KDKy/57zvIyfPz6bXN7ItYrHTg+miOuBsDmAU=; b=N1m6XcYrSVTk4ep2Rjzz/xT235MRIqf1JFfHWbRiDTjh4aJsigUKi9jDk/tEokolw0KWsSpYo9WCx CcIfXAdZR2p6Ta9PxQSx0GRcyRscJJ/4DNJp0QtMV7XhVkGvjuknMJp8jnYnnrjPlbZMAoqCr56Tns pCc/i7uUjuthcvHE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg.kirei.se (Halon Mail Gateway) with ESMTPS; Tue, 1 Feb 2011 17:05:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <1296575329.1888.26.camel@mattlaptop2.local> Date: Tue, 1 Feb 2011 17:05:51 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <4D481576.3040008@nic.cz> <1296575329.1888.26.camel@mattlaptop2.local> To: Matt McCutchen X-Mailer: Apple Mail (2.1082) Cc: keyassure Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 16:02:40 -0000 On 1 feb 2011, at 16.48, Matt McCutchen wrote: > I don't feel strongly about the syntax, but I like the consistency of > _443._tcp.example.com with SRV. +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 C44EF3A6B58 for ; Tue, 1 Feb 2011 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.335 X-Spam-Level: X-Spam-Status: No, score=-105.335 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, 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 07XHhElKv9qv for ; Tue, 1 Feb 2011 07:57:22 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 135BA3A6AC9 for ; Tue, 1 Feb 2011 07:57:21 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p11G0cu6004985 for ; Tue, 1 Feb 2011 08:00:38 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296576038; bh=Slq7XnWBaLxrIvpJl77UkUQBXPE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=swoGRoX0YF6NkwQG6T0uRhpxkEna+ygUtc3xewWXTWCh73bs903TBRf24ShNx7li4 Nv60nYCr3+mpvA6dzTJMA== Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by kpbe14.cbf.corp.google.com with ESMTP id p11G0aYV028460 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Feb 2011 08:00:37 -0800 Received: by qyk7 with SMTP id 7so4484527qyk.7 for ; Tue, 01 Feb 2011 08:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IGDUyBsxnM0OZAFMUy7YXkcgxjKz9+PPXQkmtU6BDzE=; b=T/97oanUgMtjq2PluXHQSsnpX6b1hqzjKjeilQq9tWYfsSc+oiNq2SuVqc+/sAknVp MV6sJ5U26C9/uaLLwdqw== 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; b=eyKitjIL9jDCdR4krt4mK734wIx8ywhlEpmUcRBOp32DzVXoqN567wbz/wavlMn+ap H/NRSebbKPrUJD+qw+Hw== MIME-Version: 1.0 Received: by 10.224.45.134 with SMTP id e6mr338248qaf.270.1296576035170; Tue, 01 Feb 2011 08:00:35 -0800 (PST) Received: by 10.220.88.137 with HTTP; Tue, 1 Feb 2011 08:00:35 -0800 (PST) In-Reply-To: <4D48246D.2040904@os3.nl> References: <4D48246D.2040904@os3.nl> Date: Tue, 1 Feb 2011 11:00:35 -0500 Message-ID: From: Ben Laurie To: Pieter Lange Content-Type: multipart/alternative; boundary=0015175ce032002c5d049b3aa23c X-System-Of-Record: true Cc: keyassure@ietf.org Subject: Re: [keyassure] Firefox 4 (beta) add-on for certificate validations using DNSSEC 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, 01 Feb 2011 15:57:25 -0000 --0015175ce032002c5d049b3aa23c Content-Type: text/plain; charset=ISO-8859-1 You invite people to submit patches, but where's the source? Did I miss a link somewhere? On 1 February 2011 10:19, Pieter Lange wrote: > We're students from the System and Network Engineering master at the > University of Amsterdam and have almost completed our one month project > under supervision of NLnet. > The topic was related to issue #8 (securing last hop) and other subjects > you're discussing here, so we think you might be interested. > > During last month we've been following the list, reading your draft for > securing TLS certificate associations and have implemented an add-on for > the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC > validator by NIC.CZ, but does much more. > > Actual DNSSEC trust chain validation is performed by implementing > libunbound[2], unlike the original add-on -- that just checked if the > 'ad' flag was set and by no means informed users that the 'ad' can be > faked. > > Additionally, the add-on requests TXT and TLSA records for the same > label. The TXT implementation is based on Dan Kaminsky's spec[3] as it > is a nice showcase for what's possible. Note that we will remove support > for TXT record lookup when dane is nearing consensus on all issues. > > The add-on currently only supports doing sha1 validation for both TXT > and TLSA records; full certificates (cert type 2) or 'parent' (cert type > 3/4) certificates are not supported. And there must be a thousand and > one more things wrong with it; we are not by any means saying this is a > proper way to verify certificates yet. Nor do we properly support the > 'sts' flag in Kaminsky's specification because of a conflicting rule in > the STS[4] draft specification (doesn't allow self signed certificates). > > We are very much aware that you focus on more than just HTTP, but still > this add-on might prove to be a useful tool to evaluate the current drafts. > > Bug reports are very welcome but we haven't yet set up our bugtracker. > Please have patience and if you have any immediate concerns contact us > via email. > > You can find our add-on at https://os3sec.org, the website of our > education can be found at https://www.os3.nl > > Regards, > Danny Groenewegen & Pieter Lange > > [1] http://www.dnssec-validator.cz > [2] http://www.unbound.net > [3] http://dankaminsky.com/2010/12/19/dnssec-ch1/ > [4] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-00 > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > --0015175ce032002c5d049b3aa23c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You invite people to submit patches, but where's the source? Did I miss= a link somewhere?

On 1 February 2011 10:= 19, Pieter Lange <pieter.lange@os3.nl> wrote:
We're students from the System and Netw= ork Engineering master at the
University of Amsterdam and have almost completed our one month project
under supervision of NLnet.
The topic was related to issue #8 (securing last hop) and other subjects you're discussing here, so we think you might be interested.

During last month we've been following the list, reading your draft for=
securing TLS certificate associations and have implemented an add-on for the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC
validator by NIC.CZ, but do= es much more.

Actual DNSSEC trust chain validation is performed by implementing
libunbound[2], unlike the original add-on -- that just checked if the
'ad' flag was set and by no means informed users that the 'ad&#= 39; can be faked.

Additionally, the add-on requests TXT and TLSA records for the same
label. The TXT implementation is based on Dan Kaminsky's spec[3] as it<= br> is a nice showcase for what's possible. Note that we will remove suppor= t
for TXT record lookup when dane is nearing consensus on all issues.

The add-on currently only supports doing sha1 validation for both TXT
and TLSA records; full certificates (cert type 2) or 'parent' (cert= type
3/4) certificates are not supported. And there must be a thousand and
one more things wrong with it; we are not by any means saying this is a
proper way to verify certificates yet. Nor do we properly support the
'sts' flag in Kaminsky's specification because of a conflicting= rule in
the STS[4] draft specification (doesn't allow self signed certificates)= .

We are very much aware that you focus on more than just HTTP, but still
this add-on might prove to be a useful tool to evaluate the current drafts.=

Bug reports are very welcome but we haven't yet set up our bugtracker.<= br> Please have patience and if you have any immediate concerns contact us
via email.

You can find our add-on at https://os3sec.org, the website of our
education can be found at = https://www.os3.nl

Regards,
Danny Groenewegen & Pieter Lange

[1] http://www= .dnssec-validator.cz
[2] http://www.unbound= .net
[3] http://dankaminsky.com/2010/12/19/dnssec-ch1/
[4] http://tools.ietf.org/html/draft-ietf-websec-st= rict-transport-sec-00
_______________________________________________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure

--0015175ce032002c5d049b3aa23c-- 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 DEB843A6C28 for ; Tue, 1 Feb 2011 07:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW1CWc434mXY for ; Tue, 1 Feb 2011 07:47:12 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id C26D93A6E42 for ; Tue, 1 Feb 2011 07:46:00 -0800 (PST) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 213CA10AFAB for ; Tue, 1 Feb 2011 07:49:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=W0UP64+0Mgz+0OP7en2tBfK7BSI4kOoKiIasTm/S0Lm DyOfI3NPQNnLAzdPANAIkWGkMiop4eWS4tPUNT8E+ngvO+S+2JctwdJVPIkY91AW mhWF+tS1mjQXyyjR0D8XzAbncyEdcoGVAIjKLXwxKxRHpTQbquk1xNiVEkWh/P9Q = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=RWK2eKsaZd5VIQmTKONti49onkE=; b=AN2UIFLyCt WxraYMNAUyyGibP+UYPv+wOLUo43MWyEiTdbv/h4UmPaTFrpQ3FU9sY7ZMmZTOYv i9cGMJatsBSVPd+Rxt7mGqPIx81AkJkTby2RWHPkL+OoeXxsOnRe32Od1weAwFcj 5PC2w6REBa86EsVo5wJCVYU8654ndDxUE= Received: from [192.168.1.10] (static-173-66-73-45.washdc.fios.verizon.net [173.66.73.45]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPA id B104A10AFA5 for ; Tue, 1 Feb 2011 07:49:17 -0800 (PST) From: Matt McCutchen To: keyassure@ietf.org In-Reply-To: <4D481641.6090604@nic.cz> References: <4D481641.6090604@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 10:49:16 -0500 Message-ID: <1296575356.1888.28.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable Subject: Re: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org 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, 01 Feb 2011 15:47:13 -0000 On Tue, 2011-02-01 at 15:18 +0100, Ond=C5=99ej Sur=C3=BD wrote:=20 > I would like to ask the listmaster to rename the mailing list to=20 > dane@ietf.org to keep it with sync with the WG name. >=20 > Any objections? Not from me. Just please make sure that the old archive redirects to the new so that the links in our mails from the past few months do not all break. Hopefully that is standard practice. --=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 E93EF3A6C28 for ; Tue, 1 Feb 2011 07:45:44 -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 wmVG0WVv6qn7 for ; Tue, 1 Feb 2011 07:45:44 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 462323A6DFC for ; Tue, 1 Feb 2011 07:45:44 -0800 (PST) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 9B33757806C for ; Tue, 1 Feb 2011 07:49:01 -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=tqwATut 03pI7P0YubOVMfDmMlCVC3Nx1rVTLI9LvMl/8aYRvX+CQFrvuCuUSAwZ9Jy1bCXw VORi6T/3JW1ZG6oZg8Xvzg9Y/Eg0/7he29Q4qPZuOg0CVRQjKgB9ADBL7MLfgA/R VYjaU3z3ri0BWjwjYjJTScKkiTO6fams+0OY= 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=5mSzm6iWTkDLZ PR87NUmy0bllHY=; b=i0UP+N3msFv3R8QQGJ1wu1SBl4c2bD7+/MV1mb09m2N4J alqc2bqKlrNTmOiUlaMrvO7IviHh3yRi0hZ+njQ4Ab/Qg28g3dlYXafz9lwSq4N8 pi3MMR+H9EGSNoxq9UYpscB66jHx8S/eElf/6tTlxwJre3VhYc+OTMTNyF0Dsw= Received: from [192.168.1.10] (static-173-66-73-45.washdc.fios.verizon.net [173.66.73.45]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 23430578073 for ; Tue, 1 Feb 2011 07:49:01 -0800 (PST) From: Matt McCutchen To: keyassure Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 10:49:00 -0500 Message-ID: <1296575340.1888.27.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: [keyassure] Asserting DANE exclusivity for an entire domain 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, 01 Feb 2011 15:45:45 -0000 I would like to assert DANE exclusivity for the entire domain mattmccutchen.net so that, with respect to clients that check DANE first and fall back to a mainstream public CA list, a shady CA cannot impersonate my existing TLS services /or/ fabricate TLS services I do not offer. I know I can achieve that by adding enough wildcard dummy TLSA records to cover the entire namespace as an automated postprocessing step, but that is a little ugly. One solution would be to have the client, when no TLSA exists at the desired host/transport/port after following CNAMEs, search from the host name up for a "DANE options" record with an exclusivity flag (which could be on or off). If no such record is found all the way up to the root zone, the default is "off". Do people think this would be worth the implementation effort and the extra queries? -- 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 867903A6E42 for ; Tue, 1 Feb 2011 07:45:34 -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 0y+LR+37+M0p for ; Tue, 1 Feb 2011 07:45:33 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 9216F3A6E3C for ; Tue, 1 Feb 2011 07:45:33 -0800 (PST) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id DB7E034806C for ; Tue, 1 Feb 2011 07:48:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=aLdy5REe9uvNvtbKVUhPWA2qq6J9d2VU5IlTzWesDF3 pQCxrYUu7DDNmQ0wffInuGuM54zGZWENUzWNviYf7Byo0bH3DtDndGXUCioHW90R Ra6QShnjuzNGpMKGjymdIhVE4g9y/Fd/WMnKBSEOnJrgGFI3olqLwcAEQ6Lu0srs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=jVGISkR437uc0Vsjpk/bInM9G9M=; b=ZIuDudtUK8 AKYB1OMS2d2FetTdbYfw0szKCIZX3pHrpFEF5IZQhnhwRWvrkeIl0sCKorOMnoUy RaWI7uMAQ1u/SqQD9Q+8b+OE5tJO3lltUYB9iG270LMg/X80hNXa88ikz/wG45C6 25728/LcyyJ0jXR/RpiWC1dcJAVakDbb4= Received: from [192.168.1.10] (static-173-66-73-45.washdc.fios.verizon.net [173.66.73.45]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id 9B68334806B for ; Tue, 1 Feb 2011 07:48:50 -0800 (PST) From: Matt McCutchen To: keyassure In-Reply-To: <4D481576.3040008@nic.cz> References: <4D481576.3040008@nic.cz> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 10:48:49 -0500 Message-ID: <1296575329.1888.26.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 15:45:34 -0000 On Tue, 2011-02-01 at 15:15 +0100, Ond=C5=99ej Sur=C3=BD wrote:=20 > I would like to call for consensus on issue #1. >=20 > The consensus would be that the draft-dane-protocol would define lookup= =20 > on TLSA records as query for a name prefixed with a port or port and pr= oto. >=20 > Possible examples (no preference here for issue #1): > _443.www.example.com > _443._tcp.example.com > _tcp_443.example.com. >=20 > I will open separate issue# for the particular solution for querying=20 > (proto or not, fallback or not, etc.), since I don't think we have=20 > consensus on that yet. (And I think we should step forward constantly=20 > even in small steps.) Are we going to talk about the specifics next? I would vote for always including the transport protocol. The client and DNS admin both know what protocol they are using, so there is no reason not to include it; having a fallback without the protocol is just extra complexity. The possibility of having two different services using different transport protocols with the same port number seems remote now, but we don't know what the future might hold for transport protocols so I think we might as well do this right. I don't feel strongly about the syntax, but I like the consistency of _443._tcp.example.com with SRV. --=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 514A13A6C0F for ; Tue, 1 Feb 2011 07:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=0.256, 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 KLFLo-Ylq0qS for ; Tue, 1 Feb 2011 07:39:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 338073A6B58 for ; Tue, 1 Feb 2011 07:39:10 -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 44E4C734446 for ; Tue, 1 Feb 2011 16:42:26 +0100 (CET) Message-ID: <4D4829E2.9080907@nic.cz> Date: Tue, 01 Feb 2011 16:42:26 +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: <4D481576.3040008@nic.cz> <5C2AE6F6-4FB2-457A-B644-209975676638@insensate.co.uk> In-Reply-To: <5C2AE6F6-4FB2-457A-B644-209975676638@insensate.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 15:39:12 -0000 On 1.2.2011 16:31, Lawrence Conroy wrote: > Hi There OndÅ™ej, folks, > did you mean example 3 to have no dot between the _tcp and _443 (i.e. to be one label, rather than two)? Yes. > I have no problem with example 2 (or example 1), but example 3 is confusing and/or less pleasing. I new I shouldn't add examples there :). On 1.2.2011 16:31, Martin Rex wrote: > I'm confused; shouldn't this read > > a _443.www.example.com > b _443._tcp.www.example.com > c _tcp_443.www.example.com Yes, it should. > What would be easier on the DNS administration (software, handling > and understanding): (b) or (c) ? I knew I shouldn't add the examples to my call for consensus :-). This call was only about if: a) we want to go the DNS prefix way (_prefix._hostname) b) something else (just _hostname, SRV, etc.) My understanding from reading the thread was that the general opinion (except Paul W.) was to go the DNS prefix way. O. > On 1 Feb 2011, at 14:15, OndÅ™ej Surý wrote: >> Hi, >> >> I would like to call for consensus on issue #1. >> >> The consensus would be that the draft-dane-protocol would define lookup on TLSA records as query for a name prefixed with a port or port and proto. >> >> Possible examples (no preference here for issue #1): >> _443.www.example.com >> _443._tcp.example.com >> _tcp_443.example.com. >> >> I will open separate issue# for the particular solution for querying (proto or not, fallback or not, etc.), since I don't think we have consensus on that yet. (And I think we should step forward constantly even in small steps.) >> >> 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 > -- 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 1701F3A6C1D for ; Tue, 1 Feb 2011 07:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 EdLPvSNzndew for ; Tue, 1 Feb 2011 07:28:10 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id B01B03A6C11 for ; Tue, 1 Feb 2011 07:28:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B830FD70FF; Tue, 1 Feb 2011 15:31:25 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUn-jGSR2fhE; Tue, 1 Feb 2011 15:31:25 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 0F829D70F4; Tue, 1 Feb 2011 15:31:25 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=utf-8 From: Lawrence Conroy In-Reply-To: <4D481576.3040008@nic.cz> Date: Tue, 1 Feb 2011 15:31:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5C2AE6F6-4FB2-457A-B644-209975676638@insensate.co.uk> References: <4D481576.3040008@nic.cz> To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= X-Mailer: Apple Mail (2.1082) Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 15:28:11 -0000 Hi There Ond=C5=99ej, folks, did you mean example 3 to have no dot between the _tcp and _443 (i.e. = to be one label, rather than two)? I have no problem with example 2 (or example 1), but example 3 is = confusing and/or less pleasing. all the best, Lawrence On 1 Feb 2011, at 14:15, Ond=C5=99ej Sur=C3=BD wrote: > Hi, >=20 > I would like to call for consensus on issue #1. >=20 > The consensus would be that the draft-dane-protocol would define = lookup on TLSA records as query for a name prefixed with a port or port = and proto. >=20 > Possible examples (no preference here for issue #1): > _443.www.example.com > _443._tcp.example.com > _tcp_443.example.com. >=20 > I will open separate issue# for the particular solution for querying = (proto or not, fallback or not, etc.), since I don't think we have = consensus on that yet. (And I think we should step forward constantly = even in small steps.) >=20 > Ondrej > --=20 > Ond=C5=99ej Sur=C3=BD > vedouc=C3=AD v=C3=BDzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > _______________________________________________ > 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 EABCB3A6C0F for ; Tue, 1 Feb 2011 07:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.004 X-Spam-Level: X-Spam-Status: No, score=-10.004 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 Rw+ih7WlJPFf for ; Tue, 1 Feb 2011 07:27:57 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id CB2123A6C1A for ; Tue, 1 Feb 2011 07:27:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p11FVC6i015140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 16:31:13 +0100 (MET) From: Martin Rex Message-Id: <201102011531.p11FVC1l029404@fs4113.wdf.sap.corp> To: ondrej.sury@nic.cz (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=) Date: Tue, 1 Feb 2011 16:31:12 +0100 (MET) In-Reply-To: <4D481576.3040008@nic.cz> from "=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=" at Feb 1, 11 03:15:18 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] Call for consensus on #1 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 15:27:58 -0000 =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= wrote: > > The consensus would be that the draft-dane-protocol would define lookup > on TLSA records as query for a name prefixed with a port or port and proto. > > Possible examples (no preference here for issue #1): > _443.www.example.com > _443._tcp.example.com > _tcp_443.example.com. I'm confused; shouldn't this read a _443.www.example.com b _443._tcp.www.example.com c _tcp_443.www.example.com What would be easier on the DNS administration (software, handling and understanding): (b) or (c) ? -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 45CB93A6D0E for ; Tue, 1 Feb 2011 07:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.555 X-Spam-Level: X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, SARE_OBFU_AMP2B=2.555] 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 8UHmrQW8w-An for ; Tue, 1 Feb 2011 07:16:20 -0800 (PST) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by core3.amsl.com (Postfix) with ESMTP id 209873A6CF4 for ; Tue, 1 Feb 2011 07:15:54 -0800 (PST) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 145F317AA92 for ; Tue, 1 Feb 2011 16:19:10 +0100 (CET) Received: from [IPv6:2001:610:158:1023:21d:72ff:feac:f5ab] (unknown [IPv6:2001:610:158:1023:21d:72ff:feac:f5ab]) by smtp.os3.nl (Postfix) with ESMTP id DFE8B17AA8F; Tue, 1 Feb 2011 16:19:09 +0100 (CET) Message-ID: <4D48246D.2040904@os3.nl> Date: Tue, 01 Feb 2011 16:19:09 +0100 From: Pieter Lange User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: keyassure@ietf.org, Danny Groenewegen X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [keyassure] Firefox 4 (beta) add-on for certificate validations using DNSSEC 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, 01 Feb 2011 15:16:21 -0000 We're students from the System and Network Engineering master at the University of Amsterdam and have almost completed our one month project under supervision of NLnet. The topic was related to issue #8 (securing last hop) and other subjects you're discussing here, so we think you might be interested. During last month we've been following the list, reading your draft for securing TLS certificate associations and have implemented an add-on for the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC validator by NIC.CZ, but does much more. Actual DNSSEC trust chain validation is performed by implementing libunbound[2], unlike the original add-on -- that just checked if the 'ad' flag was set and by no means informed users that the 'ad' can be faked. Additionally, the add-on requests TXT and TLSA records for the same label. The TXT implementation is based on Dan Kaminsky's spec[3] as it is a nice showcase for what's possible. Note that we will remove support for TXT record lookup when dane is nearing consensus on all issues. The add-on currently only supports doing sha1 validation for both TXT and TLSA records; full certificates (cert type 2) or 'parent' (cert type 3/4) certificates are not supported. And there must be a thousand and one more things wrong with it; we are not by any means saying this is a proper way to verify certificates yet. Nor do we properly support the 'sts' flag in Kaminsky's specification because of a conflicting rule in the STS[4] draft specification (doesn't allow self signed certificates). We are very much aware that you focus on more than just HTTP, but still this add-on might prove to be a useful tool to evaluate the current drafts. Bug reports are very welcome but we haven't yet set up our bugtracker. Please have patience and if you have any immediate concerns contact us via email. You can find our add-on at https://os3sec.org, the website of our education can be found at https://www.os3.nl Regards, Danny Groenewegen & Pieter Lange [1] http://www.dnssec-validator.cz [2] http://www.unbound.net [3] http://dankaminsky.com/2010/12/19/dnssec-ch1/ [4] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-00 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 074B23A6D1C for ; Tue, 1 Feb 2011 07:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.063, 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 IVC1ExJ+u3Dy for ; Tue, 1 Feb 2011 07:08:09 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 194843A6CEA for ; Tue, 1 Feb 2011 07:08:09 -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 D25DC1ECB422; Tue, 1 Feb 2011 15:11:25 +0000 (UTC) Date: Tue, 1 Feb 2011 10:11:24 -0500 From: Andrew Sullivan To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20110201151124.GC3928@shinkuro.com> References: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> <4D481C46.7020009@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D481C46.7020009@nic.cz> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: keyassure@ietf.org Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 15:08:14 -0000 On Tue, Feb 01, 2011 at 03:44:22PM +0100, OndÅ™ej Surý wrote: > But I am fine with withdrawing the call if there is not enough support > to go in those smaller steps. No, I have no complaint about the call, and I think it's wise to try to separate these things for clarity. I just meant that I don't know they're quite as separable in fact as in principle. 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 D6FD83A6BED for ; Tue, 1 Feb 2011 06:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.272, 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 rqMZJQet-Zth for ; Tue, 1 Feb 2011 06:41: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 678BE3A6CEA for ; Tue, 1 Feb 2011 06:41:06 -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 C31EA7343C9 for ; Tue, 1 Feb 2011 15:44:22 +0100 (CET) Message-ID: <4D481C46.7020009@nic.cz> Date: Tue, 01 Feb 2011 15:44:22 +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: <4D481576.3040008@nic.cz> <20110201142237.GA3135@shinkuro.com> In-Reply-To: <20110201142237.GA3135@shinkuro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 14:41:22 -0000 On 1.2.2011 15:22, Andrew Sullivan wrote: > On Tue, Feb 01, 2011 at 03:15:18PM +0100, OndÅ™ej Surý wrote: >> The consensus would be that the draft-dane-protocol would define lookup >> on TLSA records as query for a name prefixed with a port or port and >> proto. >> >> Possible examples (no preference here for issue #1): >> _443.www.example.com >> _443._tcp.example.com >> _tcp_443.example.com. >> >> I will open separate issue# for the particular solution for querying >> (proto or not, fallback or not, etc.), since I don't think we have >> consensus on that yet. (And I think we should step forward constantly >> even in small steps.) > > I'm not actually sure that these issues can be separated, since two of > the examples include the proto and one does not. I prefer the 2d > arrangement, personally, because it's cleaner from the DNS point of > view. I was planning to open separate issue# on what to include into DNS name after we get consensus on that we want to have solution based on prefix+hostname in QNAME. As opposed to just having hostname in QNAME, or some interaction with SRV record. I felt that if we slowly narrow the topic it will not divert that much in the mailing list. But I am fine with withdrawing the call if there is not enough support to go in those smaller steps. 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 EB89A3A6CDC for ; Tue, 1 Feb 2011 06:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 3In8zksOKdar for ; Tue, 1 Feb 2011 06:19:24 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 348F13A6BA3 for ; Tue, 1 Feb 2011 06:19:24 -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 C166B1ECB422 for ; Tue, 1 Feb 2011 14:22:40 +0000 (UTC) Date: Tue, 1 Feb 2011 09:22:39 -0500 From: Andrew Sullivan To: keyassure@ietf.org Message-ID: <20110201142237.GA3135@shinkuro.com> References: <4D481576.3040008@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D481576.3040008@nic.cz> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [keyassure] Call for consensus on #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, 01 Feb 2011 14:19:25 -0000 On Tue, Feb 01, 2011 at 03:15:18PM +0100, OndÅ™ej Surý wrote: > The consensus would be that the draft-dane-protocol would define lookup > on TLSA records as query for a name prefixed with a port or port and > proto. > > Possible examples (no preference here for issue #1): > _443.www.example.com > _443._tcp.example.com > _tcp_443.example.com. > > I will open separate issue# for the particular solution for querying > (proto or not, fallback or not, etc.), since I don't think we have > consensus on that yet. (And I think we should step forward constantly > even in small steps.) I'm not actually sure that these issues can be separated, since two of the examples include the proto and one does not. I prefer the 2d arrangement, personally, because it's cleaner from the DNS point of view. -- 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 B59683A6C96 for ; Tue, 1 Feb 2011 06:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.283 X-Spam-Level: X-Spam-Status: No, score=-0.283 tagged_above=-999 required=5 tests=[AWL=-0.997, 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 HwlHz2n0MmWE for ; Tue, 1 Feb 2011 06:15:25 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id AA1A63A6C00 for ; Tue, 1 Feb 2011 06:15:25 -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 1AD4A7343C9 for ; Tue, 1 Feb 2011 15:18:42 +0100 (CET) Message-ID: <4D481641.6090604@nic.cz> Date: Tue, 01 Feb 2011 15:18:41 +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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] Administrivia: Rename the mailing list to dane@ietf.org 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, 01 Feb 2011 14:15:26 -0000 Hi, I would like to ask the listmaster to rename the mailing list to dane@ietf.org to keep it with sync with the WG name. Any objections? I'll keep you posted on the dates, etc. when I know more details. 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 F20C43A6D22 for ; Tue, 1 Feb 2011 06:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_05=-1.11, 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 0Gdr5Z-2tfmX for ; Tue, 1 Feb 2011 06:12:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id 42FDC3A6D20 for ; Tue, 1 Feb 2011 06:12:02 -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 8EB9D7343C9 for ; Tue, 1 Feb 2011 15:15:18 +0100 (CET) Message-ID: <4D481576.3040008@nic.cz> Date: Tue, 01 Feb 2011 15:15:18 +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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [keyassure] Call for consensus on #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, 01 Feb 2011 14:12:07 -0000 Hi, I would like to call for consensus on issue #1. The consensus would be that the draft-dane-protocol would define lookup on TLSA records as query for a name prefixed with a port or port and proto. Possible examples (no preference here for issue #1): _443.www.example.com _443._tcp.example.com _tcp_443.example.com. I will open separate issue# for the particular solution for querying (proto or not, fallback or not, etc.), since I don't think we have consensus on that yet. (And I think we should step forward constantly even in small steps.) 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 28B5A3A6CDE for ; Tue, 1 Feb 2011 05:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 uNND6UlLXMsP for ; Tue, 1 Feb 2011 05:58:08 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 1F1263A6C00 for ; Tue, 1 Feb 2011 05:58:08 -0800 (PST) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 43A0628006D for ; Tue, 1 Feb 2011 06:01:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=HGhFSNiJqDwCAsjQ9T4v1dabLBOTwsYVaIlw9wJpDoV GyFAw6WM5MkpO64FWuPRmMz2ksAPEygLniuPjlbMjl+xZRpaJ3dn7qtMenOpfxd0 J7i1sHDSl50vhUUnOkzrG3wkFAq2B9PwhZx6ipsV9hXkjD0Ynm+iPi2hKpz+1t4I = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=JzCaOQoXiiA3gJDOChzoQ1Mo5QY=; b=dePhYJvv6a LRqkFcd2Tqh7z1B4EBOVMwSlh42/Q2sAAP2821josl+cjh1/MWZQVvtvVSln4j/h uP+Vd+Li6eRXx+0xKV15xd+hC7rp/XuQS1+uMW438WhONiP94v0M/X79dUIJcVjH n5Wz6GVi3rNLx+H4i6wQGFyUh1q1G1oaw= Received: from [10.108.64.61] (unknown [129.2.129.80]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 0AD5C280061 for ; Tue, 1 Feb 2011 06:01:24 -0800 (PST) From: Matt McCutchen To: keyassure 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> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Feb 2011 09:01:23 -0500 Message-ID: <1296568884.2012.39.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 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, 01 Feb 2011 13:58:09 -0000 On Thu, 2011-01-27 at 12:14 -0500, 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. Let's subdivide: 1a: Each record is acceptable for any port. 1b: Each record says which port it is for. > 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. Philosophically, I prefer 2 including the transport protocol (to spell everything out) because the client asks for precisely the information it needs. Compared to 1b, the different owner names might make it easier for the various services to automatically administer their own TLSA records (as Phill envisioned) without stepping on each other. The only problem is making 2 work with CNAMEs and wildcards, the same problem faced by SRV. (IMO, it's a pity this interaction wasn't specified the way we want originally, but there might be other considerations I'm not aware of.) Phill described some grand plans. I would just propose that the client check for CNAME at www.example.com or TLSA at _443._tcp.www.example.com in unspecified order (they should not both exist), and if a CNAME at www.example.com is found, query the prefixed version of the target name. The client would not honor a CNAME at _443._tcp.www.example.com. DNS admins who want to apply TLSA to a wildcard set of host names can use a wildcard CNAME first and then put the TLSA at the target name. I am unhappy with 1a. I wouldn't like to build the assumption that ports at the same host name are at the same security level into DANE, and I really don't see what's so hard about specifying the port on which you are going to use the certificate. And quite apart from security levels, binding a different certificate to each port is the only way to prevent connection diversion among ports at the TLS level (where it should be prevented) since SNI currently does not do ports. -- 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 86EDB3A6CC1 for ; Tue, 1 Feb 2011 03:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 Fvg6JBin-zCY for ; Tue, 1 Feb 2011 03:19:57 -0800 (PST) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) by core3.amsl.com (Postfix) with ESMTP id A1E4C3A6CC8 for ; Tue, 1 Feb 2011 03:19:56 -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 4AF61EF754; Tue, 1 Feb 2011 13:23:11 +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 A0720048849; Tue, 01 Feb 2011 13:23:11 +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 861D027D87; Tue, 1 Feb 2011 13:23:08 +0200 (EET) Date: Tue, 1 Feb 2011 13:22:59 +0200 From: Ilari Liusvaara To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Message-ID: <20110201112259.GA27979@LK-Perkele-VI.localdomain> References: <2DDAD3E3-6378-4C29-AFA2-A860CD652ED4@kumari.net> <4D46DAEA.5040606@nic.cz> <87lj21f345.fsf@latte.josefsson.org> <4D47DD21.4020709@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D47DD21.4020709@nic.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Ilari Liusvaara Content-Transfer-Encoding: quoted-printable 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: Tue, 01 Feb 2011 11:19:58 -0000 On Tue, Feb 01, 2011 at 11:14:57AM +0100, Ond=C5=99ej Sur=C3=BD wrote: > On 31.1.2011 17:29, Simon Josefsson wrote: > >Ond=C5=99ej Sur=C3=BD 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? >=20 > You can have multiple https and multiple pop3s running on the same > machine? But you're probably right. To be useful that would require multiple services with distinct keys sharing the same port(!). Without explicit muxing like tcpmux (tcp/1; who uses that anymore???) it would be seriously fragile (or downright impossible) with many service pairs (server goes first services, services that can't be reliably be sniffed). If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say, ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and 995 and 996 for POP3S. That would give four ports, 80, 443, 995 and 996 with no conflicts that would need service labels. So I don't see any need for service labels unless supporting seriously obsolete stuff like tcpmux. Port labels are enough. -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 7F2F43A6C40 for ; Tue, 1 Feb 2011 02:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=0.185, 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 IbQG6qSe7luh for ; Tue, 1 Feb 2011 02:11: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 5238F3A6C3C for ; Tue, 1 Feb 2011 02:11: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 35DBA7342DE for ; Tue, 1 Feb 2011 11:14:58 +0100 (CET) Message-ID: <4D47DD21.4020709@nic.cz> Date: Tue, 01 Feb 2011 11:14:57 +0100 From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= 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> <4D46DAEA.5040606@nic.cz> <87lj21f345.fsf@latte.josefsson.org> In-Reply-To: <87lj21f345.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-2; 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, 01 Feb 2011 10:11:43 -0000 On 31.1.2011 17:29, Simon Josefsson wrote: > Ondøej Surý 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? You can have multiple https and multiple pop3s running on the same machine? But you're probably right. >> 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. /me too :) > 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. The bad thing is that it doesn't only destroy flexibility, but it also destroys the security (the _443.www would be authenticated by www TLSA record). Is this fear of bad implementation shared among other members of the DANE? Isn't that more of issue a security warning, a CVE number and force the vendor to fix it? 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 2A5813A6B2F for ; Tue, 1 Feb 2011 02:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 2fYT3lzXpIg2 for ; Tue, 1 Feb 2011 02:07:32 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id B6F863A68F3 for ; Tue, 1 Feb 2011 02:07:31 -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 850B47342DE for ; Tue, 1 Feb 2011 11:10:46 +0100 (CET) Message-ID: <4D47DC26.3060004@nic.cz> Date: Tue, 01 Feb 2011 11:10:46 +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> <4D46DAEA.5040606@nic.cz> <87hbcpf2pw.fsf@latte.josefsson.org> <201101312005.p0VK5G3s022244@new.toad.com> In-Reply-To: <201101312005.p0VK5G3s022244@new.toad.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [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: Tue, 01 Feb 2011 10:07:33 -0000 On 31.1.2011 21:05, John Gilmore wrote: > 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. I don't think that anybody said that the modification of the DNS server-side algorithm is a requirement for DANE work. It could be viewed as a nice-to-have optimization (which is same for A+AAAA or any other attempts which didn't go through the dnsext), but that's really an DNSEXT work and we should not even slightly assume that this will ever happen. (But yes, EDNSx which would allow multiple queries (f.e. just in-the-bailiwick) would be nice to have, but it also would have to be very carefully designed.) Anyway everybody please let's stick to the topic which is Issue#1, thanks. 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 4391A3A6957 for ; Sun, 27 Feb 2011 08:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU+5QNoB1LHq for ; Sun, 27 Feb 2011 08:40:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 863903A694D for ; Sun, 27 Feb 2011 08:40:37 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Ptjgd-00033L-3l; Sun, 27 Feb 2011 08:41:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dane issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: warren@kumari.net X-Trac-Project: dane Date: Sun, 27 Feb 2011 16:41:35 -0000 X-URL: http://tools.ietf.org/dane/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dane/trac/ticket/19#comment:2 Message-ID: <065.9e87ed003130253eaaacbe2efdbc8643@trac.tools.ietf.org> References: <056.77019b0afb5ddfee6d29362d466d5d39@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <056.77019b0afb5ddfee6d29362d466d5d39@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: warren@kumari.net, keyassure@ietf.org X-SA-Exim-Mail-From: trac+dane@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 01 Mar 2011 09:47:58 -0800 Cc: keyassure@ietf.org Subject: Re: [keyassure] [dane] #19: Format for TLSA DNS lookup. X-BeenThere: keyassure@ietf.org X-Mailman-Version: 2.1.9 List-Id: Key Assurance With DNSSEC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 16:40:38 -0000 #19: Format for TLSA DNS lookup. Changes (by warren@…): * status: new => closed * resolution: => fixed -- -------------------------------+-------------------------------------------- Reporter: warren@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: protocol | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------+-------------------------------------------- Ticket URL: dane