From jakob@kirei.se Fri Jun 1 02:03:16 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864BE21F8644 for ; Fri, 1 Jun 2012 02:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCDYP8x8ifIT for ; Fri, 1 Jun 2012 02:03:15 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2DA21F8649 for ; Fri, 1 Jun 2012 02:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=3V7bTfP0CX98ifA25zSA2UUW5C1JS0Td66LGa3YJeuU=; b=vgnJBqEIxDA0s/773scY33MQDZRNToklCOQDjyrB88WCYrcUSIU9PY/LprYjRDb469Az8knRelZ0H Qu/BMxGDEwCXrl6SldQb0Z4wgln7cj4jwP41ZY3WTnN7IUp7Dv+rrPr3R+E6pytkqn8VO6oCxdS9XZ itRbk3gY+gGqdDEY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Fri, 1 Jun 2012 11:03:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jakob Schlyter In-Reply-To: <4FC8073C.1030500@stpeter.im> Date: Fri, 1 Jun 2012 11:03:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <77972E9E-24D3-43E0-845C-93A4F3F572E4@kirei.se> References: <4FC7C220.3060001@mirix.org> <4FC8073C.1030500@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] DANE OpenPGP support X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:03:16 -0000 On 1 jun 2012, at 02:05, Peter Saint-Andre wrote: > My understanding is that it was considered and deemed out of scope for > now. You'll notice that there are some hooks for other certificate types > in the text, but someone will need to define those usages since they're > out of scope for the core spec. Yes, an OpenPGP specification for DANE TLSA would be very welcome. jakob From mrex@sap.com Fri Jun 1 09:16:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD121F8A36 for ; Fri, 1 Jun 2012 09:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG9Jo9pLKEPp for ; Fri, 1 Jun 2012 09:16:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3846021F8A35 for ; Fri, 1 Jun 2012 09:16:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q51GGWPw015331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 18:16:37 +0200 (MEST) In-Reply-To: <1338435781.1728.29.camel@localhost> To: Matt McCutchen Date: Fri, 1 Jun 2012 18:16:32 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120601161632.509641A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:16:46 -0000 Matt McCutchen wrote: > > This approach is not going to work. My understanding > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01215.html) > is that a TLSA RRset at a given endpoint (DNS name + transport + port) > is not a guarantee that a TLS service is offered at that endpoint. It > only indicates the server certificates to be considered authentic if a > client wants to attempt a connection to such a TLS service. Indeed, an > organization with an existing private CA may publish may cover its > entire zone with TLSA RRsets of usage 2 referring to that CA. And I > cover all the unused names in mattmccutchen.net with dummy TLSA RRsets > (SHA256 0000...0000) to ensure that TLS clients will never successfully > authenticate a TLS service that I do not offer if a MITM attacker tries > to spoof one into existence with a fraudulent certificate from a public > CA. > > A mail client that is already configured to require authenticated TLS > could certainly use DANE. But it would be incorrect for a client to > refuse to deliver insecurely because it found a secure TLSA RRset. For > that kind of logic, we need something like HASTLS. I actually believe that you're abusing TLSA with "dummy RRsets", and if there was a desire to lock out public CAs from issuing certs for a particular domain, a seperate TLSA usage type should be defined specifically for that purpose. -Martin From mrex@sap.com Fri Jun 1 09:20:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F03311E80D6 for ; Fri, 1 Jun 2012 09:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKu88Y1KGE76 for ; Fri, 1 Jun 2012 09:20:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 751ED11E80C8 for ; Fri, 1 Jun 2012 09:20:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q51GKpuA016289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2012 18:20:51 +0200 (MEST) In-Reply-To: <4FC6F36B.4080103@gmail.com> To: Yaron Sheffer Date: Fri, 1 Jun 2012 18:20:51 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120601162051.68F371A094@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane@ietf.org Subject: Re: [dane] DANE+SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:20:57 -0000 Yaron Sheffer wrote: > > - In addition, this sentence conflicts with the earlier text "If these > security requirements are not satisfied, this protocol does not take > effect. The client SHOULD fall back to insecure delivery (which might > be over unauthenticated TLS)." So we do allow fallback to > "unauthenticated TLS" (and implicitly also to plaintext?), which is in > fact vulnerable to the same MITM attacker. I agree that this suggestion (SHOULD fall back to insecure delivery) looks non-sensical. If insecure deliver *is* acceptable, then confidentiality protected insecure delivery must be even more so, therefore aborting the connection is a bad idea. -Martin From fanf2@hermes.cam.ac.uk Fri Jun 1 09:24:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D6211E80D6 for ; Fri, 1 Jun 2012 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os7-xHBSC+I6 for ; Fri, 1 Jun 2012 09:24:23 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id F385311E80EF for ; Fri, 1 Jun 2012 09:24:17 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38031) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SaUe8-0003hh-D5 (Exim 4.72) (return-path ); Fri, 01 Jun 2012 17:24:16 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SaUe8-0004ml-1R (Exim 4.67) (return-path ); Fri, 01 Jun 2012 17:24:16 +0100 Date: Fri, 1 Jun 2012 17:24:16 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Rex In-Reply-To: <20120601162051.68F371A094@ld9781.wdf.sap.corp> Message-ID: References: <20120601162051.68F371A094@ld9781.wdf.sap.corp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] DANE+SMTP draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:24:24 -0000 Martin Rex wrote: > > I agree that this suggestion (SHOULD fall back to insecure delivery) > looks non-sensical. If insecure deliver *is* acceptable, then > confidentiality protected insecure delivery must be even more so, > therefore aborting the connection is a bad idea. I already replied to Yaron saying: No, the fallback occurs when the DNSSEC part of the protocol has not been (completely) deployed. A MITM cannot spoof DNSSEC responses, so it can't force a downgrade on the MX or TLSA lookups. The latest draft says: For this protocol to take effect, all of these DNS RRsets MUST be "secure" according to DNSSSEC validation. In the case of an implicit MX record, there MUST be a secure denial of existence of an MX RRset for the mail domain. In the case of a (chain of) CNAME RRs, all the CNAMEs MUST be secure as well as their ultimate target. If they are not all secure, this protocol has not been fully deployed. The client SHOULD fall back to insecure delivery (which might be over unauthenticated TLS). Does that make it clearer? Tony. -- f.anthony.n.finch http://dotat.at/ North FitzRoy, Sole: Easterly veering southerly or southwesterly 4 or 5, increasing 6 at times. Moderate, occasionally rough in west. Rain or thundery showers, fog patches at first in east Sole. Moderate or good, occasionally very poor at first in east Sole. From fanf2@hermes.cam.ac.uk Fri Jun 1 09:47:53 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC511E80E0; Fri, 1 Jun 2012 09:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZdd8bcbgFVL; Fri, 1 Jun 2012 09:47:52 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1911E80D2; Fri, 1 Jun 2012 09:47:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:58622) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SaV0w-0006oO-T0 (Exim 4.72) (return-path ); Fri, 01 Jun 2012 17:47:51 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SaV0w-00087s-VP (Exim 4.67) (return-path ); Fri, 01 Jun 2012 17:47:50 +0100 Date: Fri, 1 Jun 2012 17:47:50 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: apps-discuss@ietf.org, dane@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dane] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:47:53 -0000 I've started a draft for using DANE with IMAP, POP3, and message submission, but I've got a bit stuck deciding how to fit in with RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). RFC 6125 has the following example: A mail user agent that is connecting via IMAPS to the email service at "example.net" (resolved as "mail.example.net") might have five reference identifiers: an SRV-ID of "_imaps.example.net" (see [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, as a fallback, CN-IDs of "example.net" and "mail.example.net". (A legacy email user agent would not support [EMAIL-SRV] and therefore would probably be explicitly configured to connect to "mail.example.net", whereas an SRV-aware user agent would derive "example.net" from an email address of the form "user@example.net" but might also accept "mail.example.net" as the DNS domain name portion of reference identifiers for the service.) I presume that the client would not actually use mail.example.net as a reference identifier unless DNSSEC is in use, otherwise that would not be secure and is therefore forbidden according to the rules a few paragraphs earlier in RFC 6125. There's also a question about how SNI fits in. RFC 6066 says that it only supports DNS host names, which I take to mean SRV targets not SRV names. RFC 6186 encourages the use of SNI but says nothing about which identity should be used. So I'm inclined to state that the server should have a certificate containing both the SRV name and target as DNS-IDs and offer that certificate if it is given either identity in an SNI. This is so that the server can support new-style clients (supporing DANE and SRV and using the SRV name as the identity) as well as old-style clients (using address records directly and the server host name for the TLS identity). I'll mention the SRV-ID for form's sake but as far as I can tell it's a fantasy that doesn't exist in the real world. Tony. -- f.anthony.n.finch http://dotat.at/ Dogger: Northwesterly 4 or 5, occasionally 6 in east. Moderate. Showers later. Good. From shuque@upenn.edu Fri Jun 1 10:03:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CF621F88F7; Fri, 1 Jun 2012 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3VjwgmjSGyP; Fri, 1 Jun 2012 10:03:13 -0700 (PDT) Received: from mopeypopo.net.isc.upenn.edu (www.huque.com [IPv6:2607:f470:2:1::a:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA2621F88F3; Fri, 1 Jun 2012 10:03:13 -0700 (PDT) Received: by mopeypopo.net.isc.upenn.edu (Postfix, from userid 500) id E1F27A0A44; Fri, 1 Jun 2012 13:03:06 -0400 (EDT) Date: Fri, 1 Jun 2012 13:03:06 -0400 From: Shumon Huque To: Tony Finch Message-ID: <20120601170306.GA32180@isc.upenn.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: University of Pennsylvania User-Agent: Mutt/1.5.21 (2010-09-15) Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:03:14 -0000 On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: > I've started a draft for using DANE with IMAP, POP3, and message > submission, but I've got a bit stuck deciding how to fit in with > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > > RFC 6125 has the following example: > > A mail user agent that is connecting via IMAPS to the email service > at "example.net" (resolved as "mail.example.net") might have five > reference identifiers: an SRV-ID of "_imaps.example.net" (see > [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, > as a fallback, CN-IDs of "example.net" and "mail.example.net". (A > legacy email user agent would not support [EMAIL-SRV] and therefore > would probably be explicitly configured to connect to > "mail.example.net", whereas an SRV-aware user agent would derive > "example.net" from an email address of the form "user@example.net" > but might also accept "mail.example.net" as the DNS domain name > portion of reference identifiers for the service.) > > I presume that the client would not actually use mail.example.net as a > reference identifier unless DNSSEC is in use, otherwise that would not be > secure and is therefore forbidden according to the rules a few paragraphs > earlier in RFC 6125. That sounds correct to me. > There's also a question about how SNI fits in. RFC 6066 says that it only > supports DNS host names, which I take to mean SRV targets not SRV names. > RFC 6186 encourages the use of SNI but says nothing about which identity > should be used. SNI really needs to be extended to support other name types (especially SRVName and URI). > So I'm inclined to state that the server should have a certificate > containing both the SRV name and target as DNS-IDs and offer that > certificate if it is given either identity in an SNI. This is so that the > server can support new-style clients (supporing DANE and SRV and using the > SRV name as the identity) as well as old-style clients (using address > records directly and the server host name for the TLS identity). I'll > mention the SRV-ID for form's sake but as far as I can tell it's a fantasy > that doesn't exist in the real world. This doesn't achieve compartmentalization of security against other services sharing the domain name at the DNS-ID. It might however be necessary until software evolves. I agree that SRV-ID is for the time being a fantasy. Although if DANE usage types 2 and 3 take off, it might not be in the future. -- Shumon Huque University of Pennsylvania. From matt@mattmccutchen.net Fri Jun 1 10:12:12 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9181F21F890E for ; Fri, 1 Jun 2012 10:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j0inP8d-Jx9 for ; Fri, 1 Jun 2012 10:12:12 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0340621F890A for ; Fri, 1 Jun 2012 10:12:11 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id A9DA810AFAD; Fri, 1 Jun 2012 10:12:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=b6jnUuAyo5npPZhLqWhrL615gZxA8bcmd8cNU5+iZ23 WxtxZV6qApSC5OV+AOf1OUbDTuI0emVK3VakXZRzJDZmWPxep+xYDvV3kVlEq8Nq 4dDQm8fBk8F6Oi2YZAuRGXnNX3Z7HmpyTn8Ftq9/Yup5HXx2IOuIWRJ6YrQa6z44 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=R5JuKM5hlYZYiGjs01l6L6pEhOE=; b=U0DreThSMl bPq7Rb9GByOuQNfVQMSljnLEIGEvmptHQ+YaL0v3aGKfc1lTiaP9kKxQRIlPUdK7 EoHONLyePO3Gs3+Zmk15m6ujt8YRcsf9CsTrITAo7k9pqeK5xNTZMqrHl2uHiTdE fgj5BY/mofIDKdtNHqXebVfuA/vUx8GN0= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 7750B10AFAB; Fri, 1 Jun 2012 10:12:11 -0700 (PDT) Message-ID: <1338570732.1728.44.camel@localhost> From: Matt McCutchen To: Martin Rex Date: Fri, 01 Jun 2012 10:12:12 -0700 In-Reply-To: <20120601161632.509641A094@ld9781.wdf.sap.corp> References: <20120601161632.509641A094@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: dane@ietf.org Subject: [dane] Asserting TLS service nonexistence X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:12:12 -0000 On Fri, 2012-06-01 at 18:16 +0200, Martin Rex wrote: > I actually believe that you're abusing TLSA with "dummy RRsets", > and if there was a desire to lock out public CAs from issuing certs > for a particular domain, a seperate TLSA usage type should be > defined specifically for that purpose. If a better solution becomes available (https://trac.tools.ietf.org/wg/dane/trac/ticket/23), I will adopt it promptly. In the meantime, this approach should work according to the semantics of TLSA. I don't see why I should forego the concrete benefit of locking out the public CAs. If it makes you feel better, I could generate an actual key pair and publish the certificate; it would make no difference to DANE clients, but it would be less obvious to a human looking at the record. -- Matt From matt@mattmccutchen.net Fri Jun 1 12:58:55 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9743411E80A4 for ; Fri, 1 Jun 2012 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4HaJJrWx-K9 for ; Fri, 1 Jun 2012 12:58:54 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA011E80A0 for ; Fri, 1 Jun 2012 12:58:54 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 6BB7E578078; Fri, 1 Jun 2012 12:58:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=K/gFuiXrwWRBT9nDpF4JeMC6p8mXnkzV/fpxtfEWwa1 S7gbSc0SqvueK7bsdDO/SGUTwiut3qL4re0jcLraCUEyMUOpTO53VNNWYgbpFhZT FN2N+zRqj+EuBBuwVt2UWWnhLwuYEGLH2zJDPW3J5N/kpL17sk5sJ7F7+aQ/b2A4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=q514pAKmmXSUDl58JG/QbLBWr44=; b=kYpE8hNf3n 0uOjLLpxlBh322XMQz1EPcgF0YH0nV1MjhS8uCYkNldgmA542Ucz1tQQHq68z5RG Zehe3mEoS671PKlwAxF4h2e32SU0dw9zh0vP6eAxgnsIVk34N183gLZsQasYZu/y 0qwo4/LP+zFyRHOZzPmoMVO2+HndjuwnE= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 221D0578073; Fri, 1 Jun 2012 12:58:54 -0700 (PDT) Message-ID: <1338580733.1728.47.camel@localhost> From: Matt McCutchen To: Tony Finch Date: Fri, 01 Jun 2012 12:58:53 -0700 In-Reply-To: References: <1338435781.1728.29.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 19:58:55 -0000 On Thu, 2012-05-31 at 15:46 +0100, Tony Finch wrote: > Matt McCutchen wrote: > > > > This approach is not going to work. > > I think you mean that you want weaker semantics for SMTP+TLSA than I have > specified. I have deliberately stated that extra semantics apply - in the > intro I wrote: > > As well as its normal function of providing an association > between a domain name and a certificate, we are also using the > existance of a TLSA record to signal to the client that it can > expect a valid server certificate. TLSA always signals to the client that *if* it does TLS, it can expect a valid server certificate. The issue is whether to do TLS. I think you mean this: As well as its normal function of providing an association between a domain name and a certificate, we are also using the existance of a TLSA record to signal to the client that the SMTP server supports TLS. -- Matt From ned.freed@mrochek.com Fri Jun 1 13:34:05 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9E811E80C7; Fri, 1 Jun 2012 13:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioWb7-8MeF0m; Fri, 1 Jun 2012 13:34:04 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC8E311E80B0; Fri, 1 Jun 2012 13:34:04 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG68WL990W002Z6R@mauve.mrochek.com>; Fri, 1 Jun 2012 13:34:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 13:34:00 -0700 (PDT) Message-id: <01OG68WJL5MG0006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 12:15:15 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Jun 2012 12:55:21 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: To: Cyrus Daboo Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:34:05 -0000 > Hi Tony, > --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > > I've started a draft for using DANE with IMAP, POP3, and message > > submission, but I've got a bit stuck deciding how to fit in with > > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > Shouldn't 6125 be updated to account for DANE, rather than doing this per > protocol (or set of protocols)? That way anything that references 6125bis > would inherit the correct DANE behavior. I've been thinking about this as well, and due to the different ways the DNS is used in these cases, I think it it at least makes sense to do them separately. But we should do all the email SRV ones at once. I'm willing to help on a DANE spec built on top of RFC 6186. (Since Tony has apparently taken some of my prose, I feel no qualms about swiping a bunch of his ;-) Ned From ned.freed@mrochek.com Fri Jun 1 13:35:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3367E21F882D; Fri, 1 Jun 2012 13:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwdlMIGXUiO6; Fri, 1 Jun 2012 13:35:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B931621F882C; Fri, 1 Jun 2012 13:35:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG68YLKYDC002Z6R@mauve.mrochek.com>; Fri, 1 Jun 2012 13:35:40 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OG54121Q0W0006TF@mauve.mrochek.com>; Fri, 1 Jun 2012 13:35:37 -0700 (PDT) Message-id: <01OG68YK6UR00006TF@mauve.mrochek.com> Date: Fri, 01 Jun 2012 13:34:56 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 01 Jun 2012 12:15:15 -0700 (PDT)" <01OG68WJL5MG0006TF@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OG68WJL5MG0006TF@mauve.mrochek.com> To: Ned Freed Cc: Cyrus Daboo , apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:35:43 -0000 Sorry, didn't notice that Tony has already started. Anyway, I'm willing to help. Ned > > Hi Tony, > > --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > > > I've started a draft for using DANE with IMAP, POP3, and message > > > submission, but I've got a bit stuck deciding how to fit in with > > > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > > Shouldn't 6125 be updated to account for DANE, rather than doing this per > > protocol (or set of protocols)? That way anything that references 6125bis > > would inherit the correct DANE behavior. > I've been thinking about this as well, and due to the different ways the DNS is > used in these cases, I think it it at least makes sense to do them separately. > But we should do all the email SRV ones at once. > I'm willing to help on a DANE spec built on top of RFC 6186. (Since Tony has > apparently taken some of my prose, I feel no qualms about swiping a bunch of > his ;-) > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Fri Jun 1 13:36:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF8311E8097; Fri, 1 Jun 2012 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InRJqu23uQbo; Fri, 1 Jun 2012 13:36:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9E711E808A; Fri, 1 Jun 2012 13:36:35 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C1E540075; Fri, 1 Jun 2012 14:53:09 -0600 (MDT) Message-ID: <4FC927D2.9080903@stpeter.im> Date: Fri, 01 Jun 2012 14:36:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ned Freed References: <01OG68WJL5MG0006TF@mauve.mrochek.com> In-Reply-To: <01OG68WJL5MG0006TF@mauve.mrochek.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:36:36 -0000 On 6/1/12 1:15 PM, Ned Freed wrote: >> Hi Tony, > >> --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > >> > I've started a draft for using DANE with IMAP, POP3, and message >> > submission, but I've got a bit stuck deciding how to fit in with >> > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > >> Shouldn't 6125 be updated to account for DANE, rather than doing this per >> protocol (or set of protocols)? That way anything that references 6125bis >> would inherit the correct DANE behavior. > > I've been thinking about this as well, and due to the different ways the > DNS is > used in these cases, I think it it at least makes sense to do them > separately. > But we should do all the email SRV ones at once. Ned, I tend to agree. Let's define them separately for now (Matt Miller and I are working on an XMPP+DANE spec) and then see what the commonalities are before we try to define a more generic approach. Now, it's *also* possible that we might want to update RFC 6125 to address the existence of DANE, and I'm happy to work on that as well, but I see it as a parallel work item. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jun 1 13:42:14 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2188F11E80CE; Fri, 1 Jun 2012 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvduUC9wdaZN; Fri, 1 Jun 2012 13:42:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C911E80C7; Fri, 1 Jun 2012 13:42:13 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9330140075; Fri, 1 Jun 2012 14:58:47 -0600 (MDT) Message-ID: <4FC928DE.6070503@stpeter.im> Date: Fri, 01 Jun 2012 14:41:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Shumon Huque References: <20120601170306.GA32180@isc.upenn.edu> In-Reply-To: <20120601170306.GA32180@isc.upenn.edu> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:42:14 -0000 On 6/1/12 11:03 AM, Shumon Huque wrote: > On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: >> I've started a draft for using DANE with IMAP, POP3, and message >> submission, but I've got a bit stuck deciding how to fit in with >> RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). >> >> RFC 6125 has the following example: >> >> A mail user agent that is connecting via IMAPS to the email service >> at "example.net" (resolved as "mail.example.net") might have five >> reference identifiers: an SRV-ID of "_imaps.example.net" (see >> [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, >> as a fallback, CN-IDs of "example.net" and "mail.example.net". (A >> legacy email user agent would not support [EMAIL-SRV] and therefore >> would probably be explicitly configured to connect to >> "mail.example.net", whereas an SRV-aware user agent would derive >> "example.net" from an email address of the form "user@example.net" >> but might also accept "mail.example.net" as the DNS domain name >> portion of reference identifiers for the service.) >> >> I presume that the client would not actually use mail.example.net as a >> reference identifier unless DNSSEC is in use, otherwise that would not be >> secure and is therefore forbidden according to the rules a few paragraphs >> earlier in RFC 6125. > > That sounds correct to me. Agreed. That's the approach Matt Miller and I are taking for secure delegation in XMPP (we'll submit an I-D soonish). Peter -- Peter Saint-Andre https://stpeter.im/ From matt@mattmccutchen.net Fri Jun 1 20:05:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1121F86B5 for ; Fri, 1 Jun 2012 20:05:31 -0700 (PDT) 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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzgUEi2YKDvK for ; Fri, 1 Jun 2012 20:05:30 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 53BA021F86B4 for ; Fri, 1 Jun 2012 20:05:30 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 97232598070; Fri, 1 Jun 2012 20:05:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=l9yJJIPg2yKJSra7de9y1YeYIma3FzoF1VdHVC0tq2w rQHf0VrjvKJLfY5vA80uDVdrA7Vat1LSudgkSQarq9juhgZx+PUMWCCpKG5rzR5v 1y70ysO+mHhlwCmgVr2jjTEYrkN9naVBUK/Hu8UAGpON3+Q6GxO3cwMMcZybY4Ok = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=sM8H5XQDR/+YGLRvPTTSxGZhC+4=; b=QraaW3dPTh CE/AFPCgT3DgjP67h91Yraz3M+5Kfd6FeY0gr750asv4aZ0GsP7ZfoAvICU9rCa7 xGCQpcsPHhCsL8t0kSMBvuTl7CRuD+aEsm64L1fNBYfc59J021/T1BddD6eP4048 mcEMnLyBluuHOA52SjkqZ0keECXq/6tKE= Received: from [IPv6:::1] (ps7180.dreamhost.com [75.119.218.76]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 77DE159806C; Fri, 1 Jun 2012 20:05:29 -0700 (PDT) Message-ID: <1338606328.1728.64.camel@localhost> From: Matt McCutchen To: Paul Hoffman Date: Fri, 01 Jun 2012 20:05:28 -0700 In-Reply-To: References: <1338435781.1728.29.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: ietf-smtp@imc.org, IETF DANE WG list Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 03:05:31 -0000 On Thu, 2012-05-31 at 08:05 -0700, Paul Hoffman wrote: > On May 30, 2012, at 8:43 PM, Matt McCutchen wrote: > > A mail client that is already configured to require authenticated TLS > > could certainly use DANE. But it would be incorrect for a client to > > refuse to deliver insecurely because it found a secure TLSA RRset. > > That's incorrect. draft-fanf-dane-smtp is defining the specific use of > TLSA for _25._tcp.hostname. (It would be good if it said so in the > Introduction.) I thought (and hoped) that TLSA was a generic protocol for authenticating a TLS service at a given (DNS name, transport, port), nothing more. I didn't realize that subsequent documents would attach other semantics to TLSA RRsets. Nothing in the DANE doc anticipates this. (The clause, "Unless there is a protocol-specific specification that is different than this one", appears to me to refer to putting TLSA RRsets at a different owner name, not giving them different semantics.) I would oppose doing this, but it looks like I'm outvoted. > I think HASTLS might be a good idea, but the IETF still needs to have > the discussion of layering of these types of announcements. I think IETF should have that discussion before the WG commits to Tony's proposal for SMTP. > > This approach is not going to work. > > It will work fine for everyone who doesn't do the "cover every port > and assume that no future protocol will ever define how specific > applications will use TLSA". It's true that there was no strong support for ensuring that covering every port works. Though, if we intend to break it, section "A.2.1.3. Provisioning TLSA Records with Wildcards" of the DANE doc should be updated. It's also true that I can't just expect the standard to support the features I want without slogging through the process of building consensus. For now, I can have fun deploying records with the private-use certificate usage and implementing them in my client. -- Matt From paul.hoffman@vpnc.org Sat Jun 2 08:10:18 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3683121F8552 for ; Sat, 2 Jun 2012 08:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAbrcCMV4dmy for ; Sat, 2 Jun 2012 08:10:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3F21F84DF for ; Sat, 2 Jun 2012 08:10:17 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q52FAFIa034417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Jun 2012 08:10:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <1338606328.1728.64.camel@localhost> Date: Sat, 2 Jun 2012 08:10:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77C97071-7639-48F0-98AD-A1B6EF3F021A@vpnc.org> References: <1338435781.1728.29.camel@localhost> <1338606328.1728.64.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1278) Cc: ietf-smtp@imc.org, IETF DANE WG list Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 15:10:18 -0000 On Jun 1, 2012, at 8:05 PM, Matt McCutchen wrote: > I thought (and hoped) that TLSA was a generic protocol for > authenticating a TLS service at a given (DNS name, transport, port), > nothing more. I didn't realize that subsequent documents would attach > other semantics to TLSA RRsets. Nothing in the DANE doc anticipates > this. (The clause, "Unless there is a protocol-specific specification > that is different than this one", appears to me to refer to putting = TLSA > RRsets at a different owner name, not giving them different = semantics.) > I would oppose doing this, but it looks like I'm outvoted. It was discussed on the DANE mailing list off and on over time, = particularly with respect to SRV-using protocols. You may disagree with = it and hope for different, but it should not be a surprise to you. We = all know that a TLS-on-defined-port protocol is not the same as a = TLS-after-upgrade protocol when the TLS handshake fails, and DANE by = design gives a different way for the TLS handshake to fail. >> I think HASTLS might be a good idea, but the IETF still needs to have >> the discussion of layering of these types of announcements. >=20 > I think IETF should have that discussion before the WG commits to = Tony's > proposal for SMTP. This draft is a great forcing function for the discussion. However, I = will be shocked if the discussion comes to a fixed result any time soon. >>> This approach is not going to work. =20 >>=20 >> It will work fine for everyone who doesn't do the "cover every port >> and assume that no future protocol will ever define how specific >> applications will use TLSA". >=20 > It's true that there was no strong support for ensuring that covering > every port works. =20 s/no strong support/no noticeable support/ > Though, if we intend to break it, section "A.2.1.3. > Provisioning TLSA Records with Wildcards" of the DANE doc should be > updated. Disagree. The text in A.2.1.3 is still correct: it's only your = interpretation of "if the port is covered, it must offer TLS" that is = wrong. > It's also true that I can't just expect the standard to support the > features I want without slogging through the process of building > consensus. For now, I can have fun deploying records with the > private-use certificate usage and implementing them in my client. By all means let the mailing list know your experiences with that = deployment. If DANE is anything like DNSSEC, we have muffed and = understated many important features that will only be found by = interesting deployment. --Paul Hoffman From cyrus@daboo.name Fri Jun 1 09:55:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F7421F889A; Fri, 1 Jun 2012 09:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLeBZmxzicmn; Fri, 1 Jun 2012 09:55:27 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C862721F8899; Fri, 1 Jun 2012 09:55:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2E8952855C34; Fri, 1 Jun 2012 12:55:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOh1lwOdnNQd; Fri, 1 Jun 2012 12:55:26 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id AE30D2855C29; Fri, 1 Jun 2012 12:55:24 -0400 (EDT) Date: Fri, 01 Jun 2012 12:55:21 -0400 From: Cyrus Daboo To: Tony Finch , apps-discuss@ietf.org, dane@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=489 X-Mailman-Approved-At: Sat, 02 Jun 2012 11:13:16 -0700 Subject: Re: [dane] [apps-discuss] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 16:55:28 -0000 Hi Tony, --On June 1, 2012 5:47:50 PM +0100 Tony Finch wrote: > I've started a draft for using DANE with IMAP, POP3, and message > submission, but I've got a bit stuck deciding how to fit in with > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). Shouldn't 6125 be updated to account for DANE, rather than doing this per protocol (or set of protocols)? That way anything that references 6125bis would inherit the correct DANE behavior. -- Cyrus Daboo From matt@mattmccutchen.net Sat Jun 2 14:59:36 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5148C21F854C for ; Sat, 2 Jun 2012 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIhlWXOhBqzr for ; Sat, 2 Jun 2012 14:59:35 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9418721F8548 for ; Sat, 2 Jun 2012 14:59:35 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id A389A63406F; Sat, 2 Jun 2012 14:59:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=message-id :subject:from:to:cc:date:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s= mattmccutchen.net; b=KUMtPWXrl0zS0fgoIgNJmd1H/OBLPH4LVobjFk/5A9E HLKP5mgm4xVt/BQn1KIIB88w8hKAn/2ZdRDUDJbuZExesE5bZZlbTfniZ2zXuWVX v04X0LqINLS2ZXoQw7aO3pSWU5bpX9gVbmqJ/JjQco/FOMpns8p+dtTWEBElt50o = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s= mattmccutchen.net; bh=PGgF5yNLrmUsV8S/fQXc9802USM=; b=PIl8p8LXTf RcuATn+HrxDuSFEtUMz4vH0aaaIw9yqzWlfK03LuN1q/uX+Mew+Eckz0xmAYKkTC 7mDt/vM8Tyu+/0KBGdLMDEzbdkp+xFYzPHOUhcNcrbo9HEocNtogSf26v/b6zGEi aKdR8Rr/mh6XZpKP52sg8vvVdu4K/wc9Y= Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPSA id 7989F63406E; Sat, 2 Jun 2012 14:59:34 -0700 (PDT) Message-ID: <1338674373.1728.74.camel@localhost> From: Matt McCutchen To: Paul Hoffman Date: Sat, 02 Jun 2012 14:59:33 -0700 In-Reply-To: <77C97071-7639-48F0-98AD-A1B6EF3F021A@vpnc.org> References: <1338435781.1728.29.camel@localhost> <1338606328.1728.64.camel@localhost> <77C97071-7639-48F0-98AD-A1B6EF3F021A@vpnc.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: ietf-smtp@imc.org, IETF DANE WG list Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 21:59:36 -0000 On Sat, 2012-06-02 at 08:10 -0700, Paul Hoffman wrote: > On Jun 1, 2012, at 8:05 PM, Matt McCutchen wrote: > > I thought (and hoped) that TLSA was a generic protocol for > > authenticating a TLS service at a given (DNS name, transport, port), > > nothing more. I didn't realize that subsequent documents would attach > > other semantics to TLSA RRsets. Nothing in the DANE doc anticipates > > this. (The clause, "Unless there is a protocol-specific specification > > that is different than this one", appears to me to refer to putting TLSA > > RRsets at a different owner name, not giving them different semantics.) > > I would oppose doing this, but it looks like I'm outvoted. > > It was discussed on the DANE mailing list off and on over time, > particularly with respect to SRV-using protocols. You may disagree > with it and hope for different, but it should not be a surprise to > you. Can you please provide the reference where the WG discussed using TLSA to indicate "TLS is available"? All I see is you promoting the opposite position, at least for HTTP: http://www.ietf.org/mail-archive/web/keyassure/current/msg01209.html > We all know that a TLS-on-defined-port protocol is not the same as a > TLS-after-upgrade protocol when the TLS handshake fails, and DANE by > design gives a different way for the TLS handshake to fail. Sorry, I don't follow. Can you spell out the argument for protocols with in-band TLS upgrade should be treated differently? > > Though, if we intend to break it, section "A.2.1.3. > > Provisioning TLSA Records with Wildcards" of the DANE doc should be > > updated. > > Disagree. The text in A.2.1.3 is still correct: it's only your > interpretation of "if the port is covered, it must offer TLS" that is > wrong. Can you explain? The doc says, "This is possibly useful in some scenarios where [...] the same certificate and/or key is used for all services on a host." I read this as "all TLS services". So if the host offers several TLS services with the same certificate, plus SMTP that does not support TLS, then it would seem one could deploy a wildcard RRset. But then draft-fanf-dane-smtp would break the use of the SMTP service. -- Matt From fanf2@hermes.cam.ac.uk Sun Jun 3 10:08:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47B521F84F0 for ; Sun, 3 Jun 2012 10:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1ozXpSlQrGH for ; Sun, 3 Jun 2012 10:08:06 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7421F84D8 for ; Sun, 3 Jun 2012 10:08:05 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36978) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SbEHb-0007ov-EZ (Exim 4.72) (return-path ); Sun, 03 Jun 2012 18:08:03 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SbEHb-0007oF-Eu (Exim 4.67) (return-path ); Sun, 03 Jun 2012 18:08:03 +0100 Date: Sun, 3 Jun 2012 18:08:03 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matt McCutchen In-Reply-To: <1338580733.1728.47.camel@localhost> Message-ID: References: <1338435781.1728.29.camel@localhost> <1338580733.1728.47.camel@localhost> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: ietf-smtp@imc.org, dane@ietf.org Subject: Re: [dane] draft-fanf-dane-smtp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 17:08:07 -0000 Matt McCutchen wrote: > > As well as its normal function of providing an association > > between a domain name and a certificate, we are also using the > > existance of a TLSA record to signal to the client that it can > > expect a valid server certificate. > > TLSA always signals to the client that *if* it does TLS, it can expect a > valid server certificate. The issue is whether to do TLS. I think you > mean this: > > As well as its normal function of providing an association > between a domain name and a certificate, we are also using the > existance of a TLSA record to signal to the client that the SMTP > server supports TLS. There is a load of other text in the intro explaining that in the current internet a lot of MXs support TLS but don't have valid certificates, and even if they did the existing specs don't explain how to validate them. So the point of that text is to explain that we are using TLSA to fix this. You are right to point out that I had left server support for TLS implicit; I already improved that between -01 and -02 so the paragraph now reads: As well as its normal function of providing an association between a domain name and a certificate, we are also using the existance of a TLSA record to signal to the client that it can expect the server to offer TLS with a valid certificate. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: North 4 or 5, veering southeast 5 or 6. Moderate, occasionally rough at first. Occasional rain. Good, occasionally poor. From ondrej.sury@nic.cz Tue Jun 5 05:16:32 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C421F866E for ; Tue, 5 Jun 2012 05:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSF6KlmVIxaH for ; Tue, 5 Jun 2012 05:16:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0641721F866C for ; Tue, 5 Jun 2012 05:16:31 -0700 (PDT) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 77E10141065 for ; Tue, 5 Jun 2012 14:16:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1338898590; bh=75kRIO7N7gnpPW/w4LQpYCaZbK2u0n0yS2ArFnFeYPs=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=Fv8kp6ijsyF976+5NoIeLo09dI9PMa+XkzjnVF9AmBAmXIYjdTSkUWi/aAV4kQPuo HximrGbO/nhvDB0McpMZuXFUTF6mvIJmhTezBVAkMbyrLSatYf61eL20TZqcTdsYim b3g/9yv9S8eDGcyivz7hYUnCZSU91O+FpHZ8OpLA= From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 14:16:29 +0200 Message-Id: <3BB91448-A97C-488C-9B49-6A8387396A76@nic.cz> To: dane WG list Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [dane] Meeting in Vancouver X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 12:16:33 -0000 Hi all, this is just a notification that we will meet in Vancouver, so if you already have some things you would like to see on the agenda, please send it to us. As far I can see several topics: - What to do next? Close/Hiatus/Recharter/...? (chairs) - DANE+S/MIME - DANE+XMMP - DANE+SMTP O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From fanf2@hermes.cam.ac.uk Tue Jun 5 06:51:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1969821F8680; Tue, 5 Jun 2012 06:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrRLLf8ZjGHW; Tue, 5 Jun 2012 06:51:48 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id E087F21F85F2; Tue, 5 Jun 2012 06:51:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51976) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SbuAX-0005Ov-Py (Exim 4.72) (return-path ); Tue, 05 Jun 2012 14:51:33 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SbuAW-0006Pr-Vx (Exim 4.67) (return-path ); Tue, 05 Jun 2012 14:51:33 +0100 Date: Tue, 5 Jun 2012 14:51:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FC927D2.9080903@stpeter.im> Message-ID: References: <01OG68WJL5MG0006TF@mauve.mrochek.com> <4FC927D2.9080903@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Cyrus Daboo , Ned Freed , apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] [apps-discuss] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:51:50 -0000 Peter Saint-Andre wrote: > Ned Freed wrote: > > > > I've been thinking about this as well, and due to the different ways > > the DNS is used in these cases, I think it it at least makes sense to > > do them separately. But we should do all the email SRV ones at once. > > Ned, I tend to agree. Let's define them separately for now (Matt Miller > and I are working on an XMPP+DANE spec) and then see what the > commonalities are before we try to define a more generic approach. Yes, that was what I had in mind. It's possible that we might find commonalities before the separate-protocol drafts get to RFC stage, but we clearly need to bash out some details. It will be particularly useful to compare XMPP and email. Tony. -- f.anthony.n.finch http://dotat.at/ Humber, Thames: South 4 or 5, backing southeast 5 or 6. Slight or moderate. Showers then rain. Good, becoming moderate or poor. From paul.hoffman@vpnc.org Tue Jun 5 13:47:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AE721F87DF; Tue, 5 Jun 2012 13:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPayI6bNg7oV; Tue, 5 Jun 2012 13:47:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 545AB21F8599; Tue, 5 Jun 2012 13:47:52 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q55KlnEv051095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jun 2012 13:47:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 13:47:49 -0700 References: <4FCE6431.6050808@ieca.com> To: IETF DANE WG list , IETF WebSec WG Message-Id: <6A359D3F-3ACD-4E47-9F24-96A103178048@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dane] Fwd: [saag] Pinning X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 20:47:56 -0000 =46rom the SAAG mailing list, but appropriate here. I bet that Sean = would appreciate all discussion to go on on the SAAG mailing list... Begin forwarded message: > From: Sean Turner > Subject: [saag] Pinning > Date: June 5, 2012 12:55:29 PM PDT > To: saag@ietf.org >=20 > All, >=20 > There are many proposals for how to say which key or certificate or = trust anchor should be used by the client in a TLS session that it is = about to open. These proposals include making that decision in the DNS = (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and = in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin = tls-tack/). If more than one of these protocols are deployed, = operational mistakes could lead to a client getting conflicting = information. >=20 > Similarly, there are also proposals on how to say whether or not a = client should expect to see a particular service running under TLS. = These proposals include making that indication in the DNS (draft = hoffman-server-has-tls, expired but might be revived) and in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport = sec/). If more than one of these protocols are deployed, operational = mistakes could lead to a client getting conflicting information. >=20 > Is a standards-track operations statement needed to describe the = choices that a TLS server administrator has, and to deal with conflicts = between the proposals? >=20 > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From mamille2@cisco.com Wed Jun 6 08:39:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2AF21F88D2 for ; Wed, 6 Jun 2012 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG4GMr8ReCHi for ; Wed, 6 Jun 2012 08:39:45 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CC09321F88B4 for ; Wed, 6 Jun 2012 08:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6036; q=dns/txt; s=iport; t=1338997185; x=1340206785; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=PM5MtaYtA0oMpxEF3Px992roDBJiBXNQ8p2LCpASE3c=; b=EO6yilvKThwUJacztnfNcd5ur7tch5wcTChn0DPMrmzWbIOSAGdK4n14 7v0uShmfTuEw3nsPNlDpsoWjobfLnka9A2CqIueAebRlwQ30LFD4DyMWz y+JbjuUak4WU+UIjWy0W+vwhpcxJckZ4FyKFKdyhNSRPtm9IWs5GZ/1rW s=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAB5z0+rRDoH/2dsb2JhbABFtDWBB4IYAQEBAwEBAQEPAVsQCxwDAQIvAiUfBwIIBhMJGYdkBAELl3Cfd4sYhTlgA4hAhXeGZoVThS6DE4Fmgn8 X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="sig'?p7s'?scan'208";a="47890432" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 06 Jun 2012 15:39:45 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q56FdWY8012212 for ; Wed, 6 Jun 2012 15:39:45 GMT From: Matt Miller Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16--87251548" Date: Wed, 6 Jun 2012 09:40:01 -0600 References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> To: IETF DANE WG list Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:39:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16--87251548 Content-Type: multipart/signed; boundary=Apple-Mail-15--87251552; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-15--87251552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 6, 2012 09:37:12 MDT > To: i-d-announce@ietf.org > Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Using DNSSEC and DANE as a Prooftype for XMPP = Delegation > Author(s) : Matthew Miller > Peter Saint-Andre > Filename : draft-miller-xmpp-dnssec-prooftype-00.txt > Pages : 6 > Date : 2012-06-06 >=20 > This document defines a model for securely delegating an XMPP = service > for a domain to a host associated with a different domain. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-00.= txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-00.t= xt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-15--87251552 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwNjE1NDAw MVowIwYJKoZIhvcNAQkEMRYEFFKJkncC7dPrxA66U9XUcsvSnxIvMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCBIL1aSsbbzmOdLRVMy9+hPkBj6U4qhJixUwmfpTYoL8eRCeRIRuvB1sgM JKaz9KsrFwh0b4b9za/y2V/chgRCqVakXWDCCfS75rZJd0vFyji6eZRQIeW0mK0iSwMuzrO2/8YE kSfEDvPVNmtCmTrYaRQMeQXRX5dl/8f8LSpL4JRcZKQTrmIHdXBeC6fD860SROTtC8nljm32N1aN 6/eoovd32CNtCDvPQrMosh8MK0QiyjBFaV4+NZe+Ilx6GfHaOH0eFyOGoG8an0jhiyVlS8uxAk27 Z1sWs7bluXL8HLI149qEpovdrwmZvrbGnoMq+JwkIZrX3fINut/80C7oAAAAAAAA --Apple-Mail-15--87251552-- --Apple-Mail-16--87251548 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJPz3nRAAoJEJq6Ou0cgrSPt/wH+gLE41xXy0bl/bhlGnrGC5ah 0NBO4Uhp+BXueanegYq0NQtzN6SMNOVX36VKjSRcP3/leZjeiY1SDd3yCNX/GSG8 bWQlpfYEBMZTSNXvNtiHvbsF3C7KOWINWkzUf6CGSZ4zh7gPkAxXxcVFUmUK4m37 o6dZdVWO7P1KL8me4lPTdbu+ZNeWM/fCf66DKQ37dY10SjvUUhToWTHooDCQXcNd SBeMmH4zxGAHDO/dqrj+a0Rd5XW+nZUqJ6GFdi2zPgs+5J1V/4I4V3t3l4PHKq0I bFpbaEAtbOgsCR7Lhy9MrXki8da4nvZCvpRGkKQkP5Bb8I2lnWEEOMox3E8F6Yo= =3O4b -----END PGP SIGNATURE----- --Apple-Mail-16--87251548-- From fanf2@hermes.cam.ac.uk Thu Jun 7 07:48:24 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECEC21F8914; Thu, 7 Jun 2012 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcGXGFyzjrZj; Thu, 7 Jun 2012 07:48:23 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0321F8912; Thu, 7 Jun 2012 07:48:22 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36650) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Sce0Z-000692-Yh (Exim 4.72) (return-path ); Thu, 07 Jun 2012 15:48:19 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sce0Z-0003A0-Ef (Exim 4.67) (return-path ); Thu, 07 Jun 2012 15:48:19 +0100 Date: Thu, 7 Jun 2012 15:48:19 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FC928DE.6070503@stpeter.im> Message-ID: References: <20120601170306.GA32180@isc.upenn.edu> <4FC928DE.6070503@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:48:24 -0000 Peter Saint-Andre wrote: > On 6/1/12 11:03 AM, Shumon Huque wrote: > > On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: > >> > >> I presume that the client would not actually use mail.example.net as a > >> reference identifier unless DNSSEC is in use, otherwise that would not be > >> secure and is therefore forbidden according to the rules a few paragraphs > >> earlier in RFC 6125. > > > > That sounds correct to me. > > Agreed. That's the approach Matt Miller and I are taking for secure > delegation in XMPP (we'll submit an I-D soonish). I have a review in the works :-) While I was investigating this yesterday I had a look at gmail.com's RFC 6186 email SRV setup since I thought I might use it as an example. Sadly their servers have the wrong certificates - they can only authenticate {imap,pop,smtp}.gmail.com not gmail.com. I've written this up in more detail at http://fanf.livejournal.com/120855.html and notified security@google.com. I don't entirely blame them for this error since RFC 6125's abstractions are a bit confusing and the email example doesn't mention the "derived domain" caveat. Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: West veering northwest 5 or 6. Moderate or rough. Occasional rain. Moderate or good. From stpeter@stpeter.im Thu Jun 7 08:42:28 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA7521F8894; Thu, 7 Jun 2012 08:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.798 X-Spam-Level: X-Spam-Status: No, score=-102.798 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi041FPNqOM5; Thu, 7 Jun 2012 08:42:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A14C721F8811; Thu, 7 Jun 2012 08:42:27 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 64B4D400A4; Thu, 7 Jun 2012 09:59:20 -0600 (MDT) Message-ID: <4FD0CBE1.2070802@stpeter.im> Date: Thu, 07 Jun 2012 09:42:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Tony Finch References: <20120601170306.GA32180@isc.upenn.edu> <4FC928DE.6070503@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, dane@ietf.org Subject: Re: [dane] DANE for MUAs X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:42:28 -0000 On 6/7/12 8:48 AM, Tony Finch wrote: > Peter Saint-Andre wrote: >> On 6/1/12 11:03 AM, Shumon Huque wrote: >>> On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: >>>> >>>> I presume that the client would not actually use mail.example.net as a >>>> reference identifier unless DNSSEC is in use, otherwise that would not be >>>> secure and is therefore forbidden according to the rules a few paragraphs >>>> earlier in RFC 6125. >>> >>> That sounds correct to me. >> >> Agreed. That's the approach Matt Miller and I are taking for secure >> delegation in XMPP (we'll submit an I-D soonish). > > I have a review in the works :-) Thanks. > While I was investigating this yesterday I had a look at gmail.com's > RFC 6186 email SRV setup since I thought I might use it as an example. > Sadly their servers have the wrong certificates - they can only > authenticate {imap,pop,smtp}.gmail.com not gmail.com. I've written this up > in more detail at http://fanf.livejournal.com/120855.html and notified > security@google.com. I don't entirely blame them for this error since > RFC 6125's abstractions are a bit confusing and the email example doesn't > mention the "derived domain" caveat. The more I think about it, the more I realize that RFC 6125 will need to be updated to reflect the use of derived domains under secure delegation. But let's work on our separate email and XMPP I-Ds first. :) Peter -- Peter Saint-Andre https://stpeter.im/ From fanf2@hermes.cam.ac.uk Thu Jun 7 12:13:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431B711E80A3 for ; Thu, 7 Jun 2012 12:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3AOlv2jjR3v for ; Thu, 7 Jun 2012 12:13:21 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD111E8072 for ; Thu, 7 Jun 2012 12:13:20 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34680) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Sci8z-00019z-Rd (Exim 4.72) (return-path ); Thu, 07 Jun 2012 20:13:17 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sci8z-00009l-F5 (Exim 4.67) (return-path ); Thu, 07 Jun 2012 20:13:17 +0100 Date: Thu, 7 Jun 2012 20:13:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matt Miller , Peter Saint-Andre In-Reply-To: Message-ID: References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 19:13:22 -0000 This looks mostly good to me - it's going in pretty much the right direction. By which I mean I am specifying basically the same semantics for the MUA protocols :-) The pragmatics of deployment are somewhat different between XMPP and email, I think, since email deployments usually use certificates for the server host names whereas XMPP deployments use certificates for the JID domain. This might mean we have to specify different fallback behaviour. I haven't pinned down the precise details yet. Detailed comments and questions: Section 4 (XMPP SRV + DNSSEC): There is no mention of CNAME or DNAME indirections. They do not break the model, provided the entire indirection chain is secure. Bogus answers should be treated as security failures and cause the client to abort. Insecure/indeterminate answers should be treated as if DNSSEC were not present. At the moment the draft treats these the same. Points 4,5,6: There is no need to check the security status of the SRV target addresses, since the client is going to verify that the server's certificate matches the SRV target host name. Point 7: The client SHOULD check the source domain if the derived domain doesn't match. Making the source check a MAY is too weak: you don't want DNSSEC deployment to change a working configuration into a broken one. Section 5.1: What if the SRV records specify non-standard port numbers? Or does "not been delegated" mean the same thing as "missing SRV records"? Section 5.2: What port number should the client use in the TLSA query? Should the setup be like this? (using a non-standard port for clarity) _xmpp-client._tcp.im.example.com SRV 1 1 5555 im.example.com _5555._tcp.im.example.com TLSA ... Note that it is very unlikely for the SRV to be insecure but the TLSA to be secure and therefore usable. Perhaps it would be simpler to specify that DANE can't be used if the SRV record is not secure. Section 5.3: In this case the TLSA records should definitely be looked up using the port numbers specified in the SRV records. (That's what draft-ietf-dane-protocol section 3 says.) The requirement to check the source domain if the TLSA records are missing conflicts with section 4. I wonder if there are situations where checking the source (as in 5.1) can conflict with checking the target (as in 5.3). We need to be sure that a service can easily change from one good configuration to another good configuration without accidentally passing through a bad configuration. Section 5.4: What is the point of omitting the name check in this case? Alternatively, what is the point of including the name check in the other DANE cases? My drafts say that name checks should still be performed in the usual way, the idea being that DANE leads to additional verification code paths rather than completely distinct code paths. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, Rockall: North 6 to gale 8, backing northwest 5 to 7 later. Rough, occasionally very rough in Shannon. Rain or showers. Moderate or good. From mamille2@cisco.com Thu Jun 7 13:53:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E8711E80AA for ; Thu, 7 Jun 2012 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.406 X-Spam-Level: X-Spam-Status: No, score=-9.406 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, MANGLED_DOSE=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX7vmN7nQg99 for ; Thu, 7 Jun 2012 13:53:45 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57111E80F2 for ; Thu, 7 Jun 2012 13:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=9458; q=dns/txt; s=iport; t=1339102421; x=1340312021; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=nS8Iz518ub5Vy49mYQovCSQDYXBY+ad6C0b1BCr2IOQ=; b=FWYqL0r/Lu9rjUf96qmwTGyz+7rpD5JQSJXx0anDQp0BTEP45U+c5xXw LQAXnFmsypARibI5Q29k6nu5hipSK6iBkKi91Bu3mDv3aw4AMROsqN+z0 6T8xRXO7C0Tp+gwSTShKyMsRP7OdiI2KEc5JFr0/IFnmWVVjRS/lomuoK k=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMQT0U+rRDoI/2dsb2JhbABFtE2BB4IYAQEBAwESAWYFCwsOOAJVBhMih2QEAQuZLp9xix2FIGADiECFd4ZmgRKEQYhBgWaCf4FA X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="sig'?p7s'?scan'208";a="45515646" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 07 Jun 2012 20:53:32 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q57KrVPv008679; Thu, 7 Jun 2012 20:53:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-44-17976308" From: Matt Miller In-Reply-To: Date: Thu, 7 Jun 2012 14:53:48 -0600 Message-Id: <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> To: Tony Finch Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 20:53:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-44-17976308 Content-Type: multipart/signed; boundary=Apple-Mail-43-17976289; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-43-17976289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2012, at 13:13, Tony Finch wrote: >=20 > This looks mostly good to me - it's going in pretty much the right > direction. By which I mean I am specifying basically the same > semantics for the MUA protocols :-) >=20 Thanks for the feedback. It's good to know we're not completely off (-: > The pragmatics of deployment are somewhat different between XMPP and > email, I think, since email deployments usually use certificates for = the > server host names whereas XMPP deployments use certificates for the = JID > domain. This might mean we have to specify different fallback = behaviour. I > haven't pinned down the precise details yet. >=20 > Detailed comments and questions: >=20 >=20 > Section 4 (XMPP SRV + DNSSEC): >=20 > There is no mention of CNAME or DNAME indirections. They do not break = the > model, provided the entire indirection chain is secure. >=20 Noted. > Bogus answers should be treated as security failures and cause the > client to abort. Insecure/indeterminate answers should be treated as > if DNSSEC were not present. At the moment the draft treats these the = same. >=20 Good point; will fix in next revision. > Points 4,5,6: There is no need to check the security status of the SRV > target addresses, since the client is going to verify that the = server's > certificate matches the SRV target host name. >=20 I think I agree if there are TLSA records to be found. However, if = there are no TLSA records, I do think the checks mean there are = additional names verify against. However, you're not the first to suggest remove them! I'll ponder on = improvements here, and remove them if I can't think of any. > Point 7: The client SHOULD check the source domain if the derived > domain doesn't match. Making the source check a MAY is too weak: > you don't want DNSSEC deployment to change a working configuration > into a broken one. >=20 I think my current phrasing is bad. Basically, we want to expand the = possible identities allowed in the certificate to include the derived = domain in addition to RFC6120's requirements. I'll change the text to = reflect that. >=20 > Section 5.1: What if the SRV records specify non-standard port = numbers? > Or does "not been delegated" mean the same thing as "missing SRV = records"? >=20 For this section, "not been delegated" means "no SRV records". I'll = clarify that. >=20 > Section 5.2: What port number should the client use in the TLSA query? > Should the setup be like this? (using a non-standard port for clarity) >=20 > _xmpp-client._tcp.im.example.com SRV 1 1 5555 im.example.com > _5555._tcp.im.example.com TLSA ... >=20 In this particular case, I think we really do want the standard port = 5222, e.g. "_5222._tcp.im.example.com". > Note that it is very unlikely for the SRV to be insecure but the TLSA = to > be secure and therefore usable. Perhaps it would be simpler to specify > that DANE can't be used if the SRV record is not secure. >=20 That would be easier. I'll ponder on this more. >=20 > Section 5.3: >=20 > In this case the TLSA records should definitely be looked > up using the port numbers specified in the SRV records. > (That's what draft-ietf-dane-protocol section 3 says.) >=20 I can remove the text after "... then the TLS client SHOULD query for a = TLSA resource record as described in [DANE]". > The requirement to check the source domain if the TLSA records are > missing conflicts with section 4. >=20 Good point; will remove in next revision. > I wonder if there are situations where checking the source (as in 5.1) > can conflict with checking the target (as in 5.3). We need to be sure > that a service can easily change from one good configuration to > another good configuration without accidentally passing through a bad > configuration. >=20 I think the two can be treated as mutually exclusive without undo burden = on implementations. if (source domain =3D=3D derived domain) do 5.1 elif (source domain !=3D derived domain) do 5.3 Not sure yet if it needs to explicitly stated anywhere, but I'll think = more about it. >=20 > Section 5.4: >=20 > What is the point of omitting the name check in this case? > Alternatively, what is the point of including the name check in the > other DANE cases? My drafts say that name checks should still be > performed in the usual way, the idea being that DANE leads to > additional verification code paths rather than completely distinct > code paths. >=20 My thinking was, if we got to this point, then the name in the = certificate was no longer material. The delegation by the source domain = to the derived domain was already proved, and this check simply added a = technicality to fail on. However, it's not something I'm willing to fight for. I can remove it = unless there's a better suggestion. Thanks again for the feedback! - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-43-17976289 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwNzIwNTM0 OVowIwYJKoZIhvcNAQkEMRYEFAWdHGDIMU4drvLI5QmnduxLBRCtMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQA4MOtpPHWnzHK3rhJlnlYz/5dvQEDMCFcFkx3oFO2EaXW8eXq/kgwXXkXU c2MuXbkNb0V7tyM9ePTZ350jvak9cMk1qEfQqqGt1JewvIPjIqujmchrS0/N8yHixCeY1IJRj0ER 5o1HU8FcXe7e2W3BjLeUzOWfRUEDjMqGOCmt6yA5hP4BIzFEGkZSkGbulhf7C1dzNO+ULNP04g6t 1uEV5uKVz0F2vGCN7+JsdaROZFDgiyg8wZEnTdBrd9IMsunuagzdAYwTUx2EdwUDB9QYWbug1eLl IyfqsyvIQq/tQkN5wKvVw4yjQcNr4JQEZ4NrtlKg1IKZJAH0UuCUDzKTAAAAAAAA --Apple-Mail-43-17976289-- --Apple-Mail-44-17976308 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP0RTdAAoJEJq6Ou0cgrSP8KkH/iRvdwe+4485gbG48oC1RJYJ 1KY8uc/EkVkZO/Jo9kM8x5NQXxZFDE9MKN77KTZK2s6Dv7w0LC8rDbFIhe63sj/7 p7kt6Sk4kb0k6pl8/EOG8h3Fjpd36cN/1uWPPfvG4sWBVmeNonlVqXscgOQz8YMP Dvrh7v2pN+nWN6U5BmQgnnVh6PIUESk/hKG3puOVu2ReBqDav+pOVYt1qIPtm/4d veAmu65mztBP4AT3mJA+pqngZ0vkG1GhUN+NWeWKzP+Jml36qhivxHu57/O5bRCU DQjKJ8LfnwNgUe9S1bmcKfjOdq3W9P5jFbJF0fzwW9RYBwxHXYtohscl/pOaW9k= =wyo0 -----END PGP SIGNATURE----- --Apple-Mail-44-17976308-- From stpeter@stpeter.im Thu Jun 7 14:12:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C521F8710 for ; Thu, 7 Jun 2012 14:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.68 X-Spam-Level: X-Spam-Status: No, score=-101.68 tagged_above=-999 required=5 tests=[AWL=-1.381, BAYES_00=-2.599, MANGLED_DOSE=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wVypL6GSHdv for ; Thu, 7 Jun 2012 14:12:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8174221F870E for ; Thu, 7 Jun 2012 14:12:56 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BC667400A4; Thu, 7 Jun 2012 15:29:49 -0600 (MDT) Message-ID: <4FD11956.7000400@stpeter.im> Date: Thu, 07 Jun 2012 15:12:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Matt Miller References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> In-Reply-To: <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:12:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Matt and Tony, a few notes from my perspective. On 6/7/12 2:53 PM, Matt Miller wrote: > > On Jun 7, 2012, at 13:13, Tony Finch wrote: > >> >> This looks mostly good to me - it's going in pretty much the >> right direction. By which I mean I am specifying basically the >> same semantics for the MUA protocols :-) >> > > Thanks for the feedback. It's good to know we're not completely > off (-: > >> The pragmatics of deployment are somewhat different between XMPP >> and email, I think, since email deployments usually use >> certificates for the server host names whereas XMPP deployments >> use certificates for the JID domain. This might mean we have to >> specify different fallback behaviour. I haven't pinned down the >> precise details yet. >> >> Detailed comments and questions: >> >> >> Section 4 (XMPP SRV + DNSSEC): >> >> There is no mention of CNAME or DNAME indirections. They do not >> break the model, provided the entire indirection chain is >> secure. >> > > Noted. Personally I'd prefer to not mention those indirections for now because they muddy the waters a bit for typical XMPP deployments. >> Bogus answers should be treated as security failures and cause >> the client to abort. Insecure/indeterminate answers should be >> treated as if DNSSEC were not present. At the moment the draft >> treats these the same. >> > > Good point; will fix in next revision. Agreed. >> Points 4,5,6: There is no need to check the security status of >> the SRV target addresses, since the client is going to verify >> that the server's certificate matches the SRV target host name. >> > > I think I agree if there are TLSA records to be found. However, > if there are no TLSA records, I do think the checks mean there are > additional names verify against. > > However, you're not the first to suggest remove them! I'll ponder > on improvements here, and remove them if I can't think of any. We definitely need (and already do) step 4 in Section 4. The question is whether we need to validate the A/AAAA lookups as secure. I see Tony's point here and perhaps we don't need the latter validation. >> Point 7: The client SHOULD check the source domain if the derived >> domain doesn't match. Making the source check a MAY is too weak: >> you don't want DNSSEC deployment to change a working >> configuration into a broken one. >> > > I think my current phrasing is bad. Basically, we want to expand > the possible identities allowed in the certificate to include the > derived domain in addition to RFC6120's requirements. I'll change > the text to reflect that. Right, sloppy wording on our part. >> Section 5.1: What if the SRV records specify non-standard port >> numbers? Or does "not been delegated" mean the same thing as >> "missing SRV records"? >> > > For this section, "not been delegated" means "no SRV records". > I'll clarify that. Can't an SRV lookup for foo.example.com point to foo.example.com? That wouldn't be delegation to another entity, even if the port were non-standard. >> Section 5.2: What port number should the client use in the TLSA >> query? Should the setup be like this? (using a non-standard port >> for clarity) >> >> _xmpp-client._tcp.im.example.com SRV 1 1 5555 im.example.com >> _5555._tcp.im.example.com TLSA ... >> > > In this particular case, I think we really do want the standard > port 5222, e.g. "_5222._tcp.im.example.com". We had some discussion about this on the XMPP WG list, see for example: http://www.ietf.org/mail-archive/web/xmpp/current/msg02765.html My reading of the DANE spec is that the port in the prepared domain name would be the port that is assumed to be correct for the application protocol in question. Since the IANA-registered port for XMPP client-to-server communication is 5222, you'd use 5222 instead of any non-standard port that you might have discovered via SRV. But I admit that I might be reading too much into the DANE spec on this point. >> Note that it is very unlikely for the SRV to be insecure but the >> TLSA to be secure and therefore usable. Perhaps it would be >> simpler to specify that DANE can't be used if the SRV record is >> not secure. >> > > That would be easier. I'll ponder on this more. This might be related to two points in RFC 6120, Section 3.2.1: 8. If the initiating entity receives a response to its SRV query but it is not able to establish an XMPP connection using the data received in the response, it SHOULD NOT attempt the fallback process described in the next section (this helps to prevent a state mismatch between inbound and outbound connections). 9. If the initiating entity does not receive a response to its SRV query, it SHOULD attempt the fallback process described in the next section. I'll think about this a bit more, too. >> Section 5.3: >> >> In this case the TLSA records should definitely be looked up >> using the port numbers specified in the SRV records. (That's >> what draft-ietf-dane-protocol section 3 says.) Does it? See above. It depends on what is meant by "assumed to exist" in the following text: 1. The decimal representation of the port number on which a TLS- based service is assumed to exist is prepended with an underscore character ("_") to become the left-most label in the prepared domain name. > I can remove the text after "... then the TLS client SHOULD query > for a TLSA resource record as described in [DANE]". Let's see what the outcome of this port conversation is first. :) >> The requirement to check the source domain if the TLSA records >> are missing conflicts with section 4. >> > > Good point; will remove in next revision. Yep, thanks for noticing the mismatch. >> I wonder if there are situations where checking the source (as >> in 5.1) can conflict with checking the target (as in 5.3). We >> need to be sure that a service can easily change from one good >> configuration to another good configuration without accidentally >> passing through a bad configuration. >> > > I think the two can be treated as mutually exclusive without undo > burden on implementations. > > if (source domain == derived domain) do 5.1 elif (source domain > != derived domain) do 5.3 > > Not sure yet if it needs to explicitly stated anywhere, but I'll > think more about it. > >> >> Section 5.4: >> >> What is the point of omitting the name check in this case? >> Alternatively, what is the point of including the name check in >> the other DANE cases? My drafts say that name checks should >> still be performed in the usual way, the idea being that DANE >> leads to additional verification code paths rather than >> completely distinct code paths. >> > > My thinking was, if we got to this point, then the name in the > certificate was no longer material. The delegation by the source > domain to the derived domain was already proved, and this check > simply added a technicality to fail on. Agreed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/RGVYACgkQNL8k5A2w/vxxXACdE1NrL7IiFJj0Mq0BTAANi2Qd DLEAoOWiVJjS0mb61Ju1cJSQnpuvkmTe =IZpz -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Jun 7 15:36:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4321F84FE for ; Thu, 7 Jun 2012 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.806 X-Spam-Level: X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QBoRKZxBTul for ; Thu, 7 Jun 2012 15:36:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87911E80DE for ; Thu, 7 Jun 2012 15:36:31 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B8D8B400A4; Thu, 7 Jun 2012 16:53:24 -0600 (MDT) Message-ID: <4FD12CED.707@stpeter.im> Date: Thu, 07 Jun 2012 16:36:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Matt Miller References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> In-Reply-To: <4FD11956.7000400@stpeter.im> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 22:36:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/7/12 3:12 PM, Peter Saint-Andre wrote: > Hi Matt and Tony, a few notes from my perspective. > > On 6/7/12 2:53 PM, Matt Miller wrote: > >> On Jun 7, 2012, at 13:13, Tony Finch wrote: > >>> >>> This looks mostly good to me - it's going in pretty much the >>> right direction. By which I mean I am specifying basically the >>> same semantics for the MUA protocols :-) >>> > >> Thanks for the feedback. It's good to know we're not completely >> off (-: > >>> The pragmatics of deployment are somewhat different between >>> XMPP and email, I think, since email deployments usually use >>> certificates for the server host names whereas XMPP >>> deployments use certificates for the JID domain. This might >>> mean we have to specify different fallback behaviour. I haven't >>> pinned down the precise details yet. >>> >>> Detailed comments and questions: >>> >>> >>> Section 4 (XMPP SRV + DNSSEC): >>> >>> There is no mention of CNAME or DNAME indirections. They do not >>> break the model, provided the entire indirection chain is >>> secure. >>> > >> Noted. > > Personally I'd prefer to not mention those indirections for now > because they muddy the waters a bit for typical XMPP deployments. > >>> Bogus answers should be treated as security failures and cause >>> the client to abort. Insecure/indeterminate answers should be >>> treated as if DNSSEC were not present. At the moment the draft >>> treats these the same. >>> > >> Good point; will fix in next revision. > > Agreed. > >>> Points 4,5,6: There is no need to check the security status of >>> the SRV target addresses, since the client is going to verify >>> that the server's certificate matches the SRV target host >>> name. >>> > >> I think I agree if there are TLSA records to be found. However, >> if there are no TLSA records, I do think the checks mean there >> are additional names verify against. > >> However, you're not the first to suggest remove them! I'll >> ponder on improvements here, and remove them if I can't think of >> any. > > We definitely need (and already do) step 4 in Section 4. The > question is whether we need to validate the A/AAAA lookups as > secure. I see Tony's point here and perhaps we don't need the > latter validation. > >>> Point 7: The client SHOULD check the source domain if the >>> derived domain doesn't match. Making the source check a MAY is >>> too weak: you don't want DNSSEC deployment to change a working >>> configuration into a broken one. >>> > >> I think my current phrasing is bad. Basically, we want to >> expand the possible identities allowed in the certificate to >> include the derived domain in addition to RFC6120's requirements. >> I'll change the text to reflect that. > > Right, sloppy wording on our part. > >>> Section 5.1: What if the SRV records specify non-standard port >>> numbers? Or does "not been delegated" mean the same thing as >>> "missing SRV records"? >>> > >> For this section, "not been delegated" means "no SRV records". >> I'll clarify that. > > Can't an SRV lookup for foo.example.com point to foo.example.com? > That wouldn't be delegation to another entity, even if the port > were non-standard. > >>> Section 5.2: What port number should the client use in the TLSA >>> query? Should the setup be like this? (using a non-standard >>> port for clarity) >>> >>> _xmpp-client._tcp.im.example.com SRV 1 1 5555 im.example.com >>> _5555._tcp.im.example.com TLSA ... >>> > >> In this particular case, I think we really do want the standard >> port 5222, e.g. "_5222._tcp.im.example.com". > > We had some discussion about this on the XMPP WG list, see for > example: > > http://www.ietf.org/mail-archive/web/xmpp/current/msg02765.html > > My reading of the DANE spec is that the port in the prepared > domain name would be the port that is assumed to be correct for > the application protocol in question. Since the IANA-registered > port for XMPP client-to-server communication is 5222, you'd use > 5222 instead of any non-standard port that you might have > discovered via SRV. But I admit that I might be reading too much > into the DANE spec on this point. Matt and I talked about in person and he convinced me that the port wouldn't be the IANA-registered port but whatever port you happen to be using for your XMPP service. So despite the fact that port 80 is typically an HTTP port, jabber80.com (yes, there is such a thing!) would have: _xmpp-client._tcp.jabber80.com SRV 1 1 80 im.example.com _80._tcp.im.example.com TLSA ... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/RLO0ACgkQNL8k5A2w/vztsQCfbtWmpta6IeaRXh9urPYIboBy Z50AoLz0z5F4OXDAjclmIjbOtrFhBwF9 =kE80 -----END PGP SIGNATURE----- From mamille2@cisco.com Thu Jun 7 15:48:01 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89F711E80E6 for ; Thu, 7 Jun 2012 15:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyzL43e2+FJq for ; Thu, 7 Jun 2012 15:48:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 56CAD11E80E5 for ; Thu, 7 Jun 2012 15:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=8558; q=dns/txt; s=iport; t=1339109280; x=1340318880; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ek+YGu8hrMx/Y3RLEsAODotZhIWcRwSM6RU5/dTfplE=; b=QtMhDfUI/dOgF59P5KvL3AzMHxbNim3ygjxYEDN/wzTH6/lq0dTABYdO 86oV4g2MyzFUzBeqlcOasJPBhuF6PayXmMtY17sKiuZGNPt84ctjcz4ZW 3Ont2Q/1J2sOgpsAIpfUmCy1shlTXFgfqrmCWVYNtDOtEj8g7SZv6lmnk 0=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACUv0U+rRDoH/2dsb2JhbABFtE2BB4IYAQEBAwESAWYQCxguAlUGEwkZh2QEAQuZMJ9uix0ahQZgA4hAhXeGZoEShEGIQYFmgn+BOQcc X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="sig'?p7s'?scan'208";a="44991728" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 07 Jun 2012 22:47:59 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q57MlwIm027030; Thu, 7 Jun 2012 22:47:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-46-24844117" From: Matt Miller In-Reply-To: <4FD11956.7000400@stpeter.im> Date: Thu, 7 Jun 2012 16:48:16 -0600 Message-Id: <270B552A-7D2A-4E44-B31A-0DB169028DAC@cisco.com> References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> To: Peter Saint-Andre Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 22:48:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-46-24844117 Content-Type: multipart/signed; boundary=Apple-Mail-45-24844098; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-45-24844098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2012, at 15:12, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Matt and Tony, a few notes from my perspective. >=20 > On 6/7/12 2:53 PM, Matt Miller wrote: >>=20 >> On Jun 7, 2012, at 13:13, Tony Finch wrote: < snip > >>> Points 4,5,6: There is no need to check the security status of >>> the SRV target addresses, since the client is going to verify >>> that the server's certificate matches the SRV target host name. >>>=20 >>=20 >> I think I agree if there are TLSA records to be found. However, >> if there are no TLSA records, I do think the checks mean there are=20 >> additional names verify against. >>=20 >> However, you're not the first to suggest remove them! I'll ponder >> on improvements here, and remove them if I can't think of any. >=20 > We definitely need (and already do) step 4 in Section 4. The question > is whether we need to validate the A/AAAA lookups as secure. I see > Tony's point here and perhaps we don't need the latter validation. >=20 If this specification is all about DANE (which, to me, implies DNSSEC), = then I agree it's not necessary. If this specification is about DNSSEC with DANE goodness, then I do = think the A/AAAA verification is necessary, or at least recommended. Per an IRL conversation between Peter and I, I'll change this to be = RECOMMENDED sans DANE, but MAY (at best) con DANE. >>>=20 < snip > >=20 >>> Section 5.1: What if the SRV records specify non-standard port=20 >>> numbers? Or does "not been delegated" mean the same thing as=20 >>> "missing SRV records"? >>>=20 >>=20 >> For this section, "not been delegated" means "no SRV records". >> I'll clarify that. >=20 > Can't an SRV lookup for foo.example.com point to foo.example.com? That > wouldn't be delegation to another entity, even if the port were > non-standard. >=20 With the IRL conversation stpeter and I just had, I'm going to re-word = this section to mean "no SRV records". I'll try to re-word the "Secure = Delegation" section to include the case where the SRV record's target = host is identical to the source domain (but might be to a different = port). >>> Section 5.2: What port number should the client use in the TLSA=20 >>> query? Should the setup be like this? (using a non-standard port=20 >>> for clarity) >>>=20 >>> _xmpp-client._tcp.im.example.com SRV 1 1 5555 im.example.com=20 >>> _5555._tcp.im.example.com TLSA ... >>>=20 >>=20 >> In this particular case, I think we really do want the standard >> port 5222, e.g. "_5222._tcp.im.example.com". >=20 > We had some discussion about this on the XMPP WG list, see for = example: >=20 > http://www.ietf.org/mail-archive/web/xmpp/current/msg02765.html >=20 > My reading of the DANE spec is that the port in the prepared domain > name would be the port that is assumed to be correct for the > application protocol in question. Since the IANA-registered port for > XMPP client-to-server communication is 5222, you'd use 5222 instead of > any non-standard port that you might have discovered via SRV. But I > admit that I might be reading too much into the DANE spec on this = point. >=20 See note about IRL conversation (-: >>>=20 >>=20 < snip > >>>=20 >>> Section 5.4: >>>=20 >>> What is the point of omitting the name check in this case?=20 >>> Alternatively, what is the point of including the name check in=20 >>> the other DANE cases? My drafts say that name checks should >>> still be performed in the usual way, the idea being that DANE >>> leads to additional verification code paths rather than >>> completely distinct code paths. >>>=20 >>=20 >> My thinking was, if we got to this point, then the name in the=20 >> certificate was no longer material. The delegation by the source=20 >> domain to the derived domain was already proved, and this check=20 >> simply added a technicality to fail on. >=20 > Agreed. >=20 But like I said, it's not a hill for me to die on. I'm content with = keeping it or removing it. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-45-24844098 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwNzIyNDgx N1owIwYJKoZIhvcNAQkEMRYEFEX1U5VUfEGVDmbY0MRSu+LIhSEMMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAko+eHdHKTcj3gV3RJQo9s38DuPvx2lldteeymCGfeyKPHX2OmB+Zo7E2h 4B5W4huQeQaNYjYJ/g+C3cPiLCMriC57bQOVOhHD0P+Lq9zbTpmoapu+qDyVPP3jQdw/dSQjE2cl UJS69oaojcY1rTF/m7hTNdudX3Sy8f0j8agjXJ9HUJ5m4BIG4fKMC/y1ASjWyfUrKZhNnYNO0ecA fLNrm4fI6q/R34x8qPHc8Aqw5oJ1P9NRN6+/b18d75J0rxrQfuG0Zwe99ML2MAcKpsR++VxpCj0C JoR9X1flvHG8XOvLAaUnOvfVoSawbZRilAKkBTuxlTWNrMb+CutpPVI2AAAAAAAA --Apple-Mail-45-24844098-- --Apple-Mail-46-24844117 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP0S+xAAoJEJq6Ou0cgrSPFE8IANS9+X1dHPJ8TE33cFb4GhHM BfLTI9DprA5F4eKwpPNkIToX4wgbO7KzxHfFRA8dLoyibGo5ouAyuZQphNOvjThM uP5BNSTwgyUb4zf6X9KghPPsuCYUvq92MNsGmbQ4C1BE/NLL/pR4mnzPVRiDeRbM f61SFNyoxbyYk3uZ2oh+mPuCwgiHB1OAClyh5MvOE88yEz4cCev6vypQdDmt9JsC LEICU6g9d1lwTKJMH3ENiIni/Bg6JfKjiBk9pXnazdIT/HprclbkWg6EI3CtCcaI wog8X03ynTJzHMR4rEF0yxgI7oB2Bv6YxAorqbS4p/YHMa0ZGYFlXOWaRa6rQ+Y= =xUue -----END PGP SIGNATURE----- --Apple-Mail-46-24844117-- From fanf2@hermes.cam.ac.uk Fri Jun 8 03:43:39 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617A321F87B1 for ; Fri, 8 Jun 2012 03:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pERdqZSi4YFn for ; Fri, 8 Jun 2012 03:43:38 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6065A21F8786 for ; Fri, 8 Jun 2012 03:43:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48646) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1ScwfH-0000PF-Ya (Exim 4.72) (return-path ); Fri, 08 Jun 2012 11:43:35 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1ScwfH-0008Iu-LA (Exim 4.67) (return-path ); Fri, 08 Jun 2012 11:43:35 +0100 Date: Fri, 8 Jun 2012 11:43:35 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <4FD11956.7000400@stpeter.im> Message-ID: References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:43:39 -0000 Peter Saint-Andre wrote: > >> What is the point of omitting the name check in this case? > >> Alternatively, what is the point of including the name check in > >> the other DANE cases? My drafts say that name checks should > >> still be performed in the usual way, the idea being that DANE > >> leads to additional verification code paths rather than > >> completely distinct code paths. > >> > > > > My thinking was, if we got to this point, then the name in the > > certificate was no longer material. The delegation by the source > > domain to the derived domain was already proved, and this check > > simply added a technicality to fail on. > > Agreed. Yes this is a valid argument and I agree. However I also think consistency is important. Why would some TLSA usages require name matches and others not? Why disable a check done by existing code rather than just adding checks? Tony. -- f.anthony.n.finch http://dotat.at/ Thames, Dover, Wight, Portland: Southwest 7 to severe gale 9, decreasing 6 later in Wight and Portland. Rough or very rough. Squally showers. Moderate or good. From fanf2@hermes.cam.ac.uk Fri Jun 8 03:54:04 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB1B21F8882 for ; Fri, 8 Jun 2012 03:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyiTcgy4SZjH for ; Fri, 8 Jun 2012 03:54:04 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id D5C2F21F8879 for ; Fri, 8 Jun 2012 03:54:03 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42597) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1ScwpN-0004kb-qa (Exim 4.72) (return-path ); Fri, 08 Jun 2012 11:54:01 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1ScwpN-0001c0-8j (Exim 4.67) (return-path ); Fri, 08 Jun 2012 11:54:01 +0100 Date: Fri, 8 Jun 2012 11:54:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Matt Miller In-Reply-To: <270B552A-7D2A-4E44-B31A-0DB169028DAC@cisco.com> Message-ID: References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> <270B552A-7D2A-4E44-B31A-0DB169028DAC@cisco.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:54:04 -0000 Matt Miller wrote: > On Jun 7, 2012, at 15:12, Peter Saint-Andre wrote: Glad we're all pretty much agreeing :-) One further question: > If this specification is about DNSSEC with DANE goodness, then I do > think the A/AAAA verification is necessary, or at least recommended. What advantage does the verification have, if the client is going to check the server certificate? (I'm assuming that bogus == DNS lookup failure, so the question is about secure vs. insecure.) The client is knows the SRV record is secure so the link from source domain to derived domain is secure. If the address records are insecure, the client needs to check a certificate to be sure the server is the right one; the client gets the same level of assurance whether it matches the source or derived domain. Tony. -- f.anthony.n.finch http://dotat.at/ Fisher: Southeast 5 to 7. Moderate or rough. Occasional rain. Good, occasionally poor. From mamille2@cisco.com Fri Jun 8 10:01:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EE721F87A8 for ; Fri, 8 Jun 2012 10:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3uy0l6yBaoN for ; Fri, 8 Jun 2012 10:01:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2B21F87A4 for ; Fri, 8 Jun 2012 10:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5803; q=dns/txt; s=iport; t=1339174905; x=1340384505; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=RoKeYaGWV2l1HPWpweag/oPSbnZCdnD1wHr9wxAxv/U=; b=WgjgM/Ik6VBmd/GDZgrMMTBPBn6knfX7o8oDZbQU9HekLColeDbzvrnQ xEarL1NxmMJPDRoqGD1hrosW3s3iE3Kv0TiEz6Y9na1KQBl4FP/hgfdVm SCtDPDFdj16Ga42w4JDYccIAJpRE82+yOFUHvxLwlkbHSk/KmzFZZ25Hx 0=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPAu0k+rRDoI/2dsb2JhbABFtFeBB4IYAQEBAwESAWYFCwsOCi4CVQYTIodkBAGZSZ9oiyaFIGADiECFeIZmgRKEQYhCgWaCfw X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="sig'?p7s'?scan'208";a="48126910" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Jun 2012 17:01:45 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q58H1i82027342; Fri, 8 Jun 2012 17:01:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-50-90471208" From: Matt Miller In-Reply-To: Date: Fri, 8 Jun 2012 11:02:03 -0600 Message-Id: References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> <270B552A-7D2A-4E44-B31A-0DB169028DAC@cisco.com> To: Tony Finch Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:01:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-50-90471208 Content-Type: multipart/signed; boundary=Apple-Mail-49-90471203; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-49-90471203 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 8, 2012, at 04:54, Tony Finch wrote: > Matt Miller wrote: >> On Jun 7, 2012, at 15:12, Peter Saint-Andre wrote: >=20 > Glad we're all pretty much agreeing :-) One further question: >=20 >> If this specification is about DNSSEC with DANE goodness, then I do >> think the A/AAAA verification is necessary, or at least recommended. >=20 > What advantage does the verification have, if the client is going to = check > the server certificate? (I'm assuming that bogus =3D=3D DNS lookup = failure, so > the question is about secure vs. insecure.) The client is knows the = SRV > record is secure so the link from source domain to derived domain is > secure. If the address records are insecure, the client needs to check = a > certificate to be sure the server is the right one; the client gets = the > same level of assurance whether it matches the source or derived = domain. >=20 I was thinking of a case where a hosting provider ("hosting.example.net" = in our text) has their DNS entries hijacked, and the hijacker finds a CA = that will issue them certs for the hijacked name. My thinking was this = can be mitigated by verifying the A/AAAA records. That was my thinking, but I'm less convinced it's worth covering now, = and will probably remove in the next revision. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-49-90471203 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwODE3MDIw NFowIwYJKoZIhvcNAQkEMRYEFHNDrFc28iSKo8cwQv8z2VxNL3WtMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQBHX8Wl0HBFUSNJ+CPpCm3NMCFLfreAIBGUhXQbWl+ltCdmxjN/0TkHrjub bEwM7m3BKc7CNLIJ16amel4a4FGynHXQfTQ63glmz7sv7BuGcg1HTkY8IU9sMz/yG2VKrnmtIkVo TVKcNfZr/KArBZ+BGUASw3VS4WQLS7jr7s/0zSOj2l9wqrNV1otOgW/nBkEau7ixq0m4OyYHpo/A dMYmkvm/Tixar+j9jHVuwCE2pWPsdGvEFKYzhl0wDNbPyl78738tZ1GeqodXBZOBK+eAcVRqTcPh fAchc9xNqn2kfNUXAb6uv0Dvlq/wKTAbcbJB969KWG/n1Qp9Gdk057BPAAAAAAAA --Apple-Mail-49-90471203-- --Apple-Mail-50-90471208 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP0jAMAAoJEJq6Ou0cgrSP0ggIAO3nQTT29DkW3jz4KooFStaz UmvwNSrTMI13pjZc26lkEFbCKbPR3qdaqxuq0ygnGXkKtcdGgnIczx7pxxvZVbep G2nn98EYBtid5Gxl5n/Rw84D6cMxMRVW4HIbM7IMCFYW34Fq2q4+Bw0DTK6Wxvfe ExvH3OmnORV8mnNLztUgS3m6d6mndmUUqwEpO1G3724f+fPDUZNlH3zcNuXraI9D D9+UoO2/HRvdT0fcMDVWds9VKl+l7UY9H9Kyff9B1tiP/L4D2fGONTcZe5G++7KU /CF8Fa/y1dGdT2cT6RcG430u/UqnpS21AzXLSWOW+SMgc/RTHKYWSdYXAHnia7w= =ttC9 -----END PGP SIGNATURE----- --Apple-Mail-50-90471208-- From mamille2@cisco.com Fri Jun 8 10:02:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A627F21F88C5 for ; Fri, 8 Jun 2012 10:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkkChIIJeWo8 for ; Fri, 8 Jun 2012 10:02:14 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4421F88B7 for ; Fri, 8 Jun 2012 10:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5667; q=dns/txt; s=iport; t=1339174934; x=1340384534; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QJxi+qeXXjax3gwXuKQTKnwLxpv6yTvZ4LNKmPdhvw0=; b=QBq3MkJzUFxcfM61n+ADzWenzrq1x9UC8M7pFRSDixIQYD9v1hJbP0dI IGQw9YBer5qRSWyZSZizygOwqk5xSnC1CxKdJEjnF+lUt5VH4yeguLah+ 73PMAkfpwfiF/ZwQBeokz43tElYvRAa9WeK47QGREktvRr4hBItgFd7Ft 8=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ8u0k+rRDoI/2dsb2JhbABFtFeBB4IYAQEBAwESAWYFCwsOCi4CVQYTIodkBAGZSJ9oiyaFIGADiECFeIZmhVOIQoFmgn8 X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="sig'?p7s'?scan'208";a="45098497" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 08 Jun 2012 17:02:14 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q58H1i83027342; Fri, 8 Jun 2012 17:02:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-52-90501462" From: Matt Miller In-Reply-To: Date: Fri, 8 Jun 2012 11:02:34 -0600 Message-Id: <8AFED8BC-9E9A-4ED7-950A-5E3579799BAE@cisco.com> References: <20120606153712.8378.19976.idtracker@ietfa.amsl.com> <04872EB1-060F-4605-8E1F-6A45152600CF@cisco.com> <4FD11956.7000400@stpeter.im> To: Tony Finch Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: IETF DANE WG list Subject: Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:02:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-52-90501462 Content-Type: multipart/signed; boundary=Apple-Mail-51-90501458; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-51-90501458 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 8, 2012, at 04:43, Tony Finch wrote: > Peter Saint-Andre wrote: >=20 >>>> What is the point of omitting the name check in this case? >>>> Alternatively, what is the point of including the name check in >>>> the other DANE cases? My drafts say that name checks should >>>> still be performed in the usual way, the idea being that DANE >>>> leads to additional verification code paths rather than >>>> completely distinct code paths. >>>>=20 >>>=20 >>> My thinking was, if we got to this point, then the name in the >>> certificate was no longer material. The delegation by the source >>> domain to the derived domain was already proved, and this check >>> simply added a technicality to fail on. >>=20 >> Agreed. >=20 > Yes this is a valid argument and I agree. However I also think = consistency > is important. Why would some TLSA usages require name matches and = others > not? Why disable a check done by existing code rather than just adding > checks? >=20 For Usage 3, the TLS client was effectively told what to match in = totality. I see this check as overly burdensome on deployments, and not = very burdensome on implementers. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-51-90501458 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwODE3MDIz NFowIwYJKoZIhvcNAQkEMRYEFGIZfG8k3VI7e7J0D2T/fB1vCAU8MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQB1IcwMQxDUJDhmb1cePewcxUjDZ5xtjbNB9MRl34EHuQH9edlt3rv7VH4d s2Ej+vG0ZVChcj1UOkbG6rBQC9bkmnYjaQU7UtpB4XEXKxL3VDBSU1eboqgOO4TwCn7JnR8QpCan WiLH6eI0IlrFOO7FRqiFpqKiVFnujOeBcBCgSDkXvvlK/+dpufLKrefOW2JNvsHCHBEUE9T3nGWX 1SAYfRFsvoGXoarToZzXUuJu1Zq7dR+p/2uk37TegnLojz7CGnfUsgKZXtdqnZNTyblNQn5+xHEj NIrDcIj9p6GQLo/nBiREz0EooBqI2oE9AZbWR7EUUX5TJ8HV0raBREuXAAAAAAAA --Apple-Mail-51-90501458-- --Apple-Mail-52-90501462 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP0jAqAAoJEJq6Ou0cgrSPxaUH/0cE04fQJfNRRdBgTxSJQQDO +umXGjSk3bcBDdnjXWuNVEe4uRu/42EeQjCeQbjvvqVVFeEedidYy659U/tmP51X IjgFj7rnbSu6pLuxVSq+fnk4x9E5YgKM8zHDtslzd5akwoExcp28LlUp2DazgvGy ws9Jf3Bhk39piRn756BpDmRprkCja1bzYkBZBmSfXUo3Jjn1bFE4EU81yUIZNhgt WSRfg4QHzO8ppUaqMXoOuJHSBZAL2X5OGZonAR+qTgHLsSJE9D2a/InFP87eJgbA jJRZuz8sqccs+nD0XRUqtbKRhoWgMBr2t51aGUaK/TSQeYiB3U0xboIYg6iDJ/s= =w8Ii -----END PGP SIGNATURE----- --Apple-Mail-52-90501462-- From mamille2@cisco.com Fri Jun 8 13:28:06 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AE311E817B for ; Fri, 8 Jun 2012 13:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha6V2f9hoWKS for ; Fri, 8 Jun 2012 13:28:05 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9453711E8179 for ; Fri, 8 Jun 2012 13:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6108; q=dns/txt; s=iport; t=1339187285; x=1340396885; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=hR1VJhSfXCkxB9mrd+6385d/Ejy9wqE+i4LYR2xU5r0=; b=hZDsyvp2VQw9iVE+8oRLebyEUc/Q4AMsC7suhenEbXCqAo6pP+d+UUS4 +fSyLfyDZRfG5s/PR/Ij5zI4ByZD6kuU+0rNbBvs8SmTyVjYqXJ0k8f6O al2YtyBm+wtUn4J1mZJv0RS7i/uQ2lHd3Hwcnbxq3ZTDVGKORnPZq0Mjz c=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHJf0k+rRDoG/2dsb2JhbABFtFeBB4IYAQEBAwEBAQEPAVsQCxwDAQIvAiUfBwIIBhMJGYdkBAELmRKfYYsmhSBgA4hAhXiGZoVThS6DFIFmgn8 X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="sig'?p7s'?scan'208";a="48235810" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Jun 2012 20:28:04 +0000 Received: from [64.101.72.35] ([64.101.72.35]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q58KRZ3s023000 for ; Fri, 8 Jun 2012 20:28:04 GMT From: Matt Miller Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-56-102851506" Date: Fri, 8 Jun 2012 14:28:24 -0600 References: <20120608202212.8859.65155.idtracker@ietfa.amsl.com> To: IETF DANE WG list Message-Id: <05B409C3-774F-4FBF-AC7C-48B32EBBFA47@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Subject: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-01.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 20:28:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-56-102851506 Content-Type: multipart/signed; boundary=Apple-Mail-55-102851499; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-55-102851499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, version -01 published based on feedback. - m&m Matt Miller - Cisco Systems, Inc. Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 8, 2012 14:22:12 MDT > To: i-d-announce@ietf.org > Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-01.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Using DNSSEC and DANE as a Prooftype for XMPP = Delegation > Author(s) : Matthew Miller > Peter Saint-Andre > Filename : draft-miller-xmpp-dnssec-prooftype-01.txt > Pages : 7 > Date : 2012-06-08 >=20 > This document specifies how to use DNSSEC and DANE to securely > delegate an XMPP service identified by a domain to a host associated > with a different domain. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-01.= txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-01.t= xt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-55-102851499 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYwODIwMjgy NFowIwYJKoZIhvcNAQkEMRYEFCpsnZRGDxVT6b1AwX2o94da0K0rMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAxwKOli7Twwx67vtCjwzk4ia1AlnUBVzXhybbjD3NkOJB6Xb61NXp0NApH Oy6mEfBr6eWTqK97xL+urtqIxTo5gdrP03rOy2WgyAA168E+3pWCO3W4sLLyL3Ds6efwnmfjLBa0 HOSXAwt0fM6mr8aputgKnCM6sCqbCl/BM7YZoscIMSg7RzA7GJp7KGIycft34OV98sf87TyKpwj3 WiLBOpynZoBy14e8dU/ROKmQagtM2s5jMkxRTU4TAtSsTjAEkZ9L6Ktqs84lWqUPOftMoFS905Fm 5Nv240JavDyIfjhKsz4JNDPfmvxOB/jQlqU/gxOAcQnoQwMKVppSskBAAAAAAAAA --Apple-Mail-55-102851499-- --Apple-Mail-56-102851506 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP0mBoAAoJEJq6Ou0cgrSPLVQIAJ2A3mXfmJW341tmp1EIP32g T5XjGCoXSZDGzfcOmscBO+RxOwHMZKNHh2aDOl9JpegX79jC2Pjxy22XOyI/qbcm 13d1kVyuPMQ4vYD0rp1G7s9vWrDG+W0ZTKSr8H7yv3zEc+IchE4UMBvu8w9GuAYL Fg5b7/CDyt8m7/TC+/UB14HuCOaExV2yWn4ArYD0NYME+YCtBVmnF7xqs5snh876 UpJWHyDS0JqVPxUrbsVuYq6CmdGGQz9c8L+HHjjqj7WPNQmg0jRRHsHclu+G2GWp RPi9AOoSuVCKzzss5kmgy0XamcwtJaI/w8NSW6i1uYU0KQygm85Bwc3IMFQEzvE= =a1v6 -----END PGP SIGNATURE----- --Apple-Mail-56-102851506-- From warren@kumari.net Fri Jun 8 14:08:45 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9E11E818C for ; Fri, 8 Jun 2012 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.39 X-Spam-Level: X-Spam-Status: No, score=-106.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Orvi68xJk21n for ; Fri, 8 Jun 2012 14:08:41 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 739C511E8142 for ; Fri, 8 Jun 2012 14:08:41 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id F3C261B40256 for ; Fri, 8 Jun 2012 17:08:40 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2012 17:08:38 -0400 Message-Id: <34F2A38F-374F-4231-8657-374715143AE4@kumari.net> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dane] Questions from IESG review #1 - From Barry Leiba X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:08:45 -0000 Hi all, There are a number of questions that came out of the IESG Evaluation on = draft-ietf-dane-protocol-21 that we would like the WG input on=85 I am not going to try summarize the discussions / views -- the = discussions are short and / or subtle enough that you should read them = yourself if you have an opinion / want more details. Unless we hear SCOAT (Strong Clear Objections with Alternate Text) by = Wednesday June 13th we will incorporate the new text. ------------------------------------ Section 8.3: OLD: For this reason, it is RECOMMENDED that DNSSEC validation always be = performed on-host, even when a secure path to an external validator is = available. NEW:=20 For this reason, DNSSEC validation is best performed on-host, even when a secure path to an external validator is available. ------------------------------------ W --=20 With Feudalism, it's your Count that votes. From warren@kumari.net Fri Jun 8 14:08:46 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7711E8142 for ; Fri, 8 Jun 2012 14:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.409 X-Spam-Level: X-Spam-Status: No, score=-106.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn7FM-Tzn0Ci for ; Fri, 8 Jun 2012 14:08:45 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6811E8183 for ; Fri, 8 Jun 2012 14:08:41 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 7D01F1B41783 for ; Fri, 8 Jun 2012 17:08:41 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2012 17:08:40 -0400 Message-Id: To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dane] Questions from IESG review #2 - From Russ Housley X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:08:46 -0000 Hi all, There are a number of questions that came out of the IESG Evaluation on = draft-ietf-dane-protocol-21 that we would like the WG input on=85 I am not going to try summarize the discussions / views -- the = discussions are short and / or subtle enough that you should read them = yourself if you have an opinion / want more details. Unless we hear SCOAT (Strong Clear Objections with Alternate Text) by = Wednesday June 13th we will remove the old text. = --------------------------------------------------------------------------= -- Based on the briefing in the SAAG Session at IETF 83, I strongly suggest that this text be removed from Section 6. At the time this is written, it is expected that there will be a new=20 family of hash algorithms called SHA-3 within the next few years.=20 It is expected that some of the SHA-3 algorithms will be mandatory and/or recommended for TLSA records after the algorithms are fully defined. At that time, this specification will be updated. ------------------------------------------- If folk disagree with removing this text, please read the SAAG minutes = (http://www.ietf.org/proceedings/83/minutes/minutes-83-saag.txt), Tim's = presentation on the SHA-3 Competition = (http://www.ietf.org/proceedings/83/slides/slides-83-saag-0.pdf) and = maybe the audio archives as well. In case it wasn't obvious I too think this should be pulled. Speculating = about the future gets us into tricky territory as does committing future = folk to do stuff. If we mention that SHA-3 is coming and we'll rev the = draft then, do we also need to mention SHA-4? SHA-17? SHA-33.3? OMG, = when will the madness stop?! =85.Sorry, got a little carried away = there=85. W --=20 American Non-Sequitur Society;=20 we don't make sense, but we do like pizza! From warren@kumari.net Fri Jun 8 15:00:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A7911E813C for ; Fri, 8 Jun 2012 15:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwvE6YZiSZz7 for ; Fri, 8 Jun 2012 15:00:48 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 16B9411E80E8 for ; Fri, 8 Jun 2012 15:00:38 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 822721B4153B for ; Fri, 8 Jun 2012 18:00:37 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2012 18:00:35 -0400 Message-Id: <12DC0055-8AF3-478B-92FF-400AB1A83DE3@kumari.net> To: dane@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dane] Rechartering? / new work? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:00:49 -0000 Hi all, So, the -protocol doc is now moving along nicely, and we are seeing a = number of the "How to do DANE with $foo" documents (thank you!). Our charter allows for these docs ("The group may also create documents = that describe how protocol entities can discover and validate these bindings in the execution of specific = applications. ."), but we should discuss rechartering to capture what = we've done, re-evaluate the milestones (we still have "First WG draft of = standards-track protocols for using DNS to associate hosts with IPsec") = and add new ones, decide it we want to stay open, etc.=20 We will discuss this in Vancouver, but it makes sense (IMO) to start = these discussions now so we can maybe have a proposed new charter = (assuming that's what the WG wants) to throw darts at, etc. So: 1: What is wrong with the current charter? What should be removed? What = should be added? 2: Are we planning on doing the IPSec work or should we ask to be = excused from that? 3: Will we do the "DANE with $foo" work in this WG or should it be = individual submissions? 4: Should we remain open? Is there desire and energy? Who should do = what? Obviously whatever we discuss and propose will need to be ok with our = AD, but let's start discussing what we want=85 W -- "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 From stpeter@stpeter.im Fri Jun 8 15:18:07 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A620F11E81AC for ; Fri, 8 Jun 2012 15:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-jO+W-WpTe3 for ; Fri, 8 Jun 2012 15:18:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1B28911E8155 for ; Fri, 8 Jun 2012 15:18:07 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E95C2400A4; Fri, 8 Jun 2012 16:35:03 -0600 (MDT) Message-ID: <4FD27A1C.9080801@stpeter.im> Date: Fri, 08 Jun 2012 16:18:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Warren Kumari References: <12DC0055-8AF3-478B-92FF-400AB1A83DE3@kumari.net> In-Reply-To: <12DC0055-8AF3-478B-92FF-400AB1A83DE3@kumari.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] Rechartering? / new work? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:18:07 -0000 On 6/8/12 4:00 PM, Warren Kumari wrote: > 3: Will we do the "DANE with $foo" work in this WG or should it be individual submissions? Another option is to complete such work in other working groups where applicable (e.g., the "DANE with XMPP" might best be completed in the XMPP WG), with appropriate review from the DANE WG. Peter -- Peter Saint-Andre https://stpeter.im/ From fanf2@hermes.cam.ac.uk Fri Jun 8 15:36:15 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972A311E81B5 for ; Fri, 8 Jun 2012 15:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEFbaBj8EDZA for ; Fri, 8 Jun 2012 15:36:15 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id A622811E8091 for ; Fri, 8 Jun 2012 15:36:12 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from host109-153-162-174.range109-153.btcentralplus.com ([109.153.162.174]:64907 helo=[192.168.1.66]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1Sd7mt-0003gD-QI (Exim 4.72) (return-path ); Fri, 08 Jun 2012 23:36:11 +0100 References: <12DC0055-8AF3-478B-92FF-400AB1A83DE3@kumari.net> <4FD27A1C.9080801@stpeter.im> In-Reply-To: <4FD27A1C.9080801@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Tony Finch Date: Fri, 8 Jun 2012 23:36:09 +0100 To: Peter Saint-Andre Sender: Tony Finch Cc: "dane@ietf.org" Subject: Re: [dane] Rechartering? / new work? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:36:15 -0000 On 8 Jun 2012, at 23:18, Peter Saint-Andre wrote: > On 6/8/12 4:00 PM, Warren Kumari wrote: >=20 >> 3: Will we do the "DANE with $foo" work in this WG or should it be indivi= dual submissions? >=20 > Another option is to complete such work in other working groups where > applicable (e.g., the "DANE with XMPP" might best be completed in the > XMPP WG), with appropriate review from the DANE WG. I think it is best to keep them all here so we can try to make them as simil= ar as possible. Tony. -- f.anthony.n.finch http://dotat.at/= From paul.hoffman@vpnc.org Fri Jun 8 19:26:00 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C68011E80AF for ; Fri, 8 Jun 2012 19:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN8a4xJcerBF for ; Fri, 8 Jun 2012 19:25:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AF90911E80A4 for ; Fri, 8 Jun 2012 19:25:59 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q592Pp1E077647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jun 2012 19:25:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 8 Jun 2012 19:25:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E735D4C-3B6E-4673-98DC-93ABFE7FE252@vpnc.org> References: <12DC0055-8AF3-478B-92FF-400AB1A83DE3@kumari.net> <4FD27A1C.9080801@stpeter.im> To: Tony Finch X-Mailer: Apple Mail (2.1278) Cc: "dane@ietf.org" Subject: Re: [dane] Rechartering? / new work? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 02:26:00 -0000 On Jun 8, 2012, at 3:36 PM, Tony Finch wrote: > On 8 Jun 2012, at 23:18, Peter Saint-Andre wrote: >> On 6/8/12 4:00 PM, Warren Kumari wrote: >>=20 >>> 3: Will we do the "DANE with $foo" work in this WG or should it be = individual submissions? >>=20 >> Another option is to complete such work in other working groups where >> applicable (e.g., the "DANE with XMPP" might best be completed in the >> XMPP WG), with appropriate review from the DANE WG. >=20 > I think it is best to keep them all here so we can try to make them as = similar as possible. Further, there is no WG for SMTP. Dead, revived, dead, revived, dead = again for many years. --Paul Hoffman From stpeter@stpeter.im Fri Jun 8 19:27:57 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1E211E80AF for ; Fri, 8 Jun 2012 19:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl9Ed52cTWaZ for ; Fri, 8 Jun 2012 19:27:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 050A511E80F8 for ; Fri, 8 Jun 2012 19:27:56 -0700 (PDT) Received: from [192.168.0.7] (unknown [216.17.179.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 51DC9400A4; Fri, 8 Jun 2012 20:44:54 -0600 (MDT) Message-ID: <4FD2B4A7.9080901@stpeter.im> Date: Fri, 08 Jun 2012 20:27:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Paul Hoffman References: <12DC0055-8AF3-478B-92FF-400AB1A83DE3@kumari.net> <4FD27A1C.9080801@stpeter.im> <4E735D4C-3B6E-4673-98DC-93ABFE7FE252@vpnc.org> In-Reply-To: <4E735D4C-3B6E-4673-98DC-93ABFE7FE252@vpnc.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "dane@ietf.org" Subject: Re: [dane] Rechartering? / new work? X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 02:27:57 -0000 On 6/8/12 8:25 PM, Paul Hoffman wrote: > > On Jun 8, 2012, at 3:36 PM, Tony Finch wrote: > >> On 8 Jun 2012, at 23:18, Peter Saint-Andre wrote: >>> On 6/8/12 4:00 PM, Warren Kumari wrote: >>> >>>> 3: Will we do the "DANE with $foo" work in this WG or should it be individual submissions? >>> >>> Another option is to complete such work in other working groups where >>> applicable (e.g., the "DANE with XMPP" might best be completed in the >>> XMPP WG), with appropriate review from the DANE WG. >> >> I think it is best to keep them all here so we can try to make them as similar as possible. > > > Further, there is no WG for SMTP. Dead, revived, dead, revived, dead again for many years. I did say "where applicable". :) As long as all the appropriate folks review each spec, I don't particularly care which WG acronym shows up in the draft name... Peter -- Peter Saint-Andre https://stpeter.im/ From i.grok@comcast.net Sat Jun 9 16:19:33 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750C821F8694 for ; Sat, 9 Jun 2012 16:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EcK54FXXVDP for ; Sat, 9 Jun 2012 16:19:33 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id BECAE21F8693 for ; Sat, 9 Jun 2012 16:19:32 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id LPFL1j0010EZKEL51PKXz7; Sat, 09 Jun 2012 23:19:31 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta01.westchester.pa.mail.comcast.net with comcast id LPKX1j0022Ekl483MPKXck; Sat, 09 Jun 2012 23:19:31 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q59NJVm0014134 for ; Sat, 9 Jun 2012 19:19:31 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q59NJUTI014133 for dane@ietf.org; Sat, 9 Jun 2012 19:19:30 -0400 Date: Sat, 9 Jun 2012 19:19:30 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120609231930.GC12683@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: <34F2A38F-374F-4231-8657-374715143AE4@kumari.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="PuGuTyElPB9bOcsM" Content-Disposition: inline In-Reply-To: <34F2A38F-374F-4231-8657-374715143AE4@kumari.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Questions from IESG review #1 - From Barry Leiba X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 23:19:33 -0000 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 08, 2012 at 05:08:38PM -0400, Warren Kumari wrote: > ------------------------------------ >=20 > Section 8.3: > OLD: > For this reason, it is RECOMMENDED that DNSSEC validation always be perf= ormed on-host, even when a secure path to an external validator is availabl= e. >=20 > NEW:=20 > For this reason, DNSSEC validation is best performed on-host, even > when a secure path to an external validator is available. >=20 > ------------------------------------ That works for me. --=20 Scott Schmit --PuGuTyElPB9bOcsM Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNjA5MjMxOTMwWjAjBgkqhkiG9w0BCQQxFgQUsubtxssg dBU30b1Q78ZBMC/PFygweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAhgfMHFTq 8LzG+qOWx1JlUCzzp9oh1UFSOB/SeeJOlbrnCgCHmocXmIg35yg6bNuf83Sos1+nmx7tX3r2 Qe2c30B5kmjbMVpB1lQIaegL82t6mjeFONQ9CunrFdJxyYdlTFTebUp4iTCPumbOqWxcFLaK fyrQj7qBy5nV+BRv5MUK56C0HvzbKjvsHQAzCG8QEUb33F95XZvle4sjK4PV3XZDM2XosH9Q 7SvTldOY1S0M/+ForJ04/b8PBMltveEubXkLhsqZDZ0RHVvb6vsfr9m+PkXepUxB/iCU0vp0 xWfQALUDyHQfODLXYM7KYmTlLaf3hBs5Rne+wFrlm++j2A== --PuGuTyElPB9bOcsM-- From i.grok@comcast.net Sat Jun 9 19:24:43 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D79F21F8664 for ; Sat, 9 Jun 2012 19:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QyPudshup9D for ; Sat, 9 Jun 2012 19:24:43 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E282021F8661 for ; Sat, 9 Jun 2012 19:24:42 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id LSPu1j0020QuhwU51SQip0; Sun, 10 Jun 2012 02:24:42 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta02.westchester.pa.mail.comcast.net with comcast id LSQh1j00A2Ekl483NSQitF; Sun, 10 Jun 2012 02:24:42 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id q5A2Ofle014729 for ; Sat, 9 Jun 2012 22:24:41 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id q5A2OfJ4014728 for dane@ietf.org; Sat, 9 Jun 2012 22:24:41 -0400 Date: Sat, 9 Jun 2012 22:24:40 -0400 From: Scott Schmit To: dane@ietf.org Message-ID: <20120610022440.GA14375@odin.ulthar.us> Mail-Followup-To: dane@ietf.org References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Questions from IESG review #2 - From Russ Housley X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 02:24:43 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 08, 2012 at 05:08:40PM -0400, Warren Kumari wrote: > Unless we hear SCOAT (Strong Clear Objections with Alternate Text) by > Wednesday June 13th we will remove the old text. >=20 > -------------------------------------------------------------------------= --- >=20 > Based on the briefing in the SAAG Session at IETF 83, I strongly > suggest that this text be removed from Section 6. >=20 > At the time this is written, it is expected that there will be a new=20 > family of hash algorithms called SHA-3 within the next few years.=20 > It is expected that some of the SHA-3 algorithms will be mandatory > and/or recommended for TLSA records after the algorithms are fully > defined. At that time, this specification will be updated. >=20 > ------------------------------------------- >=20 > > In case it wasn't obvious I too think this should be pulled. > Speculating about the future gets us into tricky territory as does > committing future folk to do stuff. If we mention that SHA-3 is coming > and we'll rev the draft then, do we also need to mention SHA-4? > SHA-17? SHA-33.3? OMG, when will the madness stop?! =E2=80=A6.Sorry, got= a > little carried away there=E2=80=A6. >=20 > The reason this was originally included was due to a concern that if we had too few or only one mandatory-to-implement hash algorithm, implementers would not be inclined to code in algorithm agility. See the thread around here: https://www.ietf.org/mail-archive/web/dane/current/msg02165.html Not saying that that's true or a good reason to keep the text, mind you, but reminding the WG why this text was put into the draft in the first place. Personally, I'm ok with removing the paragraph--we still specify that SHA-512 is a SHOULD, so any implementer worth their salt will be algorithm-agile. The rest will probably ignore that paragraph anyway. --=20 Scott Schmit --tThc/1wpZn/ma/RB Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQJgYJKoZIhvcNAQcCoIIQFzCCEBMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBxswggYDoAMCAQICAwK+HTANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTExMDcxNzA1 MDQwNFoXDTEyMDcxNzExNDI1OVowYjEgMB4GA1UEDRMXNDY1MjU2LTBnRmI2Sk5ZWW44QnFW bUwxGzAZBgNVBAMMEmkuZ3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9r QGNvbWNhc3QubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2AjLOMsBGaqN hv2FcRbfom/QCeKMXu5tUd1JY5oIDZe5y29stnd+se/zUlEkiVeMam4Jgo1c8yGNnwLVYc5/ 9xVi7Qg1Is5b9AB6aJWElJDw/jIdihymNZ2kwkSLT0wl/lzd0mXlwFJPRgQiRkmE6V0ZmjsQ jaVtllVleGBbMvmWPm92e+4Bju9P81kKz7Xr02ijETmaPdVsl+jmOaKPS8Y+2Lat2xus4Ked oJ/7aIWIpz1gRSKjAHSZ1Wmwi2TYUjYhZryChu9e1RWtqk1CycNoeusJ8xdEVN3WSnJ299w/ 3ltK/x/9rpj2j9ShQZVB4NnX6cjQs7pz1lVxvIkjcQIDAQABo4IDrTCCA6kwCQYDVR0TBAIw ADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBQ29j2I0O8sRYi0So9NwwmT1caakDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhR gjAdBgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwggIhBgNVHSAEggIYMIICFDCCAhAG CysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJp bGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFu ZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAr oCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0 cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQAZ5U0nL/2PQwsVfHgN7MVPbZEGzDzuj4Oy pTgz4XQFwPcCuy6U9sp1Dwmo3DyKX5nKN4xA7pslN+2Pl/kElGamX7zMCAH0xED0RTOLyk+v nDML4s+OUtWaYVnq1bZEp0F8Luq3zIslAYSebleyiz8M0EypZczsL5rOk86R2F9EYw1CBuFJ 5a4x0CmNu5o30fGNDFt+iXRlbJPp/KY25iUgVnBzJ4COT5kQjxn5lgr4t1I+BDCL5HQQ3h/8 2CzwrWVRBNb9Vqh9LL1ZtzYRt8JezoB6HkVvcKVNGlCZ+/MnvfMzPLwfbTDZC8o4d+4RH6aE LeGF2XmAOaenc/YRqm9oMYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQIDAr4dMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTIwNjEwMDIyNDQwWjAjBgkqhkiG9w0BCQQxFgQUh4ALmtCU rZWQnHVe0TiFY/EolwIweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUD BAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAeKzWh8he ugI8/gC8176jS/cnwcP4Ei8Z4xdp58Tze687umM+N49cAbOxYwBbUlC6GcSXiGA1dLGzXTOP GiHmHDm5noSCxYlgbWljdwjCupDiS/XeANBCuA2q1UETKnp+zaW265SImLr5RtepToiDSt9B Gbbnw3mF6tfJuUOB244LoUP6aVsg07qbTdVhxSaGnx3k5l/Hu//YTn3Oq4B/e4TYi8eijWLf 6ihEkHIbQLPgyYOuflrSo+hWbNSHOmjqs6utZBkgoFgc9voy4p7/4JmQw1Ov7Db2SmG2uBHp OxUUR1jIbhjlX2DuP6hrw+nAbZf6AlLrN+liN5vEZojgCQ== --tThc/1wpZn/ma/RB-- From paul.hoffman@vpnc.org Sat Jun 9 19:42:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD8411E8073 for ; Sat, 9 Jun 2012 19:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeeOL80m9DSS for ; Sat, 9 Jun 2012 19:42:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0657D11E8072 for ; Sat, 9 Jun 2012 19:42:58 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5A2gtHj033678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Jun 2012 19:42:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120610022440.GA14375@odin.ulthar.us> Date: Sat, 9 Jun 2012 19:42:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <91550B01-3774-4F3B-ABA4-30187A73EAF5@vpnc.org> References: <20120610022440.GA14375@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Questions from IESG review #2 - From Russ Housley X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 02:42:59 -0000 On Jun 9, 2012, at 7:24 PM, Scott Schmit wrote: > Personally, I'm ok with removing the paragraph--we still specify that > SHA-512 is a SHOULD, so any implementer worth their salt will be > algorithm-agile. The rest will probably ignore that paragraph anyway. Excellent logic. +1 --Paul Hoffman From snabb@epipe.com Mon Jun 11 08:29:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6775421F8643 for ; Mon, 11 Jun 2012 08:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvS18jj2vAQ8 for ; Mon, 11 Jun 2012 08:29:34 -0700 (PDT) Received: from angkar.epipe.com (angkar.epipe.com [IPv6:2001:470:b:566::4]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3421F8638 for ; Mon, 11 Jun 2012 08:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=epipe.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=3mIA4mxO//ZCzygRVA11muA48Cb+H9jmPtYrZjhAK9w=; b=dBC2NCgNHSzKakDXYbqHaQqesLW5PhLM3ya/i4Ocs+czWKNqXJ5dpN+9LoGzZbB2tNurPo+AyJiylGawa/8vvzL2DGv8KrhYU8Slbvb3nFgrVga9FXDtCXHmEkw/hKHs0s1KDIR7e2M1VzcFr4zLqD+r5/1cgsX1uFe5K/nLzbY=; Received: by angkar.epipe.com with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Se6Yf-0001an-60 for dane@ietf.org; Mon, 11 Jun 2012 15:29:33 +0000 Message-ID: <4FD60ED8.6050203@epipe.com> Date: Mon, 11 Jun 2012 22:29:28 +0700 From: Janne Snabb MIME-Version: 1.0 To: dane@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:29:35 -0000 Hi, I looked at the current DANE specifications and drafts with my mail server admin hat on and was surprised to notice that there is nothing about client certificate validation. Is this an intentional omission? Is it something that is postponed for later date? I tried to look through the mailing list archives, but did not find anything relevant. The DANE WG charter does not seem to be limited to server authentication, it just talks about authentication of "Named Entities" which in my mind can be both clients and servers. Obviously many people are only thinking about web site certificates and web browsers. Looks like the current DANE specification could be called DANSE (DNS-based Authentication of Named _Server_ Entities). It could be relatively easily extended to cover client authentication (DANCE: DNS-based Authentication of Named _Client_ Entities). DANSE+DANCE could then be finally called DANE when merged together. :) I was thinking that something similar to the following could work: 1. Mail server foo.example.com wants to send an e-mail to mail server bar.example.net using SMTP. 2. foo.example.com opens a TCP connection to bar.example.net port 25 and issues STARTTLS. foo.example.com might verify the server certificate of bar.example.net with DAN(S)E or it might not. 3. bar.example.net requests a client certificate in the TLS handshake. 4. foo.example.com supplies a client certificate to certify that the SMTP connection really comes from it and not from someone who has hijacked their IP address. 5. bar.example.net is configured to verify SMTP senders using DANCE. It performs the following DNS lookups and validations: A. reverse lookup the client IP address (returns foo.example.com) B. lookup A/AAAA records of foo.example.com and ensure that one of the returned IP addresses matches the IP of the incoming connection C. lookup TLSA records of _25._tcp._client.foo.example.com (the label "_client" could be something different, this is just an example) D. verify that one of the TLSA records matches the client certificate (Lookups C and probably B need to be DNSSEC validated. Lookup A does not need to be DNSSEC validated.) 6. At this point bar.example.net knows if foo.example.com authenticated with the correct certificate and can proceed accordingly depending on the local policies. It might reject the connection/e-mail if the client did not provide the correct certificate. This way a named client entity (typically a server of some sort, not a end-user workstation) could securely announce that when connecting to a well-known port at any other entity it shall authenticate using a specific client certificate (or a certificate signed by specific CA). IMHO it seems pretty pointless to implement DANE for SMTP without the ability to verify both sides of the conversation. Any thoughts? -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From fanf2@hermes.cam.ac.uk Mon Jun 11 08:57:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6260721F8622 for ; Mon, 11 Jun 2012 08:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNIEJgvw+uS7 for ; Mon, 11 Jun 2012 08:57:58 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 009B021F8618 for ; Mon, 11 Jun 2012 08:57:57 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33858) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Se708-0006yI-RP (Exim 4.72) (return-path ); Mon, 11 Jun 2012 16:57:56 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Se708-0007aP-Eh (Exim 4.67) (return-path ); Mon, 11 Jun 2012 16:57:56 +0100 Date: Mon, 11 Jun 2012 16:57:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Janne Snabb In-Reply-To: <4FD60ED8.6050203@epipe.com> Message-ID: References: <4FD60ED8.6050203@epipe.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dane@ietf.org Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:57:59 -0000 Janne Snabb wrote: > > IMHO it seems pretty pointless to implement DANE for SMTP without the > ability to verify both sides of the conversation. The point of server authentication for SMTP is to make sure you are sending mail where you intend to. The point of client authentication is ... what? What the server cares about is the authenticity of the message data, which has relatively little to do with where it came from and even less to do with the client host name. Tony. -- f.anthony.n.finch http://dotat.at/ Thames, Dover, Wight: Cyclonic 4 or 5, becoming north or northeast 5 or 6. Slight or moderate. Occasional rain. Moderate or good, occasionally poor. From paul.hoffman@vpnc.org Mon Jun 11 09:06:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC521F865D for ; Mon, 11 Jun 2012 09:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CRmkpEz81fe for ; Mon, 11 Jun 2012 09:06:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BF48C21F8648 for ; Mon, 11 Jun 2012 09:06:10 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5BG62ww057172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2012 09:06:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 11 Jun 2012 09:06:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9A9962-B8DF-4DE1-B137-902EA1BF2BB6@vpnc.org> References: <4FD60ED8.6050203@epipe.com> To: Tony Finch X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:06:11 -0000 On Jun 11, 2012, at 8:57 AM, Tony Finch wrote: > Janne Snabb wrote: >>=20 >> IMHO it seems pretty pointless to implement DANE for SMTP without the >> ability to verify both sides of the conversation. >=20 > The point of server authentication for SMTP is to make sure you are > sending mail where you intend to. >=20 > The point of client authentication is ... what? ...to make the server sure it is speaking to the client it thinks it is. > What the server cares about is the authenticity of the message data, = which > has relatively little to do with where it came from and even less to = do > with the client host name. That's one view; another is that the two parties both want to be sure of = the others' identity. Jakob and I are dealing with client auth in our S/MIME proposal; it = could be applied to client certificates as well.= From henry.story@bblfish.net Mon Jun 11 09:14:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62421F85DA for ; Mon, 11 Jun 2012 09:14:40 -0700 (PDT) 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_55=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qWutlzS8HzJ for ; Mon, 11 Jun 2012 09:14:39 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B627B21F859A for ; Mon, 11 Jun 2012 09:14:38 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so2538477wib.13 for ; Mon, 11 Jun 2012 09:14:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=HpTheXDX3jmNJ+3L0lgFPSNY6S/M6+9yIsGKXDRKdbk=; b=gI3wNKYM89ZbOrKq3kSMbyPh2VYIWvGruYUZYHB4roS91nZ29Bs31aL+chuoIRWXC3 DiJx3xGy1Bhrk2fCcNRqzyHmLjPgtHG0jSH7m1PAZcVIMhi1g4FboG8Og8wHd26LdwUe Q1jRByf2XJf6p/2q+SdiJH433cY/UR3+HMI/fcymAenn4Cq7smSQvYITT7/3cq95oZhp wrV3A1ts20WP2Uy9pHWutCSmVAo2NnP5ygkt9SuCjJyEG5zYrS3C4oBzNrsidypsffju kjZoXh0AQsYQ4dJ3/H0Bo4sOKjmPdoRF0bwdt3XfX1LMcX5ALrz3+jVmRDjKBlAPSLr5 4puw== Received: by 10.180.74.193 with SMTP id w1mr22112722wiv.4.1339431277587; Mon, 11 Jun 2012 09:14:37 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-325-4.w83-200.abo.wanadoo.fr. [83.200.92.4]) by mx.google.com with ESMTPS id i10sm39774540wiy.10.2012.06.11.09.14.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 09:14:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4FD60ED8.6050203@epipe.com> Date: Mon, 11 Jun 2012 18:14:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD60ED8.6050203@epipe.com> To: Janne Snabb X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkGC2J9zvJTjXHw83Wa2qCBcMl6SPSl997sj6/wNWdBnFxUMvzKGAqZiOuIToYg63+19XU/ Cc: dane@ietf.org Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:14:40 -0000 On 11 Jun 2012, at 17:29, Janne Snabb wrote: > Hi, >=20 > I looked at the current DANE specifications and drafts with my mail > server admin hat on and was surprised to notice that there is nothing > about client certificate validation. >=20 > Is this an intentional omission? Is it something that is postponed for > later date? Once you have Dane for server authentication it makes client = authentication with WebID even easier to deploy. See the spec on the w3c at http://webid.info/spec/ You can also see the short video explaining how that works at = http://webid.info/ And you can join the community at=20 http://www.w3.org/community/webid/ It is also possible to extend this for trust of issuers as I argued = recently in WebID and eCommerce: http://bblfish.net/blog/2012/04/30/ Henry >=20 > I tried to look through the mailing list archives, but did not find > anything relevant. The DANE WG charter does not seem to be limited to > server authentication, it just talks about authentication of "Named > Entities" which in my mind can be both clients and servers. Obviously > many people are only thinking about web site certificates and web = browsers. >=20 > Looks like the current DANE specification could be called DANSE > (DNS-based Authentication of Named _Server_ Entities). It could be > relatively easily extended to cover client authentication (DANCE: > DNS-based Authentication of Named _Client_ Entities). DANSE+DANCE = could > then be finally called DANE when merged together. :) >=20 >=20 > I was thinking that something similar to the following could work: >=20 > 1. Mail server foo.example.com wants to send an e-mail to mail server > bar.example.net using SMTP. >=20 > 2. foo.example.com opens a TCP connection to bar.example.net port 25 = and > issues STARTTLS. foo.example.com might verify the server certificate = of > bar.example.net with DAN(S)E or it might not. >=20 > 3. bar.example.net requests a client certificate in the TLS handshake. >=20 > 4. foo.example.com supplies a client certificate to certify that the > SMTP connection really comes from it and not from someone who has > hijacked their IP address. >=20 > 5. bar.example.net is configured to verify SMTP senders using DANCE. = It > performs the following DNS lookups and validations: > A. reverse lookup the client IP address (returns foo.example.com) > B. lookup A/AAAA records of foo.example.com and ensure that one of the > returned IP addresses matches the IP of the incoming connection > C. lookup TLSA records of _25._tcp._client.foo.example.com (the label > "_client" could be something different, this is just an example) > D. verify that one of the TLSA records matches the client certificate >=20 > (Lookups C and probably B need to be DNSSEC validated. Lookup A does = not > need to be DNSSEC validated.) >=20 > 6. At this point bar.example.net knows if foo.example.com = authenticated > with the correct certificate and can proceed accordingly depending on > the local policies. It might reject the connection/e-mail if the = client > did not provide the correct certificate. >=20 >=20 > This way a named client entity (typically a server of some sort, not a > end-user workstation) could securely announce that when connecting to = a > well-known port at any other entity it shall authenticate using a > specific client certificate (or a certificate signed by specific CA). >=20 > IMHO it seems pretty pointless to implement DANE for SMTP without the > ability to verify both sides of the conversation. >=20 > Any thoughts? >=20 > --=20 > Janne Snabb / EPIPE Communications > snabb@epipe.com - http://epipe.com/ > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane Social Web Architect http://bblfish.net/ From cloos@jhcloos.com Mon Jun 11 09:41:41 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E97C21F85F6 for ; Mon, 11 Jun 2012 09:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix80nP+VgBQ3 for ; Mon, 11 Jun 2012 09:41:39 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [207.210.242.212]) by ietfa.amsl.com (Postfix) with ESMTP id E017A21F848A for ; Mon, 11 Jun 2012 09:41:39 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 80E0440191; Mon, 11 Jun 2012 16:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1339432897; bh=oPV9tTT688C1IqCSO6naNmHRTQW2nV8+SWPYWcRbGYA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=jM1DGvpmxUnIlWiYLCQEGnW4S6v8G0zP09PmfRpcXmwTRhcdbPIdsZpA0afugNUbl wnp5kYtHtOErZVLGlIutGMuXopsMvp1rAYGdvuqqrHUWDyz8wqYregyaBZYweqJ9w7 mjMcdEFS0DXKQQJVyjGSvhBYQG1itAozcDfquaME= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7BD0D36004C; Mon, 11 Jun 2012 16:38:28 +0000 (UTC) From: James Cloos To: Tony Finch In-Reply-To: (Tony Finch's message of "Mon, 11 Jun 2012 16:57:56 +0100") References: <4FD60ED8.6050203@epipe.com> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 11 Jun 2012 12:38:28 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:120611:dot@dotat.at::ffUCX4ynD0IFXGEp:0000E5Hyy X-Hashcash: 1:30:120611:snabb@epipe.com::I3BtouuvGiCd/TEA:0WaY/a X-Hashcash: 1:30:120611:dane@ietf.org::B334jvgJhOCVNccy:0008Xzbw Cc: dane@ietf.org Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:41:41 -0000 >>>>> "TF" == Tony Finch writes: TF> The point of server authentication for SMTP is to make sure you are TF> sending mail where you intend to. TF> The point of client authentication is ... what? So that the person reading the message can confirm the path it took. It is more a forensic tool than a real-time one, AFAICS. I have seen benefit from it, albeit rarely, given the small number of MTAs which offer or request client certs on MTA-MTA sockets. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From snabb@epipe.com Mon Jun 11 12:27:13 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F611E808A for ; Mon, 11 Jun 2012 12:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB27SEbb3FqL for ; Mon, 11 Jun 2012 12:27:12 -0700 (PDT) Received: from angkar.epipe.com (angkar.epipe.com [IPv6:2001:470:b:566::4]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4111E8087 for ; Mon, 11 Jun 2012 12:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=epipe.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/6JfUURB5S/kk8bhFakOkouKTD7gbJMczkXfu19hVwU=; b=QC3t0vBB9XpW4C1N53IMpW8gpUQ841RSUEZ+F7iQvpk8F9ZZgkBwJBgJhZQQHwbQlM2HyzLDU5HDXlEH/xHWVQlvo4UgBTE3TzoiuJjezT2++4Wc2qV0JJEgPtN+Pr4iz0A17r7ksqH9GOILx3F2T7b+K4doONYTMDSzHkLvpog=; Received: by angkar.epipe.com with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1SeAGb-0001mX-Nv; Mon, 11 Jun 2012 19:27:10 +0000 Message-ID: <4FD64688.2000903@epipe.com> Date: Tue, 12 Jun 2012 02:27:04 +0700 From: Janne Snabb MIME-Version: 1.0 To: Tony Finch References: <4FD60ED8.6050203@epipe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dane@ietf.org Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 19:27:13 -0000 On 2012-06-11 22:57, Tony Finch wrote: > The point of client authentication is ... what? It would make automatic or manual recognition of fraudulent e-mails much more simple and effective. These days I receive perhaps 100 e-mails a year from someone who claims to be from my bank and asks me to perform some important action. Currently I can not perform that action unless I do a careful risk assessment based on "received" headers and whatever, but I still can not be absolutely sure because it is all guesswork as no verified certificates are involved. Therefore I have to assume that all of those e-mails are fraudulent and as a result I miss the one important e-mail a year which was really from my bank. I should have done something to renew my credit card for example. With the feature that I am suggesting my mail system could tell me that "we have positively authenticated that this e-mail was sent to us by a server which is named mailserver.$my_bank.com". I could be quite confident that the e-mail actually arrived from my bank. Equally confident as when https connection to www.$my_bank.com presents a server certificate identified by _443._tcp.www.$my_bank.com TLSA record. My receiving MTA could make the authentication results available to my MUA either using the "Authentication-Results" header or by some other underlying mechanism. Obviously this overlaps with some other technologies. My bank could sign their e-mails using PGP or S/MIME, but in reality almost nobody except geeks does that because of various difficulties (the DANE + S/MIME work might finally make S/MIME signatures automatically verifiable). The bank's mail server administrators might be geeky enough to implement DAN(C)E on their servers. They would only need to set it up once and as a result all their outgoing e-mail could be positively identified coming from whoever controls their domain. DANE + S/MIME and DANE/DANCE + SMTP would be complementing each other, working on different levels of the e-mail infrastructure. Google apparently sees some benefit in presenting a verifiable client certificate in their outgoing SMTP sessions. -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From ondrej.sury@nic.cz Mon Jun 11 23:36:22 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8987E11E8087 for ; Mon, 11 Jun 2012 23:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B-9Wl33Muhe for ; Mon, 11 Jun 2012 23:36:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 93DDE11E8080 for ; Mon, 11 Jun 2012 23:36:21 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:9198:cb13:62a3:d9f6] (unknown [IPv6:2001:1488:ac14:1400:9198:cb13:62a3:d9f6]) by mail.nic.cz (Postfix) with ESMTPSA id 448FD141258; Tue, 12 Jun 2012 08:36:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339482975; bh=YAwolbruua1HxhlvC6nJVynY2kRqiJc7A+vUdLShBrg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OhJ8ilia/ecnK/aIZdjQ39PXEsT/YOkj/EC242Mp/o111IhVGAore2FYgtOuojV1D IiCE9tp/KdGkCtAYziT9kgpeIZGy5J3iazZVNn7a/7zTJQ2zUM+8jEaTkh7x+2k06A OGP8PfoF7EQWePKbxRY6878n5hX6Xg9LEuWRbByM= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4FD64688.2000903@epipe.com> Date: Tue, 12 Jun 2012 08:36:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F3F1FD0-91E3-4EA3-B1D2-B8565B5157A6@nic.cz> References: <4FD60ED8.6050203@epipe.com> <4FD64688.2000903@epipe.com> To: Janne Snabb , Stephen Farrell X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane WG list Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 06:36:22 -0000 On 11. 6. 2012, at 21:27, Janne Snabb wrote: > With the feature that I am suggesting my mail system could tell me = that > "we have positively authenticated that this e-mail was sent to us by a > server which is named mailserver.$my_bank.com". I could be quite > confident that the e-mail actually arrived from my bank. Equally > confident as when https connection to www.$my_bank.com presents a = server > certificate identified by _443._tcp.www.$my_bank.com TLSA record. My > receiving MTA could make the authentication results available to my = MUA > either using the "Authentication-Results" header or by some other > underlying mechanism. We already have different technologies for that - DKIM, S/MIME... I am not sure that reinventing the wheel for a -th time, because we failed before, would actually help anything > Obviously this overlaps with some other technologies. My bank could = sign > their e-mails using PGP or S/MIME, but in reality almost nobody except > geeks does that because of various difficulties (the DANE + S/MIME = work > might finally make S/MIME signatures automatically verifiable). The difficulty mainly lies in the presentation that information to the end user. Your proposal doesn't really help with that. It would be yet > DANE + S/MIME and DANE/DANCE + SMTP would be complementing each other, > working on different levels of the e-mail infrastructure. And end-user would be totally confused. You seem to forgot the fact that SMTP is a bunch of loosely connected servers which might or might not relay your email. Try to answer following questions: How is your proposal better than DKIM? How is your proposal better than S/MIME? (and/or PGP) How would you present the information that the email came through two or more SMTP relays before it has reached you? I am not even sure this belongs here. It changes the semantics of SMTP protocol and since we don't have a SMTP WG (now) I think it's more suitable to individual submission in App area. It seems to me that this doesn't change any semantics of DANE protocol (short summary: "hey, receiving MTA - check TLSA record of the sending MTA"). But of course the WG will is my will, so if you want to take this work into the WG, we can try to recharter and convince our AD that this really belongs here. But it would take a lot of strong arguments to convince me and not to mention our beloved AD :). O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From snabb@epipe.com Tue Jun 12 08:43:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB2721F86B9 for ; Tue, 12 Jun 2012 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo+xwCBK+Ryi for ; Tue, 12 Jun 2012 08:43:55 -0700 (PDT) Received: from angkar.epipe.com (angkar.epipe.com [IPv6:2001:470:b:566::4]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8321F86AB for ; Tue, 12 Jun 2012 08:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=epipe.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=WDhEuLckmedZBWyZKXTnmmutR8IAg/isAJLR2rEMNII=; b=l03qfsqQH3+h8Hex6HgI5tTjE4wjJuPLrjJu5QV3NRoLGd79vfx46+bvKJmgyafSRsLbvXbRFTys2+EIr39Ubd+qfynBdx1ySZr36xG12JOE5j6WFwBxF0ojzEFx5wsszAcTehQf81Q6rxzWgvYPQx0uuqp7lWMvAwOBwphpCus=; Received: by angkar.epipe.com with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1SeTG3-0002vq-Bw; Tue, 12 Jun 2012 15:43:51 +0000 Message-ID: <4FD763B3.7080301@epipe.com> Date: Tue, 12 Jun 2012 22:43:47 +0700 From: Janne Snabb MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4FD60ED8.6050203@epipe.com> <4FD64688.2000903@epipe.com> <8F3F1FD0-91E3-4EA3-B1D2-B8565B5157A6@nic.cz> In-Reply-To: <8F3F1FD0-91E3-4EA3-B1D2-B8565B5157A6@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dane WG list Subject: Re: [dane] DANE and client certificates (DANCE?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:43:56 -0000 On 2012-06-12 13:36, Ondřej Surý wrote: > We already have different technologies for that - DKIM, S/MIME... Ok. I thought I was pointing out an obvious lack of feature in DANE which limits its use cases and was inquiring if there is a reason for that. Looks like everyone is missing my point because I used SMTP in my example. I thought SMTP would be a good example because it is well known and could easily benefit from DANE + DANCE. Looks like it was a bad example because everyone is afraid of improving SMTP after the previous attempts to improve internet mail have failed miserably. Please forget SMTP for the rest of this mail. I would like to try once more to get my point across before giving up. What I am proposing is a generic mechanism which can be easily utilized by any protocol running on top of TLS/DTLS and which uses a well-known/pre-defined port number at the server side and a known DNS name on the client side. It would be an extension of the current DANE work to cover not only verification of server certificates but also client certificates within the scope of DANE (the endpoints must be "named entities" in the DNS for this to be useful -- which already applies to the current DANE work as a fundamental requirement). Many use cases of TLS/DTLS require authentication of both parties, not just the server (which DANE currently implements). Read the following again (from my original mail): > This way a named client entity (typically a server of some sort, not > a end-user workstation) could securely announce that when connecting > to a well-known port at any other entity it shall authenticate using > a specific client certificate (or a certificate signed by specific CA). The goal of IPSEC was to implement transparent end-to-end security in the internet. It failed due to various reasons (key management/trust, NAT traversal, complexity, disagreements, etc). Now we have TLS and DTLS. They are ok because it is relatively easy to run almost any existing protocol on top of them. TLS provides confidentiality as well as authentication of both ends of a communication circuit. The #1 problem with TLS is key management and trust. DANE addresses that problem nicely (or currently half - the server side - of that problem). By using the pre-existing DNS trust infrastructure we can now attach any certificates to any entities which have names in DNS. This liberates the consumers from the complexities of PKI, CRLs, CAs, CSRs, cut'n'pasting PEM encoded blobs around, trusting or not trusting some untrustworthy CAs, etc. We can now make all of this very simple by just generating a self-signed certificate and put the corresponding TLSA record in the DNS. After that everyone else can just use DNS to verify that certificate and be secure. Now, again, TLS provides facilities for authenticating both ends of a communication circuit. DANE implements only the other half of that. In TLS one of the two communicating parties is a client and the other one is a server, even though both endpoints may really be servers with known names in DNS. A client certificate is not different from a server certificate. TLS is able to authenticate both endpoints. DANE can only authenticate the receiving/server end of the connection. Why such an omission? The features of DANE should match the features of TLS. I believe and hope that the intention of DANE is to be protocol-agnostic and not artificially limit its usability to verifying only web site certificates. The current DANE work already has all the pieces for client authentication using the same TLSA DNS record. We need only a couple of paragraphs which explain how to attach a client certificate to client's DNS name. Here is a new example: I process credit card payments. My customers have POS (point-of-sale) systems which accept credit cards and connect to my server to process the payments. The protocol is proprietary, but it runs on top of TLS (it could be even XML-RPC or SOAP over HTTPS or whatever else you like). The POS terminals connect to TCP port 555 on my server and use an ephemeral port on their side. Obviously I need to authenticate the incoming connections from the POS terminals. The POS terminals also need to authenticate my server, which is already possible with DANE, and therefore I am ignoring that part because it does not require attention any more. With the current pre-DANE technology I need to tell my customers to cut'n'paste PEM encoded blobs back and forth in their POS systems. Also my customers, myself or some third party must run a CA. Or otherwise both parties have to manually enter and remove POS specific keys/certificates at both ends every time a new POS is installed or old one is removed/stolen. If we have DANCE, I can tell my customers to create their certificates any way they wish and to just specify the POS terminals' names and TLSA records in their DNS. I can specify at my payment processing server that anything that authenticates with a name matching *.pos.$customername.com is to be trusted. My customers can manage that namespace themselves. They only need to register the name of the POS terminal in their DNS and attach a DANCE TLSA record to it. There is one big benefit from using DANE/DANCE: If the customer later wants to start using a different payment processor, they only need to change the payment server's address in their POS terminals and inform the new provider that their terminals authenticate using a DNS name in a specific sub-domain. There is no need to re-create keys, re-issue certificates, change trusted CAs or anything like that. All the key management complexity is completely gone. For example: 55.2.0.192.in-addr.arpa. PTR sunnytown6.pos.example.com. sunnytown6.pos.example.com. A 192.0.2.55 _555._tcp._client.sunnytown6.pos.example.com. TLSA XXXXXXXXXX Note the port number in the client's TLSA record. This record announces that when this named entity makes an _outgoing_ connection _to_ TCP port 555 of any other entity it shall authenticate using the specified TLS certificate. We need the "_client" label or something similar to distinguish between client and server TLSA records (no need to invent a new DNS record for this). This makes DNS names useful for strong client authentication. I can just put "*.pos.example.com" in my ACL and my payment server can instantly perform strong authentication of any entity residing in that namespace. Now DNS name based ACLs are useful for strong authentication of clients. I am not vulnerable to IP or DNS spoofing because I have TLS+DNSSEC+DAN(C)E. If you read this far, thank you for your time. If you are planning to reply along the lines "this would not work because POS systems..." you have missed my point and are wasting your time. I do not know anything about current POS systems except that they need a secure channel and authentication of both endpoints, which can be implemented as in this example by using TLS. The last time I touched a POS system was more than 15 years ago and at that time the "secure channel" part was addressed by using a X.25 circuit and the "authentication" part was solved by using static addresses and access-lists. I think POS is a better example than SMTP because people should not be able to argue about the need of client authentication in this TLS use case. My goal is to convince this WG that TLS client authentication is needed in many TLS use cases and can/should be included in DANE (or alternatively there should be a conscious decision to leave it out if for example there is some flaw in my thinking that I do not see myself). -- Janne Snabb / EPIPE Communications snabb@epipe.com - http://epipe.com/ From warren@kumari.net Thu Jun 14 09:23:35 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693921F8658 for ; Thu, 14 Jun 2012 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7FPaj82gTKN for ; Thu, 14 Jun 2012 09:23:35 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id EB05E21F861F for ; Thu, 14 Jun 2012 09:23:31 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id E81841B402B8 for ; Thu, 14 Jun 2012 12:23:30 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Warren Kumari In-Reply-To: Date: Thu, 14 Jun 2012 12:23:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9722D02A-2F13-4389-8357-C2E5DC1A43AC@kumari.net> References: To: dane@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [dane] Questions from IESG review #2 - From Russ Housley X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 16:23:35 -0000 On Jun 8, 2012, at 5:08 PM, Warren Kumari wrote: > Hi all, >=20 > There are a number of questions that came out of the IESG Evaluation = on draft-ietf-dane-protocol-21 that we would like the WG input on=85 >=20 > I am not going to try summarize the discussions / views -- the = discussions are short and / or subtle enough that you should read them = yourself if you have an opinion / want more details. >=20 > Unless we hear SCOAT (Strong Clear Objections with Alternate Text) by = Wednesday June 13th we will remove the old text. Awesome, we heard no SCOAT, but we did hear a Scott, who provided useful = background, and is cool with removing the text.\\ So, authors, please remove the old text. W >=20 > = --------------------------------------------------------------------------= -- >=20 > Based on the briefing in the SAAG Session at IETF 83, I strongly > suggest that this text be removed from Section 6. >=20 > At the time this is written, it is expected that there will be a new=20= > family of hash algorithms called SHA-3 within the next few years.=20 > It is expected that some of the SHA-3 algorithms will be mandatory > and/or recommended for TLSA records after the algorithms are fully > defined. At that time, this specification will be updated. >=20 > ------------------------------------------- >=20 > If folk disagree with removing this text, please read the SAAG minutes = (http://www.ietf.org/proceedings/83/minutes/minutes-83-saag.txt), Tim's = presentation on the SHA-3 Competition = (http://www.ietf.org/proceedings/83/slides/slides-83-saag-0.pdf) and = maybe the audio archives as well. >=20 > > In case it wasn't obvious I too think this should be pulled. = Speculating about the future gets us into tricky territory as does = committing future folk to do stuff. If we mention that SHA-3 is coming = and we'll rev the draft then, do we also need to mention SHA-4? SHA-17? = SHA-33.3? OMG, when will the madness stop?! =85.Sorry, got a little = carried away there=85. >=20 > >=20 > W > --=20 > American Non-Sequitur Society;=20 > we don't make sense, but we do like pizza! >=20 >=20 For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken From warren@kumari.net Thu Jun 14 09:24:26 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3C21F8671 for ; Thu, 14 Jun 2012 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAXVpG1NMhR0 for ; Thu, 14 Jun 2012 09:24:26 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1998621F8658 for ; Thu, 14 Jun 2012 09:24:26 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 9682B1B402B8; Thu, 14 Jun 2012 12:24:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20120609231930.GC12683@odin.ulthar.us> Date: Thu, 14 Jun 2012 12:24:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D457A83-46F4-4E8B-9EE8-4C36F6A85B65@kumari.net> References: <34F2A38F-374F-4231-8657-374715143AE4@kumari.net> <20120609231930.GC12683@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1278) Cc: dane@ietf.org Subject: Re: [dane] Questions from IESG review #1 - From Barry Leiba X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 16:24:26 -0000 On Jun 9, 2012, at 7:19 PM, Scott Schmit wrote: > On Fri, Jun 08, 2012 at 05:08:38PM -0400, Warren Kumari wrote: >> ------------------------------------ >>=20 >> Section 8.3: >> OLD: >> For this reason, it is RECOMMENDED that DNSSEC validation always be = performed on-host, even when a secure path to an external validator is = available. >>=20 >> NEW:=20 >> For this reason, DNSSEC validation is best performed on-host, even >> when a secure path to an external validator is available. >>=20 >> ------------------------------------ >=20 > That works for me. >=20 Excellent. Authors, please make it so=85 W > --=20 > Scott Schmit > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- "I think perhaps the most important problem is that we are trying to = understand the fundamental workings of the universe via a language = devised for telling one another when the best fruit is." --Terry = Prachett=20 From internet-drafts@ietf.org Thu Jun 14 13:13:31 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3CF21F877F; Thu, 14 Jun 2012 13:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJLTxtGrelmh; Thu, 14 Jun 2012 13:13:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA49821F8741; Thu, 14 Jun 2012 13:13:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120614201330.20196.68600.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 13:13:30 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-22.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:13:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : The DNS-Based Authentication of Named Entities (DANE) Tr= ansport Layer Security (TLS) Protocol: TLSA Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-22.txt Pages : 37 Date : 2012-06-14 Abstract: Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-protocol-22 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-protocol-22 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From msheldon@godaddy.com Thu Jun 14 13:46:27 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6821F8567 for ; Thu, 14 Jun 2012 13:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lRv2HYXNZYq for ; Thu, 14 Jun 2012 13:46:27 -0700 (PDT) Received: from smtpoutwbe10.prod.mesa1.secureserver.net (smtpoutwbe10.prod.mesa1.secureserver.net [208.109.78.26]) by ietfa.amsl.com (Postfix) with SMTP id 010A021F8550 for ; Thu, 14 Jun 2012 13:46:23 -0700 (PDT) Received: (qmail 28739 invoked from network); 14 Jun 2012 20:46:23 -0000 Received: from unknown (HELO gem-wbe33.prod.mesa1.secureserver.net) (64.202.189.215) by smtpoutwbe10.prod.mesa1.secureserver.net with SMTP; 14 Jun 2012 20:46:19 -0000 Received: (qmail 1128 invoked by uid 99); 14 Jun 2012 20:46:19 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 172.19.38.144 User-Agent: Workspace Webmail 5.6.19 Message-Id: <20120614134618.205a61dff9fc1684c258b274662bb912.7eb1405561.wbe@email00.secureserver.net> From: "Michael Sheldon" To: internet-drafts@ietf.org, i-d-announce@ietf.org Date: Thu, 14 Jun 2012 13:46:18 -0700 Mime-Version: 1.0 Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-22.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:46:27 -0000 In section 2.2, the certificate usage field was changed from "8-bit=0Aunsig= ned decimal integer" to "8-bit decimal integer"=0A=0AI'm thinking that shou= ld have been "8-bit unsigned integer" like the=0Aother fields?=0A=0AMichael= Sheldon=0ADev-DNS Services=0AGoDaddy.com=0A=0A> -------- Original Message = --------=0A> Subject: [dane] I-D Action: draft-ietf-dane-protocol-22.txt=0A= > From: internet-drafts@ietf.org=0A> Date: Thu, June 14, 2012 1:13 pm=0A> T= o: i-d-announce@ietf.org=0A> Cc: dane@ietf.org=0A> =0A> =0A> A New Internet= -Draft is available from the on-line Internet-Drafts directories.=0A> This= draft is a work item of the DNS-based Authentication of Named Entities Wor= king Group of the IETF.=0A> =0A> =09Title : The DNS-Based Authent= ication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: T= LSA=0A> =09Author(s) : Paul Hoffman=0A> Jak= ob Schlyter=0A> =09Filename : draft-ietf-dane-protocol-22.txt=0A> = =09Pages : 37=0A> =09Date : 2012-06-14=0A> =0A> Abstra= ct:=0A> Encrypted communication on the Internet often uses Transport Lev= el=0A> Security (TLS), which depends on third parties to certify the key= s=0A> used. This document improves on that situation by enabling the=0A= > administrators of domain names to specify the keys used in that=0A> = domain's TLS servers. This requires matching improvements in TLS=0A> c= lient software, but no change in TLS server software.=0A> =0A> =0A> The IET= F datatracker status page for this draft is:=0A> https://datatracker.ietf.o= rg/doc/draft-ietf-dane-protocol=0A> =0A> There's also a htmlized version av= ailable at:=0A> http://tools.ietf.org/html/draft-ietf-dane-protocol-22=0A> = =0A> A diff from previous version is available at:=0A> http://tools.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-dane-protocol-22=0A> =0A> =0A> Internet-Drafts = are also available by anonymous FTP at:=0A> ftp://ftp.ietf.org/internet-dra= fts/=0A> =0A> _______________________________________________=0A> dane mail= ing list=0A> dane@ietf.org=0A> https://www.ietf.org/mailman/listinfo/dane= =0A From internet-drafts@ietf.org Thu Jun 14 14:36:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAF221F8567; Thu, 14 Jun 2012 14:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6olGtEe4-GjZ; Thu, 14 Jun 2012 14:36:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D050621F848B; Thu, 14 Jun 2012 14:36:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120614213657.1894.5923.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 14:36:57 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-protocol-23.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:36:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : The DNS-Based Authentication of Named Entities (DANE) Tr= ansport Layer Security (TLS) Protocol: TLSA Author(s) : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-protocol-23.txt Pages : 37 Date : 2012-06-14 Abstract: Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-protocol-23 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-protocol-23 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Thu Jun 14 14:58:02 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B89D21F84A7 for ; Thu, 14 Jun 2012 14:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUyKh10sJOy0 for ; Thu, 14 Jun 2012 14:58:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE9EA21F84A2 for ; Thu, 14 Jun 2012 14:58:01 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5ELvwMt003588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2012 14:58:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120614134618.205a61dff9fc1684c258b274662bb912.7eb1405561.wbe@email00.secureserver.net> Date: Thu, 14 Jun 2012 14:57:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7908C7A6-56F3-4164-B9B3-A1B488036E86@vpnc.org> References: <20120614134618.205a61dff9fc1684c258b274662bb912.7eb1405561.wbe@email00.secureserver.net> To: Michael Sheldon X-Mailer: Apple Mail (2.1278) Cc: IETF DANE WG list Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-22.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:58:02 -0000 Er, yes. Fixed in -23. From stephen.farrell@cs.tcd.ie Fri Jun 15 04:15:47 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6921F8615 for ; Fri, 15 Jun 2012 04:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9H2BfF2+coZ for ; Fri, 15 Jun 2012 04:15:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B035C21F8613 for ; Fri, 15 Jun 2012 04:15:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 20057171829 for ; Fri, 15 Jun 2012 12:15:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1339758945; bh=5JrQRnK4FSTeUXy7Ytj7rIva 9Zny4zf38LBEJ4r62ws=; b=AcNpNbY1MsYI2ZFmKxDhfEKrXbb2+veduf2SmEwd +3gKU07DZvttnCgfEenn7wwgKKEsXaxjMX2aZOEUkjoRtugriTLyO35sK0ah2jn+ QpE8bBCOcGenbt3YQO+A+yKb1/lMSSlXTJd3FUbgMnxfFxZCBZjNJTaeg8magqQ4 kHg5wXKA6e0I1CoiEncEv2g3pv4c5ItJ/nBlFqtOwz16ummwt+GgJ7zJ28OupBpN PWS9qbcPYDbMEzei8FpzZsW505TtD9+sxr6pPZNKagS9lX6QZCuDFYUDXEsqwH/T eSKaoQ8tP4gGykAcugY3lZb73+wEEARRq9GPGUPKYWkqHA== 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 gx3qS7jxqatl for ; Fri, 15 Jun 2012 12:15:45 +0100 (IST) Received: from [IPv6:2001:770:10:203:440c:e22f:3c2b:83cc] (unknown [IPv6:2001:770:10:203:440c:e22f:3c2b:83cc]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BE09C171471 for ; Fri, 15 Jun 2012 12:15:45 +0100 (IST) Message-ID: <4FDB1962.1060403@cs.tcd.ie> Date: Fri, 15 Jun 2012 12:15:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: dane X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] draft-ietf-dane-protocol approved X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 11:15:47 -0000 Hi all, All discusses are cleared so I've just sent the approval message to the secretariat and this'll now head to the RFC editor for final processing. Well done to the chairs, editors and wg! Thanks, Stephen. From iesg-secretary@ietf.org Fri Jun 15 05:12:40 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83D821F85C7; Fri, 15 Jun 2012 05:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHtQ99EbiMqi; Fri, 15 Jun 2012 05:12:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CE921F860E; Fri, 15 Jun 2012 05:12:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> Date: Fri, 15 Jun 2012 05:12:39 -0700 Cc: dane mailing list , dane chair , RFC Editor Subject: [dane] Protocol Action: 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' to Proposed Standard (draft-ietf-dane-protocol-23.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 12:12:41 -0000 The IESG has approved the following document: - 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' (draft-ietf-dane-protocol-23.txt) as Proposed Standard This document is the product of the DNS-based Authentication of Named Entities Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ Technical Summary Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrator of a domain name to publish the keys used in the DNS, secured with DNSSEC. Working Group Summary The working group made extensive use of the issue tracker: listing, opening, discussing and then calling consensus on each issue. This gave everyone the opportunity to participate and be heard. There have been approximately 2,000 messages discussing this (and closely related) documents. Document Quality There is a tool (Swede - https://github.com/pieterlexis/swede) that generates TLSA records, and a proof-of-concept implementation of DANE for NSS (https://mattmccutchen.net/cryptid/#nss-dane). A number of vendors have mentioned that they are planning on implementing the specification. I do not think that it would be fair (or possible) to single out any specific reviewers -- we have had a large number of very active reviewers / participants and they have all been very diligent (and sometimes vocal :-)) in providing feedback. Personnel Warren Kumari is acting as the Document Shepherd. Stephen Farrell is the Responsible Area Director. From warren@kumari.net Fri Jun 15 08:53:56 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F8D21F857D for ; Fri, 15 Jun 2012 08:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPCv7lDGdPjT for ; Fri, 15 Jun 2012 08:53:55 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C3CE521F8573 for ; Fri, 15 Jun 2012 08:53:55 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BFB3A1B402B8 for ; Fri, 15 Jun 2012 11:53:54 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Warren Kumari In-Reply-To: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> Date: Fri, 15 Jun 2012 11:53:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> To: dane mailing list X-Mailer: Apple Mail (2.1278) Subject: Re: [dane] Protocol Action: 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' to Proposed Standard (draft-ietf-dane-protocol-23.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 15:53:56 -0000 Hello all, The chairs would like to take this opportunity to thank the the entire = Working Group for all of their hard work, input, careful review and = professionalism.=20 Particular thanks to the authors (Paul Hoffman, Jakob Schlyter) for = managing to interpret our often poorly articulated instructions and for = being willing to so quickly integrate changes and rev the document=85. We have made some great progress now (although it has taken much longer = than we had hoped, apologies for that), and can now start focusing on: A: deployment and=20 B: the "How to do DANE with $foo" series. Once again, thank you to everyone for contributing, and trying to remain = civil / willing to listen to opposing viewpoints. W On Jun 15, 2012, at 8:12 AM, The IESG wrote: > The IESG has approved the following document: > - 'The DNS-Based Authentication of Named Entities (DANE) Transport = Layer > Security (TLS) Protocol: TLSA' > (draft-ietf-dane-protocol-23.txt) as Proposed Standard >=20 > This document is the product of the DNS-based Authentication of Named > Entities Working Group. >=20 > The IESG contact persons are Stephen Farrell and Sean Turner. >=20 > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ >=20 >=20 >=20 >=20 > Technical Summary >=20 > Encrypted communication on the Internet often uses Transport Level > Security (TLS), which depends on third parties to certify the keys > used. This document improves on that situation by enabling the > administrator of a domain name to publish the keys used in the > DNS, secured with DNSSEC. >=20 > Working Group Summary >=20 >=20 > The working group made extensive use of the issue tracker: > listing, opening, discussing and then calling consensus on > each issue. This gave everyone the opportunity to participate > and be heard. There have been approximately 2,000 messages > discussing this (and closely related) documents. >=20 > Document Quality >=20 > There is a tool (Swede - https://github.com/pieterlexis/swede) > that generates TLSA records, and a proof-of-concept implementation > of DANE for NSS (https://mattmccutchen.net/cryptid/#nss-dane). > A number of vendors have mentioned that they are planning on > implementing the specification. >=20 > I do not think that it would be fair (or possible) to single > out any specific reviewers -- we have had a large number of very > active reviewers / participants and they have all been very diligent > (and sometimes vocal :-)) in providing feedback. >=20 > Personnel >=20 > Warren Kumari is acting as the Document Shepherd. > Stephen Farrell is the Responsible Area Director. >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 A. No Q. Is it sensible to top-post? From stpeter@stpeter.im Fri Jun 15 09:17:48 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E155521F852E for ; Fri, 15 Jun 2012 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYolVJqJL6Ru for ; Fri, 15 Jun 2012 09:17:48 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 613CF21F84B3 for ; Fri, 15 Jun 2012 09:17:48 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A7CB5400A4; Fri, 15 Jun 2012 10:35:06 -0600 (MDT) Message-ID: <4FDB602A.4090908@stpeter.im> Date: Fri, 15 Jun 2012 10:17:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Warren Kumari References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> In-Reply-To: <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: dane mailing list Subject: Re: [dane] Protocol Action: 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' to Proposed Standard (draft-ietf-dane-protocol-23.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:17:49 -0000 On 6/15/12 9:53 AM, Warren Kumari wrote: > Particular thanks to the authors (Paul > Hoffman, Jakob Schlyter) for managing to interpret our often poorly > articulated instructions and for being willing to so quickly > integrate changes and rev the document…. Hear, hear! /psa From paul.hoffman@vpnc.org Fri Jun 15 15:54:25 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FE311E80E5 for ; Fri, 15 Jun 2012 15:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWEiUBWLTBpT for ; Fri, 15 Jun 2012 15:54:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B624411E80CE for ; Fri, 15 Jun 2012 15:54:24 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5FMsMi0039063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Jun 2012 15:54:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> Date: Fri, 15 Jun 2012 15:54:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9728C1AB-D6B5-4DAC-AB12-225F1A73DA3E@vpnc.org> References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> To: dane mailing list X-Mailer: Apple Mail (2.1278) Subject: [dane] That "next" thing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 22:54:25 -0000 On Jun 15, 2012, at 8:53 AM, Warren Kumari wrote: > We have made some great progress now (although it has taken much = longer than we had hoped, apologies for that), and can now start = focusing on: > A: deployment and=20 > B: the "How to do DANE with $foo" series. +1 to (B). (Of course, +1 to (A) as well, but I'm not in a position got = do anything about that.) There are two types of drafts that might be part of (B): - Ones that use the TLSA RRtype but specify how a particular protocol = uses TLS and DANE. draft-fanf-dane-smtp covers interesting bits about = SMTP and DANE such as how to deal with traversing MX records, now to get = the right host name, and how to deal with STARTTLS. = draft-miller-xmpp-dnssec-prooftype covers interesting bits about XMPP, = such as how to traverse SRV records and how to get the right host name. =20 - Ones that don't use the TLSA RRtype but do DANE-style things with = non-TLS security protocols. draft-hoffman-dane-smime will parallel TLSA = but for CMS. To date, there has be zero interest in the IPsec community = for doing something DANE-style for IPsec. Both of these paths seem interesting, at least to me. --Paul Hoffman= From paul@cypherpunks.ca Sat Jun 16 12:09:03 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E439A21F84CF for ; Sat, 16 Jun 2012 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tcXxIwqGu6F for ; Sat, 16 Jun 2012 12:09:02 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D63EE21F84A2 for ; Sat, 16 Jun 2012 12:09:01 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 474968563F; Sat, 16 Jun 2012 15:08:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 3BD2F8244F; Sat, 16 Jun 2012 15:08:59 -0400 (EDT) Date: Sat, 16 Jun 2012 15:08:59 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman , "D. Hugh Redelmeier" In-Reply-To: <9728C1AB-D6B5-4DAC-AB12-225F1A73DA3E@vpnc.org> Message-ID: References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> <9728C1AB-D6B5-4DAC-AB12-225F1A73DA3E@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane mailing list Subject: [dane] RFC 4322/4025, was Re: That "next" thing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:09:03 -0000 On Fri, 15 Jun 2012, Paul Hoffman wrote: > To date, there has be zero interest in the IPsec community for doing something DANE-style for IPsec. I'm not sure what you mean with "DANE-style for IPsec" and "no interest". RFC-4025 with RFC-4322 is a "dane style ipsec" and far predates DANE. Both these documents need an update, and possibly a merge. RFC-4322 should be updated to only allow RFC-4025(bis) type DNS records. And section section 5, 9.1 and 9.2 need updating on requiring DNSSEC and hard/soft failure modes similar to DANE. I also believe that in RFC-4025, the gateway specification and their security impact also needs to be re-evaluated based on our experience with freeswan/openswan. And it probably needs to allow for other public key types based on draft-kivinen-ipsecme-oob-pubkey-00. Paul From paul.hoffman@vpnc.org Sat Jun 16 12:36:58 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECED21F847E for ; Sat, 16 Jun 2012 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9TmM00PYccG for ; Sat, 16 Jun 2012 12:36:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7BC21F8472 for ; Sat, 16 Jun 2012 12:36:58 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5GJatJi091590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 16 Jun 2012 12:36:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: Date: Sat, 16 Jun 2012 12:36:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <522C46CF-1880-49EF-A9EF-F6776CE4B3AD@vpnc.org> References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> <9728C1AB-D6B5-4DAC-AB12-225F1A73DA3E@vpnc.org> To: dane mailing list X-Mailer: Apple Mail (2.1278) Subject: Re: [dane] RFC 4322/4025, was Re: That "next" thing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:36:58 -0000 On Jun 16, 2012, at 12:08 PM, Paul Wouters wrote: > On Fri, 15 Jun 2012, Paul Hoffman wrote: >=20 >> To date, there has be zero interest in the IPsec community for doing = something DANE-style for IPsec. >=20 > I'm not sure what you mean with "DANE-style for IPsec" and "no > interest". >=20 > RFC-4025 with RFC-4322 is a "dane style ipsec" and far predates DANE. Correct. And there has been essentially no interest in either of them in = the IPsec community. > Both these documents need an update, and possibly a merge. That is a discussion for the IPsec community, not here. --Paul Hoffman= From paul@cypherpunks.ca Sat Jun 16 15:49:42 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD24821F85A0 for ; Sat, 16 Jun 2012 15:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2EYGqe6hHTm for ; Sat, 16 Jun 2012 15:49:42 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7C21F8575 for ; Sat, 16 Jun 2012 15:49:42 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 020838563F; Sat, 16 Jun 2012 18:49:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id ED3538244F; Sat, 16 Jun 2012 18:49:39 -0400 (EDT) Date: Sat, 16 Jun 2012 18:49:39 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <522C46CF-1880-49EF-A9EF-F6776CE4B3AD@vpnc.org> Message-ID: References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> <9728C1AB-D6B5-4DAC-AB12-225F1A73DA3E@vpnc.org> <522C46CF-1880-49EF-A9EF-F6776CE4B3AD@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane mailing list Subject: Re: [dane] RFC 4322/4025, was Re: That "next" thing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 22:49:42 -0000 On Sat, 16 Jun 2012, Paul Hoffman wrote: > >> On Fri, 15 Jun 2012, Paul Hoffman wrote: >> >>> To date, there has be zero interest in the IPsec community for doing something DANE-style for IPsec. >> >> I'm not sure what you mean with "DANE-style for IPsec" and "no >> interest". >> >> RFC-4025 with RFC-4322 is a "dane style ipsec" and far predates DANE. > > Correct. And there has been essentially no interest in either of them in the IPsec community. I'm a little confused by your original comment then. You seemed to suggest there was some need for a dane like RFC effort for IPsec for this working group to undertake? Paul From leifj@mnt.se Sun Jun 17 00:14:50 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA5121F84C8 for ; Sun, 17 Jun 2012 00:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvFfUsgAclx7 for ; Sun, 17 Jun 2012 00:14:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E32B321F84B3 for ; Sun, 17 Jun 2012 00:14:49 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4044905lbb.31 for ; Sun, 17 Jun 2012 00:14:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=pyhZZC8wCoCj9yUdvObqc9oVMWdU/1RJdmObUZx5Pxg=; b=QMKdtbhWAR4jqphGMzH69NhQWfLaxq+t0vGEuceTRReoJOB6WXc6tqR1+iTjV+rJvs yYScUTpLb/4wIpuWfr/SUGR3mTXy094q1c+h3k8GwT1AvAvKjz4at3N9Sbmhr2aMO3mJ JEeH1vJyBMI+0NC+m0aUwZvymP9Fvrg56PbG+OCc+MJTHgeZG8EIQgEfO1dU1izw9aUO W+WfFjM1CRwrIhPzeLP4PePrwp0Qf5D/3Kb3Cab8vQW9OhUSQv07QSqjDHWWPlA/n2ny RLtKVOBCSaZ2NGLkth+OHfeTJzrB+wHumz8UsgcOzxKGalomcLtZ3UUkqoKt4Dq8kZV8 /dmw== Received: by 10.112.42.34 with SMTP id k2mr4833890lbl.0.1339917288908; Sun, 17 Jun 2012 00:14:48 -0700 (PDT) Received: from [10.0.0.232] (ua-83-227-179-169.cust.bredbandsbolaget.se. [83.227.179.169]) by mx.google.com with ESMTPS id hi14sm20929054lab.4.2012.06.17.00.14.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 00:14:47 -0700 (PDT) References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> <4FDB602A.4090908@stpeter.im> In-Reply-To: <4FDB602A.4090908@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9B206) From: Leif Johansson Date: Sun, 17 Jun 2012 09:14:45 +0200 To: Peter Saint-Andre X-Gm-Message-State: ALoCoQmONnPIGuCHeOXzgo+/WG1DiaeNnluU+h41dzotjC7VMVxLJnHB3x19kp/Vm8HVxzI/gB+m Cc: dane mailing list Subject: Re: [dane] Protocol Action: 'The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA' to Proposed Standard (draft-ietf-dane-protocol-23.txt) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 07:14:50 -0000 15 jun 2012 kl. 18:17 skrev Peter Saint-Andre : > On 6/15/12 9:53 AM, Warren Kumari wrote: >> Particular thanks to the authors (Paul >> Hoffman, Jakob Schlyter) for managing to interpret our often poorly >> articulated instructions and for being willing to so quickly >> integrate changes and rev the document=E2=80=A6. >=20 > Hear, hear! > =20 +1= From paul.hoffman@vpnc.org Sun Jun 17 11:33:11 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA24C21F8593 for ; Sun, 17 Jun 2012 11:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2IXXDLQjYmQ for ; Sun, 17 Jun 2012 11:33:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACE321F858F for ; Sun, 17 Jun 2012 11:33:11 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5HIWx6P022504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jun 2012 11:33:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 17 Jun 2012 11:32:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120615121239.13766.94700.idtracker@ietfa.amsl.com> <88D74E66-459F-48D1-BE5A-9479F1A9712F@kumari.net> <9728C1AB-D6B5-4DAC-AB12-225F1A73DA3E@vpnc.org> <522C46CF-1880-49EF-A9EF-F6776CE4B3AD@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1278) Cc: dane mailing list Subject: Re: [dane] RFC 4322/4025, was Re: That "next" thing X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 18:33:12 -0000 On Jun 16, 2012, at 3:49 PM, Paul Wouters wrote: > On Sat, 16 Jun 2012, Paul Hoffman wrote: >=20 >>=20 >>> On Fri, 15 Jun 2012, Paul Hoffman wrote: >>>=20 >>>> To date, there has be zero interest in the IPsec community for = doing something DANE-style for IPsec. >>>=20 >>> I'm not sure what you mean with "DANE-style for IPsec" and "no >>> interest". >>>=20 >>> RFC-4025 with RFC-4322 is a "dane style ipsec" and far predates = DANE. >>=20 >> Correct. And there has been essentially no interest in either of them = in the IPsec community. >=20 > I'm a little confused by your original comment then. You seemed to > suggest there was some need for a dane like RFC effort for IPsec for > this working group to undertake? I don't see where I seemed to suggest that, but I certainly didn't mean = to. --Paul Hoffman From warren@kumari.net Sun Jun 17 14:47:17 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90521F84FA for ; Sun, 17 Jun 2012 14:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4Ncfwavl79k for ; Sun, 17 Jun 2012 14:47:16 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B30A121F84E7 for ; Sun, 17 Jun 2012 14:47:16 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id A6DC21B40377 for ; Sun, 17 Jun 2012 17:47:15 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 17 Jun 2012 17:47:13 -0400 Message-Id: To: dane mailing list Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [dane] I'm off traveling... X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 21:47:17 -0000 Hi there all, I will be traveling for the next 2 or so weeks. While I will be checking = email, I may be taking a bunch longer to respond=85 IETF 84 is fast approaching. We *do* have a slot scheduled, and would = like to use that to discuss the "How to do DANE with $foo" documents = (and the future of the WG, etc). So, if you would like to / are willing to present on your "How to do = DANE with $foo" draft, please let us know soon. Drafts that have been = discussed get priority, those with early slides (PDF only, no PPT!) get = additional priority :-P W -- Hope is not a strategy. -- Ben Treynor, Google From ondrej.sury@nic.cz Thu Jun 21 04:05:44 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27021F85F3 for ; Thu, 21 Jun 2012 04:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpIRpmKemMpE for ; Thu, 21 Jun 2012 04:05:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DE46521F851C for ; Thu, 21 Jun 2012 04:05:40 -0700 (PDT) Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id C1929140F5D; Thu, 21 Jun 2012 13:05:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340276739; bh=WmbTNSTlkgD6EDbmsdugre5an029+V8Ko7+ojkDrNvA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Op/gtCrt4l6KH/DNAHVRJvW95xSxzMA41egjriPgvdRDiSUGMRlFFt+C6d6ClxWmG hPeg7DtFx/E/WUF+irgrmyeUgENV3dBnFLdqPzFv5PNAC8ARnMdXZYr9k+ZhyqmcBR wRI9YlABVkQ+P7YBsxtZrICvfCz8yJkqQSicTjLA= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <3BB91448-A97C-488C-9B49-6A8387396A76@nic.cz> Date: Thu, 21 Jun 2012 13:05:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C208B4A-EB51-428E-89A7-1DA99CA5F5B1@nic.cz> References: <3BB91448-A97C-488C-9B49-6A8387396A76@nic.cz> To: dane WG list X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dane-chairs@tools.ietf.org Subject: Re: [dane] Meeting in Vancouver X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 11:05:44 -0000 Final agenda is due in two weeks and we still haven't heard from anybody willing to present any of the topics below... So this is just a bugging email to remind you to make up your mind and just ping us with: "Yes, I will present foo". If we don't gather any topics, there will be almost no reason to meet... O. On 5. 6. 2012, at 14:16, Ond=C5=99ej Sur=C3=BD wrote: > Hi all, >=20 > this is just a notification that we will meet in Vancouver, > so if you already have some things you would like to see > on the agenda, please send it to us. >=20 > As far I can see several topics: >=20 > - What to do next? Close/Hiatus/Recharter/...? (chairs) > - DANE+S/MIME > - DANE+XMMP > - DANE+SMTP On 17. 6. 2012, at 23:47, Warren Kumari wrote: > IETF 84 is fast approaching. We *do* have a slot scheduled, and would = like to use that to discuss the "How to do DANE with $foo" documents = (and the future of the WG, etc). > So, if you would like to / are willing to present on your "How to do = DANE with $foo" draft, please let us know soon. Drafts that have been = discussed get priority, those with early slides (PDF only, no PPT!) get = additional priority :-P -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From paul.hoffman@vpnc.org Thu Jun 21 07:54:37 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501DF21F8707 for ; Thu, 21 Jun 2012 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKima3zq2S8S for ; Thu, 21 Jun 2012 07:54:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B250521F86F4 for ; Thu, 21 Jun 2012 07:54:36 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q5LEsV8x061027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Jun 2012 07:54:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <1C208B4A-EB51-428E-89A7-1DA99CA5F5B1@nic.cz> Date: Thu, 21 Jun 2012 07:54:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3FC0FD59-FDCB-45CA-ABBE-A9430E246345@vpnc.org> References: <3BB91448-A97C-488C-9B49-6A8387396A76@nic.cz> <1C208B4A-EB51-428E-89A7-1DA99CA5F5B1@nic.cz> To: dane WG list X-Mailer: Apple Mail (2.1278) Subject: Re: [dane] Meeting in Vancouver X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 14:54:37 -0000 On Jun 21, 2012, at 4:05 AM, Ond=C5=99ej Sur=C3=BD wrote: > Final agenda is due in two weeks and we still haven't heard > from anybody willing to present any of the topics below... >=20 > So this is just a bugging email to remind you to make up > your mind and just ping us with: "Yes, I will present foo". >=20 > If we don't gather any topics, there will be almost no reason > to meet... I will present on draft-fanf-dane-smtp based on slides from Tony Finch. Either Jakob or I will present on draft-hoffman-dane-smime. --Paul Hoffman= From fanf2@hermes.cam.ac.uk Wed Jun 27 12:09:59 2012 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A721F866B for ; Wed, 27 Jun 2012 12:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD4-yjHm0Ogn for ; Wed, 27 Jun 2012 12:09:58 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2996421F8665 for ; Wed, 27 Jun 2012 12:09:58 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37164) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Sjxci-00050s-sS (Exim 4.72) for dane@ietf.org (return-path ); Wed, 27 Jun 2012 20:09:56 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Sjxci-0003WK-Qu (Exim 4.67) for dane@ietf.org (return-path ); Wed, 27 Jun 2012 20:09:56 +0100 Date: Wed, 27 Jun 2012 20:09:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dane@ietf.org Message-ID: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Subject: [dane] draft-fanf-dane-mua-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:10:00 -0000 At long last, I have got what I hope is a plausible spec for using DANE with IMAP, POP3, and message submission. I think my main struggle was working out what I did not need to put in the document. The compatibility bits are particularly tricky. The structure owes a fair amount to Matt Miller and PSA's XMPP draft, and to RFC 6186. I have also made a minor revision to my other draft which is now draft-fanf-dane-smt-04. This is mainly to flag up points for discussion in Vancouver. All questions / comments / suggestions welcome! Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Variable mainly northwesterly 3 or 4, but easterly 5 to 7 at first in far southeast. Rough at first in far southeast, otherwise slight or moderate. Showers, fog patches. Moderate or good, occasionally very poor. ---------- Forwarded message ---------- Date: Wed, 27 Jun 2012 11:58:10 -0700 From: internet-drafts@ietf.org To: dot@dotat.at Subject: New Version Notification for draft-fanf-dane-mua-00.txt A new version of I-D, draft-fanf-dane-mua-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository. Filename: draft-fanf-dane-mua Revision: 00 Title: DNSSEC and TLSA records for IMAP, POP3, and message submission Creation date: 2012-06-27 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-fanf-dane-mua-00.txt Status: http://datatracker.ietf.org/doc/draft-fanf-dane-mua Htmlized: http://tools.ietf.org/html/draft-fanf-dane-mua-00 Abstract: This specification describes the effect that DNSSEC has on SRV-based autoconfiguration and TLS certificate verification in the mail user agent protocols IMAP, POP3, and message submission. It also describes how to use TLSA DNS records to provide stronger authentication of server TLS certificates. The IETF Secretariat