From nobody Sat Aug 2 11:13: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 A2FB11B2824; Sat, 2 Aug 2014 11:13:24 -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 SgNwKTyFf2yI; Sat, 2 Aug 2014 11:13:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2D1B2827; Sat, 2 Aug 2014 11:13:18 -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.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140802181318.11208.51660.idtracker@ietfa.amsl.com> Date: Sat, 02 Aug 2014 11:13:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SMAO96ohk498cxVdmLvMz8PT4cg Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-11.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 18:13:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-11.txt Pages : 35 Date : 2014-08-02 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 2 11:40:02 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 8FF741B287D for ; Sat, 2 Aug 2014 11:40:00 -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 Yjlyvd6H94hT for ; Sat, 2 Aug 2014 11:39: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 8EDF91B2872 for ; Sat, 2 Aug 2014 11:39:58 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D6FDF2AB0A8; Sat, 2 Aug 2014 18:39:56 +0000 (UTC) Date: Sat, 2 Aug 2014 18:39:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140802183956.GD15044@mournblade.imrryr.org> References: <20140802181318.11208.51660.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140802181318.11208.51660.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6PqoWKF2ugntTw86Nr8_huB6arw Subject: [dane] SMTP draft, please review, especially digest agility! 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, 02 Aug 2014 18:40:00 -0000 On Sat, Aug 02, 2014 at 11:13:18AM -0700, internet-drafts@ietf.org wrote: > Filename : draft-ietf-dane-smtp-with-dane-11.txt > Pages : 35 > Date : 2014-08-02 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-11 Modulo one typo introduced in this update, that will be fixed in the final version: diff --git a/draft-ietf-dane-smtp-with-dane b/draft-ietf-dane-smtp-with-dane index f230f01..481ce4f 100644 --- a/draft-ietf-dane-smtp-with-dane +++ b/draft-ietf-dane-smtp-with-dane @@ -489 +489 @@ available, and authentication using the data is impossible. In -what follows, the term "insecure" will also includes the case of +what follows, the term "insecure" will also include the case of I believe the document is almost ready for publication, if you've not read a recent complete version of the document, please review this version in full. The key issue on which the WG may has not yet reached rough consensus is digest agility. This is now also specified in the latest revisions of the OPs draft: http://tools.ietf.org/html/draft-ietf-dane-ops-05#section-8 http://tools.ietf.org/html/draft-ietf-dane-ops-05#section-7 Therefore we need to collectively decide whether digest agility as specified in either document can move forward, and whether the SMTP draft should contain such a specification by value or by reference to the OPs draft. Perhaps it is a problem to reference normative material from the OPS draft which is currently stated to be reviewed and published later than the SMTP draft? Should we then drop agility from the SMTP draft, and address it only in the OPS draft? If agility (as specified) is to be required, I want other SMTP implementors to know about it as soon as possible. Other than agility, I am hoping to now shift my focus primarily to the OPS draft. A question for the chairs is whether we still want to stick to coordinated publication of the SMTP and SRV docuements, given that the former is largely done, and the latter still requires work, which may not happen for some time. -- Viktor. From nobody Wed Aug 6 07:48: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 5A33F1B2C30 for ; Wed, 6 Aug 2014 07:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 fhDTvl6_rVnG for ; Wed, 6 Aug 2014 07:48:30 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4862E1B27EF for ; Wed, 6 Aug 2014 07:48:30 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 6 Aug 2014 10:48:39 -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; Wed, 6 Aug 2014 10:48:26 -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 s76EmDxY025763 for ; Wed, 6 Aug 2014 10:48:22 -0400 Message-ID: <53E2402E.40004@nist.gov> Date: Wed, 6 Aug 2014 10:48:14 -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: 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/qpkZcRjJUuxG-1eQQes6K0KcI6Y Subject: [dane] 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, 06 Aug 2014 14:48:33 -0000 We now have a DANE OpenPGP tester up and running in the HAD-Pilot project at NIST. Test descriptions are at https://www.had-pilot.com/openpgp/. The test target is tester@openpgp.had-pilot.biz. The website describes tests for signing, encrypting, authenticating and decrypting, and the associated DNS lookups for your user@domain and our tester@openpgp.had-pilot.biz. If you provision your user, and do DNS lookups for our tester, you should get correct responses for all 7 tests. Without provisioning your user and domain in the DNS, you can meaningfully run the tests: - openpgp ping - returns a 'tester alive' message, - openpgp signed - returns 'NXDOMAIN', - openpgp request sign - returns a signed message for which you don't have the public key. We are trying to get some early users for the system, and wring it out as needed. Error behaviour tests will follow, sometime. Cheers, Stephen Nightingale. From nobody Wed Aug 6 08:57:12 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 B8AEA1A0114 for ; Wed, 6 Aug 2014 08:57:09 -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_HELO_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 UR-W8K2BVWUB for ; Wed, 6 Aug 2014 08:57:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAF01A00B8 for ; Wed, 6 Aug 2014 08:57:02 -0700 (PDT) Received: from BLUPR09MB117.namprd09.prod.outlook.com (10.255.213.14) by BLUPR09MB120.namprd09.prod.outlook.com (10.255.213.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 15:57:01 +0000 Received: from BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) by BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) with mapi id 15.00.0995.014; Wed, 6 Aug 2014 15:57:00 +0000 From: "Rose, Scott" To: "dane@ietf.org list" Thread-Topic: [dane] draft-wouters-dane-openpgp-02 Thread-Index: AQHPsYWHX2U/Mh+7zEeHuZRDse5+G5vDuxCA Date: Wed, 6 Aug 2014 15:56:59 +0000 Message-ID: References: <53E2402E.40004@nist.gov> In-Reply-To: <53E2402E.40004@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.6] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(377454003)(24454002)(51704005)(36756003)(105586002)(106356001)(92726001)(106116001)(4396001)(80022001)(64706001)(31966008)(20776003)(66066001)(74662001)(83716003)(76176999)(74502001)(86362001)(107886001)(95666004)(107046002)(50986999)(54356999)(81542001)(99396002)(81342001)(76482001)(87936001)(15202345003)(85306004)(82746002)(79102001)(77982001)(2656002)(15975445006)(83072002)(110136001)(99286002)(85852003)(92566001)(21056001)(83322001)(33656002)(19580405001)(46102001)(101416001)(19580395003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB120; H:BLUPR09MB117.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <8EEF48A7246ACD439740A4F26DD3F310@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WqoE0ZmYZ2OBsJTpPYYrTd_F4As Subject: Re: [dane] 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, 06 Aug 2014 15:57:09 -0000 Also, the test tool uses 65280 as the RRType code for the OPENPGPKEY RR. O= nce it is assigned an IANA registration number, we'll change it. Scott On Aug 6, 2014, at 10:48 AM, Stephen Nightingale wrote: >=20 >=20 > We now have a DANE OpenPGP tester up and running in the HAD-Pilot > project at NIST. Test descriptions are at > https://www.had-pilot.com/openpgp/. The test target is > tester@openpgp.had-pilot.biz. The website describes tests for signing, > encrypting, authenticating and decrypting, and the associated DNS > lookups for your user@domain and our tester@openpgp.had-pilot.biz. >=20 > If you provision your user, and do DNS lookups for our tester, you > should get correct responses for all 7 tests. >=20 > Without provisioning your user and domain in the DNS, you can > meaningfully run the tests: > - openpgp ping - returns a 'tester alive' message, > - openpgp signed - returns 'NXDOMAIN', > - openpgp request sign - returns a signed message for which you > don't have the public key. >=20 > We are trying to get some early users for the system, and wring it out > as needed. Error behaviour tests will follow, sometime. >=20 > Cheers, >=20 > Stephen Nightingale. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Fri Aug 8 06:42:44 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 B274E1B2997 for ; Fri, 8 Aug 2014 06:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-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 xoko2Z86S6ON for ; Fri, 8 Aug 2014 06:42:40 -0700 (PDT) Received: from mx.karotte.org (mx.karotte.org [IPv6:2a01:4f8:150:7142::25]) (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 697CC1B28D0 for ; Fri, 8 Aug 2014 06:42:40 -0700 (PDT) Received: from danton.fire-world.de (danton.fire-world.de [IPv6:2001:4dd0:f8dd::120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.karotte.org (Postfix) with ESMTPSA id 3hV76c1VWszCr0Z for ; Fri, 8 Aug 2014 15:42:32 +0200 (CEST) X-DKIM: OpenDKIM Filter v2.6.8 mx.karotte.org 3hV76c1VWszCr0Z DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=karotte.org; s=snowcrash; t=1407505352; bh=mSnfv/T0DTo9g28wQD9AjhF2i2ERmWydY4eZebW11rM=; h=Date:From:To:Subject; b=CSEurSj16zCQEJ4kOr6O3Hs/9AE4NvFACEUlBki4N8R295Oto9TIq0ILyX8bYOz15 vrGJ13SeoSfXrD5bXOQAqosPOgpHptfYyTJr9gTP0ARV1hEXErltIgmq+DwkxPtq3h SG7CP/mqJFpXeFSRB8BbQndxhz1Y/rjUIanbEF9s= Received: from danton.fire-world.de (fire@localhost [127.0.0.1]) by danton.fire-world.de (8.14.4/8.14.4/Debian-4) with ESMTP id s78DgYRp022455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 8 Aug 2014 15:42:34 +0200 Received: (from fire@localhost) by danton.fire-world.de (8.14.4/8.14.4/Submit) id s78DgXGN022454 for dane@ietf.org; Fri, 8 Aug 2014 15:42:33 +0200 Date: Fri, 8 Aug 2014 15:42:33 +0200 From: Sebastian Wiesinger To: IETF DANE Mailinglist Message-ID: <20140808134233.GA20325@danton.fire-world.de> Mail-Followup-To: IETF DANE Mailinglist MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Xx50HCSIKOCo552ZzS6nTRRC-eo Subject: [dane] Client tool to check DANE records (for monitoring) 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, 08 Aug 2014 13:42:42 -0000 Hello, I'm having trouble finding a tool that I can integrate into a monitoring solution that will check if the DANE record and certificate for a service match. Google did not show any when searching, except perhaps for swede (that has some issues too). Is there anything else that I can for example plug into Nagios? Thanks & Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From nobody Fri Aug 8 07:20:47 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 23CA91B2C25 for ; Fri, 8 Aug 2014 07:20:45 -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 gzA4TlakYXJA for ; Fri, 8 Aug 2014 07:20:43 -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 7973D1B2C22 for ; Fri, 8 Aug 2014 07:20:42 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E280680048; Fri, 8 Aug 2014 10:20:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407507641; bh=JHnxR53kMGeBpFuLK0ee6mka55efXsrme+vCtF72ZnU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PG5QCT4cKd/PRn6UDsk+x0E1t/LSq1JFRxCothfXXtrt4H6++pg5K/a9FSeBD1fay V51a0fkpVOn4mY9g7umbk95uR9D8etAOa4msEJ/xdkxgjBmcP7XfUB1eT0y8N4z9yb SqOIu1P/h10g/0AhELh57nIwZFbFEyjfj3FjdaLY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s78EKd2o000944; Fri, 8 Aug 2014 10:20:40 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 8 Aug 2014 10:20:39 -0400 (EDT) From: Paul Wouters To: Sebastian Wiesinger In-Reply-To: <20140808134233.GA20325@danton.fire-world.de> Message-ID: References: <20140808134233.GA20325@danton.fire-world.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/89yCnMfl011H0KOkAZ5G0GFWlvk Cc: IETF DANE Mailinglist Subject: Re: [dane] Client tool to check DANE records (for monitoring) 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, 08 Aug 2014 14:20:45 -0000 On Fri, 8 Aug 2014, Sebastian Wiesinger wrote: > I'm having trouble finding a tool that I can integrate into a > monitoring solution that will check if the DANE record and certificate > for a service match. Google did not show any when searching, except > perhaps for swede (that has some issues too). Is there anything else > that I can for example plug into Nagios? swede got pulled into hash-slinger as dane. The tool still has some known bugs, and does not support protocols with STARTTLS. http://people.redhat.com/pwouters/hash-slinger/ Paul From nobody Fri Aug 8 07:42:58 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 AB1AC1B2ACA for ; Fri, 8 Aug 2014 07:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] 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 AcFzlwxDlASi for ; Fri, 8 Aug 2014 07:42:55 -0700 (PDT) Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1F71B2A54 for ; Fri, 8 Aug 2014 07:42:54 -0700 (PDT) Received: from mailout.strotmann.de (b9168e1b.cgn.dg-w.de [185.22.142.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by csgate3.strotmann.de (Postfix) with ESMTPSA id C279850EE; Fri, 8 Aug 2014 16:42:47 +0200 (CEST) Received: by mailout.strotmann.de (Postfix, from userid 1001) id B032FB63B; Fri, 8 Aug 2014 16:42:51 +0200 (CEST) From: Carsten Strotmann To: "Sebastian Wiesinger" References: <20140808134233.GA20325@danton.fire-world.de> User-agent: mu4e 0.9.9.5; emacs 24.3.1 In-reply-to: <20140808134233.GA20325@danton.fire-world.de> Date: Fri, 08 Aug 2014 16:42:51 +0200 Message-ID: <86fvh7m49g.fsf@strotmann.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kcfQCFHs58ZmLUGlRwMZAJMqtVk Cc: IETF DANE Mailinglist Subject: Re: [dane] Client tool to check DANE records (for monitoring) 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, 08 Aug 2014 14:42:56 -0000 Hello Sebastian, Sebastian Wiesinger writes: > Hello, > > I'm having trouble finding a tool that I can integrate into a > monitoring solution that will check if the DANE record and certificate > for a service match. Google did not show any when searching, except > perhaps for swede (that has some issues too). Is there anything else > that I can for example plug into Nagios? > > Thanks & Regards > > Sebastian ldns-dane from the (recent version of the) ldns tool (by NLnetLabs): % ldns-dane verify strotmann.de 443 91.190.147.212 dane-validated successfully 2001:470:1f08:f1d::2 dane-validated successfully -- Carsten Strotmann Email: cas@strotmann.de Blog: strotmann.de From nobody Fri Aug 8 08:30: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 6D5621B2B82 for ; Fri, 8 Aug 2014 08:30:38 -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 ZaGrR-pPwKoc for ; Fri, 8 Aug 2014 08:30:28 -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 AF8FB1B2BA9 for ; Fri, 8 Aug 2014 08:30:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9DE7A2AB29E; Fri, 8 Aug 2014 15:30:26 +0000 (UTC) Date: Fri, 8 Aug 2014 15:30:26 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140808153026.GW14392@mournblade.imrryr.org> References: <20140808134233.GA20325@danton.fire-world.de> <86fvh7m49g.fsf@strotmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86fvh7m49g.fsf@strotmann.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/emdswaRh0YlGu8T5p4TCdh1qvZE Subject: Re: [dane] Client tool to check DANE records (for monitoring) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 15:30:38 -0000 On Fri, Aug 08, 2014 at 04:42:51PM +0200, Carsten Strotmann wrote: > ldns-dane from the (recent version of the) ldns tool (by NLnetLabs): > > % ldns-dane verify strotmann.de 443 > 91.190.147.212 dane-validated successfully > 2001:470:1f08:f1d::2 dane-validated successfully For SMTP, the Postfix source distribution as of 2.11 or later, includes posttls-finger: http://www.postfix.org/posttls-finger.1.html Concise: $ posttls-finger -c -L summary strotmann.de posttls-finger: Verified TLS connection established to mail.strotmann.de[91.190.147.212]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) More verbose: $ posttls-finger strotmann.de posttls-finger: using DANE RR: _25._tcp.mail.strotmann.de IN TLSA 3 0 1 2C:DD:A7:3A:FD:1D:6D:82:C7:E9:EB:8F:D4:37:C4:88:62:73:E5:2F:9A:E3:0A:BC:16:89:93:9C:5F:52:20:91 posttls-finger: using DANE RR: _25._tcp.mail.strotmann.de IN TLSA 3 0 1 DD:8B:57:EE:38:AF:6C:7E:70:DA:A4:1D:A8:0A:6A:17:1D:82:18:58:48:AA:7C:7A:A8:9D:31:97:BF:11:D9:0F posttls-finger: Connected to mail.strotmann.de[91.190.147.212]:25 posttls-finger: < 220 csgate3.strotmann.de ESMTP Postfix posttls-finger: > EHLO amnesiac.example posttls-finger: < 250-csgate3.strotmann.de posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 50000000 posttls-finger: < 250-VRFY posttls-finger: < 250-ETRN posttls-finger: < 250-STARTTLS posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-AUTH=PLAIN LOGIN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: mail.strotmann.de[91.190.147.212]:25: depth=0 matched end entity certificate sha256 digest 2C:DD:A7:3A:FD:1D:6D:82:C7:E9:EB:8F:D4:37:C4:88:62:73:E5:2F:9A:E3:0A:BC:16:89:93:9C:5F:52:20:91 posttls-finger: mail.strotmann.de[91.190.147.212]:25: Matched subjectAltName: mail.strotmann.de posttls-finger: mail.strotmann.de[91.190.147.212]:25: subjectAltName: imap.strotmann.de posttls-finger: mail.strotmann.de[91.190.147.212]:25: subjectAltName: smtp.strotmann.de posttls-finger: mail.strotmann.de[91.190.147.212]:25 CommonName mail.strotmann.de posttls-finger: mail.strotmann.de[91.190.147.212]:25: subject_CN=mail.strotmann.de, issuer_CN=CA Cert Signing Authority, fingerprint=B0:2C:D6:53:A4:CD:5A:85:EE:12:BB:4E:E7:36:4F:6E:D6:5A:29:E9, pkey_fingerprint=BF:AE:74:62:57:F2:F0:D8:CD:40:3E:3C:D9:64:13:40:B7:8D:C6:2F posttls-finger: Verified TLS connection established to mail.strotmann.de[91.190.147.212]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) posttls-finger: > EHLO amnesiac.example posttls-finger: < 250-csgate3.strotmann.de posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 50000000 posttls-finger: < 250-VRFY posttls-finger: < 250-ETRN posttls-finger: < 250-AUTH PLAIN LOGIN posttls-finger: < 250-AUTH=PLAIN LOGIN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye -- Viktor. From nobody Fri Aug 8 15:25:21 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 688AD1A0107 for ; Fri, 8 Aug 2014 15:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 tpn9DpkoQPkP for ; Fri, 8 Aug 2014 15:25:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020381A00C9 for ; Fri, 8 Aug 2014 15:25:15 -0700 (PDT) Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB244.namprd06.prod.outlook.com (10.242.191.153) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Fri, 8 Aug 2014 22:25:11 +0000 Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.5]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.5]) with mapi id 15.00.1005.008; Fri, 8 Aug 2014 22:25:11 +0000 From: Dan York To: IETF DANE Mailinglist Thread-Topic: DANE proposals related to email usage? Fwd: Call for Participation -- ICANN DNSSEC Workshop 15 October 2014 Thread-Index: AQHPs1ee3cZnwzkCT0GLg/gr9VK81g== Date: Fri, 8 Aug 2014 22:25:11 +0000 Message-ID: <63BBEF3B-0FA5-406F-9568-DD2C6811A831@isoc.org> References: <4A0DCE36-C0D8-4EBB-8950-519A57650867@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2604:6000:9fc0:53:801e:5527:2cfe:8df6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009004)(164054003)(2473001)(199002)(189002)(377454003)(33656002)(561944003)(36756003)(79102001)(21056001)(85852003)(83072002)(4396001)(95666004)(107046002)(107886001)(105586002)(106116001)(99286002)(106356001)(76482001)(83322001)(46102001)(19580405001)(19580395003)(101416001)(229853001)(16236675004)(80022001)(31966008)(74662001)(74502001)(77096002)(15202345003)(99396002)(64706001)(20776003)(2656002)(77982001)(82746002)(87936001)(15975445006)(92566001)(92726001)(86362001)(85306004)(81542001)(19617315012)(110136001)(54356999)(50986999)(83716003)(81342001)(76176999)(104396001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB244; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_63BBEF3B0FA5406F9568DD2C6811A831isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yEMEckigRmi9snsGjVyqQwxHFhw Subject: [dane] DANE proposals related to email usage? Fwd: Call for Participation -- ICANN DNSSEC Workshop 15 October 2014 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, 08 Aug 2014 22:25:20 -0000 --_000_63BBEF3B0FA5406F9568DD2C6811A831isocorg_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable DANE WG members, I don't usually send call for presentations to WG mailing lists, but in thi= s case we are looking to highlight some of the recent activity happening ar= ound DANE - and specifically around DANE and email - and I figured people h= ere might be the right people or would know people (and I did check with Wa= rren and Olafur first!). If any of you will be going to ICANN 51 in L.A. in October, or know of peop= le who will be going (or are in the area and can get there), we're working = to put together a panel that can talk about DANE and SMTP. Wes Hardaker ha= s already agreed to participate based on the work he and Viktor have been d= oing with posttix and I'd really like to find some other folks who might be= a good fit. (Wes gave me some names, too.) The broad description is: ----------------------- 2. DANE / DNSSEC as a way to secure email The DNS-based Authentication of Named Entities (DANE) protocol is an exciti= ng development where DNSSEC can be used to provide a strong additional trus= t layer for traditional SSL/TLS certificates. We are both pleased and intri= gued by the growing usage of DANE and DNSSEC as a means of providing added = security for email. Multiple email servers have added support for DANE reco= rds to secure TLS/SSL connections. Some email providers are marketing DNSSE= C/DANE support. We would like to have a panel at ICANN 51 focusing on this = particular usage of DANE. Are you a developer of an email server or client = supporting DANE? Do you provide DANE / DNSSEC support in your email servic= e? Can you provide a brief case study of what you have done to implement DA= NE / DNSSEC? Can you talk about any lessons you learned in the process? ------------------------- We are also open to any other ideas around DANE usage (and demos, too) beyo= nd email. I'd personally like to promote DANE as much as possible so I wel= come any proposals. (The full call for participation is included below - b= ut we're also open to proposals on *any* DANE/DNSSEC topic.) If you will be at ICANN 51 (or could get there), or know someone who will b= e, please just send a 1-2 sentence proposal for what you would like to talk= about to: dnssec-losangeles@isoc.org = and that will reach the full Program Committee. As I'm about to head out= on 2 weeks of vacation, sending email messages directly to me won't really= help either you or me! :-) Thanks, Dan Begin forwarded message: From: Julie Hedlund > Subject: [dns-operations] REMINDER Re: Call for Participation -- ICANN DNSS= EC Workshop 15 October 2014 Date: August 5, 2014 10:37:06 AM EDT To: "dns-operations@lists.dns-oarc.net" > Call for Participation -- ICANN DNSSEC Workshop 15 October 2014 The DNSSEC Deployment Initiative and the Internet Society Deploy360 Program= me, in cooperation with the ICANN Security and Stability Advisory Committee= (SSAC), are planning a DNSSEC Workshop at the ICANN 51 meeting in Los Ange= les, California, on 15 October 2014. The DNSSEC Workshop has been a part o= f ICANN meetings for several years and has provided a forum for both experi= enced and new people to meet, present and discuss current and future DNSSEC= deployments. For reference, the most recent session was held at the ICANN= meeting in London on 25 June 2014. The presentations and transcripts are a= vailable at: http://london50.icann.org/en/schedule/wed-dnssec. We are seeking presentations on the following topics; 1. DNSSEC activities in the North America region For this panel we are seeking participation from those who have been involv= ed in DNSSEC deployment in the North America region and also from those who= have not deployed DNSSEC but who have a keen interest in the challenges an= d benefits of deployment. In particular, we will consider the following qu= estions: What can DNSSEC do for you? What doesn't it do? What are the int= ernal tradeoffs to implementing DNSSEC? What did you learn in your deployme= nt of DNSSEC? We are interested in presentations from both people involved= with the signing of domains and people involved with the deployment of DNS= SEC-validating DNS resolvers. 2. DANE / DNSSEC as a way to secure email The DNS-based Authentication of Named Entities (DANE) protocol is an exciti= ng development where DNSSEC can be used to provide a strong additional trus= t layer for traditional SSL/TLS certificates. We are both pleased and intri= gued by the growing usage of DANE and DNSSEC as a means of providing added = security for email. Multiple email servers have added support for DANE reco= rds to secure TLS/SSL connections. Some email providers are marketing DNSSE= C/DANE support. We would like to have a panel at ICANN 51 focusing on this = particular usage of DANE. Are you a developer of an email server or client = supporting DANE? Do you provide DANE / DNSSEC support in your email servic= e? Can you provide a brief case study of what you have done to implement DA= NE / DNSSEC? Can you talk about any lessons you learned in the process? 3. Potential impacts of Root Key Rollover Given many concerns about the need to do a Root Key Rollover, we would like= to bring together a panel of people who can talk about what the potential = impacts may be to ISPs, equipment providers and end users, and also what ca= n be done to potentially mitigate those issues. In particular, we are seeki= ng participation from vendors, ISPs, and the community that will be affecte= d by distribution of new root keys. We would like to be able to offer sugg= estions out of this panel to the wider technical community. If you have a = specific concern about the Root Key Rollover, or believe you have a method = or solution to help address impacts, we would like to hear from you. 4. New gTLD registries and administrators implementing DNSSEC With the launch of the new gTLDs, we are interested in hearing from registr= ies and operators of new gTLDs about what systems and processes they have i= mplemented to support DNSSEC. As more gTLDs are launched, is there DNSSEC-= related information that can be shared to help those launches go easier? 5. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registr= ars, and ISPs, what have we learned about how we manage DNSSEC? What is the= best practice around key rollovers? How often do you review your disaster = recovery procedures? Is there operational familiarity within your customer = support teams? What operational statistics have we gathered about DNSSEC? A= re there experiences being documented in the form of best practices, or som= ething similar, for transfer of signed zones? 6. DNSSEC automation For DNSSEC to reach massive deployment levels it is clear that a higher lev= el of automation is required than is currently available. Topics for which = we would like to see presentations include: * What tools, systems and services are available to help automate DNSSEC ke= y management? * Can you provide an analysis of current tools/services and identify gaps? * Where are the best opportunities for automation within DNSSEC signing and= validation processes? * What are the costs and benefits of different approaches to automation? 7. When unexpected DNSSEC events occur What have we learned from some of the operational outages that we have seen= over the past 18 months? Are there lessons that we can pass on to those ju= st about to implement DNSSEC? How do you manage dissemination of informatio= n about the outage? What have you learned about communications planning? Do= you have a route to ISPs and registrars? How do you liaise with your CERT = community? 8. DANE and DNSSEC applications There is strong interest for DANE usage within web transactions as well as = for securing email and Voice-over-IP (VoIP). We are seeking presentations o= n topics such as: * What are some of the new and innovative uses of DANE and other DNSSEC app= lications in new areas or industries? * What tools and services are now available that can support DANE usage? * How soon could DANE and other DNSSEC applications become a deployable rea= lity? * How can the industry use DANE and other DNSSEC applications as a mechanis= m for creating a more secure Internet? We would be particularly interested in any live demonstrations of DNSSEC / = DANE applications and services. For example, a demonstration of the actual= process of setting up a site with a certificate stored in a TLSA record th= at correctly validates would be welcome. Demonstrations of new tools that = make the setup of DNSSEC or DANE more automated would also be welcome. 9. DNSSEC and DANE in the enterprise Enterprises can play a critical role in both providing DNSSEC validation to= their internal networks and also through signing of the domains owned by t= he enterprise. We are seeking presentations from enterprises that have impl= emented DNSSEC on validation and/or signing processes and can address quest= ions such as: * What are the benefits to enterprises of rolling out DNSSEC validation? An= d how do they do so? * What are the challenges to deployment for these organizations and how cou= ld DANE and other DNSSEC applications address those challenges? * How should an enterprise best prepare its IT staff and network to impleme= nt DNSSEC? * What tools and systems are available to assist enterprises in the deploym= ent of DNSSEC? * How can the DANE protocol be used within an enterprise to bring a higher = level of security to transactions using SSL/TLS certificates? 10. Guidance for Registrars in supporting DNSSEC The 2013 Registrar Accreditation Agreement (RAA) for registrars and reselle= rs requires them to support DNSSEC from January 1, 2014. We are seeking pr= esentations discussing: * What are the specific technical requirements of the RAA and how can regis= trars meet those requirements? * What tools and systems are available for registrars that include DNSSEC s= upport? * What information do registrars need to provide to resellers and ultimatel= y customers? We are particularly interested in hearing from registrars who have signed t= he 2013 RAA and have either already implemented DNSSEC support or have a pl= an for doing so. 11. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC v= alidation for the caching DNS resolvers used by their customers. We have n= ow seen massive rollouts of DNSSEC validation within large North American I= SPs and at ISPs around the world. We are interested in presentations on to= pics such as: * What does an ISP need to do to prepare its network for implementing DNSSE= C validation? * How does an ISP need to prepare its support staff and technical staff for= the rollout of DNSSEC validation? * What measurements are available about the degree of DNSSEC validation cur= rently deployed? * What tools are available to help an ISP deploy DNSSEC validation? * What are the practical server-sizing impacts of enabling DNSSEC validatio= n on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support= , etc.)? 12. APIs between the Registrars and DNS hosting operators One specific area that has been identified as needing focus is the communic= ation between registrars and DNS hosting operators, specifically when these= functions are provided by different entities. Currently, the communicatio= n, such as the transfer of a DS record, often occurs by way of the domain n= ame holder copying and pasting information from one web interface to anothe= r. How can this be automated? We would welcome presentations by either reg= istrars or DNS hosting operators who have implemented APIs for the communic= ation of DNSSEC information, or from people with ideas around how such APIs= could be constructed. 13. Hardware Security Modules (HSMs) use cases and innovation We are interested in demonstrations of HSMs, presentations of HSM-related i= nnovations and real world use cases of HSMs and key management. In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) = description of your proposed presentation to dnssec-losangeles@isoc.org by **Friday, 13 August 2014** We hope that you can join us. Thank you, Julie Hedlund On behalf of the DNSSEC Workshop Program Committee: Steve Crocker, Shinkuro Mark Elkins, DNS/ZACR Cath Goulding, Nominet UK Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, CNNIC Luciano Minuchin, NIC.AR Russ Mundy, Sparta/Parsons Ond=F8ej Sur=FD, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs --_000_63BBEF3B0FA5406F9568DD2C6811A831isocorg_ Content-Type: text/html; charset="iso-8859-2" Content-ID: <8BCFA6F7D4B8494E8E2004548CB3EEF0@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
DANE WG members,

I don't usually send call for presentations to WG mailing lists, but i= n this case we are looking to highlight some of the recent activity happeni= ng around DANE - and specifically around DANE and email - and I figured peo= ple here might be the right people or would know people (and I did check with Warren and Olafur first!). &nbs= p;

If any of you will be going to ICANN 51 in L.A. in October, or know of= people who will be going (or are in the area and can get there), we're wor= king to put together a panel that can talk about DANE and SMTP.  Wes H= ardaker has already agreed to participate based on the work he and Viktor have been doing with posttix and I'd reall= y like to find some other folks who might be a good fit.  (Wes gave me= some names, too.)  The broad description is:

-----------------------
2. DANE / DNSSEC as a way to secure email
 
The DNS-based Authentication of Named Entities (DANE) protocol is an exciti= ng development where DNSSEC can be used to provide a strong additional= trust layer for traditional SSL/TLS certificates. We are both pleased and&= nbsp;intrigued by the growing usage of DANE and DNSSEC as a means of providing added security for email. Multiple = ;email servers have added support for DANE records to secure TLS/SSL connec= tions. Some email providers are marketing DNSSEC/DANE support. We woul= d like to have a panel at ICANN 51 focusing on this particular usage of DANE. Are you a developer of an email ser= ver or client supporting DANE?  Do you provide DANE / DNSSEC support i= n your email service? Can you provide a brief case study of what you h= ave done to implement DANE / DNSSEC?  Can you talk about any lessons you learned in the process?
-------------------------

We are also open to any other ideas around DANE usage (and demos, too)= beyond email.  I'd personally like to promote DANE as much as possibl= e so I welcome any proposals.  (The full call for participation is inc= luded below - but we're also open to proposals on *any* DANE/DNSSEC topic.)

If you will be at ICANN 51 (or could get there), or know someone who w= ill be, please just send a 1-2 sentence proposal for what you would like to= talk about to:   dnssec-losangeles@isoc.org  and that will reach the full Program Committee.   As I'm about= to head out on 2 weeks of vacation, sending email messages directly to me = won't really help either you or me! :-)

Thanks,
Dan


Begin forwarded message:

Subject: [dns-= operations] REMINDER Re: Call for Participation -- ICANN DNSSEC Workshop 15= October 2014
Date: August 5, 2= 014 10:37:06 AM EDT
Call for Participat= ion -- ICANN DNSSEC Workshop 15 October 2014
 
The DNSSEC Deployme= nt Initiative and the Internet Society Deploy360 Programme, in cooperation = with the ICANN Security and Stability Advisory Committee (SSAC), are p= lanning a DNSSEC Workshop at the ICANN 51 meeting in Los Angeles, California, on 15 October 2014.  The DNSSEC = ;Workshop has been a part of ICANN meetings for several years and has = provided a forum for both experienced and new people to meet, present and&n= bsp;discuss current and future DNSSEC deployments.  For reference= , the most recent session was held at the ICANN meeting in London on 25= June 2014. The presentations and transcripts are available at: <= /span>http://london50.icann.org/en/schedul= e/wed-dnssec.  =
 
We are seeking pres= entations on the following topics;
 
1.  DNSSE= C activities in the North America region 
 
For this panel we a= re seeking participation from those who have been involved in DNSSEC d= eployment in the North America region and also from those who have not depl= oyed DNSSEC but who have a keen interest in the challenges and benefits of deployment.  In particular, we will co= nsider the following questions:  What can DNSSEC do for you? What does= n't it do?  What are the internal tradeoffs to implementing DNSSEC? Wh= at did you learn in your deployment of DNSSEC?  We are interested in presentations from both people involved with th= e signing of domains and people involved with the deployment of DNSSEC-vali= dating DNS resolvers.

 

2. DANE / DNSSEC as= a way to secure email

 

The DNS-based Authe= ntication of Named Entities (DANE) protocol is an exciting development wher= e DNSSEC can be used to provide a strong additional trust layer for traditi= onal SSL/TLS certificates. We are both pleased and intrigued by the growing usage of DANE and DNSSEC as a means o= f providing added security for email. Multiple email servers have added sup= port for DANE records to secure TLS/SSL connections. Some email providers a= re marketing DNSSEC/DANE support. We would like to have a panel at ICANN 51 focusing on this particular usag= e of DANE. Are you a developer of an email server or client supporting DANE= ?  Do you provide DANE / DNSSEC support in your email service? Can you= provide a brief case study of what you have done to implement DANE / DNSSEC?  Can you talk about any lessons= you learned in the process?

 

3.  Poten= tial impacts of Root Key Rollover
 
Given many concerns= about the need to do a Root Key Rollover, we would like to bring together = a panel of people who can talk about what the potential impacts may be to I= SPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In pa= rticular, we are seeking participation from vendors, ISPs, and the com= munity that will be affected by distribution of new root keys.  We wou= ld like to be able to offer suggestions out of this panel to the wider technical community.  If you have a specific = concern about the Root Key Rollover, or believe you have a method or soluti= on to help address impacts, we would like to hear from you.

 

4.  New gTLD r= egistries and administrators implementing DNSSEC
 
With the launch of = the new gTLDs, we are interested in hearing from registries and operators o= f new gTLDs about what systems and processes they have implemented to suppo= rt DNSSEC.  As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launc= hes go easier?
 
5. The operational = realities of running DNSSEC
 
Now that DNSSEC has= become an operational norm for many registries, registrars, and ISPs,= what have we learned about how we manage DNSSEC? What is the best pra= ctice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity w= ithin your customer support teams? What operational statistics have we=  gathered about DNSSEC? Are there experiences being documented in the = form of best practices, or something similar, for transfer of signed zones?

 

6.  DNSSEC aut= omation
 
For DNSSEC to reach= massive deployment levels it is clear that a higher level of automation is= required than is currently available. Topics for which we would like to se= e presentations include:
* What tools, syste= ms and services are available to help automate DNSSEC key management?<= /o:p>
* Can you provide a= n analysis of current tools/services and identify gaps?
* Where are the bes= t opportunities for automation within DNSSEC signing and validation process= es?
* What are the cost= s and benefits of different approaches to automation?

 

7.  When unexp= ected DNSSEC events occur
 
What have we learne= d from some of the operational outages that we have seen over the past= 18 months? Are there lessons that we can pass on to those just about = to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communic= ations planning? Do you have a route to ISPs and registrars? How do yo= u liaise with your CERT community?

 

8.  DANE and D= NSSEC applications
 
There is strong int= erest for DANE usage within web transactions as well as for securing email = and Voice-over-IP (VoIP). We are seeking presentations on topics such as:
* What are some of = the new and innovative uses of DANE and other DNSSEC applications in new ar= eas or industries?
* What tools and se= rvices are now available that can support DANE usage?
* How soon could DA= NE and other DNSSEC applications become a deployable reality?
* How can the indus= try use DANE and other DNSSEC applications as a mechanism for creating a mo= re secure Internet?

 

We would be particu= larly interested in any live demonstrations of DNSSEC / DANE applications a= nd services.  For example, a demonstration of the actual process of se= tting up a site with a certificate stored in a TLSA record that correctly validates would be welcome.  Demonstrati= ons of new tools that make the setup of DNSSEC or DANE more automated would= also be welcome.
 
9.  DNSSEC and= DANE in the enterprise
 
Enterprises can pla= y a critical role in both providing DNSSEC validation to their internal net= works and also through signing of the domains owned by the enterprise. We a= re seeking presentations from enterprises that have implemented DNSSEC on validation and/or signing processes and ca= n address questions such as:
* What are the bene= fits to enterprises of rolling out DNSSEC validation? And how do they do so= ?
* What are the chal= lenges to deployment for these organizations and how could DANE and other D= NSSEC applications address those challenges?
* How should an ent= erprise best prepare its IT staff and network to implement DNSSEC?
* What tools and sy= stems are available to assist enterprises in the deployment of DNSSEC?=
* How can the DANE = protocol be used within an enterprise to bring a higher level of security t= o transactions using SSL/TLS certificates?

 

10.  Guidance = for Registrars in supporting DNSSEC 
 
The 2013 Registrar = Accreditation Agreement (RAA) for registrars and resellers requires them to= support DNSSEC from  January 1, 2014. We are seeking presentatio= ns discussing:
* What are the spec= ific technical requirements of the RAA and how can registrars meet those re= quirements?
* What tools and sy= stems are available for registrars that include DNSSEC support?<= /font>
* What information = do registrars need to provide to resellers and ultimately custome= rs?
 
We are particularly= interested in hearing from registrars who have signed the 2013 RAA and hav= e either already implemented DNSSEC support or have a plan for doing so.&nb= sp;

 

11.  Implement= ing DNSSEC validation at Internet Service Providers (ISPs)

Internet Service Pr= oviders (ISPs) play a critical role by enabling DNSSEC validation for the c= aching DNS resolvers used by their customers.  We have now seen massiv= e rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world.  We are interested = in presentations on topics such as: 
* What does an ISP = need to do to prepare its network for implementing DNSSEC validation?  = ;
* How does an ISP n= eed to prepare its support staff and technical staff for the rollout of DNS= SEC validation?  
* What measurements= are available about the degree of DNSSEC validation currently deployed? &n= bsp;
* What tools are av= ailable to help an ISP deploy DNSSEC validation?
* What are the prac= tical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolv= ers (ex. cost, memory, CPU, bandwidth, technical support, etc.)?=
 <= /o:p>
12.  APIs betw= een the Registrars and DNS hosting operators
 
One specific area t= hat has been identified as needing focus is the communication between regis= trars and DNS hosting operators, specifically when these functions are prov= ided by different entities.  Currently, the communication, such as the transfer of a DS record, often occurs by wa= y of the domain name holder copying and pasting information from one web in= terface to another. How can this be automated?  We would welcome prese= ntations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSE= C information, or from people with ideas around how such APIs could be cons= tructed.
 <= /o:p>
13. Hardware Securi= ty Modules (HSMs) use cases and innovation
 <= /o:p>
We are interested i= n demonstrations of HSMs, presentations of HSM-related innovations and real= world use cases of HSMs and key management. 
  
In addition, we wel= come suggestions for additional topics.
 
If you are interest= ed in participating, please send a brief (1-2 sentence) description of= your proposed presentation to dnssec-lo= sangeles@isoc.org by **Friday, 13 August 2014**
 
We hope that you ca= n join us.
 
Thank you,
 
Julie Hedlund<= /o:p>
 
On behalf of the DN= SSEC Workshop Program Committee:
Steve Crocker, Shin= kuro
Mark Elkins, D= NS/ZACR
Cath Goulding, Nomi= net UK
Jean Robert Hountom= ey, AfricaCERT
Jacques Latour, .CA=
Xiaodong Lee, CNNIC=
Luciano Minuchin, N= IC.AR
Russ Mundy, Sparta/= Parsons
Ond=F8ej Sur=FD, CZ= .NIC
Yoshiro Yoneya, JPR= S
Dan York, Int= ernet Society

_______________________________________________
dns-operations mailing list
dns-operations@lists.d= ns-oarc.net
http= s://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


--_000_63BBEF3B0FA5406F9568DD2C6811A831isocorg_-- From nobody Mon Aug 11 16:02: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 498FD1A06D9 for ; Mon, 11 Aug 2014 16:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 THhAmLZptv1d for ; Mon, 11 Aug 2014 16:02:10 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E083D1A0163 for ; Mon, 11 Aug 2014 16:02:09 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so4952213wib.16 for ; Mon, 11 Aug 2014 16:02:08 -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=c9bLggXcb3VRKAD5xCkZfqOAWdJPvTQ6eKNHLmkQqDs=; b=ZFJzcJFKj6e/WOTJk/edg1AC5eKc71uF0MTnsO2vhadwGjDmJJhCf7EAJ47+DEu3Z5 kAFsANdFExxEObq90pz0iDdkRPFK48s4JhMxPn+0xUXNBuoDujTIOZ+zbGkkIz/zuN0a wq8bCgY5Kr8AXevkTvyNrumBdd0k78W0Agyzu/U+cPJ2DndqTZZoul07HoeEF9Y9XebJ cFYxWuGFHvB3L/XcTxOGQqwc0UV+9tuV3msG8yPRHk104DB1GpRZQE2TC+t4VkbyRNL+ E4Qb4QGCqOccn3WfMOcyPDvHS77KhVxP9geJ+/oX5aMg512wKLpQahsNTYrcurfh54J/ VrIA== X-Gm-Message-State: ALoCoQlIGJJSEZxwWBTxek/o43ZaXZHIcwoij/si4TmczmPWD9UkKB0pT94nHCjKFKnExMN0Z1mH MIME-Version: 1.0 X-Received: by 10.180.210.231 with SMTP id mx7mr22748151wic.42.1407798128446; Mon, 11 Aug 2014 16:02:08 -0700 (PDT) Received: by 10.194.62.39 with HTTP; Mon, 11 Aug 2014 16:02:08 -0700 (PDT) Date: Mon, 11 Aug 2014 19:02:08 -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/2QT-1LnHf2mDf-lrF3BfiDHrXv8 Subject: [dane] Draft minutes from IETF90 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, 11 Aug 2014 23:02:13 -0000 Huge thanks to Geoff for taking these. Will be posted as final minutes if there are no corrections by Friday. W ---------------------- Administrivia DANE status, (appoint scribes, blue-sheets, agenda bashing) Chairs - 5 min DANE has a new charter, and the DANE specification documents will be revised by the end of next year, according to this new charter. DANE activites in Other WGs Chairs - 5 min Dan York: Reported on a draft proposing using DANE in SIP in SIPCORE WG, also a draft on using DANE with TURN servers in the TRAM WG in the RAI area. Working group documents: 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 Awaiting final edits from the authors before conducting WG Last Call Matt Miller: Existing edits need to be sync=E2=80=99ed with co-authors, the= n submitted. Wes Hardaker: SMTP Draft functionally done. The SRV draft may want to look at the SMTP draft style for considerations and usage description. 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 Call for comments on OpenPGP and SMIME. Eric Osterweil: Concerns that the suggestions on the mailing list (Feb=E2=80=9914) concerning deployment were not pulled into the draft Paul Hoffman: Did not see enough interest in this to integrate it it, but if there is more interest if this is applicable then we will put it in. Eric O: We have implementations. What is the right way to bring this to the group to ensure that there is notice and interest? Paul H: Sure - bring it up again. Olafur G: Tasked Eric to restart this discussion on the mailing list. DANEbis and operational guidance http://tools.ietf.org/html/draft-ietf-dane-ops-05 Wes Hardaker - 30 minutes. [see presentation] Paul Wouters: When you say =E2=80=9Cnon-PKIX=E2=80=9D do you mean =E2=80=9C= non-TLS=E2=80=9D? Wes H: Right now for SMTP the only non-PKIX protocol is SMTP, but for now thats it. The protocol operators need to think about the world that they are in and their expectations and think about what types to use Paul W: But in switching you may need to run them for 10 years in parallel? Wes H: Yes Paul W: Should we think about this, and have a new usage type? Wes H: It would be great to say that this end system will only use PKIX-trust and this system will not. But how to signal this division is challenging. The protocol is that trumping one over the other. Victor D: non-PKIX means where there is not an established and used PKIX Phil HB: this is about what RPs should (or may) do. If a RP checks the DANE records are they allowed NOT to check PKIX revocation? (for example) Wes H: Why is a decision for a protocol to use DANE a deliberate decision? For these very considerations, as the protocol trust model cannot be left in an undistinguished state Olafur G: I am slightly confused. The decision of which to use (DANE or PKIX) would be left tot he protocol designers, rather than the operators Wes H: Yup. Don=E2=80=99t leave it to the operators Victor D: When clients support both then they are vulnerable to DNSSEC-only attacks. Olafur G: I thought that operators could chose to use DANE in SRV - you are saying that this is a protocol designer decision? Viktor D: The important thing to realize is that the choice of PKIX vs. DANE is a CLIENT-side choice that needs to be made. The server can publish whatever it wants, but clients need to pick which world they are in. Paul H: This WG needs to think about this to assist in the users of DANE Wes H: This sounds like future BCP material once we have some experience he= re Keith Moore: One of the issues here is mixed motives for DANE. Extend TLS into areas where the CA model has not worked well, and there are situations to use DANE where there was no CA model. These are different. You need a template that says what protocol design should specify. But this conflicts with the desire to extend existing protocols with DANE. This is messy. Dan Y: This is about best practices for a protocol to chose to use DANE or = not Paul W: as a PKIX protocol you could use DNAE as an add-on to further restrict the PKIX model. Wes H: there are tradeoffs here TLSA Raw Keys http://tools.ietf.org/html/draft-ietf-dane-rawkeys-00 Paul Wouters 20 min (slides) "Should every protocol that uses TLSA records need its own RFC?=E2=80=9D Wes: we just tried to not break things in our draft, but did not go into the semantics of when and how to use it in the TLS protocol. If you think there is just one more paragraph then great, send us the paragraph! Viktor: The draft suggests that any usage 3 works with RPK, but in fact only "3 1 X" works. Also with anything other than "3 1 0", there needs to be some way to convey the actual key (as in TLS). Paul: Yes you need to use the correct TLSA type that publishes the full public key Peter Koch: Existing protocols need this kind of specification, but are you also taking about future protocols? Paul: For a new protocol you can just use the TLSA record, and say so. Peter: you need to be explicit about the use of non-TLSA records Paul Hoffman: You don=E2=80=99t need to create a new record type with the s= ame format as TLSA then if you are going to use TLSA for a non-TLS protocol then you should describe that use, and do so in the context of the protocol description. It may not need a dedicated RFC, but it does need to be described. Viktor: My intention was to put in enough RPK semantics into the OPS draft, to make a separate draft unnecessary. Dan York: We need to minimise the number of documents that an apps developer needs to refer to to implement an app Adam ?: there are situations of interop problems with RSA key use of explicit =E2=80=9Cnull=E2=80=9D values to parameters. Jeff Hodges: +1 to Paul Hoffman and Adam. You have to write all this stuff = down. Wes: Is a document needed? Those 14,000 RFCS are all useful and valuable. [Really? :-) Your cynical minute taker!] Keith: disagrees with all the discussion item prompts. He argues in favour of explicit prohibition, against, reuse of existing RRtypes, against not requiring new specifications per protocol. Paul: DANE made these mistakes in the past, and this document tried to remove these restrictions and limitations on the usage of these types Olaf: Is this TLS of the use of TLSA? Keith: Well we are already in that zone and we can=E2=80=99t go back. Viktor: With TLS the server presents the public key to the client, provided it uses the same format on the wire as in DNS, it should just work. I've never seen any problems with 3 1 1 records with respect to SPKI encoding. And in practice all the keys are RSA. So it looks like the issue is absent in practice=E2=80=A6 (room) RFC3279: its already written down section: 2.3.1 Dan: Specification of the use of TLSA is good, but look at SIP - the glomming of PSTN goop in SIP lead to RFC5411, which is 42 pages of meta info about SIP that refers to the other RFCs. We should not reproduce this for DANE. That;=E2=80=99s what I want. Wes: Could be IANA Registry Paul: We=E2=80=99ve already lost that registry naming. Matt Miller: generic and simple. but. if folk have to write something for their protocol. then fine, but its good to think that this is generic. Phil HB: If you are going to put raw things in then it depends on the crypto - for example RSA has a lot of ancillary infer there, and if you use curve 25519 with short keys, then there is a point to this. 2048 bits of raw keys squished into a DNS would be a more comfortable fit. Adam: If you can do this for DNSSEC, then you can do this for DANE Keith: Section in a document that describes its usage in the context of DAN= E Paul W: Should the 6689 restrictions be dropped? Is there an objection to dropping these restrictions? Paul Hoffman: Well you should say when to drop and provide context: Paul W: I meant "drop the restrictions to PKIX-only" Paul Hoffman: Yes Paul W: Which document should include this dropping of restrictions Olaf: Should we think about a new RRtype for protocols that only use raw ke= ys? Wes: Didn=E2=80=99t we have a failed key-type RRtype and didn=E2=80=99t it = fail? Viktor: NO. 3 1 X is sufficient to represent keys. The SPKI selector already solves the problem. Peter Koch: Unless the protocol is clear in the beginning that it wants type =E2=80=9Cfoo=E2=80=9D Paul Hoffman: Agree with Victor - TLSA is sufficient Andrew Sullivan: Agree. on grounds of reuse of TLSA to make it simpler to u= se 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 Keith Moore: Doubts that additional security is being provided here Adam Langley: +1 Yoar Nir: Similar doubts. If you already have DNSSEC then the CNAME is enough. There is no other requirement for the TLSA record Viktor: Yes. Exactly. This proposal is fatally flawed. The design is broken. And failed to use the origin site cert for anything. Anyone can copy a cert! This is profoundly broken EV or NOT. Philip HB: Perhaps there is a need for a publication protocol to allow one to easily acquire and publish a new certificate, and thereby avoid delegation records Erik N; You need to be careful of conflating a bunch of discrete issues. There is some opportunities for opportunistic security in using DANE for TLSA records for traffic heading through a CDN. Chairs: Write an individual draft on the problem statement "Reverse DANE" i.e. can server check TLSA records for client? no draft Chairs - 10 min How can a server look up a client DANE key? Some protocols send names via handshake. Some protocols only have the addresses of the client. Can a server validate a client WG Feedback: There is the feel that this is interesting, and there are some challenges here, but it would be useful to start with some form of problem statement draft. Perhaps some use cases would help and perhaps the protocol should perform this itself? End of meeting From nobody Sat Aug 16 21:56: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 B808B1A06F5; Sat, 16 Aug 2014 21:56:37 -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 A-v0GaosvGzT; Sat, 16 Aug 2014 21:56:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8EB1A06FD; Sat, 16 Aug 2014 21:56:36 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140817045636.23232.15605.idtracker@ietfa.amsl.com> Date: Sat, 16 Aug 2014 21:56:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/q3vPMb9Y4WCNoT1GCVIjHXeKs7I Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-06.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: Sun, 17 Aug 2014 04:56:38 -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-06.txt Pages : 28 Date : 2014-08-16 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-06 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 Sun Aug 17 07:50: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 251B81A0A3C; Sun, 17 Aug 2014 07:50:18 -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 RESsdMU3h1N7; Sun, 17 Aug 2014 07:50:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C19211A0A52; Sun, 17 Aug 2014 07:50:12 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140817145012.20931.92473.idtracker@ietfa.amsl.com> Date: Sun, 17 Aug 2014 07:50:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ous8Rzmi4LntzEYborF7W_O-8Hk Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-12.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: Sun, 17 Aug 2014 14:50:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : SMTP security via opportunistic DANE TLS Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-smtp-with-dane-12.txt Pages : 33 Date : 2014-08-17 Abstract: This memo describes a downgrade-resistant protocol for SMTP transport security between Mail Transfer Agents (MTAs) based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 19 09: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 B37701A065E for ; Tue, 19 Aug 2014 09:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 PyUd-GMPpPso for ; Tue, 19 Aug 2014 09:33:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 60A421A0659 for ; Tue, 19 Aug 2014 09:33:20 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D409341196; Tue, 19 Aug 2014 10:33:18 -0600 (MDT) Message-ID: <53F37C4C.7040906@stpeter.im> Date: Tue, 19 Aug 2014 10:33:16 -0600 From: Peter Saint-Andre 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: "Olle E. Johansson" , dane@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7wMBI6w_x_wWDhBD4cYBlJikfZg 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: Tue, 19 Aug 2014 16:33:21 -0000 Hej Olle, thanks for the feedback and sorry about the slow response time. Comments inline. On 7/24/14, 2:19 AM, Olle E. Johansson wrote: > 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? > > This is a big issue and may be too big an issue for this document to > cover, especially with normative language. I agree that normative language might not be appropriate. However, the authors of this spec do think that performing the DNS queries (not, as noted, the final application connection attempts) in parallel can help to expedite things significantly. Here is some alternate wording: OLD 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]). NEW Developers of application clients that depend on DANE-SRV often would like to prepare as quickly as possible for making a connection to the intended service, thus reducing the wait time for end users. To make this possible, a DNS library might perform the queries described in the following sections in parallel, rather than waiting for one set of queries to be completed (say, all SRV queries) before performing additional queries (say, address queries and TLSA queries). > 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. Ack. > In fact the DNS SRV rfc talks > about "any address family" - now and in the future ;-) We can always replace this spec when IPv12 is deployed. :-) > 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 How is this? o Use of SRV records with additional discovery technologies, such as the use of both SRV records and NAPTR records [RFC2915] for transport selection in the Session Initiation Protocol (SIP). > That will help me in sipcore :-) We're here for you! > 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 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? I'd prefer to leave identity verification rules up to RFC 6125 or the application-specific equivalent. There's a reason why RFC 6125 ended up at 57 pages... Peter From nobody Tue Aug 19 09:41: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 3A1D51A0682 for ; Tue, 19 Aug 2014 09:41:17 -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 xASZe2voOapS for ; Tue, 19 Aug 2014 09:41:15 -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 B4DA51A0681 for ; Tue, 19 Aug 2014 09:41:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DCA722AB2A4; Tue, 19 Aug 2014 16:41:10 +0000 (UTC) Date: Tue, 19 Aug 2014 16:41:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140819164110.GF14392@mournblade.imrryr.org> References: <53F37C4C.7040906@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F37C4C.7040906@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jc0kwJL1d9hbfHvqjRNP1k6EJ8o 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: Tue, 19 Aug 2014 16:41:17 -0000 On Tue, Aug 19, 2014 at 10:33:16AM -0600, Peter Saint-Andre wrote: > >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 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? > > I'd prefer to leave identity verification rules up to RFC 6125 or the > application-specific equivalent. There's a reason why RFC 6125 ended up at > 57 pages... DANE with SRV (as also DANE with MX) is sufficiently different that the 6125 rules can and should be revised. * The TLSA base domain is the preferred reference identifier * While treatment of wildcards, ... is application-specific per 6125, the choice of reference identifier with DANE needs to recognize the fact that historically SRV lookups were not DNSSEC protected, and so applications (that cared about security, rather than merely went through the motions) needed to verify the input domain not the SRV host. * Therefore, for backwards-compatibility with UCC certs, ... Tony correctly recognized the need to allow either the SRV hostname (which is now secure and is generally the TLSA base domain) or the legacy input domain. The OPS draft also recomments the CNAME expanded version of the input domain. You can probably reference the OPS draft for some of this, and clone the rest from the SMTP draft. -- Viktor. From nobody Tue Aug 19 09:47:25 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 956CA1A710D for ; Tue, 19 Aug 2014 09:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 HJHDFS8Q7NVA for ; Tue, 19 Aug 2014 09:47:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 05D891A067E for ; Tue, 19 Aug 2014 09:47:23 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2C7A141196; Tue, 19 Aug 2014 10:47:25 -0600 (MDT) Message-ID: <53F37F9C.3050504@stpeter.im> Date: Tue, 19 Aug 2014 10:47:24 -0600 From: Peter Saint-Andre 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: <20140724125827.GX2595@mournblade.imrryr.org> In-Reply-To: <20140724125827.GX2595@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/mo9ALH1URVzk4LIZajC_eGVPgFw 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: Tue, 19 Aug 2014 16:47:24 -0000 On 7/24/14, 6:58 AM, Viktor Dukhovni wrote: > 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. Definitions of "major" vary. In the HTTP world, something like SRV is actively shunned because of the latency it introduces. > 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. This is true. Thus text like this might be better: Developers of application clients that depend on DANE-SRV often would like to prepare as quickly as possible for making a connection to the intended service, thus reducing the wait time for end users. To make this possible, a DNS library might perform the SRV queries and address queries in parallel (because it is wrong to make TLSA queries if the address records are not secure, performing them in parallel with the SRV queries and address queries is not appropriate). > (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). Yes, that usage makes my head hurt. However, that usage does not comply with RFC 2782 (which says that the Target MUST NOT be an alias), which is why we don't talk about it in the dane-srv specification. > 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. Pointing implementors (in a non-normative way) to the possible benefits of lookup concurrency does not seem actively harmful to me. >> 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. Right. As I said, I'd prefer to avoid this contentious topic in the dane-srv specification. Peter From nobody Tue Aug 19 09:49: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 E6E6F1A04F1 for ; Tue, 19 Aug 2014 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 y15BYThFDjAk for ; Tue, 19 Aug 2014 09:49:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 682B71A892F for ; Tue, 19 Aug 2014 09:49:22 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 69B1C41196; Tue, 19 Aug 2014 10:49:24 -0600 (MDT) Message-ID: <53F38013.60709@stpeter.im> Date: Tue, 19 Aug 2014 10:49:23 -0600 From: Peter Saint-Andre 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: <53F37C4C.7040906@stpeter.im> <20140819164110.GF14392@mournblade.imrryr.org> In-Reply-To: <20140819164110.GF14392@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ySE8u_ANAWrDb4_X9RM0h51bLEk 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: Tue, 19 Aug 2014 16:49:31 -0000 On 8/19/14, 10:41 AM, Viktor Dukhovni wrote: > On Tue, Aug 19, 2014 at 10:33:16AM -0600, Peter Saint-Andre wrote: > >>> 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 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? >> >> I'd prefer to leave identity verification rules up to RFC 6125 or the >> application-specific equivalent. There's a reason why RFC 6125 ended up at >> 57 pages... > > DANE with SRV (as also DANE with MX) is sufficiently different that > the 6125 rules can and should be revised. I have ~15 active Internet-Drafts to finish off before I start work on 6125bis. ;-) > * The TLSA base domain is the preferred reference identifier > > * While treatment of wildcards, ... is application-specific per > 6125, the choice of reference identifier with DANE needs to > recognize the fact that historically SRV lookups were not > DNSSEC protected, and so applications (that cared about > security, rather than merely went through the motions) needed > to verify the input domain not the SRV host. > > * Therefore, for backwards-compatibility with UCC certs, ... > Tony correctly recognized the need to allow either the SRV > hostname (which is now secure and is generally the TLSA base > domain) or the legacy input domain. The OPS draft also > recomments the CNAME expanded version of the input domain. > > You can probably reference the OPS draft for some of this, and clone > the rest from the SMTP draft. Noted! Peter From nobody Tue Aug 19 10:06:44 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 7B82F1A0640 for ; Tue, 19 Aug 2014 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 YClZWolp1h8R for ; Tue, 19 Aug 2014 10:06:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 406551A05D3 for ; Tue, 19 Aug 2014 10:06:40 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5CDD641196; Tue, 19 Aug 2014 11:06:42 -0600 (MDT) Message-ID: <53F38421.2050407@stpeter.im> Date: Tue, 19 Aug 2014 11:06:41 -0600 From: Peter Saint-Andre 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: <20140724230432.D09771AC966F@rock.dv.isc.org> <20140726025653.GQ15044@mournblade.imrryr.org> In-Reply-To: <20140726025653.GQ15044@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jO_L56ouHE0UUUbHGM1nxVqdcEo 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: Tue, 19 Aug 2014 17:06:41 -0000 On 7/25/14, 8:56 PM, Viktor Dukhovni wrote: > 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. That's sounds like a great outcome, eventually. Peter From nobody Tue Aug 19 10:24: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 ABF9E1A06DE for ; Tue, 19 Aug 2014 10:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 A4mF4kBU5QuC for ; Tue, 19 Aug 2014 10:24:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E874F1A890A for ; Tue, 19 Aug 2014 10:24:46 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 37D0C41196; Tue, 19 Aug 2014 11:24:49 -0600 (MDT) Message-ID: <53F3885F.5090703@stpeter.im> Date: Tue, 19 Aug 2014 11:24:47 -0600 From: Peter Saint-Andre 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: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> <20140724125757.GW2595@mournblade.imrryr.org> In-Reply-To: <20140724125757.GW2595@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Z-dYVNGd80eIYLb5FUydjfWjYAc 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 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:24:48 -0000 Hi Viktor, thanks for the continued feedback. On 7/24/14, 6:57 AM, Viktor Dukhovni wrote: > 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. What would you suggest the client do in this case? > 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. That comports with my reading of RFC 4035. > Since we're ultimately looking at an SRV RRset Correct. > (possibly after CNAME expansion of the original domain), Disallowed by RFC 2782, right? Or do you mean expansion of the SRV "Name" rather than the SRV "Target"? > it is > either secure in full or insecure in full. That's what we were trying to capture by "entire". But it's just as easy to remove the word if it is causing confusion. > More appropriately, > "entire" applies not to RRset, but rather "entire chain" of aliases > (CNAME or DNAME if any) leading to the ultimate SRV RRset. I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest that we spend time and energy in defining it for use in this specification? > Not continuing with connections to the target service applies when > the DNS lookup fails ("bogus", "indeterminate", "timeout", ...). Are you referring to this text? o If the response is "bogus" or "indeterminate", the client MUST NOT connect to this target server; instead it uses the next most appropriate SRV target. And are you suggesting that we expand that text to mention additional DNS lookup errors (e.g., "timeout")? > DNS lookup error handling is more comprehensively specified in the > SMTP draft, and perhaps should be borrowed from that document in > its entirety. Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily because copying introduces the possibility of divergence in text and secondarily because that text talks about SMTP. It seems safer to me if we point to that text from the dane-srv specification. Peter From nobody Tue Aug 19 11:00: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 E68C71A0646 for ; Tue, 19 Aug 2014 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 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.668, 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 bMeedRwQbSfg for ; Tue, 19 Aug 2014 11:00:53 -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 8DB2B1A0584 for ; Tue, 19 Aug 2014 11:00:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 4256C1E310; Tue, 19 Aug 2014 18:00:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1408471251; bh=LLD3cDCQTt7blzmSrm/smpAx8jO0Pd9pUkYDhPtKncM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G/BaHZedCORYGMS1Vn7r4yQCiz7B2A6RsFaYZBxlUPC48hrpFZNZvoJpApGaEKpOm ua+Cyiv8V1lvvMwOlwlO7j5cIsxeEEYyyo2pZsfT6JK2BH+Zekj7qYNC1IOLKxo0r4 lzztkXlP6cNdWTgpxzmbopDVjWZhoO8NbbRFQEsA= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1511B60022; Tue, 19 Aug 2014 17:59:03 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <53F37F9C.3050504@stpeter.im> (Peter Saint-Andre's message of "Tue, 19 Aug 2014 10:47:24 -0600") References: <20140724125827.GX2595@mournblade.imrryr.org> <53F37F9C.3050504@stpeter.im> 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: Tue, 19 Aug 2014 13:59:03 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:140819:dane@ietf.org::2HH/TpkHGWNPTpFo:0002lpPU X-Hashcash: 1:28:140819:stpeter@stpeter.im::3ulL5ohsy8WQMyOK:000000000000000000000000000000000000000000TgeHY Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tQEY3lkH2aFx9CBt7DgyKqCvrWM 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: Tue, 19 Aug 2014 18:00:54 -0000 >> 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. The TLSA lookup does not need to wait until the status of the address lookup is known. The adress status affects whether one should care about and use the tlsa, not whether one can check for it. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Aug 19 11:07: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 EF9451A0639 for ; Tue, 19 Aug 2014 11:07:20 -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 RJn88Y7Gu_KH for ; Tue, 19 Aug 2014 11:07:19 -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 0CB1B1A0646 for ; Tue, 19 Aug 2014 11:07:19 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3812A2AB2A7; Tue, 19 Aug 2014 18:07:17 +0000 (UTC) Date: Tue, 19 Aug 2014 18:07:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140819180717.GH14392@mournblade.imrryr.org> References: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> <20140724125757.GW2595@mournblade.imrryr.org> <53F3885F.5090703@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F3885F.5090703@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/DFIaHBw5X-cuFTLYTA2HsMUG9cc 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: Tue, 19 Aug 2014 18:07:21 -0000 On Tue, Aug 19, 2014 at 11:24:47AM -0600, Peter Saint-Andre wrote: > >Since we're ultimately looking at an SRV RRset > > Correct. > > >(possibly after CNAME expansion of the original domain), > > Disallowed by RFC 2782, right? Or do you mean expansion of the SRV "Name" > rather than the SRV "Target"? Yes, the "Name". > >More appropriately, > >"entire" applies not to RRset, but rather "entire chain" of aliases > >(CNAME or DNAME if any) leading to the ultimate SRV RRset. > > I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest that > we spend time and energy in defining it for use in this specification? Just be clear that the text in question is talking about the security if the sequence of CNAMEs leading to the result, (all the links in the chain need to be "secure"). The RRset at the end of the chain is "secure" or not, binary, thus "entire" does not apply to that. > >Not continuing with connections to the target service applies when > >the DNS lookup fails ("bogus", "indeterminate", "timeout", ...). > > Are you referring to this text? > > o If the response is "bogus" or "indeterminate", the client MUST NOT > connect to this target server; instead it uses the next most > appropriate SRV target. Yes, "bogus" is not the only case in which you skip the target, and "indeterminate" (as defined in 4035) is best viewed as an error condition. All error conditions in resolving the TLSA RRset lead to skipping the target. > And are you suggesting that we expand that text to mention additional DNS > lookup errors (e.g., "timeout")? All DNS lookup errors, with or without examples of specific ones. Definitely not limited to just "bogus" and "indeterminate". > >DNS lookup error handling is more comprehensively specified in the > >SMTP draft, and perhaps should be borrowed from that document in > >its entirety. > > Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite > comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily > because copying introduces the possibility of divergence in text and > secondarily because that text talks about SMTP. It seems safer to me if we > point to that text from the dane-srv specification. Whatever works for you. There is also a possibility of migrating that text to the OPS draft, if the WG consensus is that such text would be better placed there, and used by reference in both SMTP and SRV. This of course means that OPS must be published at least concurrently with SMTP (and SRV) or even before. -- Viktor. From nobody Tue Aug 19 11:11:09 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 480311A0639 for ; Tue, 19 Aug 2014 11:11:06 -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 jVY4W9m9q33m for ; Tue, 19 Aug 2014 11:11:04 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8FE1A0646 for ; Tue, 19 Aug 2014 11:11:03 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5C72D93C1AF; Tue, 19 Aug 2014 18:10:12 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <53F37C4C.7040906@stpeter.im> Date: Tue, 19 Aug 2014 20:11:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F37C4C.7040906@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QDIynNKxiMr26AAfMfT7nmXZ90M Cc: dane@ietf.org 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: Tue, 19 Aug 2014 18:11:06 -0000 On 19 Aug 2014, at 18:33, Peter Saint-Andre wrote: > Hej Olle, thanks for the feedback and sorry about the slow response > time. Comments inline. >=20 > On 7/24/14, 2:19 AM, Olle E. Johansson wrote: >> Hi! >>=20 >> 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. >>=20 >>=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 >> 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. >=20 > I agree that normative language might not be appropriate. However, the = authors of this spec do think that performing the DNS queries (not, as = noted, the final application connection attempts) in parallel can help = to expedite things significantly. Here is some alternate wording: >=20 > OLD >=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 > NEW >=20 > Developers of application clients that depend on DANE-SRV often > would like to prepare as quickly as possible for making a connection > to the intended service, thus reducing the wait time for end users. > To make this possible, a DNS library might perform the queries > described in the following sections in parallel, rather than waiting > for one set of queries to be completed (say, all SRV queries) before > performing additional queries (say, address queries and TLSA > queries). >=20 Much better >> Section 3.2 >>=20 >> 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 > Ack. Ack >=20 >> In fact the DNS SRV rfc talks >> about "any address family" - now and in the future ;-) >=20 > We can always replace this spec when IPv12 is deployed. :-) Deal. >=20 >> Section 5: >>=20 >> It would help me if you add a bullet like >>=20 >> * Handling in the case of protocols using NAPTR for transport >> selection, like the Session Initiation Protocol >=20 > How is this? >=20 >=20 > o Use of SRV records with additional discovery technologies, such = as > the use of both SRV records and NAPTR records [RFC2915] for > transport selection in the Session Initiation Protocol (SIP). Great. >=20 >> That will help me in sipcore :-) >=20 > We're here for you! Thank you! >=20 >> Section 6: >>=20 >> 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 CN and >> the others Subject Alt Names. >>=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 > I'd prefer to leave identity verification rules up to RFC 6125 or the = application-specific equivalent. There's a reason why RFC 6125 ended up = at 57 pages... Right. /O= From nobody Tue Aug 19 11:34:09 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 0F4201A06AC for ; Tue, 19 Aug 2014 11:34:08 -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 JbF8tgTL0R2q for ; Tue, 19 Aug 2014 11:34:07 -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 0250D1A06A1 for ; Tue, 19 Aug 2014 11:34:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AD3632AB2A4; Tue, 19 Aug 2014 18:34:05 +0000 (UTC) Date: Tue, 19 Aug 2014 18:34:05 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140819183405.GI14392@mournblade.imrryr.org> References: <53F37C4C.7040906@stpeter.im> <20140819164110.GF14392@mournblade.imrryr.org> <53F38013.60709@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F38013.60709@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MaqAmdUNBfklHle1rBp0SWSpi5s 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: Tue, 19 Aug 2014 18:34:08 -0000 On Tue, Aug 19, 2014 at 10:49:23AM -0600, Peter Saint-Andre wrote: > >DANE with SRV (as also DANE with MX) is sufficiently different that > >the 6125 rules can and should be revised. > > I have ~15 active Internet-Drafts to finish off before I start work on > 6125bis. ;-) Sorry, I was unclear, I did not mean 6125bis, I meant that the SRV draft can specify a refinement of the 6125 rules (the SMTP draft does this). -- Viktor. From nobody Tue Aug 19 12:02:02 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 6B3FC1A890D for ; Tue, 19 Aug 2014 12:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 kaTbMRPOkGLX for ; Tue, 19 Aug 2014 12:01:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3D1A6FCF for ; Tue, 19 Aug 2014 12:01:46 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 842F941196; Tue, 19 Aug 2014 13:01:48 -0600 (MDT) Message-ID: <53F39F1A.2080108@stpeter.im> Date: Tue, 19 Aug 2014 13:01:46 -0600 From: Peter Saint-Andre 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: James Cloos , dane@ietf.org References: <20140724125827.GX2595@mournblade.imrryr.org> <53F37F9C.3050504@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3qs9y8IDAAOlg-dHqnlRYLqBlVQ 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: Tue, 19 Aug 2014 19:02:00 -0000 On 8/19/14, 11:59 AM, James Cloos wrote: >>> 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. > > The TLSA lookup does not need to wait until the status of the address > lookup is known. The adress status affects whether one should care > about and use the tlsa, not whether one can check for it. I think that's a more precise way to put it. Thus I propose the following revised text: Developers of application clients that depend on DANE-SRV often would like to prepare as quickly as possible for making a connection to the intended service, thus reducing the wait time for end users. To make this possible, a DNS library might perform the SRV queries, address queries, and TLSA queries in parallel (although the TLSA records are not usable if the address records are not secure, performing the TLSA queries in parallel is not harmful from a security perspective). Peter From nobody Tue Aug 19 12:04:18 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 8EBED1A0ACE for ; Tue, 19 Aug 2014 12:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 uG55Q-CCPYnV for ; Tue, 19 Aug 2014 12:04:14 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 602901A0715 for ; Tue, 19 Aug 2014 12:04:14 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E14ED41196; Tue, 19 Aug 2014 13:04:16 -0600 (MDT) Message-ID: <53F39FAF.2080804@stpeter.im> Date: Tue, 19 Aug 2014 13:04:15 -0600 From: Peter Saint-Andre 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: <53F37C4C.7040906@stpeter.im> <20140819164110.GF14392@mournblade.imrryr.org> <53F38013.60709@stpeter.im> <20140819183405.GI14392@mournblade.imrryr.org> In-Reply-To: <20140819183405.GI14392@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pfwp7innB6FKN1arYAQ71RGIazM 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: Tue, 19 Aug 2014 19:04:16 -0000 On 8/19/14, 12:34 PM, Viktor Dukhovni wrote: > On Tue, Aug 19, 2014 at 10:49:23AM -0600, Peter Saint-Andre wrote: > >>> DANE with SRV (as also DANE with MX) is sufficiently different that >>> the 6125 rules can and should be revised. >> >> I have ~15 active Internet-Drafts to finish off before I start work on >> 6125bis. ;-) > > Sorry, I was unclear, I did not mean 6125bis, I meant that the SRV > draft can specify a refinement of the 6125 rules (the SMTP draft > does this). Thanks. I will look at the dane-smtp spec more carefully with this in mind. Peter From nobody Tue Aug 19 12:42:40 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 9C0D41A0AF5 for ; Tue, 19 Aug 2014 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 cDJ4nI7YMiI6 for ; Tue, 19 Aug 2014 12:42:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFD31A00C2 for ; Tue, 19 Aug 2014 12:42:37 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 038F741196; Tue, 19 Aug 2014 13:42:39 -0600 (MDT) Message-ID: <53F3A8AE.6050605@stpeter.im> Date: Tue, 19 Aug 2014 13:42:38 -0600 From: Peter Saint-Andre 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: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> <20140724125757.GW2595@mournblade.imrryr.org> <53F3885F.5090703@stpeter.im> <20140819180717.GH14392@mournblade.imrryr.org> In-Reply-To: <20140819180717.GH14392@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B0v5--BNMreD8DMMOt7xARDBPcA 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 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 19:42:38 -0000 On 8/19/14, 12:07 PM, Viktor Dukhovni wrote: > On Tue, Aug 19, 2014 at 11:24:47AM -0600, Peter Saint-Andre wrote: > >>> Since we're ultimately looking at an SRV RRset >> >> Correct. >> >>> (possibly after CNAME expansion of the original domain), >> >> Disallowed by RFC 2782, right? Or do you mean expansion of the SRV "Name" >> rather than the SRV "Target"? > > Yes, the "Name". OK. Yes, we might need to account for expansion there. I'm sure you will tell me that the SMTP draft addresses this issue, right? ;-) (I'm not being sarcastic, just in awe of your thoroughness!) >>> More appropriately, >>> "entire" applies not to RRset, but rather "entire chain" of aliases >>> (CNAME or DNAME if any) leading to the ultimate SRV RRset. >> >> I find the term "ultimate SRV RRset" to be a bit vague. Do you suggest that >> we spend time and energy in defining it for use in this specification? > > Just be clear that the text in question is talking about the security > if the sequence of CNAMEs leading to the result, (all the links in > the chain need to be "secure"). The RRset at the end of the chain > is "secure" or not, binary, thus "entire" does not apply to that. Yes, that makes sense. >>> Not continuing with connections to the target service applies when >>> the DNS lookup fails ("bogus", "indeterminate", "timeout", ...). >> >> Are you referring to this text? >> >> o If the response is "bogus" or "indeterminate", the client MUST NOT >> connect to this target server; instead it uses the next most >> appropriate SRV target. > > Yes, "bogus" is not the only case in which you skip the target, > and "indeterminate" (as defined in 4035) is best viewed as an error > condition. All error conditions in resolving the TLSA RRset lead > to skipping the target. > >> And are you suggesting that we expand that text to mention additional DNS >> lookup errors (e.g., "timeout")? > > All DNS lookup errors, with or without examples of specific ones. > Definitely not limited to just "bogus" and "indeterminate". OK. >>> DNS lookup error handling is more comprehensively specified in the >>> SMTP draft, and perhaps should be borrowed from that document in >>> its entirety. >> >> Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite >> comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily >> because copying introduces the possibility of divergence in text and >> secondarily because that text talks about SMTP. It seems safer to me if we >> point to that text from the dane-srv specification. > > Whatever works for you. There is also a possibility of migrating > that text to the OPS draft, if the WG consensus is that such text > would be better placed there, and used by reference in both SMTP > and SRV. This of course means that OPS must be published at least > concurrently with SMTP (and SRV) or even before. Let's see what our WG chairs think about how to proceed. Peter From nobody Tue Aug 19 12:46:12 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 D84D61A0AFC for ; Tue, 19 Aug 2014 12:46:10 -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 U-EcVkUFck8V for ; Tue, 19 Aug 2014 12:46:09 -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 63BDE1A00C2 for ; Tue, 19 Aug 2014 12:46:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5554F2AB2A7; Tue, 19 Aug 2014 19:46:08 +0000 (UTC) Date: Tue, 19 Aug 2014 19:46:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140819194607.GJ14392@mournblade.imrryr.org> References: <20140724125827.GX2595@mournblade.imrryr.org> <53F37F9C.3050504@stpeter.im> <53F39F1A.2080108@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F39F1A.2080108@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nwXNgYCMoyYYCdlNFqAExC1zRnI 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: Tue, 19 Aug 2014 19:46:11 -0000 On Tue, Aug 19, 2014 at 01:01:46PM -0600, Peter Saint-Andre wrote: > I think that's a more precise way to put it. Thus I propose the following > revised text: > > Developers of application clients that depend on DANE-SRV often would > like to prepare as quickly as possible for making a connection to the > intended service, thus reducing the wait time for end users. To make > this possible, a DNS library might perform the SRV queries, address > queries, and TLSA queries in parallel (although the TLSA records are > not usable if the address records are not secure, performing the TLSA > queries in parallel is not harmful from a security perspective). Almost right, but note that the reason to "supress" TLSA RRs when address RRs are insecure is that TLSA RR lookups have been observed to generate spurious lookup errors in that case (which one might misconstrue to be an attack). If TLSA RRs are actually returned, they are most likely to be also "insecure" when the A records are insecure. In fact any other outcome would require a DLV configuration for say either _tcp.imap.example.com or _143._tcp.imap.example.com to re-establish trust below the "insecure" imap.example.com. Such configurations seem most unlikely. Also avoid "not usable", since that has special meaning in 6698. So the thing to say is something along the lines that when the A/AAAA results are "insecure" errors in TLSA lookup can be ignored, but otherwise, any errors in TLSA lookup should be considered equivalent to an active attack and cause the peer to be skipped. -- Viktor. From nobody Tue Aug 19 12:49: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 6C8361A0AFC for ; Tue, 19 Aug 2014 12:49:51 -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 U7PptuSRFwxl for ; Tue, 19 Aug 2014 12:49:50 -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 7F4B31A0AFA for ; Tue, 19 Aug 2014 12:49:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 802372AB2A7; Tue, 19 Aug 2014 19:49:49 +0000 (UTC) Date: Tue, 19 Aug 2014 19:49:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140819194949.GK14392@mournblade.imrryr.org> References: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> <20140724125757.GW2595@mournblade.imrryr.org> <53F3885F.5090703@stpeter.im> <20140819180717.GH14392@mournblade.imrryr.org> <53F3A8AE.6050605@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F3A8AE.6050605@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Q5aiyVMoNzT0paeKfFniBru3G4I 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: Tue, 19 Aug 2014 19:49:51 -0000 On Tue, Aug 19, 2014 at 01:42:38PM -0600, Peter Saint-Andre wrote: > >Yes, the "Name". > > OK. Yes, we might need to account for expansion there. I'm sure you will > tell me that the SMTP draft addresses this issue, right? ;-) Yes. :-) > (I'm not being sarcastic, just in awe of your thoroughness!) Thanks. That's how the SMTP draft got to 33 pages... The thoroughness is a result of writing both the draft and an implementation of that draft. -- Viktor. From nobody Tue Aug 19 15:44:03 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 8FA1F1A6F2A for ; Tue, 19 Aug 2014 15:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 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.668, 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 RcV-DR72KD08 for ; Tue, 19 Aug 2014 15:44:00 -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 2C2431A6F03 for ; Tue, 19 Aug 2014 15:44:00 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 4445F1E668; Tue, 19 Aug 2014 22:43:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1408488238; bh=JDR1hG50XBkGDuiSh0ZnGZlPoR9LOiXNLc4/a7trDOg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BlNoBIkrCijZ9UZIXrFy4Co0vAbfgj0mWDCiiG8aJxDILr6F6ri6C7qzrCLU/T6OA lxa86z7z651U0qJh8UVyk68Fu/e9ByVVcgdw+TJfckQL0Rv/5EJan1RVlDQhMgfpkk nDHX1DVu+lXea6whmn2hbiThpoZyO/ri4O3CMcYQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id D2C8460022; Tue, 19 Aug 2014 22:43:01 +0000 (UTC) From: James Cloos To: Peter Saint-Andre In-Reply-To: <53F39F1A.2080108@stpeter.im> (Peter Saint-Andre's message of "Tue, 19 Aug 2014 13:01:46 -0600") References: <20140724125827.GX2595@mournblade.imrryr.org> <53F37F9C.3050504@stpeter.im> <53F39F1A.2080108@stpeter.im> 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: Tue, 19 Aug 2014 18:43:01 -0400 Message-ID: Lines: 21 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:140819:stpeter@stpeter.im::Nv3lO9gBgqkFGL8s:0000000000000000000000000000000000000000002uV1a X-Hashcash: 1:28:140819:dane@ietf.org::HKELjWiwccl6gIGR:000HXgCI Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xqwGP2QPFVjHRwvkOIHoBz2rsO0 Cc: dane@ietf.org 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: Tue, 19 Aug 2014 22:44:01 -0000 >>>>> "PS" == Peter Saint-Andre writes: PS> I think that's a more precise way to put it. Thus I propose the PS> following revised text: PS> Developers of application clients that depend on DANE-SRV often would PS> like to prepare as quickly as possible for making a connection to the PS> intended service, thus reducing the wait time for end users. To make PS> this possible, a DNS library might perform the SRV queries, address PS> queries, and TLSA queries in parallel (although the TLSA records are PS> not usable if the address records are not secure, performing the TLSA PS> queries in parallel is not harmful from a security perspective). Looks good to me! -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Aug 19 17:52: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 E479B1A0162 for ; Tue, 19 Aug 2014 17:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 BZBjpeB9b5hJ for ; Tue, 19 Aug 2014 17:52:06 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id A1B131A00EC for ; Tue, 19 Aug 2014 17:52:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E66385C5C9F; Wed, 20 Aug 2014 01:52:03 +0100 (BST) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6IAi5nB0SiY; Wed, 20 Aug 2014 01:52:02 +0100 (BST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id BCAE75C5C94; Wed, 20 Aug 2014 01:52:02 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: Date: Wed, 20 Aug 2014 01:52:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F37C4C.7040906@stpeter.im> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2_oWYL68irdHPQ5nCgZUNohCbNI Cc: dane@ietf.org 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: Wed, 20 Aug 2014 00:52:09 -0000 Hi there Olle, folks OK, whilst we're adding references, please don't put in a reference to = an obsoleted RFC. 2915 was obsoleted by that fine collection, RFCs 3401-3504 -- ages ago. SIP always was kinda different (allowing an informational RFC through = that included MUSTs), so sipcore may not care, but ... BTW, I found 3263 to be not too bad at all; it does lose it and drift = into philosophy (or at least, not English) half way through, but the = protocol use bits are fine, IMHO. The 2543 A record and guess approach = was and is fugly -- 3263 with its NAPTRs & SRVs has to be a better way. = With Dane, it's even better. all the best, Lawrence On 19 Aug 2014, at 19:11, Olle E. Johansson wrote: > On 19 Aug 2014, at 18:33, Peter Saint-Andre = wrote: >> >>> Section 5: >>>=20 >>> It would help me if you add a bullet like >>>=20 >>> * Handling in the case of protocols using NAPTR for transport >>> selection, like the Session Initiation Protocol >>=20 >> How is this? >>=20 >> o Use of SRV records with additional discovery technologies, such = as >> the use of both SRV records and NAPTR records [RFC2915] for >> transport selection in the Session Initiation Protocol (SIP). > Great. >>=20 >>> That will help me in sipcore :-) >>=20 >> We're here for you! > Thank you! > > /O From nobody Tue Aug 19 17:58: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 60AA01A010D for ; Tue, 19 Aug 2014 17:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 hU-twFyiHgJK for ; Tue, 19 Aug 2014 17:58:53 -0700 (PDT) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1201A00ED for ; Tue, 19 Aug 2014 17:58:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 99FC65C5D62; Wed, 20 Aug 2014 01:58:52 +0100 (BST) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV0gVnerP8AO; Wed, 20 Aug 2014 01:58:52 +0100 (BST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 4AD675C5D57; Wed, 20 Aug 2014 01:58:52 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: Date: Wed, 20 Aug 2014 01:58:52 +0100 Content-Transfer-Encoding: 7bit Message-Id: <513D4F48-6088-4B47-9F70-AB0B75718467@insensate.co.uk> References: <53F37C4C.7040906@stpeter.im> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pddngdwkrX2FgGbAxT_XlElBZBU Cc: dane@ietf.org 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: Wed, 20 Aug 2014 00:58:54 -0000 On 20 Aug 2014, at 01:52, Lawrence Conroy wrote: > 2915 was obsoleted by that fine collection, RFCs 3401-3504 -- ages ago. To which I edit: 2915 was obsoleted by that fine collection, RFCs 3401-3405 -- ages ago. The DDDS set just seemed that long. (The core NAPTR ref is, BTW, 3403). atb, L Repeat after me: sleep before mailing. From nobody Fri Aug 22 00:25: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 C66DE1A00FB; Fri, 22 Aug 2014 00:25: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 oQ05mX3Xy3o2; Fri, 22 Aug 2014 00:25:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8441A00ED; Fri, 22 Aug 2014 00:25:02 -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.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140822072502.14880.6231.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 00:25:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3FV86ZBYwo3r6brMWcgLHrUuFkI Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-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: Fri, 22 Aug 2014 07:25: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 Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-07.txt Pages : 7 Date : 2014-08-22 Abstract: This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-smime-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-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 Mon Aug 25 16:27: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 481F51A0476 for ; Mon, 25 Aug 2014 16:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668, 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 w8lY89ykQnsY for ; Mon, 25 Aug 2014 16:27:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4121A0462 for ; Mon, 25 Aug 2014 16:27:36 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC43240FA4; Mon, 25 Aug 2014 17:28:04 -0600 (MDT) Message-ID: <53FBC668.3000204@stpeter.im> Date: Mon, 25 Aug 2014 17:27:36 -0600 From: Peter Saint-Andre 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: <20140724125827.GX2595@mournblade.imrryr.org> <53F37F9C.3050504@stpeter.im> <53F39F1A.2080108@stpeter.im> <20140819194607.GJ14392@mournblade.imrryr.org> In-Reply-To: <20140819194607.GJ14392@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/arqKFf4gr_PZrXb3KT7t3hFe0vw 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: Mon, 25 Aug 2014 23:27:38 -0000 On 8/19/14, 1:46 PM, Viktor Dukhovni wrote: > On Tue, Aug 19, 2014 at 01:01:46PM -0600, Peter Saint-Andre wrote: > >> I think that's a more precise way to put it. Thus I propose the following >> revised text: >> >> Developers of application clients that depend on DANE-SRV often would >> like to prepare as quickly as possible for making a connection to the >> intended service, thus reducing the wait time for end users. To make >> this possible, a DNS library might perform the SRV queries, address >> queries, and TLSA queries in parallel (although the TLSA records are >> not usable if the address records are not secure, performing the TLSA >> queries in parallel is not harmful from a security perspective). > > Almost right, but note that the reason to "supress" TLSA RRs when > address RRs are insecure is that TLSA RR lookups have been observed > to generate spurious lookup errors in that case (which one might > misconstrue to be an attack). > > If TLSA RRs are actually returned, they are most likely to be also > "insecure" when the A records are insecure. In fact any other > outcome would require a DLV configuration for say either > _tcp.imap.example.com or _143._tcp.imap.example.com to re-establish > trust below the "insecure" imap.example.com. Such configurations > seem most unlikely. > > Also avoid "not usable", since that has special meaning in 6698. > So the thing to say is something along the lines that when the > A/AAAA results are "insecure" errors in TLSA lookup can be ignored, > but otherwise, any errors in TLSA lookup should be considered > equivalent to an active attack and cause the peer to be skipped. How about this? (because the TLSA records can be ignored if the address records are not secure, performing the TLSA queries in parallel is not harmful from a security perspective). Peter From nobody Mon Aug 25 16:32: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 20A781A048A for ; Mon, 25 Aug 2014 16:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOLu2lRIs8_g for ; Mon, 25 Aug 2014 16:32:25 -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 599881A03F6 for ; Mon, 25 Aug 2014 16:32:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1FC8D2AB173; Mon, 25 Aug 2014 23:32:24 +0000 (UTC) Date: Mon, 25 Aug 2014 23:32:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140825233223.GV14392@mournblade.imrryr.org> References: <20140724125827.GX2595@mournblade.imrryr.org> <53F37F9C.3050504@stpeter.im> <53F39F1A.2080108@stpeter.im> <20140819194607.GJ14392@mournblade.imrryr.org> <53FBC668.3000204@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FBC668.3000204@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5SNyt8XYdCYEfUsptKTNAt-pvjI 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: Mon, 25 Aug 2014 23:32:27 -0000 On Mon, Aug 25, 2014 at 05:27:36PM -0600, Peter Saint-Andre wrote: > How about this? > > (because the TLSA records can > be ignored if the address records are not secure, performing the TLSA > queries in parallel is not harmful from a security perspective). The reason to skip (or at least ignore lookup errors with) TLSA lookups when A/AAAA are "insecure" are operational, not security. So perhaps: s/security perspective/operational perspective/ Otherwise, if it says what you want it to say, fine. I am not sure we the draft needs to teach implementors how to optimize the implementation, but if you feel it is important (to encourage adoption) go for it. You could probably therefore phrase it a bit better than the suggested substitution. -- Viktor. From nobody Mon Aug 25 18:07: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 110A01A0584 for ; Mon, 25 Aug 2014 18:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 6YNawK7Lx7wv for ; Mon, 25 Aug 2014 18:07:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7BC1A0574 for ; Mon, 25 Aug 2014 18:07:18 -0700 (PDT) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A6AF40FA4; Mon, 25 Aug 2014 19:07:48 -0600 (MDT) Message-ID: <53FBDDC8.4010908@stpeter.im> Date: Mon, 25 Aug 2014 19:07:20 -0600 From: Peter Saint-Andre 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: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> <20140724125757.GW2595@mournblade.imrryr.org> <53F3885F.5090703@stpeter.im> In-Reply-To: <53F3885F.5090703@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YgHHgTERGdAxKlDe6z4LVctseH8 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 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 01:07:20 -0000 I've been reading the dane-smtp draft and have a further thought... On 8/19/14, 11:24 AM, Peter Saint-Andre wrote: > > On 7/24/14, 6:57 AM, Viktor Dukhovni wrote: >> DNS lookup error handling is more comprehensively specified in the >> SMTP draft, and perhaps should be borrowed from that document in >> its entirety. > > Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite > comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily > because copying introduces the possibility of divergence in text and > secondarily because that text talks about SMTP. It seems safer to me if > we point to that text from the dane-srv specification. Upon reading the dane-smtp document again, I am thinking more strongly that the text in Section 2.1 applies to most application protocols, not only SMTP; thus I wonder if we can move it to a more general document. Chairs & WG, what do you think? Peter From nobody Tue Aug 26 07:48:44 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 3B7121A8035 for ; Tue, 26 Aug 2014 07:48:42 -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 kotugUhvo-36 for ; Tue, 26 Aug 2014 07:48:40 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF4C1A802B for ; Tue, 26 Aug 2014 07:48:40 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKU/yeR7bNL/PPHe7UZvQM5bAXDtJ8C8p2@postini.com; Tue, 26 Aug 2014 07:48:40 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s7QEmddl018816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 10:48:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 26 Aug 2014 10:48:38 -0400 From: "Osterweil, Eric" To: dane WG list Thread-Topic: S/MIME draft Thread-Index: AQHPwTzSp2zLy/0IwEiIGXszYmLFzg== Date: Tue, 26 Aug 2014 14:48:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_EF452441-40E1-481B-9605-84CFE45FA555"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/zuagQGhvTVVKS8RkeiMSQ8_fy1g Subject: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:48:42 -0000 --Apple-Mail=_EF452441-40E1-481B-9605-84CFE45FA555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey all, Some time ago we had some discussions about draft-ietf-dane-smime, which = led to=20 https://www.ietf.org/mail-archive/web/dane/current/msg06338.html A few of us felt that it might be productive to outline a set of = requirements that we foresee DANE facing in enterprises environments = (w.r.t. encrypted/signed email). To that end, we put together the = draft: ``Enterprise Requirements for Secure Email Key Management'' = http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 We certainly welcome discussion and feedback, and we're hoping that this = work will help inform the and evolve draft-ietf-dane-smime. Thanks! Eric --Apple-Mail=_EF452441-40E1-481B-9605-84CFE45FA555 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDgyNjE0NDgzNFowIwYJKoZIhvcN AQkEMRYEFLXgRxvqnqFP3xTq3uoNJjmF9SsQMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAGQRXTXdfypIsbFqy4wDzgFfY1F1691x/wQKa5SwxZcAlyGEmq96 l46RvkG99v7ksUbT/gnPs8Lifex81LAhXvia8/wB1ZtYaSgJU52hOvni65vbnYze63XwpUhf1l6O OMp1uaTQEDOoNP5YfZnv+JPhhmHw0Ejx7fML4cvO0g9nfp8b6W69h4XAXxE5rnPLedhI76sEwIus kK0QEQbeKNppXY3hOdjTW2OHYrIdVlKf9Ac0pOJkjJZ+mA7ERJrvoHKmLFiexIFqooEEkbenleFj Cyw+OUr7G6Zt/Whuomw2VqlCvFKQKe08TEdt2A+tzW1YzUfUU6qVt66Ve2ZF/mwAAAAAAAA= --Apple-Mail=_EF452441-40E1-481B-9605-84CFE45FA555-- From nobody Tue Aug 26 08:22: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 E0EFC1A870E for ; Tue, 26 Aug 2014 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] 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 RmYxjHR4p5Ur for ; Tue, 26 Aug 2014 08:22:14 -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 4CDAB1A871C for ; Tue, 26 Aug 2014 08:22:14 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E00D582E12; Tue, 26 Aug 2014 11:22:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1409066532; bh=uPtlDhCnf126mOxMFxXY4pNFKEgsyYT6tH9GQzkwF4Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=B5Jbw8y96rFLeNZwSLQ2vvXDep3MVA40lnMk65ibDOjZLY1/Sfie9VzkCs84cpUUL cSgr4dTHsXP/TWiXLwJCeEvAGfju+DOPeIRxoIH53/bWBMOlJUUCUuHcqHgTXoB2tp 5wOw4c1rIQhC6lnOaUNUsaByOH7XTPOknbApqm7U= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7QFMC5s001834; Tue, 26 Aug 2014 11:22:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 26 Aug 2014 11:22:12 -0400 (EDT) From: Paul Wouters To: "Osterweil, Eric" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1A7b16MP53ZgoynMpaUsBGKtKRs Cc: dane WG list Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:22:18 -0000 On Tue, 26 Aug 2014, Osterweil, Eric wrote: > Some time ago we had some discussions about draft-ietf-dane-smime, which led to > https://www.ietf.org/mail-archive/web/dane/current/msg06338.html > A few of us felt that it might be productive to outline a set of requirements that we foresee DANE facing in enterprises environments (w.r.t. encrypted/signed email). To that end, we put together the draft: > ``Enterprise Requirements for Secure Email Key Management'' > http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 I'm not an smime person at all and I'm a little confused about what the document is trying to do. It talks about "key management requirements", and then suggests specific requirements for a "protocol"? Which protocol? I would think this would be very much in the realm of local policies. If something is missing in the smime-dane draft for "enterprise deployment", does that mean the smime-dane draft itself is incomplete? Could you send PaulH and Jakob text to ensure it can support enterprise roll-out? If it is complete, then your document should only list the requirements on HOW to use it, instead of defining a new future protocol? REQ-16 Encryption keys MUST be discoverable separately from signature keys. Possible means includes (but not limited to) naming conventions, sub-typing or unique RR types for each use Intuition: Not all certificates for a user may be needed for all circumstances. Fetching them separately can be a management, a scaling, or even a security concern. This requirement for example is impossible with the current smime-dane draft? And sub-typing these days is frowned upon. I'm not sure how fetching the keys for encryption and signing separately would be a security concern? That seems a little uhm, far fetched :) If it is in public DNS, anyone can do it. If it is in private DNS, I'd say it is already secured? Paul From nobody Tue Aug 26 08:35:50 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 0523F1A8746 for ; Tue, 26 Aug 2014 08:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oSGv5Dc7EpA for ; Tue, 26 Aug 2014 08:35:43 -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 420611A8749 for ; Tue, 26 Aug 2014 08:35:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0F93D2AB0B4; Tue, 26 Aug 2014 15:35:41 +0000 (UTC) Date: Tue, 26 Aug 2014 15:35:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140826153540.GZ14392@mournblade.imrryr.org> References: <20140723172859.7673.58244.idtracker@ietfa.amsl.com> <20140724125757.GW2595@mournblade.imrryr.org> <53F3885F.5090703@stpeter.im> <53FBDDC8.4010908@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FBDDC8.4010908@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rbIHreYuyOBLptGdQAbs97Q6uP4 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: Tue, 26 Aug 2014 15:35:48 -0000 On Mon, Aug 25, 2014 at 07:07:20PM -0600, Peter Saint-Andre wrote: > >Yes, Section 2.1 of draft-ietf-dane-smtp-with-dane is indeed quite > >comprehensive. I am hesitant to copy it to draft-ietf-dane-srv primarily > >because copying introduces the possibility of divergence in text and > >secondarily because that text talks about SMTP. It seems safer to me if > >we point to that text from the dane-srv specification. > > Upon reading the dane-smtp document again, I am thinking more strongly that > the text in Section 2.1 applies to most application protocols, not only > SMTP; thus I wonder if we can move it to a more general document. > > Chairs & WG, what do you think? At the time that was written, the OPS draft was informational, but this section necessarily contains normative text. So for lack of a better place, it was in the SMTP draft. I'm not sure that section 2.1 is a good fit for the OPS draft, which is already somewhat of a chimera as a result of a change of mission from an informational implementation/ops guide to a 6698 update. What is perhaps missing is a generic document describing DANE implementation guidelines for opportunistic protocols that use DANE for "discovery", and implement DANE-based authentication only when keys are found (this is the use-case addressed by 2.1, though some or most of it[ might also apply with non-opportunistic scenarios). There could be a separate document with implementation guidelines for using DANE for mandatory security (application must use authentication by local policy, with TLSA RRs for key lookup). [ Any volunteers? I need a break from IETF activity after all the sturm und drang over the opportunistic security definition draft. ] Another option may be to move 2.1 into the SRV draft, and use it by reference from SMTP. Tony's original documents had most of the meat in the SRV draft, and SMTP was a thin variant. The main difficulty is that SRV does not have an explicit opportunistic or mandatory mode of operation. It leaves that question unaddressed. So moving 2.1 into the SRV document might require at least some text about differences between opportunistic DANE and mandatory DANE. We have a record format in 6698, but we don't yet have a document that presents a model of how DANE should be used. And there are in fact at least two high-level models to describe. The SRV document is basically DANE with Service Specification records (http://www.ietf.org/archive/id/draft-ogud-dane-vocabulary-02.txt). Perhaps the SRV draft should become primarily "Opportunistic DANE with SSR" (some of the content already makes more sense in that light), with a section at the end that briefly touches on how the mandatory SRV use-case might differ? If so, 2.1 moves to the SRV draft, and the SMTP draft imports it by reference. Other bits could move over also (the sections on the various Certificate usages for example). This is a difficult question, and another option is to focus and specify DANE for XMPP (which is looking to use the SRV draft as its DANE specification) leaving generic SRV for a time when we have more clarity. Are there other major application protocols with SRV records that are gearing up to use DANE? Here, I think there needs to a vision of how all the pieces fit together, and somebody to drive it. At this time, per protocol documents may be easier to pin down, and SRV is arguably too general. -- Viktor. From nobody Tue Aug 26 08:41: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 806841A8705 for ; Tue, 26 Aug 2014 08:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 Uz3MvbRZSuUx for ; Tue, 26 Aug 2014 08:41:18 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 9DC291A6F64 for ; Tue, 26 Aug 2014 08:41:18 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s7QFfBvO004044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Aug 2014 08:41:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-0-66-181.dsl.dynamic.sonic.net [50.0.66.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: Date: Tue, 26 Aug 2014 08:41:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Eric Osterweil X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Uuwy5O0zqqeedWyya43br2cGzLw Cc: dane WG list Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 15:41:20 -0000 On Aug 26, 2014, at 7:48 AM, Osterweil, Eric = wrote: > A few of us felt that it might be productive to outline a set of = requirements that we foresee DANE facing in enterprises environments = (w.r.t. encrypted/signed email). To that end, we put together the = draft: > ``Enterprise Requirements for Secure Email Key Management'' > = http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 Although you are using DANE for that, the general topic is = email-end-to-end. You might therefore want to instead discuss the = principles on the "endymail" mailing list that Stephen Farrell just = announced yesterday on the SAAG list; see below. --Paul Hoffman Begin forwarded message: > From: Stephen Farrell > Subject: [saag] new list for discussion of end-to-end email = security/privacy improvements > Date: August 25, 2014 at 11:20:41 AM PDT > To: "saag@ietf.org" >=20 >=20 > Hi all, >=20 > Following on from discussion in Toronto in appaswg and saag, > and a subsequent request, we've created a mailing list for > discussing this topic. Pete Resnick and I will initially > manage the list. If you're interested, please subscribe. > Once Pete and I figure there's a good enough set of folks > subscribed we'll fire off a starter email. That usually takes > a few days, so probably Wed-Thu this week. >=20 > The list [1] description is: >=20 > There is significant interest in improving the > privacy-related properties of Internet mail. One focus of > current efforts is on the per-hop (connection-based) > protections provided by TLS. However a wide range of other > work has a focus on end-to-end protection, at the Internet > scale of billions of end users and perhaps millions of > operators. Such work typically involves new forms of mail > header or body protection, new public key management > (compared to S/MIME or PGP), and security mechanisms more > appropriate for mobile/web user-agents. Other > security-relevant approaches may be discussed if needed. > Various proposals and development efforts on this topic are > underway outside the IETF. This mailing list provides an > IETF venue for discussion of elements that might be commonly > needed by such efforts and to identify work that the IETF > could do to aid in achieving better end-to-end security > deployed for Internet email. >=20 > Cheers, > S. >=20 > [1] https://www.ietf.org/mailman/listinfo/endymail From nobody Tue Aug 26 10:28: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 1E3131A00A8 for ; Tue, 26 Aug 2014 10:28:21 -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 g2m9FmQEuqLz for ; Tue, 26 Aug 2014 10:28:17 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECFF1A0045 for ; Tue, 26 Aug 2014 10:28:13 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKU/zDrO9Iy5ZJ/wWCJidP7glBoCoJgYkU@postini.com; Tue, 26 Aug 2014 10:28:17 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 s7QHSBb7023832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 13:28:12 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 26 Aug 2014 13:28:10 -0400 From: "Osterweil, Eric" To: Paul Wouters Thread-Topic: [dane] S/MIME draft Thread-Index: AQHPwTzSp2zLy/0IwEiIGXszYmLFzpvjQ5kAgAAjMIA= Date: Tue, 26 Aug 2014 17:28:09 +0000 Message-ID: <68A831F1-9066-41AD-81A2-2A2EEE2CE556@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_51EE2C05-391E-4CF6-8A81-7422B6405BE1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/asqmLFTsiIXm3pFpLzIkWoemkvM Cc: dane WG list Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 17:28:21 -0000 --Apple-Mail=_51EE2C05-391E-4CF6-8A81-7422B6405BE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey Paul, Wow, thanks for the really quick read! :) On Aug 26, 2014, at 11:22 AM, Paul Wouters wrote: > On Tue, 26 Aug 2014, Osterweil, Eric wrote: >=20 >> Some time ago we had some discussions about draft-ietf-dane-smime, = which led to >> https://www.ietf.org/mail-archive/web/dane/current/msg06338.html >> A few of us felt that it might be productive to outline a set of = requirements that we foresee DANE facing in enterprises environments = (w.r.t. encrypted/signed email). To that end, we put together the = draft: >> ``Enterprise Requirements for Secure Email Key Management'' >> = http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 >=20 > I'm not an smime person at all and I'm a little confused about what = the > document is trying to do. It talks about "key management = requirements", > and then suggests specific requirements for a "protocol"? >=20 > Which protocol? By protocol, we were talking about the process of trying to find, = verify, and use keys from DNS for email encryption and signing. > I would think this would be very much in the realm of > local policies. If something is missing in the smime-dane draft for > "enterprise deployment", does that mean the smime-dane draft itself is > incomplete? Could you send PaulH and Jakob text to ensure it can = support > enterprise roll-out? In the referenced email thread, we had a discussion about adding = specific text, but we wound up not being able to resolve things. As a = result, we were hoping that this draft would server as a step back that = provides focused intuition behind the general ideas from the previously = offered specific text. The previous suggestions are in the email = archive, but this draft is intended to spark any needed discussions in = order to clarify (and hopefully overcome) fundamental = misunderstandings/disagreements/etc. We're definitely open the prospect = that there might be more optimal ways to update the smime-dane draft = than the text that was previously suggested before. > If it is complete, then your document should only list the > requirements on HOW to use it, instead of defining a new future = protocol? I think we feel it is the former. > REQ-16 Encryption keys MUST be discoverable separately from > signature keys. Possible means includes (but not limited = to) > naming conventions, sub-typing or unique RR types for each > use >=20 > Intuition: Not all certificates for a user may be needed > for all circumstances. Fetching them separately can be = a > management, a scaling, or even a security concern. >=20 > This requirement for example is impossible with the current smime-dane = draft? And > sub-typing these days is frowned upon. RFC 5751 has support for this behavior in Section 2.5.3, so I think it's = worth considering that this policy choice exists in operational = deployments. That said, I think your comment raises a very good point = though because it underlies some of our motivation for writing this = draft. We think supporting existing practices is important to help = bolster DANE's deployment. I don't think we want our protocols to show = up and be incompatible with existing deployments on day 1, if we can = reasonably avoid it, right? That could actually deal a much harsher = blow to DANE than anything else:=20 ``this thing just doesn't work at all=85''=20 could be quite hard to overcome. > I'm not sure how fetching the keys for encryption and signing = separately > would be a security concern? That seems a little uhm, far fetched :) Maybe an organization wants to control the ability of external RPs to = learn specific types of keying material, but may want/need to continue = to expose other types. That was actually an operational problem = encountered after Heartbleed for some places. > If it is in public DNS, anyone can do it. If it is in private DNS, I'd > say it is already secured? If I want to ensure that some keys are public and some are not (based on = how they are used, i.e. signing or encrypting), I likely want = configuration options to help me there. That's part of the point. Do = the other two points (management and scaling) make more sense than this = one? Is it primarily the ``security concern'' statement that seems = untenable? Eric --Apple-Mail=_51EE2C05-391E-4CF6-8A81-7422B6405BE1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDgyNjE3MjgwOVowIwYJKoZIhvcN AQkEMRYEFAxFRZvPYoN37KIA1ZYvf03YWVFmMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBAJnvQtxQRuuvWCMA9enPWPLZIdDGs0KQ9v8tqFCmr4IIiyede6UP cfAcGc4ZgHNDUTxmf2X9ApN7oKRWZQkNXuZ78iNvhVfE/qgUyOMyzRzxBo50ZSQvkfbXbVxXKe/w +EsMVGEVgPJsp6P23kJ+nAwOvy3zS7J30bbSvoKawkN9edBNlBcz653IleNok3Rb0+frmcEaX71y lQ+ookDydXsOLC/jd8ASkNy3kWb49/+X7h0pQ/7n1XXYY/H93ph7+lybsHEBoqRWIYBmtl8mGvfB RkEo6+JmFxgc2jibgbRLsH0F/NRu2v4I/nS1wKNoa5Yd6FQfu4iQUgKb1oS0ObwAAAAAAAA= --Apple-Mail=_51EE2C05-391E-4CF6-8A81-7422B6405BE1-- From nobody Tue Aug 26 10:50: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 A01DB1A00AD for ; Tue, 26 Aug 2014 10:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 SZ7uEuwgJPuX for ; Tue, 26 Aug 2014 10:50:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA671A0010 for ; Tue, 26 Aug 2014 10:50:32 -0700 (PDT) Received: from BLUPR09MB117.namprd09.prod.outlook.com (10.255.213.14) by BLUPR09MB119.namprd09.prod.outlook.com (10.255.213.147) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 26 Aug 2014 17:50:30 +0000 Received: from BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) by BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) with mapi id 15.00.1015.018; Tue, 26 Aug 2014 17:50:30 +0000 From: "Rose, Scott" To: Paul Wouters Thread-Topic: [dane] S/MIME draft Thread-Index: AQHPwTzSp2zLy/0IwEiIGXszYmLFzpvjAIoAgAApbQA= Date: Tue, 26 Aug 2014 17:50:30 +0000 Message-ID: <699D1F51-00F3-4DD4-9D62-2307DC3B4582@nist.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.6.140.6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(51704005)(189002)(24454002)(377454003)(85306004)(105586002)(36756003)(107046002)(106116001)(21056001)(64706001)(101416001)(80022001)(66066001)(50986999)(106356001)(31966008)(76176999)(54356999)(99286002)(33656002)(74502001)(95666004)(74662001)(110136001)(20776003)(19580405001)(87936001)(19580395003)(81342001)(99396002)(4396001)(81542001)(86362001)(92566001)(92726001)(46102001)(90102001)(76482001)(83716003)(77982001)(15975445006)(82746002)(2656002)(85852003)(83072002)(79102001)(15202345003)(83322001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB119; H:BLUPR09MB117.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <548528201E983742AB8FB2C9C84E2510@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iAxaIbGnYIlm4oqg5OGf1H0ggdo Cc: dane WG list Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 17:50:34 -0000 On Aug 26, 2014, at 11:22 AM, Paul Wouters wrote: > On Tue, 26 Aug 2014, Osterweil, Eric wrote: >=20 >> Some time ago we had some discussions about draft-ietf-dane-smime, which= led to >> https://www.ietf.org/mail-archive/web/dane/current/msg06338.html >> A few of us felt that it might be productive to outline a set of require= ments that we foresee DANE facing in enterprises environments (w.r.t. encry= pted/signed email). To that end, we put together the draft: >> ``Enterprise Requirements for Secure Email Key Management'' >> http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 >=20 > I'm not an smime person at all and I'm a little confused about what the > document is trying to do. It talks about "key management requirements", > and then suggests specific requirements for a "protocol"? >=20 > Which protocol? I would think this would be very much in the realm of > local policies. If something is missing in the smime-dane draft for > "enterprise deployment", does that mean the smime-dane draft itself is > incomplete? Could you send PaulH and Jakob text to ensure it can support > enterprise roll-out? If it is complete, then your document should only li= st the > requirements on HOW to use it, instead of defining a new future protocol? >=20 Noted - the requirements are for capabilities, so maybe "protocol" is a bad= choice of words. This draft is to start to flesh out requirements and get= the discussion going with the goal to improve the SMIMEA draft, or other d= rafts. =20 >=20 > REQ-16 Encryption keys MUST be discoverable separately from > signature keys. Possible means includes (but not limited to) > naming conventions, sub-typing or unique RR types for each > use >=20 > Intuition: Not all certificates for a user may be needed > for all circumstances. Fetching them separately can be a > management, a scaling, or even a security concern. >=20 > This requirement for example is impossible with the current smime-dane dr= aft? And > sub-typing these days is frowned upon. >=20 Just listing the options, even bad ones. :) The main reason for being able= to differentiate between signing and encrypting keys is the size issue, bu= t also reduce the risk of a client encrypting an email with a receiver's si= gning key by mistake. Enterprises may have the encrypting key stored at th= e receiving MTA, but not the signing key. Scott > I'm not sure how fetching the keys for encryption and signing separately > would be a security concern? That seems a little uhm, far fetched :) > If it is in public DNS, anyone can do it. If it is in private DNS, I'd > say it is already secured? >=20 > Paul >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Aug 26 11:45:43 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 612841A0195 for ; Tue, 26 Aug 2014 11:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 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.668] 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 LiFIsxIcOOFr for ; Tue, 26 Aug 2014 11:45:40 -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 822881A0089 for ; Tue, 26 Aug 2014 11:45:40 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4600D82E12; Tue, 26 Aug 2014 14:45:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1409078739; bh=9GD0U2K60QUTIh/Eb1hMPvJEWU7o6hCOzzwpR6cmkho=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MopjNu0I5dXtqQFv7IcgF4bBN6/Hmhss5j4H6j/+TU/o9vUPFmshXT/rKv4dBpmDu 0KT+A7xkKMWgXAZxgGQqOI/PiPafki8E4EeGjIGlQtdPZNKh2UAc2ac4svxBLd20o6 he8dUQuFqo2jqcZjKy5Y/wLDYhiRftTLdsFwAgzI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7QIjdJS001009; Tue, 26 Aug 2014 14:45:39 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 26 Aug 2014 14:45:38 -0400 (EDT) From: Paul Wouters To: "Rose, Scott" In-Reply-To: <699D1F51-00F3-4DD4-9D62-2307DC3B4582@nist.gov> Message-ID: References: <699D1F51-00F3-4DD4-9D62-2307DC3B4582@nist.gov> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ldXIReMKpvNsn6OpAZYu-B7qTyQ Cc: dane WG list Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:45:42 -0000 On Tue, 26 Aug 2014, Rose, Scott wrote: > Noted - the requirements are for capabilities, so maybe "protocol" is a bad choice of words. This draft is to start to flesh out requirements and get the discussion going with the goal to improve the SMIMEA draft, or other drafts. So it is an smime-dane-usage draft? Similar to: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00 I'm not sure if this new document and that one should be merged or not. There will be similar concerns but also very different concerns. Paul From nobody Tue Aug 26 12:25: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 33C5F1A00DC for ; Tue, 26 Aug 2014 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 vZFuueUOCyq7 for ; Tue, 26 Aug 2014 12:25:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796861A01DC for ; Tue, 26 Aug 2014 12:25:49 -0700 (PDT) Received: from BLUPR09MB117.namprd09.prod.outlook.com (10.255.213.14) by BLUPR09MB118.namprd09.prod.outlook.com (10.255.213.141) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 26 Aug 2014 19:25:45 +0000 Received: from BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) by BLUPR09MB117.namprd09.prod.outlook.com ([10.255.213.14]) with mapi id 15.00.1015.018; Tue, 26 Aug 2014 19:25:44 +0000 From: "Rose, Scott" To: dane WG list Thread-Topic: [dane] S/MIME draft Thread-Index: AQHPwTzSp2zLy/0IwEiIGXszYmLFzpvjAIoAgAApbQCAAA9qAIAACzIA Date: Tue, 26 Aug 2014 19:25:44 +0000 Message-ID: References: <699D1F51-00F3-4DD4-9D62-2307DC3B4582@nist.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.6.140.6] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03152A99FF x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(199003)(189002)(24454002)(377454003)(85306004)(46102001)(64706001)(99396002)(74502001)(93886004)(107886001)(15202345003)(95666004)(33656002)(76482001)(50986999)(74662001)(31966008)(77982001)(4396001)(36756003)(21056001)(76176999)(83716003)(107046002)(54356999)(20776003)(79102001)(81342001)(99286002)(80022001)(106356001)(106116001)(81542001)(83322001)(87936001)(19580405001)(105586002)(19580395003)(92726001)(92566001)(86362001)(110136001)(85852003)(66066001)(90102001)(2656002)(15975445006)(101416001)(83072002)(82746002)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB118; H:BLUPR09MB117.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nJCPh5yMPRxAqoBeIHsynrYsP68 Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:25:51 -0000 On Aug 26, 2014, at 2:45 PM, Paul Wouters wrote: > On Tue, 26 Aug 2014, Rose, Scott wrote: >=20 >> Noted - the requirements are for capabilities, so maybe "protocol" is a = bad choice of words. This draft is to start to flesh out requirements and = get the discussion going with the goal to improve the SMIMEA draft, or othe= r drafts. >=20 > So it is an smime-dane-usage draft? Similar to: >=20 > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00 >=20 > I'm not sure if this new document and that one should be merged or not. > There will be similar concerns but also very different concerns. >=20 Possibly, but it would require some work. Or else there would be a SMIMEA = and SMIMEA-usage documents as the result. In effect, a mirror of the OPENP= GPKEY and its usage document pair. =20 Scott > Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Aug 26 14:03:19 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 04C001A8757 for ; Tue, 26 Aug 2014 14:03:18 -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 cjN94vJfpuJo for ; Tue, 26 Aug 2014 14:03:16 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB401A032F for ; Tue, 26 Aug 2014 14:03:15 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKU/z2Ep9nxdE9EdqfOBmfyoFfyAX9MVHm@postini.com; Tue, 26 Aug 2014 14:03:16 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s7QL3ESL018874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 17:03:14 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 26 Aug 2014 17:03:13 -0400 From: "Osterweil, Eric" To: Paul Hoffman Thread-Topic: [dane] S/MIME draft Thread-Index: AQHPwTzSp2zLy/0IwEiIGXszYmLFzg== Date: Tue, 26 Aug 2014 21:03:12 +0000 Message-ID: <02D9D8C9-E46E-4E79-ACB5-C80685F240C4@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_33D2B67B-BC42-41F7-90FE-0CF26EE1FC02"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yzOZhds_jblcqmhwO3zNf4HPtpU Cc: dane WG list Subject: Re: [dane] S/MIME draft X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:03:18 -0000 --Apple-Mail=_33D2B67B-BC42-41F7-90FE-0CF26EE1FC02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 26, 2014, at 11:41 AM, Paul Hoffman = wrote: > On Aug 26, 2014, at 7:48 AM, Osterweil, Eric = wrote: >=20 >> A few of us felt that it might be productive to outline a set of = requirements that we foresee DANE facing in enterprises environments = (w.r.t. encrypted/signed email). To that end, we put together the = draft: >> ``Enterprise Requirements for Secure Email Key Management'' >> = http://tools.ietf.org/html/draft-osterweil-dane-ent-email-reqs-00 >=20 > Although you are using DANE for that, the general topic is = email-end-to-end. You might therefore want to instead discuss the = principles on the "endymail" mailing list that Stephen Farrell just = announced yesterday on the SAAG list; see below. In addition to anywhere else that this topic resonates, I would say it's = important to couple this work with the S/MIME draft here in DANE. That = was the impetus for writing it. Eric= --Apple-Mail=_33D2B67B-BC42-41F7-90FE-0CF26EE1FC02 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7DCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggeEMIIGbKADAgECAhBcCMgDVFpl hwRR0TZyMUgoMA0GCSqGSIb3DQEBBQUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE0MDQxMDAwMDAwMFoXDTE1MDQxMDIzNTk1OVowczEmMCQGCSqGSIb3DQEJARYXZW9zdGVy d2VpbEB2ZXJpc2lnbi5jb20xGDAWBgNVBAMMD09zdGVyd2VpbCwgRXJpYzEWMBQGA1UECwwNRU5U RVJQUklTRSBJVDEXMBUGA1UECgwOVmVyaVNpZ24sIEluYy4wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCmK2/yLaprGu39usXztz6N7uLYDoKN4MNaDFGGj1eYfMkIfb6LDoYBs9qcnINg 8in4NxGwVQGIJU5AE/1wHe/V1qavpHEO2mVxRq94cBF0P8ETPpM1yhwBhU4QKhjNEDj9wov8RXzO hjqPy/uknZvBxfobQx22vhnEKpf7QEN0zfLDJON3tyYwsnrFZkmop4ni4ANI7ev5uqcI05ED7vSh K9AHAVjzjr2QvtmvqHAkOnpHgqkWJWhuw4f9Gx+8LmbC3tl8oxF7+E7WEwKTQG56BV0uR6PN/o0S O7VSbDCZyNoxxrjzw+CesWsigi2NvC5DnhkKlxP+JSfJxMDu+7MDAgMBAAGjggO7MIIDtzAMBgNV HRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAdBgNVHQ4E FgQUVoVKaC1xEPB9EWKq3dWrwskIufkwUAYDVR0RBEkwR4EXZW9zdGVyd2VpbEB2ZXJpc2lnbi5j b22gLAYKKwYBBAGCNxQCA6AeDBxlb3N0ZXJ3ZWlsQHZjb3JwLmFkLnZyc24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQUFAAOCAQEAXFTS ZEP9la6QYPlo6ybMEEpxVOADx082WRGtrYoU9ZEaC2IlxmwI9JprNfBlIy8FtyJAuWKBbe9/XKJF cukb2HNS0httHUIcSTfMEsAyc99/ba/SoMlhtvko/nCvx5brzhpQwop6AgMv9v5V7F1GUFO7db8L LSs1gIZYI8IeudznJOQGUBFGe0aJhA4cD/3OIZyItWpNtn94i1GJUFPMjYhGcy/r0fUQY/KFLwOi M6bT/m1RwAJKJI/mON/OshdzylAYqKOPoFTJD4qrbrpij1r1+e1VHKklAxTd+nOg9J1L0yRwlEDS 1boeOxqNXGnEYAa54k0ZWPh+8dFemteaLjGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgoMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDgyNjIxMDMxM1owIwYJKoZIhvcN AQkEMRYEFNb9lIEJYEhYxkmg2LwtOBnL3Ex5MIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEFwIyANUWmWHBFHRNnIxSCgwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBcCMgDVFplhwRR0TZyMUgo MA0GCSqGSIb3DQEBAQUABIIBACVA8neSa9gPVGgYXvrZhzjH/B0IyDqfsLZYcvF8AnNTCS90Bb6r CogBQH2bWYfyaMz+ImNiaJ9h+uOn2uenf0U5nmQODy9TCytjs5OXZARw/z1LyW3CgK11nlK/3ymL Ff2BICgI0DOIGqmbG7QLFSr3/o0eWwKrz9YYQBFwEJEgP3wYubHAmqXiP1vOMDTNIduZMCjScUxj 5Jk3KPu6mvE3y0Pkntw+agXSDCRRrajIfEqp8buErfcdDOe7RE49mW7vBkzc/Tzch4R3eyYNlmVK W+uj31j2idOPpTba1O5azA5X00NrKzj1zRSy1Z75hdO7orsIwgZi+96QVtVN+xQAAAAAAAA= --Apple-Mail=_33D2B67B-BC42-41F7-90FE-0CF26EE1FC02--