From nobody Wed Jul 2 09:46:14 2014 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 20CA91A0022 for ; Wed, 2 Jul 2014 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=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 IkSUdrCzEco2 for ; Wed, 2 Jul 2014 09:46:12 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.225.22]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0E71B2840 for ; Wed, 2 Jul 2014 09:46:12 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 5E635ADA6AC91; Wed, 2 Jul 2014 11:46:11 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 43B6EADA6A366 for ; Wed, 2 Jul 2014 11:46:09 -0500 (CDT) Received: from [173.73.128.252] (port=51868 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2Nfc-0006Hf-EC; Wed, 02 Jul 2014 11:46:08 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Wed, 2 Jul 2014 12:46:04 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3E23DF2F-86F1-4D2F-95F7-46F3DBCA8F3B@ieca.com> References: To: Warren Kumari X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.128.252 X-Exim-ID: 1X2Nfc-0006Hf-EC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:51868 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uWtD9159-IppO_dzu-6GQFVKQBw Cc: draft-gilmore-dane-rawkeys-00@tools.ietf.org, "" Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 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, 02 Jul 2014 16:46:13 -0000 I support adoption of this draft. spt On Jun 23, 2014, at 06:16, Warren Kumari wrote: > Dear DANE WG, > > This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00. > The draft is available here: > https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys-00/ > > This document was written in response to a request, and so we are > compressing the more traditional 2 week call for adoption to instead > be a single week. > > Please let us know clearly if you *object* to this document being > adopted, with a clear explanation of why. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends Monday 07-Jul-2014. > > Thanks, > Warren Kumari > (as DANE WG co-chair) > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jul 2 10:07:26 2014 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 A9E1F1A05C3 for ; Wed, 2 Jul 2014 10:07:03 -0700 (PDT) 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 fshRSFnn5eMN for ; Wed, 2 Jul 2014 10:06:58 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEC91B2832 for ; Wed, 2 Jul 2014 10:06:57 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so9990455wib.12 for ; Wed, 02 Jul 2014 10:06:52 -0700 (PDT) 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=8we2Yd2QbAr16L8GwH9JpY//9hjcwmRJrLjmvFtFPd4=; b=bsjkWNIDnPs7VztPNwQj80ideUtN+o+xv0eXPXQSwY8ao5rCB82E7nxJmjoVz5SFW3 4fACY2QOu03Wcz0trCaOZ7ImHbvY/cq2Wg3FYiGvmCtoxTYL2b3QvLyJiXH/zrjISNTi UZYCIRBfo/ceFYY/PhhJM7TKeeBEyUqJaBu+yrlRA4nHMRwXHQIWCMgO7YAnW/YSHpzE cdi9DHoTdQKsSHXet1D/DMRWHe//3bkrxDYys7JEgzgpMJPiTkzJ+6XWHy/y/OlOXhbo XBGp8vtvqYtY+PRKpbbOJqSkmEKbbXQ2ljfk0sk9sr8afT9IHJV8QV1CluqxHWbkVuQj hBCw== X-Gm-Message-State: ALoCoQkviRQAxsM4G3xMMdofZwxBMICADwzfEQEFJRqCnQXzWVrBArucO8GG0B8mKUIN7zANiMen MIME-Version: 1.0 X-Received: by 10.180.90.233 with SMTP id bz9mr5540972wib.42.1404320812055; Wed, 02 Jul 2014 10:06:52 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Wed, 2 Jul 2014 10:06:51 -0700 (PDT) In-Reply-To: <3E23DF2F-86F1-4D2F-95F7-46F3DBCA8F3B@ieca.com> References: <3E23DF2F-86F1-4D2F-95F7-46F3DBCA8F3B@ieca.com> Date: Wed, 2 Jul 2014 13:06:51 -0400 Message-ID: From: Warren Kumari To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9RDSn9L-kAaoa_qg2PCEiY0NxDU Cc: draft-gilmore-dane-rawkeys-00@tools.ietf.org, "" Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 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, 02 Jul 2014 17:07:04 -0000 On Wed, Jul 2, 2014 at 12:46 PM, Sean Turner wrote: > I support adoption of this draft. Great! Well, let's adopt it then... :-)[0] I [1] see significant consensus on adoption, and only minor dissent. Once adopted, the document becomes a WG document and the final text / details can be hammered out later. W [0]: The CfA was supposed to close on Monday, but I got sidetracked and forgot to call it. [1]: Mwahahah. That'll teach Olafur to take some well deserved time off, and leave me in charge :-P > > spt > > On Jun 23, 2014, at 06:16, Warren Kumari wrote: > >> Dear DANE WG, >> >> This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00. >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys-00/ >> >> This document was written in response to a request, and so we are >> compressing the more traditional 2 week call for adoption to instead >> be a single week. >> >> Please let us know clearly if you *object* to this document being >> adopted, with a clear explanation of why. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends Monday 07-Jul-2014. >> >> Thanks, >> Warren Kumari >> (as DANE WG co-chair) >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > From nobody Wed Jul 2 10:26:55 2014 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 15B2D1B291D for ; Wed, 2 Jul 2014 10:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=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 r-Y63n-hvXiO for ; Wed, 2 Jul 2014 10:26:51 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [69.93.243.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8DE1B2846 for ; Wed, 2 Jul 2014 10:26:51 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 69E21D7D991D2; Wed, 2 Jul 2014 12:26:48 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id A267DD7D1C78E for ; Wed, 2 Jul 2014 12:18:47 -0500 (CDT) Received: from [173.73.128.252] (port=52144 helo=192.168.1.10) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X2O9I-00045x-R8; Wed, 02 Jul 2014 12:16:54 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <201406210425.s5L4P2eo001257@new.toad.com> Date: Wed, 2 Jul 2014 13:16:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E325436-B2BE-40A4-A8D5-80407622222E@ieca.com> References: <201406210425.s5L4P2eo001257@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.128.252 X-Exim-ID: 1X2O9I-00045x-R8 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.10) [173.73.128.252]:52144 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_zRoaOAmirTkhVmHxr2dC_siLQA Cc: dane@ietf.org Subject: Re: [dane] New I-D on Authenticating Raw Public Keys with DANE TLSA 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, 02 Jul 2014 17:26:53 -0000 Two nits: 0) s3 contains the following: This SubjectPublicKeyInfo structure MUST be encoded in DER encoding [X.660] of Abstract Syntax Notation One (ASN.1) [X.208]. r/X.660/X.690 or just: This SubjectPublicKeyInfo structure MUST be encoded in DER encoding of Abstract Syntax Notation One (ASN.1) [X.690]. Personally, I think that=92s not referring to the X.680/208 is fine = because that=92s what RFC 6898 did, but for completeness I could see = using X.680 instead of X.208: This SubjectPublicKeyInfo structure MUST be encoded in DER encoding [X.690] of Abstract Syntax Notation One (ASN.1) [X.680]. If you decide to go with the X.680 reference (from PKIX): [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. 1) s3: r/(from RFC 6699 section 2.1.1)/(from RFC 6698 section 2.1.1) spt On Jun 21, 2014, at 00:25, John Gilmore wrote: > In an effort to nudge along the process of standardizing the use of > DANE with TLS's use of raw public keys, I have written a short > Internet-Draft that defines how these keys can be authenticated by = using > TLSA records. >=20 > Name: draft-gilmore-dane-rawkeys > Revision: 00 > Title: Authenticating Raw Public Keys with DANE TLSA > Document date: 2014-06-20 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-gilmore-dane-rawkeys-00.txt > Status: = https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys/ > Htmlized: = http://tools.ietf.org/html/draft-gilmore-dane-rawkeys-00 > Abstract: > This document standardizes how the Domain Name System can > authenticate Raw Public Keys. Transport Level Security now has the > option to use Raw Public Keys, but they require some form of = external > authentication. The document updates RFC 6698 to allow the Domain > Name System to standardize the authentication of more types of = keying > material. >=20 > The TLS extension for raw public keys, which inspired this work, is > currently very late in the IETF publication process, but not quite > published, here: >=20 > "Using Raw Public Keys in Transport Layer Security (TLS) > and Datagram Transport Layer Security (DTLS)" > https://www.rfc-editor.org/authors/rfc7250.txt >=20 > John >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Thu Jul 3 11:23:35 2014 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 621F11B2B3C; Thu, 3 Jul 2014 11:23:32 -0700 (PDT) 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 qeds2ZVn9DrL; Thu, 3 Jul 2014 11:23:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 486EA1B2B2F; Thu, 3 Jul 2014 11:23:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703182331.30969.8336.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 11:23:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6zZmHrQRAa5PjGooKj_Yq4h90YI Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-rawkeys-00.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: Thu, 03 Jul 2014 18:23:32 -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 : Authenticating Raw Public Keys with DANE TLSA Author : John Gilmore Filename : draft-ietf-dane-rawkeys-00.txt Pages : 7 Date : 2014-07-03 Abstract: This document standardizes how the Domain Name System can authenticate Raw Public Keys. Transport Level Security now has the option to use Raw Public Keys, but they require some form of external authentication. The document updates RFC 6698 to allow the Domain Name System to standardize the authentication of more types of keying material. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-rawkeys/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-rawkeys-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 16:10:37 2014 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 9F0A81B2A9F for ; Thu, 3 Jul 2014 16:10:34 -0700 (PDT) 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 mgoZED9bqfYU for ; Thu, 3 Jul 2014 16:10:33 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FBD1B2ABC for ; Thu, 3 Jul 2014 16:10:32 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so3087115wiv.8 for ; Thu, 03 Jul 2014 16:10:31 -0700 (PDT) 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=IhnjkG0kNIfwotJz21NqOp/96g4Owiu7oYiXDlxTyts=; b=Pu7vXZcRMbyMAEUlweSdQ0eI8mzK2vNHAdJr7hdbDZ401Kw0Rh93zSFYgapNeJJLcs 3LvHTcaU7H1zEaRI6IsgJ7579x61rqVLIjnmH2UOuagFxTzjwH09GDjk4jJg1tsHSIDS t9T8cEBGoxbwfi3zQZWoGCP8+S83gDfQuz20pXVUK4S3w2DeVvuyyPUCz111pHcP0SDP SrsDKsVMRm4gUv7N6BGy5fAuBc8rpaQSqauYsnEJr7SyT8Hkke5WdMVl1uf5Kz0UAYBC aztU8dY7DSwM9xx+3wtZwhYKlvLt3RUy/BCTAjQCrPCRMLeUvzXbwWPTz6NEhDilU68v 5+pg== X-Gm-Message-State: ALoCoQnPtW/lliQ3ikg5iXfq8VphDsilx1CqOjHLBUZSYaLuzHuQVyJSroUFOQM8S0w2vIULqCVR MIME-Version: 1.0 X-Received: by 10.180.90.132 with SMTP id bw4mr43940926wib.42.1404429031354; Thu, 03 Jul 2014 16:10:31 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Thu, 3 Jul 2014 16:10:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jul 2014 19:10:31 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ZSmkwV29mCBoLXE7WmFeqbrbY9s Subject: Re: [dane] Call for agenda items. 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, 03 Jul 2014 23:10:34 -0000 On Mon, Jun 23, 2014 at 6:22 AM, Warren Kumari wrote: > Hi there DANEites, > > We still have free agenda time for the upcoming London meeting. Please > let us know if you would like some... > > The sooner you request time, the more likely you are to get some... > > Remember, we give priority to documents that have open issues than > would benefit from in person discussion. > Dear all, A reminder to please let us know if you'd like to present on anything (DANE related :-)) in **Toronto**. W > W From nobody Thu Jul 3 23:44:20 2014 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 4AAEA1B2C03; Thu, 3 Jul 2014 23:44:16 -0700 (PDT) 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 E2wUFGgdU_P9; Thu, 3 Jul 2014 23:44:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 969E31B2C05; Thu, 3 Jul 2014 23:44:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704064414.1035.21136.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 23:44:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SefksO-Yih5fWvo2moc04bNUoxg Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-05.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, 04 Jul 2014 06:44:17 -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 : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-05.txt Pages : 27 Date : 2014-07-03 Abstract: This memo clarifies and updates the DANE TLSA protocol based on implementation experience since the publication of the original DANE specification in [RFC6698]. It also contains guidance for DANE implementers and operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-ops-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-05 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 Thu Jul 3 23:44:56 2014 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 B0D761B2C0F for ; Thu, 3 Jul 2014 23:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 WZN0slkFJpik for ; Thu, 3 Jul 2014 23:44:53 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 661991B2C0B for ; Thu, 3 Jul 2014 23:44:53 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C29152C12F; Thu, 3 Jul 2014 23:44:52 -0700 (PDT) From: Wes Hardaker To: Viktor Dukhovni References: <20140624061702.30418.90850.idtracker@ietfa.amsl.com> <20140624062346.GW17723@mournblade.imrryr.org> Date: Thu, 03 Jul 2014 23:44:52 -0700 In-Reply-To: <20140624062346.GW17723@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 24 Jun 2014 06:23:47 +0000") Message-ID: <0legy11v2z.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/A9_Qe8QJHw6_Gt5hsEfnNP0fWg8 Cc: dane@ietf.org Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-04.txt 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, 04 Jul 2014 06:44:54 -0000 Viktor Dukhovni writes: > Wes and I have returned our attention to this document, which is now > slated to be a standards-track update to 6698. Thus the -04 version > is a substantial revision, and very much still a work in progress, a > first step on a new journey. And -05 contains mostly minor editing tweaks. -- Wes Hardaker Parsons From nobody Mon Jul 7 12:37:57 2014 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 D43E61B28A7 for ; Mon, 7 Jul 2014 12:37:54 -0700 (PDT) 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 FeLNJfsM2mBQ for ; Mon, 7 Jul 2014 12:37:52 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8AD1B289C for ; Mon, 7 Jul 2014 12:37:51 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so7306590wiw.5 for ; Mon, 07 Jul 2014 12:37:50 -0700 (PDT) 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=DUB81m9VCsj4abQzlFT2UOmpoAIq799XH/4RaCMvSkY=; b=KA7TMYpo1a79vXPY26QLAqW5Fr+Qu1nooGImaZg1hc7SW68kFx2woUccZ66X3LOtoS bu5PB9VgiQkJHV1JrfjRwwMjSYSS2aclmMh836CKNYVH2nVCMF+85M6Yk5HHXqhqTaHc Cy2QxB6RHBNIJSHixJTT9etQEpjaoeej7QICHMjjwUkiWBmeNYyAUI3l0spP7ns/1cJh vhOsrs+p0bTf3iEZJOj0WIqJlg5oT+7MXxLMJd1u3cOTti+jEr2IVE9Dopjq1ICViP0c wmUMLxz8ec/j8nWUD7zwr2v17uE2DoLgrQN9rTJ9JyrSohrp0Jc93B6FQCCV7sLBFuu3 aBGQ== X-Gm-Message-State: ALoCoQldzBfvy4SZlmXb8evDX2rvJaD6US455pTFAm7CXVB9k5OrAUJGc/tTqr0sPLRPLADAYG87 MIME-Version: 1.0 X-Received: by 10.194.222.230 with SMTP id qp6mr34796169wjc.23.1404761870614; Mon, 07 Jul 2014 12:37:50 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Mon, 7 Jul 2014 12:37:50 -0700 (PDT) In-Reply-To: <20140624062346.GW17723@mournblade.imrryr.org> References: <20140624061702.30418.90850.idtracker@ietfa.amsl.com> <20140624062346.GW17723@mournblade.imrryr.org> Date: Mon, 7 Jul 2014 15:37:50 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/sPO1ApHkSJtAgCg0-WoVYYMlzVE Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-04.txt 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, 07 Jul 2014 19:37:55 -0000 On Tue, Jun 24, 2014 at 2:23 AM, Viktor Dukhovni wrote: > On Mon, Jun 23, 2014 at 11:17:02PM -0700, internet-drafts@ietf.org wrote: > >> This draft is a work item of the DNS-based Authentication of >> Named Entities Working Group of the IETF. >> >> Title : Updates to and Operational Guidance for the DANE Protocol >> Authors : Viktor Dukhovni >> Wes Hardaker >> Filename : draft-ietf-dane-ops-04.txt >> Pages : 27 >> Date : 2014-06-23 >> >> Abstract: >> This memo clarifies and updates the DANE TLSA protocol based on >> implementation experience since the publication of the original >> specification [RFC6698]. It also contains guidance for DANE >> implementers and operators. > > This draft has been on the back-burner for a while, while work on > the SMTP draft took precedence. Wes and I have returned our > attention to this document, which is now slated to be a standards-track > update to 6698. Thus the -04 version is a substantial revision, > and very much still a work in progress, a first step on a new > journey. > > If anyone reviewing the document would like to suggest edits, the best > mechanism is perhaps a pull-request at: > > https://github.com/vdukhovni/ietf.git > > it would I think be useful for the DANE WG to have a more formal > git repository. I believe the TLS WG has one now, and perhaps we > can follow their example. Just FYI, Ops Area / OpsAWG will have a presentation / discussion on "github as a tool" -- will listen to see what they have learned / advice they have, and then strongly considering this. Even if we don't use the git part, the issue tracker is in github is supposed to work nicely (never tried it myself though). We were originally using the IETF provided trac instance for discussing topics on the original DANE documents - this worked well for helping keep discussions on track. One of the upcoming topics / discussions points will likely be the "what all things can be covered in TLSA records and rawkeys" - perhaps we'll use git to try corral this discussion. W > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jul 9 09:28:41 2014 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 CD7961A0377 for ; Wed, 9 Jul 2014 09:28:40 -0700 (PDT) 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 BSCxVNPuLANf for ; Wed, 9 Jul 2014 09:28:39 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853141A0331 for ; Wed, 9 Jul 2014 09:28:39 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so7595950wev.34 for ; Wed, 09 Jul 2014 09:28:38 -0700 (PDT) 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:content-transfer-encoding; bh=5iC1C5Z/AlXOXaaLGQLUWTydkaAMJDmEKRFvJ5dCDKI=; b=jqhuRi8kHMG8/lZ1XWXxzaLDK7w9MXvL+WJ8/tc4jnpzrD/rO1OalzZes36EsSJk/e vgdph1rxa+kq0x1/7E5c/phhLXRtCW7+dnMDlDEq/Ea+3/fgvvXrLTJ7sAkS53TM60rv OflosT2XFhlaMlEblpzJLNkEjxZ9NC+7TPdTNOiN6aGfsb/69R96KneFJ2MRbWzB8TEg LELrTp/3PSSWkpiWL+78jijIayRZgvyK614krGQ4uWYlzJ5o6EXZ2onn5srlFE0rUgi/ e08QPclgm3rjATpL7EdxGt+Kt3Q4kJ3pAhGr38YJ8VcGwxC1yC8XRwS/n9EPkhYLqKqI CL/A== X-Gm-Message-State: ALoCoQkYsYqqoQH3WGCi8pp6/bXQtzvRqYJJX/kOEMLSxyVshOBFY4rt5tLnVUKuJRxpHCtJ2woO MIME-Version: 1.0 X-Received: by 10.181.8.198 with SMTP id dm6mr12584989wid.30.1404923317929; Wed, 09 Jul 2014 09:28:37 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Wed, 9 Jul 2014 09:28:37 -0700 (PDT) Date: Wed, 9 Jul 2014 12:28:37 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dane/z1N5v9PW4W7Qo2_doAFKILxa6hE Subject: [dane] Looking up keying for the client. 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, 09 Jul 2014 16:28:40 -0000 Dear collages Enabling a server to look up keying information for the client was raised as a possible feature during the charter discussions. This is a call for discussion on "how to do=E2=80=9D / =E2=80=9Cis this pos= sible / advisable=E2=80=9D. If there is sufficient progress in in the next week the chairs would like to dedicate some time at the meeting in Toronto to this topic. The goal of this discussion is to 1) gauge if this possible / desirable, 2) find environments that would like full authentication of both parties. 3) evaluate different ideas on how proceed. Olafur & Warren From nobody Wed Jul 9 09:44:26 2014 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 A6ED11A029D for ; Wed, 9 Jul 2014 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] 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 vv3Md_dn1Elb for ; Wed, 9 Jul 2014 09:44:23 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68631A020B for ; Wed, 9 Jul 2014 09:44:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B5B3B8008E; Wed, 9 Jul 2014 12:44:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1404924260; bh=UK835ipYPuZy4PVOuVHPSXIwpD7w+3Vr+AXCouUZJ/M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=K5sNnBVu2OEH9XPkWTYbxhrLUtEiixxsumm4R1ZRw0DXc6Vu+fZr2ULcvObtzS4ZX fXsk+pcGLqIvGrDHD/QnAlXocf2o60ZE31y4Tt08PU25rOrK+CuOIjWGZTEhvrGqA5 7ntoY1scG4TP8WGo+L6nYhUk1PfwHM1NrBregc+k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s69GiKia003019; Wed, 9 Jul 2014 12:44:20 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 9 Jul 2014 12:44:20 -0400 (EDT) From: Paul Wouters To: Warren Kumari 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=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/knbeCLmzsLUHT7FYlXw-cuqdFbA Cc: "" Subject: Re: [dane] Looking up keying for the client. 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, 09 Jul 2014 16:44:24 -0000 On Wed, 9 Jul 2014, Warren Kumari wrote: > Enabling a server to look up keying information for the client was > raised as a possible feature during the charter discussions. > > This is a call for discussion on "how to do” / “is this possible / advisable”. > If there is sufficient progress in in the next week the chairs would > like to dedicate some time at the meeting in Toronto to this topic. > > The goal of this discussion is to > 1) gauge if this possible / desirable, > 2) find environments that would like full authentication of both parties. > 3) evaluate different ideas on how proceed. The Libreswan Project uses a local DNS server plugin, and piggybacking on the cache management to do IPSECKEY lookups. Setup IKE/IPsec when you find a new key that wasn't in the cache yet. Paul (unbound python plugin) From nobody Wed Jul 9 12:41:34 2014 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 B50031A0401 for ; Wed, 9 Jul 2014 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 HVy2d27LJvTM for ; Wed, 9 Jul 2014 12:41:28 -0700 (PDT) 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 2EFE61A0422 for ; Wed, 9 Jul 2014 12:41:28 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id C01241E14D; Wed, 9 Jul 2014 19:41:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1404934886; bh=ocsjIOTwfsSuSJeA//Y96hTUDGE6d4KA0w2DENFvZDE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kgY0B1zNRjiQsFOqtlsrj1+uNohcURZvFsE+7pycTyCZZVOBFwb32Wgk3jxsmJ+UR QbrW+GAWVkdka3H7SB+kMdm87YaEPlDfluPLy6Xx+2/I9qV41mZVQJQsplHKK1eNFi zayogdK6OXTDiE8UK3EhHziXDON3g74J8qYJt5Gc= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 0AD9F6004C; Wed, 9 Jul 2014 19:31:07 +0000 (UTC) From: James Cloos To: In-Reply-To: (Warren Kumari's message of "Wed, 9 Jul 2014 12:28:37 -0400") References: User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.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: Wed, 09 Jul 2014 15:31:07 -0400 Message-ID: Lines: 65 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140709:dane@ietf.org::SEF+w1avMQ/Pk3ev:000e/2mv X-Hashcash: 1:30:140709:warren@kumari.net::Ukum2TP65xzW21SF:0000000000000000000000000000000000000000000yaAiF Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RC49dHv1pEWV9YCtSRzWHJ-4WPk Subject: Re: [dane] Looking up keying for the client. 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, 09 Jul 2014 19:41:30 -0000 The primary issue is where to find the tlsa. For oob, it will have to be based on whatever autentication info which the initiator provides to the listen(8)er at the application level. For x509 certs, there are several additional possibilities. The CommonName (CN) field often has either a dns name or something which looks like an email address. But it might also be an actual, real-world common name. The Subject Alternative Name can have a set of dns names, email addresses, URIs, IP addresses, et cetera. The appliation might ask for a specific association when an application- layer authentication is used or tried. Or may tell the tls code to prefer email, dns or whatever names. Converting the selected string to a lookup needs specification for each type of string. For dns names, we could specify an indentity transformation, or add a simple prefix, such as _client, _$ProtoName._(tcp|udp|etc) or _$ProtoName. The prefix SHOULD NOT involve port numbers. That is appropriate for a listen(8)er on a well-known port or found via SRV or the like, but not for initiator tlsas. For email-like strings, we should specify the same transformation we specify for smime. The current draft looks mostly OK for that, but an _at between the h(H(left)) part and the right part may be in order. For URIs like $proto:$hostname or $proto://$hostname, a lookup like either _$proto.$hosname, _$proto._client.$hostname seems reasonable. For URIs like $proto:$email or $proto://$username@$hostname either following the email transformation or adding an additional _$proto before the results of that transformation seems right. All of 0,1,2,3 should be OK if the intitiator sends a set of certs, but the EE cert SHOULD be the one used to find the tlsa set. The OOB case should follow the same advice as for OOB listen(8)ers, wrt types of tlsa. IP address SANs should map to where the ptr is, provided it matches the IP from which the socket originated. And even without an explicit IP address SAN, the originaing IP probably SHOULD be checked. A prefix in that case probably is unneeded; the tlsa can be parallel to the ptr. Other types of SAN data probably need their own RFC to map to tlsa locations. CNs probably should be checked only as a fallback, if it is different from any of the SANs and if none of them worked. The application SHOULD get to know exactly which SAN/CN verified, so that it can match that to its ideas about aaa. I think that is everthing I've been considering recently. (I had planned on a missive about this; but the above is written from memory, with minimal editing.) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 9 16:45:05 2014 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 2B21D1B2843 for ; Wed, 9 Jul 2014 16:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 zoCJ4Nixhrn3 for ; Wed, 9 Jul 2014 16:44:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5CA1B2856 for ; Wed, 9 Jul 2014 16:44:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BA0642AB2A7; Wed, 9 Jul 2014 23:44:55 +0000 (UTC) Date: Wed, 9 Jul 2014 23:44:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140709234455.GF27568@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: http://mailarchive.ietf.org/arch/msg/dane/eA-82T6CCGV-DCLPa8bXycrcU9Y Subject: Re: [dane] Looking up keying for the client. 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, 09 Jul 2014 23:45:00 -0000 On Wed, Jul 09, 2014 at 12:28:37PM -0400, Warren Kumari wrote: > Dear collages Auto-corrupt? > This is a call for discussion on "how to do? / ?is this possible / advisable?. > If there is sufficient progress in in the next week the chairs would > like to dedicate some time at the meeting in Toronto to this topic. For SMTP, the plausible use-case is that the client's EHLO name is used to construct a TLSA lookup key, something along the lines of: _smtp-client.${ehlo_name} IN TLSA ? which then *could* make it possible for the server to obtain key material to authenticate the client (request client certs when TLSA records are found, ...). A serious difficulty is that even legitimate clients with non-negligible frequency use bad EHLO names, for which DNS lookups tempfail. Since timeouts due to bad input cannot be distinguished from timeouts due to transient network problems, client DANE TLSA authentication cannot be reliably applied opportunistically (zero configuration). This is likely OK, since client authentication is perhaps only useful when the client domain is whitelisted or otherwise already known to the server. Authentication of a stranger domain has rather limited utility. So I can see SMTP client authentication with DANE serving some limited use cases, for example, relay access via a provider's outbound gateway (for MTAs, not submission). So the main task is to identify sensible use-cases, then define associated lookup keys and lookup error handling for each use-case. -- Viktor. From nobody Fri Jul 18 14:15:26 2014 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 A7FBA1B2A6F for ; Fri, 18 Jul 2014 14:15:25 -0700 (PDT) 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 o4hcuFWAvgZb for ; Fri, 18 Jul 2014 14:15:23 -0700 (PDT) Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CF11B2A17 for ; Fri, 18 Jul 2014 14:15:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 82D5C80454 for ; Fri, 18 Jul 2014 17:15:22 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 400CA80AB0 for ; Fri, 18 Jul 2014 17:15:22 -0400 (EDT) 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 AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Fri, 18 Jul 2014 21:15:22 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_9CCBBAF1-18E3-4C40-B273-E89370409C32" Message-Id: Date: Fri, 18 Jul 2014 17:15:21 -0400 To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RIBzmgCKk4hrfhgM_SnETeYgkhM Subject: [dane] Meeting agenda 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, 18 Jul 2014 21:15:25 -0000 --Apple-Mail=_9CCBBAF1-18E3-4C40-B273-E89370409C32 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sorry I only uploaded this but forgot to email it out. Presenters please send me your slides ASAP thanks Olafur DANE @ IETF-90 Toronto Thuesday July 22'nd 2014 1640-1840 EDT Canadian Room Chairs: Warren Kumari, Olafur Gudmundsson Last updated: 2014-07-15 21:06 UTC ------------- Administrivia DANE status, (appoint scribes, blue-sheets, agenda bashing) Chairs - 5 min DANE activites in Other WGS Chairs - 5 min Working group documents: est 16:50 SRV and & SMTP status http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-10 http://tools.ietf.org/html/draft-ietf-dane-srv-06 Chairs 10 min OPENPGP and SMIME status http://tools.ietf.org/html/draft-ietf-dane-openpgp-00 http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00 http://tools.ietf.org/html/draft-ietf-dane-smime-06 Chairs 5 min DANEbis and operational guidance http://tools.ietf.org/html/draft-ietf-dane-ops-05 Wes Hardaker - 30 minutes. TLSA Raw Keys http://tools.ietf.org/html/draft-ietf-dane-rawkeys-00 Paul Wouters 20 min New proposals for DANE est 17:55 A DANE based solution for improving the security of HTTPS in CDN http://netsec.ccert.edu.cn/duanhx/files/2014/05/httpsincdn.pdf Haixin Duan -- 25 min Only if there is time: "Reverse DANE" i.e. can server check TLSA records for client? Chairs - 10 min End of meeting --Apple-Mail=_9CCBBAF1-18E3-4C40-B273-E89370409C32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Sorry I only uploaded this but = forgot to email it out. 
Presenters please send me your = slides ASAP thanks 

= Olafur
DANE @ IETF-90  Toronto
Thuesday July 22'nd 2014 1640-1840 EDT
Canadian Room 
Chairs: Warren Kumari, Olafur = Gudmundsson
Last = updated: 2014-07-15 21:06 UTC

-------------
Administrivia DANE status, 
(appoint scribes, = blue-sheets, agenda bashing)
Chairs - 5 min

DANE activites in Other WGS
Chairs -  5 = min

Working = group documents:  est 16:50
SRV and & SMTP status 
Chairs 10 min 

OPENPGP and SMIME status
http://tools.= ietf.org/html/draft-ietf-dane-smime-06
Chairs 5 min

DANEbis and operational = guidance 
Wes Hardaker - 30 minutes.

TLSA Raw Keys 
Paul Wouters 20 min 

New = proposals for DANE est 17:55 
A DANE based solution for improving the security of = HTTPS in CDN 
Haixin Duan -- 25 = min 

Only if there is time: 
"Reverse DANE" i.e. can server check TLSA records = for client? 
<no draft> 
Chairs - 10 min 

End of = meeting 

= --Apple-Mail=_9CCBBAF1-18E3-4C40-B273-E89370409C32-- From nobody Wed Jul 23 10:29:33 2014 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 EAC321B2A16; Wed, 23 Jul 2014 10:29:04 -0700 (PDT) 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 PeBhmgpghFrV; Wed, 23 Jul 2014 10:29:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9931A028B; Wed, 23 Jul 2014 10:28:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 10:28:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jOBzUiu7NsO3f5Jxa5j-w_VEr70 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-07.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: Wed, 23 Jul 2014 17:29:05 -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-07.txt Pages : 13 Date : 2014-07-23 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured with DNSSEC. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-07 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 Wed Jul 23 12:44:31 2014 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 918031A8BB2 for ; Wed, 23 Jul 2014 12:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 dwtBjJUrDvkG for ; Wed, 23 Jul 2014 12:44:29 -0700 (PDT) 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 123EE1A014F for ; Wed, 23 Jul 2014 12:44:29 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 1220A1E121; Wed, 23 Jul 2014 19:44:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1406144668; bh=F7J+cxOfbUijrCrjjnZwwB1UPrOPiW63/BfLEy3dkWA=; h=From:To:Subject:Date:From; b=hBwRSxb7qbfjlfVmDtAe12tOLwlXXlaaAC02ZL2bteBOD4pDlaqTchChey+JSiU73 t1NZW8nL0gwNKaTfHg/z/VuIUS/IyCuRH0WGQZdpAqD8FgM31Hh2sqhJBh5mynMGTh XxbRKXRco6WdXaWV4KZwUcJVvkzWLa+sTVu1q3FE= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 8EC3460022; Wed, 23 Jul 2014 19:42:28 +0000 (UTC) From: James Cloos To: dane@ietf.org User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.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: Wed, 23 Jul 2014 15:42:28 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140723:dane@ietf.org::D1yaf/LBX88xDoxF:000dWcce Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wst1lAI6gj-1qZ8F2AuWzZCrums Subject: [dane] on tlsa for rfc 7250 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, 23 Jul 2014 19:44:30 -0000 Thinking about 7250, I'm becoming convinced that we should recommend that anyone publishing tlsa, whose software might have or gain support for 7250, or might be accessed by clients which can support 7250, SHOULD publish a 31x for them, in addition to any non-31x tlsa they publish. Ie, those who prefer 0, 1 or 2 should publish both, for the benefit of any 7250 clients which might access them. Thoughts? I also remain conviced that, per liberal in what you accept, any 7250 client should accept a 11x just as though it were a 31x, since the association data is identical. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 23 17:37:41 2014 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 407951A019A for ; Wed, 23 Jul 2014 17:37:40 -0700 (PDT) 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 13CvqWmBKeZX for ; Wed, 23 Jul 2014 17:37:38 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E271A0115 for ; Wed, 23 Jul 2014 17:37:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 226DF2AB2B2; Thu, 24 Jul 2014 00:37:32 +0000 (UTC) Date: Thu, 24 Jul 2014 00:37:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724003732.GT2595@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: http://mailarchive.ietf.org/arch/msg/dane/DSo67MyxbXXF1AW7OSdjO5F4HNI Subject: Re: [dane] on tlsa for rfc 7250 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, 24 Jul 2014 00:37:40 -0000 On Wed, Jul 23, 2014 at 03:42:28PM -0400, James Cloos wrote: > Thinking about 7250, I'm becoming convinced that we should recommend > that anyone publishing TLSA, whose software might have or gain support > for 7250, or might be accessed by clients which can support 7250, SHOULD > publish a 31x for them, in addition to any non-31x tlsa they publish. That is, publish "DANE-EE(3) SPKI(1) ? {blob}" associations for the public keys in any extant certificates, so as to allow the corresponding bare public keys to be used without the surrounding X.509 baggage later. If the protocol is in fact TLS (in which case the full keys are exchanged in-band), the matching type SHOULD typically be a digest, though for some algorithms (say EC curve 25519 keys), the key size is comparable to the size of its SHA2-256 digest. However, once "3 1 x" records are published, there is little point in publishing any other type of record. So I am not sure about the "in addition to" bit. Rather I would suggest "instead of". > Ie, those who prefer 0, 1 or 2 should publish both, for the benefit of > any 7250 clients which might access them. The cost of publishing "3 1 x" is that the server operator needs to update DNS when keys change, while with DANE-TA(2), a CNAME to the TA TLSA record can be published for each service, and the task of DNS updates is left to the organization's TA administrator. Once the cost burden (on each server operator) of updating "3 1 x" records is present already, also publishing "2 1 X" just makes things needlessly complex. There is no point. > Thoughts? I think that in most cases DANE users will publish either "3 1 X" or "3 0 X". With 7250 in mind, they should be encouraged to publish "3 1 X" and avoid "3 0 X". > I also remain conviced that, per liberal in what you accept, any 7250 > client should accept a 11x just as though it were a 31x, since the > association data is identical. This is what Postfix does, but is not what the SMTP draft says. I was dissuaded from formalizing such creative interpretation of TLSA RRs. If the publisher wants PKIX then the service should not agree to RPK (raw public keys) use and the client should be free to either do PKIX or treat the record as unusable, or at least that's all the server operator can expect. Clients might be more lenient, but no standard will require them to do it. If the group believes that Postel's rule applies here, and that non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as DANE-EE(3), then we SHOULD add that to the text the OPS draft, and update the SMTP draft accordingly. -- Viktor. From nobody Thu Jul 24 01:19:46 2014 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 849831A00D8 for ; Thu, 24 Jul 2014 01:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 YOXu9vqn4EMd for ; Thu, 24 Jul 2014 01:19:40 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A6FD41A00D5 for ; Thu, 24 Jul 2014 01:19:36 -0700 (PDT) Received: from [192.168.40.44] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6DAA293C1AF; Thu, 24 Jul 2014 08:19:17 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jul 2014 10:19:08 +0200 Message-Id: To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/i6T3SrI1wGBPFDwOBigRpzUERqQ Subject: [dane] Draft ietf-dane-srv-07 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, 24 Jul 2014 08:19:42 -0000 Hi! Sorry for not having followed the details of the discussion lately, so = please excuse me if I'm too late with comments or ask about stuff = discussed in a gazillion emails before. Section 3: I really like this here, but would like it to be expanded a bit to help = implementors. The DNS SRV RFC is not easy to understand and in the IP world RFC 3263 has confused a lot of people. DNS SRV says = that all candidates for a given priority should be attempted before one moves to the next priority. It doesn't say anything = about order, which this document does when you say "SHOULD be performed in parallell". If one given priority have two = hosts with two IPv4 and three IPv6 each - should all of them be tried in parallell?=20 This is a big issue and may be too big an issue for this document to = cover, especially with normative language. Section 3.2 Please change "A/AAAA" to "A and AAAA" to be very clear that it's not a = choice if the client is dual stack.=20 In fact the DNS SRV rfc talks about "any address family" - now and in = the future ;-) Section 5: It would help me if you add a bullet like * Handling in the case of protocols using NAPTR for transport selection, = like the Session Initiation Protocol That will help me in sipcore :-) Section 6: I think it would help implementors to explain a bit more detail - that = if you have multiple names in the cert, one could be the=20 CN and the others Subject Alt Names. According to the SIP domain cert RFC the CN should be disregarded and = NOT used if there are any SANs. I don't know the reasoning behind this. Anyone? Should we do that here too or just forget = it? Sorry I couldn't be in Toronto :-( /O= From nobody Thu Jul 24 01:45:37 2014 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 AC67B1A00EC for ; Thu, 24 Jul 2014 01:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 4Xt7ALDZzARU for ; Thu, 24 Jul 2014 01:45:34 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 17B141A00BB for ; Thu, 24 Jul 2014 01:45:33 -0700 (PDT) Received: from [192.168.40.44] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2764993C1AF; Thu, 24 Jul 2014 08:45:16 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jul 2014 10:45:32 +0200 Message-Id: To: dane@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dfop5nAUQ59sR8dHL1PgYMog6K0 Subject: [dane] draft-ietf-dane-srv-07 - identifiers in the cert 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, 24 Jul 2014 08:45:35 -0000 Hi! Re-reading I found another issue that confuses me a bit: "SRV is secure: The reference identifiers SHALL include both the service domain and the SRV target server host name (e.g., include both "im.example.com" and "xmpp23.hosting.example.net"). The target server host name is the preferred name for TLS SNI or its equivalent." Why SHALL we include the service domain? I thought the reasoning here was that the signed chain was the proof of authorization to handle a = specific service domain. I don't really see the point in having the service = domain in the cert as this generates issues with multi-hosting (as previously = discussed). Again I may have missed previous conversation, so feel free to tell me = to shut up and send me pointers to those ;-) The SNI discussion is also a bit unclear. To be nitpicking, someone = pointed out to me that SNI only supports hostnames. If we want to ask for = service domains we have to register a new type of SNI if I understood it = correctly. This means that section 6 discussion about SNI in section 6 that recommends SNI with service domains is not really supported by SNI. Cheers, /O= From nobody Thu Jul 24 05:58:06 2014 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 609731A0276 for ; Thu, 24 Jul 2014 05:58:05 -0700 (PDT) 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 9TZnohMj5uMS for ; Thu, 24 Jul 2014 05:58:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5931A023E for ; Thu, 24 Jul 2014 05:58:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 162112AB2A9; Thu, 24 Jul 2014 12:57:57 +0000 (UTC) Date: Thu, 24 Jul 2014 12:57:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724125757.GW2595@mournblade.imrryr.org> References: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Jt0piAsiZw5V2fa-dgQByNt3VrA Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-07.txt 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, 24 Jul 2014 12:58:05 -0000 On Wed, Jul 23, 2014 at 10:28:59AM -0700, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-07 For now comments on the -07 changes, will review the whole draft later. Section 3.1 paragraph 3 (page 4 line 17): If the the entire RRset is "insecure" or "indeterminate", this protocol has not been correctly deployed. The client SHOULD fall back to its non-DNSSEC, non-DANE behavior (this corresponds to the AD bit being unset). If the entire RRset is "bogus", the client MUST abort the attempt. delete [or "indeterminate"], per RFC 4035, from which "indeterminate" is reputedly taken, that status is essentially a lookup error (failure to determine whether the query zone is opted out or not), and so is not a case where the client simply falls back to non-DANE behaviour. Note the words "entire RRset" in paragraphs 3 and 4 are misleading. I believe that it is not possible for an RRset to be partially secure. Unless I am mistaken, RRSIGs apply to an RRset, not an individual RR. Since we're ultimately looking at an SRV RRset (possibly after CNAME expansion of the original domain), it is either secure in full or insecure in full. More appropriately, "entire" applies not to RRset, but rather "entire chain" of aliases (CNAME or DNAME if any) leading to the ultimate SRV RRset. Not continuing with connections to the target service applies when the DNS lookup fails ("bogus", "indeterminate", "timeout", ...). DNS lookup error handling is more comprehensively specified in the SMTP draft, and perhaps should be borrowed from that document in its entirety. -- Viktor. From nobody Thu Jul 24 05:58:49 2014 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 3ACA51A02DB for ; Thu, 24 Jul 2014 05:58:48 -0700 (PDT) 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 uLom_YB2LqEv for ; Thu, 24 Jul 2014 05:58:46 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3CF1A023E for ; Thu, 24 Jul 2014 05:58:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CB4C82AB2A9; Thu, 24 Jul 2014 12:58:27 +0000 (UTC) Date: Thu, 24 Jul 2014 12:58:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724125827.GX2595@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: http://mailarchive.ietf.org/arch/msg/dane/obqWG6I6nFFyOdDdTOr5ALwzOjM Subject: Re: [dane] Draft ietf-dane-srv-07 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, 24 Jul 2014 12:58:48 -0000 On Thu, Jul 24, 2014 at 10:19:08AM +0200, Olle E. Johansson wrote: > Section 3: > > I really like this here, but would like it to be expanded a bit to help > implementors. The DNS SRV RFC is not easy to understand and in the IP > world RFC 3263 has confused a lot of people. DNS SRV says that all > candidates for a given priority should be attempted before one moves to > the next priority. It doesn't say anything about order, which this document > does when you say "SHOULD be performed in parallel". Note, the text at the top of Section 3: To expedite connection to the intended service, where possible the queries described in the following sections SHOULD be performed in parallel (this is similar to the "happy eyeballs" approach for IPv4 and IPv6 connections described in [RFC6555]). is encouraging parallel *DNS lookup*, not parallel connection attempts. And in fact parallel connection attempts would be wrong unless all the weights are equal, and, as a blanket policy, questionable even then. > If one given priority have two hosts with two IPv4 and three IPv6 each - > should all of them be tried in parallell? The answer is NO, because the document does not suggest connection concurrency, and because even that is I thing a mistake. When the weights are unequal, the client is supposed to employ some sort of RNG to choose candidate servers with a probability based on the weights. If the client is correctly employing weighted selection, parallel address lookup is generally inappropriate, in most cases the first (randomly) chosen server will in fact be available and lookups for other server addresses are I believe wasteful. Thus parallel lookups are only useful when the first server does not respond and further lookups are required to find more servers, and could arguably have been performed in parallel with the first lookup. However, after incurring a connection timeout with the first server, additional DNS lookup latency for the second server is not a major increment in the latency. Also one needs TLSA lookups which should only follow the address lookups because the TLSA lookup should not be made when the address records are not secure. (Also when CNAMEs are supported on the RHS of SRV records, the TLSA base domain is not known until the original address record is CNAME expanded). Bottom line I think the "parallel" language should be withdrawn. > This is a big issue and may be too big an issue for this document to cover, > especially with normative language. This document definitely cannot specify anything about connection concurrency. I would like to suggest strongly it also should *not* specify lookup concurrency. > According to the SIP domain cert RFC the CN should be disregarded > and NOT used if there are any SANs. I don't know the > reasoning behind this. Anyone? Should we do that here too or just forget it? This is IIRC either from 5280, 6125 or both. DNS names in the subject CN are deprecated, SANs are preferred, and trump the CN when both (at least one SAN of type DNS and a CN in the subject DN) are present. -- Viktor. From nobody Thu Jul 24 13:22:52 2014 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 54AA01B2835 for ; Thu, 24 Jul 2014 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 Bfs831ZUSI_s for ; Thu, 24 Jul 2014 13:22:44 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 41EA91A0A9D for ; Thu, 24 Jul 2014 13:22:44 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 91EF01E350; Thu, 24 Jul 2014 20:22:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1406233362; bh=MVcLYC2XowlUQFJFvoAIZrOt36uvPaJPCnUDwbW2jLk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dtLSkuCYGEYDNlqUsIybA5I7KvDmYBNJsTX+J5eZwrgqmLnpc/x76DyZH9sDMlAJI wmWEk0ZkBnaFw2hIb6Ht1jQWtwiYzpMdjx/FbMtVuFg2K6Q3Nfeotxp50sfRtXDmaH TlHOa9l55ZtjDdPajqMjUbXzN5/uia99ba4KaAS4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 09D7560021; Thu, 24 Jul 2014 20:13:19 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20140724003732.GT2595@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 24 Jul 2014 00:37:32 +0000") References: <20140724003732.GT2595@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.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: Thu, 24 Jul 2014 16:13:19 -0400 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140724:dane@ietf.org::TRYBfHJDJAz+7Kh+:000H3WWU X-Hashcash: 1:30:140724:ietf-dane@dukhovni.org::GE4uRqHzgqsQnAa1:00000000000000000000000000000000000000uRIy/ Archived-At: http://mailarchive.ietf.org/arch/msg/dane/26dYQ8nZMh8kt7T_yM_WwtJ5oNA Subject: Re: [dane] on tlsa for rfc 7250 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, 24 Jul 2014 20:22:50 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> However, once "3 1 x" records are published, there is little point VD> in publishing any other type of record. So I am not sure about VD> the "in addition to" bit. Rather I would suggest "instead of". The idea is that some seem to so wedded to pkix that they feel that they MUST publish 0 or 1 if they publish tlsa at all. (I obviously don't agree with that sentiment; and there is the possiblity that those who do lost interest here and it may not ever be an issue???) Publish both is directed at them, to ease interoperability with any 7250 clients. VD> Once the cost burden (on each server operator) of updating "3 1 x" VD> records is present already, also publishing "2 1 X" just makes VD> things needlessly complex. There is no point. I considered that issue even though I didn't call it out. You're right that it may lead type 2 users to choose between easy updates and supporting 7250 clients. That is part of why I'm only 'becoming convinced'. VD> If the group believes that Postel's rule applies here, and that VD> non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as VD> DANE-EE(3), then we SHOULD add that to the text the OPS draft, and VD> update the SMTP draft accordingly. Postel's rule goes without writing; even when it isn't mentioned in (potential) standards it remains proper for code to implment it. But I would prefer to see it mentioned in the documents. For a one-way authenticated sockect like tls often is, if the client can create a trust path which /it/ likes, the server's pref doesn't matter. Similarly, when the server authenticates the client, it is only the server's choices about trust paths et alia which should matter to /it/. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Jul 24 15:57:29 2014 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 3EABE1A01AA for ; Thu, 24 Jul 2014 15:57:28 -0700 (PDT) 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 wZINIf_M_zgO for ; Thu, 24 Jul 2014 15:57:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D4A1A0270 for ; Thu, 24 Jul 2014 15:57:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4CA752AB2AF; Thu, 24 Jul 2014 22:57:24 +0000 (UTC) Date: Thu, 24 Jul 2014 22:57:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724225724.GE15044@mournblade.imrryr.org> References: <20140724003732.GT2595@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: http://mailarchive.ietf.org/arch/msg/dane/AozZAXaHYiovcZkTnFgED22G9V0 Subject: Re: [dane] on tlsa for rfc 7250 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, 24 Jul 2014 22:57:28 -0000 On Thu, Jul 24, 2014 at 04:13:19PM -0400, James Cloos wrote: > >>>>> "VD" == Viktor Dukhovni writes: > > VD> However, once "3 1 x" records are published, there is little point > VD> in publishing any other type of record. So I am not sure about > VD> the "in addition to" bit. Rather I would suggest "instead of". > > The idea is that some seem to so wedded to pkix that they feel that they > MUST publish 0 or 1 if they publish tlsa at all. Once they stoop to publishing "3 1 x", the've accepted lack of PKIX, with one caveat, the recommendation in the OPS draft to support either only PKIX or only non-PKIX DANE usages is a recommendation primarily for the *client*. If a server supports both PKIX-loving clients and PKIX-hating clients, then it can reasonably publish mixed TLSA RRsets, with each type of client using only the RRs it supports. A client that supports both, is maximally burdened (to have comprehensive CA lists, ...) and minimally secured (by being vulnerable to DNSSEC-only attacks). So while the client should rarely if ever support both PKIX and non-PKIX usages, servers can in some cases straddle the two worlds when the application protocol leaves the choice of security model to the each particular client. In that case, servers that want to support all types of clients might pay the operational cost to support both "3 1 X" and one of the PKIX usages. > VD> If the group believes that Postel's rule applies here, and that > VD> non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as > VD> DANE-EE(3), then we SHOULD add that to the text the OPS draft, and > VD> update the SMTP draft accordingly. > > Postel's rule goes without writing; even when it isn't mentioned in > (potential) standards it remains proper for code to implment it. > But I would prefer to see it mentioned in the documents. > > For a one-way authenticated sockect like tls often is, if the client can > create a trust path which /it/ likes, the server's pref doesn't matter. > > Similarly, when the server authenticates the client, it is only the > server's choices about trust paths et alia which should matter to /it/. Is this generally the WG's view? IIRC Wes played a role in dissuading me from recommending playing "fast and loose" with the server's RR semantics, by down-grading PKIX-EE(1) to DANE-EE(3). Note also that one cannot in general downgrade PKIX-TA(0) to DANE-TA(2), and this lack of symmetry might cause confusion. The reason for not being able to map 0->2 is that PKIX root CAs are optional in the server's handshake chain, while DANE TAs are not. So a non-PKIX client can't expect to succeed in validating a PKIX-TA chain. This is actually part of the reason I'm reluctant to map 1->3, because it sets up false expectations of being able to map 0->2 which can't be met reliably. -- Viktor. From nobody Thu Jul 24 16:04:42 2014 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 1DC9C1A02E8 for ; Thu, 24 Jul 2014 16:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 tCY4hFHnPfv5 for ; Thu, 24 Jul 2014 16:04:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EAE1A03AA for ; Thu, 24 Jul 2014 16:04:39 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 6B8C61FCB39; Thu, 24 Jul 2014 23:04:36 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E73CE160055; Thu, 24 Jul 2014 23:13:56 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B1846160054; Thu, 24 Jul 2014 23:13:56 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D09771AC966F; Fri, 25 Jul 2014 09:04:32 +1000 (EST) To: "Olle E. Johansson" From: Mark Andrews References: In-reply-to: Your message of "Thu, 24 Jul 2014 10:45:32 +0200." Date: Fri, 25 Jul 2014 09:04:32 +1000 Message-Id: <20140724230432.D09771AC966F@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CJZWQqrZCVIJ9sJDTuK7vW4pRqE Cc: dane@ietf.org Subject: Re: [dane] draft-ietf-dane-srv-07 - identifiers in the cert 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, 24 Jul 2014 23:04:41 -0000 In message , "Olle E. Johansso n" writes: > Hi! > > Re-reading I found another issue that confuses me a bit: > > "SRV is secure: The reference identifiers SHALL include both the > service domain and the SRV target server host name (e.g., include > both "im.example.com" and "xmpp23.hosting.example.net"). The > target server host name is the preferred name for TLS SNI or its > equivalent." > > Why SHALL we include the service domain? I thought the reasoning here > was that the signed chain was the proof of authorization to handle a specific > service domain. I don't really see the point in having the service domain > in the cert as this generates issues with multi-hosting (as previously discus > sed). > > Again I may have missed previous conversation, so feel free to tell me to shu > t > up and send me pointers to those ;-) > > The SNI discussion is also a bit unclear. To be nitpicking, someone pointed > out to me that SNI only supports hostnames. If we want to ask for service > domains we have to register a new type of SNI if I understood it correctly. > This means that section 6 discussion about SNI in section 6 that > recommends SNI with service domains is not really supported by SNI. > > Cheers, > /O The assumption is that one will share a port if the protocol permits it (e.g. HTTPS, SMTP) so there are scaling issues. 50000 names in a cert does not scale. Using the server name is the only real solution. For protocols where you can't share a port you could use either but to make it consistent you use the server's name. SHALL helps here if you are transitioning from CNAME to SRV as you can point both to the same instance. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Jul 25 00:42:20 2014 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 600B41A007C for ; Fri, 25 Jul 2014 00:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 8EQfenRIg--s for ; Fri, 25 Jul 2014 00:42:16 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E61C11A0011 for ; Fri, 25 Jul 2014 00:42:15 -0700 (PDT) Received: from [192.168.40.44] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 86C4093C1AF; Fri, 25 Jul 2014 07:41:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <20140724125827.GX2595@mournblade.imrryr.org> Date: Fri, 25 Jul 2014 09:42:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140724125827.GX2595@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0f_eIhmTMmnoVBp9sQYHc7PdFXc Subject: Re: [dane] Draft ietf-dane-srv-07 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, 25 Jul 2014 07:42:18 -0000 On 24 Jul 2014, at 14:58, Viktor Dukhovni = wrote: > On Thu, Jul 24, 2014 at 10:19:08AM +0200, Olle E. Johansson wrote: >=20 >> Section 3: >>=20 >> I really like this here, but would like it to be expanded a bit to = help >> implementors. The DNS SRV RFC is not easy to understand and in the IP >> world RFC 3263 has confused a lot of people. DNS SRV says that all >> candidates for a given priority should be attempted before one moves = to >> the next priority. It doesn't say anything about order, which this = document >> does when you say "SHOULD be performed in parallel". >=20 > Note, the text at the top of Section 3: >=20 > To expedite connection to the intended service, where possible the > queries described in the following sections SHOULD be performed in > parallel (this is similar to the "happy eyeballs" approach for IPv4 > and IPv6 connections described in [RFC6555]). >=20 > is encouraging parallel *DNS lookup*, not parallel connection > attempts. And in fact parallel connection attempts would be wrong > unless all the weights are equal, and, as a blanket policy, = questionable > even then. >=20 >> If one given priority have two hosts with two IPv4 and three IPv6 = each - >> should all of them be tried in parallell? >=20 > The answer is NO, because the document does not suggest connection > concurrency, and because even that is I thing a mistake. When the > weights are unequal, the client is supposed to employ some sort of > RNG to choose candidate servers with a probability based on the > weights. If the client is correctly employing weighted selection, > parallel address lookup is generally inappropriate, in most cases > the first (randomly) chosen server will in fact be available and > lookups for other server addresses are I believe wasteful. >=20 > Thus parallel lookups are only useful when the first server does > not respond and further lookups are required to find more servers, > and could arguably have been performed in parallel with the first > lookup. However, after incurring a connection timeout with the > first server, additional DNS lookup latency for the second server > is not a major increment in the latency. >=20 > Also one needs TLSA lookups which should only follow the address > lookups because the TLSA lookup should not be made when the address > records are not secure. (Also when CNAMEs are supported on the > RHS of SRV records, the TLSA base domain is not known until the > original address record is CNAME expanded). >=20 > Bottom line I think the "parallel" language should be withdrawn. Or rewritten to make it olle-compatible ;-) >=20 >> This is a big issue and may be too big an issue for this document to = cover, >> especially with normative language. >=20 > This document definitely cannot specify anything about connection > concurrency. I would like to suggest strongly it also should *not* > specify lookup concurrency. +1 The reference to Happy Eyeballs, which is all about connection attempts, mislead me I guess. I think we may add "the handling of network = connection attempts is not defined in this document". >=20 >> According to the SIP domain cert RFC the CN should be disregarded >> and NOT used if there are any SANs. I don't know the >> reasoning behind this. Anyone? Should we do that here too or just = forget it? >=20 > This is IIRC either from 5280, 6125 or both. DNS names in the > subject CN are deprecated, SANs are preferred, and trump the CN > when both (at least one SAN of type DNS and a CN in the subject > DN) are present. Then we need to clarify this again. Thanks for your response, Viktor! /O= From nobody Fri Jul 25 10:22:13 2014 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 F08EF1A0240; Fri, 25 Jul 2014 10:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 oWX3N73IjtE3; Fri, 25 Jul 2014 10:22:09 -0700 (PDT) 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 2B5591A01E2; Fri, 25 Jul 2014 10:22:09 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6PHM83j017274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Jul 2014 13:22:08 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6PHM6sc007574 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 13:22:07 -0400 Message-ID: <53D2923E.6080903@redhat.com> Date: Fri, 25 Jul 2014 19:22:06 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dnsext@ietf.org, dane WG list , Paul Wouters References: <20140723213403.GN94557@registro.br> In-Reply-To: <20140723213403.GN94557@registro.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_XfPtWDoKSreDtj4f_BMg7iqEqw Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th 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, 25 Jul 2014 17:22:11 -0000 Hello, On 23.7.2014 23:34, Frederico A C Neves wrote: > Dear Colleagues, > > Bellow is a completed template requesting a new RRTYPE assignment > under the procedures of RFC6895. > > This message starts a 2 weeks period for an expert review of the DNS > RRTYPE parameter allocation for OPENPGPKEY specified at: > > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 I was asking dane-list [1] if it makes sense to publish PGP key revocation certificate in OPENPGPKEY. I haven't heard any reply to this idea yet (maybe it is too dumb idea to warrant single reply). There is one important detail to note: - OPENPGPKEY as proposed requires DNSSEC protection (it is public key). - Key revocation certificate doesn't require DNSSEC because the certificate itself is signed. I think it is worth considering support for key revocation certificates in DNS because they can be deployed even more easily and rapidly (because DNSSEC is not required). The question is if it makes sense to publish both types of data using: - Different RR type (a la OPENPGPREVOC) - The same RR type but under different _prefix (_revoc._openpgpkey?) - Under the same owner name and RR type, which would (I guess) require an additional field in OPENPGPKEY RR type Mixing keys and revocation data in single RR set will obviously result in bigger replies. The question is if client should verify always verify that the other keys of the same user were not revoked so it could make sense to send him all the data in one response. (The older key could be obtained via non-DNS means etc.) On the other hand, "_openpgpkey aware" clients could always check live data in DNS and use only keys which are present in DNS at the moment. In that case removing RR which represents particular key will have the same affect as key revocation (but only for "_openpgpkey aware" clients). Unfortunately I will not be available for next two weeks so I'm throwing the idea to mailing list without any promise to reply before 2014-08-11. [1] http://www.ietf.org/mail-archive/web/dane/current/msg06672.html -- Petr Spacek @ Red Hat From nobody Fri Jul 25 10:31:08 2014 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 DC01A1A03CC for ; Fri, 25 Jul 2014 10:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 efUDZr3LslAX for ; Fri, 25 Jul 2014 10:31:06 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B71D1A03AD for ; Fri, 25 Jul 2014 10:31:06 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 25 Jul 2014 13:30:54 -0400 Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.348.2; Fri, 25 Jul 2014 13:31:04 -0400 Received: from [127.0.0.1] (114-140.antd.nist.gov [129.6.140.114]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s6PHUpJq023281; Fri, 25 Jul 2014 13:30:53 -0400 Message-ID: <53D2944B.5030009@nist.gov> Date: Fri, 25 Jul 2014 13:30:51 -0400 From: Stephen Nightingale User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> In-Reply-To: <53D2923E.6080903@redhat.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: Archived-At: http://mailarchive.ietf.org/arch/msg/dane/j6Twu9m5gk1gxgb8J5ZDq4TctYk Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th 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, 25 Jul 2014 17:31:08 -0000 Openpgpkey revocation: If a client is 'openpgpkey unaware', they will be unaware of the latest OPENPGPKEYREVOC update. If they always check for the revocation, then they might as well be 'openpgpkey aware' and always refresh the key instead? Or am I missing a trick somewhere? Stephen Nightingale. On 7/25/2014 1:22 PM, Petr Spacek wrote: > Hello, > > On 23.7.2014 23:34, Frederico A C Neves wrote: >> Dear Colleagues, >> >> Bellow is a completed template requesting a new RRTYPE assignment >> under the procedures of RFC6895. >> >> This message starts a 2 weeks period for an expert review of the DNS >> RRTYPE parameter allocation for OPENPGPKEY specified at: >> >> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 > > I was asking dane-list [1] if it makes sense to publish PGP key > revocation certificate in OPENPGPKEY. I haven't heard any reply to this > idea yet (maybe it is too dumb idea to warrant single reply). > > There is one important detail to note: > - OPENPGPKEY as proposed requires DNSSEC protection (it is public key). > - Key revocation certificate doesn't require DNSSEC because the > certificate itself is signed. > > I think it is worth considering support for key revocation certificates > in DNS because they can be deployed even more easily and rapidly > (because DNSSEC is not required). > > The question is if it makes sense to publish both types of data using: > - Different RR type (a la OPENPGPREVOC) > - The same RR type but under different _prefix (_revoc._openpgpkey?) > - Under the same owner name and RR type, which would (I guess) require > an additional field in OPENPGPKEY RR type > > > Mixing keys and revocation data in single RR set will obviously result > in bigger replies. The question is if client should verify always verify > that the other keys of the same user were not revoked so it could make > sense to send him all the data in one response. (The older key could be > obtained via non-DNS means etc.) > > On the other hand, "_openpgpkey aware" clients could always check live > data in DNS and use only keys which are present in DNS at the moment. In > that case removing RR which represents particular key will have the same > affect as key revocation (but only for "_openpgpkey aware" clients). > > > Unfortunately I will not be available for next two weeks so I'm throwing > the idea to mailing list without any promise to reply before 2014-08-11. > > [1] http://www.ietf.org/mail-archive/web/dane/current/msg06672.html > From nobody Fri Jul 25 10:33:23 2014 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 7B3971A0334 for ; Fri, 25 Jul 2014 10:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.176 X-Spam-Level: X-Spam-Status: No, score=0.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Wn2Rlo9Hwry6 for ; Fri, 25 Jul 2014 10:33:19 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3351A033D for ; Fri, 25 Jul 2014 10:33:19 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so5986259pdb.5 for ; Fri, 25 Jul 2014 10:33:19 -0700 (PDT) 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=yuPkVzKj2SUDpDEhcK5z0hNMBdHM0SLLV16ad0Id+jA=; b=Ni3Itytd1Xz8au7GMLQdMT6K9CPFv/7BqgMj6oXp1lo3StdptfvociO6meOaLyymY+ hDgYOKYtQHiUL7otaT7fn2MFh3sB/4zCHVfeBeYLAH4u3Ait5BZYCruxNTfuOAqXwyz8 QcUfFP7/ruIMFSXKx8mjFMzBIweJgnFeERrIA44I6yYllMt8SqAtrpu8CvZIMz1eJDTP Z/CLLFGXQVcKe1yfCwnunE+fIfKFOVLFpsLNMWDxdO3aU0LvlPdcrP9MXX8AZybGbITD sNcCi747DvDKZE9Td7AzQ3aM9o8goQ+Prs2SgciGtvYFZez/BKkv23e44zSzKJUsjlmw nxAw== X-Gm-Message-State: ALoCoQkicuWD86m9kYhgAPMZJqRP2r8YlOvrEBlozAOHM4bg6ragLWsjQmqjMUaHcN740hrZvCL4 MIME-Version: 1.0 X-Received: by 10.70.65.40 with SMTP id u8mr11876791pds.96.1406309599300; Fri, 25 Jul 2014 10:33:19 -0700 (PDT) Received: by 10.70.131.100 with HTTP; Fri, 25 Jul 2014 10:33:19 -0700 (PDT) X-Originating-IP: [2001:67c:370:168:782b:5f5a:feb7:4f1d] In-Reply-To: <53D2944B.5030009@nist.gov> References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> <53D2944B.5030009@nist.gov> Date: Fri, 25 Jul 2014 13:33:19 -0400 Message-ID: From: George Michaelson To: Stephen Nightingale Content-Type: multipart/alternative; boundary=089e0162832c1c678b04ff07f880 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CqYtY4FadkyhBBDbRF1-w6mm6HY Cc: dane@ietf.org Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th 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, 25 Jul 2014 17:33:21 -0000 --089e0162832c1c678b04ff07f880 Content-Type: text/plain; charset=UTF-8 There would be *no* relationship between any DNSSEC signing chain, trust in the path, and the actual contents of the REVOKE, right? I mean, a REVOKE is just an assertion by fiat. Its innately testable. How you find it is immaterial. That hasn't changed has it? -G On Fri, Jul 25, 2014 at 1:30 PM, Stephen Nightingale wrote: > > Openpgpkey revocation: > > If a client is 'openpgpkey unaware', they will be unaware of the latest > OPENPGPKEYREVOC update. If they always check for the revocation, then > they might as well be 'openpgpkey aware' and always refresh the key > instead? Or am I missing a trick somewhere? > > Stephen Nightingale. > > > On 7/25/2014 1:22 PM, Petr Spacek wrote: > > Hello, > > > > On 23.7.2014 23:34, Frederico A C Neves wrote: > >> Dear Colleagues, > >> > >> Bellow is a completed template requesting a new RRTYPE assignment > >> under the procedures of RFC6895. > >> > >> This message starts a 2 weeks period for an expert review of the DNS > >> RRTYPE parameter allocation for OPENPGPKEY specified at: > >> > >> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 > > > > I was asking dane-list [1] if it makes sense to publish PGP key > > revocation certificate in OPENPGPKEY. I haven't heard any reply to this > > idea yet (maybe it is too dumb idea to warrant single reply). > > > > There is one important detail to note: > > - OPENPGPKEY as proposed requires DNSSEC protection (it is public key). > > - Key revocation certificate doesn't require DNSSEC because the > > certificate itself is signed. > > > > I think it is worth considering support for key revocation certificates > > in DNS because they can be deployed even more easily and rapidly > > (because DNSSEC is not required). > > > > The question is if it makes sense to publish both types of data using: > > - Different RR type (a la OPENPGPREVOC) > > - The same RR type but under different _prefix (_revoc._openpgpkey?) > > - Under the same owner name and RR type, which would (I guess) require > > an additional field in OPENPGPKEY RR type > > > > > > Mixing keys and revocation data in single RR set will obviously result > > in bigger replies. The question is if client should verify always verify > > that the other keys of the same user were not revoked so it could make > > sense to send him all the data in one response. (The older key could be > > obtained via non-DNS means etc.) > > > > On the other hand, "_openpgpkey aware" clients could always check live > > data in DNS and use only keys which are present in DNS at the moment. In > > that case removing RR which represents particular key will have the same > > affect as key revocation (but only for "_openpgpkey aware" clients). > > > > > > Unfortunately I will not be available for next two weeks so I'm throwing > > the idea to mailing list without any promise to reply before 2014-08-11. > > > > [1] http://www.ietf.org/mail-archive/web/dane/current/msg06672.html > > > > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --089e0162832c1c678b04ff07f880 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There would be *no* relationship between any DNSSEC signin= g chain, trust in the path, and the actual contents of the REVOKE, right?
I mean, a REVOKE is just =C2=A0an assertion by fiat. Its = innately testable. How you find it is immaterial.

That hasn't changed has it?

-G


On Fri, Jul 25, 2014 at 1:30 PM, Stephen Nightingale &= lt;night@nist.gov&g= t; wrote:

Openpgpkey revocation:

If a client is 'openpgpkey unaware', they will be unaware of the la= test
OPENPGPKEYREVOC update. =C2=A0If they always check for the revocation, then=
they might as well be 'openpgpkey aware' and always refresh the key=
instead? =C2=A0Or am I missing a trick somewhere?

Stephen Nightingale.


On 7/25/2014 1:22 PM, Petr Spacek wrote:
> Hello,
>
> On 23.7.2014 23:34, Frederico A C Neves wrote:
>> Dear Colleagues,
>>
>> Bellow is a completed template requesting a new RRTYPE assignment<= br> >> under the procedures of RFC6895.
>>
>> This message starts a 2 weeks period for an expert review of the D= NS
>> RRTYPE parameter allocation for OPENPGPKEY specified at:
>>
>> http://tools.ietf.org/html/draft-ietf-dane-o= penpgpkey-00#section-2
>
> I was asking dane-list [1] if it makes sense to publish PGP key
> revocation certificate in OPENPGPKEY. I haven't heard any reply to= this
> idea yet (maybe it is too dumb idea to warrant single reply).
>
> There is one important detail to note:
> - OPENPGPKEY as proposed requires DNSSEC protection (it is public key)= .
> - Key revocation certificate doesn't require DNSSEC because the > certificate itself is signed.
>
> I think it is worth considering support for key revocation certificate= s
> in DNS because they can be deployed even more easily and rapidly
> (because DNSSEC is not required).
>
> The question is if it makes sense to publish both types of data using:=
> - Different RR type (a la OPENPGPREVOC)
> - The same RR type but under different _prefix (_revoc._openpgpkey?) > - Under the same owner name and RR type, which would (I guess) require=
> an additional field in OPENPGPKEY RR type
>
>
> Mixing keys and revocation data in single RR set will obviously result=
> in bigger replies. The question is if client should verify always veri= fy
> that the other keys of the same user were not revoked so it could make=
> sense to send him all the data in one response. (The older key could b= e
> obtained via non-DNS means etc.)
>
> On the other hand, "_openpgpkey aware" clients could always = check live
> data in DNS and use only keys which are present in DNS at the moment. = In
> that case removing RR which represents particular key will have the sa= me
> affect as key revocation (but only for "_openpgpkey aware" c= lients).
>
>
> Unfortunately I will not be available for next two weeks so I'm th= rowing
> the idea to mailing list without any promise to reply before 2014-08-1= 1.
>
> [1] http://www.ietf.org/mail-archive/web/dane/curre= nt/msg06672.html
>


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

--089e0162832c1c678b04ff07f880-- From nobody Fri Jul 25 13:32:48 2014 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 BFFB51A0310; Fri, 25 Jul 2014 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 mBraKxFWjK84; Fri, 25 Jul 2014 13:32:43 -0700 (PDT) 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 D64DB1A008B; Fri, 25 Jul 2014 13:32:43 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 292D61E34C; Fri, 25 Jul 2014 20:26:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1406320013; bh=/HBlrbk0AGyBqjGE96hHcOE6/Xlgyr9gHfLn9HCDqsY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZXuN1s3AWhXnmeYKt3oMDg5mStjPAkmvs/InPn5Zi8fGCNancMUge6SDFdxGc4jIf p1NrmuTBLnvdHoMRgdypb0pvZrWWBXjVEEgdIbpN6z0xyePQyuY2Vpb+Lo9qkyULD/ KOb7X6L9k8QcTPgpQSiW5d7pZqpqWwRqfFpBMvgw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 3C1F560021; Fri, 25 Jul 2014 20:12:20 +0000 (UTC) From: James Cloos To: Petr Spacek In-Reply-To: <53D2923E.6080903@redhat.com> (Petr Spacek's message of "Fri, 25 Jul 2014 19:22:06 +0200") References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.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, 25 Jul 2014 16:12:20 -0400 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140725:pspacek@redhat.com::uyv4082CjbddjwXt:000000000000000000000000000000000000000000DX/Gf X-Hashcash: 1:30:140725:dnsext@ietf.org::6FvcXPhe3XbrhWnd:00r/hr X-Hashcash: 1:30:140725:dane@ietf.org::clcXhWdAmGl7fsBi:000DYnbB X-Hashcash: 1:30:140725:pwouters@redhat.com::1bDqaRYGQqj9iu0C:00000000000000000000000000000000000000000cQsdG Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ui847kqpo3DuEFfJk4d6sqC2kY0 Cc: Paul Wouters , dnsext@ietf.org, dane WG list Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th 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, 25 Jul 2014 20:32:44 -0000 >>>>> "PS" == Petr Spacek writes: PS> I was asking dane-list [1] if it makes sense to publish PGP key PS> revocation certificate in OPENPGPKEY. I haven't heard any reply to PS> this idea yet (maybe it is too dumb idea to warrant single reply). I must have missed that last paragraph when I replied to the other part of that mail. If one is to publish openpgp keys in dns, then also publishing related revocation certs seems reasonable. If the querier already has a path through the WoT to the revoked key, a revocation signed by that key indeed does not need a dnssec trust path, too. But if the querier does not have a WoT path, they would benefit from the dnssec path. So as you wrote a signed revocation is useful even w/o dnssec, but dnssec does benefit some. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jul 25 19:57:00 2014 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 DCB7C1A01FA for ; Fri, 25 Jul 2014 19:56:57 -0700 (PDT) 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 ZCME9Ut6E1ak for ; Fri, 25 Jul 2014 19:56:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCCF1A01F7 for ; Fri, 25 Jul 2014 19:56:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3BFF62AB2B1; Sat, 26 Jul 2014 02:56:54 +0000 (UTC) Date: Sat, 26 Jul 2014 02:56:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140726025653.GQ15044@mournblade.imrryr.org> References: <20140724230432.D09771AC966F@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140724230432.D09771AC966F@rock.dv.isc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wZUDp-VeNroGpbUhRvdldRgg58s Subject: Re: [dane] draft-ietf-dane-srv-07 - identifiers in the cert 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, 26 Jul 2014 02:56:58 -0000 On Fri, Jul 25, 2014 at 09:04:32AM +1000, Mark Andrews wrote: > > The SNI discussion is also a bit unclear. To be nitpicking, someone pointed > > out to me that SNI only supports hostnames. If we want to ask for service > > domains we have to register a new type of SNI if I understood it correctly. > > This means that section 6 discussion about SNI in section 6 that > > recommends SNI with service domains is not really supported by SNI. > > The assumption is that one will share a port if the protocol permits > it (e.g. HTTPS, SMTP) so there are scaling issues. 50000 names in > a cert does not scale. Using the server name is the only real > solution. Note, with DANE-EE(3) the certificate name is immaterial, so the same certificate works for all ports, but this is of course a distraction. For any given service, sending the hostname is generally sufficient to disambiguate hosted domains and return the correct certificate. I also don't see a need for a new kind of SNI here. My hope is that DANE adoption will in the future make SNI generally unnecessary. -- Viktor. From nobody Sun Jul 27 09:18:59 2014 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 336B51A019A for ; Wed, 23 Jul 2014 17:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 sqlSEwGH3BUY for ; Wed, 23 Jul 2014 17:36:57 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B910A1A0115 for ; Wed, 23 Jul 2014 17:36:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9CBA72AB2B2; Thu, 24 Jul 2014 00:36:55 +0000 (UTC) Date: Thu, 24 Jul 2014 00:36:55 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724003655.GS2595@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: http://mailarchive.ietf.org/arch/msg/dane/M1FXWvTQyBL388ecmDVW2tZk-t4 X-Mailman-Approved-At: Sun, 27 Jul 2014 09:18:52 -0700 Subject: Re: [dane] on tlsa for rfc 7250 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, 24 Jul 2014 00:36:59 -0000 On Wed, Jul 23, 2014 at 03:42:28PM -0400, James Cloos wrote: > Thinking about 7250, I'm becoming convinced that we should recommend > that anyone publishing TLSA, whose software might have or gain support > for 7250, or might be accessed by clients which can support 7250, SHOULD > publish a 31x for them, in addition to any non-31x tlsa they publish. That is, publish "DANE-EE(3) SPKI(1) ? {blob}" associations for the public keys in any extant certificates, so as to allow the corresponding bare public keys to be used without the surrounding X.509 baggage later. If the protocol is in fact TLS (in which case the full keys are exchanged in-band), the matching type SHOULD typically be a digest, though for some algorithms (say EC curve 25519 keys), the key size is comparable to the size of its SHA2-256 digest. However, once "3 1 x" records are published, there is little point in publishing any other type of record. So I am not sure about the "in addition to" bit. Rather I would suggest "instead of". > Ie, those who prefer 0, 1 or 2 should publish both, for the benefit of > any 7250 clients which might access them. The cost of publishing "3 1 x" is that the server operator needs to update DNS when keys change, while with DANE-TA(2), a CNAME to the TA TLSA record can be published for each service, and the task of DNS updates is left to the organization's TA administrator. Once the cost burden (on each server operator) of updating "3 1 x" records is present already, also publishing "2 1 X" just makes things needlessly complex. There is no point. > Thoughts? I think that in most cases DANE users will publish either "3 1 X" or "3 0 X". With 7250 in mind, they should be encouraged to publish "3 1 X" and avoid "3 0 X". > I also remain conviced that, per liberal in what you accept, any 7250 > client should accept a 11x just as though it were a 31x, since the > association data is identical. This is what Postfix does, but is not what the SMTP draft says. I was dissuaded from formalizing such creative interpretation of TLSA RRs. If the publisher wants PKIX then the service should not agree to RPK (raw public keys) use and the client should be free to either do PKIX or treat the record as unusable, or at least that's all the server operator can expect. Clients might be more lenient, but no standard will require them to do it. If the group believes that Postel's rule applies here, and that non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as DANE-EE(3), then we SHOULD add that to the text the OPS draft, and update the SMTP draft accordingly. -- Viktor. From nobody Sun Jul 27 09:19:00 2014 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 4D3E81A0251 for ; Thu, 24 Jul 2014 05:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 FDIp5JUWD37J for ; Thu, 24 Jul 2014 05:43:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB2A1A024C for ; Thu, 24 Jul 2014 05:43:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 549702AB2A9; Thu, 24 Jul 2014 12:43:21 +0000 (UTC) Date: Thu, 24 Jul 2014 12:43:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724124321.GU2595@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: http://mailarchive.ietf.org/arch/msg/dane/E9j00dG7wfSveU33c4Eyzi0SSzI X-Mailman-Approved-At: Sun, 27 Jul 2014 09:18:53 -0700 Subject: Re: [dane] Draft ietf-dane-srv-07 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, 24 Jul 2014 12:43:26 -0000 On Thu, Jul 24, 2014 at 10:19:08AM +0200, Olle E. Johansson wrote: > Section 3: > > I really like this here, but would like it to be expanded a bit to help > implementors. The DNS SRV RFC is not easy to understand and in the IP > world RFC 3263 has confused a lot of people. DNS SRV says that all > candidates for a given priority should be attempted before one moves to > the next priority. It doesn't say anything about order, which this document > does when you say "SHOULD be performed in parallel". Note, the text at the top of Section 3: To expedite connection to the intended service, where possible the queries described in the following sections SHOULD be performed in parallel (this is similar to the "happy eyeballs" approach for IPv4 and IPv6 connections described in [RFC6555]). is encouraging parallel *DNS lookup*, not parallel connection attempts. And in fact parallel connection attempts would be wrong unless all the weights are equal, and, as a blanket policy, questionable even then. > If one given priority have two hosts with two IPv4 and three IPv6 each - > should all of them be tried in parallell? The answer is NO, because the document does not suggest connection concurrency, and because even that is I thing a mistake. When the weights are unequal, the client is supposed to employ some sort of RNG to choose candidate servers with a probability based on the weights. If the client is correctly employing weighted selection, parallel address lookup is generally inappropriate, in most cases the first (randomly) chosen server will in fact be available and lookups for other server addresses are I believe wasteful. Thus parallel lookups are only useful when the first server does not respond and further lookups are required to find more servers, and could arguably have been performed in parallel with the first lookup. However, after incurring a connection timeout with the first server, additional DNS lookup latency for the second server is not a major increment in the latency. Also one needs TLSA lookups which should only follow the address lookups because the TLSA lookup should not be made when the address records are not secure. (Also when CNAMEs are supported on the RHS of SRV records, the TLSA base domain is not known until the original address record is CNAME expanded). Bottom line I think the "parallel" language should be withdrawn. > This is a big issue and may be too big an issue for this document to cover, > especially with normative language. This document definitely cannot specify anything about connection concurrency. I would like to suggest strongly it also should *not* specify lookup concurrency. > According to the SIP domain cert RFC the CN should be disregarded > and NOT used if there are any SANs. I don't know the > reasoning behind this. Anyone? Should we do that here too or just forget it? This is IIRC either from 5280, 6125 or both. DNS names in the subject CN are deprecated, SANs are preferred, and trump the CN when both (at least one SAN of type DNS and a CN in the subject DN) are present. -- Viktor. From nobody Sun Jul 27 09:19:01 2014 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 567361A02B9 for ; Thu, 24 Jul 2014 05:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 YZZ0Gloq3bGV for ; Thu, 24 Jul 2014 05:56:58 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809181A023E for ; Thu, 24 Jul 2014 05:56:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 967B62AB2A9; Thu, 24 Jul 2014 12:56:57 +0000 (UTC) Date: Thu, 24 Jul 2014 12:56:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140724125657.GV2595@mournblade.imrryr.org> References: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/y-voRxLYA8ApFXZA2EizVxlUVbQ X-Mailman-Approved-At: Sun, 27 Jul 2014 09:18:53 -0700 Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-07.txt 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, 24 Jul 2014 12:57:00 -0000 On Wed, Jul 23, 2014 at 10:28:59AM -0700, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-07 For now comments on the -07 changes, will review the whole draft later. Section 3.1 paragraph 3 (page 4 line 17): If the the entire RRset is "insecure" or "indeterminate", this protocol has not been correctly deployed. The client SHOULD fall back to its non-DNSSEC, non-DANE behavior (this corresponds to the AD bit being unset). If the entire RRset is "bogus", the client MUST abort the attempt. delete [or "indeterminate"], per RFC 4035, from which "indeterminate" is reputedly taken, that status is essentially a lookup error (failure to determine whether the query zone is opted out or not), and so is not a case where the client simply falls back to non-DANE behaviour. Note the words "entire RRset" in paragraphs 3 and 4 are misleading. I believe that it is not possible for an RRset to be partially secure. Unless I am mistaken, RRSIGs apply to an RRset, not an individual RR. Since we're ultimately looking at an SRV RRset (possibly after CNAME expansion of the original domain), it is either secure in full or insecure in full. More appropriately, "entire" applies not to RRset, but rather "entire chain" of aliases (CNAME or DNAME if any) leading to the ultimate SRV RRset. Not continuing with connections to the target service applies when the DNS lookup fails ("bogus", "indeterminate", "timeout", ...). DNS lookup error handling is more comprehensively specified in the SMTP draft, and perhaps should be borrowed from that document in its entirety. -- Viktor. From nobody Sun Jul 27 09:19:24 2014 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 317091A0426; Fri, 25 Jul 2014 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_BELOW2=2.154] 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 ytuYXjdYkMMz; Fri, 25 Jul 2014 11:11:00 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F4F1A040C; Fri, 25 Jul 2014 11:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CFC76E2034; Fri, 25 Jul 2014 14:10:58 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 08126-07; Fri, 25 Jul 2014 14:10:57 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 0FE99E2031; Fri, 25 Jul 2014 14:10:57 -0400 (EDT) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id s6PIAuCa003989; Fri, 25 Jul 2014 14:10:56 -0400 From: Derek Atkins To: Petr Spacek References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> Date: Fri, 25 Jul 2014 14:10:56 -0400 In-Reply-To: <53D2923E.6080903@redhat.com> (Petr Spacek's message of "Fri, 25 Jul 2014 19:22:06 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nCuyJf_6Pfp4hJYesGCCWshDSD4 X-Mailman-Approved-At: Sun, 27 Jul 2014 09:19:05 -0700 Cc: Paul Wouters , dnsext@ietf.org, dane WG list Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th 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, 25 Jul 2014 18:11:01 -0000 Petr Spacek writes: > Hello, > > On 23.7.2014 23:34, Frederico A C Neves wrote: >> Dear Colleagues, >> >> Bellow is a completed template requesting a new RRTYPE assignment >> under the procedures of RFC6895. >> >> This message starts a 2 weeks period for an expert review of the DNS >> RRTYPE parameter allocation for OPENPGPKEY specified at: >> >> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2 > > I was asking dane-list [1] if it makes sense to publish PGP key > revocation certificate in OPENPGPKEY. I haven't heard any reply to > this idea yet (maybe it is too dumb idea to warrant single reply). > > There is one important detail to note: > - OPENPGPKEY as proposed requires DNSSEC protection (it is public key). Note that this public key could still (theoretically) be signed. Unless DANE is specifying it differently there should be no limitation that it be *just* the public key. > - Key revocation certificate doesn't require DNSSEC because the > certificate itself is signed. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Sun Jul 27 15:49:26 2014 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 D5F4F1A0A89; Sun, 27 Jul 2014 15:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 2NjL3N1mjx-5; Sun, 27 Jul 2014 15:49:21 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 A22521A02D1; Sun, 27 Jul 2014 15:49:21 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id E23281E26E; Sun, 27 Jul 2014 22:49:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1406501359; bh=z6SgzOM2M80UEfVl1a9XJkl6rQWThwDIRBKJVzhQlmg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Jt/dv/7TiwOnuVUozo2YFCHdzQKQUhTuRRW3ZolZPkP4Y3QbHZkys8KbJ8vbOc9se oQfglujvRrVlM17ev7dwvK6iUmKOyRA6O+2dBCt4zc/FB2j545vv233b4eEdJSL2KH Q3YAAkdoGw13v6+5pE+mdBKtZ5MpojANUxZ6kSQo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C6A6C60021; Sun, 27 Jul 2014 22:23:11 +0000 (UTC) From: James Cloos To: Derek Atkins In-Reply-To: (Derek Atkins's message of "Fri, 25 Jul 2014 14:10:56 -0400") References: <20140723213403.GN94557@registro.br> <53D2923E.6080903@redhat.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.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: Sun, 27 Jul 2014 18:23:11 -0400 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140727:warlord@mit.edu::JpeUjmMZW89w2UdM:0Od/kz X-Hashcash: 1:30:140727:pspacek@redhat.com::Y6Gm3Sx7BLXkI/qJ:0000000000000000000000000000000000000000003SoMI X-Hashcash: 1:30:140727:pwouters@redhat.com::qtygxFJNX5thpr85:00000000000000000000000000000000000000000Oxff2 X-Hashcash: 1:30:140727:dnsext@ietf.org::QT+T+mPug51WHDQV:0IqPkJ X-Hashcash: 1:30:140727:dane@ietf.org::Q1JVGuzbJ5kROGMu:000ADRps Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kgwmF5lltZXsyAg9hGGyMZ7fSRs Cc: Paul Wouters , dnsext@ietf.org, dane WG list Subject: Re: [dane] [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th 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: Sun, 27 Jul 2014 22:49:23 -0000 >>>>> "DA" == Derek Atkins writes: DA> Note that this public key could still (theoretically) be signed. Unless DA> DANE is specifying it differently there should be no limitation that it DA> be *just* the public key. That is an important point; unsigned OPENPGPKEY provides similar benefits as using the key servers. Part of the motivation for OPENPGPKEY was to provide an additional trust path to the dnssec root for those who lack a existing or sufficient path through the WoT. (I think everyone agrees that a nice path through the WoT to a key with ultimate trust is better, but if you WoT path is weak or non-extant than dns can at least provide /some/ trust.) Another aspect of the motivation is to have similar discovery paths for openpgp and smime -- where a dns trust path is arguably more useful. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From ml@bartschnet.de Mon Jul 28 04:39:35 2014 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 8C6C21A014F for ; Mon, 28 Jul 2014 04:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 7huA0VD4JrIx for ; Mon, 28 Jul 2014 04:39:33 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (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 F13C21A014C for ; Mon, 28 Jul 2014 04:39:32 -0700 (PDT) Received: (qmail 24192 invoked from network); 28 Jul 2014 11:39:31 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 28 Jul 2014 11:39:31 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 28 Jul 2014 13:39:30 +0200 From: Rene Bartsch To: dane@ietf.org Message-ID: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> X-Sender: ml@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/R9CRaoLet8AtfTL3eEfFH9-dJo0 Subject: [dane] Comments on draft-wouters-dane-openpgp-02 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, 28 Jul 2014 11:41:28 -0000 Hello, I've three suggestions on draft-wouters-dane-openpgp-02: 1. email domain providers MUST provide a secure API/interface to customers to provide a personal OpenPGP public key 2. MTAs/SPAM detection systems MUST check if the tupel "sender email address" <-> "sender OpenPGP public key" matches and MUST reject the email in case it does not match with signed messages to prevent address forgery and SPAM. 3. Security considerations: The IANA has control over the DNSSEC root keys. As the IANA is bound to US law, US government agencies probably have access to the DNSSEC root keys and are capable to manipulate the OpenPGP keys signed with DNSSEC. -- Best regards, Renne Rene Bartsch, B. Sc. Informatics From nobody Mon Jul 28 06:52:16 2014 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 A2D621A03FD for ; Mon, 28 Jul 2014 06:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 wrjMtTc2oW-O for ; Mon, 28 Jul 2014 06:52:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60971B27FC for ; Mon, 28 Jul 2014 06:52:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5783080048; Mon, 28 Jul 2014 09:52:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406555530; bh=aC2vUzWKi5PC34Go9zFh9IxfHTVjjBP/WhCBfXtjf44=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=u2Qx6QG0R0bW8ST7SVFGGhAix1dyC9mMRPy+An0jGQWEF+hznhoHb3vX8LbdHIZml EMSvNeM5hrViAoiWKSYGQ/PgX3/jMZ3V3xwbW1VPivpMjxrJ80tq83NqFq5A/L+ShV 8O1iYirCScHxKgQt0BAXCNp2lUm+GCMMUjUECt6U= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6SDq94M031549; Mon, 28 Jul 2014 09:52:09 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 28 Jul 2014 09:52:09 -0400 (EDT) From: Paul Wouters To: Rene Bartsch In-Reply-To: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> Message-ID: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> 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: http://mailarchive.ietf.org/arch/msg/dane/C0CX_M5JoHr8U38a714NQmavT_U Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-wouters-dane-openpgp-02 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, 28 Jul 2014 13:52:15 -0000 On Mon, 28 Jul 2014, Rene Bartsch wrote: > I've three suggestions on draft-wouters-dane-openpgp-02: > > 1. email domain providers MUST provide a secure API/interface to customers to > provide a personal OpenPGP public key The draft document is the "secure API" to obtain records. The IETF is not an organisation that can tell domain providers what they must provide to their customers. > 2. MTAs/SPAM detection systems MUST check if the tupel "sender email address" > <-> "sender OpenPGP public key" matches and MUST reject the email in case it > does not match with signed messages to prevent address forgery and SPAM. These are security considerations that should be discussed for http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00 Note that I don't agree with the check you propose. I might be using a different key for my "default email" protection, versus a manually verified web of trust key. That is, my "default email" key might be online and auto-decrypt on my own server, while my "web of trust" key is completely offline- and I might not even want to publish it in DNS or elsewhere. Although I agree that anti-spam based solutions could surely taking signing into consideration in their determination of spam versus ham. > 3. Security considerations: The IANA has control over the DNSSEC root keys. > As the IANA is bound to US law, US government agencies probably have access > to the DNSSEC root keys and are capable to manipulate the OpenPGP keys signed > with DNSSEC. There is currently a first attempt at specifying transparancy for DNSSEC for those who want to audit/track the DNSSEC root or parent domain holders: http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00 Paul From nobody Mon Jul 28 06:53:39 2014 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 CF68A1B2819 for ; Mon, 28 Jul 2014 06:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 jizF_c6kQMde for ; Mon, 28 Jul 2014 06:53:37 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C3B1A03FD for ; Mon, 28 Jul 2014 06:53:37 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 44A1280048; Mon, 28 Jul 2014 09:53:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406555616; bh=iRV//ujI7ieEQ+c2gd6oB4YVutCXOjJTze2NcGsf2+o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=By2UwGJgKJJgk9qG/2BR7hd+/ohjsPZxLKnGEBJNc3wMHMc/QC2dqnt5DzXI+axQ8 wh6o51kJ//cxPR/ue9AbzQ7sTOI8yR4sQB+QbDV9FYk8HtfiU1G9BuI1iREmQV1uSj Rif6IYjmgW3M/EVZ6yNcVxI//ea4zIs4/0mDneX4= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6SDraPc031670; Mon, 28 Jul 2014 09:53:36 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 28 Jul 2014 09:53:36 -0400 (EDT) From: Paul Wouters To: Rene Bartsch In-Reply-To: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> Message-ID: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> 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: http://mailarchive.ietf.org/arch/msg/dane/B4e7ymCPDLpsasOuY0QMn-YWM1U Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-wouters-dane-openpgp-02 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, 28 Jul 2014 13:53:38 -0000 On Mon, 28 Jul 2014, Rene Bartsch wrote: > Subject: [dane] Comments on draft-wouters-dane-openpgp-02 Also, please note that draft-wouters-dane-openpgp-02 was adopted by the working group and is now proceeding as draft-ietf-dane-openpgpkey: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00 Paul From nobody Mon Jul 28 07:47:17 2014 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 CF0921A0385 for ; Mon, 28 Jul 2014 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 Id_Q8JBI8xw5 for ; Mon, 28 Jul 2014 07:47:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 95F331A0292 for ; Mon, 28 Jul 2014 07:47:14 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6SElC3L019199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jul 2014 16:47:12 +0200 (MEST) In-Reply-To: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> To: Rene Bartsch Date: Mon, 28 Jul 2014 16:47:12 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140728144712.1B7991ADC9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zNUztDyJkPI1VfS1GvPbxONhZpA Cc: dane@ietf.org Subject: Re: [dane] Comments on draft-wouters-dane-openpgp-02 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:47:16 -0000 Rene Bartsch wrote: > > 2. MTAs/SPAM detection systems MUST check if the tupel "sender email > address" <-> "sender OpenPGP public key" matches and MUST reject the > email in case it does not match with signed messages to prevent address > forgery and SPAM. Terribly bad idea. Similar to DMARC policies, such behaviour by MTA would be a true criminal offence when performed by telecommunications service providers under EU jurisdiction. This is a check for the receiving MUA to perform. -Martin From nobody Mon Jul 28 07:59:16 2014 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 4F9FA1B287D for ; Mon, 28 Jul 2014 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 QCx-ogTRUm9y for ; Mon, 28 Jul 2014 07:59:13 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (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 5376D1B2866 for ; Mon, 28 Jul 2014 07:59:13 -0700 (PDT) Received: (qmail 16039 invoked from network); 28 Jul 2014 14:59:10 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 28 Jul 2014 14:59:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 28 Jul 2014 16:59:09 +0200 From: Rene Bartsch To: dane@ietf.org In-Reply-To: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> Message-ID: X-Sender: ml@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/U3Tc7HdS-34y8ZIqgy4wVswlZ3E Subject: [dane] =?utf-8?q?Manipulation_of_DNSSEC_by_US_government_possible?= =?utf-8?q?=3F_=28was_Re=3A__Comments_on_draft-wouters-dane-openpgp-02=29?= 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, 28 Jul 2014 14:59:15 -0000 Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see how it would help. Consider the following case: (Forced by secret US law) The IANA secretly hands over the current private key of the DNSSEC trust anchor to a US government agency which uses the private key to sign forged zones and feeds them to DNS resolvers. That way US government agencies would be able to manipulate any DNS record including OpenPGP while users would be lulled in a false sense of security. In case I didn't miss any super-security feature users should be aware of that fact. Am 2014-07-28 15:52, schrieb Paul Wouters: >> 3. Security considerations: The IANA has control over the DNSSEC root >> keys. As the IANA is bound to US law, US government agencies probably >> have access to the DNSSEC root keys and are capable to manipulate the >> OpenPGP keys signed with DNSSEC. > > There is currently a first attempt at specifying transparancy for > DNSSEC for those who want to audit/track the DNSSEC root or parent > domain holders: > > http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00 > > Paul -- Best regards, Renne From nobody Mon Jul 28 08:02:38 2014 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 F28B41B287C for ; Mon, 28 Jul 2014 08:02:36 -0700 (PDT) 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 2NVus9dwplkH for ; Mon, 28 Jul 2014 08:02:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464241A02E6 for ; Mon, 28 Jul 2014 08:02:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 33D542AB2AE; Mon, 28 Jul 2014 15:02:31 +0000 (UTC) Date: Mon, 28 Jul 2014 15:02:31 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140728150230.GW15044@mournblade.imrryr.org> References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <20140728144712.1B7991ADC9@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140728144712.1B7991ADC9@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9GZPG62WXUmU8azvu9G3ExOX-CA Subject: Re: [dane] Comments on draft-wouters-dane-openpgp-02 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, 28 Jul 2014 15:02:37 -0000 On Mon, Jul 28, 2014 at 04:47:12PM +0200, Martin Rex wrote: > Rene Bartsch wrote: > > > > 2. MTAs/SPAM detection systems MUST check if the tupel "sender email > > address" <-> "sender OpenPGP public key" matches and MUST reject the > > email in case it does not match with signed messages to prevent address > > forgery and SPAM. > > Terribly bad idea. Similar to DMARC policies, such behaviour by MTA > would be a true criminal offence when performed by telecommunications > service providers under EU jurisdiction. > > This is a check for the receiving MUA to perform. Laws aside, PGP is an end-to-end security mechanism, and is generally the concern of MUAs not MTAs. A PGP-signed message can be Resent or forwarded via a list, and the envelope sender need not match the message author. Yes, I also find DMARC distasteful on technical, rather than legal grounds. -- Viktor. From nobody Mon Jul 28 09:14:10 2014 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 0C21A1A038E for ; Mon, 28 Jul 2014 09:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 mc256Ht2c1O4 for ; Mon, 28 Jul 2014 09:14:08 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD801A038C for ; Mon, 28 Jul 2014 09:14:07 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5EB88813B2; Mon, 28 Jul 2014 12:14:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406564046; bh=osq/JeUZkun8fO+J7UmrQN4leH31eQ7FUV9pXXfnzyI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NY30PDlSNKxFT7h7iEwkHfA7tp7c1TYDLNlWozhGOtOc/8tYxkyKd6HIXw5UjWqmN Y8rKy2hGJNE3xxefnRXWphMjZNcpFO2kFmZWpF7ThUolCqmydfmVAfCoXWCJo2+aDK +EyEJoKIJZbBZdd+GRH+YnPkOI47maom4axxiMAs= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6SGE51n012924; Mon, 28 Jul 2014 12:14:06 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 28 Jul 2014 12:14:05 -0400 (EDT) From: Paul Wouters To: Rene Bartsch In-Reply-To: Message-ID: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> 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: http://mailarchive.ietf.org/arch/msg/dane/An5VOpqTOjDQ8cRPPkBPRAHJTB4 Cc: dane@ietf.org Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) 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, 28 Jul 2014 16:14:09 -0000 On Mon, 28 Jul 2014, Rene Bartsch wrote: > Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see how it > would help. Consider the following case: > > (Forced by secret US law) The IANA secretly hands over the current private > key of the DNSSEC trust anchor to a US government agency which uses the > private key to sign forged zones and feeds them to DNS resolvers. That way US > government agencies would be able to manipulate any DNS record including > OpenPGP while users would be lulled in a false sense of security. > > In case I didn't miss any super-security feature users should be aware of > that fact. An audit log or reputation system would prevent the user from believing a signed answer by a different "good" key. For the USG to take over your domain, for which they do not have the private key, they need to take over the parent domain and change the key listed there. That change can be detected by you. Paul From nobody Mon Jul 28 09:43:53 2014 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 06FE91A0503 for ; Mon, 28 Jul 2014 09:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 ghzsgKYcGogn for ; Mon, 28 Jul 2014 09:43:50 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 782361A03B3 for ; Mon, 28 Jul 2014 09:43:50 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 3851F202043 for ; Mon, 28 Jul 2014 09:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SUXxo8kZvlega/9EevC+ f8vq2FA=; b=PWDS6vIIpb52p7gSdcXzkffTvCP08RI36atiLSiQBpdzKGCbwUUT RnM7wkxj3IJf4RtRANu5zsg6MnbhLicg4mmR0r3uSrVpPDRr/MsxW8yjB4DAtRdm Yag5CU3sAhigH7C8jXBUXxNKD20N4llcueCx8HN+P58JeQEm28jjIcs= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id C520520203C for ; Mon, 28 Jul 2014 09:43:49 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so4672299wiv.15 for ; Mon, 28 Jul 2014 09:43:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr32477160wiv.3.1406565826476; Mon, 28 Jul 2014 09:43:46 -0700 (PDT) Received: by 10.217.98.6 with HTTP; Mon, 28 Jul 2014 09:43:46 -0700 (PDT) In-Reply-To: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> Date: Mon, 28 Jul 2014 11:43:46 -0500 Message-ID: From: Nico Williams To: Rene Bartsch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wZ96Zjmq2fX8GgBrz1io0_lpknQ Cc: dane@ietf.org Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) 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, 28 Jul 2014 16:43:51 -0000 With CT the attacker has these choices: - compromise the target zone and its logs - compromise the target zone and be an MITM forever more and hope that no one notices the logged changes This is a significant improvement over the current situation, where the attacker can be an undetected MITM when and as desired once they compromise the zone. Nico -- From nobody Mon Jul 28 10:13:11 2014 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 EF23B1A03DE for ; Mon, 28 Jul 2014 10:13:04 -0700 (PDT) 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 jVymvKGi6X14 for ; Mon, 28 Jul 2014 10:13:02 -0700 (PDT) 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 255D71A041C for ; Mon, 28 Jul 2014 10:12:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 8EC6E803E2; Mon, 28 Jul 2014 13:12:45 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp20.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 334EE802CE; Mon, 28 Jul 2014 13:12:45 -0400 (EDT) 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 AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Mon, 28 Jul 2014 17:12:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Olafur Gudmundsson In-Reply-To: Date: Mon, 28 Jul 2014 13:12:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> To: Rene Bartsch X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pevQnigQdAp7WsCCxiJXZN4kClw Cc: dane@ietf.org Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) 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, 28 Jul 2014 17:13:05 -0000 =20 This discussion is off topic.=20 DANE is about how to leverage DNSSEC by applications and conspiracy = theories are not within our charter.=20 Anyone that does not trust DNSSEC operations is free to ignore = distribution of OPENPGP keys via DNS, and continue to=20 use the web of trust.=20 =20 Olafur On Jul 28, 2014, at 10:59 AM, Rene Bartsch wrote: > Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see = how it would help. Consider the following case: >=20 > (Forced by secret US law) The IANA secretly hands over the current = private key of the DNSSEC trust anchor to a US government agency which = uses the private key to sign forged zones and feeds them to DNS = resolvers. That way US government agencies would be able to manipulate = any DNS record including OpenPGP while users would be lulled in a false = sense of security. >=20 > In case I didn't miss any super-security feature users should be aware = of that fact. >=20 > Am 2014-07-28 15:52, schrieb Paul Wouters: >>> 3. Security considerations: The IANA has control over the DNSSEC = root keys. As the IANA is bound to US law, US government agencies = probably have access to the DNSSEC root keys and are capable to = manipulate the OpenPGP keys signed with DNSSEC. >> There is currently a first attempt at specifying transparancy for >> DNSSEC for those who want to audit/track the DNSSEC root or parent >> domain holders: >> http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00 >> Paul >=20 > --=20 > Best regards, >=20 > Renne >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jul 30 03:15:17 2014 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 7E3D91A034B for ; Wed, 30 Jul 2014 03:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, 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 YQZZU6F0xWhd for ; Wed, 30 Jul 2014 03:15:14 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (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 9D2FE1A0218 for ; Wed, 30 Jul 2014 03:15:13 -0700 (PDT) Received: (qmail 26803 invoked from network); 30 Jul 2014 10:15:10 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 30 Jul 2014 10:15:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 30 Jul 2014 12:15:08 +0200 From: Rene Bartsch To: dane@ietf.org In-Reply-To: <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> Message-ID: <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3XEGfSTTDTzAQZejlCCJlDY6aeI Subject: Re: [dane] =?utf-8?q?Manipulation_of_DNSSEC_by_US_government_possible?= =?utf-8?q?=3F_=28was_Re=3A__Comments_on_draft-wouters-dane-openpgp-02=29?= 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, 30 Jul 2014 10:15:15 -0000 Two years ago I would have thought the same. But today we are far beyond conspiracy theories. We are facing the biggest coordinated hacker attack in history of the internet. After what we've learned in the last year the US government has abused the trust of billions of internet users to gain control over the internet. We have no clue what other governments and intelligence angencies have done or might do. The former director of the austrian intelligence agency expects a lot of new disclosures in the next half year. Internet users worldwide are furious about the situation. If we sell DANE as magic bullet without mentioning the trust anchor can manipulate the whole DNSSEC system and who the trust anchor is users will trust DANE blindly. If the trust anchor abuses control over DNSSEC this will blow up right into our face and harm the reputation of the IETF. In my opinion we should mention the identity of the DNSSEC trust anchor in security considerations and we should mention the DNSSEC trust anchor has the possibility to manipulate the whole DNSSEC system. Regards, Renne Am 2014-07-28 19:12, schrieb Olafur Gudmundsson: > > This discussion is off topic. > DANE is about how to leverage DNSSEC by applications and conspiracy > theories are not within our charter. > > Anyone that does not trust DNSSEC operations is free to ignore > distribution of OPENPGP keys via DNS, and continue to > use the web of trust. > > > Olafur > > On Jul 28, 2014, at 10:59 AM, Rene Bartsch wrote: > >> Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see >> how it would help. Consider the following case: >> >> (Forced by secret US law) The IANA secretly hands over the current >> private key of the DNSSEC trust anchor to a US government agency which >> uses the private key to sign forged zones and feeds them to DNS >> resolvers. That way US government agencies would be able to manipulate >> any DNS record including OpenPGP while users would be lulled in a >> false sense of security. >> >> In case I didn't miss any super-security feature users should be aware >> of that fact. >> >> Am 2014-07-28 15:52, schrieb Paul Wouters: >>>> 3. Security considerations: The IANA has control over the DNSSEC >>>> root keys. As the IANA is bound to US law, US government agencies >>>> probably have access to the DNSSEC root keys and are capable to >>>> manipulate the OpenPGP keys signed with DNSSEC. >>> There is currently a first attempt at specifying transparancy for >>> DNSSEC for those who want to audit/track the DNSSEC root or parent >>> domain holders: >>> http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00 >>> Paul >> >> -- >> Best regards, >> >> Renne >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Wed Jul 30 05:49:36 2014 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 C1C261A0029 for ; Wed, 30 Jul 2014 05:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zeCIqvYvc1gL for ; Wed, 30 Jul 2014 05:49:32 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBCD1A0021 for ; Wed, 30 Jul 2014 05:49:28 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKU9jp2HTPPmjfwGwxLi7nY3v2IABhujDp@postini.com; Wed, 30 Jul 2014 05:49:32 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s6UCnR19020394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 08:49:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 08:49:27 -0400 From: "Wiley, Glen" To: Rene Bartsch , "dane@ietf.org" Thread-Topic: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) Thread-Index: AQHPq98tcnfsFPnAA0Gg95Mp3u8nAJu4kaIA Date: Wed, 30 Jul 2014 12:49:26 +0000 Message-ID: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> In-Reply-To: <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <062BDC1903A76643AB6959A1435B6C32@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jeYRxybGxcaog-cs6fpKg1_HCAk Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) 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, 30 Jul 2014 12:49:34 -0000 Renne, While it is technically true that the holder of the trust anchor could alter key material it would be impossible to accomplish unnoticed. In order for a trust anchor to change your zone (say by changing an A record) they would have to create a new private key (and corresponding public key) then sign the altered RR set. Your DNS key signing and zone signing keys should be protected with as much diligence as your private signing and encryption keys. It is as though a locksmith would have to change the locks on a house in order to open the door. Sure they can do it but the homeowner will notice immediately when their keys no longer work. My analogy breaks down if you take it too far, but I hope it conveys the point. I am far more worried about vectors that can be leveraged passively and unobtrusively. I agree that we should be open about DNSSEC/DANE however the holder of the trust anchor can not manipulate the DNS without being detected. --=20 Glen Wiley KK4SFV Sr. Engineer The Hive, Verisign, Inc. On 7/30/14 6:15 AM, "Rene Bartsch" wrote: >Two years ago I would have thought the same. But today we are far beyond >conspiracy theories. We are facing the biggest coordinated hacker attack >in history of the internet. After what we've learned in the last year >the US government has abused the trust of billions of internet users to >gain control over the internet. We have no clue what other governments >and intelligence angencies have done or might do. The former director of >the austrian intelligence agency expects a lot of new disclosures in the >next half year. Internet users worldwide are furious about the >situation. > >If we sell DANE as magic bullet without mentioning the trust anchor can >manipulate the whole DNSSEC system and who the trust anchor is users >will trust DANE blindly. If the trust anchor abuses control over DNSSEC >this will blow up right into our face and harm the reputation of the >IETF. > >In my opinion we should mention the identity of the DNSSEC trust anchor >in security considerations and we should mention the DNSSEC trust anchor >has the possibility to manipulate the whole DNSSEC system. > >Regards, > >Renne > > >Am 2014-07-28 19:12, schrieb Olafur Gudmundsson: >> >> This discussion is off topic. >> DANE is about how to leverage DNSSEC by applications and conspiracy >> theories are not within our charter. >>=20 >> Anyone that does not trust DNSSEC operations is free to ignore >> distribution of OPENPGP keys via DNS, and continue to >> use the web of trust. >> >>=20 >> Olafur >>=20 >> On Jul 28, 2014, at 10:59 AM, Rene Bartsch wrote: >>=20 >>> Maybe I misunderstood draft-zhang-ct-dnssec-trans-00 but I do not see >>> how it would help. Consider the following case: >>>=20 >>> (Forced by secret US law) The IANA secretly hands over the current >>> private key of the DNSSEC trust anchor to a US government agency which >>> uses the private key to sign forged zones and feeds them to DNS >>> resolvers. That way US government agencies would be able to manipulate >>> any DNS record including OpenPGP while users would be lulled in a >>> false sense of security. >>>=20 >>> In case I didn't miss any super-security feature users should be aware >>> of that fact. >>>=20 >>> Am 2014-07-28 15:52, schrieb Paul Wouters: >>>>> 3. Security considerations: The IANA has control over the DNSSEC >>>>> root keys. As the IANA is bound to US law, US government agencies >>>>> probably have access to the DNSSEC root keys and are capable to >>>>> manipulate the OpenPGP keys signed with DNSSEC. >>>> There is currently a first attempt at specifying transparancy for >>>> DNSSEC for those who want to audit/track the DNSSEC root or parent >>>> domain holders: >>>> http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00 >>>> Paul >>>=20 >>> -- >>> Best regards, >>>=20 >>> Renne >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane > >--=20 >Best regards, > >Rene Bartsch, B. Sc. Informatics > >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From nobody Wed Jul 30 06:21:26 2014 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 403491A0046 for ; Wed, 30 Jul 2014 06:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ZckGs-gmd15k for ; Wed, 30 Jul 2014 06:21:20 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE32F1A0053 for ; Wed, 30 Jul 2014 06:21:16 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 8E0671FCB4C; Wed, 30 Jul 2014 13:21:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 50E97160066; Wed, 30 Jul 2014 13:30:54 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 1FD97160051; Wed, 30 Jul 2014 13:30:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 432C11B1536F; Wed, 30 Jul 2014 23:21:06 +1000 (EST) To: "Wiley, Glen" From: Mark Andrews References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> In-reply-to: Your message of "Wed, 30 Jul 2014 12:49:26 +0000." Date: Wed, 30 Jul 2014 23:21:06 +1000 Message-Id: <20140730132106.432C11B1536F@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ShKoJK3e_mxNRZq3MSaBXgE8LQ8 Cc: "dane@ietf.org" Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) 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, 30 Jul 2014 13:21:22 -0000 In message , "Wiley, Glen" writes: > Renne, > > While it is technically true that the holder of the trust anchor could > alter key material it would be impossible to accomplish unnoticed. In > order for a trust anchor to change your zone (say by changing an A record) > they would have to create a new private key (and corresponding public key) > then sign the altered RR set. > > Your DNS key signing and zone signing keys should be protected with as > much diligence as your private signing and encryption keys. > > It is as though a locksmith would have to change the locks on a house in > order to open the door. Sure they can do it but the homeowner will notice > immediately when their keys no longer work. My analogy breaks down if you > take it too far, but I hope it conveys the point. > > I am far more worried about vectors that can be leveraged passively and > unobtrusively. > > I agree that we should be open about DNSSEC/DANE however the holder of the > trust anchor can not manipulate the DNS without being detected. If one can intecept the packets one could fake up a world view. This would be detectable if you have trust anchors for the parts of the world being faked. If one can't intercept the packets it will be almost certainly be detected. Maintaining a set trust anchors for all the TLD's would defeat most of the threat. A state agency would have to compromise multiple tlds to pull this off not just the root. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 31 03:37:11 2014 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 D69971A01C6 for ; Thu, 31 Jul 2014 03:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 VzcntCF7kMJe for ; Thu, 31 Jul 2014 03:37:04 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (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 56D6B1A0AAE for ; Thu, 31 Jul 2014 03:37:02 -0700 (PDT) Received: (qmail 23195 invoked from network); 31 Jul 2014 10:37:00 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 31 Jul 2014 10:37:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 31 Jul 2014 12:36:59 +0200 From: Rene Bartsch To: dane@ietf.org In-Reply-To: <20140730132106.432C11B1536F@rock.dv.isc.org> References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> Message-ID: <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/oZDFsJBCDJNLnzE4K7npKCzYmGI Subject: Re: [dane] =?utf-8?q?Manipulation_of_DNSSEC_by_US_government_possible?= =?utf-8?q?=3F_=28was_Re=3A_Comments_on_draft-wouters-dane-openpgp-02=29?= 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, 31 Jul 2014 10:37:09 -0000 Am 2014-07-30 15:21, schrieb Mark Andrews: > In message , "Wiley, Glen" writes: >> Renne, >> >> While it is technically true that the holder of the trust anchor could >> alter key material it would be impossible to accomplish unnoticed. In >> order for a trust anchor to change your zone (say by changing an A >> record) >> they would have to create a new private key (and corresponding public >> key) >> then sign the altered RR set. >> >> Your DNS key signing and zone signing keys should be protected with as >> much diligence as your private signing and encryption keys. >> >> It is as though a locksmith would have to change the locks on a house >> in >> order to open the door. Sure they can do it but the homeowner will >> notice >> immediately when their keys no longer work. My analogy breaks down if >> you >> take it too far, but I hope it conveys the point. >> >> I am far more worried about vectors that can be leveraged passively >> and >> unobtrusively. >> >> I agree that we should be open about DNSSEC/DANE however the holder of >> the >> trust anchor can not manipulate the DNS without being detected. > > If one can intecept the packets one could fake up a world view. > This would be detectable if you have trust anchors for the parts > of the world being faked. > > If one can't intercept the packets it will be almost certainly be > detected. > > Maintaining a set trust anchors for all the TLD's would defeat most > of the threat. A state agency would have to compromise multiple > tlds to pull this off not just the root. I have the following attack in mind: An attacker (Mallory) with access to the trust anchor keys runs a man-in-the-middle attack on sender and recipient. He forges the OPENPGPKEY RRs, the ZSK-RRs and KSK-RRs of the sender and recipient domains and the TLDs but uses the current origin keys of the trust anchor to sign the forged DNSSEC RRs. Alice gets the OPENPGPKEY 1 of Mallory as Bob's and Bob gets the OPENPGPKEY 2 of Mallory as Alice's via DANE. Alice -> OPENPGPKEY 1 of Mallory -> Mallory -> OPENPGPKEY of Bob -> Bob Bob -> OPENPGPKEY 2 of Mallory -> Mallory -> OPENPGPKEY of Alice -> Alice Unless Alice and Bob do not accidentially compare their public OpenPGP keys manually they won't realize the attack. It seems DNSSEC/DANE helps against most hackers and attackers but cannot protect from attackers which have access to both the trust anchor keys and routing infrastructure. Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver software? Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Thu Jul 31 03:44:05 2014 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 A2B7D1A0AAB for ; Thu, 31 Jul 2014 03:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 z_gdWd3kEaj7 for ; Thu, 31 Jul 2014 03:43:59 -0700 (PDT) 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 C09A31A03F6 for ; Thu, 31 Jul 2014 03:43:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 6F27A3493DB; Thu, 31 Jul 2014 10:43:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 95DCE160066; Thu, 31 Jul 2014 10:53:43 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 62A8216004E; Thu, 31 Jul 2014 10:53:43 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 82C181B45C5D; Thu, 31 Jul 2014 20:43:50 +1000 (EST) To: Rene Bartsch From: Mark Andrews References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> In-reply-to: Your message of "Thu, 31 Jul 2014 12:36:59 +0200." <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> Date: Thu, 31 Jul 2014 20:43:50 +1000 Message-Id: <20140731104350.82C181B45C5D@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eqb6L5ujemThSr5xYl4bfgyD6cI Cc: dane@ietf.org Subject: Re: [dane] =?utf-8?q?Manipulation_of_DNSSEC_by_US_government_possible?= =?utf-8?q?=3F_=28was_Re=3A_Comments_on_draft-wouters-dane-openpgp-02=29?= 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, 31 Jul 2014 10:44:01 -0000 In message <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de>, Rene Bar tsch writes: > Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver > software? Yes. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Jul 31 08:10:42 2014 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 AD96D1A00E6 for ; Thu, 31 Jul 2014 08:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 XbQLmxg-QH2h for ; Thu, 31 Jul 2014 08:10:38 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858211A0092 for ; Thu, 31 Jul 2014 08:10:38 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EBDA580048; Thu, 31 Jul 2014 11:10:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406819436; bh=XTxvaEr2RX5FIR7R/6hIygVSttIAM/5ZI4CQhAWGHko=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=agsxn5iqm0TmVdb9BJgdL1N6BAa3y1o89H2mXLHhlr9yzw0rUeYCB5sovSI/G5o8T Dp9QSzSihhDlReaYk9UV3WoDvpA4kGDk2QO0SQpHXhjPzR6OSmq7xIXJ/tuiTE1rON +UGf0htIMBhbQ27r+oFCVWPf+3c8eYi2XhJ5VlMA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6VFAa3U012919; Thu, 31 Jul 2014 11:10:36 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 31 Jul 2014 11:10:36 -0400 (EDT) From: Paul Wouters To: Rene Bartsch In-Reply-To: <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> Message-ID: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> 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: http://mailarchive.ietf.org/arch/msg/dane/tv-Xr5nL10I2R57uOvUer1g-l8s Cc: dane WG list Subject: Re: [dane] Manipulation of DNSSEC by US government possible? (was Re: Comments on draft-wouters-dane-openpgp-02) 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, 31 Jul 2014 15:10:40 -0000 On Thu, 31 Jul 2014, Rene Bartsch wrote: > It seems DNSSEC/DANE helps against most hackers and attackers but cannot > protect from attackers which have access to both the trust anchor keys and > routing infrastructure. Whom do you trust? "No one" is not a valid answer. The best we can do is audit/log the KSKs and do some kind of "N of M" verification that such keys are in the public world view. Of course, that leads to small outages during rollovers.... > Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver > software? Of course. That's not so much a matter of protocol but of local policy. Paul From nobody Thu Jul 31 10:36:46 2014 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 B88DF1A02E3 for ; Thu, 31 Jul 2014 10:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, 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 mAAyMz9E9uqs for ; Thu, 31 Jul 2014 10:36:42 -0700 (PDT) Received: from triangulum.uberspace.de (triangulum.uberspace.de [95.143.172.227]) (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 884C31A026F for ; Thu, 31 Jul 2014 10:36:41 -0700 (PDT) Received: (qmail 12646 invoked from network); 31 Jul 2014 17:36:37 -0000 Received: from localhost (HELO www.bartschnet.de) (127.0.0.1) by triangulum.uberspace.de with SMTP; 31 Jul 2014 17:36:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 31 Jul 2014 19:36:34 +0200 From: Rene Bartsch To: dane WG list In-Reply-To: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> Message-ID: <75c3ef7eef38c9d621b9e69976865d26@triangulum.uberspace.de> X-Sender: ietf@bartschnet.de User-Agent: Roundcube Webmail/1.0.1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XsXs-Q4HbYB3Q1XFyCXiFcynk6k Subject: Re: [dane] =?utf-8?q?Manipulation_of_DNSSEC_by_US_government_possible?= =?utf-8?q?=3F_=28was_Re=3A_Comments_on_draft-wouters-dane-openpgp-02=29?= 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, 31 Jul 2014 17:36:43 -0000 Am 2014-07-31 17:10, schrieb Paul Wouters: > On Thu, 31 Jul 2014, Rene Bartsch wrote: > >> It seems DNSSEC/DANE helps against most hackers and attackers but >> cannot protect from attackers which have access to both the trust >> anchor keys and routing infrastructure. > > Whom do you trust? "No one" is not a valid answer. http://en.wikipedia.org/wiki/Bundesnachrichtendienst#History In global communication I only trust mathematically proven algorithms. But don't worry, I trust people I've known for years personally. ;-) > The best we can do is > audit/log the KSKs and do some kind of "N of M" verification that such > keys are in the public world view. Of course, that leads to small > outages during rollovers.... > >> Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with >> resolver software? > > Of course. That's not so much a matter of protocol but of local policy. > > Paul In hierarchical architectures we always have a more or less trustworthy anchor. So we should clearly describe the security limitations in the security considerations section. Real security has to wait until the next evolution step of the internet (maybe blockchains?). Renne -- Best regards, Rene Bartsch, B. Sc. Informatics From nobody Thu Jul 31 11:22:16 2014 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 025841A0303 for ; Thu, 31 Jul 2014 11:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.248 X-Spam-Level: ** X-Spam-Status: No, score=2.248 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-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 Lqp8pCbORh9m for ; Thu, 31 Jul 2014 11:22:13 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654811A0271 for ; Thu, 31 Jul 2014 11:22:12 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s6VIM2lO024077; Thu, 31 Jul 2014 11:22:02 -0700 Message-Id: <201407311822.s6VIM2lO024077@new.toad.com> To: Rene Bartsch In-reply-to: <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> Comments: In-reply-to Rene Bartsch message dated "Thu, 31 Jul 2014 12:36:59 +0200." Date: Thu, 31 Jul 2014 11:22:02 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ClEYGuQXXfD6jE71nZHDG-R3G0U Cc: dane@ietf.org Subject: Re: [dane] Manipulation of DNSSEC by US government possible? 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, 31 Jul 2014 18:22:15 -0000 > An attacker (Mallory) with access to the trust anchor keys runs a > man-in-the-middle attack on sender and recipient. He forges the > OPENPGPKEY RRs, the ZSK-RRs and KSK-RRs of the sender and recipient > domains and the TLDs but uses the current origin keys of the trust > anchor to sign the forged DNSSEC RRs. > ... > It seems DNSSEC/DANE helps against most hackers and attackers but cannot > protect from attackers which have access to both the trust anchor keys > and routing infrastructure. > > Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver > software? Yes, not only can anyone distribute the public keys of the TLDs, but each TLD public key is readily accessible at any time from anywhere on the Internet, by sending a single DNS request to any of the root servers. This is one of the improvements that DNSSEC made, over the prior art of public key infrastructure. So, not only can resolver software come with a set of TLD keys, but that software can also compare the built-in set of keys with the set currently published online. (And if Mallory has MITM'd Alice, she will see discrepancies, unless Mallory has also obtained the private zone signing key of the TLD that Alice is accessing.) This comparison can be done when the newly installed OS first boots and joins the Internet. It can be done every time the OS boots. It can be done every time a TLD's key is used in a given day. It can be done by comparing keys obtained last month or last year, to keys obtained now. It can be done by comparing today's keys to keys provided by one or several other servers that you personally trust (e.g. a home machine, or one run by your company), over a connection secured by crypto known only to you. You can make the detection software arbitrarily complex, which will make Mallory's job arbitrarily complex. It's all "a simple matter of software". The challenge is that TLDs are *intended* to roll over their keys, so there will always be some discrepancies between keys frozen in a resolver software package from a few months or years ago, versus the keys used on the live Internet. That's why we have root keys: to authenticate the changes in the TLD keys. So if the root says, "This new TLD key is valid", yet it doesn't match the local database, is it an attack, or a key rollover? What does the software do? What does the user do? Making the software pop up a warning box at that point -- or, more stringently, fail to connect to the intended destination, as ssh does -- will likely cause Alice to bypass the warning or to accept the key update. "Get out of my way, stupid software!" Her other option is to decline to connect, until she can find out what's going on via some other means -- but ordinary Alices won't do that. Google Chrome's "key pinning" prints a big ugly message that encourages the user to report the message to Google tech support. But that only works the first few times -- then Mallory learns that he must not only forge the keys, but also prevent access to Google tech support (or worse -- Mallory pretends to *be* Google tech support, accepts the report, and responds with soothing reassurances that all is well). So, there are ways to detect key rollover / key compromise. But unless you think of something useful to do at that point, there is little reason to do that work. As with much of crypto / computer security, it is far easier to detect and repel mass surveillance than it is to detect and repel tightly targeted surveillance. And luckily, this is also in line with most people's social goals (disallow suspicionless mass surveillance, but allow targeted surveillance with responsible, e.g. independent judicial, oversight). So my suggestion is that if these mechanisms are built, they should focus on detecting mass surveillance and reporting that to the public. Such as IETF's Certificate Transparency work: http://www.certificate-transparency.org/ or EFF's Decentralized SSL Observatory: https://www.eff.org/observatory https://www.eff.org/press/releases/new-https-everywhere-version-warns-users-about-web-security-holes John From nobody Thu Jul 31 11:29:16 2014 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 080441A0303 for ; Thu, 31 Jul 2014 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 pYB3lC--J5Hr for ; Thu, 31 Jul 2014 11:29:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E701A011D for ; Thu, 31 Jul 2014 11:29:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 757D880048; Thu, 31 Jul 2014 14:29:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406831352; bh=172GAWCyw/kGQr952dSM+6MbtfaSPGs8ErumKS4aalc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XhMVPn8QJCX80RFav5zAP9Zp2SMkY3L8C0YUuz7E4zi3LLr3nFwbot4rDg1OELtx9 SClvjc/cZ2fWg9mR26KQyNf+S9PYpqShVY66pVM69gl452qqVlmQfVeelJsYqJeLdF IzXOHlqmCA1decE0ia5DC7OjOsW9P4PipGvvyYj8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6VITBWN001752; Thu, 31 Jul 2014 14:29:11 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 31 Jul 2014 14:29:11 -0400 (EDT) From: Paul Wouters To: John Gilmore In-Reply-To: <201407311822.s6VIM2lO024077@new.toad.com> Message-ID: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> <201407311822.s6VIM2lO024077@new.toad.com> 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: http://mailarchive.ietf.org/arch/msg/dane/LVLGdquoJ0Q0AWpekMzIvVnPCqg Cc: dane@ietf.org Subject: Re: [dane] Manipulation of DNSSEC by US government possible? 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, 31 Jul 2014 18:29:15 -0000 On Thu, 31 Jul 2014, John Gilmore wrote: > The challenge is that TLDs are *intended* to roll over their keys, > so there will always be some discrepancies between keys frozen in > a resolver software package from a few months or years ago, versus > the keys used on the live Internet. That's why we have root keys: > to authenticate the changes in the TLD keys. > > So if the root says, "This new TLD key is valid", yet it doesn't match > the local database, is it an attack, or a key rollover? What does the > software do? What does the user do? > > So, there are ways to detect key rollover / key compromise. But > unless you think of something useful to do at that point, there is > little reason to do that work. That's what transaparancy for DNSSEC is about that is being discussed in the trans working group now. It's stil in the preliminairy stages, and likely will take a back seat to the more urgent certificate transparency which needs an audit log much more than DNSSEC. Paul From nobody Thu Jul 31 12:29:22 2014 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 2BF291A0058 for ; Thu, 31 Jul 2014 12:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 aIREcT4XiIDc for ; Thu, 31 Jul 2014 12:29:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A271A0086 for ; Thu, 31 Jul 2014 12:29:11 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51476) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCw2G-000Dym-Ov for dane@ietf.org; Thu, 31 Jul 2014 15:29:08 -0400 Message-ID: <53DA9904.1040909@bbn.com> Date: Thu, 31 Jul 2014 15:29:08 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dane@ietf.org References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> <201407311822.s6VIM2lO024077@new.toad.com> In-Reply-To: <201407311822.s6VIM2lO024077@new.toad.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1weQfJZ9o4NkAu4QpoFTMZxrTWA Subject: Re: [dane] Manipulation of DNSSEC by US government possible? 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, 31 Jul 2014 19:29:19 -0000 John, > ... > Yes, not only can anyone distribute the public keys of the TLDs, but > each TLD public key is readily accessible at any time from anywhere on > the Internet, by sending a single DNS request to any of the root servers. > This is one of the improvements that DNSSEC made, over the prior art > of public key infrastructure. If generic PKIs could assume a single TA, then the same model has always been possible. DNS has the advantage of having a single root, and a robust infrastructure supporting distribution of data about the next tier of the DNS. This allows DNSSEC to offer the functionality you describe. it is not an improvement over the prior art of PKI. Steve From nobody Thu Jul 31 12:44:20 2014 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 0FF581A0022; Thu, 31 Jul 2014 12:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 04mvR3Fe0im3; Thu, 31 Jul 2014 12:44:17 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA591A000F; Thu, 31 Jul 2014 12:44:17 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 4D191202022; Thu, 31 Jul 2014 12:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5C9t/rgKGTb+7nczZeVE izRymwg=; b=aNrAXw5HtA9kWs49d1iO2YkOfd+1s6T0nepxIm4iFdmK6LdsMA9k ///3Lzy0rIi2ZVgUsqhtG+pl7sKiey61Rl52YyWFGva+lgUQsHakn9Hq9DehiWx+ tQWyBTaXFG0fghzsHoESXnCc8DW4EjlSBZMATlKrqXL/4tLM74ogZD4= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9B9BE202018; Thu, 31 Jul 2014 12:44:16 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so176349wiv.7 for ; Thu, 31 Jul 2014 12:44:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr950032wik.70.1406835855246; Thu, 31 Jul 2014 12:44:15 -0700 (PDT) Received: by 10.217.98.6 with HTTP; Thu, 31 Jul 2014 12:44:15 -0700 (PDT) In-Reply-To: References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de> <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de> <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> <201407311822.s6VIM2lO024077@new.toad.com> Date: Thu, 31 Jul 2014 14:44:15 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eMPpzLoxpP7Ikg08VVWcvlvPVYc Cc: "trans@ietf.org" , dane@ietf.org Subject: Re: [dane] Manipulation of DNSSEC by US government possible? 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, 31 Jul 2014 19:44:19 -0000 On Thu, Jul 31, 2014 at 1:29 PM, Paul Wouters wrote: > That's what transaparancy for DNSSEC is about that is being discussed in > the trans working group now. It's stil in the preliminairy stages, and > likely will take a back seat to the more urgent certificate transparency > which needs an audit log much more than DNSSEC. And which is a good chance to remind everyone that this topic is off-topic here. This should be discussed there [trans]. Nico --