From nobody Mon Feb 16 07:59:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DD41A1B0A; Mon, 16 Feb 2015 07:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttTh-y4b5QE7; Mon, 16 Feb 2015 07:59:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B2A1A88C3; Mon, 16 Feb 2015 07:59:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216155931.9775.28655.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 07:59:31 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-09.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:59:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-09.txt Pages : 14 Date : 2015-02-16 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 16 09:01:31 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E476B1A1B66 for ; Mon, 16 Feb 2015 09:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFZvEU1wHOTq for ; Mon, 16 Feb 2015 09:01:28 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE881A1EF1 for ; Mon, 16 Feb 2015 09:01:24 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 75DE3282D5F; Mon, 16 Feb 2015 17:01:23 +0000 (UTC) Date: Mon, 16 Feb 2015 17:01:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150216170123.GR1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 17:01:30 -0000 [ Note, I've read only the changes from -08, not the whole document. ] Section 3.4 (Impact on TLA Usage) second bullet: Revert change from -08 to -09. The -08 language: If the TLSA response is "insecure", then the client SHALL proceed ... was correct, the -09 language opens the door to downgrade attacks: If the TLSA lookup fails, then the client SHALL proceed as if the ... Section 3.1 (Srv Query): Quote: If the lookup result is "insecure" (or no SRV records are located), this protocol does not apply and the client SHOULD fall back to its non-DNSSEC, non-DANE (and possibly non-SRV) behavior. If the SRV lookup fails because the RRset is "bogus", the client MUST abort its attempt to connect to the desired service. Note that *any* SRV lookup error, not just "bogus" needs to trigger connection failure. Timeout, SRVFAIL, ... all of these are potential downgrade attacks. Here, error is in the sense of section 2.1.1 of the SMTP draft (NXDOMAIN either "secure" or "insecure" is NOT an error). In light of that, the parenthetical comment "(or no SRV records are located)" should perhaps be made more precise. (or the lookup result is a denial of existence, whether "secure" or "insecure", but is not a lookup error) Also please update your xml2rfc reference cache, the SMTP draft reference should be to version 13. -- Viktor. From nobody Mon Feb 16 09:36:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8051A1B84 for ; Mon, 16 Feb 2015 09:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.818 X-Spam-Level: X-Spam-Status: No, score=-11.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7x_PyMGJyTO for ; Mon, 16 Feb 2015 09:35:59 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1973E1A1BB3 for ; Mon, 16 Feb 2015 09:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3589; q=dns/txt; s=iport; t=1424108146; x=1425317746; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pW/6RcZimfrkjYIBMhjKdhdajM1SFoWyzy96E3U+Sz0=; b=C23iQuIOjiA0+ik6KKO8566+1ZpOI0Rak3N7yZcxP/e8sMO+B8ng6jeM fHHCrd8K5UY8DZ14wSBrayRXGu8pdWKdK75bNMeEF7ovte5ibmPZ6AZWa TjyVmRQp4LpKD6149rufGfKcm5dvty/6jqKRM8NEmghRnoNogR2Q4lsmq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BmBQD/KOJU/5pdJa1cgwZSWgSCf78yhXkCgRdDAQEBAQEBfIQMAQEBAwEjDwFFBgsLGAICBQwKCwICCQMCAQIBRQYNBgIBAYghCLchll0BAQEBAQEBAwEBAQEBAQEBFgSBIYlrhDo6CoJegUIFijqIVYVggRiDDYIqIYVWgwmDPiKCAQEcgXBPgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,588,1418083200"; d="scan'208";a="124004246" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 16 Feb 2015 17:35:45 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1GHZjYw028139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Feb 2015 17:35:45 GMT Received: from [10.129.24.61] (10.129.24.61) by xhc-aln-x09.cisco.com (173.36.12.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 16 Feb 2015 11:35:45 -0600 Message-ID: <54E22A70.8050705@cisco.com> Date: Mon, 16 Feb 2015 10:35:44 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150216170123.GR1260@mournblade.imrryr.org> In-Reply-To: <20150216170123.GR1260@mournblade.imrryr.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.61] Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 17:36:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thanks for the feedback! More inline ... On 2/16/15 10:01 AM, Viktor Dukhovni wrote: > > [ Note, I've read only the changes from -08, not the whole > document. ] > > Section 3.4 (Impact on TLA Usage) second bullet: > > Revert change from -08 to -09. The -08 language: > > If the TLSA response is "insecure", then the client SHALL proceed > ... > > was correct, the -09 language opens the door to downgrade attacks: > > If the TLSA lookup fails, then the client SHALL proceed as if the > ... > The original language did not account for the lack of records, but I can see how this is too permissive. Perhaps the following is more acceptable (replacing the last two bullets in dane-srv-09)? o If the TLSA response is "bogus" or "indeterminate" (or the lookup fails for reasons other than no records), then the client MUST NOT connect to the target server (the client can still use other SRV targets). o If the TLSA response is "insecure" (or no TLSA records exist), then the client SHALL proceed as if the target server had no TLSA records. It MAY connect to the target server with or without TLS, subject to the policies of the application protocol or client implementation. > Section 3.1 (Srv Query): > > Quote: > > If the lookup result is "insecure" (or no SRV records are located), > this protocol does not apply and the client SHOULD fall back to its > non-DNSSEC, non-DANE (and possibly non-SRV) behavior. If the SRV > lookup fails because the RRset is "bogus", the client MUST abort > its attempt to connect to the desired service. > > Note that *any* SRV lookup error, not just "bogus" needs to > trigger connection failure. Timeout, SRVFAIL, ... all of these > are potential downgrade attacks. Here, error is in the sense of > section 2.1.1 of the SMTP draft (NXDOMAIN either "secure" or > "insecure" is NOT an error). > > In light of that, the parenthetical comment "(or no SRV records > are located)" should perhaps be made more precise. > > (or the lookup result is a denial of existence, whether "secure" or > "insecure", but is not a lookup error) The parenthetical is meant to account for the lack of SRV records, but I can see how that might be too permissive. Is the following more acceptable? If the SRV lookup fails because the RRset is "bogus" (or the lookup fails for reasons other than no records), the client MUST abort its attempt to connect to the desired service. If the lookup result is "insecure" (or no SRV records exist), this protocol does not apply and the client SHOULD fall back to its non-DNSSEC, non-DANE (and possibly non-SRV) behavior. > > Also please update your xml2rfc reference cache, the SMTP draft > reference should be to version 13. > Thanks for the catch. I'll force a cache refresh. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4ipwAAoJEDWi+S0W7cO1IAwH/jm69XKWbgc+r1Wxrayrt6cG Tb05iVU3JNUZlEn1ATw6J0HCasaY/9AKqOUQTOl6kU56aWOUvZV2lVB62+h1mcI6 sqTOillrK7bvAoWLJRzCoFchsVZqmaCv0ZkimMwnDj36/lJC07BZxsvRWTknKOCK 8JtdCm6JbkxadO5trkNoL2y5u9Ca5LBCBbNNAsA5AdlVzAlQDwFJDNMF1gP0Tfpw rx3jADKoojWnSfNu0QFh2biiefjW1IEWnGqXxCqZCsguVcAjKYqCQWkKlN4tI7Ok V5ryDFX512UwKTluBf+lti/xFr9NrEeeUzyfwEXZ21bf1Zx8WqW1u5RI1BlLt3g= =hnNh -----END PGP SIGNATURE----- From nobody Mon Feb 16 10:08:34 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FEF1A6FF9 for ; Mon, 16 Feb 2015 10:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.493 X-Spam-Level: X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ML9QcpeyzP0 for ; Mon, 16 Feb 2015 10:08:21 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D441A7008 for ; Mon, 16 Feb 2015 10:08:19 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4EA6C282D5F; Mon, 16 Feb 2015 18:08:13 +0000 (UTC) Date: Mon, 16 Feb 2015 18:08:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150216180813.GT1260@mournblade.imrryr.org> References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E22A70.8050705@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 18:08:23 -0000 On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller wrote: > Thanks for the feedback! More inline ... > > > Section 3.4 (Impact on TLA Usage) second bullet: > > > > Revert change from -08 to -09. The -08 language: > > [...] > > The original language did not account for the lack of records, but I > can see how this is too permissive. Perhaps the following is more > acceptable (replacing the last two bullets in dane-srv-09)? > > o If the TLSA response is "bogus" or "indeterminate" (or the lookup > fails for reasons other than no records), then the client MUST > NOT connect to the target server (the client can still use other > SRV targets). > > o If the TLSA response is "insecure" (or no TLSA records exist), > then the client SHALL proceed as if the target server had no TLSA > records. It MAY connect to the target server with or without > TLS, subject to the policies of the application protocol or > client implementation. Much better and basically correct, provided that it is clear that "indeterminate" is the 4035 (not 4033) definition, and the phrase "fails for reasons other than no records" is sufficiently clear to the document's audience. It is a somewhat informal phrase... In the SMTP draft ([1] below my signature) "no records" (be it NOERROR with ancount==0 or NXDOMAIN) is defined as a non-error (a successful empty result). Your taxonomy is different, but my guess is that the text is good enough. [ Is denial of existence of a success or a failure? How many angels can dance on the head of a pin? ... ] ---- Question to the WG at large: Anyone see any room for confusion about the meaning of the proposed text? ---- > The parenthetical is meant to account for the lack of SRV records, but > I can see how that might be too permissive. Is the following more > acceptable? > > If the SRV lookup fails because the RRset is "bogus" (or the lookup > fails for reasons other than no records), the client MUST abort its > attempt to connect to the desired service. If the lookup result is > "insecure" (or no SRV records exist), this protocol does not apply > and the client SHOULD fall back to its non-DNSSEC, non-DANE (and > possibly non-SRV) behavior. Thanks. Looks fine, provided the "fails for reasons other than no records" bit is clear enough to the world at large. -- Viktor. [1] SMTP draft section 2.1.1 (middle of page 10): There is an important non-failure condition we need to highlight in addition to the obvious case of the DNS client obtaining a non-empty "secure" or "insecure" RRset of the requested type. Namely, it is not an error when either "secure" or "insecure" non-existence is determined for the requested data. When a DNSSEC response with a validation status that is either "secure" or "insecure" reports either no records of the requested type or non-existence of the query domain, the response is not a DNS error condition. The DNS client has not been left without an answer; it has learned that records of the requested type do not exist. From nobody Mon Feb 16 13:48:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483ED1A88B2 for ; Mon, 16 Feb 2015 13:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.818 X-Spam-Level: X-Spam-Status: No, score=-11.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgB4AgBfaZ7V for ; Mon, 16 Feb 2015 13:48:28 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BA91A0354 for ; Mon, 16 Feb 2015 13:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3233; q=dns/txt; s=iport; t=1424123302; x=1425332902; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0OeBr6H1Db2oTkMt/b+QW57I0TtT4PKchV1kM11gziA=; b=iU+ENh2JWOcJ3zc4S8wLEfztNEI0bbEwYzHphjFZn78vf9Q4lPHEJk4t mwauRjrfkDAHZNlsVSt8mEZr6crQEtec+wOX4srlUCjWuy0cal/EO6A1H AlCK01/wX55H975WIJGwRL+dZ2eZkRSTW8TEZE37cBbJgpFV9jE83C9Ux Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BmBQAEZeJU/5tdJa1bgwZSWgSCf781hXkCgRhDAQEBAQEBfIQNAQEEI1URCxgCAgUMCgsCAgkDAgECAUUGDQYCAQGIKbcNlwQBAQEBAQEBAwEBAQEBAQEBFgSBIYlrhDo6CoJegUIFijqIVYVggRiFN4kAgz4iggEBHIFwT4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,590,1418083200"; d="scan'208";a="124078719" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 16 Feb 2015 21:48:22 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1GLmKVG001114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Feb 2015 21:48:20 GMT Received: from [10.129.24.61] (10.129.24.61) by xhc-aln-x09.cisco.com (173.36.12.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 16 Feb 2015 15:48:19 -0600 Message-ID: <54E265A3.8040201@cisco.com> Date: Mon, 16 Feb 2015 14:48:19 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> In-Reply-To: <20150216180813.GT1260@mournblade.imrryr.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.61] Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:48:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/16/15 11:08 AM, Viktor Dukhovni wrote: > On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller wrote: > >> Thanks for the feedback! More inline ... >> >>> Section 3.4 (Impact on TLA Usage) second bullet: >>> >>> Revert change from -08 to -09. The -08 language: [...] >> >> The original language did not account for the lack of records, >> but I can see how this is too permissive. Perhaps the following >> is more acceptable (replacing the last two bullets in >> dane-srv-09)? >> >> o If the TLSA response is "bogus" or "indeterminate" (or the >> lookup fails for reasons other than no records), then the client >> MUST NOT connect to the target server (the client can still use >> other SRV targets). >> >> o If the TLSA response is "insecure" (or no TLSA records >> exist), then the client SHALL proceed as if the target server had >> no TLSA records. It MAY connect to the target server with or >> without TLS, subject to the policies of the application protocol >> or client implementation. > > Much better and basically correct, provided that it is clear that > "indeterminate" is the 4035 (not 4033) definition, and the phrase > "fails for reasons other than no records" is sufficiently clear to > the document's audience. It is a somewhat informal phrase... > > In the SMTP draft ([1] below my signature) "no records" (be it > NOERROR with ancount==0 or NXDOMAIN) is defined as a non-error (a > successful empty result). Your taxonomy is different, but my > guess is that the text is good enough. > > [ Is denial of existence of a success or a failure? How many > angels can dance on the head of a pin? ... ] > > ---- Question to the WG at large: > > Anyone see any room for confusion about the meaning of the proposed > text? ---- > >> The parenthetical is meant to account for the lack of SRV >> records, but I can see how that might be too permissive. Is the >> following more acceptable? >> >> If the SRV lookup fails because the RRset is "bogus" (or the >> lookup fails for reasons other than no records), the client MUST >> abort its attempt to connect to the desired service. If the >> lookup result is "insecure" (or no SRV records exist), this >> protocol does not apply and the client SHOULD fall back to its >> non-DNSSEC, non-DANE (and possibly non-SRV) behavior. > > Thanks. Looks fine, provided the "fails for reasons other than no > records" bit is clear enough to the world at large. > I'll submit -10 presently. Thanks again, - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU4mWjAAoJEDWi+S0W7cO178sIAJO+FPG1S1IsU9Ubsfkojnyl z4wkU7JGolLJ4eZUY+YMndYWpYo2CpxIdyOWN/dSDzIAiVZmgcQk0/3Rf+Z2BUKw /EZXtpzXKLXhTK2qdM2Frb10UjUZ6pmuwZY6eVz00qPJrVqRJF+g9101YNS92gM5 npY1mBX9FWE2Kww9/HV98og6zKxUltlYGb4qhzpKWkLCQRXuWPLUHEKkJZulPpIU 22ECLP1RRp3cBdZwu+QjeKQZsfyj/fg56afVMEawOKdIKHYQXSWJ0tCkzkRq+mv6 6vwEOFnztHaQtFz7+DKOgHKpGpCuN3SfIQ3acmjxea4YbjEL57fbbSG3QYFvUYk= =XWQQ -----END PGP SIGNATURE----- From nobody Mon Feb 16 13:50:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6A1A88E8; Mon, 16 Feb 2015 13:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJc7lmsIxqfY; Mon, 16 Feb 2015 13:49:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 632381A88EF; Mon, 16 Feb 2015 13:49:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216214925.2937.92260.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 13:49:25 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:49:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-10.txt Pages : 14 Date : 2015-02-16 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 14:01:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002B51A87CD for ; Tue, 17 Feb 2015 14:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMPJn1fjTXzm for ; Tue, 17 Feb 2015 14:01:43 -0800 (PST) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EB21A8822 for ; Tue, 17 Feb 2015 14:01:35 -0800 (PST) Received: from smtp13.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C3547380290; Tue, 17 Feb 2015 17:01:34 -0500 (EST) Received: by smtp13.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 507803804F3; Tue, 17 Feb 2015 17:01:34 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Tue, 17 Feb 2015 22:04:33 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_7C21C6ED-2B41-4968-A745-7ECF961F5A25" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <54E265A3.8040201@cisco.com> Date: Tue, 17 Feb 2015 17:01:33 -0500 Message-Id: <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> To: =?utf-8?Q?=E2=8C=98_Matt_Miller?= X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 22:01:46 -0000 --Apple-Mail=_7C21C6ED-2B41-4968-A745-7ECF961F5A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Matt, thank you for updating the draft based on last call comments.=20 I have verified that you seem to have addressed all the comments that I = noted.=20 I like the new definitions you added they add clarity, thanks.=20 But I noticed some =E2=80=9Cstrange language=E2=80=9D=20 I section 3.1 you say in paragraph 2:=20 For this specification to apply, the entire DNS RRset that is returned = MUST be =E2=80=9Csecure=E2=80=9D =E2=80=A6=20 Well the word entire is redundant if you are talking about single DNS = RRset,=20 BUT I think there are missing words i.e. the sentence should be: For this specification to apply, the entire chain of DNS RRset(s) that = is returned MUST be =E2=80=9Csecure=E2=80=9D =E2=80=A6 =20 If the second interpretation is right some minor word-smithing in = paragraph 3 is also needed.=20 Olafur as document Shepard=20 > On Feb 16, 2015, at 4:48 PM, =E2=8C=98 Matt Miller = wrote: >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 2/16/15 11:08 AM, Viktor Dukhovni wrote: >> On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller wrote: >>=20 >>> Thanks for the feedback! More inline ... >>>=20 >>>> Section 3.4 (Impact on TLA Usage) second bullet: >>>>=20 >>>> Revert change from -08 to -09. The -08 language: [...] >>>=20 >>> The original language did not account for the lack of records, >>> but I can see how this is too permissive. Perhaps the following >>> is more acceptable (replacing the last two bullets in >>> dane-srv-09)? >>>=20 >>> o If the TLSA response is "bogus" or "indeterminate" (or the >>> lookup fails for reasons other than no records), then the client >>> MUST NOT connect to the target server (the client can still use >>> other SRV targets). >>>=20 >>> o If the TLSA response is "insecure" (or no TLSA records >>> exist), then the client SHALL proceed as if the target server had >>> no TLSA records. It MAY connect to the target server with or >>> without TLS, subject to the policies of the application protocol >>> or client implementation. >>=20 >> Much better and basically correct, provided that it is clear that=20 >> "indeterminate" is the 4035 (not 4033) definition, and the phrase=20 >> "fails for reasons other than no records" is sufficiently clear to=20 >> the document's audience. It is a somewhat informal phrase... >>=20 >> In the SMTP draft ([1] below my signature) "no records" (be it=20 >> NOERROR with ancount=3D=3D0 or NXDOMAIN) is defined as a non-error (a=20= >> successful empty result). Your taxonomy is different, but my >> guess is that the text is good enough. >>=20 >> [ Is denial of existence of a success or a failure? How many=20 >> angels can dance on the head of a pin? ... ] >>=20 >> ---- Question to the WG at large: >>=20 >> Anyone see any room for confusion about the meaning of the proposed >> text? ---- >>=20 >>> The parenthetical is meant to account for the lack of SRV >>> records, but I can see how that might be too permissive. Is the >>> following more acceptable? >>>=20 >>> If the SRV lookup fails because the RRset is "bogus" (or the >>> lookup fails for reasons other than no records), the client MUST >>> abort its attempt to connect to the desired service. If the >>> lookup result is "insecure" (or no SRV records exist), this >>> protocol does not apply and the client SHOULD fall back to its >>> non-DNSSEC, non-DANE (and possibly non-SRV) behavior. >>=20 >> Thanks. Looks fine, provided the "fails for reasons other than no=20 >> records" bit is clear enough to the world at large. >>=20 >=20 > I'll submit -10 presently. >=20 >=20 > Thanks again, >=20 > - --=20 > - - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. --Apple-Mail=_7C21C6ED-2B41-4968-A745-7ECF961F5A25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Matt, thank you for updating the draft based on last = call comments. 
I have verified that you seem to have = addressed all the comments that I noted. 
I like the new = definitions you added they add clarity, thanks. 

But I noticed some =E2=80=9Cstrange = language=E2=80=9D 
I section 3.1 you say in paragraph = 2: 
For this specification to apply, the entire DNS RRset = that is returned MUST be =E2=80=9Csecure=E2=80=9D = =E2=80=A6 

Well the word entire = is redundant if you are talking about single DNS = RRset, 
BUT I think there are missing words i.e. the = sentence should be:

For this = specification to apply, the entire chain of  DNS RRset(s) that is = returned MUST be =E2=80=9Csecure=E2=80=9D = =E2=80=A6
 
If the second interpretation is = right some minor word-smithing in paragraph 3 is also = needed. 

Olafur as document = Shepard 



On Feb 16, 2015, at 4:48 PM, =E2=8C=98 Matt = Miller <mamille2@cisco.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2/16/15 11:08 AM, Viktor Dukhovni = wrote:
On Mon, Feb 16, 2015 at 10:35:44AM -0700, ? Matt Miller = wrote:

Thanks for the feedback!  More inline ...

Section = 3.4 (Impact on TLA Usage) second bullet:

Revert change from -08 to -09.  The -08 language: = [...]

The original language = did not account for the lack of records,
but I can see how = this is too permissive.  Perhaps the following
is = more acceptable (replacing the last two bullets in
dane-srv-09)?

o  If the = TLSA response is "bogus" or "indeterminate" (or the
lookup = fails for reasons other than no records), then the client
MUST NOT connect to the target server (the client can still = use
other SRV targets).

o =  If the TLSA response is "insecure" (or no TLSA records
exist), then the client SHALL proceed as if the target server = had
no TLSA records.  It MAY connect to the target = server with or
without TLS, subject to the policies of the = application protocol
or client implementation.

Much better and basically = correct, provided that it is clear that 
"indeterminate" is the 4035 (not 4033) definition, and the = phrase 
"fails for reasons other than no records" is sufficiently = clear to 
the document's audience.  It is a somewhat informal = phrase...

In the SMTP draft ([1] below my = signature) "no records" (be it 
NOERROR with = ancount=3D=3D0 or NXDOMAIN) is defined as a non-error (a 
successful = empty result).  Your taxonomy is different, but my
guess is that the text is good enough.

[ Is denial of existence of a success or a failure?  How = many 
angels can dance on the head of a pin? ... ]

---- Question to the WG at large:

Anyone see any room for confusion about the meaning of the = proposed
text? ----

The parenthetical is meant to account for the = lack of SRV
records, but I can see how that might be too = permissive.  Is the
following more acceptable?

If the SRV lookup fails because the RRset is = "bogus" (or the
lookup fails for reasons other than no = records), the client MUST
abort its attempt to connect to = the desired service.  If the
lookup result is = "insecure" (or no SRV records exist), this
protocol does = not apply and the client SHOULD fall back to its
non-DNSSEC,= non-DANE (and possibly non-SRV) behavior.

Thanks.  Looks fine, provided the "fails for reasons = other than no 
records" bit is clear enough to the world at large.


I'll submit -10 presently.


Thanks again,

- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

= --Apple-Mail=_7C21C6ED-2B41-4968-A745-7ECF961F5A25-- From nobody Tue Feb 17 14:05:41 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411821A90E7 for ; Tue, 17 Feb 2015 14:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SztedjWhduoh for ; Tue, 17 Feb 2015 14:05:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678811A90E6 for ; Tue, 17 Feb 2015 14:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1697; q=dns/txt; s=iport; t=1424210739; x=1425420339; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ejFdFYUIuQXC8PQE7O4rgNGxaTdCOlQotULuseGwMV8=; b=BFOTiFX53fVops9c5zHHJc/ebQJsExkvvuHarUIV8lyEQkPfE+dCmY/u CL/DU0K0XuhZo9yAt2AHjQYHFhSgNMNY/Had3JzdF3mGrc5d4MOSDqag7 oHruSK1wa4KkXnfsmusLrmPXO7hj44tJd5EXk7bRB4Cly0xjLuSqOtYcd w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9BQD4ueNU/4gNJK1bgwZSWgSCf79HhXkCgRpDAQEBAQEBfIQNAQEEIw8BRQEQCQIOCgICBRYLAgIJAwIBAgE1EAYNAQUCAQGIK5xqnGyXcAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGJboQ7MweCaIFCAQSKOohVhWCBGIU3hXeGRyKCAR2BcE+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="393831317" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 17 Feb 2015 22:05:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1HM5bsn031958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 22:05:37 GMT Received: from [10.129.24.61] (10.129.24.61) by xhc-aln-x09.cisco.com (173.36.12.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 17 Feb 2015 16:05:37 -0600 Message-ID: <54E3BB30.2030501@cisco.com> Date: Tue, 17 Feb 2015 15:05:36 -0700 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> In-Reply-To: <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.61] Archived-At: Cc: dane@ietf.org Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 22:05:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/17/15 3:01 PM, Olafur Gudmundsson wrote: > Matt, thank you for updating the draft based on last call comments. > I have verified that you seem to have addressed all the comments > that I noted. I like the new definitions you added they add > clarity, thanks. > > But I noticed some “strange language” I section 3.1 you say in > paragraph 2: For this specification to apply, the entire DNS RRset > that is returned MUST be “secure” … > > Well the word entire is redundant if you are talking about single > DNS RRset, BUT I think there are missing words i.e. the sentence > should be: > > For this specification to apply, the entire chain of DNS RRset(s) > that is returned MUST be “secure” … > > If the second interpretation is right some minor word-smithing in > paragraph 3 is also needed. > > Olafur as document Shepard > > > Thanks for the catch! The intent is the second interpretation. I'll get an update (which will be revision -11) out soon. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU47swAAoJEDWi+S0W7cO1G50IAKgd6Gt4wbY4/vOWbzAhjWAV dEFF9+z58QFUJ2xJ1sW0x95w10py8iH1BvPyiZXA++x68fbNjiUly29cnHa8Csfq SunGRY36yOOLjSxLcADkN7lwYznNVJEjWF8tLyoh2I1kcu+jW5MLGCn88/twZe09 H0aK7NlW5+Oyant22DkdnPC7VRhp6YR64CdmPmI+JQrfM/MpTulzOROD0E/T3hfe lpjkh4i6Pxs7rEOx1Z7glci5RdzGE70QacuRt95s9/rn3ixoBI1w7y43eMWc/Xri JyzayGIyw0p7C1txBQhGxk8jgPOjDcQKt6blmBULu/rPdGmwkwEdwoXRhANR7hM= =a1JU -----END PGP SIGNATURE----- From nobody Tue Feb 17 14:34:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721C51A1AB5; Tue, 17 Feb 2015 14:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfCTj9zgM9J4; Tue, 17 Feb 2015 14:34:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8141A8025; Tue, 17 Feb 2015 14:33:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217223359.19643.13596.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 14:33:59 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-11.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 22:34:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-11.txt Pages : 14 Date : 2015-02-17 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its TLS certificate. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 14:41:18 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3296B1A1AB5 for ; Tue, 17 Feb 2015 14:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgoSXAZQj8gw for ; Tue, 17 Feb 2015 14:41:15 -0800 (PST) Received: from smtp116.ord1c.emailsrvr.com (smtp116.ord1c.emailsrvr.com [108.166.43.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051071A88CE for ; Tue, 17 Feb 2015 14:41:14 -0800 (PST) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 3BE24380498; Tue, 17 Feb 2015 17:41:14 -0500 (EST) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1C4023805EE; Tue, 17 Feb 2015 17:41:13 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Tue, 17 Feb 2015 22:41:14 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_D1343139-4706-424D-8622-2DF5A3D54EAA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> Date: Tue, 17 Feb 2015 17:41:12 -0500 Message-Id: <18B6C626-B27B-4EE9-A3E2-32CD43B195FA@ogud.com> References: <0DAFC2A8-A1E2-46F4-BA52-E8261CB09159@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 22:41:17 -0000 --Apple-Mail=_D1343139-4706-424D-8622-2DF5A3D54EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear wg members,=20 This is a belated summary of the WGLC (sorry my fault) The SRV document got number of good reviews and editors have updated the = document to reflect the comments received, version -11 should be final WG version and we plan to advance it to the = IESG.=20 SMTP document did not get as many reviews, only 3 that I can see Paul = Hoffman (no comments), Dan York (not a thorough review) and Sean Turner, who had number of comments. There github repository contains a version = of the document that addresses all the comments received.=20 Editors please post ASAP.=20 Chairs plan on advancing this document as well, but we would really like = if couple of people take a fresh look and tell us the document is as = ready as we think it is.=20 Both the SRV and SMTP document have a dependency relationship with -OPS = document thus we will start a WGLC on that document in the near future,=20= Olafur=20 > On Nov 12, 2014, at 11:09 PM, Olafur Gudmundsson = wrote: >=20 > Dear wg members >=20 > This email message starts a three week WGLC ending on December 4=92th = at 23:59 UTC.=20 >=20 > http://tools.ietf.org/wg/dane/draft-ietf-dane-srv = > and=20 > https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 = >=20 > These two document are specifying related uses of DANE.=20 > Please review the documents carefully, in particular we want to make = sure the documents have no=20 > contradictions.=20 >=20 > We need at least 5 members of the working group to state in public = that they have read the documents and=20 > state what is needed to fixed before the documents are advanced.=20 >=20 > I will act as document shepherd for these two documents.=20 >=20 > Olafur & Warren > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_D1343139-4706-424D-8622-2DF5A3D54EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear wg members, 

This is a belated summary of the WGLC  (sorry my = fault)
The SRV document got number of good reviews = and editors have updated the document to reflect the comments = received,
version -11 should be final WG version = and we plan to advance it to the IESG. 

SMTP document did not get as many = reviews, only 3 that I can see Paul Hoffman (no comments), Dan York (not = a thorough review) and Sean Turner,
who had number = of comments. There github repository contains a version of the document = that addresses all the comments received. 
Editors please post ASAP. 
Chairs = plan on advancing this document as well, but we would really like if = couple of people take a fresh look and tell us the document is as ready = as we think it is. 

Both the SRV and SMTP document have a dependency relationship = with -OPS document thus we will start a WGLC on that document in the = near future, 

   Olafur 

On Nov 12, 2014, at 11:09 PM, Olafur = Gudmundsson <ogud@ogud.com> wrote:

Dear wg members

This = email message starts a three week WGLC ending on December 4=92th at = 23:59 UTC. 

http://tools.ietf.org/wg/dane/draft-ietf-dane-srv
and 
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13

These two document are specifying = related uses of DANE. 
Please review the documents = carefully, in particular we want to make sure the documents have = no 
contradictions. 

We need at least 5 members of the working group to state in = public that they have read the documents and 
state = what is needed to fixed before the documents are advanced. 

I will act as document shepherd for these two = documents. 

Olafur & = Warren
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

= --Apple-Mail=_D1343139-4706-424D-8622-2DF5A3D54EAA-- From nobody Tue Feb 17 15:12:16 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17621A8884 for ; Tue, 17 Feb 2015 15:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGxrl4e4yUc8 for ; Tue, 17 Feb 2015 15:12:13 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CEF1A1AB5 for ; Tue, 17 Feb 2015 15:12:13 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 608FF282F4B; Tue, 17 Feb 2015 23:12:12 +0000 (UTC) Date: Tue, 17 Feb 2015 23:12:12 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150217231212.GT1260@mournblade.imrryr.org> References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:12:16 -0000 On Tue, Feb 17, 2015 at 05:01:33PM -0500, Olafur Gudmundsson wrote: > I section 3.1 you say in paragraph 2: > > For this specification to apply, the entire DNS RRset that is returned MUST be ?secure? ? > > Well the word entire is redundant if you are talking about single DNS RRset, > BUT I think there are missing words i.e. the sentence should be: > > For this specification to apply, the entire chain of DNS RRset(s) that is returned MUST be ?secure? ? > > If the second interpretation is right some minor word-smithing in paragraph 3 is also needed. Yes, if indeed there is a "chain" (of CNAME/DNAME RRs) leading from the query domain to the owner domain of the answer records then the entire chain must be "secure". IIRC this much is already said elsewhere in the draft. Note that with security-aware non-validating stub-resolvers that trust the AD-bit from a validating iterative resolver (presumably one to which they have a secure communications path) the "chain" issue is largely handled by that upstream resolver. The upstream resolver will return AD=0 if any link in the chain is insecure. With for non-validating security-aware stub resolvers the application need only worry about "chains" if multiple resolver queries are required to get from the query domain to the final answer (i.e. the iterative resolver returns one or more CNAME, but not the final answer, and the application has to retstart with the final CNAME). Thus, for example, Postfix has code to chase CNAMEs by asking the resolver multiple times, and in *that* case it makes sure that the final AD bit is the "AND" of the AD bits of all the replies received. That code is rarely exercised, since in practice most iterative resolvers do the CNAME chasing internally before returning multiple CNAME RRs and the final answer in a single response. This creates an interesting edge-case for testing whether individual MX hosts (or SRV target hosts) live in a signed zone (that's the purpose of the A/AAAA queries in the SRV and SMTP drafts that gate the applicability of TLSA lookups): ; example.com is a signed zone ; example.com. IN MX 0 mail.example.com. mail.example.com. IN CNAME mail.example.net. _25._tcp.mail.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ; example.net is an "insecure" zone: ; mail.example.net. IN A 192.0.2.1 When a query for the "A" records of "mail.example.com." is sent to a validating iterative resolver, the response has a CNAME RR, an "A" RR and AD=0. However the query domain is actually "secure", the reason for "AD=0" is that the CNAME points into an "insecure" zone. To accomodate this edge-case, when the A/AAAA record returns an insecure CNAME, Postfix sends a second query: mail.example.com. IN CNAME ? and if that yields "AD=1", TLSA records are still requested: _25._tcp.mail.example.com. IN TLSA ? and used if returned (with AD=1). Now this case is atypical, because with MX and SRV records the target host is supposed to never be a CNAME (though it is in a small fraction of cases). So this issue legitimately arises only for email domains that have no MX RRs and use just A records to publish the available SMTP server(s). Nevertheless many MTAs tolerate MX hostnames that are aliases. Therefore the SMTP draft in section 2.2.2 (which covers the A/AAAA record lookup rationale and processing logic) says: [ ... Cases for possible replies to A/AAAA queries ... ] Insecure CNAME: The input domain is a CNAME alias, but the ultimate network address RRset is "insecure" (see Section 2.1.1). If the initial CNAME response is also "insecure", DANE TLS does not apply. Otherwise, this case is treated just like the non-CNAME case above, where a search is performed for a TLSA record with the original input domain as the candidate TLSA base domain. This type of detail is how the SMTP draft go to be 33 pages, while the SRV draft is noticeably shorter. :-) -- Viktor. From nobody Tue Feb 17 15:46:22 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819BC1A8960 for ; Tue, 17 Feb 2015 15:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWE6_12dhBIZ for ; Tue, 17 Feb 2015 15:46:18 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC0E1A6F3F for ; Tue, 17 Feb 2015 15:46:18 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kmzN73c08z7T6 for ; Wed, 18 Feb 2015 00:46:15 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=kj3vuKIP; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YdNe_5eYFjJ9 for ; Wed, 18 Feb 2015 00:46:14 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 18 Feb 2015 00:46:14 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F255380416 for ; Tue, 17 Feb 2015 18:46:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424216774; bh=9nD/bdquo8B0KCscYajOvCbiY4z/GlaKcdD/WIcWMJE=; h=Date:From:To:Subject:In-Reply-To:References; b=kj3vuKIPsuEiR81giygSNqLOO6yYTXD7keihOSXUB6fG5xOzzqzjzUJr21/i3X73j L5ViS/OYkuLwVahZrCx64cTIVdTOTLTR3iF8hTV7vNVoOhlgVcM7c2zASW40yd9Nd+ 4oJGHh64E4UWO2VRDOuN266M0DR1XtJn7fD9meJM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1HNkD9l022460 for ; Tue, 17 Feb 2015 18:46:13 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 17 Feb 2015 18:46:13 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150217231212.GT1260@mournblade.imrryr.org> Message-ID: References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> <20150217231212.GT1260@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 23:46:20 -0000 On Tue, 17 Feb 2015, Viktor Dukhovni wrote: > This creates an interesting edge-case for testing whether individual > MX hosts (or SRV target hosts) live in a signed zone (that's the > purpose of the A/AAAA queries in the SRV and SMTP drafts that > gate the applicability of TLSA lookups): > > ; example.com is a signed zone > ; > example.com. IN MX 0 mail.example.com. > mail.example.com. IN CNAME mail.example.net. > _25._tcp.mail.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 > > > ; example.net is an "insecure" zone: > ; > mail.example.net. IN A 192.0.2.1 > > When a query for the "A" records of "mail.example.com." is > sent to a validating iterative resolver, the response has > a CNAME RR, an "A" RR and AD=0. However the query domain > is actually "secure", the reason for "AD=0" is that the CNAME > points into an "insecure" zone. > > To accomodate this edge-case, when the A/AAAA record returns > an insecure CNAME, Postfix sends a second query: > > mail.example.com. IN CNAME ? > > and if that yields "AD=1", TLSA records are still requested: > > _25._tcp.mail.example.com. IN TLSA ? > > and used if returned (with AD=1). Why does postfix care about the security of the A/CNAME results before asking for TLSA records? Why isn't it asking for TLSA records, and if those are secure, don't care about the AD bit for the A/AAAA/CNAME. As long as whatever insecure A/CNAME/AAAA address has the right certificate you were looking for. Paul From nobody Tue Feb 17 16:06:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3771A9109 for ; Tue, 17 Feb 2015 16:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZMEkxFm-kQf for ; Tue, 17 Feb 2015 16:06:31 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12531A9107 for ; Tue, 17 Feb 2015 16:06:31 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 3B450349598; Wed, 18 Feb 2015 00:06:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DA097160067; Wed, 18 Feb 2015 00:13:20 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id A4EB9160064; Wed, 18 Feb 2015 00:13:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1A3A429B21E6; Wed, 18 Feb 2015 11:06:21 +1100 (EST) To: Paul Wouters From: Mark Andrews References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> <20150217231212.GT1260@mournblade.imrryr.org> In-reply-to: Your message of "Tue, 17 Feb 2015 18:46:13 -0500." Date: Wed, 18 Feb 2015 11:06:20 +1100 Message-Id: <20150218000621.1A3A429B21E6@rock.dv.isc.org> Archived-At: Cc: dane@ietf.org Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 00:06:34 -0000 In message , Paul Wouters w rites: > On Tue, 17 Feb 2015, Viktor Dukhovni wrote: > > > This creates an interesting edge-case for testing whether individual > > MX hosts (or SRV target hosts) live in a signed zone (that's the > > purpose of the A/AAAA queries in the SRV and SMTP drafts that > > gate the applicability of TLSA lookups): > > > > ; example.com is a signed zone > > ; > > example.com. IN MX 0 mail.example.com. > > mail.example.com. IN CNAME mail.example.net. > > _25._tcp.mail.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb9 > 2427ae41e4649b934ca495991b7852b855 > > > > > > ; example.net is an "insecure" zone: > > ; > > mail.example.net. IN A 192.0.2.1 > > > > When a query for the "A" records of "mail.example.com." is > > sent to a validating iterative resolver, the response has > > a CNAME RR, an "A" RR and AD=0. However the query domain > > is actually "secure", the reason for "AD=0" is that the CNAME > > points into an "insecure" zone. > > > > To accomodate this edge-case, when the A/AAAA record returns > > an insecure CNAME, Postfix sends a second query: > > > > mail.example.com. IN CNAME ? > > > > and if that yields "AD=1", TLSA records are still requested: > > > > _25._tcp.mail.example.com. IN TLSA ? > > > > and used if returned (with AD=1). > > Why does postfix care about the security of the A/CNAME results before > asking for TLSA records? > > Why isn't it asking for TLSA records, and if those are secure, don't > care about the AD bit for the A/AAAA/CNAME. Because there are idiots that design nameservers, firewalls and scrubbing services that think asking for TLSA records is a good reason to drop the query. Looking at the result of the MX/A/AAAA query and using that to determine if the TLSA query should be performed reduces the number of queries that encounter such idiocy. MX/A/AAAA are rarely dropped. > As long as whatever insecure A/CNAME/AAAA address has the right > certificate you were looking for. > > Paul > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 17 16:18:47 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FD41A88A4 for ; Tue, 17 Feb 2015 16:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvo5A69cOW4G for ; Tue, 17 Feb 2015 16:18:44 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E43E1A8892 for ; Tue, 17 Feb 2015 16:18:44 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4BBFE282F4B; Wed, 18 Feb 2015 00:18:43 +0000 (UTC) Date: Wed, 18 Feb 2015 00:18:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150218001843.GV1260@mournblade.imrryr.org> References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> <20150217231212.GT1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 00:18:46 -0000 On Tue, Feb 17, 2015 at 06:46:13PM -0500, Paul Wouters wrote: > Why does postfix care about the security of the A/CNAME results before > asking for TLSA records? Because "nist.gov" would otherwise receive no email: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18665 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;nist.gov. IN MX nist.gov. MX 0 nist-gov.mail.protection.outlook.com. ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53098 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA The nameservers for the unsigned zone of nist.gov's MX hosts are allergic to TLSA queries. They return "NOTIMPL" instead of: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28627 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.nist-gov.mail.protection.outlook.com. IN A You can try it for yourself ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;mail.protection.outlook.com. IN NS mail.protection.outlook.com. NS ns1-proddns.glbdns.o365filtering.com. mail.protection.outlook.com. NS ns2-proddns.glbdns.o365filtering.com. $ dig +norecur +dnssec +noall +comment +qu -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 19776 ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: EDNS query returned status FORMERR - retry with '+nodnssec +noedns' $ dig +norecur +nodnssec +noedns +noall +comment -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365filtering.com. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 56709 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 This was discussed quite some time ago, and has been in the SMTP draft since. The domain "nist.gov" is not a comprehensive list of problem domains. The SMTP draft avoids sending queries for "exotic" RR-types to "minimal" nameservers that don't support DNSSEC. > Why isn't it asking for TLSA records, and if those are secure, don't > care about the AD bit for the A/AAAA/CNAME. Because those queries would all too often spuriously fail, and with "discovery" of TLS support (opportunistic DANE TLS), would lead to loss of connectivity, since the failures are indistinguishable from downgrade attacks. -- Viktor. From nobody Tue Feb 17 17:02:09 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E71A8BB0 for ; Tue, 17 Feb 2015 17:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZ7U6rLNgZNT for ; Tue, 17 Feb 2015 17:01:59 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021FD1A8945 for ; Tue, 17 Feb 2015 17:01:59 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 189931FCAD0 for ; Wed, 18 Feb 2015 01:01:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 375B2160067 for ; Wed, 18 Feb 2015 01:08:46 +0000 (UTC) Received: from rock.dv.isc.org (c122-106-252-81.belrs3.nsw.optusnet.com.au [122.106.252.81]) by zmx1.isc.org (Postfix) with ESMTPSA id C8683160064 for ; Wed, 18 Feb 2015 01:08:45 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B82CD29B5827 for ; Wed, 18 Feb 2015 12:01:44 +1100 (EST) To: dane@ietf.org From: Mark Andrews References: <20150216170123.GR1260@mournblade.imrryr.org> <54E22A70.8050705@cisco.com> <20150216180813.GT1260@mournblade.imrryr.org> <54E265A3.8040201@cisco.com> <1936971F-ED29-45AD-8683-E449DC9330F8@ogud.com> <20150217231212.GT1260@mournblade.imrryr.org> <20150218001843.GV1260@mournblade.imrryr.org> In-reply-to: Your message of "Wed, 18 Feb 2015 00:18:43 -0000." <20150218001843.GV1260@mournblade.imrryr.org> Date: Wed, 18 Feb 2015 12:01:43 +1100 Message-Id: <20150218010144.B82CD29B5827@rock.dv.isc.org> Archived-At: Subject: Re: [dane] srv-09 comments X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 01:02:06 -0000 See also https://tools.ietf.org/html/draft-andrews-dns-no-response-issue-07 6. Response Code Selection Choosing the correct response code when fixing a nameserver is important. Just because a type is not implemented does not mean that NOTIMP is the correct response code to return. Response codes need to be chosen considering how clients will handle them. For unimplemented opcodes NOTIMP is the expected response code. In general, for unimplemented type codes Name Error (NXDOMAIN) and NOERROR (no data) are the expected response codes. A server is not supposed to serve a zone which contains unsupported types ([RFC1034]) so the only thing left is return if the QNAME exists or not. NOTIMP and REFUSED are not useful responses as they force the clients to try all the authoritative servers for a zone looking for a server which will answer the query. Meta queries type may be the exception but these need to be thought about on a case by case basis. If you support EDNS and get a query with a unsupported EDNS version the correct response is BADVERS [RFC6891]. If you do not support EDNS at all FORMERR and NOTIMP are the expected error codes. That said a minimal EDNS server implementation just requires parsing the OPT records and responding with a empty OPT record. There is no need to interpret any EDNS options present in the request as unsupported options are expected to be ignored [RFC6891]. In message <20150218001843.GV1260@mournblade.imrryr.org>, Viktor Dukhovni writes: > On Tue, Feb 17, 2015 at 06:46:13PM -0500, Paul Wouters wrote: > > > Why does postfix care about the security of the A/CNAME results before > > asking for TLSA records? > > Because "nist.gov" would otherwise receive no email: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18665 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ;nist.gov. IN MX > nist.gov. MX 0 nist-gov.mail.protection.outlook.com. > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53098 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;_25._tcp.nist-gov.mail.protection.outlook.com. IN TLSA > > The nameservers for the unsigned zone of nist.gov's MX hosts are > allergic to TLSA queries. They return "NOTIMPL" instead of: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28627 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;_25._tcp.nist-gov.mail.protection.outlook.com. IN A > > You can try it for yourself > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37877 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ;mail.protection.outlook.com. IN NS > mail.protection.outlook.com. NS ns1-proddns.glbdns.o365filtering.com. > mail.protection.outlook.com. NS ns2-proddns.glbdns.o365filtering.com. > > $ dig +norecur +dnssec +noall +comment +qu -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdns.o365 > filtering.com. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 19776 > ;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; WARNING: EDNS query returned status FORMERR - retry with '+nodnssec +noedns' > > $ dig +norecur +nodnssec +noedns +noall +comment -t tlsa _25._tcp.nist-gov.mail.protection.outlook.com. @ns1-proddns.glbdn > s.o365filtering.com. > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 56709 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > This was discussed quite some time ago, and has been in the SMTP > draft since. The domain "nist.gov" is not a comprehensive list of > problem domains. The SMTP draft avoids sending queries for "exotic" > RR-types to "minimal" nameservers that don't support DNSSEC. > > > Why isn't it asking for TLSA records, and if those are secure, don't > > care about the AD bit for the A/AAAA/CNAME. > > Because those queries would all too often spuriously fail, and with > "discovery" of TLS support (opportunistic DANE TLS), would lead to > loss of connectivity, since the failures are indistinguishable from > downgrade attacks. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Feb 20 10:15:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA691A0068; Fri, 20 Feb 2015 10:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZhxyh3Kff4N; Fri, 20 Feb 2015 10:15:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A51D1A039F; Fri, 20 Feb 2015 10:15:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220181520.16696.67016.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:15:20 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-08.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:15:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-08.txt Pages : 7 Date : 2015-02-20 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smime-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 20 12:30:15 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504A21A0060 for ; Fri, 20 Feb 2015 12:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIRoTC8NZkPA for ; Fri, 20 Feb 2015 12:30:10 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8351A0006 for ; Fri, 20 Feb 2015 12:30:07 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id z12so15339939wgg.2 for ; Fri, 20 Feb 2015 12:30:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1eqOBZ5VJ9zywlVYK3QDWhdx+W+l5obAZqLvlnr3Clw=; b=RQ6mUXTQU0afCWe4FkyVSmyTYn7ljBn8Pw31ghCraIx61Dji4lsGooqgKV0PftG+Z4 lhEkt4oS3V1M7l+MtqGbXatu+QlRDOwYYT775XXI2Et2xcyGItRa2o3ftBttPw+NMVQk 6KFZI0fpvL6cR1heWAdwSia/LDYTUC3vq/Uwvh8QG0FOA4+HytOyFrJ0pGkjZTmDZWjb KN8RqkVrrz0MoViJbABmOJwvCYFHH5QpEKtUM/7QJfRx/k1ivTxpo0AnxJxQSaNlzpsb Xo4JUgV4czuy5EwRmaK5kt2S07XGmFnRvWoDk/NaEAanPLI9kr49BjZ0MpAwwBFtMzSg wM1g== X-Gm-Message-State: ALoCoQlzzqsW4+qzrh4SmDkzbBIVtS33ZUAPWXVtNNbrC6iaKRf6IMFHoHIfgHRm49ShQwLSRha7 MIME-Version: 1.0 X-Received: by 10.194.63.16 with SMTP id c16mr22462842wjs.117.1424464205890; Fri, 20 Feb 2015 12:30:05 -0800 (PST) Received: by 10.194.158.229 with HTTP; Fri, 20 Feb 2015 12:30:05 -0800 (PST) Date: Fri, 20 Feb 2015 15:30:05 -0500 Message-ID: From: Warren Kumari To: "" , draft-ietf-dane-openpgpkey@tools.ietf.org, DANE-chairs Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 20:30:13 -0000 Dear DANE WG, The author of draft-ietf-dane-openpgpkey has indicated that he believes that the document is ready for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ This document has been discussed a number of times, to jog your memory, here is one slidedeck: http://www.ietf.org/proceedings/89/slides/slides-89-dane-2.pdf Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/ .*$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p | gpg --import --dry-run Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This WGLC ends Fri 06-Mar-2015. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-dane-openpgpkey? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as DANE WG co-chair) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Feb 20 13:48:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69C21A0127; Fri, 20 Feb 2015 13:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzgOP_9iYHX5; Fri, 20 Feb 2015 13:48:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 137E21A8828; Fri, 20 Feb 2015 13:48:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220214825.11512.30311.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 13:48:25 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-14.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:48:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-14.txt Pages : 33 Date : 2015-02-20 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 20 14:09:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6761A01BA for ; Fri, 20 Feb 2015 14:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.485 X-Spam-Level: * X-Spam-Status: No, score=1.485 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FAKE_REPLY_C=1.486] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reqH78HPzZ4W for ; Fri, 20 Feb 2015 14:09:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7EC1A024C for ; Fri, 20 Feb 2015 14:09:22 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DBE98282D5F; Fri, 20 Feb 2015 22:09:21 +0000 (UTC) Date: Fri, 20 Feb 2015 22:09:21 +0000 From: Viktor Dukhovni To: "" Message-ID: <20150220220921.GH1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141209095813.GP285@mournblade.imrryr.org> <20150108011529.GU7322@mournblade.imrryr.org> <18B6C626-B27B-4EE9-A3E2-32CD43B195FA@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 22:09:30 -0000 On Tue, Feb 17, 2015 at 05:41:12PM -0500, Olafur Gudmundsson wrote: > The SRV document got number of good reviews and editors have updated the > document to reflect the comments received, version -11 should be final WG > version and we plan to advance it to the IESG. Great, thanks! > SMTP document did not get as many reviews, only 3 that I can see Paul > Hoffman (no comments), Dan York (not a thorough review) and Sean Turner, > who had number of comments. Perhaps some folks [hint, hint] can return the favour and review the SMTP draft in full. :-) > The github repository contains a version of the document that addresses > all the comments received. Editors please post ASAP. A -14 version has been pushed. I've not yet received any feedback on the possibility of extending the operational considerations section based on the last few months of operational experience. Please advise... On Thu, Jan 08, 2015 at 01:15:29AM +0000, Viktor Dukhovni wrote: > [...] > > I did ask a question during LC: > > http://www.ietf.org/mail-archive/web/dane/current/msg07159.html > > ... > > One deployment pitfall discovered in recent interoperability tests > is that some domains have cleartext-only anti-spam proxies in front > of their MTA, with the proxies only allowing connections to the > real MTA once the SMTP client passes a grey-listing check (this > was observed with "spamd" as the proxy, but any "selective access" > to TLS can be similarly problematic). > > If the receiving domain publishes TLSA records, this creates a > catch-22 with DANE-aware client MTAs. The DANE client never begins > the first mail transaction, because the proxy does not offer > STARTTLS, (the proxy is a receiving system deployed downgrade to > cleartext MiTM in front of the real MTA). > > The short-term solution for such domains is to NOT publish TLSA > RRs for port 25. Longer-term the anti-spam proxy should be upgraded > to support STARTTLS. For example, the Postfix "postscreen" service, > which has functionality similar to "spamd", supports STARTTLS so that > grey-listing does not amount to a similar downgrade attack. > > I'd like to add some language about avoiding this problem in the > operational considerations section of the smtp-with-dane draft. > Any objections? > > Additional operational considerations might include not forgetting > to update TLSA RRs for *all* the names under which a server might > be known when doing key rotation. This is a problem particularly > when a single wild-card certificate is deployed on all the MX hosts, > and replaced concurrently on them all, creating an immediate outage > for any domains that use variant MX host names (for flexibility of > later hosting some domains separately). With DANE one should > strongly consider per-server certificates to avoid synchronized > multi-MTA outages. > > And lastly, by far the most common problems are with DNSSEC. A > mixture of failure to perform timely re-signing and at present lots > of domains with nameservers that have non-working Denial of Existence. > I don't have a comprehensive list of software that is deficient in > this manner, but it seems that some older versions of PowerDNS > botch DoE in at least some configurations. Similar issues reportedly > with djbdns DNSSEC patches. A few domains have firewalls that > block TLSA queries, one blocked these only for IPv4 clients, with > IPv6 clients not filtered, that can create difficult to diagnose > problems. > > So I am looking for guidance on how much *current* operational > experience to include in the draft that may ultimately become > irrelevant as the infrastructure improves, but may be very useful > to get us past the initial deployment hurdles. If we don't get > early adopters past the initial problems, the long-term obsolescence > of the issues might remain forever in the future. > > Any feedback on that would be appreciated, plus guidance on *when* to > make any such changes. -- Viktor. From nobody Fri Feb 20 14:13:11 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DEF1A891A for ; Fri, 20 Feb 2015 14:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-ATKafpc6GS for ; Fri, 20 Feb 2015 14:13:03 -0800 (PST) Received: from smtp92.ord1c.emailsrvr.com (smtp92.ord1c.emailsrvr.com [108.166.43.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FE01A8924 for ; Fri, 20 Feb 2015 14:13:03 -0800 (PST) Received: from smtp12.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp12.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BC9BF38077A for ; Fri, 20 Feb 2015 17:13:02 -0500 (EST) Received: by smtp12.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 46C4A380887 for ; Fri, 20 Feb 2015 17:13:02 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 20 Feb 2015 22:13:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <20150220220921.GH1260@mournblade.imrryr.org> Date: Fri, 20 Feb 2015 17:13:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com> References: <20150220220921.GH1260@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 22:13:10 -0000 Dear colleagues=20 please take a few minutes to review this document if you have not done = so yet. This is a critical document from the working group and the chairs rather want = the WG to find any issues then in IETF last call.=20 We plan to start a WGLC on the related OPS document RSN and will live = with cross references between the documents as they will all be published at the same time=20 Olafur > On Feb 20, 2015, at 5:09 PM, Viktor Dukhovni = wrote: >=20 > On Tue, Feb 17, 2015 at 05:41:12PM -0500, Olafur Gudmundsson wrote: >=20 >> The SRV document got number of good reviews and editors have updated = the >> document to reflect the comments received, version -11 should be = final WG >> version and we plan to advance it to the IESG. >=20 > Great, thanks! >=20 >> SMTP document did not get as many reviews, only 3 that I can see Paul >> Hoffman (no comments), Dan York (not a thorough review) and Sean = Turner, >> who had number of comments. >=20 > Perhaps some folks [hint, hint] can return the favour and review > the SMTP draft in full. :-) >=20 >> The github repository contains a version of the document that = addresses >> all the comments received. Editors please post ASAP. >=20 > A -14 version has been pushed. I've not yet received any feedback on > the possibility of extending the operational considerations section > based on the last few months of operational experience. Please > advise... >=20 > On Thu, Jan 08, 2015 at 01:15:29AM +0000, Viktor Dukhovni wrote: >=20 >> [...] >>=20 >> I did ask a question during LC: >>=20 >> http://www.ietf.org/mail-archive/web/dane/current/msg07159.html >>=20 >> ... >>=20 >> One deployment pitfall discovered in recent interoperability tests >> is that some domains have cleartext-only anti-spam proxies in = front >> of their MTA, with the proxies only allowing connections to the >> real MTA once the SMTP client passes a grey-listing check (this >> was observed with "spamd" as the proxy, but any "selective access" >> to TLS can be similarly problematic). >>=20 >> If the receiving domain publishes TLSA records, this creates a >> catch-22 with DANE-aware client MTAs. The DANE client never = begins >> the first mail transaction, because the proxy does not offer >> STARTTLS, (the proxy is a receiving system deployed downgrade to >> cleartext MiTM in front of the real MTA). >>=20 >> The short-term solution for such domains is to NOT publish TLSA >> RRs for port 25. Longer-term the anti-spam proxy should be = upgraded >> to support STARTTLS. For example, the Postfix "postscreen" = service, >> which has functionality similar to "spamd", supports STARTTLS so = that >> grey-listing does not amount to a similar downgrade attack. >>=20 >> I'd like to add some language about avoiding this problem in the >> operational considerations section of the smtp-with-dane draft. >> Any objections? =20 >>=20 >> Additional operational considerations might include not forgetting >> to update TLSA RRs for *all* the names under which a server might >> be known when doing key rotation. This is a problem particularly >> when a single wild-card certificate is deployed on all the MX = hosts, >> and replaced concurrently on them all, creating an immediate = outage >> for any domains that use variant MX host names (for flexibility of >> later hosting some domains separately). With DANE one should >> strongly consider per-server certificates to avoid synchronized >> multi-MTA outages. >>=20 >> And lastly, by far the most common problems are with DNSSEC. A >> mixture of failure to perform timely re-signing and at present = lots >> of domains with nameservers that have non-working Denial of = Existence. >> I don't have a comprehensive list of software that is deficient in >> this manner, but it seems that some older versions of PowerDNS >> botch DoE in at least some configurations. Similar issues = reportedly >> with djbdns DNSSEC patches. A few domains have firewalls that >> block TLSA queries, one blocked these only for IPv4 clients, with >> IPv6 clients not filtered, that can create difficult to diagnose >> problems. >>=20 >> So I am looking for guidance on how much *current* operational >> experience to include in the draft that may ultimately become >> irrelevant as the infrastructure improves, but may be very useful >> to get us past the initial deployment hurdles. If we don't get >> early adopters past the initial problems, the long-term = obsolescence >> of the issues might remain forever in the future. >>=20 >> Any feedback on that would be appreciated, plus guidance on *when* to >> make any such changes. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Feb 20 16:04:23 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAA11A0367 for ; Fri, 20 Feb 2015 16:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjWVFC8wt87q for ; Fri, 20 Feb 2015 16:04:20 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D201A017D for ; Fri, 20 Feb 2015 16:04:20 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 7EEC91E75C; Sat, 21 Feb 2015 00:04:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1424477059; bh=IeKePUM0pOw0T8EQmv4x1X/EyhDVIRTRjn931X7AcwI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UB2+boefmN2cKiecZVdtgQcHG26bV+pp2iepLplw3R7Zk25xNgLc0uyLW+4eK+IVY K/WuOC7tOUKkhXwuRp4AErMJRYahMPEf8B9Y9Qog0KRmehKVGlVcbOfcbrM0ryR6Zg oT3sy31ep3EpzDAgvJ/q5kxaK+qfRY2CedpQaW/E= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7689C106F92D6; Sat, 21 Feb 2015 00:03:04 +0000 (UTC) From: James Cloos To: In-Reply-To: (Warren Kumari's message of "Fri, 20 Feb 2015 15:30:05 -0500") References: User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 20 Feb 2015 19:03:04 -0500 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150221:dane@ietf.org::seH57680ydQ9qEgm:000BR33b X-Hashcash: 1:28:150221:warren@kumari.net::3mx4WPm1xWePV+OM:0000000000000000000000000000000000000000000G0y3L Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 00:04:21 -0000 >>>>> "WK" == Warren Kumari writes: WK> Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/ WK> ..$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed WK> "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p WK> | gpg --import --dry-run FWIW, that does not work here. Bash adds a space after the $(), so one has to do: dig type61 $(printf %s._openpgpkey.fedoraproject.org. \ $(printf pwouters | sha224sum | sed 's/..$//' )) \ | grep TYPE61 | sed 's/^.*TYPE61.*\\\#[0-9]* //' \ | grep -v ';' | sed 's/ //g' | xxd -r -p | gpg --import --dry-run but gpg (2.0) does not like that binary data. Replacing --import --dry-run with --list-packets does not do any better. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Feb 20 16:34:45 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975A61A044F for ; Fri, 20 Feb 2015 16:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeKmZ4Wv9o9f for ; Fri, 20 Feb 2015 16:34:41 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AF41A0439 for ; Fri, 20 Feb 2015 16:34:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9149A282D5F; Sat, 21 Feb 2015 00:34:39 +0000 (UTC) Date: Sat, 21 Feb 2015 00:34:39 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150221003439.GM1260@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 00:34:43 -0000 On Fri, Feb 20, 2015 at 07:03:04PM -0500, James Cloos wrote: > >>>>> "WK" == Warren Kumari writes: > > WK> Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/ > WK> ..$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed > WK> "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p > WK> | gpg --import --dry-run > > FWIW, that does not work here. What works for me is: $ dig +short -t type61 $( printf "%s._openpgpkey.fedoraproject.org" $( printf "%s" pwouters | openssl dgst -sha224 -binary | hexdump -ve '/1 "%02x"' ) ) | perl -ane ' ($escape_sharp, $len) = splice(@F, 0, 2); next if ($escape_sharp ne q{\#}); ($rdata = join("", @F)) =~ s/(..)/chr(hex($1))/eg; next if (length($rdata) != $len); print $rdata; last; ' | gpg --import --dry-run --verbose gpg: pub 4096R/E0FD94D2 2014-12-11 Paul Wouters gpg: using classic trust model gpg: key E0FD94D2: public key "[User ID not found]" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) Of course this ignores the DNSSEC validation status. A better approach is to do it all in Perl with Net::DNS and either trusted (AD-bit) local resolver, or DNSSEC validation support in Net::DNS. Python with the getdns api is another attractive option. -- Viktor. From nobody Fri Feb 20 16:46:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1431A066C for ; Fri, 20 Feb 2015 16:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYtl6jbHvty1 for ; Fri, 20 Feb 2015 16:45:59 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6075C1A049A for ; Fri, 20 Feb 2015 16:45:59 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kprYc3kx4zDXB for ; Sat, 21 Feb 2015 01:45:56 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=GwwS0dMB; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id IAj_Q7RmQ-_i for ; Sat, 21 Feb 2015 01:45:55 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 21 Feb 2015 01:45:55 +0100 (CET) Received: from [10.0.0.55] (c-24-4-36-84.hsd1.ca.comcast.net [24.4.36.84]) by bofh.nohats.ca (Postfix) with ESMTPSA id 0B91482A1E for ; Fri, 20 Feb 2015 19:45:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424479554; bh=k50DSWC3K2T60Jjlnu+vB2HdHv9WA+fFhQrekefoOM8=; h=Subject:References:From:In-Reply-To:Date:To; b=GwwS0dMB59jtCM75vyJ2YGe4RhjSaEJsxjpw7Pv22XCp1foWfpDwWuJeVWVovWei+ u0/S9pbm9NZM40SI01kYYeR4VDwXBS+pOuJ3EH50u2q2ycpMQPhOUMKEMgSL1CKOYN che116yjC8xU0ORubtgljEkYGqSECbJa68cyynR4= References: <20150221003439.GM1260@mournblade.imrryr.org> From: Paul Wouters Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (12B466) In-Reply-To: <20150221003439.GM1260@mournblade.imrryr.org> Message-Id: <46D64B78-4EBA-48C1-BEB1-27E3B9386DCA@nohats.ca> Date: Fri, 20 Feb 2015 16:45:52 -0800 To: "dane@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 00:46:02 -0000 What works for me is: $ sudo yum | apt-get install hash-slinger $ openpgpkey --fetch pwouters@fedoraproject.org :) Sent from my iPhone > On Feb 20, 2015, at 16:34, Viktor Dukhovni wrote: > > On Fri, Feb 20, 2015 at 07:03:04PM -0500, James Cloos wrote: > >>>>>>> "WK" == Warren Kumari writes: >> >> WK> Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/ >> WK> ..$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed >> WK> "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p >> WK> | gpg --import --dry-run >> >> FWIW, that does not work here. > > What works for me is: > > $ dig +short -t type61 $( > printf "%s._openpgpkey.fedoraproject.org" $( > printf "%s" pwouters | > openssl dgst -sha224 -binary | > hexdump -ve '/1 "%02x"' > ) > ) | > perl -ane ' > ($escape_sharp, $len) = splice(@F, 0, 2); > next if ($escape_sharp ne q{\#}); > ($rdata = join("", @F)) =~ s/(..)/chr(hex($1))/eg; > next if (length($rdata) != $len); > print $rdata; > last; > ' | > gpg --import --dry-run --verbose > gpg: pub 4096R/E0FD94D2 2014-12-11 Paul Wouters > gpg: using classic trust model > gpg: key E0FD94D2: public key "[User ID not found]" imported > gpg: Total number processed: 1 > gpg: imported: 1 (RSA: 1) > > Of course this ignores the DNSSEC validation status. A better > approach is to do it all in Perl with Net::DNS and either trusted > (AD-bit) local resolver, or DNSSEC validation support in Net::DNS. > > Python with the getdns api is another attractive option. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Fri Feb 20 18:23:36 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72BF1A19E3 for ; Fri, 20 Feb 2015 18:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB5X8Je6jI5l for ; Fri, 20 Feb 2015 18:23:32 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF0A1A005D for ; Fri, 20 Feb 2015 18:23:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 023FE282D5F; Sat, 21 Feb 2015 02:23:31 +0000 (UTC) Date: Sat, 21 Feb 2015 02:23:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150221022330.GN1260@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 02:23:34 -0000 On Fri, Feb 20, 2015 at 03:30:05PM -0500, Warren Kumari wrote: > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. Comments: * The below does not mention the hex encoding of the digest. Compare with SMIMEA: OPENPGPKEY: 3. Location of the OpenPGPKEY record Email addresses are mapped into DNS using the following method: 1. The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC2822] and the "local part" in the specification for internationalized email [RFC6530]), is hashed using the SHA2-224 [RFC5754] algorithm to become the left-most label in the prepared domain name. This does not include the at symbol ("@") that separates the left and right sides of the email address. SMIMEA: The user name (the "left-hand side" of the email address, called the "local-part" in the mail message format definition [RFC2822] and the "local part" in the specification for internationalized email [RFC6530]), is hashed using the SHA2-224 [RFC5754] algorithm (with the hash being represented in its hexadecimal representation, to become the left-most label in the prepared domain name. This does not include the "@" character that separates the left and right sides of the email address. The string that is used for the local part is a Unicode string encoded in UTF-8. * Grammar nit replace "its" with "their" or rephrase: 5.1. Email address information leak Email addresses are not secret. Using them causes its publication. * Forward security vouching for long-term keys There's a typo in the first word of the highlighted paragraph: 5.2. Forward security of OpenPGP versus DNSSEC [...] Therefor, an OpenPGP key obtained via an OPENPGPKEY record can only be trusted as much as the DNS domain can be trusted, and are no substitute for in-person key verification of the "Web of Trust". See [OPENPGPKEY-USAGE] for more in-depth information on safe usage of OPENPGPKEY based OpenPGP keys. An complementary approach is to not use the retrieved OpenPGP key beyond the signature lifetime of the OPENPGPKEY RRset RRSIG record. Keys obtained from DNS should be refreshed as often as is practical (ideally before encrypting each message) and never used beyond the RRSIG lifetime. Were the RRSIG in question signed by an attacker, only messages signed before the key is refreshed are compromised. Of course this requires that PGP user agent software track the provenance and cache lifetime of keys obtained via DNS. * Encoding tools: Appendix A. Generating OPENPGPKEY records gpg --export --export-options export-minimal \ hugh@example.com | base64 the "openssl base64" command is an alternative on many other platforms. Later the examples don't yet use the newly allocated TYPE61: These values can then be used to generate a generic record (line break has been added for formatting): ._openpgpkey.example.com. IN TYPE65280 \# \ ... ~> openpgpkey --output generic hugh@example.com 8d[...]b7._openpgpkey.example.com. IN TYPE65280 \# 2313 99008d03[...] the type should of course now be TYPE61. May as well give a recipe for generating "SHA2-224(hugh)": printf "%s" hugh | openssl dgst -sha224 -binary | hexdump -ve '/1 "%.2x"' -e '/28 "\n"' -- Viktor. From nobody Fri Feb 20 21:19:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C017A1A1AFE for ; Fri, 20 Feb 2015 21:19:08 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgmy-kF6AB9i for ; Fri, 20 Feb 2015 21:19:06 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D6B1A1AF9 for ; Fri, 20 Feb 2015 21:19:06 -0800 (PST) Received: by iecar1 with SMTP id ar1so12818867iec.0 for ; Fri, 20 Feb 2015 21:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mEQy0CZzxiuMXHJZB75z9lI6DrNNzD0X13rnU0UMb1E=; b=HDNgjuxEgjl+qZpOdfy5MzYvgvfnuTGfbwO8ZgDsejugWdooCfFnMohIrzRu4O5wgG AIK8rLV3N1sRFlswP1ersF/JtFaHcOB4+OiDTgd0ZgC9kQXdolbEA1pHNUllL1zkpb3L bIrnillRMpZlvUHZO0VrLNIQmwKTKucxRaqe+g35JweR3wqSgO+4kMX+kQiOjXBkjH/+ rV+xwPZOIm7I/qfgdMVH5NKOd3lH8b15LVvieTMxCtUonldnw4iFIx8cwQWXg/POyYlm Qkpb0F61yzLR6ZQlbWqrjvvmvAd5SzVpINAO23oQ96Bp47oyWgA6BV7AK923Pw8xUejl +Wsw== MIME-Version: 1.0 X-Received: by 10.42.222.68 with SMTP id if4mr1430902icb.45.1424495945422; Fri, 20 Feb 2015 21:19:05 -0800 (PST) Received: by 10.64.80.193 with HTTP; Fri, 20 Feb 2015 21:19:05 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 21:19:05 -0800 Message-ID: From: Brian Dickson To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1133212ecfa19c050f924e35 Archived-At: Cc: draft-ietf-dane-openpgpkey@tools.ietf.org, DANE-chairs , "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 05:19:08 -0000 --001a1133212ecfa19c050f924e35 Content-Type: text/plain; charset=UTF-8 I have read the document. Modulo any other minor comments from other reviewers, I think it is a fine document, and should be published. Extremely minor comment: In section 5.1, about email leaks, it may be worth additionally mentioning: Use of distinct SALT values can further limit brute force efforts, even where the same key is used. Brian On Fri, Feb 20, 2015 at 12:30 PM, Warren Kumari wrote: > Dear DANE WG, > > The author of draft-ietf-dane-openpgpkey has indicated that he > believes that the document is ready for Working Group Last Call. > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ > > This document has been discussed a number of times, to jog your > memory, here is one slidedeck: > http://www.ietf.org/proceedings/89/slides/slides-89-dane-2.pdf > Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/ > .*$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed > "s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "s/ //g" | xxd -r -p > | gpg --import --dry-run > > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This WGLC ends Fri 06-Mar-2015. > > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-dane-openpgpkey? If so, has this IPR been disclosed in > compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 > for more details.) > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a1133212ecfa19c050f924e35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read the document. Modulo any other minor comments = from other reviewers, I think it is a fine document, and should be publishe= d.

Extremely minor comment:
In section 5.1, ab= out email leaks, it may be worth additionally mentioning:
Use of = distinct SALT values can further limit brute force efforts, even where the = same key is used.

Brian

On Fri, Feb 20, 2015 at 12:30 PM= , Warren Kumari <warren@kumari.net> wrote:
Dear DANE WG,

The author of draft-ietf-dane-openpgpkey has indicated that he
believes that the document is ready for Working Group Last Call.
The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey= /

This document has been discussed a number of times, to jog your
memory, here is one slidedeck:
http://www.ietf.org/proceedings/89/slides/slides-89-dane-= 2.pdf
Also, a cute trick: dig type61 $(echo -n pwouters| sha224sum | sed "s/=
.*$//")._openpgpkey.fedoraproject.org |grep TYPE61 | sed
"s/^.*TYPE61.*\\\#[0-9]* //" | grep -v ";" | sed "= s/ //g" | xxd -r -p
| gpg --import --dry-run


Please review this draft to see if you think it is ready for
publication and send comments to the list, clearly stating your view.

This WGLC ends Fri 06-Mar-2015.



In addition, to satisfy RFC 6702 ("Promoting Compliance with
Intellectual Property Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dane-openpgpkey?=C2=A0 If so, has this IPR been disclosed in
compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
for more details.)

Thanks,
Warren Kumari
(as DANE WG co-chair)

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--001a1133212ecfa19c050f924e35-- From nobody Fri Feb 20 21:32:33 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28211A1B11 for ; Fri, 20 Feb 2015 21:32:31 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nBm63ytmP9f for ; Fri, 20 Feb 2015 21:32:28 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783BA1A1B0D for ; Fri, 20 Feb 2015 21:32:28 -0800 (PST) Received: by iecar1 with SMTP id ar1so12854603iec.0 for ; Fri, 20 Feb 2015 21:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uzByvynnQgCFa6dRJYzHlgm4oDXWi3URGbKwWD17388=; b=h7YPTkmUYu3ML20dQCXwZygEjPR481kp8bSOFiS6mz+9tjRFi/su3d3fts1c25K3ZN vMt+4jt/qVjioMhotLXkdnzv1PnjZdDC5njSRzexwPo8gkYHC5NuoZoDF8IUn7E/p9jM 9tAqrQBmNStriUYYK9w7zO8iT+4UbTrQwrtwl48IOACqrcxyna7wc2zxjBkG2VkllBy1 URN01l0Vjw+rvvvjZ1lAipZbQ8kvRj8y0oabkKC8LAAwStjKQ59zwEcRJoEqxxR17Woc 6VudY2eQjy2lVbb094YqJJ6QiQwFKQdbpolHrIwA3c+irMEwyzEFJsjq5D6YaksaAE8n Vqnw== MIME-Version: 1.0 X-Received: by 10.50.32.7 with SMTP id e7mr989266igi.21.1424496747465; Fri, 20 Feb 2015 21:32:27 -0800 (PST) Received: by 10.64.80.193 with HTTP; Fri, 20 Feb 2015 21:32:27 -0800 (PST) In-Reply-To: <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com> References: <20150220220921.GH1260@mournblade.imrryr.org> <98BDCF0E-88CD-4392-9194-DABB8AA62532@ogud.com> Date: Fri, 20 Feb 2015 21:32:27 -0800 Message-ID: From: Brian Dickson To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=047d7b10cbf19dd5fa050f927e74 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 05:32:31 -0000 --047d7b10cbf19dd5fa050f927e74 Content-Type: text/plain; charset=UTF-8 I have read the documents, and do not see any glaring problems. I support publishing them. Brian On Fri, Feb 20, 2015 at 2:13 PM, Olafur Gudmundsson wrote: > Dear colleagues > please take a few minutes to review this document if you have not done so > yet. This > is a critical document from the working group and the chairs rather want > the WG to find any > issues then in IETF last call. > > We plan to start a WGLC on the related OPS document RSN and will live with > cross references between the > documents as they will all be published at the same time > > Olafur > > > On Feb 20, 2015, at 5:09 PM, Viktor Dukhovni > wrote: > > > > On Tue, Feb 17, 2015 at 05:41:12PM -0500, Olafur Gudmundsson wrote: > > > >> The SRV document got number of good reviews and editors have updated the > >> document to reflect the comments received, version -11 should be final > WG > >> version and we plan to advance it to the IESG. > > > > Great, thanks! > > > >> SMTP document did not get as many reviews, only 3 that I can see Paul > >> Hoffman (no comments), Dan York (not a thorough review) and Sean Turner, > >> who had number of comments. > > > > Perhaps some folks [hint, hint] can return the favour and review > > the SMTP draft in full. :-) > > > >> The github repository contains a version of the document that addresses > >> all the comments received. Editors please post ASAP. > > > > A -14 version has been pushed. I've not yet received any feedback on > > the possibility of extending the operational considerations section > > based on the last few months of operational experience. Please > > advise... > > > > On Thu, Jan 08, 2015 at 01:15:29AM +0000, Viktor Dukhovni wrote: > > > >> [...] > >> > >> I did ask a question during LC: > >> > >> http://www.ietf.org/mail-archive/web/dane/current/msg07159.html > >> > >> ... > >> > >> One deployment pitfall discovered in recent interoperability tests > >> is that some domains have cleartext-only anti-spam proxies in front > >> of their MTA, with the proxies only allowing connections to the > >> real MTA once the SMTP client passes a grey-listing check (this > >> was observed with "spamd" as the proxy, but any "selective access" > >> to TLS can be similarly problematic). > >> > >> If the receiving domain publishes TLSA records, this creates a > >> catch-22 with DANE-aware client MTAs. The DANE client never begins > >> the first mail transaction, because the proxy does not offer > >> STARTTLS, (the proxy is a receiving system deployed downgrade to > >> cleartext MiTM in front of the real MTA). > >> > >> The short-term solution for such domains is to NOT publish TLSA > >> RRs for port 25. Longer-term the anti-spam proxy should be upgraded > >> to support STARTTLS. For example, the Postfix "postscreen" service, > >> which has functionality similar to "spamd", supports STARTTLS so that > >> grey-listing does not amount to a similar downgrade attack. > >> > >> I'd like to add some language about avoiding this problem in the > >> operational considerations section of the smtp-with-dane draft. > >> Any objections? > >> > >> Additional operational considerations might include not forgetting > >> to update TLSA RRs for *all* the names under which a server might > >> be known when doing key rotation. This is a problem particularly > >> when a single wild-card certificate is deployed on all the MX hosts, > >> and replaced concurrently on them all, creating an immediate outage > >> for any domains that use variant MX host names (for flexibility of > >> later hosting some domains separately). With DANE one should > >> strongly consider per-server certificates to avoid synchronized > >> multi-MTA outages. > >> > >> And lastly, by far the most common problems are with DNSSEC. A > >> mixture of failure to perform timely re-signing and at present lots > >> of domains with nameservers that have non-working Denial of > Existence. > >> I don't have a comprehensive list of software that is deficient in > >> this manner, but it seems that some older versions of PowerDNS > >> botch DoE in at least some configurations. Similar issues reportedly > >> with djbdns DNSSEC patches. A few domains have firewalls that > >> block TLSA queries, one blocked these only for IPv4 clients, with > >> IPv6 clients not filtered, that can create difficult to diagnose > >> problems. > >> > >> So I am looking for guidance on how much *current* operational > >> experience to include in the draft that may ultimately become > >> irrelevant as the infrastructure improves, but may be very useful > >> to get us past the initial deployment hurdles. If we don't get > >> early adopters past the initial problems, the long-term obsolescence > >> of the issues might remain forever in the future. > >> > >> Any feedback on that would be appreciated, plus guidance on *when* to > >> make any such changes. > > > > -- > > Viktor. > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7b10cbf19dd5fa050f927e74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have read the documents, and do not see any glaring prob= lems.
I support publishing them.

Brian

On Fri, Feb 2= 0, 2015 at 2:13 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:
Dear colleagues
please take a few minutes to review this document if you have not done so y= et. This
is a critical document from the working group and the chairs rather want th= e WG to find any
issues then in IETF last call.

We plan to start a WGLC on the related OPS document RSN and will live with = cross references between the
documents as they will all be published at the same time

=C2=A0Olafur

> On Feb 20, 2015, at 5:09 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>
> On Tue, Feb 17, 2015 at 05:41:12PM -0500, Olafur Gudmundsson wrote: >
>> The SRV document got number of good reviews and editors have updat= ed the
>> document to reflect the comments received, version -11 should be f= inal WG
>> version and we plan to advance it to the IESG.
>
> Great, thanks!
>
>> SMTP document did not get as many reviews, only 3 that I can see P= aul
>> Hoffman (no comments), Dan York (not a thorough review) and Sean T= urner,
>> who had number of comments.
>
> Perhaps some folks [hint, hint] can return the favour and review
> the SMTP draft in full. :-)
>
>> The github repository contains a version of the document that addr= esses
>> all the comments received.=C2=A0 Editors please post ASAP.
>
> A -14 version has been pushed.=C2=A0 I've not yet received any fee= dback on
> the possibility of extending the operational considerations section > based on the last few months of operational experience.=C2=A0 Please > advise...
>
> On Thu, Jan 08, 2015 at 01:15:29AM +0000, Viktor Dukhovni wrote:
>
>> [...]
>>
>> I did ask a question during LC:
>>
>>=C2=A0 =C2=A0 http://www.ietf.org/mail-archive/w= eb/dane/current/msg07159.html
>>
>>=C2=A0 =C2=A0 ...
>>
>>=C2=A0 =C2=A0 One deployment pitfall discovered in recent interoper= ability tests
>>=C2=A0 =C2=A0 is that some domains have cleartext-only anti-spam pr= oxies in front
>>=C2=A0 =C2=A0 of their MTA, with the proxies only allowing connecti= ons to the
>>=C2=A0 =C2=A0 real MTA once the SMTP client passes a grey-listing c= heck (this
>>=C2=A0 =C2=A0 was observed with "spamd" as the proxy, but= any "selective access"
>>=C2=A0 =C2=A0 to TLS can be similarly problematic).
>>
>>=C2=A0 =C2=A0 If the receiving domain publishes TLSA records, this = creates a
>>=C2=A0 =C2=A0 catch-22 with DANE-aware client MTAs.=C2=A0 The DANE = client never begins
>>=C2=A0 =C2=A0 the first mail transaction, because the proxy does no= t offer
>>=C2=A0 =C2=A0 STARTTLS, (the proxy is a receiving system deployed d= owngrade to
>>=C2=A0 =C2=A0 cleartext MiTM in front of the real MTA).
>>
>>=C2=A0 =C2=A0 The short-term solution for such domains is to NOT pu= blish TLSA
>>=C2=A0 =C2=A0 RRs for port 25.=C2=A0 Longer-term the anti-spam prox= y should be upgraded
>>=C2=A0 =C2=A0 to support STARTTLS.=C2=A0 For example, the Postfix &= quot;postscreen" service,
>>=C2=A0 =C2=A0 which has functionality similar to "spamd",= supports STARTTLS so that
>>=C2=A0 =C2=A0 grey-listing does not amount to a similar downgrade a= ttack.
>>
>>=C2=A0 =C2=A0 I'd like to add some language about avoiding this= problem in the
>>=C2=A0 =C2=A0 operational considerations section of the smtp-with-d= ane draft.
>>=C2=A0 =C2=A0 Any objections?
>>
>>=C2=A0 =C2=A0 Additional operational considerations might include n= ot forgetting
>>=C2=A0 =C2=A0 to update TLSA RRs for *all* the names under which a = server might
>>=C2=A0 =C2=A0 be known when doing key rotation.=C2=A0 This is a pro= blem particularly
>>=C2=A0 =C2=A0 when a single wild-card certificate is deployed on al= l the MX hosts,
>>=C2=A0 =C2=A0 and replaced concurrently on them all, creating an im= mediate outage
>>=C2=A0 =C2=A0 for any domains that use variant MX host names (for f= lexibility of
>>=C2=A0 =C2=A0 later hosting some domains separately).=C2=A0 With DA= NE one should
>>=C2=A0 =C2=A0 strongly consider per-server certificates to avoid sy= nchronized
>>=C2=A0 =C2=A0 multi-MTA outages.
>>
>>=C2=A0 =C2=A0 And lastly, by far the most common problems are with = DNSSEC.=C2=A0 A
>>=C2=A0 =C2=A0 mixture of failure to perform timely re-signing and a= t present lots
>>=C2=A0 =C2=A0 of domains with nameservers that have non-working Den= ial of Existence.
>>=C2=A0 =C2=A0 I don't have a comprehensive list of software tha= t is deficient in
>>=C2=A0 =C2=A0 this manner, but it seems that some older versions of= PowerDNS
>>=C2=A0 =C2=A0 botch DoE in at least some configurations.=C2=A0 Simi= lar issues reportedly
>>=C2=A0 =C2=A0 with djbdns DNSSEC patches.=C2=A0 A few domains have = firewalls that
>>=C2=A0 =C2=A0 block TLSA queries, one blocked these only for IPv4 c= lients, with
>>=C2=A0 =C2=A0 IPv6 clients not filtered, that can create difficult = to diagnose
>>=C2=A0 =C2=A0 problems.
>>
>>=C2=A0 =C2=A0 So I am looking for guidance on how much *current* op= erational
>>=C2=A0 =C2=A0 experience to include in the draft that may ultimatel= y become
>>=C2=A0 =C2=A0 irrelevant as the infrastructure improves, but may be= very useful
>>=C2=A0 =C2=A0 to get us past the initial deployment hurdles.=C2=A0 = If we don't get
>>=C2=A0 =C2=A0 early adopters past the initial problems, the long-te= rm obsolescence
>>=C2=A0 =C2=A0 of the issues might remain forever in the future.
>>
>> Any feedback on that would be appreciated, plus guidance on *when*= to
>> make any such changes.
>
> --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Viktor.
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7b10cbf19dd5fa050f927e74-- From nobody Sat Feb 21 12:44:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE7D1A046D for ; Sat, 21 Feb 2015 12:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SOvhsFOX8GI for ; Sat, 21 Feb 2015 12:44:43 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38F71A00B2 for ; Sat, 21 Feb 2015 12:44:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kqM8l1C5lzB5Q; Sat, 21 Feb 2015 21:44:39 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=MWMTok+5; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bfy8i3BM6qbg; Sat, 21 Feb 2015 21:44:38 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 21 Feb 2015 21:44:38 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BB2A480416; Sat, 21 Feb 2015 15:44:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424551477; bh=rHm4I49ZPjAdQ3HFd/s/4v2Xf5KTdNBXeZdv+3rSDr0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MWMTok+5OxNjA7rE88AgBpVICShJrlB1ewThlPRBA2j8DMs98Ik6KpezYjVVbhtVf iqsoeqqP3colIpa29rOC1zNbfJf2uLsi3c38OEaPcBOEa27pQf3W5YVsDinxrBzKjE 27ipWUSh3IgZ8A/ZzoResDqNxaSRf+QVhlM7mGwA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1LKibrp007285; Sat, 21 Feb 2015 15:44:37 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 21 Feb 2015 15:44:37 -0500 (EST) From: Paul Wouters To: Brian Dickson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 20:44:46 -0000 On Fri, 20 Feb 2015, Brian Dickson wrote: > I have read the document. Modulo any other minor comments from other > reviewers, I think it is a fine document, and should be published. > Extremely minor comment: Thanks for the review! > In section 5.1, about email leaks, it may be worth additionally mentioning: > Use of distinct SALT values can further limit brute force efforts, even > where the same key is used. How would that help? I would assume the attacker zone walks the zone and then brute forces the names offline. Whether the actual live zone changes salt wouldnt matter at that point? Paul From nobody Sat Feb 21 12:54:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF01A0013 for ; Sat, 21 Feb 2015 12:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM3w2LjdO0S3 for ; Sat, 21 Feb 2015 12:54:26 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9091A0010 for ; Sat, 21 Feb 2015 12:54:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kqMN10cmpzB5Q for ; Sat, 21 Feb 2015 21:54:25 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=ICxWEhIm; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id cYpNJ_YbrtwT for ; Sat, 21 Feb 2015 21:54:23 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sat, 21 Feb 2015 21:54:23 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B53BF80416 for ; Sat, 21 Feb 2015 15:54:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424552062; bh=w3RNfzmraEna6Y81O2B6zTypJR9yrlX1JETrErJcmzQ=; h=Date:From:To:Subject:In-Reply-To:References; b=ICxWEhIm9a2kbkwJ1Iz5abrUNiob8x9PVFmbTwEVHnCVY46MB9Kj+K0yePTqehoON /gEiMBJJpHaqXSXkUpAxfY/BymsjwSNwGjOfqI4rO6uY36EMLrpsRPM+eKgtjbirY/ LwrfO5g/vRtPEuvsCJzWafvAdlXq9SJvUHqXd0SM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1LKsMab007917 for ; Sat, 21 Feb 2015 15:54:22 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 21 Feb 2015 15:54:22 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150221022330.GN1260@mournblade.imrryr.org> Message-ID: References: <20150221022330.GN1260@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 20:54:28 -0000 On Sat, 21 Feb 2015, Viktor Dukhovni wrote: > Comments: > > * The below does not mention the hex encoding of the digest. Compare with SMIMEA: Thanks. Fixed for -02. > * Grammar nit replace "its" with "their" or rephrase: Fixed for -02. > * Forward security vouching for long-term keys > > There's a typo in the first word of the highlighted paragraph: > Therefor, an OpenPGP key obtained via an OPENPGPKEY Fixed Therefor -> Therefore. > verification of the "Web of Trust". See [OPENPGPKEY-USAGE] > for more in-depth information on safe usage of OPENPGPKEY > based OpenPGP keys. > > An complementary approach is to not use the retrieved OpenPGP > key beyond the signature lifetime of the OPENPGPKEY RRset RRSIG > record. Keys obtained from DNS should be refreshed as often > as is practical (ideally before encrypting each message) and > never used beyond the RRSIG lifetime. Were the RRSIG in question > signed by an attacker, only messages signed before the key is > refreshed are compromised. Of course this requires that PGP > user agent software track the provenance and cache lifetime of > keys obtained via DNS. I would like that discussion to go into the OPENPGPKEY-USAGE document. > * Encoding tools: > > Appendix A. Generating OPENPGPKEY records > > gpg --export --export-options export-minimal \ > hugh@example.com | base64 > > the "openssl base64" command is an alternative on many other platforms. What is more widespread? coreutils or openssl ? > Later the examples don't yet use the newly allocated TYPE61: Well spotted :) Fixed. > the type should of course now be TYPE61. May as well give a > recipe for generating "SHA2-224(hugh)": > > printf "%s" hugh | > openssl dgst -sha224 -binary | > hexdump -ve '/1 "%.2x"' -e '/28 "\n"' Sure. But what is more common, coreutils or openssl :) Paul From nobody Sat Feb 21 13:34:01 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9A01A0092 for ; Sat, 21 Feb 2015 13:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWkeTEsp4LYO for ; Sat, 21 Feb 2015 13:33:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830FD1A006B for ; Sat, 21 Feb 2015 13:33:56 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 17C4B282E4F; Sat, 21 Feb 2015 21:33:55 +0000 (UTC) Date: Sat, 21 Feb 2015 21:33:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150221213354.GP1260@mournblade.imrryr.org> References: <20150221022330.GN1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 21:33:58 -0000 On Sat, Feb 21, 2015 at 03:54:22PM -0500, Paul Wouters wrote: > > Appendix A. Generating OPENPGPKEY records > > > > gpg --export --export-options export-minimal \ > > hugh@example.com | base64 > > > > the "openssl base64" command is an alternative on many other platforms. > > What is more widespread? coreutils or openssl ? I was not suggesting a replacement. Rather, you might mention an alternative for platforms without "coreutils". -- Viktor. From nobody Sat Feb 21 14:15:34 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDDA1A00F0 for ; Sat, 21 Feb 2015 14:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcarkdOzX18V for ; Sat, 21 Feb 2015 14:15:32 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB12B1A0092 for ; Sat, 21 Feb 2015 14:15:31 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so10722892igq.0 for ; Sat, 21 Feb 2015 14:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BM59tTJVMZ9gHzomApV/V0jt0iYYf5E958YJAu4LeqE=; b=oikwhSNzPPOA2Hkt/3fO59/uP9aLxmQq3VSZ6W9r569aCgo4GqjMDxlgPEGY4q/JEI 5Ak3Y8PZqORV8tFOOQYGC16GxzSS/vI2fQO8QGPtN3ynnXtkTNhr+K/341BDrtq2y/Q+ dUx9HoEqjwjXYcf3RWpx1mffAbd8+84PDfwkZMHhMCrQBkgtOFlGrpLD72IR9/th1g9n tH8lwEN3P7Amwyhi2SRWOe8omf+/P4rj+Citn7BSKpWjQYHg2qbPuZp2k5x1KHSN1El9 n+uAH82RORh6iOpHYIHColEJHjeybluQ2GJOJz6ghrgepZwr8CtsbRTQqJTAKI1BPFXl lEKg== MIME-Version: 1.0 X-Received: by 10.50.142.38 with SMTP id rt6mr4624915igb.39.1424556931111; Sat, 21 Feb 2015 14:15:31 -0800 (PST) Received: by 10.64.80.193 with HTTP; Sat, 21 Feb 2015 14:15:31 -0800 (PST) In-Reply-To: References: Date: Sat, 21 Feb 2015 14:15:31 -0800 Message-ID: From: Brian Dickson To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c3a950d76514050fa081ee Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 22:15:33 -0000 --001a11c3a950d76514050fa081ee Content-Type: text/plain; charset=UTF-8 On Sat, Feb 21, 2015 at 12:44 PM, Paul Wouters wrote: > On Fri, 20 Feb 2015, Brian Dickson wrote: > > > In section 5.1, about email leaks, it may be worth additionally >> mentioning: >> Use of distinct SALT values can further limit brute force efforts, even >> where the same key is used. >> > > How would that help? I would assume the attacker zone walks the zone and > then brute forces the names offline. Whether the actual live zone > changes salt wouldnt matter at that point? > > I should have been more clear in my comment. Enumerating a zone when NSEC3 is used, basically only gives the attacker a dictionary of NSEC3 owner names. _Those_ owner names are salted hashes of the original owner names. The effort to create a mapping from salted hashes to original owner name is "X", for some X. If the same NSEC3PARAMs are used, the same input -> same output, i.e. for owner FOO, NSEC3 owner is BAR. Changing the SALT and leaving the alg and iterations unchanged, means FOO now hashes to BAR_PRIME. If everyone used the same SALT, alg, and iterations, the attacker would be able to add to her dictionary by attacking each hashed value once. However, if everyone used random SALT, even with same alg and iterations, the dictionary of hashed values becomes worthless, and the attacker needs to maintain a dictionary of unhashed values, and need to hash the entire dictionary to find matches on each subsequent zone. It's an order(N) vs order(N) x order(M) thing, where N is the attacks dictionary size and M is the number of zones the attacker is attempting to harvest names for. It turns a win (space vs time) into a lose (diminishing returns). I think. Brian --001a11c3a950d76514050fa081ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 21, 2015 at 12:44 PM, Paul Wouters <paul@nohats.ca> wrote:
On Fri, 20 F= eb 2015, Brian Dickson wrote:


In section 5.1, about email leaks, it may be worth additionally mentioning:=
Use of distinct SALT values can further limit brute force efforts, even
where the same key is used.

 How would that help? I would assume the attacker zone walks the zone and then brute forces the names offline. Whether the actual live zone
changes salt wouldnt matter at that point?


I shou= ld have been more clear in my comment.

Enumerating= a zone when NSEC3 is used, basically only gives the attacker a dictionary = of NSEC3 owner names.
_Those_ owner names are salted hashes of th= e original owner names.
The effort to create a mapping from salte= d hashes to original owner name is "X", for some X.
If the same NSEC3PARAMs are used, the same input -> same out= put, i.e. for owner FOO, NSEC3 owner is BAR.
Changing the SALT an= d leaving the alg and iterations unchanged, means FOO now hashes to BAR_PRI= ME.

If everyone used the same SALT, alg, and itera= tions, the attacker would be able to add to her dictionary by attacking eac= h hashed value once.

However, if everyone used ran= dom SALT, even with same alg and iterations, the dictionary of hashed value= s becomes worthless, and the attacker needs to maintain a dictionary of unh= ashed values, and need to hash the entire dictionary to find matches on eac= h subsequent zone.

It's an order(N) vs order(N= ) x order(M) thing, where N is the attacks dictionary size and M is the num= ber of zones the attacker is attempting to harvest names for. It turns a wi= n (space vs time) into a lose (diminishing returns).

I think.

Brian

--001a11c3a950d76514050fa081ee-- From nobody Sat Feb 21 14:50:28 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705E01A0104 for ; Sat, 21 Feb 2015 14:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LA6Ee9qdxa2I for ; Sat, 21 Feb 2015 14:50:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E146D1A00F9 for ; Sat, 21 Feb 2015 14:50:24 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8B60D282E4F; Sat, 21 Feb 2015 22:50:23 +0000 (UTC) Date: Sat, 21 Feb 2015 22:50:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150221225023.GQ1260@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 22:50:26 -0000 On Sat, Feb 21, 2015 at 02:15:31PM -0800, Brian Dickson wrote: > If the same NSEC3PARAMs are used, the same input -> same output, i.e. for > owner FOO, NSEC3 owner is BAR. Changing the SALT and leaving the alg and > iterations unchanged, means FOO now hashes to BAR_PRIME. > > If everyone used the same SALT, alg, and iterations, the attacker would > be able to add to her dictionary by attacking each hashed value once. This is not the case. Even with the same salt everywhere, the same relative names yield different NSEC3 hashes in different domains. $ ldns-nsec3-hash -t 10 -s deadbeef www.example.com posh7b8ariqtee5s9bji4jvlhmj5qtbn. $ ldns-nsec3-hash -t 10 -s deadbeef www.example.net mj2fbsp4rqaqd2u1d1jhlr3scqeqi11i. That's because the hash covers the full domain name, not just some "prefix" labels. So NSEC3 hashes are already effectively "salted" with the zone name. What "salts" do is allow each domain to further impede off-line dictionary attacks (via per-domain rainbow tables) by periodically changing the salt. > However, if everyone used random SALT, even with same alg and iterations, > the dictionary of hashed values becomes worthless, and the attacker needs > to maintain a dictionary of unhashed values, and need to hash the entire > dictionary to find matches on each subsequent zone. No, it is OK for everyone to use the same salt, because that salt is combined with their unique domain name. For high value domains, what is perhaps useful is to change the salt periodically. For example, everyone could use the calendar YYYYMM (year + month) as the salt. And the attacker would need a new rainbow table for each domain every month. The fact that the salt is the same everywhere would not be helpful to the attacker. Of course knowing future values of the salt would make it possible to start computing the rainbow tables sooner, so the problem with YYYYMM is predictability, rather than use by multiple domains. -- Viktor. From nobody Sat Feb 21 15:00:10 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162B91A010F for ; Sat, 21 Feb 2015 15:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvjUFiHhH9Rn for ; Sat, 21 Feb 2015 15:00:07 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CCF1A010E for ; Sat, 21 Feb 2015 15:00:07 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so10804313iga.5 for ; Sat, 21 Feb 2015 15:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ukTl9lAhaeXdFIcASjM3NJmVGXEOBU6riGmd36WVbOo=; b=MygkRaJy5hRv1qWhn+uBqwkgOEWAFU4sVVSZRwuucXxGPVVQRXvTpNdopdUpDOHb5o K2D8iTeJlWPYBt3nAhB2g3wXTbub4wFu8yXH3c3mE1UJtGF+zDY5CmcptDTrW8ap04zn JF4w8tIbnz+hmj1zp3PzWpnbmQCQGWRe4qpHUWBsdwYCgDxZeV4BmMH0GI3iCljxglVo hbQ1NaAX7Wh8xvD2VPRjhvh9KOJzRm3iFxJwWlpt8WUPPJFywfy3+zuDc5fAK5iNMoFf rTI9d3MnOmqYGX2r9n0jUT1KqEj25dJJwYvqLT4QuXUPYeqU0WxEpvw7Hkf1fA2Yp8iK kxVA== MIME-Version: 1.0 X-Received: by 10.50.25.231 with SMTP id f7mr4809742igg.48.1424559605950; Sat, 21 Feb 2015 15:00:05 -0800 (PST) Received: by 10.64.80.193 with HTTP; Sat, 21 Feb 2015 15:00:05 -0800 (PST) In-Reply-To: <20150221225023.GQ1260@mournblade.imrryr.org> References: <20150221225023.GQ1260@mournblade.imrryr.org> Date: Sat, 21 Feb 2015 15:00:05 -0800 Message-ID: From: Brian Dickson To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc05da46334c050fa12177 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 23:00:09 -0000 --047d7bdc05da46334c050fa12177 Content-Type: text/plain; charset=UTF-8 Thanks Viktor. Obviously, not enough coffee. :-) Brian On Sat, Feb 21, 2015 at 2:50 PM, Viktor Dukhovni wrote: > On Sat, Feb 21, 2015 at 02:15:31PM -0800, Brian Dickson wrote: > > > If the same NSEC3PARAMs are used, the same input -> same output, i.e. for > > owner FOO, NSEC3 owner is BAR. Changing the SALT and leaving the alg and > > iterations unchanged, means FOO now hashes to BAR_PRIME. > > > > If everyone used the same SALT, alg, and iterations, the attacker would > > be able to add to her dictionary by attacking each hashed value once. > > This is not the case. Even with the same salt everywhere, the same > relative names yield different NSEC3 hashes in different domains. > > $ ldns-nsec3-hash -t 10 -s deadbeef www.example.com > posh7b8ariqtee5s9bji4jvlhmj5qtbn. > > $ ldns-nsec3-hash -t 10 -s deadbeef www.example.net > mj2fbsp4rqaqd2u1d1jhlr3scqeqi11i. > > That's because the hash covers the full domain name, not just some > "prefix" labels. So NSEC3 hashes are already effectively "salted" > with the zone name. What "salts" do is allow each domain to further > impede off-line dictionary attacks (via per-domain rainbow tables) > by periodically changing the salt. > > > > However, if everyone used random SALT, even with same alg and iterations, > > the dictionary of hashed values becomes worthless, and the attacker needs > > to maintain a dictionary of unhashed values, and need to hash the entire > > dictionary to find matches on each subsequent zone. > > No, it is OK for everyone to use the same salt, because that salt > is combined with their unique domain name. For high value domains, > what is perhaps useful is to change the salt periodically. > > For example, everyone could use the calendar YYYYMM (year + month) > as the salt. And the attacker would need a new rainbow table for > each domain every month. The fact that the salt is the same > everywhere would not be helpful to the attacker. Of course knowing > future values of the salt would make it possible to start computing > the rainbow tables sooner, so the problem with YYYYMM is predictability, > rather than use by multiple domains. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7bdc05da46334c050fa12177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Viktor. Obviously, not enough coffee. :-)

<= /div>
Brian

On Sat, Feb 21, 2015 at 2:50 PM, Viktor Dukhovni <ietf-dane= @dukhovni.org> wrote:
On Sat, Feb 21, 2015 at 02:15:31PM -0800, Brian Dickson wrote:<= br>
> If the same NSEC3PARAMs are used, the same input -> same output, i.= e. for
> owner FOO, NSEC3 owner is BAR.=C2=A0 Changing the SALT and leaving the= alg and
> iterations unchanged, means FOO now hashes to BAR_PRIME.
>
> If everyone used the same SALT, alg, and iterations, the attacker woul= d
> be able to add to her dictionary by attacking each hashed value once.<= br>
This is not the case.=C2=A0 Even with the same salt everywhere, the = same
relative names yield different NSEC3 hashes in different domains.

=C2=A0 =C2=A0 $ ldns-nsec3-hash -t 10 -s deadbeef=C2=A0 www.example.com
=C2=A0 =C2=A0 posh7b8ariqtee5s9bji4jvlhmj5qtbn.

=C2=A0 =C2=A0 $ ldns-nsec3-hash -t 10 -s deadbeef=C2=A0 www.example.net
=C2=A0 =C2=A0 mj2fbsp4rqaqd2u1d1jhlr3scqeqi11i.

That's because the hash covers the full domain name, not just some
"prefix" labels.=C2=A0 So NSEC3 hashes are already effectively &q= uot;salted"
with the zone name.=C2=A0 What "salts" do is allow each domain to= further
impede off-line dictionary attacks (via per-domain rainbow tables)
by periodically changing the salt.


> However, if everyone used random SALT, even with same alg and iteratio= ns,
> the dictionary of hashed values becomes worthless, and the attacker ne= eds
> to maintain a dictionary of unhashed values, and need to hash the enti= re
> dictionary to find matches on each subsequent zone.

No, it is OK for everyone to use the same salt, because that salt is combined with their unique domain name.=C2=A0 For high value domains, what is perhaps useful is to change the salt periodically.

For example, everyone could use the calendar YYYYMM (year + month)
as the salt.=C2=A0 And the attacker would need a new rainbow table for
each domain every month.=C2=A0 The fact that the salt is the same
everywhere would not be helpful to the attacker.=C2=A0 Of course knowing future values of the salt would make it possible to start computing
the rainbow tables sooner, so the problem with YYYYMM is predictability, rather than use by multiple domains.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7bdc05da46334c050fa12177-- From nobody Sun Feb 22 19:35:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75011A0154 for ; Sun, 22 Feb 2015 19:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxAEALmMCPRA for ; Sun, 22 Feb 2015 19:35:45 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B23E1A0151 for ; Sun, 22 Feb 2015 19:35:45 -0800 (PST) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 01BB138F00; Sun, 22 Feb 2015 19:35:44 -0800 (PST) From: "Jim Schaad" To: References: In-Reply-To: Date: Sun, 22 Feb 2015 19:34:53 -0800 Message-ID: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZrEAk8fO9l7kPFCFwPwE9DoqVVp1q1ALw Content-Language: en-us Archived-At: Cc: "''" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 03:35:47 -0000 Having reviewed the document, I would suggest the following issues be addressed: 1. The introduction nicely restricts the problem to dealing with encryption and not signatures. I think it would be wise to have a brief paragraph about why the signature side is not dealt with. I think it would be as simple as saying that the document is not doing anything about changing the trust model, so the fact that one could obtain a signature key ring for a sender does not give any additional security on the trust of the signature. This might prevent a future update to the document that extended to deal with signatures. 2. The abstract should probably make a statement that the trust model is not changing for keys, and this is targeted towards doing optimistic encryption rather than secure encryption. 3. Minor point - if you lost the public key you probably lost the pre-signed key revocation. Not sure that it is worth updating the paragraph to reflect that this value can be lost as well. s/pre-sign a key revocation/pre-sign and retained a key revocation/ 4. In section 3, I strongly urge that the problem of case folding of user names be acknowledged. I don't insist that the problem be solved. (I believe that it is not really solvable.) However I strongly field that the existence of the problem needs to be stated along with the fact that there is no intention to solve it. The problem statement can also easily state that this is a problem ONLY for US ASCII systems and not for UNICODE systems as these are less likely to allow for case folding in the first place. (Does not need to be in section 3, but that seems to be the logical place to put it.) 5. Did I miss someplace a statement that this record type MUST be used only if DNSSEC is present? Or are you willing to use it w/o DNSSEC for opportunistic encryption? If so then that should probably be stated. Jim From nobody Sun Feb 22 19:52:34 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05CC1A0167 for ; Sun, 22 Feb 2015 19:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iYkIxVc67pp for ; Sun, 22 Feb 2015 19:52:32 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA991A00F0 for ; Sun, 22 Feb 2015 19:52:32 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F0EB1282F52; Mon, 23 Feb 2015 03:52:30 +0000 (UTC) Date: Mon, 23 Feb 2015 03:52:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150223035230.GD1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 03:52:34 -0000 On Sun, Feb 22, 2015 at 07:34:53PM -0800, Jim Schaad wrote: > 4. In section 3, I strongly urge that the problem of case folding of user > names be acknowledged. I don't insist that the problem be solved. (I > believe that it is not really solvable.) However I strongly field that the > existence of the problem needs to be stated along with the fact that there > is no intention to solve it. The problem statement can also easily state > that this is a problem ONLY for US ASCII systems and not for UNICODE systems > as these are less likely to allow for case folding in the first place. > (Does not need to be in section 3, but that seems to be the logical place to > put it.) The problem *is* solvable. Case-insensitive receiving domains, could publish a case-folded version of the user name (hashed with a tag that prevents collisions in other domains, I proposed a concrete scheme some months back). Senders could for the unmodified lookup key, and then for the tagged case-folded key. The main question is whether we can reach consensus on wanting to solve it (for OPENPGPKEY and SMIMEA alike). Solving is the easy part. -- Viktor. From nobody Sun Feb 22 19:59:13 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B501A0163 for ; Sun, 22 Feb 2015 19:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRDSgWkljXwu for ; Sun, 22 Feb 2015 19:59:11 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571FC1A00F0 for ; Sun, 22 Feb 2015 19:59:11 -0800 (PST) Received: from Philemon (unknown [50.38.66.182]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id C413A38EF2 for ; Sun, 22 Feb 2015 19:59:10 -0800 (PST) From: "Jim Schaad" To: References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> In-Reply-To: <20150223035230.GD1260@mournblade.imrryr.org> Date: Sun, 22 Feb 2015 19:58:19 -0800 Message-ID: <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZrEAk8fO9l7kPFCFwPwE9DoqVVgHou59QAh//qxmdSpspIA== Content-Language: en-us Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 03:59:12 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni > Sent: Sunday, February 22, 2015 7:53 PM > To: dane@ietf.org > Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* > review. > > On Sun, Feb 22, 2015 at 07:34:53PM -0800, Jim Schaad wrote: > > > 4. In section 3, I strongly urge that the problem of case folding of user > > names be acknowledged. I don't insist that the problem be solved. (I > > believe that it is not really solvable.) However I strongly field > > that the existence of the problem needs to be stated along with the fact > that there > > is no intention to solve it. The problem statement can also easily state > > that this is a problem ONLY for US ASCII systems and not for UNICODE > > systems as these are less likely to allow for case folding in the first place. > > (Does not need to be in section 3, but that seems to be the logical > > place to put it.) > > The problem *is* solvable. Case-insensitive receiving domains, could publish > a case-folded version of the user name (hashed with a tag that prevents > collisions in other domains, I proposed a concrete scheme some months > back). Senders could for the unmodified lookup key, and then for the tagged > case-folded key. And what happens in the following case: I am on a case sensitive receiving domain. There are two recipients - JimSch and jimsch on the domain. jimsch has a record but JimSch does not. I now try and send mail to JimSch but get a key for jimsch. Jim > > The main question is whether we can reach consensus on wanting to solve it > (for OPENPGPKEY and SMIMEA alike). Solving is the easy part. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sun Feb 22 20:08:37 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACDE1A0174 for ; Sun, 22 Feb 2015 20:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkc04_MphchL for ; Sun, 22 Feb 2015 20:08:35 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F8E1A0167 for ; Sun, 22 Feb 2015 20:08:35 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E26F1282FC0; Mon, 23 Feb 2015 04:08:33 +0000 (UTC) Date: Mon, 23 Feb 2015 04:08:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150223040833.GF1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 04:08:36 -0000 On Sun, Feb 22, 2015 at 07:58:19PM -0800, Jim Schaad wrote: > I am on a case sensitive receiving domain. > There are two recipients - JimSch and jimsch on the domain. > jimsch has a record but JimSch does not. > I now try and send mail to JimSch but get a key for jimsch. You forgot to hash the tag with the case-folded name. Speaking of which, IIRC neither the OPENPGPKEY nor the SMIMEA draft explicitly mentions what to do about quoted localparts: "Sam.Jr."@example.com The localpart is not a dot-atom, and thus requires double-quotes. My contention is that in this case the input to SHA2-224 MUST include the quotes: SHA2-224("Sam.Jr.") not SHA2-224("Sam.Jr.") In this case the simplest tagging scheme is: JimSch - unfolded hash input jimsch@lowercase - folded hash input any email address of the form: "jimsch@lowercase"@example.com would be hashed together with the quotes! I don't have a pointer to my original proposal handy, check the archives. It is something along these lines. -- Viktor. From nobody Mon Feb 23 09:31:15 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2B91A1BFE for ; Mon, 23 Feb 2015 09:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5MBzwddbF59 for ; Mon, 23 Feb 2015 09:31:11 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BBA1A1BED for ; Mon, 23 Feb 2015 09:31:10 -0800 (PST) Received: by wesk11 with SMTP id k11so20139588wes.11 for ; Mon, 23 Feb 2015 09:31:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BTte1wdpHMPZQnhJhxGIcwcbqu4QTpcr4PUtxe/g4Jo=; b=FkvlvX46x4vnBW4dTTZRKdPOxq6jgxA60q4IfFeA2pzN2IvBoBGp0kknZl6cCGOlW6 hxBVsEmjVnWI3GBRheBtoMdq5do5+M+u6/fZne3XwtvlGJ4MfBiEB3/4VEJd4XMBYddk TDcMjwLLn9gkhnlYpTsshxyh7XtAoegz3n+wM4vN6PNRO4Fc46TgsTbi30Ra9SPYKWXP qzonT7V4mES6XwexqjjUrQCAPoZRwxZZH999eepAbn7AJhtAzmwz6Vn9b3kgoWVFY1U+ ECWRpLgcxI/2yGw1OJm6BhEantoJU8mlpTS0Hcy41iiTE2Tvb8hZ0nfbfFLVTHnCTdyC 0MLQ== X-Gm-Message-State: ALoCoQmwgv+SylnNHdK1RnHTTOALtCnehKWF9/jhdUbtr32vvzV7RHeqjNKAkX2TB0azjx23cwZe MIME-Version: 1.0 X-Received: by 10.194.63.16 with SMTP id c16mr24654038wjs.117.1424712669164; Mon, 23 Feb 2015 09:31:09 -0800 (PST) Received: by 10.194.158.229 with HTTP; Mon, 23 Feb 2015 09:31:09 -0800 (PST) In-Reply-To: <20150223040833.GF1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> Date: Mon, 23 Feb 2015 12:31:09 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 17:31:13 -0000 [ Meta top post ] I'd like to also draw attention to the "companion" document draft-ietf-dane-openpgpkey-usage ( http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ ), which describes usage of openpgpkey records, and following CNAMES. On Sun, Feb 22, 2015 at 11:08 PM, Viktor Dukhovni wrote: > On Sun, Feb 22, 2015 at 07:58:19PM -0800, Jim Schaad wrote: > >> I am on a case sensitive receiving domain. >> There are two recipients - JimSch and jimsch on the domain. >> jimsch has a record but JimSch does not. >> I now try and send mail to JimSch but get a key for jimsch. > > You forgot to hash the tag with the case-folded name. > > Speaking of which, IIRC neither the OPENPGPKEY nor the SMIMEA draft > explicitly mentions what to do about quoted localparts: > > "Sam.Jr."@example.com > > The localpart is not a dot-atom, and thus requires double-quotes. > My contention is that in this case the input to SHA2-224 MUST > include the quotes: > > SHA2-224("Sam.Jr.") > > not > > SHA2-224("Sam.Jr.") > > In this case the simplest tagging scheme is: > > JimSch - unfolded hash input > jimsch@lowercase - folded hash input > > any email address of the form: > > "jimsch@lowercase"@example.com > > would be hashed together with the quotes! > > I don't have a pointer to my original proposal handy, > check the archives. It is something along these lines. I *think* that the proposal is in this email: http://www.ietf.org/mail-archive/web/dane/current/msg07163.html (Viktor, 11 Dec 2014) This seemed to be mostly met with acceptance (or, at least closer than many of the other options!), but didn't address the user+tag@ or johnsmith=john.smith=jo.hn.sm.th special hanging the gMail does. A potential, but icky solution to those could be synthesized records. I'd just like to note that having a single rule for mapping ascii addresses (e.g lowercase, s/\.//g, s/\+.*// ) sure would have been nice. Next time someone has access to a time machine... W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Feb 23 09:47:30 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35D21A1C03 for ; Mon, 23 Feb 2015 09:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ipg9hwddavg for ; Mon, 23 Feb 2015 09:47:26 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA711A1B87 for ; Mon, 23 Feb 2015 09:46:47 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1924C38EFA; Mon, 23 Feb 2015 09:46:47 -0800 (PST) From: "Jim Schaad" To: "'Warren Kumari'" , References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> In-Reply-To: Date: Mon, 23 Feb 2015 09:45:55 -0800 Message-ID: <004901d04f90$93a2cf70$bae86e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZrEAk8fO9l7kPFCFwPwE9DoqVVgHou59QAh//qxkCbLzqVwI4KR+7AojFI5CdEhVWwA== Content-Language: en-us Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 17:47:28 -0000 Is there a reason that this is not doing last call at the same time? Jim > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Monday, February 23, 2015 9:31 AM > To: > Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* > review. > > [ Meta top post ] > > I'd like to also draw attention to the "companion" document draft-ietf-dane- > openpgpkey-usage ( http://datatracker.ietf.org/doc/draft-ietf-dane- > openpgpkey-usage/ ), which describes usage of openpgpkey records, and > following CNAMES. > > On Sun, Feb 22, 2015 at 11:08 PM, Viktor Dukhovni dane@dukhovni.org> wrote: > > On Sun, Feb 22, 2015 at 07:58:19PM -0800, Jim Schaad wrote: > > > >> I am on a case sensitive receiving domain. > >> There are two recipients - JimSch and jimsch on the domain. > >> jimsch has a record but JimSch does not. > >> I now try and send mail to JimSch but get a key for jimsch. > > > > You forgot to hash the tag with the case-folded name. > > > > Speaking of which, IIRC neither the OPENPGPKEY nor the SMIMEA draft > > explicitly mentions what to do about quoted localparts: > > > > "Sam.Jr."@example.com > > > > The localpart is not a dot-atom, and thus requires double-quotes. > > My contention is that in this case the input to SHA2-224 MUST include > > the quotes: > > > > SHA2-224("Sam.Jr.") > > > > not > > > > SHA2-224("Sam.Jr.") > > > > In this case the simplest tagging scheme is: > > > > JimSch - unfolded hash input > > jimsch@lowercase - folded hash input > > > > any email address of the form: > > > > "jimsch@lowercase"@example.com > > > > would be hashed together with the quotes! > > > > I don't have a pointer to my original proposal handy, check the > > archives. It is something along these lines. > > I *think* that the proposal is in this email: > http://www.ietf.org/mail-archive/web/dane/current/msg07163.html > (Viktor, 11 Dec 2014) > > This seemed to be mostly met with acceptance (or, at least closer than many > of the other options!), but didn't address the user+tag@ or > johnsmith=john.smith=jo.hn.sm.th special hanging the gMail does. > A potential, but icky solution to those could be synthesized records. > > I'd just like to note that having a single rule for mapping ascii addresses (e.g > lowercase, s/\.//g, s/\+.*// ) sure would have been nice. Next time > someone has access to a time machine... > > W > > > > > -- > > Viktor. > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > > -- > I don't think the execution is relevant when it was obviously a bad idea in the > first place. > This is like putting rabid weasels in your pants, and later expressing regret at > having chosen those particular rabid weasels and that pair of pants. > ---maf > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Feb 23 10:18:21 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF61A1EF6 for ; Mon, 23 Feb 2015 10:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu9J8D7auauL for ; Mon, 23 Feb 2015 10:18:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891F81A1EF3 for ; Mon, 23 Feb 2015 10:18:16 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 814A1282F52; Mon, 23 Feb 2015 18:18:15 +0000 (UTC) Date: Mon, 23 Feb 2015 18:18:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150223181815.GL1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 18:18:20 -0000 On Mon, Feb 23, 2015 at 12:31:09PM -0500, Warren Kumari wrote: > I *think* that the proposal is in this email: > http://www.ietf.org/mail-archive/web/dane/current/msg07163.html > (Viktor, 11 Dec 2014) > > This seemed to be mostly met with acceptance (or, at least closer than > many of the other options!), but didn't address the user+tag@ or > johnsmith=john.smith=jo.hn.sm.th special hanging the gMail does. > A potential, but icky solution to those could be synthesized records. If the goal is to go beyond case-folding, then we'd have to seriously consider publishing the data via a DANE-authenticated HTTPS service rather than directly in DNS. The service would then be able to apply whatever lookup transformations are locally applicable. I'm not sensing much appetite for moving away from per-user records in DNS, so case-folding can be handled, but fancier variants are I think beyond what can be done with the logic mostly on the client side. -- Viktor. From nobody Mon Feb 23 12:40:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3540E1A6F04 for ; Mon, 23 Feb 2015 12:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhPobx5HUKB2 for ; Mon, 23 Feb 2015 12:40:17 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D241A6F03 for ; Mon, 23 Feb 2015 12:40:17 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 85CF938EA5; Mon, 23 Feb 2015 12:40:16 -0800 (PST) From: "Jim Schaad" To: "'Warren Kumari'" , References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> In-Reply-To: Date: Mon, 23 Feb 2015 12:39:24 -0800 Message-ID: <001501d04fa8$cffdef50$6ff9cdf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZrEAk8fO9l7kPFCFwPwE9DoqVVgHou59QAh//qxkCbLzqVwI4KR+7AojFI5CdEkDvMA== Content-Language: en-us Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 20:40:19 -0000 > -----Original Message----- > From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Monday, February 23, 2015 9:31 AM > To: > Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* > review. > > [ Meta top post ] > > I'd like to also draw attention to the "companion" document draft-ietf-dane- > openpgpkey-usage ( http://datatracker.ietf.org/doc/draft-ietf-dane- > openpgpkey-usage/ ), which describes usage of openpgpkey records, and > following CNAMES. > > On Sun, Feb 22, 2015 at 11:08 PM, Viktor Dukhovni dane@dukhovni.org> wrote: > > On Sun, Feb 22, 2015 at 07:58:19PM -0800, Jim Schaad wrote: > > > >> I am on a case sensitive receiving domain. > >> There are two recipients - JimSch and jimsch on the domain. > >> jimsch has a record but JimSch does not. > >> I now try and send mail to JimSch but get a key for jimsch. > > > > You forgot to hash the tag with the case-folded name. > > > > Speaking of which, IIRC neither the OPENPGPKEY nor the SMIMEA draft > > explicitly mentions what to do about quoted localparts: > > > > "Sam.Jr."@example.com > > > > The localpart is not a dot-atom, and thus requires double-quotes. > > My contention is that in this case the input to SHA2-224 MUST include > > the quotes: > > > > SHA2-224("Sam.Jr.") > > > > not > > > > SHA2-224("Sam.Jr.") > > > > In this case the simplest tagging scheme is: > > > > JimSch - unfolded hash input > > jimsch@lowercase - folded hash input > > > > any email address of the form: > > > > "jimsch@lowercase"@example.com > > > > would be hashed together with the quotes! > > > > I don't have a pointer to my original proposal handy, check the > > archives. It is something along these lines. > > I *think* that the proposal is in this email: > http://www.ietf.org/mail-archive/web/dane/current/msg07163.html > (Viktor, 11 Dec 2014) > > This seemed to be mostly met with acceptance (or, at least closer than many > of the other options!), but didn't address the user+tag@ or > johnsmith=john.smith=jo.hn.sm.th special hanging the gMail does. > A potential, but icky solution to those could be synthesized records. If we are going to deal with these cases then there are number of other problems that need to be addressed. Specifically the fact that there is going to be a problem matching of email addresses found in the PGP key ring and those that are on the to/from line of a mail message. MUAs have traditionally just done simple comparisons of names, they are not going to be able to handle the type of thing where google starts removing periods from the name. A person is going to say - send me that and here is my address. If it has funny things in it, that is going to need to be matched in the PGP key ring. I don't know how common that is for PGP, but it was rare in the S/MIME world when I was doing work there. Even case folding is not a requirement for S/MIME clients on doing name comparisons of the address in the headers as compared with the address in the certificate. There are two different names that needs to be dealt with: 1. The name the owner of the mail box thinks that is being used. 2. The name that mail system thinks is being used for the mail box. If these names differ by more than case, then there are going to be a great number of failures in comparisons between from and to fields and the email address in either a certificate or a key ring. While there are stupid folding rules that have been implemented by different systems. They are going to lead to problems if they are not recognized by the owner of the mail box. If I think the address is John.Doe@google.com and put that into a key ring and the From address is JohnDoe@google.com then there is never going to a successful match by an MUA to begin with. Jim > > I'd just like to note that having a single rule for mapping ascii addresses (e.g > lowercase, s/\.//g, s/\+.*// ) sure would have been nice. Next time > someone has access to a time machine... > > W > > > > > -- > > Viktor. > > > > _______________________________________________ > > dane mailing list > > dane@ietf.org > > https://www.ietf.org/mailman/listinfo/dane > > > > -- > I don't think the execution is relevant when it was obviously a bad idea in the > first place. > This is like putting rabid weasels in your pants, and later expressing regret at > having chosen those particular rabid weasels and that pair of pants. > ---maf > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Mon Feb 23 14:49:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF641A0173 for ; Mon, 23 Feb 2015 14:49:23 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtBleW75o_3z for ; Mon, 23 Feb 2015 14:49:20 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5161A0107 for ; Mon, 23 Feb 2015 14:49:20 -0800 (PST) Received: by iecvy18 with SMTP id vy18so27388707iec.13 for ; Mon, 23 Feb 2015 14:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/GyYSobDD7HuMIzU5ZtGzd1gIzrFpl7U7+pfsVrZBcA=; b=yCRykEveySwV8y9Hng2d93S6Gdq6yjyGqnWgqVX2D/QWGr7TEq1feW4jfRd9PzioYd /j2P/R7Efa78fsB3zuZJDKHCBexgcPiv4qUaMmoPrA/yJq7qsPH1dUMYLXMuaQa6G78T wvS2l1E606G2HkxUIXdRti520RRr4A2KmS+761bKwb47ZgLU6HcTQy/GRp7LoZkFGuzc bMHmGlrG4zqV+t1COhQG74Uvrwpsc+1RvYnJgkQwNL3i+RCA7e/gr2c2F5lfTRU2K9xl x0WfONC4krWV9NyPoAL1D8wrRF++9IsTO4a7CMNsQD7Qe5tZmP4mz5GMv+Gp5M2ci0ob afSg== MIME-Version: 1.0 X-Received: by 10.107.134.160 with SMTP id q32mr17348193ioi.70.1424731759567; Mon, 23 Feb 2015 14:49:19 -0800 (PST) Received: by 10.64.80.193 with HTTP; Mon, 23 Feb 2015 14:49:19 -0800 (PST) In-Reply-To: <20150223181815.GL1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223181815.GL1260@mournblade.imrryr.org> Date: Mon, 23 Feb 2015 14:49:19 -0800 Message-ID: From: Brian Dickson To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=001a113f92a66dee06050fc936c3 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:49:23 -0000 --001a113f92a66dee06050fc936c3 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 10:18 AM, Viktor Dukhovni wrote: > On Mon, Feb 23, 2015 at 12:31:09PM -0500, Warren Kumari wrote: > > > I *think* that the proposal is in this email: > > http://www.ietf.org/mail-archive/web/dane/current/msg07163.html > > (Viktor, 11 Dec 2014) > > > > This seemed to be mostly met with acceptance (or, at least closer than > > many of the other options!), but didn't address the user+tag@ or > > johnsmith=john.smith=jo.hn.sm.th special hanging the gMail does. > > A potential, but icky solution to those could be synthesized records. > > If the goal is to go beyond case-folding, then we'd have to seriously > consider publishing the data via a DANE-authenticated HTTPS service > rather than directly in DNS. The service would then be able to > apply whatever lookup transformations are locally applicable. > > I'm not sensing much appetite for moving away from per-user records > in DNS, so case-folding can be handled, but fancier variants are > I think beyond what can be done with the logic mostly on the client > side. > > I think maybe this needs to be broken out as a separate mini-document. However, I think the right time to do this is NOW. Here's the reasoning to support "NOW" for when to address this issue: - right now, there aren't any clients doing the DANE s/mime or pgp thing yet (I believe) - if everyone implementing the DANE stuff for clients has the same rules to work from, much happiness ensues - if, on the other hand, all the DANE stuff gets built without the extra "case-folding++" logic, it becomes a missed opportunity that can never be addressed successfully (shutting the barn door after the horse has left) The thing to do, IMHO, is identify ALL of the specific things that anyone does in MUA/MTA name-handling, beyond case folding. I think even standardizing a signaling for case-folding of names is beneficial. The difference between PGP keyrings and DANE, is that users are responsible for adding any "case folding" aliases into their PGP keyrings, e.g. as child alias for their main fingerprint (or whatever the correct terminology is for that). On the other hand, domain-based user aliasing is, by definition, known by and generally able to be handled by, the admin for the domain. My suggestion would be to have some kind of _THING defined, which is well-known, and which is queried, that lists the specific username-folding ruleset(s). E.g. _casefold TXT "lc" for lowercase as the canonical form, or _casefold TXT "lc nodots" for removing any dots, and converting to lowercase, or _casefold TXT "lc trimplus". Having a canonical list of these NOW, means coding for DANE S/MIME and DANE PGP can include this, and then it is up to the zone publisher to do the right thing. My $0.02. Brian --001a113f92a66dee06050fc936c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 23, 2015 at 10:18 AM, Viktor Dukhovni <= ;ietf-dane@dukh= ovni.org> wrote:
On Mon, Feb 23, 2015 at 12:31:09PM -0500, Warren Kumari wrote:

> I *think* that the proposal is in this email:
> http://www.ietf.org/mail-archive/web/dane/current/m= sg07163.html
> (Viktor, 11 Dec 2014)
>
> This seemed to be mostly met with acceptance (or, at least closer than=
> many of the other options!), but didn't address the user+tag@ or > johnsmith=3Djohn.smith=3Djo.hn.sm.th special hanging the gMail does.
> A potential, but icky solution to those could be synthesized records.<= br>
If the goal is to go beyond case-folding, then we'd have to seri= ously
consider publishing the data via a DANE-authenticated HTTPS service
rather than directly in DNS.=C2=A0 The service would then be able to
apply whatever lookup transformations are locally applicable.

I'm not sensing much appetite for moving away from per-user records
in DNS, so case-folding can be handled, but fancier variants are
I think beyond what can be done with the logic mostly on the client
side.

<= br>
I think maybe this needs to be broken out as a separate mini-= document.
However, I think the right time to do this is NOW.

Here's the reasoning to support "NOW" fo= r when to address this issue:
- right now, there aren't any c= lients doing the DANE s/mime or pgp thing yet (I believe)
- if ev= eryone implementing the DANE stuff for clients has the same rules to work f= rom, much happiness ensues
- if, on the other hand, all the DANE = stuff gets built without the extra "case-folding++" logic, it bec= omes a missed opportunity that can never be addressed successfully (shuttin= g the barn door after the horse has left)

The thin= g to do, IMHO, is identify ALL of the specific things that anyone does in M= UA/MTA name-handling, beyond case folding. I think even standardizing a sig= naling for case-folding of names is beneficial.

Th= e difference between PGP keyrings and DANE, is that users are responsible f= or adding any "case folding" aliases into their PGP keyrings, e.g= . as child alias for their main fingerprint (or whatever the correct termin= ology is for that). On the other hand, domain-based user aliasing is, by de= finition, known by and generally able to be handled by, the admin for the d= omain.

My suggestion would be to have some kind of= _THING defined, which is well-known, and which is queried, that lists the = specific username-folding ruleset(s). E.g. _casefold TXT "lc" for= lowercase as the canonical form, or _casefold TXT "lc nodots" fo= r removing any dots, and converting to lowercase, or _casefold =C2=A0TXT &q= uot;lc trimplus".

Having a canonical list= of these NOW, means coding for DANE S/MIME and DANE PGP can include this, = and then it is up to the zone publisher to do the right thing.
My $0.02.

Brian
--001a113f92a66dee06050fc936c3-- From nobody Mon Feb 23 14:56:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFCA1A034C for ; Mon, 23 Feb 2015 14:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN1pbnpGCFAC for ; Mon, 23 Feb 2015 14:56:32 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7031A0262 for ; Mon, 23 Feb 2015 14:56:31 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0181A282F52; Mon, 23 Feb 2015 22:56:30 +0000 (UTC) Date: Mon, 23 Feb 2015 22:56:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150223225630.GO1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:56:33 -0000 On Mon, Feb 23, 2015 at 12:31:09PM -0500, Warren Kumari wrote: > > I don't have a pointer to my original proposal handy, > > check the archives. It is something along these lines. > > I *think* that the proposal is in this email: > http://www.ietf.org/mail-archive/web/dane/current/msg07163.html > (Viktor, 11 Dec 2014) Yes, thanks that the correct, more complete description. The difference between that and what I wrote down from memory today is the placement of the tag: @lower:local-part-with-quotes-if-needed vs. local-part-with-quotes-if-needed@lowercase These are trivial variations of the same thing, perhaps today's @lowercase suffix is more natural, but I don't really care which if either is selected, if this general approach is chosen. Is there rough consensus behind this proposal (for both OPENPGPKEY and SMIMEA)? -- Viktor. From nobody Wed Feb 25 09:16:06 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB0F1A8845 for ; Wed, 25 Feb 2015 09:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMYkG2FtVZfm for ; Wed, 25 Feb 2015 09:16:02 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5A41A87D4 for ; Wed, 25 Feb 2015 09:16:02 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Feb 2015 12:15:55 -0500 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 25 Feb 2015 12:16:00 -0500 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id t1PHFlpD001247 for ; Wed, 25 Feb 2015 12:15:47 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Rose, Scott W." In-Reply-To: Date: Wed, 25 Feb 2015 12:15:45 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <3A75EA8C-C6FD-4412-BC3C-A34CDA7023D2@nist.gov> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> To: "" X-Mailer: Apple Mail (2.1878.6) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:16:05 -0000 On Feb 23, 2015, at 12:31 PM, Warren Kumari wrote: > [ Meta top post ] >=20 > I'd like to also draw attention to the "companion" document > draft-ietf-dane-openpgpkey-usage ( > http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ ), > which describes usage of openpgpkey records, and following CNAMES. >=20 Is this also in WGLC? Either way, some comments: - In section 1 (Intro), there is an incorrect XML tag (xref) - In Section 3.3 Final paragraph about wildcards: ...at other locations = (e.g. hugh@*.com) or regular expressions in keu uids are not allowed, = adn any OPENPGPKEY RR containing these should be ignored." Should that be a SHOULD above? It discusses implementation behavior in = addition to what is already described in Sections 4.3 & 4.4. =20 - In Section 3.4 spelling s/Resoruce/Resource and = s/accomodate/accommodate - In Section 4. s/twart/thwart At least I assume that last one - my spell checker gets confused about = UK vs. US english. =20 Scott =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Wed Feb 25 09:26:35 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737341A1AA5 for ; Wed, 25 Feb 2015 09:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDIW5dXhvzhE for ; Wed, 25 Feb 2015 09:26:32 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE2E1A1AB0 for ; Wed, 25 Feb 2015 09:26:31 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so6780945wid.0 for ; Wed, 25 Feb 2015 09:26:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HsfYq7bKsNPkwB0Itqrz9z0F7VGV/Gj/UHZI5WvOt4E=; b=LgiCP9IanvTgtzjcN7r9/TrVNx7o6UsxibXSsKY9uhroSv/IY4gW5lsmaZIAE9MAuo dHKE1muUaQ8oMe5SCXuxjotY08CNvcWqlJmmISJTG1YesZNDdA2lMoJ/v1SvlvVDzjMx X7RaizajzQsgGFg6Sb7Y45laoDVF9Tb/eIzIk4H+jRsNd3BV37IIim8hJp7MYvzIAYRm ZPBnKvFoILJvIJoN7DuV8CKMzUlJFnEHFaD0BXDM9cYVKV9ZZPR1cu3urdhlMRMbrgGg Fw/AFS4qWNBkuooKWKqmSokMpndln2iDHAeS7tFzj96EmoEdiUWKSu31cuk/p1F7A0pV 1a1g== X-Gm-Message-State: ALoCoQlwyxYqK8tnqg62qBn3B0U8L4cKweKcaNzMOiINUM7aFef/ZGa86teNFgDMUYUVptZxuod2 MIME-Version: 1.0 X-Received: by 10.180.74.111 with SMTP id s15mr8192293wiv.61.1424885190201; Wed, 25 Feb 2015 09:26:30 -0800 (PST) Received: by 10.194.158.229 with HTTP; Wed, 25 Feb 2015 09:26:30 -0800 (PST) In-Reply-To: <3A75EA8C-C6FD-4412-BC3C-A34CDA7023D2@nist.gov> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <3A75EA8C-C6FD-4412-BC3C-A34CDA7023D2@nist.gov> Date: Wed, 25 Feb 2015 12:26:30 -0500 Message-ID: From: Warren Kumari To: "Rose, Scott W." Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:26:34 -0000 On Wed, Feb 25, 2015 at 12:15 PM, Rose, Scott W. wrote: > > On Feb 23, 2015, at 12:31 PM, Warren Kumari wrote: > >> [ Meta top post ] >> >> I'd like to also draw attention to the "companion" document >> draft-ietf-dane-openpgpkey-usage ( >> http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ ), >> which describes usage of openpgpkey records, and following CNAMES. >> > > Is this also in WGLC? Either way, some comments: It is NOT currently in WGLC -- but the comments are appreciated. Would the WG like to WGLC this at the same time? Olafur and I has a discussion about this - he figured it should be included, I thought better to hold off - I'm happy to start a WGLC if folk want that. W > > - In section 1 (Intro), there is an incorrect XML tag (xref) > > - In Section 3.3 Final paragraph about wildcards: ...at other locations (e.g. hugh@*.com) or regular expressions in keu uids are not allowed, adn any OPENPGPKEY RR containing these should be ignored." > > Should that be a SHOULD above? It discusses implementation behavior in addition to what is already described in Sections 4.3 & 4.4. > > - In Section 3.4 spelling s/Resoruce/Resource and s/accomodate/accommodate > > - In Section 4. s/twart/thwart > > At least I assume that last one - my spell checker gets confused about UK vs. US english. > > Scott > > =================================== > Scott Rose > NIST > scott.rose@nist.gov > +1 301-975-8439 > Google Voice: +1 571-249-3671 > http://www.dnsops.gov/ > https://www.had-pilot.com/ > =================================== > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Feb 25 09:38:00 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E311A1A7F for ; Wed, 25 Feb 2015 09:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gNMsBUBkW8V for ; Wed, 25 Feb 2015 09:37:57 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C787A1A1B20 for ; Wed, 25 Feb 2015 09:37:55 -0800 (PST) Received: by wggy19 with SMTP id y19so5095857wgg.13 for ; Wed, 25 Feb 2015 09:37:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kUdaOxBEoN9DraggxSB/7TlxqT/woiugW4TVQla5zNA=; b=RaRb/RYFymVdbKZouJl2uKvwE1RLQMxMsZuvU571jyScW5QpiE2XI7WGUsHlM5ltFk oxx7/8jkaOX5RFzd61MaskGHAV+GsM6gILWcpBwY4Px+pffcof+pkUV4oJsy1+0E84GP C1ks/W26BDX1cl6Y5+L0/Xp3q80YwEjebGK1MZemQqd7MKpDGy61H/RtZ9eMosqfqWH0 i0EyJ8wMeYseNTmf6lZcIvHWGcqg1oKYevbbeFByGffxnCsiNvA/iNI8rAVtmd8NDxM6 OryyTojD966s+g/N0pouQmwe80AdxKKE2e6QWGryTDRLw4fT2Ak6KIJnNvcqmmbownBS Kd3A== X-Gm-Message-State: ALoCoQmCBhJqAFJ5PLUfj/72JYZ702utEmWBy9vpUWdDKhdueuJ4o84Hpxv1IwQJ9vSmIsXSJ6HL MIME-Version: 1.0 X-Received: by 10.180.102.199 with SMTP id fq7mr8239283wib.89.1424885874445; Wed, 25 Feb 2015 09:37:54 -0800 (PST) Received: by 10.194.158.229 with HTTP; Wed, 25 Feb 2015 09:37:54 -0800 (PST) In-Reply-To: <20150223225630.GO1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> Date: Wed, 25 Feb 2015 12:37:54 -0500 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:37:59 -0000 On Mon, Feb 23, 2015 at 5:56 PM, Viktor Dukhovni wrote: > On Mon, Feb 23, 2015 at 12:31:09PM -0500, Warren Kumari wrote: > >> > I don't have a pointer to my original proposal handy, >> > check the archives. It is something along these lines. >> >> I *think* that the proposal is in this email: >> http://www.ietf.org/mail-archive/web/dane/current/msg07163.html >> (Viktor, 11 Dec 2014) > > Yes, thanks that the correct, more complete description. > > The difference between that and what I wrote down from memory > today is the placement of the tag: > > @lower:local-part-with-quotes-if-needed > > vs. > > local-part-with-quotes-if-needed@lowercase > > These are trivial variations of the same thing, perhaps today's > @lowercase suffix is more natural, but I don't really care which > if either is selected, if this general approach is chosen. > > Is there rough consensus behind this proposal (for both OPENPGPKEY > and SMIMEA)? I think we were very close to rough consensus, but I'm not sure how many people actually read the suggestion. I know not everyone loved the idea, but I think it might be the best that we can do.... Viktor, would you mind writing up the proposal again (in a new thread) and we'll call consensus on this approach? W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Feb 25 09:43:01 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659AF1A1B6B for ; Wed, 25 Feb 2015 09:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CBWvZ2krh_A for ; Wed, 25 Feb 2015 09:42:57 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CB11A1B4C for ; Wed, 25 Feb 2015 09:42:57 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kskx80LTqz2j; Wed, 25 Feb 2015 18:42:52 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=O9BBrxCF; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id kG-h24UzQYm5; Wed, 25 Feb 2015 18:42:51 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 25 Feb 2015 18:42:51 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 78FBA803E0; Wed, 25 Feb 2015 12:42:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424886170; bh=+tD0tyv2aXlvGsf2SbYL7ECF7rhd9sRXeqqEcrxp+hw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O9BBrxCF0okTlHqJ2968aLCtZN+aba5zQn6xrXQDMZ5leOUrXbDQx8RAdYiu/tGUS 5ej7PcZeQ+4cQjywlsXBR7rWnMGIcEhG3DU0ENNqcuDUxrYwZDZeyX3upNMGlROP/G 6GImOmLFVzCpNEe9SQqvN+2XXkHO51PmewSR2umQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1PHgnRv005894; Wed, 25 Feb 2015 12:42:50 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Feb 2015 12:42:49 -0500 (EST) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <3A75EA8C-C6FD-4412-BC3C-A34CDA7023D2@nist.gov> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:43:00 -0000 On Wed, 25 Feb 2015, Warren Kumari wrote: >>> I'd like to also draw attention to the "companion" document >>> draft-ietf-dane-openpgpkey-usage ( >>> http://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey-usage/ ), >>> which describes usage of openpgpkey records, and following CNAMES. >>> >> >> Is this also in WGLC? Either way, some comments: > > It is NOT currently in WGLC -- but the comments are appreciated. > > Would the WG like to WGLC this at the same time? Olafur and I has a > discussion about this - he figured it should be included, I thought > better to hold off - I'm happy to start a WGLC if folk want that. The document is not ready. We are before the "nits" stage and I think it would be good to discuss it from a high overview level. It basically moved controversial policy decisions from the record format document into this one - I don't think we actually had the dicussions we postponed. Paul From nobody Wed Feb 25 09:51:07 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B931A003A for ; Wed, 25 Feb 2015 09:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXpjJJ5i7sYM for ; Wed, 25 Feb 2015 09:51:03 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2931A0027 for ; Wed, 25 Feb 2015 09:51:03 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ksl6Y5ryPz6T; Wed, 25 Feb 2015 18:51:01 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=lU57yOpq; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LrmjM5Z507oB; Wed, 25 Feb 2015 18:51:00 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 25 Feb 2015 18:51:00 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ECE28803E0; Wed, 25 Feb 2015 12:50:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424886659; bh=JhYCUMrASOdiPIg3q6foXAMh6qb3MCAv3rS15BP7Io4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lU57yOpq/Yfgq6ZKDZj5K6wdiQg7qnjFDcpKgulz0GaY5MrXqGry/ld/YfLZvuZEj FU5TBGIkeVrm69c9qukN3hhfjOxb4yG8XESIKAIor7zO4fZZAlbp6D8KwogkYjnb4S gdSFncZKCmq9diH4sk1CkIPAYXc0T2ZChvW5mSHQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1PHoxNa006215; Wed, 25 Feb 2015 12:50:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Feb 2015 12:50:59 -0500 (EST) From: Paul Wouters To: Warren Kumari In-Reply-To: Message-ID: References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:51:05 -0000 On Wed, 25 Feb 2015, Warren Kumari wrote: >> Is there rough consensus behind this proposal (for both OPENPGPKEY >> and SMIMEA)? > I think we were very close to rough consensus, but I'm not sure how > many people actually read the suggestion. I know not everyone loved > the idea, but I think it might be the best that we can do.... > > Viktor, would you mind writing up the proposal again (in a new thread) > and we'll call consensus on this approach? I think I explained this before, but I don't like anything that requires putting more than one entry into the DNS. The logic should be in the client behaviour. the SMTP protocol allows "Frank" to be a different email from "frank" so we cannot define these two to be the same at the protocol level. We can only provide guidance the clients trying to consume the new RRtypes. So I'm okay with defining client behaviour to try sha224(Frank) and then sha224(frank) and have a note in the security section explaining that in theory (even if not in practise) these two could be different people. Paul From nobody Wed Feb 25 10:13:27 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17821A1A39 for ; Wed, 25 Feb 2015 10:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7Cl-BKufpMG for ; Wed, 25 Feb 2015 10:13:24 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B041B1A1A3C for ; Wed, 25 Feb 2015 10:13:23 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8137C282FCC; Wed, 25 Feb 2015 18:13:22 +0000 (UTC) Date: Wed, 25 Feb 2015 18:13:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150225181322.GU1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 18:13:26 -0000 On Wed, Feb 25, 2015 at 12:50:59PM -0500, Paul Wouters wrote: > >Viktor, would you mind writing up the proposal again (in a new thread) > >and we'll call consensus on this approach? > > I think I explained this before, but I don't like anything that requires > putting more than one entry into the DNS. The logic should be in the > client behaviour. the SMTP protocol allows "Frank" to be a different > email from "frank" so we cannot define these two to be the same at the > protocol level. We can only provide guidance the clients trying to > consume the new RRtypes. Note that precisely because the client is not free to define "Frank" to be the same as "frank", and because DNS does not have anything remotely resembling server-defined case matching rules, we either give up on supporting case-less matching even when case insensitivity is known to the server, or multiple lookup keys need to be published, in such a way that "frank" is explicitly lower-case-of(Frank) rather than just some lower-case address. > So I'm okay with defining client behaviour to try sha224(Frank) and then > sha224(frank) and have a note in the security section explaining that > in theory (even if not in practise) these two could be different people. Once the client is making two queries, why accept collisions? Are we (after all these years) finally defining RFC-822/2822/5322 local parts to be case-insensitive? (Price of progress and all that?) Is a CNAME per-user really a major burden? -- Viktor. From nobody Wed Feb 25 11:01:58 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63CB1A1BE5 for ; Wed, 25 Feb 2015 11:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_47=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMIHiMLkabsZ for ; Wed, 25 Feb 2015 11:01:54 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D491A1BAE for ; Wed, 25 Feb 2015 11:01:51 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ksmhD6sqjz1L8 for ; Wed, 25 Feb 2015 20:01:48 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=kGIWR2/z; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1BQbFvcSPesu for ; Wed, 25 Feb 2015 20:01:48 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 25 Feb 2015 20:01:47 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CCED3803E0 for ; Wed, 25 Feb 2015 14:01:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424890898; bh=vSlbBzQsfpNN4VRk35dnU/ulqeqgTF9h4d+zNLl8Bks=; h=Date:From:To:Subject:In-Reply-To:References; b=kGIWR2/zdyR44wxi0hkCfYhnuFOXDyOVNxw7uXvAtNZt/PPoVXmrjbGC02rDdsVZ0 2V5ShOfrq2xeLE5IRD6x0+l7DrBPEI3rzc6Drse8bw/r+r02lavr+3/s9djH0Z+lDP KfplrSQ2SjHL/MEHwVNcr/M7bhCSoFSzAebi7C7s= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1PJ1cj0008735 for ; Wed, 25 Feb 2015 14:01:38 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 25 Feb 2015 14:01:38 -0500 (EST) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20150225181322.GU1260@mournblade.imrryr.org> Message-ID: References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> <20150225181322.GU1260@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 19:01:56 -0000 On Wed, 25 Feb 2015, Viktor Dukhovni wrote: > Once the client is making two queries, why accept collisions? Are > we (after all these years) finally defining RFC-822/2822/5322 local > parts to be case-insensitive? (Price of progress and all that?) > > Is a CNAME per-user really a major burden? It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P The client needs smart logic anyway, and the client at least has a user it can interact with. It can ask "A key for Paul@nohats.ca does not exist but there is a key for paul@nohats.ca". Needing to roll out between 2 and 4 different capitalizations for different [Ff]irstname.[Ll]astname makes everything more errorprone and the client still needs its logic and user interaction. Paul From nobody Wed Feb 25 11:15:04 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972371A1BFE for ; Wed, 25 Feb 2015 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-cgfXMcffY7 for ; Wed, 25 Feb 2015 11:15:01 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54EA61A6EE1 for ; Wed, 25 Feb 2015 11:15:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4004E282FCC; Wed, 25 Feb 2015 19:15:00 +0000 (UTC) Date: Wed, 25 Feb 2015 19:15:00 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150225191500.GZ1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> <20150225181322.GU1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 19:15:02 -0000 On Wed, Feb 25, 2015 at 02:01:38PM -0500, Paul Wouters wrote: > On Wed, 25 Feb 2015, Viktor Dukhovni wrote: > > >Once the client is making two queries, why accept collisions? Are > >we (after all these years) finally defining RFC-822/2822/5322 local > >parts to be case-insensitive? (Price of progress and all that?) > > > >Is a CNAME per-user really a major burden? > > It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul > paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P One CNAME per case-insensitive name (if the preferred form is mixed or upper case). Those other names you're mentioning if they all share the same underlying keys would be CNAMEs you'd have to create with or without my proposal for a mechanism to publish case-insensitive names. > The client needs smart logic anyway, and the client at least has a user > it can interact with. It can ask "A key for Paul@nohats.ca does not > exist but there is a key for paul@nohats.ca". Why ask the user, when the server can just publish the fact that all upper/mixed-case veriants of "paul" are the same mailbox. > Needing to roll out between 2 and 4 different capitalizations for > different [Ff]irstname.[Ll]astname makes everything more errorprone > and the client still needs its logic and user interaction. The I don't how you get to "4". You can publish exactly one owner for each case-insensitive "LocalPart", no CNAMEs required if you are willing to accept clients making two queries to find keys in your domain (space/time trade-off): SHA2-224(localpart@lowercase) IN Optionally, for faster queries, if the mailbox has a preferred form: SHA2-224(LocalPart) IN SHA2-224(localpart@lowercase) IN CNAME SHA2-224(LocalPart) If there's also a "Local.Part" and "local.part" to go with it, that it is completely separate from my proposal which deals only with handling case-insensitive matching. The overhead of supporting case-insensitive matching is at most a second (CNAME) record for each record that would be there in the absence of the proposal. -- Viktor. From nobody Wed Feb 25 13:41:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088FE1A88EA for ; Wed, 25 Feb 2015 13:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCCSI6_4tMIp for ; Wed, 25 Feb 2015 13:41:20 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB641A88F1 for ; Wed, 25 Feb 2015 13:41:20 -0800 (PST) Received: by iecar1 with SMTP id ar1so8809443iec.11 for ; Wed, 25 Feb 2015 13:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TjPnKBz3YJ9Mvei8DNIsgzasxQQCOoJyuctFz9jcT64=; b=bwED3M3PcSNhOHGA1WFVSUVeosb4HdtMUmZhX1T0HXMqUwob7AG1i38Lwu7QAaZama i74iENCx0CkbRN6OA67HI1jpuVV0x+PDqN6eTsaQCjzCa6TeseY9NWGMb/ceHbC+JJae tB3KbZoC09dQXMPPkCjFrmcUvUsJc6SBtgURZ92ftAjGpztVB9gWS5sMbjhmkgCWRuWX YMbMdDse5sNjkEI9+lAWsvN1y4p43KFBh43jEauuQW2gBFOXzxO8tylrx4l/2Kh8HSZ2 Oh2lrwIN1XB4LlmM/Ub16NQ4UOZrVl+SrbdgK3YOayKzKZm1U9XorEGoLW8YJKzBvQma i74w== MIME-Version: 1.0 X-Received: by 10.42.204.205 with SMTP id fn13mr6267545icb.67.1424900479607; Wed, 25 Feb 2015 13:41:19 -0800 (PST) Received: by 10.64.80.193 with HTTP; Wed, 25 Feb 2015 13:41:19 -0800 (PST) In-Reply-To: <20150225191500.GZ1260@mournblade.imrryr.org> References: <001a01d04f19$b0292e90$107b8bb0$@augustcellars.com> <20150223035230.GD1260@mournblade.imrryr.org> <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> <20150225181322.GU1260@mournblade.imrryr.org> <20150225191500.GZ1260@mournblade.imrryr.org> Date: Wed, 25 Feb 2015 13:41:19 -0800 Message-ID: From: Brian Dickson To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=20cf30426de4ed6940050ff07ece Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 21:41:23 -0000 --20cf30426de4ed6940050ff07ece Content-Type: text/plain; charset=UTF-8 Top-reply to raise (IMHO) a major issue: This is not only a "publish vs discover" issue, it also is dangerously close to the IDNA rat-hole. I wasn't around when the latter came up, but I think DNSEXT dodged a bullet very wisely, by making it the applications' responsibility to handle any/all case folding beyond ASCII. There are also scale issues, e.g. consider use cases where #users in a domain vary in order of magnitude. What works for O(10e3) does not work for O(10e6), and definitely does not work for O(10e9). There are implications to DNS resolution & caching, if you consider stub, recursive, and authoritative actors. It may be the case that multiple queries need to be done by the stub, regardless of approach. However, if policy discovery involves looking up a single common record per DNS zone (e.g. rhs of email address), then this is cacheable and reduces both the size of the publishing zone, as well as the number of queries by the recursive to the authoritative, per client query. I implore everyone to please consider the design: _casefolding RRTYPE RDATA as a way of allowing the zone owner to publish all the case-folding rules for the zone, and require the client to use this to discover the canonical (published) owner name for a given email address. Brian P.S. For those not familiar with it: The IDNA rat-hole involves case-folding of >2:1, as well as things like Greek language where there are lots of rules governing variant code points depending on context (first/last letter of a word). Putting that into DNS would have been an absolute nightmare, and pushing back on that request was IMHO the right thing to do. On Wed, Feb 25, 2015 at 11:15 AM, Viktor Dukhovni wrote: > On Wed, Feb 25, 2015 at 02:01:38PM -0500, Paul Wouters wrote: > > > On Wed, 25 Feb 2015, Viktor Dukhovni wrote: > > > > >Once the client is making two queries, why accept collisions? Are > > >we (after all these years) finally defining RFC-822/2822/5322 local > > >parts to be case-insensitive? (Price of progress and all that?) > > > > > >Is a CNAME per-user really a major burden? > > > > It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul > > paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P > > One CNAME per case-insensitive name (if the preferred form is mixed > or upper case). Those other names you're mentioning if they all > share the same underlying keys would be CNAMEs you'd have to create > with or without my proposal for a mechanism to publish case-insensitive > names. > > > The client needs smart logic anyway, and the client at least has a user > > it can interact with. It can ask "A key for Paul@nohats.ca does not > > exist but there is a key for paul@nohats.ca". > > Why ask the user, when the server can just publish the fact that > all upper/mixed-case veriants of "paul" are the same mailbox. > > > Needing to roll out between 2 and 4 different capitalizations for > > different [Ff]irstname.[Ll]astname makes everything more errorprone > > and the client still needs its logic and user interaction. > > The I don't how you get to "4". You can publish exactly one owner > for each case-insensitive "LocalPart", no CNAMEs required if you > are willing to accept clients making two queries to find keys in > your domain (space/time trade-off): > > SHA2-224(localpart@lowercase) IN > > Optionally, for faster queries, if the mailbox has a preferred > form: > > SHA2-224(LocalPart) IN > SHA2-224(localpart@lowercase) IN CNAME SHA2-224(LocalPart) > > If there's also a "Local.Part" and "local.part" to go with it, that > it is completely separate from my proposal which deals only with > handling case-insensitive matching. The overhead of supporting > case-insensitive matching is at most a second (CNAME) record for > each record that would be there in the absence of the proposal. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --20cf30426de4ed6940050ff07ece Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Top-reply to raise (IMHO) a major issue:

This is not only a "publish vs discover" issue, it also is dang= erously close to the IDNA rat-hole.

I wasn't a= round when the latter came up, but I think DNSEXT dodged a bullet very wise= ly, by making it the applications' responsibility to handle any/all cas= e folding beyond ASCII.

There are also scale issue= s, e.g. consider use cases where #users in a domain vary in order of magnit= ude. What works for O(10e3) does not work for O(10e6), and definitely does = not work for O(10e9).

There are implications to DN= S resolution & caching, if you consider stub, recursive, and authoritat= ive actors. It may be the case that multiple queries need to be done by the= stub, regardless of approach. However, if policy discovery involves lookin= g up a single common record per DNS zone (e.g. rhs of email address), then = this is cacheable and reduces both the size of the publishing zone, as well= as the number of queries by the recursive to the authoritative, per client= query.

I implore everyone to please consider the = design:

_casefolding RRTYPE RDATA as a way of allo= wing the zone owner to publish all the case-folding rules for the zone, and= require the client to use this to discover the canonical (published) owner= name for a given email address.

Brian
<= br>
P.S. For those not familiar with it: The IDNA rat-hole involv= es case-folding of >2:1, as well as things like Greek language where the= re are lots of rules governing variant code points depending on context (fi= rst/last letter of a word). Putting that into DNS would have been an absolu= te nightmare, and pushing back on that request was IMHO the right thing to = do.

On= Wed, Feb 25, 2015 at 11:15 AM, Viktor Dukhovni <ietf-dane@dukhovni.o= rg> wrote:
On Wed, Feb 25, 2015 at 02:01:38PM -0500, Paul Wouters wrote:

> On Wed, 25 Feb 2015, Viktor Dukhovni wrote:
>
> >Once the client is making two queries, why accept collisions?=C2= =A0 Are
> >we (after all these years) finally defining RFC-822/2822/5322 loca= l
> >parts to be case-insensitive?=C2=A0 (Price of progress and all tha= t?)
> >
> >Is a CNAME per-user really a major burden?
>
> It's not one CNAME, it is many CNAMEs. You'll be hashing paul,= Paul
> paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard := P

One CNAME per case-insensitive name (if the preferred form is mixed<= br> or upper case).=C2=A0 Those other names you're mentioning if they all share the same underlying keys would be CNAMEs you'd have to create
with or without my proposal for a mechanism to publish case-insensitive
names.

> The client needs smart logic anyway, and the client at least has a use= r
> it can interact with. It can ask "A key for Paul@nohats.ca does not
> exist but there is a key for paul@no= hats.ca".

Why ask the user, when the server can just publish the fact that
all upper/mixed-case veriants of "paul" are the same mailbox.

> Needing to roll out between 2 and 4 different capitalizations for
> different [Ff]irstname.[Ll]astname makes everything more errorprone > and the client still needs its logic and user interaction.

The I don't how you get to "4".=C2=A0 You can publish = exactly one owner
for each case-insensitive "LocalPart", no CNAMEs required if you<= br> are willing to accept clients making two queries to find keys in
your domain (space/time trade-off):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHA2-224(localpart@lowercase) IN <RDATA><= br>
Optionally, for faster queries, if the mailbox has a preferred
form:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHA2-224(LocalPart)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0IN <RDATA>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHA2-224(localpart@lowercase)=C2=A0 =C2=A0IN CN= AME SHA2-224(LocalPart)

If there's also a "Local.Part" and "local.part" to = go with it, that
it is completely separate from my proposal which deals only with
handling case-insensitive matching.=C2=A0 The overhead of supporting
case-insensitive matching is at most a second (CNAME) record for
each record that would be there in the absence of the proposal.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--20cf30426de4ed6940050ff07ece-- From nobody Wed Feb 25 16:31:44 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236C21A924E for ; Wed, 25 Feb 2015 16:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA07XXDZh6nX for ; Wed, 25 Feb 2015 16:31:40 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C4E1A923E for ; Wed, 25 Feb 2015 16:31:40 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 76ED4282F4D; Thu, 26 Feb 2015 00:31:39 +0000 (UTC) Date: Thu, 26 Feb 2015 00:31:39 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20150226003139.GK1260@mournblade.imrryr.org> References: <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> <20150225181322.GU1260@mournblade.imrryr.org> <20150225191500.GZ1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 00:31:42 -0000 On Wed, Feb 25, 2015 at 01:41:19PM -0800, Brian Dickson wrote: > There are implications to DNS resolution & caching, if you consider stub, > recursive, and authoritative actors. It may be the case that multiple > queries need to be done by the stub, regardless of approach. However, if > policy discovery involves looking up a single common record per DNS zone > (e.g. rhs of email address), then this is cacheable and reduces both the > size of the publishing zone, as well as the number of queries by the > recursive to the authoritative, per client query. If by RHS of email address you mean the domain part (the local part being the LHS), then indeed designs are possible where the case folding rules are published via a single per-domain key. However, this does not substantively impact the scalability of DNS caching, by which I mean that the number of cache entries is increased by a factor of two rather than some much larger factor. > _casefolding RRTYPE RDATA as a way of allowing the zone owner to publish > all the case-folding rules for the zone, and require the client to use this > to discover the canonical (published) owner name for a given email address. This complicates the client code, but avoids the factor of two in the number of cached records. We would still however need O(10e9) records in zones like gmail.com. The only way to eliminate that problem is to do per-user lookups via an online query service (whose location is published via DNS) rather than finding users directly in DNS. -- Viktor. From nobody Wed Feb 25 17:24:05 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49EF1A92BB for ; Wed, 25 Feb 2015 17:24:03 -0800 (PST) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw7FPhHLXMgc for ; Wed, 25 Feb 2015 17:24:01 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693C01A007A for ; Wed, 25 Feb 2015 17:24:01 -0800 (PST) Received: by iecrp18 with SMTP id rp18so10085929iec.9 for ; Wed, 25 Feb 2015 17:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hZk9fndfBhXwgHtP5o/9y7UdtFqcFZmPTCsk670e2BU=; b=CSlI17S3tEkHC8CMBftXY0p8ErU15NoHsYSTNfuWWJqmrrkyDSB9Y/6nicVR2WL8Hr 21SGNay5agwc1QzeV/H75tSO/ANlOF9hbmlsFzAaZTPob0dF2V37ivp7olgapB8TPpbP mmEHFZ2u35iqnwfXYkbICyv0R9Jn2PyN0hNBf1X8IDaLMa010Lo+APD0s2KmIN0BAOS4 lvCmmwLyub5Jmjd6smKTO8cW0i8bSQnvB0tdEa6xsb+NQFYJCUu+H2WnQ+EPu9mQqxCh SenEZZQm18NMXDCCukgp1PUE5EKDsnIjK9wsAjBEmW3YlRhOsO6zz8ifh1mrh4WOpkm0 v+zg== MIME-Version: 1.0 X-Received: by 10.107.169.42 with SMTP id s42mr8579160ioe.46.1424913840553; Wed, 25 Feb 2015 17:24:00 -0800 (PST) Received: by 10.64.80.193 with HTTP; Wed, 25 Feb 2015 17:24:00 -0800 (PST) In-Reply-To: <20150226003139.GK1260@mournblade.imrryr.org> References: <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> <20150225181322.GU1260@mournblade.imrryr.org> <20150225191500.GZ1260@mournblade.imrryr.org> <20150226003139.GK1260@mournblade.imrryr.org> Date: Wed, 25 Feb 2015 17:24:00 -0800 Message-ID: From: Brian Dickson To: "dane@ietf.org" Content-Type: multipart/alternative; boundary=001a1142dc0c4d4393050ff39bc9 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:24:04 -0000 --001a1142dc0c4d4393050ff39bc9 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 25, 2015 at 4:31 PM, Viktor Dukhovni wrote: > On Wed, Feb 25, 2015 at 01:41:19PM -0800, Brian Dickson wrote: > > > There are implications to DNS resolution & caching, if you consider stub, > > recursive, and authoritative actors. It may be the case that multiple > > queries need to be done by the stub, regardless of approach. However, if > > policy discovery involves looking up a single common record per DNS zone > > (e.g. rhs of email address), then this is cacheable and reduces both the > > size of the publishing zone, as well as the number of queries by the > > recursive to the authoritative, per client query. > > > However, this does not substantively impact the scalability of DNS > caching, by which I mean that the number of cache entries is > increased by a factor of two rather than some much larger factor. > For all but the most unusual domains, I would expect the user queries to be all long-tail, with no substantial busy user set. So, the caching of the policy record improves client query count (1 vs 2), times total volume to the zone. I would even expect that individual user entries to have TTL = 0, as there is little to no value in caching individual records. (Stubs might briefly cache, as might MTAs, but that is at the app layer, not the DNS resolver.) The real problem is the number of entries required in the zone. (see below) > > > _casefolding RRTYPE RDATA as a way of allowing the zone owner to publish > > all the case-folding rules for the zone, and require the client to use > this > > to discover the canonical (published) owner name for a given email > address. > > This complicates the client code, but avoids the factor of two in > the number of cached records. > > To use the gmail example, I just did a test. I was previously unaware of the "s/\.//g" behavior. But, it is real. So, I sent mail to a never-before-used variant of my name, "br.i.an" instead of "brian". Lo and behold, it was delivered to my mailbox. If the goal was to preserve this behavior, while having MUAs look up keys, without a policy mechanism, it would be necessary to publish 2^(N-1) records for every name of length N. If the average length of a name were 11 characters, then 2^10 = 1024 records would be needed per user. This takes O(10e9) and turns it into O(10e12), of thing which have to be hashed, signed, and then NSEC/NSEC3-ified. So, the publishing side takes a disproportionate hit. Have the client understand a very limited set of case-folding rules, which could be used universally, is clearly preferable, even to the client, IMHO. Brian --001a1142dc0c4d4393050ff39bc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 25, 2015 at 4:31 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:
On Wed, Feb 25, 2015 at 01:41:19PM -0800, Brian Dickson wrote:

> There are implications to DNS resolution & caching, if you conside= r stub,
> recursive, and authoritative actors. It may be the case that multiple<= br> > queries need to be done by the stub, regardless of approach. However, = if
> policy discovery involves looking up a single common record per DNS zo= ne
> (e.g. rhs of email address), then this is cacheable and reduces both t= he
> size of the publishing zone, as well as the number of queries by the > recursive to the authoritative, per client query.
=C2=A0

However, this does not substantively impact the scalability of DNS
caching, by which I mean that the number of cache entries is
increased by a factor of two rather than some much larger factor.

For all but the most unusual domains, I would ex= pect the user queries to be all long-tail, with no substantial busy user se= t.

So, the caching of the policy record improves c= lient query count (1 vs 2), times total volume to the zone.

<= /div>
I would even expect that individual user entries to have TTL =3D = 0, as there is little to no value in caching individual records.
= (Stubs might briefly cache, as might MTAs, but that is at the app layer, no= t the DNS resolver.)

The real problem is the numbe= r of entries required in the zone. (see below)
=C2=A0

> _casefolding RRTYPE RDATA as a way of allowing the zone owner to publi= sh
> all the case-folding rules for the zone, and require the client to use= this
> to discover the canonical (published) owner name for a given email add= ress.

This complicates the client code, but avoids the factor of two in the number of cached records.=C2=A0


To use the gmail example, I just did a test.

I wa= s previously unaware of the "s/\.//g" behavior. But, it is real.<= /div>

So, I sent mail to a never-before-used variant of = my name, "br.i.an" instead of &quo= t;brian".
Lo and behold, it was delivered to my mailbox.

If the goal was to preserve this behavior, while havi= ng MUAs look up keys, without a policy mechanism, it would be necessary to = publish 2^(N-1) records for every name of length N.

If the average length of a name were 11 characters, then 2^10 =3D 1024 re= cords would be needed per user.=C2=A0
This takes O(10e9) and turn= s it into O(10e12), of thing which have to be hashed, signed, and then NSEC= /NSEC3-ified.

So, the publishing side takes a disp= roportionate hit.

Have the client understand a ver= y limited set of case-folding rules, which could be used universally, is cl= early preferable, even to the client, IMHO.

Brian<= /div>

--001a1142dc0c4d4393050ff39bc9-- From nobody Wed Feb 25 17:48:57 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247E1A92F3 for ; Wed, 25 Feb 2015 17:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbatM8XQ7rRO for ; Wed, 25 Feb 2015 17:48:46 -0800 (PST) Received: from ryujin.darkdna.net (ryujin.darkdna.net [69.164.196.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C44B1A92E3 for ; Wed, 25 Feb 2015 17:48:46 -0800 (PST) Received: from localhost (otohime.ddna [IPv6:fdcf:3c00:e001::101]) by ryujin.darkdna.net (Postfix) with ESMTP id 3ksxjp09Blz195W for ; Thu, 26 Feb 2015 01:48:46 +0000 (UTC) Received: from ryujin.darkdna.net ([IPv6:fdcf:3c00:e001::100]) by localhost (otohime.darkdna.net [IPv6:fdcf:3c00:e001::101]) (amavisd-new, port 10026) with ESMTP id NBVDMYaRGtj3 for ; Thu, 26 Feb 2015 01:48:45 +0000 (UTC) Received: from [192.168.1.3] (pool-71-252-204-46.dllstx.fios.verizon.net [71.252.204.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ryujin.darkdna.net (Postfix) with ESMTPSA id 3ksxjn4bK6z18y6 for ; Thu, 26 Feb 2015 01:48:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkdna.net; s=mail; t=1424915325; bh=YzBNilqf3hlHPphP3ZKUyHxOdoCRIynO9bXCWIDhaqI=; h=Date:From:To:Subject:References:In-Reply-To; b=bDbhpP1BqVL9cFmFUTb93qP5mF8l8yRR3gMOlhVk3/SbFM1nH2ie1MazbeD0M6g/O rPRZkikmz75xJryjZ0lkBGzxe6gXbhx9wZ7ZzMdyAW0PUsu1TKH3Hnwf+gc2BMFL3w dluq89EJO4iDSpwVvSzwSe4e0cIOdXowhWwHRQd4= Message-ID: <54EE7B64.4020909@darkdna.net> Date: Wed, 25 Feb 2015 19:48:20 -0600 From: Coyo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dane@ietf.org References: <001b01d04f1c$f626c940$e2745bc0$@augustcellars.com> <20150223040833.GF1260@mournblade.imrryr.org> <20150223225630.GO1260@mournblade.imrryr.org> <20150225181322.GU1260@mournblade.imrryr.org> <20150225191500.GZ1260@mournblade.imrryr.org> <20150226003139.GK1260@mournblade.imrryr.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030004070101000503030303" Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 01:48:48 -0000 This is a multi-part message in MIME format. --------------030004070101000503030303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2/25/2015 7:24 PM, Brian Dickson wrote: > So, I sent mail to a never-before-used variant of my name, "br.i.an > " instead of "brian". > Lo and behold, it was delivered to my mailbox. Gmail also ignores everything after + so brian+dontspamme is sent to brian. this can be helpful for writing spam filtering rules. --------------030004070101000503030303 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 2/25/2015 7:24 PM, Brian Dickson wrote:
So, I sent mail to a never-before-used variant of my name, "br.i.an" instead of "brian".
Lo and behold, it was delivered to my mailbox.

Gmail also ignores everything after + so brian+dontspamme is sent to brian.
this can be helpful for writing spam filtering rules.
--------------030004070101000503030303-- From nobody Thu Feb 26 06:33:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8111A0155 for ; Thu, 26 Feb 2015 06:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtzlpzO1tUzJ for ; Thu, 26 Feb 2015 06:33:24 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCEE1A0149 for ; Thu, 26 Feb 2015 06:33:24 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ktGgz70Lpz6G; Thu, 26 Feb 2015 15:33:19 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=k0D8NQAI; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1vCxaSLrA3Eq; Thu, 26 Feb 2015 15:33:18 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 26 Feb 2015 15:33:18 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 11671813B1; Thu, 26 Feb 2015 09:33:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1424961198; bh=jtAgkROT8eapSBqwhGLwv97Jt7qhEGmzOkeE4GMoyPQ=; h=Date:From:To:cc:Subject; b=k0D8NQAIwJdxXyRLsMeTjFFC/mm4LwSP7gTeu4I/usaeWFpj3HjO7392KgkwRMXM0 u2Cc3bDg4s7Kr0vkPj7Ez/7GJd6Dy8gJvXGCCuq4pokpyg6T/OXnFoeP9x5BxM6nZF w8rXpl81nk1KEcgFE0Dk8jdY+Tv6TBT8SmJk3n+M= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t1QEXHNH029198; Thu, 26 Feb 2015 09:33:17 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 26 Feb 2015 09:33:17 -0500 (EST) From: Paul Wouters To: Brian Dickson , Viktor Dukhovni Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Cc: "dane@ietf.org" Subject: [dane] proposed text for openpgpkey email translation rules X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 14:33:31 -0000 On Wed, 25 Feb 2015, Brian Dickson wrote: > To use the gmail example, I just did a test. > > I was previously unaware of the "s/\.//g" behavior. But, it is real. > > So, I sent mail to a never-before-used variant of my name, "br.i.an" instead of "brian". > Lo and behold, it was delivered to my mailbox. > > If the goal was to preserve this behavior, while having MUAs look up keys, without a policy mechanism, it would be necessary to publish > 2^(N-1) records for every name of length N. > > If the average length of a name were 11 characters, then 2^10 = 1024 records would be needed per user. > This takes O(10e9) and turns it into O(10e12), of thing which have to be hashed, signed, and then NSEC/NSEC3-ified. > > So, the publishing side takes a disproportionate hit. > > Have the client understand a very limited set of case-folding rules, which could be used universally, is clearly preferable, even to the > client, IMHO. Agreed. I think the document(s) should stay away from interpreting the LHS. But it would be worth adding a subsection into the Location section. How about: 3.1 Email address variants Most SMTP servers treat the user part of the email address as case insensitive. This means that "Hugh@example.com" could be different email address from "hugh@example.com" but both email addresses would end up at the same enduser. The OPENPGPKEY lookup for both addresses would result in a different SHA-224 value. As some input methods to email clients auto-correct to using an uppercase for a first name, an email client supporting this document might want to interact with the user and try a lower-cased username for an OPENPGPKEY lookup. Other mail servers allow other kind of email translation rules, such as automatically matching "username+anystring@example.com" to "username@example.com", or allowing "." characters to be placed anywhere in the address so "first.last@example.com" matches "firstlast@example.com". While publishers can add duplicate or CNAME entries for the OPENPGPKEY records to match these variants, email clients might want to try some (obvious) variations. I think this would also apply to the SMIMEA document. Paul From nobody Thu Feb 26 07:23:51 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3413A1A0362 for ; Thu, 26 Feb 2015 07:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4_-l12_Ad5N for ; Thu, 26 Feb 2015 07:23:47 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC111A0158 for ; Thu, 26 Feb 2015 07:23:45 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1QFNh4H021348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 26 Feb 2015 10:23:44 -0500 Received: from pspacek.brq.redhat.com (unused [10.34.128.7] (may be forged)) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1QFNfen024051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 26 Feb 2015 10:23:43 -0500 Message-ID: <54EF3A7D.6070809@redhat.com> Date: Thu, 26 Feb 2015 16:23:41 +0100 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey: objection about keyring format documentation X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 15:23:50 -0000 On 20.2.2015 21:30, Warren Kumari wrote: > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. IMHO current version *should be rejected* because further clarification to keyring format is needed. See previous discussion on http://www.ietf.org/mail-archive/web/dane/current/msg07227.html As I already said, I believe that -01 version does not define an interoperable standard. The main problem is that http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01#section-2.1 2.1. The OPENPGPKEY RDATA component The RDATA (or RHS) of an OPENPGPKEY Resource Record contains a single value consisting of a [RFC4880] formatted OpenPGP public keyring. references http://tools.ietf.org/html/rfc4880#section-3.6 3.6. Keyrings A keyring is a collection of one or more keys in a file or database. Traditionally, a keyring is simply a sequential list of keys, but may be any suitable database. It is beyond the scope of this standard to discuss the details of keyrings or other databases. and this definitely is not a definition you could use for implementation. Current format of records can stay as is but it has to be clearly documented so we do not rely on current GPG implementation. 'It is beyond the scope of this standard to discuss the details of keyrings or other databases.' is simply not sufficient. -- Petr Spacek @ Red Hat From nobody Sat Feb 28 13:48:32 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417F01A001B for ; Sat, 28 Feb 2015 13:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00WHrSMxytYH for ; Sat, 28 Feb 2015 13:48:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126C51A001A for ; Sat, 28 Feb 2015 13:48:28 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B85C9282FC2; Sat, 28 Feb 2015 21:48:27 +0000 (UTC) Date: Sat, 28 Feb 2015 21:48:27 +0000 From: Viktor Dukhovni To: "" Message-ID: <20150228214827.GA1260@mournblade.imrryr.org> References: <20141209095813.GP285@mournblade.imrryr.org> <20150108011529.GU7322@mournblade.imrryr.org> <18B6C626-B27B-4EE9-A3E2-32CD43B195FA@ogud.com> <20150220220921.GH1260@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150220220921.GH1260@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dane] WGLC: DANE-SMTP (final operational guidance tweaks?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 21:48:31 -0000 On Fri, Feb 20, 2015 at 10:09:21PM +0000, Viktor Dukhovni wrote: > > The github repository contains a version of the document that addresses > > all the comments received. Editors please post ASAP. > > A -14 version has been pushed. I've not yet received any feedback on > the possibility of extending the operational considerations section > based on the last few months of operational experience. Please > advise... Perhaps making this more concrete will help. I can publish a -15 with the following changes: * In Publisher Operational considerations again mention the need to avoid PKIX-TA/PKIX-EE * In Publisher Operational considerations note that DANE TLSA and MTAs that only offer STARTTLS selectively (e.g. to client that pass greylisting) don't mix. * Note that some software cannot send root trust-anchors, if so the server TLSA records need to list an intermediate CA or use DANE-EE(3). * In section 3.1.3 note that the SHOULD NOT for PKIX-TA/PKIX-EE applies only to MTA-to-MTA SMTP, and MUA-to-MSA is not in scope. FYI, the current main culprit for selective STARTTLS is "spamd", and its authors are reputedly working on STARTTLS support to address the issue! The software simply had no STARTTLS support, and handles the first transaction with a new client before allowing connections to the real MTA. There was no intention to specifically deny TLS to new clients. As for inability to send the root CA, reportedly that's an issue with Microsoft Exchange, where either the Exchange software or Schannel or both cannot be configured to put the root CA cert on the wire. Have not tried this myself. The XML diff is below my signature. Most of the operational issues over the last few month are not SMTP specific, and the corresponding operational guidace will be added to the OPS draft. Should I add these to -15 before IETF LC? -- Viktor. diff --git a/draft-ietf-dane-smtp-with-dane b/draft-ietf-dane-smtp-with-dane index 55d6be3..60eff9e 100644 --- a/draft-ietf-dane-smtp-with-dane +++ b/draft-ietf-dane-smtp-with-dane @@ -1311,10 +1311,20 @@ path length or name constraints. -
+
+ +Note, this section applies to MTA-to-MTA SMTP on port 25. That is, +to servers that are the SMTP servers for one or more destination +domains. Other uses of SMTP, such as in MUA-to-MSA submission on +ports 587 or 465 are out of scope for this document. Where those +other uses also employ TLS opportunistically and/or depend on DNSSEC +as a result of DNS-based discovery of service location, the relevant +specifications should, as appropriate, arrive at similar conclusions. + + -As noted in the introduction, SMTP clients cannot, without relying +As noted in the introduction, sending MTAs cannot, without relying on DNSSEC for secure MX records and DANE for STARTTLS support signaling, perform server identity verification or prevent STARTTLS downgrade attacks. The use of PKIX CAs offers no added security @@ -1324,12 +1334,13 @@ convenient non-PKIX certificate usage. -SMTP servers SHOULD NOT publish TLSA RRs with certificate usage -PKIX-TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be -configured with a suitably complete set of trusted public CAs. -Lacking a complete set of public CAs, clients would not be able to -verify the certificates of SMTP servers whose issuing root CAs are -not trusted by the client. +Therefore, TLSA records for the port 25 SMTP service used by client +MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) +or PKIX-EE(1). SMTP client MTAs cannot be expected to be configured +with a suitably complete set of trusted public CAs. Lacking a +complete set of public CAs, MTA clients would not be able to verify the +certificates of SMTP servers whose issuing root CAs are not trusted +by the client. @@ -1734,10 +1745,31 @@ that server.
+As explained in server operators SHOULD +NOT publish TLSA records for their MTAs (port 25 SMTP) with certificate +usages PKIX-TA(0) or PKIX-EE(1). + + + +Some MTAs enable STARTTLS selectively. For example they might only +support STARTTLS with clients that have previously demonstrated +"proper MTA behaviour", for example by retrying the delivery of +deferred messages (greylisting). If such an MTA publishes DANE +TLSA records, sending MTAs that implement this specification will +not attempt the initial cleartext SMTP transaction needed to +establish the "proper MTA behaviour", because they cannot establish +the required channel security. Server operators MUST NOT implement +selective STARTTLS if they also want to support DANE TLSA. + + + SMTP servers that publish certificate usage DANE-TA(2) associations MUST include the TA certificate in their TLS server certificate chain, even when that TA certificate is a self-signed -root certificate. +root certificate. With some SMTP server software it is not possible to +include root CA certificates in the server chain. Such servers need to +either publish DANE-TA(2) records for an intermediate certificate or +to use DANE-EE(3). From nobody Sat Feb 28 15:08:48 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78761A0055 for ; Sat, 28 Feb 2015 15:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiM0ydZORIOi for ; Sat, 28 Feb 2015 15:08:46 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01ABF1A0053 for ; Sat, 28 Feb 2015 15:08:46 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 2BBF01DDD9; Sat, 28 Feb 2015 23:08:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1425164925; bh=Oq7kt891uhBLBe5S5zjVSzI3U9zC7VmOZbagbTuyEuI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YtwySKOAQdO4R0hx6y9Ko34/i7ZvFaQ0Xbf1Bx/uBRmvMTpzWHJENEuwwnFtwLOsi 8epLKxbVfN9UsBDAqYBzQ8t30A7t2ZBkCrVWxGE4W2NJkrgOkJIcfc+RQi/cWNKc2/ p1ucW4ibHZohYqYKDSbeaQoImCXwwcksBYSRMvSM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id DE0BA106F92D6; Sat, 28 Feb 2015 23:05:53 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20150228214827.GA1260@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 28 Feb 2015 21:48:27 +0000") References: <20141209095813.GP285@mournblade.imrryr.org> <20150108011529.GU7322@mournblade.imrryr.org> <18B6C626-B27B-4EE9-A3E2-32CD43B195FA@ogud.com> <20150220220921.GH1260@mournblade.imrryr.org> <20150228214827.GA1260@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 28 Feb 2015 18:05:53 -0500 Message-ID: Lines: 32 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:150228:ietf-dane@dukhovni.org::v0unjKBnqSNYY71V:00000000000000000000000000000000000000lwOPr X-Hashcash: 1:28:150228:dane\@ietf.org\::TNI+2bCOZ2+lCwn4:08weSA X-Hashcash: 1:28:150228:dane@ietf.org::jmZYMUtIgUJIC8se:0007ImmA Archived-At: Cc: "" Subject: Re: [dane] WGLC: DANE-SMTP (final operational guidance tweaks?) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 23:08:47 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> * In Publisher Operational considerations again mention the need VD> to avoid PKIX-TA/PKIX-EE Do mention that the reason is that most MXs do not configure the OS's CA suite by default, and most operators leave that as is. Ie, that it is not a fundamental limitation of SMTP but rather a nearly ubiquitous reality of how they are configured for port 25. VD> * In Publisher Operational considerations note that DANE TLSA and VD> MTAs that only offer STARTTLS selectively (e.g. to client that VD> pass greylisting) don't mix. +inf on that! VD> * Note that some software cannot send root trust-anchors, if so VD> the server TLSA records need to list an intermediate CA or use VD> DANE-EE(3). Also helpful. VD> * In section 3.1.3 note that the SHOULD NOT for PKIX-TA/PKIX-EE VD> applies only to MTA-to-MTA SMTP, and MUA-to-MSA is not in scope. VD> Should I add these to -15 before IETF LC? +1. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6