From nobody Mon May 5 22:15: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 259EE1A0717; Mon, 5 May 2014 22:15:13 -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 79ERzJFQKPnh; Mon, 5 May 2014 22:15:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6396D1A0718; Mon, 5 May 2014 22:15:11 -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.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140506051511.14938.42091.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 22:15:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/L5_VVgJewDspCktf4x4IRy_3Pcs Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-09.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 05:15:13 -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-09.txt Pages : 34 Date : 2014-05-05 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 5 22:33:46 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF63B1A0736 for ; Mon, 5 May 2014 22:33:44 -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 4LBRZv2N1laR for ; Mon, 5 May 2014 22:33:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 891AC1A0732 for ; Mon, 5 May 2014 22:33:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4C5E12AAA03; Tue, 6 May 2014 05:33:38 +0000 (UTC) Date: Tue, 6 May 2014 05:33:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140506053338.GX27883@mournblade.imrryr.org> References: <20140506051511.14938.42091.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140506051511.14938.42091.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/C60IypPzNwMT_f7w_uSDv9wnszk Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-09.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, 06 May 2014 05:33:45 -0000 On Mon, May 05, 2014 at 10:15:11PM -0700, internet-drafts@ietf.org wrote: > Title : SMTP security via opportunistic DANE TLS > Authors : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-09.txt > Pages : 34 > Date : 2014-05-05 Changes from -08: - Document organization feedback from Olafur. Some long sections broken up into smaller pieces, and some sub-sections promoted to top-level sections. - SMTP clients MAY elect to make use of TLSA records after "insecure" MX redirection, but MUST NOT misrepresent this as secure delivery. - Server logs SHOULD show the original (not CNAME expanded) MX hostname when the MX RRset is "insecure". Otherwise, redirection leading to downgrades may not be "tamper-evident". - SMTP clients MAY elect to make use of "insecure" TLSA records (typically resulting from "insecure" CNAME indirection from _port._tcp., as the zone containing is always signed when TLSA records are requested). Again, MUST NOT misrepresent resulting security. - Routine corrections already discussed, based on Tom Ritter's feedback. -- Viktor. From nobody Tue May 6 08:43:07 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 26BB21A0859 for ; Tue, 6 May 2014 08:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSINt0-E3jdU for ; Tue, 6 May 2014 08:43:02 -0700 (PDT) Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) by ietfa.amsl.com (Postfix) with ESMTP id 029DA1A0391 for ; Tue, 6 May 2014 08:43:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 921611A0423 for ; Tue, 6 May 2014 11:42:51 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 695CD1A0E7F for ; Tue, 6 May 2014 11:42:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20140506053338.GX27883@mournblade.imrryr.org> Date: Tue, 6 May 2014 11:42:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <94C1ABE6-E722-479B-9EA2-9586CA48C838@ogud.com> References: <20140506051511.14938.42091.idtracker@ietfa.amsl.com> <20140506053338.GX27883@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/YuBePWjQLr2TzqZhejjVEEXQTto Subject: [dane] DANE security models: Re: I-D Action: draft-ietf-dane-smtp-with-dane-09.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, 06 May 2014 15:43:05 -0000 Dear colleagues,=20 The mail exchanges on this draft and conversations with Victor have = brought up a new issue that we want to=20 highlight. (this message uses vocabulary from the dane-vocabulary draft)=20= Question: Are there more than one security models possible for = applications/protocols that use DANE ?=20 The original DANE/TLSA model in effect says "all records used for DANE = must be DNSSEC protected, both=20 actual records and DNS records used to get to those records."=20 The protocol we designed for HTTPS, unlike many other protocols uses = Address records as Service specification.=20 Protocols that use a different record (like MX or SRV) as a service = specification record now have 2 places to put=20 Authentication (TLSA) records.=20 SRV draft and SMTP drafts both say put Authentication records with = Address records, as that is better for operators.=20 The SRV and Vocabulary drafts both assume that both Service records and = Address records are secured if the=20 Authentication records are stored with Address records, (requiring = DNSSEC for all sets). The SMTP draft is proposing that it is ok to use TLSA records that are = stored with Address records even if the Service (MX) records are not signed.=20 Attempts to answer the question as what kind of security models can we = have with DANE?=20 Full: All records used to find service, address and = authentication are DNSSEC protected=20 Server only: Address and Authentication records are DNSSEC = protected=20 Service only: Service and Authentication records are protected = but not Address records Questions that need answers:=20 - What are the security implications of each model?=20 - What types of security does each model provide ?=20 - What is not possible with each model? - What threats does each model handle?=20 - any others?=20 Do we (as a WG) want to document these models formally and the = implications of each model operationally ?=20 Olafur & Warren=20 On May 6, 2014, at 1:33 AM, Viktor Dukhovni = wrote: > On Mon, May 05, 2014 at 10:15:11PM -0700, internet-drafts@ietf.org = wrote: >=20 >> Title : SMTP security via opportunistic DANE TLS >> Authors : Viktor Dukhovni >> Wes Hardaker >> Filename : draft-ietf-dane-smtp-with-dane-09.txt >> Pages : 34 >> Date : 2014-05-05 >=20 > Changes from -08: >=20 > - Document organization feedback from Olafur. Some long sections > broken up into smaller pieces, and some sub-sections promoted to > top-level sections. >=20 > - SMTP clients MAY elect to make use of TLSA records after = "insecure" > MX redirection, but MUST NOT misrepresent this as secure = delivery. >=20 > - Server logs SHOULD show the original (not CNAME expanded) MX = hostname > when the MX RRset is "insecure". Otherwise, redirection leading > to downgrades may not be "tamper-evident". >=20 > - SMTP clients MAY elect to make use of "insecure" TLSA records = (typically > resulting from "insecure" CNAME indirection from > _port._tcp., as the zone containing is > always signed when TLSA records are requested). Again, MUST NOT > misrepresent resulting security. >=20 > - Routine corrections already discussed, based on Tom Ritter's = feedback. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Tue May 6 09:44:49 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546711A0252 for ; Tue, 6 May 2014 09:44:45 -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 JRjKAs4F-1qI for ; Tue, 6 May 2014 09:44:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 552F01A0161 for ; Tue, 6 May 2014 09:44:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 78DB02AAA03; Tue, 6 May 2014 16:44:38 +0000 (UTC) Date: Tue, 6 May 2014 16:44:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140506164438.GZ27883@mournblade.imrryr.org> References: <20140506051511.14938.42091.idtracker@ietfa.amsl.com> <20140506053338.GX27883@mournblade.imrryr.org> <94C1ABE6-E722-479B-9EA2-9586CA48C838@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94C1ABE6-E722-479B-9EA2-9586CA48C838@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8ICOhZtghsj5Y8J6PI3WhI_wrrI Subject: Re: [dane] DANE security models: Re: I-D Action: draft-ietf-dane-smtp-with-dane-09.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, 06 May 2014 16:44:45 -0000 On Tue, May 06, 2014 at 11:42:55AM -0400, Olafur Gudmundsson wrote: > The SMTP draft is proposing that it is ok to use TLSA records that are > stored with Address records even if the Service (MX) records are not > signed. Note, this is predicated on the assumption that the client's security policy is "opportunistic", and that it is OK to send email in the clear or with unauthenticated TLS, when DANE is not employed. The draft also briefly touches on "mandatory DANE TLS", in which the sender demands strong transport protection for some destination domains. In that case, only "Full" below is acceptable. > Attempts to answer the question as what kind of security models can we > have with DANE? > > Full: All records used to find service, address and authentication > are DNSSEC protected > > Server only: Address and Authentication records are DNSSEC protected > > Service only: Service and Authentication records are protected > but not Address records > > Questions that need answers: > - What are the security implications of each model? > - What types of security does each model provide ? > - What is not possible with each model? > - What threats does each model handle? > - any others? So for me, the context in which this questions is set is whether the application security policy is mandatory (security expected) or opportunistic (no security expected, but opportunities for security on a peer-by-peer basis are not missed). Thus, I would suggest that the above 3-way choice is not at the right layer of the problem. The model is mandatory protection or opportunistic security, or ... which then leads one to make the appropriate choices. There are variations on the models: - Mandatory protection with DANE when available and PKIX as a fallback. (Works poorly with protocols that employ DNS SSRs, but is viable for protocols ala HTTPS). - Opportunistic DANE, with key-continuity protocols (authenticated pinning e.g. TACK, this also runs into difficulties with SSRs). - ... That said, the key dichotomy is I believe "mandatory" vs. "opportunistic" security. The discussion about "discovery" in London was in disguise a discussion about the admissibility of "opportunistic" uses of DANE, which need to "discover" peers that support DANE. We seem to have crossed that bridge without falling off, so now we can pay attention to each relevant model as further specifications are developed. > Do we (as a WG) want to document these models formally and the > implications of each model operationally ? I believe that opportunistic security models are going to be more important in IETF protocols (some of you may be keeping track of the lively discussion on the saag list). And thus it is not unreasonable to define "opportunistic DANE TLS" more broadly, with the SMTP draft a first step in that direction (a test case if you like). -- Viktor. From nobody Mon May 12 08:40:54 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 50B2F1A072D for ; Mon, 12 May 2014 08:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5b62NmXDwfF for ; Mon, 12 May 2014 08:40:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA5E1A0740 for ; Mon, 12 May 2014 08:40:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E34C72AB0B4; Mon, 12 May 2014 15:40:43 +0000 (UTC) Date: Mon, 12 May 2014 15:40:43 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140512154043.GB27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aEC_k9OtCWXFDZb_4qN0fg9aPY8 Subject: [dane] First ISP implements DANE TLSA support for SMTP X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 15:40:52 -0000 The German email provider, posteo.de, has published TLSA RRs for SMTP and also enabled DANE TLS verification outbound: http://www.heise.de/newsticker/meldung/Verschluesselter-Mail-Transport-Posteo-setzt-als-erster-Provider-DANE-ein-2187144.html $ dig +noall +comment +ans +ad -t mx posteo.de ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42574 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: posteo.de. IN MX 10 mx02.posteo.de. posteo.de. IN MX 20 mx01.posteo.de. $ dig +noall +comment +ans +ad -t TLSA _25._tcp.mx02.posteo.de ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42306 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: _25._tcp.mx02.posteo.de. IN TLSA 3 1 1 ( 1EE4C4318C1FA8D75AC0DF56755B30A2 F88DB7BFAC129A2C50F316A0C3B1E640 ) With any luck this week or next mail.ietf.org will also enable STARTTLS and have TLSA records published, enabling sending MTAs to verify ietf.org with DANE. Outbound DANE will be enabled later (pending a software refresh of the relevant servers). -- Viktor. From nobody Mon May 12 11:32: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 A06521A0785 for ; Mon, 12 May 2014 11:32:12 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6nSJ7h_x3vu for ; Mon, 12 May 2014 11:32:11 -0700 (PDT) Received: from smtp116.ord1c.emailsrvr.com (smtp116.ord1c.emailsrvr.com [108.166.43.116]) by ietfa.amsl.com (Postfix) with ESMTP id 2035C1A0728 for ; Mon, 12 May 2014 11:32:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 02F451B950F for ; Mon, 12 May 2014 14:32:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B943C1B97CE for ; Mon, 12 May 2014 14:32:04 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/mixed; boundary="Apple-Mail=_5A14FAC4-21E4-46FB-B0B1-6B166034499B" Message-Id: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> Date: Mon, 12 May 2014 14:32:05 -0400 To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rMwwH4ddNZCLdVU9uPXurlVL_Hw Subject: [dane] Draft charter 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, 12 May 2014 18:32:12 -0000 --Apple-Mail=_5A14FAC4-21E4-46FB-B0B1-6B166034499B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Colleagues=20 As the initial set of tasks set out in our original charter have been = either completed or discarded it is time to revisit the charter of the = working group. The chairs have been working with the AD's on a new charter, attached is = a draft for the new charter with milestones.=20 The goal is to complete the current set of documents this year, and next = year work on a revised RFC for DANE that will be published as Internet = standard.=20 There is lots of options in the proposed charter, some have milestones = some do not, when documents/tasks are adopted we will update milestones. If you have comments/suggestions on the draft charter please share them, = the plan is to submit the draft charter to the IESG early next week.=20 Olafur & Warren --Apple-Mail=_5A14FAC4-21E4-46FB-B0B1-6B166034499B Content-Disposition: attachment; filename=DANE-charter-2014-02.txt Content-Type: text/plain; name="DANE-charter-2014-02.txt" Content-Transfer-Encoding: quoted-printable Current Status: Active=0D =0D Chairs:=0D Warren Kumari=0D Olafur Gudmundsson=0D =0D Security Area Advisor:=0D Stephen Farrell=0D =0D Description of Working Group:=0D =0D Objective:=0D =0D The DANE WG will process documents that describe how to=0D incorporate DANE and DANE-like functionality in protocols, and=0D mechanisms to facilitate adoption of this functionality. The DANE=0D working group will also assist other working groups with adding=0D DANE functionality to their work. In addition the working group=0D will monitor and provide guidance to operators and tool developers.=0D= will monitor and provide guidance to operators and tool developers.=0D= When work on currently chartered documents is complete the WG=0D may re-charter if sufficiently pressing new work is identified.=0D DANE is not intended to be a long-lived catch-all WG=0D for all PKI in DNS issues and so will generally not adopt new=0D work items without re-chartering.=0D =0D Problem Statement:=0D =0D The DANE working group has developed a framework for securely=0D retrieving keying information from the DNS [RFC6698]. This=0D framework allows secure storing and looking up public key=0D information in the DNS. This provides a binding between a domain=0D name providing a particular service and the key that can be used=0D to establish encrypted connection to that service. =0D =0D By requiring DNSSEC protection for the lookup of the public key=0D information, DANE leverages the integrity protection provided by=0D DNSSEC to enable secure discovery of keying information. Operators=0D= wanting to take advantage of DANE for their services must turn on=0D DNSSEC signing on the zones used in finding the services. Using=0D DNS this way, bindings of keys to domains are asserted not by=0D external entities, but by the entities that operate the DNS. =0D =0D The DANE mechanisms provide flexibility in how the keying=0D information is presented. DANE supports both Certificates and raw=0D keys, further more Certificates and raw keys can be either the full=0D= key or a hash of the key. =0D The group will work on documenting the different approaches to use=0D= DANE keying, and the security implication of each. =0D =0D The group may also create documents that describe how protocol=0D entities can discover and validate these bindings in the execution=0D= of specific applications. This work would be done in coordination=0D with the IETF Working Groups responsible for the protocols. =0D =0D The group may in addition encourage interop testing and document=0D results of such testing. =0D =0D Goals and Milestones:=0D DONE - First WG draft of standards-track protocol for using DNS to = associate hosts with keys for TLS and DTLS=0D DONE - Protocol for using DNS to associate domain names with keys for = TLS and DTLS to IESG=0D Jun 2014 - Advance DANE SRV document to IESG=0D Jun 2014 - Advance DANE SMPT document to IESG=0D Aug 2014 - Advance DANE SMIME document to IESG=0D Aug 2014 - Advance DANE OPENPGP document to IESG=0D Sep 2014 - Advance DANE operational guidance document to IESG=0D Jan 2015 - Advance DANE security model document to IESG. =0D May 2015 - Advance DANE IPSEC document to IESG=0D Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard=0D= Nov 2015 - Recharter or close down =0D --Apple-Mail=_5A14FAC4-21E4-46FB-B0B1-6B166034499B-- From nobody Mon May 12 12:27:26 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3811A07CF for ; Mon, 12 May 2014 12:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzwWMmx_dVfp for ; Mon, 12 May 2014 12:27:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8561A1A07D2 for ; Mon, 12 May 2014 12:27:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0080E2AB0B4; Mon, 12 May 2014 19:27:14 +0000 (UTC) Date: Mon, 12 May 2014 19:27:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140512192714.GI27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-hjjq4g9agzTcQfrMFOd6Ihx6rA Subject: Re: [dane] Draft charter 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, 12 May 2014 19:27:24 -0000 On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote: > Objective: > > ... > DANE functionality to their work. In addition the working group > will monitor and provide guidance to operators and tool developers. > will monitor and provide guidance to operators and tool developers. The above is a duplicate line. > The DANE working group has developed a framework for securely > retrieving keying information from the DNS [RFC6698]. This > framework allows secure storing and looking up public key > information in the DNS. This provides a binding between a domain > name providing a particular service and the key that can be used > to establish encrypted connection to that service. [ The below thoughts are likely too specific to rise to visibility in the charter, so are more likely fodder for 6698 revisions. ] The RFC6698-specified lookup key of _._. is not universally applicable. It works OK for well known services such as SMTP on ports 25/587 or HTTPS on 443, but is not always well suited to environments in which service ports are dynamically registered. Also, sometimes the verifier wants to authenticate a TLS client acting on behalf of some domain in an appropriate capacity. Applications will in some use-cases need to agree on a lookup key that is not tied to a numeric port. It could be a service name or a client role. While a generic DANE TLS RFC (e.g. 6698) cannot anticipate or standardize such alternative lookup keys, a future update to 6698 should I think mention the need for such bindings, and encourage applications employing DANE TLSA to define appropriate alternative lookup keys. This could be of immediate benefit in XMPP to authenticate the origin of inbound traffic. It may also be reasonable to encourage applications to choose either PKIX-TA/PKIX-EE or DANE-TA/DANE-EE whichever is more appropriate to the problem at hand. Mixing the two yields the union of the interoperability problems and the intersection of the security features. -- Viktor. From nobody Mon May 12 13:21: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 C2C601A0771 for ; Mon, 12 May 2014 13:21:19 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlX5oKHoWilB for ; Mon, 12 May 2014 13:21:18 -0700 (PDT) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19E1A076E for ; Mon, 12 May 2014 13:21:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 20E81515F1 for ; Mon, 12 May 2014 16:21:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D06FD51627 for ; Mon, 12 May 2014 16:21:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20140512192714.GI27883@mournblade.imrryr.org> Date: Mon, 12 May 2014 16:21:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TsqVpRP6zO0gdaEh4cWVtDhyNoI Subject: Re: [dane] Draft charter 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, 12 May 2014 20:21:20 -0000 Thank you Victor=20 On May 12, 2014, at 3:27 PM, Viktor Dukhovni = wrote: > On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote: >=20 >> Objective: >>=20 >> ... >> DANE functionality to their work. In addition the working group >> will monitor and provide guidance to operators and tool = developers. >> will monitor and provide guidance to operators and tool = developers. >=20 > The above is a duplicate line. Fixed in version 03 to be posted soon=20 >=20 >> The DANE working group has developed a framework for securely >> retrieving keying information from the DNS [RFC6698]. This >> framework allows secure storing and looking up public key >> information in the DNS. This provides a binding between a domain >> name providing a particular service and the key that can be used >> to establish encrypted connection to that service. =20 >=20 > [ The below thoughts are likely too specific to rise to visibility > in the charter, so are more likely fodder for 6698 revisions. ] >=20 > The RFC6698-specified lookup key of _._. is not > universally applicable. It works OK for well known services such > as SMTP on ports 25/587 or HTTPS on 443, but is not always well > suited to environments in which service ports are dynamically > registered. Also, sometimes the verifier wants to authenticate a > TLS client acting on behalf of some domain in an appropriate > capacity. >=20 This also works well for services looked up via SRV records.=20 As the SRV contains the port number.=20 For a protocol that has some kind of other selector of port, still at = the end of the day the "Server" side has a "known-port" to the client, if the service moves = from one port to another port OR provides service on multiple ports then it is possible that the protocol = definition for the DANE variant of that protocol can say lookup of Authentication records is FP at hostname.=20 > Applications will in some use-cases need to agree on a lookup key > that is not tied to a numeric port. It could be a service name or > a client role. While a generic DANE TLS RFC (e.g. 6698) cannot > anticipate or standardize such alternative lookup keys, a future > update to 6698 should I think mention the need for such bindings, > and encourage applications employing DANE TLSA to define appropriate > alternative lookup keys. This could be of immediate benefit in > XMPP to authenticate the origin of inbound traffic. >=20 Interesting are you you are saying we want to examine/specify client = side DANE=20 records (right now DANE is all about server side records).=20 > It may also be reasonable to encourage applications to choose either > PKIX-TA/PKIX-EE or DANE-TA/DANE-EE whichever is more appropriate > to the problem at hand. Mixing the two yields the union of the > interoperability problems and the intersection of the security > features. >=20 Are you proposing a BCP ?=20 we can add that to the milestones, after the current Operational/Errata = document is done.=20 Olafur From nobody Mon May 12 13:43:07 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 7A0EC1A0771 for ; Mon, 12 May 2014 13:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGHm-zOt9LFc for ; Mon, 12 May 2014 13:43:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8C1A033A for ; Mon, 12 May 2014 13:43:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 146FE2AB10A; Mon, 12 May 2014 20:42:56 +0000 (UTC) Date: Mon, 12 May 2014 20:42:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140512204256.GK27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5KBjED38uJwDOzzNPRFC-hF_GMU Subject: Re: [dane] Draft charter 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, 12 May 2014 20:43:04 -0000 On Mon, May 12, 2014 at 04:21:10PM -0400, Olafur Gudmundsson wrote: > > The RFC6698-specified lookup key of _._. is not > > universally applicable. It works OK for well known services such > > as SMTP on ports 25/587 or HTTPS on 443, but is not always well > > suited to environments in which service ports are dynamically > > registered. Also, sometimes the verifier wants to authenticate a > > TLS client acting on behalf of some domain in an appropriate > > capacity. > > This also works well for services looked up via SRV records. > As the SRV contains the port number. > For a protocol that has some kind of other selector of port, > still at the end of the day the "Server" side has a "known-port" > to the client, if the service moves from one port to another port OR > provides service on multiple ports then it is possible that the > protocol definition for the DANE variant of that protocol can say > lookup of Authentication records is FP at hostname. I am mostly pointing out that port is not universally the right choice. Sometimes a service name or other identifier is more appropriate, whether this is the case, or what might be a better lookup key is application dependent. One immediate conclusion is that TLS + DANE toolkits (OpenSSL, GnuTLS, NSS) must not hard-code the mapping from (host, port) to the corresponding TLSA RRset. There need to be multiple ways to get a DANE TLSA authenticated connection, with the application able to perform the TLSA lookup outside the library, or able to pass-in a custom lookup domain and TLSA base domain... > > Applications will in some use-cases need to agree on a lookup key > > that is not tied to a numeric port. It could be a service name or > > a client role. While a generic DANE TLS RFC (e.g. 6698) cannot > > anticipate or standardize such alternative lookup keys, a future > > update to 6698 should I think mention the need for such bindings, > > and encourage applications employing DANE TLSA to define appropriate > > alternative lookup keys. This could be of immediate benefit in > > XMPP to authenticate the origin of inbound traffic. > > Interesting are you you are saying we want to examine/specify > client side DANE records (right now DANE is all about server side records). Yes, but we likely can't specify the lookup keys in an application neutral manner. Rather we can discuss the problem generally, and allow individual application protocols to construct appropriate keys. Still there could be some guidance on how to apply DANE to TLS client identity (when the client identity can be mapped to a suitable name in DNS). > > It may also be reasonable to encourage applications to choose either > > PKIX-TA/PKIX-EE or DANE-TA/DANE-EE whichever is more appropriate > > to the problem at hand. Mixing the two yields the union of the > > interoperability problems and the intersection of the security > > features. > > Are you proposing a BCP? > > We can add that to the milestones, after the current Operational/Errata > document is done. Yeah, something like that, or merge this into the ops draft. -- Viktor. From nobody Mon May 12 13:47:07 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 18A351A077F for ; Mon, 12 May 2014 13:47:05 -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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, 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 Y8NqP02Hddbl for ; Mon, 12 May 2014 13:47:02 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) by ietfa.amsl.com (Postfix) with ESMTP id 495481A077A for ; Mon, 12 May 2014 13:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1399927808; x=1401742209; bh=gRWAZTxI+rqd4jUqgpd3Sz05vxE7duwY38n Dqxrirdw=; b=xsVd4KPI7sauAZg9VgpfzMmaHmHmSieSDkCzHBlkk02u+8/Q1fD l0sb1E70tjR0Alkyw3SjfU4+R8luvOmN/0oNr7grfno2G1bMobCdnKXEGC65LdSv wUCkIGtuAwS5LSgpBZ+NMFyzSntqwHWWfsHQ/tPw45F1NqJRAPPLMUDrYQEYpoEl I6Bzc3HyOtc26D2c2Wq7igiHx4fQBXcbY8o2qLX/klrg9REE7fdad8U/wmOuFtPY hVWTFR8J62ghPMsDjeV+wRet9Re8gsg2Jyg7aUyjEhdTOaMgOttC+Q1kFmJ2AbwO U/APbjf6YnS0XMEUjHWISBdW0E+RQ/jnCLA== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (178-27-27-26-dynip.superkabel.de [178.27.27.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3gSDmc0DYsz3qL for ; Mon, 12 May 2014 22:50:08 +0200 (CEST) Date: Mon, 12 May 2014 22:46:53 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20140512204653.GL24708@sys4.de> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/g1Jj8NQNVyyouI6ni8wBwWoXD3I Subject: Re: [dane] Draft charter 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, 12 May 2014 20:47:05 -0000 * Olafur Gudmundsson : > Thank you Victor > > On May 12, 2014, at 3:27 PM, Viktor Dukhovni wrote: > > > On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote: > > > >> Objective: > >> > >> ... > >> DANE functionality to their work. In addition the working group > >> will monitor and provide guidance to operators and tool developers. > >> will monitor and provide guidance to operators and tool developers. > > > > The above is a duplicate line. > > Fixed in version 03 to be posted soon > > > > >> The DANE working group has developed a framework for securely > >> retrieving keying information from the DNS [RFC6698]. This > >> framework allows secure storing and looking up public key > >> information in the DNS. This provides a binding between a domain > >> name providing a particular service and the key that can be used > >> to establish encrypted connection to that service. > > > > [ The below thoughts are likely too specific to rise to visibility > > in the charter, so are more likely fodder for 6698 revisions. ] > > > > The RFC6698-specified lookup key of _._. is not > > universally applicable. It works OK for well known services such > > as SMTP on ports 25/587 or HTTPS on 443, but is not always well > > suited to environments in which service ports are dynamically > > registered. Also, sometimes the verifier wants to authenticate a > > TLS client acting on behalf of some domain in an appropriate > > capacity. > > > This also works well for services looked up via SRV records. > As the SRV contains the port number. > For a protocol that has some kind of other selector of port, still at the end of the day > the "Server" side has a "known-port" to the client, if the service moves from one port to another port OR > provides service on multiple ports then it is possible that the protocol definition for the DANE variant of that protocol can say > lookup of Authentication records is FP at hostname. > > > Applications will in some use-cases need to agree on a lookup key > > that is not tied to a numeric port. It could be a service name or > > a client role. While a generic DANE TLS RFC (e.g. 6698) cannot > > anticipate or standardize such alternative lookup keys, a future > > update to 6698 should I think mention the need for such bindings, > > and encourage applications employing DANE TLSA to define appropriate > > alternative lookup keys. This could be of immediate benefit in > > XMPP to authenticate the origin of inbound traffic. > > > > Interesting are you you are saying we want to examine/specify client side DANE > records (right now DANE is all about server side records). I suggested that once to Viktor in an offlist mail, because I think a Receiver might also want to know, which Sender it talks to. Thesis: If I were a company to whom suppliers deliver work via email, I'd like to ensure its really them and not someome else, who sends me the production plan for some vital component. BTW: We run a mail gateway for suppliers who must deliver their work via TLS to their customers. The only way to enforce that is setting a policy on the sending side. I'd find a policy on the receiving side that incorporates DANE (if you can do it I require you to use it) attractive. Also for e.g. banks that need to exchange data between themselves. If encryption is vital there should be a mutual encryption policy. Each side should be able to enforce a policy that requires the other party to use encryption or transport will be rejected. +1 from my side if that helps to examine the usefulness of client side DANE. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Mon May 12 14:01: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 C40FF1A0772 for ; Mon, 12 May 2014 14:01:19 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq98S0NX5OYT for ; Mon, 12 May 2014 14:01:17 -0700 (PDT) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4681A0771 for ; Mon, 12 May 2014 14:01:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7245950F88; Mon, 12 May 2014 17:01:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1EFEB51099; Mon, 12 May 2014 17:01:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20140512204653.GL24708@sys4.de> Date: Mon, 12 May 2014 17:01:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0FA0ED5A-81A4-46B4-BFF2-F2ED27827533@ogud.com> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204653.GL24708@sys4.de> To: Patrick Ben Koetter X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/yRtNDAItIwp5jD4-ke28blBqoO4 Cc: dane@ietf.org Subject: Re: [dane] Draft charter 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, 12 May 2014 21:01:20 -0000 On May 12, 2014, at 4:46 PM, Patrick Ben Koetter wrote: > * Olafur Gudmundsson : >> Thank you Victor=20 >>=20 >> On May 12, 2014, at 3:27 PM, Viktor Dukhovni = wrote: >>=20 >>> On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote: >>>=20 >>>> Objective: >>>>=20 >>>> ... >>>> DANE functionality to their work. In addition the working group >>>> will monitor and provide guidance to operators and tool = developers. >>>> will monitor and provide guidance to operators and tool = developers. >>>=20 >>> The above is a duplicate line. >>=20 >> Fixed in version 03 to be posted soon=20 >>=20 >>>=20 >>>> The DANE working group has developed a framework for securely >>>> retrieving keying information from the DNS [RFC6698]. This >>>> framework allows secure storing and looking up public key >>>> information in the DNS. This provides a binding between a domain >>>> name providing a particular service and the key that can be used >>>> to establish encrypted connection to that service. =20 >>>=20 >>> [ The below thoughts are likely too specific to rise to visibility >>> in the charter, so are more likely fodder for 6698 revisions. ] >>>=20 >>> The RFC6698-specified lookup key of _._. is not >>> universally applicable. It works OK for well known services such >>> as SMTP on ports 25/587 or HTTPS on 443, but is not always well >>> suited to environments in which service ports are dynamically >>> registered. Also, sometimes the verifier wants to authenticate a >>> TLS client acting on behalf of some domain in an appropriate >>> capacity. >>>=20 >> This also works well for services looked up via SRV records.=20 >> As the SRV contains the port number.=20 >> For a protocol that has some kind of other selector of port, still at = the end of the day >> the "Server" side has a "known-port" to the client, if the service = moves from one port to another port OR >> provides service on multiple ports then it is possible that the = protocol definition for the DANE variant of that protocol can say >> lookup of Authentication records is FP at hostname.=20 >>=20 >>> Applications will in some use-cases need to agree on a lookup key >>> that is not tied to a numeric port. It could be a service name or >>> a client role. While a generic DANE TLS RFC (e.g. 6698) cannot >>> anticipate or standardize such alternative lookup keys, a future >>> update to 6698 should I think mention the need for such bindings, >>> and encourage applications employing DANE TLSA to define appropriate >>> alternative lookup keys. This could be of immediate benefit in >>> XMPP to authenticate the origin of inbound traffic. >>>=20 >>=20 >> Interesting are you you are saying we want to examine/specify client = side DANE=20 >> records (right now DANE is all about server side records).=20 >=20 > I suggested that once to Viktor in an offlist mail, because I think a = Receiver > might also want to know, which Sender it talks to. >=20 > Thesis: If I were a company to whom suppliers deliver work via email, = I'd like > to ensure its really them and not someome else, who sends me the = production > plan for some vital component. >=20 > BTW: We run a mail gateway for suppliers who must deliver their work = via TLS > to their customers. The only way to enforce that is setting a policy = on the > sending side. I'd find a policy on the receiving side that = incorporates DANE > (if you can do it I require you to use it) attractive. >=20 > Also for e.g. banks that need to exchange data between themselves. If > encryption is vital there should be a mutual encryption policy. Each = side > should be able to enforce a policy that requires the other party to = use > encryption or transport will be rejected. >=20 > +1 from my side if that helps to examine the usefulness of client side = DANE. >=20 > p@rick >=20 Patrick,=20 This is real good input thank you for posting this.=20 I'm willing to add text to the charter to address this,=20 at the end of paragraph #3:=20 "In addition the WG may develop a framework to look up "client" side = DANE records for authorization/authentication purposes." (will finalize after more feedback and talking to Warren)=20 Olafur From nobody Mon May 12 23:17: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 8A0BC1A0844 for ; Mon, 12 May 2014 23:17:39 -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 06-xnI5dErIM for ; Mon, 12 May 2014 23:17:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E40F01A0843 for ; Mon, 12 May 2014 23:17:35 -0700 (PDT) Received: from [192.168.40.20] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B3CEA93C1AF; Tue, 13 May 2014 06:17:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <20140512204256.GK27883@mournblade.imrryr.org> Date: Tue, 13 May 2014 08:17:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/q9jWifLmuXxx2uagspb3eTw52yo Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 06:17:39 -0000 On 12 May 2014, at 22:42, Viktor Dukhovni = wrote: >> Interesting are you you are saying we want to examine/specify >> client side DANE records (right now DANE is all about server side = records).=20 >=20 > Yes, but we likely can't specify the lookup keys in an application > neutral manner. Rather we can discuss the problem generally, and > allow individual application protocols to construct appropriate > keys. Still there could be some guidance on how to apply DANE to > TLS client identity (when the client identity can be mapped to a > suitable name in DNS). That is something that also applies to SIP, where we have an RFC about connection reuse in SIP/TLS. For server to server connections it is important to be able to verify a list of domains each side is authorized to use. Today we do this with a long list of domains in = SAN, but since my DANE/SIP draft removes that list for server certificates, we are now in a situation where client certs use SAN and the server, if using DANE, does not.=20 The question it then boils down to is how I verify an incoming = connection from an IP address with a name. Maybe a DNSsec-secured reverse lookup is a starting point. What's the state of DNSsec in .arpa ? /O= From nobody Tue May 13 04:48: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 279341A007E for ; Tue, 13 May 2014 04:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.651, 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 BTgF99YTaluL for ; Tue, 13 May 2014 04:48:31 -0700 (PDT) Received: from mail.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) by ietfa.amsl.com (Postfix) with ESMTP id 6A46F1A008A for ; Tue, 13 May 2014 04:48:31 -0700 (PDT) Received: from [IPv6:2001:16d8:ffc6:0:d24:5f4f:5f94:adc9] (unknown [IPv6:2001:16d8:ffc6:0:d24:5f4f:5f94:adc9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 5F87260097 for ; Tue, 13 May 2014 13:48:20 +0200 (CEST) Message-ID: <5372067E.6000701@zash.se> Date: Tue, 13 May 2014 13:48:14 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BjRLN0AdFxTAlA0lODhIm000851Jv9gWv" Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wYzFbdi49Ib51-UX7AUKNzFZugQ Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 11:48:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BjRLN0AdFxTAlA0lODhIm000851Jv9gWv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-05-13 08:17, Olle E. Johansson wrote: >=20 > On 12 May 2014, at 22:42, Viktor Dukhovni wr= ote: >=20 >>> Interesting are you you are saying we want to examine/specify >>> client side DANE records (right now DANE is all about server side rec= ords).=20 >> >> Yes, but we likely can't specify the lookup keys in an application >> neutral manner. Rather we can discuss the problem generally, and >> allow individual application protocols to construct appropriate >> keys. Still there could be some guidance on how to apply DANE to >> TLS client identity (when the client identity can be mapped to a >> suitable name in DNS). >=20 > That is something that also applies to SIP, where we have an RFC > about connection reuse in SIP/TLS. For server to server connections > it is important to be able to verify a list of domains each side > is authorized to use. This problem applies to XMPP as well. > The question it then boils down to is how I verify an incoming connecti= on > from an IP address with a name. Maybe a DNSsec-secured reverse lookup > is a starting point. What's the state of DNSsec in .arpa ? Doing a full forward SRV lookup and TLSA lookups on each _port._proto.srv-target is another possibility, but it may get awkward for clustered services where incoming and outgoing connections are handled by different servers. -- Kim "Zash" Alvefur --BjRLN0AdFxTAlA0lODhIm000851Jv9gWv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTcgZ+AAoJEK3tmne2etMphicP/3Q8oLgFf7a8ldbUuV7r7qVz Z6gRHU0o7gS5JSxEcuR0lj4lScLY+60Q/w/Wak8bOrV2hxTBBup1a/aXQRVeFnUn 9CiQaity/0y/2oG+aoOMFVKBzKq9kMIVNaprr0NrKrf9fTU6EBcWhjc1K+RAnUC3 LrddhqvGS3LqzrEcni7Glp5ueeP86FCDZ1odEycaFtKm2/dBtQwtXQYbuYi5Q+gU UgW6xML9k7d7lh9+afOC5I6c1FksSfB3EU+7zaRiX8jzz5si56uQbdA5hWs1NHrz R6sZ6CermJjvxCYB1+tHSuEhUUfrexGhvFTGygQsGy+Wwj/7XzqF4t1l/Vcq0Pj5 70Ir2dvskJXgRWUHU4qqZU5zACTcT2moV8RD8hdKydHzOsGbebuYT6uNYc8y7lC9 mVw37pIeR98bk7E9SSgSASEaJr7Pjl5dzomIrngAIPZJHYbNIU36pcLsKjiNuaA9 2yTbNkUEtTD0PFIyi3l6WHQauzys3dnZTN6+gCYnoooIK2Sjk90dPXyjtKPwfhWx LHHwCWzB7X+dzQ8xOHCIiBl6d+KqH3M3hm8jtwseKCZ1yc/2BvVRxYJWSDR/OmXi vzgoG/7v5yyEHth0THmRByUU9kilixG6s37PLQmMuoJvDaPAYHz6kKQX5x6n+AzK kplUrRt747lpxw/g/Dqq =73Yu -----END PGP SIGNATURE----- --BjRLN0AdFxTAlA0lODhIm000851Jv9gWv-- From nobody Tue May 13 06:52:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77891A00D7 for ; Tue, 13 May 2014 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, USER_IN_WHITELIST=-100] 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 pId4E2PPqMHn for ; Tue, 13 May 2014 06:52:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD481A0096 for ; Tue, 13 May 2014 06:52:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EBBF62AB0DD; Tue, 13 May 2014 13:52:04 +0000 (UTC) Date: Tue, 13 May 2014 13:52:04 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140513135204.GP27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VwaCpPVWBLdNi4CLEb8xAN5YXe8 Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 13:52:14 -0000 On Tue, May 13, 2014 at 08:17:27AM +0200, Olle E. Johansson wrote: > > Yes, but we likely can't specify the lookup keys in an application > > neutral manner. Rather we can discuss the problem generally, and > > allow individual application protocols to construct appropriate > > keys. Still there could be some guidance on how to apply DANE to > > TLS client identity (when the client identity can be mapped to a > > suitable name in DNS). > > That is something that also applies to SIP, where we have an RFC > about connection reuse in SIP/TLS. For server to server connections > it is important to be able to verify a list of domains each side > is authorized to use. Today we do this with a long list of domains in SAN, > but since my DANE/SIP draft removes that list for server certificates, > we are now in a situation where client certs use SAN and the server, > if using DANE, does not. > > The question it then boils down to is how I verify an incoming connection > from an IP address with a name. Maybe a DNSsec-secured reverse lookup > is a starting point. What's the state of DNSsec in .arpa ? IP addresses are a terrible identity lookup key, they are often dynamically assigned, and even when static often controlled by a different organization than the one actually operating the host. My thinking on client authentication with DANE is that it works best when the client represents that is acting as or on behalf of some domain, and when associated TLSA records are present (lookup key TBD) authenticates the legitimacy of the client. For example, with SMTP, clients impute a hostname with EHLO: S: 220 s.example ESMTP C: EHLO c.example the server might then perform a lookup (work-around: only if "c.example IN A ?" returns a validated response, possibly validated NXDOMAIN or empty): _clientauth.c.example. IN TLSA ? if this yields secure TLSA records, the server requires that the client presents a matching certificate and infers a secure client identity. So for server-to-server, SIP the question I would ask is whether the application protocol carries some sort of client domain assertion? If SIP is wrapped in SSL (no STARTTLS unlike SMTP, IMAP, ...) then the server would always solicit client certs, just in-case, and verify them once the client indicates its domain in the application protocol. -- Viktor. From nobody Tue May 13 07:21: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 A5A3A1A00A8 for ; Tue, 13 May 2014 07:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, RP_MATCHES_RCVD=-0.651, 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 04ayHCUxTmni for ; Tue, 13 May 2014 07:21:46 -0700 (PDT) Received: from mail.sys4.de (mail.sys4.de [IPv6:2001:1578:400:111::7]) by ietfa.amsl.com (Postfix) with ESMTP id 67AC11A00A5 for ; Tue, 13 May 2014 07:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= in-reply-to:content-transfer-encoding:content-disposition :content-type:content-type:mime-version:references:message-id :subject:subject:from:from:date:date; s=mail201310; t= 1399990898; x=1401805299; bh=3uAeAVniVcuGtTtUpZ+xDLO5PGmda9SX5Om bvNXcWSU=; b=EriPgxfGnyk7WK5oHuTo3feR4Jz66nT3XOGjv5sIzQ4n4CgqOmw /bguBFLg3L3/6+c7LC10uGXJTgK9fZVECbEVmdNlYq6k4jUMibHci2vk8Rwo96et gOwPPfUD1heH1QhXSXgVk86lH22O1Lh9NX4b/17Wam4hzpDsNbWSIje6TgWulBYm QzfZ1uId3uvi4rSTawhccMPM9tB+C1lqFKZWt7s0KUEC4+IyifJKaODV2Mi9rBpL j7lfqRuhwOzbWM4bpY+iJIWT54fFpFswpZgbEftXviNgJ72VumpB54FksqjWWsCs 1jqLTUM/LVPV4DUNGTh8lwngqba1+lIFiTQ== X-Virus-Scanned: Debian amavisd-new at mail.sys4.de Received: from sys4.de (ppp-188-174-167-115.dynamic.mnet-online.de [188.174.167.115]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3gSh5t0TlpzNm for ; Tue, 13 May 2014 16:21:38 +0200 (CEST) Date: Tue, 13 May 2014 16:21:36 +0200 From: Patrick Ben Koetter To: dane@ietf.org Message-ID: <20140513142136.GK29175@sys4.de> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140513135204.GP27883@mournblade.imrryr.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Qny8MyZz7O4snUXoUHxSsr9SqUI Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 14:21:47 -0000 * Viktor Dukhovni : > On Tue, May 13, 2014 at 08:17:27AM +0200, Olle E. Johansson wrote: > > > > Yes, but we likely can't specify the lookup keys in an application > > > neutral manner. Rather we can discuss the problem generally, and > > > allow individual application protocols to construct appropriate > > > keys. Still there could be some guidance on how to apply DANE to > > > TLS client identity (when the client identity can be mapped to a > > > suitable name in DNS). > > > > That is something that also applies to SIP, where we have an RFC > > about connection reuse in SIP/TLS. For server to server connections > > it is important to be able to verify a list of domains each side > > is authorized to use. Today we do this with a long list of domains in SAN, > > but since my DANE/SIP draft removes that list for server certificates, > > we are now in a situation where client certs use SAN and the server, > > if using DANE, does not. > > > > The question it then boils down to is how I verify an incoming connection > > from an IP address with a name. Maybe a DNSsec-secured reverse lookup > > is a starting point. What's the state of DNSsec in .arpa ? > > IP addresses are a terrible identity lookup key, they are often > dynamically assigned, and even when static often controlled by a > different organization than the one actually operating the host. ACK > My thinking on client authentication with DANE is that it works > best when the client represents that is acting as or on behalf of > some domain, and when associated TLSA records are present (lookup > key TBD) authenticates the legitimacy of the client. > > For example, with SMTP, clients impute a hostname with EHLO: > > S: 220 s.example ESMTP > C: EHLO c.example > > the server might then perform a lookup (work-around: only if > "c.example IN A ?" returns a validated response, possibly > validated NXDOMAIN or empty): > > _clientauth.c.example. IN TLSA ? > > if this yields secure TLSA records, the server requires that the > client presents a matching certificate and infers a secure client > identity. Sidenote: Ask for client certificate only if TLSA is present? I like that. This would safe us interop errors from clients that can't handle being asked for a client certificate. p@rick > So for server-to-server, SIP the question I would ask is whether > the application protocol carries some sort of client domain assertion? > > If SIP is wrapped in SSL (no STARTTLS unlike SMTP, IMAP, ...) then > the server would always solicit client certs, just in-case, and > verify them once the client indicates its domain in the application > protocol. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein From nobody Tue May 13 09:59: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 B54AF1A0158 for ; Tue, 13 May 2014 09:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 IrW-P0kSWfrl for ; Tue, 13 May 2014 09:59:06 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5F51A0107 for ; Tue, 13 May 2014 09:59:06 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 543E01E3AF; Tue, 13 May 2014 16:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1400000337; bh=BM/1xyblOMCeWtQ2ou6ScueFeXgFyEkB2g45x4sXQfI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z9myc/Q7s697xDkTlpHvMJSpEUgqo0EqBaX0680cB6nUkpldV2r2uQu4J/EJbBy/g XTEuJOfvaq7NTvUw/ey0DQM6x40K97F0ivgqpWKGD/CwSQObqNSXNcWTR4f7eJcNuv C2/FCJ/LMZc/rezI2i4GcMdzdfuyRx53cCBhmoaE= Received: by carbon.jhcloos.org (Postfix, from userid 500) id CF6F36001E; Tue, 13 May 2014 16:51:25 +0000 (UTC) From: James Cloos To: Olafur Gudmundsson In-Reply-To: <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> (Olafur Gudmundsson's message of "Mon, 12 May 2014 16:21:10 -0400") References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 13 May 2014 12:51:25 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140513:ogud@ogud.com::PDnMSEmsZEf7aTbO:000eDhDA X-Hashcash: 1:30:140513:dane@ietf.org::b4G3UFyU/+CELqjM:000yK8hm Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1Sq4TwCsS7Q6sLrj7bDFZe9rNC4 Cc: dane@ietf.org Subject: Re: [dane] Draft charter 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, 13 May 2014 16:59:07 -0000 >>>>> "OG" == Olafur Gudmundsson writes: OG> Interesting are you you are saying we want to examine/specify client OG> side DANE records (right now DANE is all about server side records). We should find a way to do client RRs. The charter should reflect that. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue May 13 10:01: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 5DAAA1A011E for ; Tue, 13 May 2014 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 YXiqQYInN8LN for ; Tue, 13 May 2014 10:01:39 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCA21A0127 for ; Tue, 13 May 2014 10:01:33 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 900C71E6FC; Tue, 13 May 2014 17:01:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1400000486; bh=cJTZNDa6ajFIb+51pqZABpIJB7BQVd/VLih7WvmlNDU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=abPW3qRrBU86E267MXY7ZaQiJoIrz3tvr6L2Po/MhVjkQf6H2n738keUFPYQrmwaZ Y408QPubxUMHgsnLYFil+pluFDRtkdaRmwtcTr5aKKJV814XL8q3I9VVMzh1Tdv2Vy szCWEgKAtpK4gRz700zTZQIhTop4Ss240KRLB/NM= Received: by carbon.jhcloos.org (Postfix, from userid 500) id AF6346001E; Tue, 13 May 2014 16:59:25 +0000 (UTC) From: James Cloos To: Patrick Ben Koetter In-Reply-To: <20140513142136.GK29175@sys4.de> (Patrick Ben Koetter's message of "Tue, 13 May 2014 16:21:36 +0200") References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> <20140513142136.GK29175@sys4.de> 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, 13 May 2014 12:59:25 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140513:p@sys4.de::roy98b3WTIBp/7Ip:0000000Pvay6 X-Hashcash: 1:30:140513:dane@ietf.org::csY4RS2MLtDRNxJu:0009KiXw Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uj8sYYzfEWDJEpeXx7GM_nwJo08 Cc: dane@ietf.org Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 17:01:40 -0000 >>>>> "PBK" == Patrick Ben Koetter writes: PBK> Sidenote: Ask for client certificate only if TLSA is present? I PBK> like that. This would safe us interop errors from clients that PBK> can't handle being asked for a client certificate. I like that, too, as an option. But asking every client also should be possible. Admin's choice. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue May 13 10:03:32 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 A41941A013E for ; Tue, 13 May 2014 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 WOVjLMy48xIK for ; Tue, 13 May 2014 10:03:26 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0891A0127 for ; Tue, 13 May 2014 10:03:26 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 73B501E3AF; Tue, 13 May 2014 17:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1400000600; bh=MEXdFP4VQz3rJCFodvAwTQkZ7uHCNAcdgGfumVVTQtk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pHDIU2SZzz2GBDpj8+EfK4mOX6OlXOakj6HPdnIBMHlnVfT1Symq3IbU08OP6VsWw IumK7zFpI+iizxUsCvxJjtwVTAGjcC55WYrWkKmUVn5VTNzZjoW548Ol3JVs7r933R g6EJV5jxnngLKvyD8SkfxgsZ+orm7PKlCd48qlj0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 1CFF26001E; Tue, 13 May 2014 16:57:17 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140513135204.GP27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 13 May 2014 13:52:04 +0000") References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 13 May 2014 12:57:17 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140513:viktor1dane@dukhovni.org::cSArv1QUmwAKfScb:000000000000000000000000000000000000ayq5+ X-Hashcash: 1:30:140513:dane@ietf.org::xKkJcFaRsvdGvjqm:000KX//e Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ApDzHuuZnUpxmixhQcXZLteTLCc Cc: dane@ietf.org Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 17:03:29 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> _clientauth.c.example. IN TLSA ? Maybe, in this case, _proto._clientauth.c.example. Different client protocols may want different TLSAs; an additional level in the naming would avoid every requestor having to slog through a potentially long list of TLSA responces to find one which matches. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue May 13 10:13:54 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 CE0511A0168 for ; Tue, 13 May 2014 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o11orRm0w54 for ; Tue, 13 May 2014 10:13:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id D0C671A015B for ; Tue, 13 May 2014 10:13:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 74EC42AB070; Tue, 13 May 2014 17:13:45 +0000 (UTC) Date: Tue, 13 May 2014 17:13:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140513171345.GU27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wvrhOJBucIFB8s2rA6LzpbzYzRo Subject: Re: [dane] Draft charter - client side DANE records 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, 13 May 2014 17:13:53 -0000 On Tue, May 13, 2014 at 12:57:17PM -0400, James Cloos wrote: > >>>>> "VD" == Viktor Dukhovni writes: > > VD> _clientauth.c.example. IN TLSA ? > > Maybe, in this case, _proto._clientauth.c.example. > > Different client protocols may want different TLSAs; an additional level > in the naming would avoid every requestor having to slog through a > potentially long list of TLSA responces to find one which matches. Yes, of course. I have not given much thought to the lookup key yet. -- Viktor. From nobody Tue May 13 12:44:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE7E1A013F for ; Tue, 13 May 2014 12:44:02 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdtQT4q2TwR4 for ; Tue, 13 May 2014 12:44:00 -0700 (PDT) Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) by ietfa.amsl.com (Postfix) with ESMTP id E966B1A0194 for ; Tue, 13 May 2014 12:43:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 6C64C1B034E for ; Tue, 13 May 2014 15:43:53 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 05D721B0139 for ; Tue, 13 May 2014 15:43:52 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/mixed; boundary="Apple-Mail=_CA7D3ACC-BAAB-41C4-B60F-91B911B59242" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Tue, 13 May 2014 15:43:50 -0400 References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> To: "dane@ietf.org list" In-Reply-To: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4mgKjiAfA7l50PjMcA2DIj_-rXU Subject: Re: [dane] Draft charter 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, 13 May 2014 19:44:02 -0000 --Apple-Mail=_CA7D3ACC-BAAB-41C4-B60F-91B911B59242 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Colleagues,=20 Updated version minor changes, fixed spelling, added text on =93client = side DANE lookups=94 without milestones at this point.=20 Reworded couple of sentences for readability.=20 Attached are both full text of the charter and diff off prior version to = this version.=20 Olafur & Warren On May 12, 2014, at 2:32 PM, Olafur Gudmundsson wrote: >=20 > Dear Colleagues=20 >=20 > As the initial set of tasks set out in our original charter have been = either completed or discarded it is time to revisit the charter of the = working group. > The chairs have been working with the AD's on a new charter, attached = is a draft for the new charter with milestones.=20 > The goal is to complete the current set of documents this year, and = next year work on a revised RFC for DANE that will be published as = Internet standard.=20 >=20 > There is lots of options in the proposed charter, some have milestones = some do not, when documents/tasks are adopted we will update milestones. >=20 > If you have comments/suggestions on the draft charter please share = them, the plan is to submit the draft charter to the IESG early next = week.=20 >=20 > Olafur & Warren >=20 > = _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --Apple-Mail=_CA7D3ACC-BAAB-41C4-B60F-91B911B59242 Content-Disposition: attachment; filename=DANE-charter-2014-03.txt Content-Type: text/plain; name="DANE-charter-2014-03.txt" Content-Transfer-Encoding: quoted-printable Current Status: Active=0D DRAFT-03=20 =0D Chairs:=0D Warren Kumari=0D Olafur Gudmundsson=0D =0D Security Area Advisor:=0D Stephen Farrell=0D =0D Description of Working Group:=0D =0D Objective:=0D =0D The DANE WG will process documents that describe how to=0D incorporate DANE and DANE-like functionality in protocols, and=0D mechanisms to facilitate adoption of this functionality. The DANE=0D working group will also assist other working groups with adding=0D DANE functionality to their work. In addition the working group=0D will monitor and provide guidance to operators and tool developers.=0D= When work on currently chartered documents is complete the WG=0D may re-charter if sufficiently pressing new work is identified.=0D DANE is not intended to be a long-lived catch-all WG=0D for all PKI in DNS issues and so will generally not adopt new=0D work items without re-chartering.=0D =0D Problem Statement:=0D =0D The DANE working group has developed a framework for securely=0D retrieving keying information from the DNS [RFC6698]. This=0D framework allows secure storing and looking up server public key=0D information in the DNS. This provides a binding between a domain=0D name providing a particular service and the key that can be used=0D to establish encrypted connection to that service. =0D =0D By requiring DNSSEC protection for the look-up of the public key=0D information, DANE leverages the integrity protection provided by=0D DNSSEC to enable secure discovery of keying information. Operators=0D= wanting to take advantage of DANE for their services must turn on=0D DNSSEC signing on the zones used in finding the services. Using=0D DNS this way, bindings of keys to domains are asserted by the = entities that=20 operate the DNS for that domain, not by external entities. =0D =0D The DANE mechanisms provide flexibility in how the keying=0D information is presented. DANE supports both Certificates and raw=0D keys, further more Certificates and raw keys can be either the full=0D= key or a hash of the key. =0D The group will work on documenting the different approaches to use=0D= DANE keying, and the security implication of each. In addition=0D the WG may develop a framework(s) to facilitate the lookup "client" = DANE=20 records for authorization/authentication purposes. =0D =0D The group may also create documents that describe how protocol=0D entities can discover and validate these bindings in the execution=0D= of specific applications. This work would be done in coordination=0D with the IETF Working Groups responsible for the protocols. =0D =0D The group may in addition encourage interoperability testing and = document=0D the results of such testing. =0D =0D Goals and Milestones:=0D DONE - First WG draft of standards-track protocol for using DNS to = associate hosts with keys for TLS and DTLS=0D DONE - Protocol for using DNS to associate domain names with keys for = TLS and DTLS to IESG=0D Jun 2014 - Advance DANE SRV document to IESG=0D Jun 2014 - Advance DANE SMTP document to IESG=0D Aug 2014 - Advance DANE SMIME document to IESG=0D Aug 2014 - Advance DANE OPENPGP document to IESG=0D Sep 2014 - Advance DANE operational guidance/errata document to IESG=0D= Jan 2015 - Advance DANE security model document to IESG. =0D May 2015 - Advance DANE IPSEC document to IESG=0D Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard=0D= Nov 2015 - Recharter or close down =0D --Apple-Mail=_CA7D3ACC-BAAB-41C4-B60F-91B911B59242 Content-Disposition: attachment; filename=dane-charter-02-to-03.diff Content-Type: application/octet-stream; name="dane-charter-02-to-03.diff" Content-Transfer-Encoding: quoted-printable ---=20DANE-charter-2014-02.txt=092014-05-12=2014:24:46.000000000=20-0400=0A= +++=20DANE-charter-2014-03.txt=092014-05-13=2015:39:11.000000000=20-0400=0A= @@=20-1,4=20+1,5=20@@=0A=20Current=20Status:=20Active=0D=0A+DRAFT-03=20=0A= =20=0D=0A=20Chairs:=0D=0A=20=20=20=20=20=20Warren=20Kumari=0D=0A@@=20= -17,7=20+18,6=20@@=0A=20=20=20=20=20working=20group=20will=20also=20= assist=20other=20working=20groups=20with=20adding=0D=0A=20=20=20=20=20= DANE=20functionality=20to=20their=20work.=20In=20addition=20the=20= working=20group=0D=0A=20=20=20=20=20will=20monitor=20and=20provide=20= guidance=20to=20operators=20and=20tool=20developers.=0D=0A-=20=20=20=20= will=20monitor=20and=20provide=20guidance=20to=20operators=20and=20tool=20= developers.=0D=0A=20=20=20=20=20When=20work=20on=20currently=20chartered=20= documents=20is=20complete=20the=20WG=0D=0A=20=20=20=20=20may=20= re-charter=20if=20sufficiently=20pressing=20new=20work=20is=20= identified.=0D=0A=20=20=20=20=20DANE=20is=20not=20intended=20to=20be=20a=20= long-lived=20catch-all=20WG=0D=0A@@=20-28,42=20+28,44=20@@=0A=20=0D=0A=20= =20=20=20=20The=20DANE=20working=20group=20has=20developed=20a=20= framework=20for=20securely=0D=0A=20=20=20=20=20retrieving=20keying=20= information=20from=20the=20DNS=20[RFC6698].=20This=0D=0A-=20=20=20=20= framework=20allows=20secure=20storing=20and=20looking=20up=20public=20= key=0D=0A+=20=20=20=20framework=20allows=20secure=20storing=20and=20= looking=20up=20server=20public=20key=0D=0A=20=20=20=20=20information=20= in=20the=20DNS.=20This=20provides=20a=20binding=20between=20a=20domain=0D= =0A=20=20=20=20=20name=20providing=20a=20particular=20service=20and=20= the=20key=20that=20can=20be=20used=0D=0A=20=20=20=20=20to=20establish=20= encrypted=20connection=20to=20that=20service.=20=20=0D=0A=20=0D=0A-=20=20= =20=20By=20requiring=20DNSSEC=20protection=20for=20the=20lookup=20of=20= the=20public=20key=0D=0A+=20=20=20=20By=20requiring=20DNSSEC=20= protection=20for=20the=20look-up=20of=20the=20public=20key=0D=0A=20=20=20= =20=20information,=20DANE=20leverages=20the=20integrity=20protection=20= provided=20by=0D=0A=20=20=20=20=20DNSSEC=20to=20enable=20secure=20= discovery=20of=20keying=20information.=20Operators=0D=0A=20=20=20=20=20= wanting=20to=20take=20advantage=20of=20DANE=20for=20their=20services=20= must=20turn=20on=0D=0A=20=20=20=20=20DNSSEC=20signing=20on=20the=20zones=20= used=20in=20finding=20the=20services.=20Using=0D=0A-=20=20=20=20DNS=20= this=20way,=20bindings=20of=20keys=20to=20domains=20are=20asserted=20not=20= by=0D=0A-=20=20=20=20external=20entities,=20but=20by=20the=20entities=20= that=20operate=20the=20DNS.=20=0D=0A+=20=20=20=20DNS=20this=20way,=20= bindings=20of=20keys=20to=20domains=20are=20asserted=20by=20the=20= entities=20that=20=0A+=20=20=20=20operate=20the=20DNS=20for=20that=20= domain,=20not=20by=20external=20entities.=20=0D=0A=20=0D=0A=20=20=20=20=20= The=20DANE=20mechanisms=20provide=20flexibility=20in=20how=20the=20= keying=0D=0A=20=20=20=20=20information=20is=20presented.=20DANE=20= supports=20both=20Certificates=20and=20raw=0D=0A=20=20=20=20=20keys,=20= further=20more=20Certificates=20and=20raw=20keys=20can=20be=20either=20= the=20full=0D=0A=20=20=20=20=20key=20or=20a=20hash=20of=20the=20key.=20=0D= =0A=20=20=20=20=20The=20group=20will=20work=20on=20documenting=20the=20= different=20approaches=20to=20use=0D=0A-=20=20=20=20DANE=20keying,=20and=20= the=20security=20implication=20of=20each.=20=0D=0A+=20=20=20=20DANE=20= keying,=20and=20the=20security=20implication=20of=20each.=20In=20= addition=0D=0A+=20=20=20=20the=20WG=20may=20develop=20a=20framework(s)=20= to=20facilitate=20the=20lookup=20"client"=20DANE=20=0A+=20=20=20=20= records=20for=20authorization/authentication=20purposes.=20=0D=0A=20=0D=0A= =20=20=20=20=20The=20group=20may=20also=20create=20documents=20that=20= describe=20how=20protocol=0D=0A=20=20=20=20=20entities=20can=20discover=20= and=20validate=20these=20bindings=20in=20the=20execution=0D=0A=20=20=20=20= =20of=20specific=20applications.=20This=20work=20would=20be=20done=20in=20= coordination=0D=0A=20=20=20=20=20with=20the=20IETF=20Working=20Groups=20= responsible=20for=20the=20protocols.=20=0D=0A=20=0D=0A-=20=20=20=20The=20= group=20may=20in=20addition=20encourage=20interop=20testing=20and=20= document=0D=0A-=20=20=20=20results=20of=20such=20testing.=20=0D=0A+=20=20= =20=20The=20group=20may=20in=20addition=20encourage=20interoperability=20= testing=20and=20document=0D=0A+=20=20=20=20the=20results=20of=20such=20= testing.=20=0D=0A=20=0D=0A=20Goals=20and=20Milestones:=0D=0A=20=20=20= DONE=20-=20First=20WG=20draft=20of=20standards-track=20protocol=20for=20= using=20DNS=20to=20associate=20hosts=20with=20keys=20for=20TLS=20and=20= DTLS=0D=0A=20=20=20DONE=20-=20Protocol=20for=20using=20DNS=20to=20= associate=20domain=20names=20with=20keys=20for=20TLS=20and=20DTLS=20to=20= IESG=0D=0A=20=20=20Jun=202014=20-=20Advance=20DANE=20SRV=20document=20to=20= IESG=0D=0A-=20=20Jun=202014=20-=20Advance=20DANE=20SMPT=20document=20to=20= IESG=0D=0A+=20=20Jun=202014=20-=20Advance=20DANE=20SMTP=20document=20to=20= IESG=0D=0A=20=20=20Aug=202014=20-=20Advance=20DANE=20SMIME=20document=20= to=20IESG=0D=0A=20=20=20Aug=202014=20-=20Advance=20DANE=20OPENPGP=20= document=20to=20IESG=0D=0A-=20=20Sep=202014=20-=20Advance=20DANE=20= operational=20guidance=20document=20to=20IESG=0D=0A+=20=20Sep=202014=20-=20= Advance=20DANE=20operational=20guidance/errata=20document=20to=20IESG=0D=0A= =20=20=20Jan=202015=20-=20Advance=20DANE=20security=20model=20document=20= to=20IESG.=20=0D=0A=20=20=20May=202015=20-=20Advance=20DANE=20IPSEC=20= document=20to=20IESG=0D=0A=20=20=20Sep=202015=20-=20Advance=20DANE=20= RFC6698=20and=20DANE=20SRV=20RFC=20to=20Internet=20Standard=0D=0A= --Apple-Mail=_CA7D3ACC-BAAB-41C4-B60F-91B911B59242-- From nobody Tue May 13 16:28:38 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1D01A0205 for ; Tue, 13 May 2014 16:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFrSY_fxYmMZ for ; Tue, 13 May 2014 16:28:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBD11A01E5 for ; Tue, 13 May 2014 16:28:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3A7CE2AAD62; Tue, 13 May 2014 23:28:28 +0000 (UTC) Date: Tue, 13 May 2014 23:28:28 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140513232827.GA27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/UaGvOnMQYe9noJjXkp0Cc1yn3cU Subject: Re: [dane] Draft charter 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, 13 May 2014 23:28:37 -0000 On Tue, May 13, 2014 at 03:43:50PM -0400, Olafur Gudmundsson wrote: > Updated version minor changes, fixed spelling, added text on > 'client side DANE lookups' without milestones at this point. This change: - By requiring DNSSEC protection for the lookup of the public key + By requiring DNSSEC protection for the look-up of the public key Should I think be reverted, the noun is "lookup" not "look-up". -- Viktor. From nobody Wed May 14 16:38:36 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9914D1A036F for ; Wed, 14 May 2014 16:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm4qHNNrwYSu for ; Wed, 14 May 2014 16:38:33 -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 601841A0345 for ; Wed, 14 May 2014 16:38:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9FC0C2AB0DD; Wed, 14 May 2014 23:38:25 +0000 (UTC) Date: Wed, 14 May 2014 23:38:25 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140514233825.GM27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CqYhD5zP0hVIMeu6MI9-JjQ2U84 Subject: [dane] Dog food consumed (ietf.org STARTTLS and DANE TLSA records deployed) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 23:38:34 -0000 $ posttls-finger -c -Lsummary ietf.org posttls-finger: Verified TLS connection established to mail.ietf.org[4.31.198.44]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) -- Viktor. From nobody Thu May 15 02:15:15 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 34D811A0441 for ; Thu, 15 May 2014 02:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HNPLfKla3R4o for ; Thu, 15 May 2014 02:15:12 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7168D1A0440 for ; Thu, 15 May 2014 02:15:12 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gf5so558116lab.24 for ; Thu, 15 May 2014 02:15:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JgPvpknxPCAsyQze3c9lfetSy4+jQAQ0Nsq4aOCXTVY=; b=ScZRkC2KeeQtM5GhQ+N7bToHTaOCHxjWRld6iWBv6pA9F+zzSxyNgzrFSucwX5fkrQ getNPFDWYxWfwoa0+tt+aqq5fh061G8sKEWQ+K8Qzf1Qr+6Q8PJoB7Ltj1OcT5BJaSkI aUgxpj5sY3bWfblX23INWLuSSOSw/VpandJzOeO35aChYYP8Bsft8DV9FjjyFNzx+8X/ 5By3UGmoXPcX6GIr9tnh9RWAi+BtLE+7QwMIGJvqFAdRm0DOC1wZUPDQuPwsKYUimhf+ XiwwuX+4GYF6PvV71xHqnGsZOCTAoVZIug1u5bzttmYu5lQ5pexBLg5HgKVJ0PmP2x4s z1+g== X-Gm-Message-State: ALoCoQkwNBRbjZuKR4P5gEdeoe5KvcoxWwztiVSPz7I3kw4qVCy4j14sYC9jh69nYI+le2+O2qQA X-Received: by 10.112.149.71 with SMTP id ty7mr6355735lbb.34.1400145304125; Thu, 15 May 2014 02:15:04 -0700 (PDT) Received: from [192.36.125.224] (dhcp.pilsnet.sunet.se. [192.36.125.224]) by mx.google.com with ESMTPSA id aa1sm4742963lbd.12.2014.05.15.02.15.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 02:15:03 -0700 (PDT) Message-ID: <53748596.5030804@mnt.se> Date: Thu, 15 May 2014 11:15:02 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140514233825.GM27883@mournblade.imrryr.org> In-Reply-To: <20140514233825.GM27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_KytPTNpvq_nl8C08GCxoXgurT0 Subject: Re: [dane] Dog food consumed (ietf.org STARTTLS and DANE TLSA records deployed) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 09:15:14 -0000 On 2014-05-15 01:38, Viktor Dukhovni wrote: > > $ posttls-finger -c -Lsummary ietf.org > posttls-finger: Verified TLS connection established to mail.ietf.org[4.31.198.44]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) > yummy From nobody Thu May 15 02:37: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 DE35A1A0478 for ; Thu, 15 May 2014 02:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypUYj_nLzoQA for ; Thu, 15 May 2014 02:37:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DC35D1A0463 for ; Thu, 15 May 2014 02:37:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AF829BE63 for ; Thu, 15 May 2014 10:37:07 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-oDoxkGg3cV for ; Thu, 15 May 2014 10:37:07 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B4BCBE1D for ; Thu, 15 May 2014 10:37:07 +0100 (IST) Message-ID: <53748AC4.7000109@cs.tcd.ie> Date: Thu, 15 May 2014 10:37:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <20140514233825.GM27883@mournblade.imrryr.org> In-Reply-To: <20140514233825.GM27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JWA1hHn91Y2WO8auVxUfalyT3zE Subject: Re: [dane] Dog food consumed (ietf.org STARTTLS and DANE TLSA records deployed) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 09:37:16 -0000 On 15/05/14 00:38, Viktor Dukhovni wrote: > > $ posttls-finger -c -Lsummary ietf.org posttls-finger: Verified TLS > connection established to mail.ietf.org[4.31.198.44]:25: TLSv1.1 with > cipher ECDHE-RSA-AES256-SHA (256/256 bits) > Good job! Thanks to all who helped make this happen. S From nobody Thu May 15 09:51:46 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3541A0678 for ; Thu, 15 May 2014 09:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 rvyc8l0t1pLJ for ; Thu, 15 May 2014 09:51:42 -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 586211A0672 for ; Thu, 15 May 2014 09:51:42 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 942D91DE6F; Thu, 15 May 2014 16:51:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1400172694; bh=CQ5Rm/hFDui1PLRuCdvM4Mc6cnuiIt9r/B8VMN1sO08=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Cf5ZoRvZNDWVTq+Y5FElr1Hd1CXFz92qTezVUpAql/34aED2Ke7a5wQYGiAvyVpfI BjJEkuqgm15FF0p2QNOwAmlM2juHa0JlUkooiAxy/XWZWf8k27rqeBryvE6lmzxoav BJcsXR+lrh9w1xo+F+mIoGrknsnWg0DXUyKdFKKg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C6AA16001E; Thu, 15 May 2014 16:46:50 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20140514233825.GM27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 14 May 2014 23:38:25 +0000") References: <20140514233825.GM27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 15 May 2014 12:46:50 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Hashcash: 1:30:140515:dane@ietf.org::9URnAukOCx8gm5+x:000u9H5K X-Hashcash: 1:30:140515:viktor1dane@dukhovni.org::CxheBm+WY+8/lTVQ:000000000000000000000000000000000000dkxDN Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8TzGx6_m_6krjQB44ixTLzW9UOQ Subject: Re: [dane] Dog food consumed (ietf.org STARTTLS and DANE TLSA records deployed) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 16:51:44 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> posttls-finger: Verified TLS connection established to VD> mail.ietf.org[4.31.198.44]:25: TLSv1.1 with cipher VD> ECDHE-RSA-AES256-SHA (256/256 bits) Trés cool! Thanks to all; most welcome. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri May 16 07:09: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 D63721A0052 for ; Fri, 16 May 2014 07:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, 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 Fv3lUVDiHaS0 for ; Fri, 16 May 2014 07:09:49 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [IPv6:2001:1608:12:1:8ead:7d6c:3132:6a07]) (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 17FD41A0062 for ; Fri, 16 May 2014 07:09:48 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1400249373; bh=fWW3w3xjJyPObe5+3f1pE3TNtATcIQcJDmTtPILrjzE=; h=Date:From:To:Subject:References:In-Reply-To; b=d5ToyGDhfx8mon+szDdIeMiG66+bjs7e+93ptM7ndAwHUo7aH7dndon+p8hboIvqV TKj0udP0WTuvEDBntr2eNe5zZWKBRY7BdfQpCYssmb+56Lt7yf8yL+8194PCDvEQmK j3+fuGHj1AHbSNJkDmiV8F8Xsob3DTvYj7zC2NTeosSMr5uOqNcdpm4G99HuLz8vIK yRDxPGLA8O5vJwbFOZdIC1G67OhRO/3UJl39WwSQJWhAjSbCaaSlbhS3Jdl+gYT1PW 2sphpQK87muDJ6oqP7ACi8r5I0qNEzWjtgNXzWWVQlv/1JNoi1le73ME/Bcp5XP4jE nIEqtbZ9yUxG4XWAR8be4ILm1sNQ5f8DVc+SH0WElMzpBDSsvBT+B2tqUiHvUMA4Mr LTc0m0kn8Cn6BqiImldWP8IqhFHQKPnAr305CUE2TazZWzJnnBy70yO1uHywlgApIh XgEXenlwr3y50SD1mCRpQ2sEIHFJ32zwihOwMWmI+X1LvTvK3YojW/yWAwID9y8ccg erpaE7pjkHzpF3Hms0QEpPglb5xXdtgJYDUTeblr7PcCbXZXn/ZZbRtMCU+6o1v8UP Dv9DQPjDT+/9jDYdc5j9HtB09Zs40JqSfYRuW67E8IDJABPSFD0TxJnKZg/0gVpSFB eS0MYV5/KxVu8cShfHyzEHLY= X-Received: line deleted by mout Date: Fri, 16 May 2014 16:09:30 +0200 Message-ID: <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> From: Andreas Schulze To: dane@ietf.org References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.7) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VYgowB6ZNeaPkN1kr8mU-z3J-SY Subject: Re: [dane] Draft charter - client side DANE records 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, 16 May 2014 14:09:51 -0000 James Cloos: > Maybe, in this case, _proto._clientauth.c.example. just to make sure I read above right: - $client connect from $random_highport to $server:$fix_serviceport. - $server extract $client_ip and lookup $client_name (PTR) - $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record. right? Andras From nobody Fri May 16 08:09: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 73ED31A00C0 for ; Fri, 16 May 2014 08:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEZOaBYjNaju for ; Fri, 16 May 2014 08:09:16 -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 7FD8C1A0261 for ; Fri, 16 May 2014 08:09:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 50DC82AB0F7; Fri, 16 May 2014 15:09:07 +0000 (UTC) Date: Fri, 16 May 2014 15:09:07 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140516150907.GX27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bnyDTdP4JARGQlJVOo4Q5p6-JIA Subject: Re: [dane] Draft charter - client side DANE records 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, 16 May 2014 15:09:18 -0000 On Fri, May 16, 2014 at 04:09:30PM +0200, Andreas Schulze wrote: > James Cloos: > > >Maybe, in this case, _proto._clientauth.c.example. > > just to make sure I read above right: > > - $client connect from $random_highport to $server:$fix_serviceport. Yes. > - $server extract $client_ip and lookup $client_name (PTR) This is often not the right name, if at all possible (in an application protocol where the client can signal its identity before STARTTLS) the name should be conveyed by the client. TLSA records would authenticate that name. If the client's name is authenticated, it might be used for access control and to avoid impersonation. To mitigate downgrade attacks, the server would have to be willing to not continue when DNS resolution (either the forward address lookup or the TLSA lookup) of the client name fails (note "insecure" or validated NXDOMAIN is not a failure in this sense, see the DNS error section of the SMTP draft). For SMTP, many clients have HELO names whose lookups fail with NXDOMAIN, but I don't know whether ServFail or similar errors are also common. This is more likely to initially be more applicable to XMPP and SIP, but SMTP might also benefit some day. > - $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record. > > right? No server looks up something like: smtp._clientauth.$clientname IN TLSA ? where "smtp" is (one example of) the application service name. -- Viktor. From nobody Fri May 16 09:39:27 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 3363B1A00B5 for ; Fri, 16 May 2014 09:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 SEbD58lnyZ54 for ; Fri, 16 May 2014 09:39:25 -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 020871A0280 for ; Fri, 16 May 2014 09:39:25 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 13DDC1DFF6; Fri, 16 May 2014 16:39:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1400258356; bh=52FbsnFg/3bZJQOuUm7nuWXrIGnxYtJHarRQdX6CdEk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TXjRe6pMzlo9oKFXKZ0q4094IJF+4mbvVwgpWUPqx2GRgPJBqX4ABYZx4LrqE4Ww6 n70w+Sjq/mEP1JtyrjGSVdxnrBDQP1RvykBew2BMgsmP4kGtPFSDFwlChNBUu+1NIM nKcHSNXxWsG304sVI1Q+Laj+f04fW0mkpRDVEavg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C1CF36001E; Fri, 16 May 2014 16:32:57 +0000 (UTC) From: James Cloos To: Andreas Schulze In-Reply-To: <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> (Andreas Schulze's message of "Fri, 16 May 2014 16:09:30 +0200") References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 16 May 2014 12:32:57 -0400 Message-ID: Lines: 50 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140516:sca@andreasschulze.de::uUg/CMu8zJKgb5+4:000000000000000000000000000000000000000rTZWc X-Hashcash: 1:30:140516:dane@ietf.org::4icVivZWlZl2iCkK:000CAwLM Archived-At: http://mailarchive.ietf.org/arch/msg/dane/VSBCoysyy_0HvBte1LkhCM6CtxY Cc: dane@ietf.org Subject: Re: [dane] Draft charter - client side DANE records 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, 16 May 2014 16:39:26 -0000 >>>>> "AS" == Andreas Schulze writes: AS> just to make sure I read above right: AS> - $client connect from $random_highport to $server:$fix_serviceport. AS> - $server extract $client_ip and lookup $client_name (PTR) AS> - $server lookup $fix_serviceport._clientauth.$client_name. for TLSA Record. Unfortunately unnecessary constraints on the ptr zones are too common to support sticking tlsas therein. Client tlsa probably will only work for protocols where the client claims to be something which can be forward-resolved, such as smtp (helo name), sip (From: address) or the like. When clients claim a name which looks like a hostname, the tlsa lookup could be as simple as: _$PROTO._clientauth.$CLAIMED_NAME The tls cert is likely in such cases to offer $CLAIMED_NAME as CN or within the dnsnames. Whether $CLAIMED_NAME is related to the remote ip address is a separate issue which, if the server checks, can be used as part of the trust equation. Just like the current case with mta->mta smtp client certs. For things like sip, where the claimed name usually looks like an email address, the left hand side probably ought to be hashed and hexed, as per the dane drafts for smime and openpgp, and included in the lookup. The exact query for that case should get some discussion. Again, whether the remote ip address looks reasonable for the claimed name is orthogonal to what the cert claims to certify and whether the tlsa provides a trust path for said cert. But also again, servers can use multiple data sources to decide how much they trust any given credential. Alternatively, the server might get the claimed name from the offered cert. Either way, and unlike the server tlsa case, $PROTO should be a name rather than a port number. The string should derive from whatever means led the client to the particular server, such as the protocol specified in a uri, used for a srv lookup, the keyword in iana's port-numbers registry, et cetera. (Which wins in case of conflict?) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri May 16 12:48: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 327E31A035D for ; Fri, 16 May 2014 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 s0_2bppiXZnX for ; Fri, 16 May 2014 12:48:38 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) (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 1764B1A0353 for ; Fri, 16 May 2014 12:48:37 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1400269702; bh=gofmcF0iaApLj65RtXW7Xt/Ms507HgKG3Jri/tk1ogg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=lOtDfaZbBGiRSQBIFcHGS1dIMdYEifVs9OOXDCa55w8fd305+0V9o2rsFlwt1xJyb hE9u9MqGmM670bsqEh3+JJb4OCalDnPCVf/NOmJrhkb6tS/6w1D6XH8f2h/8+Kf1fh tjaZPz9UsnCdQVq0pTlp7skScsfJ41fBJaPCfqXAq0Tr6KkxTK3xh7POAgM4X4RYae Fp16Vt25vzuDn0zErfqzKF6ptdHbjsuudZlbG+RJlgcsb1YJHUyUxhCDVdjb9JdZuk wiaBb3zlydTny3VTSAuO3ZyJso3z0BXP5A0cDiOb2KUDZfrtNtBPvAN3IfZiJslmPW r58dDJN/F4LK6dujdhr/mO0TnmKWI0tVv7zocRjPfKGhpv9WAqtXTpjppARCqSjkGq xsA7Z/ojO5PE/Se8NVPMBn6vPENttJC9hUUh3vc05KsP7XV2BNn5noTZ8KOJCIPKwd hwLa0jSMtxaWr9MwfsvAsfmrBDssAhhum25fIEKWuSdCVT8nDGI1qH8yQBj1xIHDBS iiFan8ZhdOx4jLaVXax2FI7w34UULeuwa8sJFAoIjWLkdnCN8zC616wN8/2aaL9AiQ 0nKq92xIs1J8l50X1/8Rcurx2cIwSF/IgOuQxcm1JtuvNT2eHplJVcCwPm3NQbgai9 4bYj2X5ER3RE73Uy5H520lYI= X-Received: line deleted by mout Date: Fri, 16 May 2014 21:48:18 +0200 Message-ID: <20140516214818.Horde.9Y9TWoOsBzqyWzh66bCzGg2@horde.andreasschulze.de> From: Andreas Schulze To: James Cloos References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.7) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tkE7OL_aXQAPwi31HRGsIPEnMUM Cc: dane@ietf.org Subject: Re: [dane] Draft charter - client side DANE records 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, 16 May 2014 19:48:39 -0000 James Cloos: > Unfortunately unnecessary constraints on the ptr zones are too common to > support sticking tlsas therein. James, Viktor, thanks for clarification. you mention that the ptr is unusable as base for a TLSA lookup. You suggest to use the helo name in smtp for example. I can tell only about smtp but here I don't see a real difference. Hosts with perfect double dns mostly also use a corresponding helo name while host without mostly lack also the matching helo name. (my feeling, no detailed statistics...) > _$PROTO._clientauth.$CLAIMED_NAME I like the phrase CLAIMED_NAME but I see no benefit on using 'smtp' as $PROTO vs. the numeric portnumber ? Back to the first: taking the CLAIMED_NAME as base to build a dns label leave options open, how the server has to construct the label. Simply using a ptr *may* be an option, but hasn't to be the only one. To get the clients CLAIMED_NAME a server has multiple choices with different weights. Andreas From nobody Fri May 16 13:40:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1161A02B2 for ; Fri, 16 May 2014 13:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdejNQOBOQGr for ; Fri, 16 May 2014 13:40:39 -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 5250A1A01D4 for ; Fri, 16 May 2014 13:40:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A8312AB0F7; Fri, 16 May 2014 20:40:30 +0000 (UTC) Date: Fri, 16 May 2014 20:40:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140516204030.GE27883@mournblade.imrryr.org> References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> <20140513135204.GP27883@mournblade.imrryr.org> <20140516160930.Horde.tQdh2ECsQz4Sm_eOgR5vEg2@horde.andreasschulze.de> <20140516214818.Horde.9Y9TWoOsBzqyWzh66bCzGg2@horde.andreasschulze.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140516214818.Horde.9Y9TWoOsBzqyWzh66bCzGg2@horde.andreasschulze.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eNNnNQPv7Y1idgJMnDw91-aoKdw Subject: Re: [dane] Draft charter - client side DANE records 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, 16 May 2014 20:40:41 -0000 On Fri, May 16, 2014 at 09:48:18PM +0200, Andreas Schulze wrote: > I can tell only about smtp but here I don't see a real difference. > Hosts with perfect double dns mostly also use a corresponding helo name > while host without mostly lack also the matching helo name. > (my feeling, no detailed statistics...) Most hosts also don't have TLSA records. No loss. This feature would allow some clients to be "more equal than others". The server might then apply special access policies with these "more equal clients". Because unlike SIP or XMPP, SMTP is uni-directional, and the mail transport is store and forward, the potential value of client authentication for SMTP is more limited than for the other protocols, but may still be useful. > > _$PROTO._clientauth.$CLAIMED_NAME > > I like the phrase CLAIMED_NAME but I see no benefit > on using 'smtp' as $PROTO vs. the numeric portnumber ? The origin domain is authorizing SMTP clients to act on its behalf, more so than the right to reach a particular remote port. This said, the lookup key will be application-specific, and it is perhaps a bit early to do a deep-dive into that now... -- Viktor. From nobody Tue May 20 07:41: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 2E0911A0732 for ; Tue, 20 May 2014 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.553 X-Spam-Level: X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 RAsovK6aWzpB for ; Tue, 20 May 2014 07:41:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id F32001A0720 for ; Tue, 20 May 2014 07:41:02 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4KEf1xq018180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 May 2014 10:41:02 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4KEexWQ006272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 20 May 2014 10:41:00 -0400 Message-ID: <537B697B.3030200@redhat.com> Date: Tue, 20 May 2014 16:40:59 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <120CB7DD-9835-4842-9298-9AA0C0485085@ogud.com> <20140512192714.GI27883@mournblade.imrryr.org> <906FAD54-CD40-43EA-B1AD-8EF7B50FD294@ogud.com> <20140512204256.GK27883@mournblade.imrryr.org> In-Reply-To: <20140512204256.GK27883@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uVuOGJk1acZoZFVF0WA4K19TAo0 Subject: Re: [dane] Draft charter 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, 20 May 2014 14:41:11 -0000 On 12.5.2014 22:42, Viktor Dukhovni wrote: > On Mon, May 12, 2014 at 04:21:10PM -0400, Olafur Gudmundsson wrote: > >>> > >The RFC6698-specified lookup key of _._. is not >>> > >universally applicable. It works OK for well known services such >>> > >as SMTP on ports 25/587 or HTTPS on 443, but is not always well >>> > >suited to environments in which service ports are dynamically >>> > >registered. Also, sometimes the verifier wants to authenticate a >>> > >TLS client acting on behalf of some domain in an appropriate >>> > >capacity. >> > >> >This also works well for services looked up via SRV records. >> >As the SRV contains the port number. >> >For a protocol that has some kind of other selector of port, >> >still at the end of the day the "Server" side has a "known-port" >> >to the client, if the service moves from one port to another port OR >> >provides service on multiple ports then it is possible that the >> >protocol definition for the DANE variant of that protocol can say >> >lookup of Authentication records is FP at hostname. > I am mostly pointing out that port is not universally the right > choice. Sometimes a service name or other identifier is more > appropriate, whether this is the case, or what might be a better > lookup key is application dependent. I totally agree, some guidance how to use DANE in application-specific way would be handy. An example from Kerberos world: There is a Kerberos extension called PKINIT [RFC 4556] which relies on secure CA certificate distribution. This CA cert is shared by the whole "Kerberos realm". Maybe Kerberos protocol should be extended to look-up CA cert in DNS, e.g. from _kerberos.[REALM] IN TLSA ... I'm sure there will be other cases like that. (Note: I'm not saying that this particular case cannot be solved in other ways, it is just an example.) -- Petr Spacek @ Red Hat From nobody Tue May 20 07:49: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 41C171A005C for ; Tue, 20 May 2014 07:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F8-HIfZVV0T for ; Tue, 20 May 2014 07:49:17 -0700 (PDT) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F71F1A0346 for ; Tue, 20 May 2014 07:49:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A10B51E826B; Tue, 20 May 2014 10:49:16 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 181081E83BB; Tue, 20 May 2014 10:49:14 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_19216525-FA27-4E96-90F4-036C7F1E3357" Date: Tue, 20 May 2014 10:49:13 -0400 Message-Id: <3F2B291A-D089-4048-8692-FFB7698745DD@ogud.com> To: dane-ads@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2C7cMg9z_fyiF-bRyvD3Fe3i_4U Cc: The IESG , "dane@ietf.org list" Subject: [dane] New DANE charter submission 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, 20 May 2014 14:49:19 -0000 --Apple-Mail=_19216525-FA27-4E96-90F4-036C7F1E3357 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Stephen,=20 below is our draft charter please take it to the IESG.=20 Olafur & Warren Current Status: Active Chairs: Warren Kumari Olafur Gudmundsson Security Area Advisor: Stephen Farrell Description of Working Group: Objective: The DANE WG will process documents that describe how to incorporate DANE and DANE-like functionality in protocols, and mechanisms to facilitate adoption of this functionality. The DANE working group will also assist other working groups with adding DANE functionality to their work. In addition the working group will monitor and provide guidance to operators and tool developers. When work on currently chartered documents is complete the WG may re-charter if sufficiently pressing new work is identified. DANE is not intended to be a long-lived catch-all WG for all PKI in DNS issues and so will generally not adopt new work items without re-chartering. Problem Statement: The DANE working group has developed a framework for securely retrieving keying information from the DNS [RFC6698]. This framework allows secure storing and looking up server public key information in the DNS. This provides a binding between a domain name providing a particular service and the key that can be used to establish encrypted connection to that service. By requiring DNSSEC protection for the lookup of the public key information, DANE leverages the integrity protection provided by DNSSEC to enable secure discovery of keying information. Operators wanting to take advantage of DANE for their services must turn on DNSSEC signing on the zones used in finding the services. Using DNS this way, bindings of keys to domains are asserted by the = entities that=20 operate the DNS for that domain, not by external entities.=20 The DANE mechanisms provide flexibility in how the keying information is presented. DANE supports both Certificates and raw keys, further more Certificates and raw keys can be either the full key or a hash of the key.=20 The group will work on documenting the different approaches to use DANE keying, and the security implication of each. In addition the WG may develop a framework(s) to facilitate the lookup "client" = DANE=20 records for authorization/authentication purposes.=20 The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols.=20 The group may in addition encourage interoperability testing and = document the results of such testing.=20 Goals and Milestones: DONE - First WG draft of standards-track protocol for using DNS to = associate hosts with keys for TLS and DTLS DONE - Protocol for using DNS to associate domain names with keys for = TLS and DTLS to IESG Jun 2014 - Advance DANE SRV document to IESG Jun 2014 - Advance DANE SMTP document to IESG Aug 2014 - Advance DANE SMIME document to IESG Aug 2014 - Advance DANE OPENPGP document to IESG Sep 2014 - Advance DANE operational guidance/errata document to IESG Jan 2015 - Advance DANE security model document to IESG. May 2015 - Advance DANE IPSEC document to IESG ??? 2015 - Advance DANE reverse binding (server to client) document to = IESG. Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard Nov 2015 - Recharter or close down --Apple-Mail=_19216525-FA27-4E96-90F4-036C7F1E3357 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Stephen, 
below = is our draft charter please take it to the = IESG. 

Olafur & = Warren

Current Status: Active

Chairs:
     Warren Kumari
     Olafur = Gudmundsson

 Security Area Advisor:
     Stephen Farrell

Description of Working Group:

Objective:

    The DANE WG will process = documents that describe how to
    incorporate DANE and DANE-like = functionality in protocols, and
    mechanisms to facilitate adoption of = this functionality. The DANE
    working group will also assist other = working groups with adding
    DANE functionality to their work. In addition the = working group
    will monitor and provide guidance to operators and = tool developers.
    When work on currently chartered documents is = complete the WG
    may re-charter if sufficiently pressing new work = is identified.
    DANE is not intended to be a long-lived catch-all = WG
    = for all PKI in DNS issues and so will generally not adopt new
    work items = without re-chartering.

Problem Statement:

    The DANE working group has = developed a framework for securely
    retrieving keying information from = the DNS [RFC6698]. This
    framework allows secure storing and looking up = server public key
    information in the DNS. This provides a binding = between a domain
    name providing a particular service and the key = that can be used
    to establish encrypted connection to that = service.

  =   By requiring DNSSEC protection for the lookup of the public = key
    = information, DANE leverages the integrity protection provided = by
    = DNSSEC to enable secure discovery of keying information. = Operators
    wanting to take = advantage of DANE for their services must turn on
    DNSSEC signing on the zones used in = finding the services. Using
  =   DNS this way, bindings of keys to domains are asserted by the = entities that 
    = operate the DNS for that domain, not by external = entities. 

    The DANE = mechanisms provide flexibility in how the keying
    information is presented. DANE = supports both Certificates and raw
    keys, further more Certificates and raw keys can be = either the full
    key or a = hash of the key. 
    = The group will work on documenting the different approaches to = use
    DANE keying, and the = security implication of each. In addition
    the WG may develop a framework(s) to facilitate the = lookup "client" DANE 
  =   records for authorization/authentication = purposes. 

    The group may = also create documents that describe how protocol
    entities can discover and validate = these bindings in the execution
  =   of specific applications. This work would be done in = coordination
    with the = IETF Working Groups responsible for the protocols. 

    The group may in addition encourage interoperability = testing and document
    the = results of such testing. 

Goals and = Milestones:
  DONE - First WG = draft of standards-track protocol for using DNS to associate hosts with = keys for TLS and DTLS
  DONE - = Protocol for using DNS to associate domain names with keys for TLS and = DTLS to IESG
  Jun 2014 - Advance = DANE SRV document to IESG
  Jun = 2014 - Advance DANE SMTP document to IESG
  Aug 2014 - Advance DANE SMIME document to IESG
  Aug 2014 - Advance DANE OPENPGP document = to IESG
  Sep 2014 - Advance DANE = operational guidance/errata document to IESG
  Jan 2015 - Advance DANE security model document to = IESG.
  May 2015 - Advance DANE = IPSEC document to IESG
  ??? 2015 = - Advance DANE reverse binding (server to client) document to = IESG.
  Sep 2015 - Advance DANE = RFC6698 and DANE SRV RFC to Internet Standard
  Nov 2015 - Recharter or close = down

= --Apple-Mail=_19216525-FA27-4E96-90F4-036C7F1E3357-- From nobody Tue May 20 08:13:27 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 A3DEC1A0494; Tue, 20 May 2014 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fYJWQ5K0tkj; Tue, 20 May 2014 08:13:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B31A0182; Tue, 20 May 2014 08:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9B533BE5B; Tue, 20 May 2014 16:13:11 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCaXg8sFGJ8g; Tue, 20 May 2014 16:13:10 +0100 (IST) Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4261EBE51; Tue, 20 May 2014 16:13:10 +0100 (IST) Message-ID: <537B7106.8020107@cs.tcd.ie> Date: Tue, 20 May 2014 16:13:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Olafur Gudmundsson , dane-ads@tools.ietf.org References: <3F2B291A-D089-4048-8692-FFB7698745DD@ogud.com> In-Reply-To: <3F2B291A-D089-4048-8692-FFB7698745DD@ogud.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AXCYqPc-ZEQ2Z2wucQtq7pYERPc Cc: The IESG , "dane@ietf.org list" Subject: Re: [dane] New DANE charter submission 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, 20 May 2014 15:13:25 -0000 Thanks, I'll whack that in. I assume the WG don't want (or don't care about) external review? If there were some other SDO (e.g. IEEE, W3C etc) who you think might need to know then external review would be correct, but I don't think that applies. Correct me if that's wrong, Cheers, S. On 20/05/14 15:49, Olafur Gudmundsson wrote: > > Stephen, > below is our draft charter please take it to the IESG. > > Olafur & Warren > > Current Status: Active > > Chairs: > Warren Kumari > Olafur Gudmundsson > > Security Area Advisor: > Stephen Farrell > > Description of Working Group: > > Objective: > > The DANE WG will process documents that describe how to > incorporate DANE and DANE-like functionality in protocols, and > mechanisms to facilitate adoption of this functionality. The DANE > working group will also assist other working groups with adding > DANE functionality to their work. In addition the working group > will monitor and provide guidance to operators and tool developers. > When work on currently chartered documents is complete the WG > may re-charter if sufficiently pressing new work is identified. > DANE is not intended to be a long-lived catch-all WG > for all PKI in DNS issues and so will generally not adopt new > work items without re-chartering. > > Problem Statement: > > The DANE working group has developed a framework for securely > retrieving keying information from the DNS [RFC6698]. This > framework allows secure storing and looking up server public key > information in the DNS. This provides a binding between a domain > name providing a particular service and the key that can be used > to establish encrypted connection to that service. > > By requiring DNSSEC protection for the lookup of the public key > information, DANE leverages the integrity protection provided by > DNSSEC to enable secure discovery of keying information. Operators > wanting to take advantage of DANE for their services must turn on > DNSSEC signing on the zones used in finding the services. Using > DNS this way, bindings of keys to domains are asserted by the entities that > operate the DNS for that domain, not by external entities. > > The DANE mechanisms provide flexibility in how the keying > information is presented. DANE supports both Certificates and raw > keys, further more Certificates and raw keys can be either the full > key or a hash of the key. > The group will work on documenting the different approaches to use > DANE keying, and the security implication of each. In addition > the WG may develop a framework(s) to facilitate the lookup "client" DANE > records for authorization/authentication purposes. > > The group may also create documents that describe how protocol > entities can discover and validate these bindings in the execution > of specific applications. This work would be done in coordination > with the IETF Working Groups responsible for the protocols. > > The group may in addition encourage interoperability testing and document > the results of such testing. > > Goals and Milestones: > DONE - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS > DONE - Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG > Jun 2014 - Advance DANE SRV document to IESG > Jun 2014 - Advance DANE SMTP document to IESG > Aug 2014 - Advance DANE SMIME document to IESG > Aug 2014 - Advance DANE OPENPGP document to IESG > Sep 2014 - Advance DANE operational guidance/errata document to IESG > Jan 2015 - Advance DANE security model document to IESG. > May 2015 - Advance DANE IPSEC document to IESG > ??? 2015 - Advance DANE reverse binding (server to client) document to IESG. > Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard > Nov 2015 - Recharter or close down > > From nobody Tue May 20 08:18:30 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 D62F51A0756 for ; Tue, 20 May 2014 08:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 O3HKR5i2mVB1 for ; Tue, 20 May 2014 08:18:25 -0700 (PDT) Received: from smtp116.ord1c.emailsrvr.com (smtp116.ord1c.emailsrvr.com [108.166.43.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7571A0746 for ; Tue, 20 May 2014 08:18:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 462831B862A; Tue, 20 May 2014 11:18:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8E3E62F0009; Tue, 20 May 2014 11:18:01 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Olafur Gudmundsson In-Reply-To: <537B7106.8020107@cs.tcd.ie> Date: Tue, 20 May 2014 11:18:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37684EBC-72F7-4705-8B20-674553F59C64@ogud.com> References: <3F2B291A-D089-4048-8692-FFB7698745DD@ogud.com> <537B7106.8020107@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WMYjtHk7Ahm2KSLbQcAfhjfWJdI Cc: "dane@ietf.org list" , The IESG , dane-ads@tools.ietf.org Subject: Re: [dane] New DANE charter submission 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, 20 May 2014 15:18:27 -0000 On May 20, 2014, at 11:13 AM, Stephen Farrell = wrote: >=20 > Thanks, I'll whack that in. >=20 > I assume the WG don't want (or don't care about) external review? > If there were some other SDO (e.g. IEEE, W3C etc) who you think > might need to know then external review would be correct, but I > don't think that applies. Correct me if that's wrong, >=20 > Cheers, > S. >=20 >=20 Not aware of any external party that we need review from=20 Olafur > On 20/05/14 15:49, Olafur Gudmundsson wrote: >>=20 >> Stephen,=20 >> below is our draft charter please take it to the IESG.=20 >>=20 >> Olafur & Warren >>=20 >> Current Status: Active >>=20 >> Chairs: >> Warren Kumari >> Olafur Gudmundsson >>=20 >> Security Area Advisor: >> Stephen Farrell >>=20 >> Description of Working Group: >>=20 >> Objective: >>=20 >> The DANE WG will process documents that describe how to >> incorporate DANE and DANE-like functionality in protocols, and >> mechanisms to facilitate adoption of this functionality. The DANE >> working group will also assist other working groups with adding >> DANE functionality to their work. In addition the working group >> will monitor and provide guidance to operators and tool = developers. >> When work on currently chartered documents is complete the WG >> may re-charter if sufficiently pressing new work is identified. >> DANE is not intended to be a long-lived catch-all WG >> for all PKI in DNS issues and so will generally not adopt new >> work items without re-chartering. >>=20 >> Problem Statement: >>=20 >> The DANE working group has developed a framework for securely >> retrieving keying information from the DNS [RFC6698]. This >> framework allows secure storing and looking up server public key >> information in the DNS. This provides a binding between a domain >> name providing a particular service and the key that can be used >> to establish encrypted connection to that service. >>=20 >> By requiring DNSSEC protection for the lookup of the public key >> information, DANE leverages the integrity protection provided by >> DNSSEC to enable secure discovery of keying information. Operators >> wanting to take advantage of DANE for their services must turn on >> DNSSEC signing on the zones used in finding the services. Using >> DNS this way, bindings of keys to domains are asserted by the = entities that=20 >> operate the DNS for that domain, not by external entities.=20 >>=20 >> The DANE mechanisms provide flexibility in how the keying >> information is presented. DANE supports both Certificates and raw >> keys, further more Certificates and raw keys can be either the = full >> key or a hash of the key.=20 >> The group will work on documenting the different approaches to use >> DANE keying, and the security implication of each. In addition >> the WG may develop a framework(s) to facilitate the lookup = "client" DANE=20 >> records for authorization/authentication purposes.=20 >>=20 >> The group may also create documents that describe how protocol >> entities can discover and validate these bindings in the execution >> of specific applications. This work would be done in coordination >> with the IETF Working Groups responsible for the protocols.=20 >>=20 >> The group may in addition encourage interoperability testing and = document >> the results of such testing.=20 >>=20 >> Goals and Milestones: >> DONE - First WG draft of standards-track protocol for using DNS to = associate hosts with keys for TLS and DTLS >> DONE - Protocol for using DNS to associate domain names with keys = for TLS and DTLS to IESG >> Jun 2014 - Advance DANE SRV document to IESG >> Jun 2014 - Advance DANE SMTP document to IESG >> Aug 2014 - Advance DANE SMIME document to IESG >> Aug 2014 - Advance DANE OPENPGP document to IESG >> Sep 2014 - Advance DANE operational guidance/errata document to IESG >> Jan 2015 - Advance DANE security model document to IESG. >> May 2015 - Advance DANE IPSEC document to IESG >> ??? 2015 - Advance DANE reverse binding (server to client) document = to IESG. >> Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet = Standard >> Nov 2015 - Recharter or close down >>=20 >>=20 From nobody Tue May 20 08:24:27 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 ACB9B1A074B; Tue, 20 May 2014 08:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWL0HShqliBS; Tue, 20 May 2014 08:24:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7471A0720; Tue, 20 May 2014 08:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6556BE61; Tue, 20 May 2014 16:24:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0G8eO8IZNx3; Tue, 20 May 2014 16:24:09 +0100 (IST) Received: from [193.1.136.127] (dhcp-c101887f.ucd.ie [193.1.136.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 10C26BE32; Tue, 20 May 2014 16:24:09 +0100 (IST) Message-ID: <537B7399.60602@cs.tcd.ie> Date: Tue, 20 May 2014 16:24:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Olafur Gudmundsson References: <3F2B291A-D089-4048-8692-FFB7698745DD@ogud.com> <537B7106.8020107@cs.tcd.ie> <37684EBC-72F7-4705-8B20-674553F59C64@ogud.com> In-Reply-To: <37684EBC-72F7-4705-8B20-674553F59C64@ogud.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/id3yEgW7yeqC0os02a8a6sGxdjg Cc: "dane@ietf.org list" , The IESG , dane-ads@tools.ietf.org Subject: Re: [dane] New DANE charter submission 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, 20 May 2014 15:24:24 -0000 Ok, That's done [1] (I think, send corrections:-) I've put this on the Jun 12 telechat as I'll possibly miss the May 29th one. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-dane/ On 20/05/14 16:18, Olafur Gudmundsson wrote: > > On May 20, 2014, at 11:13 AM, Stephen Farrell wrote: > >> >> Thanks, I'll whack that in. >> >> I assume the WG don't want (or don't care about) external review? >> If there were some other SDO (e.g. IEEE, W3C etc) who you think >> might need to know then external review would be correct, but I >> don't think that applies. Correct me if that's wrong, >> >> Cheers, >> S. >> >> > Not aware of any external party that we need review from > > Olafur > >> On 20/05/14 15:49, Olafur Gudmundsson wrote: >>> >>> Stephen, >>> below is our draft charter please take it to the IESG. >>> >>> Olafur & Warren >>> >>> Current Status: Active >>> >>> Chairs: >>> Warren Kumari >>> Olafur Gudmundsson >>> >>> Security Area Advisor: >>> Stephen Farrell >>> >>> Description of Working Group: >>> >>> Objective: >>> >>> The DANE WG will process documents that describe how to >>> incorporate DANE and DANE-like functionality in protocols, and >>> mechanisms to facilitate adoption of this functionality. The DANE >>> working group will also assist other working groups with adding >>> DANE functionality to their work. In addition the working group >>> will monitor and provide guidance to operators and tool developers. >>> When work on currently chartered documents is complete the WG >>> may re-charter if sufficiently pressing new work is identified. >>> DANE is not intended to be a long-lived catch-all WG >>> for all PKI in DNS issues and so will generally not adopt new >>> work items without re-chartering. >>> >>> Problem Statement: >>> >>> The DANE working group has developed a framework for securely >>> retrieving keying information from the DNS [RFC6698]. This >>> framework allows secure storing and looking up server public key >>> information in the DNS. This provides a binding between a domain >>> name providing a particular service and the key that can be used >>> to establish encrypted connection to that service. >>> >>> By requiring DNSSEC protection for the lookup of the public key >>> information, DANE leverages the integrity protection provided by >>> DNSSEC to enable secure discovery of keying information. Operators >>> wanting to take advantage of DANE for their services must turn on >>> DNSSEC signing on the zones used in finding the services. Using >>> DNS this way, bindings of keys to domains are asserted by the entities that >>> operate the DNS for that domain, not by external entities. >>> >>> The DANE mechanisms provide flexibility in how the keying >>> information is presented. DANE supports both Certificates and raw >>> keys, further more Certificates and raw keys can be either the full >>> key or a hash of the key. >>> The group will work on documenting the different approaches to use >>> DANE keying, and the security implication of each. In addition >>> the WG may develop a framework(s) to facilitate the lookup "client" DANE >>> records for authorization/authentication purposes. >>> >>> The group may also create documents that describe how protocol >>> entities can discover and validate these bindings in the execution >>> of specific applications. This work would be done in coordination >>> with the IETF Working Groups responsible for the protocols. >>> >>> The group may in addition encourage interoperability testing and document >>> the results of such testing. >>> >>> Goals and Milestones: >>> DONE - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS >>> DONE - Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG >>> Jun 2014 - Advance DANE SRV document to IESG >>> Jun 2014 - Advance DANE SMTP document to IESG >>> Aug 2014 - Advance DANE SMIME document to IESG >>> Aug 2014 - Advance DANE OPENPGP document to IESG >>> Sep 2014 - Advance DANE operational guidance/errata document to IESG >>> Jan 2015 - Advance DANE security model document to IESG. >>> May 2015 - Advance DANE IPSEC document to IESG >>> ??? 2015 - Advance DANE reverse binding (server to client) document to IESG. >>> Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard >>> Nov 2015 - Recharter or close down >>> >>> > > From nobody Sun May 25 14:38:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF401A03F4; Sun, 25 May 2014 14:38:44 -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 zlSPAx0YMtWS; Sun, 25 May 2014 14:38:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA61A03F8; Sun, 25 May 2014 14:38:41 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140525213841.22273.14333.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 14:38:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TswtXZNiEqvch07Z7POs8sQK9i8 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-10.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 21:38:44 -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-10.txt Pages : 34 Date : 2014-05-25 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smtp-with-dane-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 25 15:10:30 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 201AF1A03F5 for ; Sun, 25 May 2014 15:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk2_0puu841w for ; Sun, 25 May 2014 15:10:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8512A1A03F4 for ; Sun, 25 May 2014 15:10:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 62DBB2AB124; Sun, 25 May 2014 22:10:22 +0000 (UTC) Date: Sun, 25 May 2014 22:10:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140525221022.GS27883@mournblade.imrryr.org> References: <20140525213841.22273.14333.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140525213841.22273.14333.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kz2McF6EctmwQ-s0HF6whUkCCTY Subject: Re: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-10.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: Sun, 25 May 2014 22:10:28 -0000 On Sun, May 25, 2014 at 02:38:41PM -0700, internet-drafts@ietf.org wrote: > Title : SMTP security via opportunistic DANE TLS > Authors : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-smtp-with-dane-10.txt > Pages : 34 > Date : 2014-05-25 Fix for formatting issue reported by Alexey Melnikov. -- Viktor. From nobody Thu May 29 01:05: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 7CE761A0789 for ; Thu, 29 May 2014 01:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.245 X-Spam-Level: X-Spam-Status: No, score=0.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] 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 SrItuA9Od8ZX for ; Thu, 29 May 2014 01:05:26 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C481A070D for ; Thu, 29 May 2014 01:05:25 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s4T85HBT008757; Thu, 29 May 2014 01:05:17 -0700 Message-Id: <201405290805.s4T85HBT008757@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Thu, 29 May 2014 01:05:17 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XrZllETsL1WdFi6vTpWADQph8YQ Subject: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 08:05:27 -0000 The TLS Working Group is in the final stages of approving RFC 7250, "Using Raw Public Keys in TLS/DTLS": https://www.rfc-editor.org/authors/rfc7250.txt The draft modifies the TLS protocol to allow clients and servers to negotiate and exchange types of authentication material other than PKIX certificate chains, and defines a format for exchanging a raw public key. These public keys are authenticated "out of band", outside the TLS protocol, for example by prior administration (in some Internet-of-Things cases), or by the use of DANE. Paul Wouters was the main author, and the protocol and document were significantly improved by several co-authors from the TLS WG. In reviewing the draft, I noticed that it doesn't ever describe how you store such a public key in a TLSA record. And the TLSA RFC 6698 explicitly specifies that TLSA records can ONLY store PKIX certificates! The relevant sections are: RFC 6698 Sec. 1.3: This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. RFC 6698 Sec. 2.1.1: The certificate usages defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values. I remember fighting this fight in the DANE WG, and the result was something along the lines of "We'll narrow the RFC now, and then if-and-when raw public keys are approved by the TLS WG, then we'll amend it to include them." Well, the time has come. Raw public keys are approved by the TLS WG. The trouble is that nobody has bothered to amend the TLSA RFC, so the new draft RFC tells people "just use DANE", but the DANE TLSA RFC says, "No you can't". I propose to add some text to the draft RFC 7250 that extends RFC 6698 by defining how raw public keys are stored in TLSA records. My coauthors seem to prefer that we just ignore the entire issue, issue RFC 7250, and ignore the conflict between the two. As someone who learned most of what I know about protocols (and the Internet) from reading Saint Jon Postel's clearly written RFCs, I would hate to inflict that on future readers. We should not release documents that contain deliberate incompatabilities. We think RFC 7250 is ready to go except for this remaining issue. It has been approved by the TLS WG, the IESG, the RFC Editor, and all the co-authors but me. Here's my proposed wording change for RFC 7520. Improvements welcome. Start from this version: https://www.rfc-editor.org/authors/rfc7250.txt Section 4.4. OLD (entire section): When the TLS server has specified RawPublicKey as the server_certificate_type, authentication of the TLS server to the TLS client is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method. NEW (entire section): When the TLS server has specified RawPublicKey as the server_certificate_type, authentication of the TLS server to the TLS client is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method. In order to support out-of-band authentication via DANE [RFC6698], this document extends the DANE TLSA record definition to allow such records to describe raw public keys as well as PKIX [RFC5280] certificates. This extension does not define any new field values; it merely defines how existing fields are processed when being matched to raw public keys provided by TLS servers. A raw public key is represented in a TLSA record by specifying a certificate usage of 3 (domain-provided), a selector of 1 (SubjectPublicKeyInfo), and a matching type of 0. The SubjectPublicKeyInfo that holds the public key is placed in the certificate association data. Matching types other than 0 may also be used, by placing the corresponding hash value into the certificate association data. DANE [RFC6698] section 1.3 is extended to say: This document only applies to raw public keys and to PKIX [RFC5280] certificates, not certificates of other formats. DANE section 2.1.1 is extended to say: The certificate usages 0, 1 and 2 defined in this document explicitly only apply to PKIX-formatted certificates in DER encoding [X.690]. If TLS allows other formats later, or if extensions to this RRtype are made that accept other formats for certificates, those certificates will need their own certificate usage values. In DANE section 2.1.1, in addition to the definition of certificate usage 3 with TLS servers that use PKIX certificates, certificate usage 3 may also be used with TLS servers that use raw public keys: 3 -- Certificate usage 3 is also used to specify a raw public key that MUST match the raw public key presented by the server in TLS. When the TLS server provides a raw public key, there is no PKIX certificate and no PKIX validation is done; the TLS server's raw public key MUST match the raw public key provided in the TLSA record. This certificate usage is sometimes referred to as "domain-issued" because it allows a domain administrator to directly certify a domain's public keys. I believe that this wording reflects the up-to-now tacit consensus on how the DANE WG expects TLS raw public keys to be represented and processed in TLSA records. In the absence of significant dissent or further improvements, I propose to provide the above updates to the RFC Editor and release the new RFC. John From nobody Thu May 29 07:00: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 465061A094D for ; Thu, 29 May 2014 07:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 K6DzqiqLXCBk for ; Thu, 29 May 2014 07:00:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA2B1A0942 for ; Thu, 29 May 2014 07:00:28 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s4TE0Mlp090592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 May 2014 07:00:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-90.dsl.dynamic.fusionbroadband.com [50.1.51.90] 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.2\)) From: Paul Hoffman In-Reply-To: <201405290805.s4T85HBT008757@new.toad.com> Date: Thu, 29 May 2014 07:00:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> References: <201405290805.s4T85HBT008757@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KROpGvQyFSiXLjqIIKtV1zTCmBs Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:00:30 -0000 On May 29, 2014, at 1:05 AM, John Gilmore wrote: > I remember fighting this fight in the DANE WG, and the result was > something along the lines of "We'll narrow the RFC now, and then > if-and-when raw public keys are approved by the TLS WG, then we'll > amend it to include them." =20 Yep. That is still the plan. > Well, the time has come. Raw public keys > are approved by the TLS WG. The trouble is that nobody has bothered > to amend the TLSA RFC, so the new draft RFC tells people "just use > DANE", but the DANE TLSA RFC says, "No you can't". Anyone could have started the process for an update to 6689 to reflect = this. They haven't yet. > I propose to add some text to the draft RFC 7250 that extends RFC 6698 > by defining how raw public keys are stored in TLSA records. That is a horrible abuse of the RFC publication process. That is, = instead of you asking for IETF review of your idea, you are trying to = slip in a significant technical change with no community review. > My coauthors seem to prefer that we just ignore the entire issue, > issue RFC 7250, and ignore the conflict between the two. =20 What conflict? DANE is clearly defined. If you want to update the = definition (and many of us would support that), write the one-page = Internet Draft to do so. > As someone > who learned most of what I know about protocols (and the Internet) > from reading Saint Jon Postel's clearly written RFCs, I would hate to > inflict that on future readers. We should not release documents that > contain deliberate incompatabilities. And you are not. > We think RFC 7250 is ready to go except for this remaining issue. It > has been approved by the TLS WG, the IESG, the RFC Editor, and all the > co-authors but me. >=20 > Here's my proposed wording change for RFC 7520. Improvements welcome. > Start from this version: >=20 > https://www.rfc-editor.org/authors/rfc7250.txt >=20 > Section 4.4. > OLD (entire section): > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the TLS > client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. >=20 > NEW (entire section): > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the TLS > client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. >=20 > In order to support out-of-band authentication via DANE [RFC6698], > this document extends the DANE TLSA record definition to allow such > records to describe raw public keys as well as PKIX [RFC5280] > certificates. This extension does not define any new field values; > it merely defines how existing fields are processed when being > matched to raw public keys provided by TLS servers. >=20 > A raw public key is represented in a TLSA record by specifying a > certificate usage of 3 (domain-provided), a selector of 1 > (SubjectPublicKeyInfo), and a matching type of 0. The > SubjectPublicKeyInfo that holds the public key is placed in the > certificate association data. Matching types other than 0 may also > be used, by placing the corresponding hash value into the > certificate association data. >=20 > DANE [RFC6698] section 1.3 is extended to say: >=20 > This document only applies to raw public keys and to PKIX > [RFC5280] certificates, not certificates of other formats. >=20 > DANE section 2.1.1 is extended to say: >=20 > The certificate usages 0, 1 and 2 defined in this document > explicitly only apply to PKIX-formatted certificates in DER > encoding [X.690]. If TLS allows other formats later, or if > extensions to this RRtype are made that accept other formats for > certificates, those certificates will need their own certificate > usage values. >=20 > In DANE section 2.1.1, in addition to the definition of certificate > usage 3 with TLS servers that use PKIX certificates, certificate > usage 3 may also be used with TLS servers that use raw public keys: >=20 > 3 -- Certificate usage 3 is also used to specify a raw public key > that MUST match the raw public key presented by the server in > TLS. When the TLS server provides a raw public key, there is no > PKIX certificate and no PKIX validation is done; the TLS > server's raw public key MUST match the raw public key provided in > the TLSA record. This certificate usage is sometimes referred > to as "domain-issued" because it allows a domain administrator > to directly certify a domain's public keys. >=20 > I believe that this wording reflects the up-to-now tacit consensus on > how the DANE WG expects TLS raw public keys to be represented and > processed in TLSA records. In the absence of significant dissent or > further improvements, I propose to provide the above updates to the > RFC Editor and release the new RFC. As co-author of RFC 6689, I fully disagree. The correct way to update = RFC 6698 is with a new RFC that has community review. --Paul Hoffman= From nobody Thu May 29 07:16: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 04DFB1A6EDE for ; Thu, 29 May 2014 07:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHcjQN5PNJ2X for ; Thu, 29 May 2014 07:16:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5391A0993 for ; Thu, 29 May 2014 07:16:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 58A502AB117; Thu, 29 May 2014 14:16:27 +0000 (UTC) Date: Thu, 29 May 2014 14:16:27 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140529141626.GH27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201405290805.s4T85HBT008757@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/st1Z_50A9IqizAoo1eusjuQU4_4 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:16:34 -0000 On Thu, May 29, 2014 at 01:05:17AM -0700, John Gilmore wrote: > In reviewing the draft, I noticed that it doesn't ever describe how > you store such a public key in a TLSA record. I think there is an obvious format, that should be spelled out explicitly in some suitable document. Namely the same format as for the SPKI of a leaf certificate with any supported matching type: ; Match SPKI of a certificate or just the bare public key _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} DANE TLS clients that also support the new TLS oob public key extension can include it in their client HELLO, provided every RR in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup before client HELLO). If any of the RRs have a different usage, then a full leaf certificate may be required, and the client MUST NOT signal oob public key support (since the client would potentially be unable to match a subset of the TLSA records, which may the currently active configuration). -- Viktor. From nobody Thu May 29 09:59:17 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898421A034E for ; Thu, 29 May 2014 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLt31OaPkjX7 for ; Thu, 29 May 2014 09:59:12 -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 2D1D41A018C for ; Thu, 29 May 2014 09:59:11 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BF935806A2; Thu, 29 May 2014 12:59:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401382746; bh=3jJKqIr2Il9DmleAbSd2L3ZY8BaVDikFPLs0RZd8caw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=m3Uh+tbBeH4NzQ8Eid8YipZ1nxrJr7kWFQWArcLnWnvzXbIfcy2E4m0IIH7a3p9AL JtY8Z9SoSk1k/ZdahbkDfiaezDThgA12PQCmEvAgEsEnH9r43TRaUtCmY0i1jKv7bX omesWEDiOnsmkdhPCBWqdPfMl84TlRHmJyWOGIno= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4TGx6xG018017; Thu, 29 May 2014 12:59:06 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 29 May 2014 12:59:06 -0400 (EDT) From: Paul Wouters To: Viktor Dukhovni In-Reply-To: <20140529141626.GH27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gCP9rRFeHah5tsMAUAazLANbU64 Cc: dane WG list Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:59:14 -0000 On Thu, 29 May 2014, Viktor Dukhovni wrote: >> In reviewing the draft, I noticed that it doesn't ever describe how >> you store such a public key in a TLSA record. > > I think there is an obvious format, that should be spelled out > explicitly in some suitable document. Namely the same format as > for the SPKI of a leaf certificate with any supported matching > type: > > ; Match SPKI of a certificate or just the bare public key > _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} Where is this not clear in the existing DANE RFCs? > DANE TLS clients that also support the new TLS oob public key > extension can include it in their client HELLO, provided every RR > in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup > before client HELLO). If any of the RRs have a different usage, > then a full leaf certificate may be required, and the client MUST > NOT signal oob public key support (since the client would potentially > be unable to match a subset of the TLSA records, which may the > currently active configuration). Can you explain why that is needed? I would envison people to migrate from full certs to bare keys to have both available in their TLS server and in their TLSA record set. Paul > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Thu May 29 11:04:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947D21A016D for ; Thu, 29 May 2014 11:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzhU9aDVrE0S for ; Thu, 29 May 2014 11:04:02 -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 350661A0168 for ; Thu, 29 May 2014 11:04:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 765EF2AB124; Thu, 29 May 2014 18:03:56 +0000 (UTC) Date: Thu, 29 May 2014 18:03:56 +0000 From: Viktor Dukhovni To: dane WG list Message-ID: <20140529180356.GL27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/t6233kb2qxMzJbQS_iVPmMg2Nak Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:04:03 -0000 On Thu, May 29, 2014 at 12:59:06PM -0400, Paul Wouters wrote: > >I think there is an obvious format, that should be spelled out > >explicitly in some suitable document. Namely the same format as > >for the SPKI of a leaf certificate with any supported matching > >type: > > > > ; Match SPKI of a certificate or just the bare public key > > _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} > > Where is this not clear in the existing DANE RFCs? Per John's note, the existing RFCs specifically exclude bare SPKI, though otherwise I agree, the mapping is fairly natural/obvious. > >DANE TLS clients that also support the new TLS oob public key > >extension can include it in their client HELLO, provided every RR > >in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup > >before client HELLO). If any of the RRs have a different usage, > >then a full leaf certificate may be required, and the client MUST > >NOT signal oob public key support (since the client would potentially > >be unable to match a subset of the TLSA records, which may the > >currently active configuration). > > Can you explain why that is needed? I would envison people to migrate > from full certs to bare keys to have both available in their TLS server > and in their TLSA record set. The server will indeed have full certs and corresponding or independent bare keys. However all the TLSA RRs MUST be "3 1 X" RRs (matching all the deployed certificates and public keys), or else clients MUST NOT indicate support for "oob public key". The point being that the client does not know which TLSA RRs are "live" and which are "legacy" as a result of key rotation. If all the "3 1 X" records are legacy, and only "3 0 1" or "2 0 1" RRs are "live", the client will fail to authenticate the server if it learns only the public key of the live leaf certificate. A client that negotiates "oob public key" can only learn the server's leaf SPKI, so this needs to be sufficient to perform authentication, which is only true when *all* the authentication records are "3 1 X". -- Viktor. From nobody Thu May 29 22:57: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 7C5E71A07C8 for ; Thu, 29 May 2014 22:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm6qrotjMTyo for ; Thu, 29 May 2014 22:57:27 -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 4A7B21A06EE for ; Thu, 29 May 2014 22:57:27 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2A274800C9 for ; Fri, 30 May 2014 01:57:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401429442; bh=+Qcw0wjH/hrnsx7YYAy+5Y7OV9VswRrqBRD5wNtchL4=; h=Date:From:To:Subject:In-Reply-To:References; b=YtBzjAg6uAQRx9gK24DM25h/Umu2OXKWsgwp9nGIEn0ksMuxCEaQjVEGuuqn7mp1G UzY1r61izAFvnAL1GMwU9Wk4q47DNfVCq/WjUJC2yBx9zTgEYxhXlCpYR4dCvy7Eoa apRVjozch7BOJGBuHCooYB7yt/mFUAIoTOLDRlDw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4U5vLhI030976 for ; Fri, 30 May 2014 01:57:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 30 May 2014 01:57:21 -0400 (EDT) From: Paul Wouters To: dane WG list In-Reply-To: <20140529180356.GL27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/lzqwppnKhp-Kv5qHbHtEH4Sd5Y8 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 05:57:29 -0000 On Thu, 29 May 2014, Viktor Dukhovni wrote: >>> I think there is an obvious format, that should be spelled out >>> explicitly in some suitable document. Namely the same format as >>> for the SPKI of a leaf certificate with any supported matching >>> type: >>> >>> ; Match SPKI of a certificate or just the bare public key >>> _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} >> >> Where is this not clear in the existing DANE RFCs? > > Per John's note, the existing RFCs specifically exclude bare SPKI, I think that's still up for discussion. But your above comment made it appear you thought something else was missing, something about leaf certificates and selector SPI? >>> DANE TLS clients that also support the new TLS oob public key >>> extension can include it in their client HELLO, provided every RR >>> in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup >>> before client HELLO). If any of the RRs have a different usage, >>> then a full leaf certificate may be required, and the client MUST >>> NOT signal oob public key support (since the client would potentially >>> be unable to match a subset of the TLSA records, which may the >>> currently active configuration). >> >> Can you explain why that is needed? I would envison people to migrate >> from full certs to bare keys to have both available in their TLS server >> and in their TLSA record set. > > The server will indeed have full certs and corresponding or > independent bare keys. However all the TLSA RRs MUST be "3 1 X" > RRs (matching all the deployed certificates and public keys), > or else clients MUST NOT indicate support for "oob public key". A client can indicate support for oob public key that is not based on DANE. > The point being that the client does not know which TLSA RRs are > "live" and which are "legacy" as a result of key rotation. Why does that matter? the client receives either the server's full certificate or its 'bare key certificate'. It looks throug the list of obtained TLSA records and looks if anything matches. It does not need to prove every TLSA record is valid. Also, all TLSA records are "live", and I don't understand your terminology of "live" versus "legacy" at all. > If all > the "3 1 X" records are legacy, and only "3 0 1" or "2 0 1" RRs > are "live", the client will fail to authenticate the server if it > learns only the public key of the live leaf certificate. If the client only has a bare public key of the server and the TLSA record is only "2 x x" the setup is broken. sure. Don't do that? If there is a "3 x x" TLSA record, there is no issue. If the client has the full public cert of the server, then any of the certificate usage TLSA types could be used, and there is no issue. > A client that negotiates "oob public key" can only learn the > server's leaf SPKI, so this needs to be sufficient to perform > authentication, which is only true when *all* the authentication > records are "3 1 X". Why isn't only _one_ TLSA record of type "3 1 x" good enough? Why can't the admin publish a "3 1 x" and a "1 x x" or "2 x x" ? So you brought up John's point (which all centers around "can we call a ASN.1 SPKI a 'certificate'") and a new issue which I completely don't understand why it is an issue. Paul From nobody Thu May 29 23:17:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756611A06EE for ; Thu, 29 May 2014 23:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] 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 ktPZdWfh6vxz for ; Thu, 29 May 2014 23:17:03 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA51A1A0313 for ; Thu, 29 May 2014 23:17:03 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s4U6GwBT015849; Thu, 29 May 2014 23:16:58 -0700 Message-Id: <201405300616.s4U6GwBT015849@new.toad.com> To: Paul Hoffman In-reply-to: <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Thu, 29 May 2014 07:00:21 -0700." Date: Thu, 29 May 2014 23:16:58 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6_zTAAF5Ad35TUmQGc2EWJ-eqRY Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 06:17:04 -0000 > > I propose to add some text to the draft RFC 7250 that extends RFC 6698 > > by defining how raw public keys are stored in TLSA records. > > That is a horrible abuse of the RFC publication process. That is, instead of you asking for IETF review of your idea, you are trying to slip in a significant technical change with no community review. Hi Paul, nice to see you. If I had wanted to slip something past the DANE WG without IETF review, why would I post the above message to the DANE WG? I am *asking* for review by the DANE WG. Not circumventing review. I saw an issue that the DANE WG should know about, in an RFC from a different WG, and I brought it to the DANE WG's attention. Is there something wrong with that? Is your complaint that you want a few-paragraph DANE RFC that makes the update, rather than a few paragraphs in the TLS Raw Public Keys RFC? I.e. is this a turf battle over which WG gets to claim the document? Or, do you have an actual, substantive, technical issue with the proposed extension of the DANE TLSA records? John From nobody Fri May 30 07:08:07 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 B04D31A03FC for ; Fri, 30 May 2014 07:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjPLhBnafemz for ; Fri, 30 May 2014 07:08:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55A71A08BD for ; Fri, 30 May 2014 07:08:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BA5852AB137; Fri, 30 May 2014 14:07:56 +0000 (UTC) Date: Fri, 30 May 2014 14:07:56 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140530140756.GQ27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/eZeLNlSTiwuvrqXA3HDMWUgjTi4 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 14:08:04 -0000 On Fri, May 30, 2014 at 01:57:21AM -0400, Paul Wouters wrote: > >The server will indeed have full certs and corresponding or > >independent bare keys. However all the TLSA RRs MUST be "3 1 X" > >RRs (matching all the deployed certificates and public keys), > >or else clients MUST NOT indicate support for "oob public key". > > A client can indicate support for oob public key that is not based on > DANE. Yes, of course. But if the client intends to perform DANE authentication, it should not preclude verification via any RRs that require a full certificate chain. In practice, server RRs for servers that want to support the new TLS extension will be all "3 1 X" for both "active" and "legacy" keys, but (DANE-aware) clients will need to be prepared for exceptions. > >The point being that the client does not know which TLSA RRs are > >"live" and which are "legacy" as a result of key rotation. > > Why does that matter? the client receives either the server's full > certificate or its 'bare key certificate'. It looks through the list of > obtained TLSA records and looks if anything matches. It does not need > to prove every TLSA record is valid. There may be no records that match the SPKI of the active public key. You're not thinking sufficiently clearly about the full TLSA record lifecycle, key rotation, changes in usage/selector over time, ... > Also, all TLSA records are "live", and I don't understand your > terminology of "live" versus "legacy" at all. Not all server keys are "live" some will refer to the previously fielded key, to accomodate key rollover. > If the client only has a bare public key of the server and the TLSA record > is only "2 x x" the setup is broken. sure. Don't do that? If there is a > "3 x x" TLSA record, there is no issue. Not true, firstly because it needs to "3 1 X" not "3 X X", but also because even "3 1 X" may describe a stale configuration that is no longer active. > Why isn't only _one_ TLSA record of type "3 1 x" good enough? Why can't > the admin publish a "3 1 x" and a "1 x x" or "2 x x" ? Because there is no guarantee that that particular RR still matches the server's chain. All we know is that *some* RR is supposed to match the chain, during key rotation, some do not. The ones that do not might be "legacy" or might be "future" (keys that are no longer deployed, or keys soon to be deployed). -- Viktor. From nobody Fri May 30 07:15: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 A8F201A08BD for ; Fri, 30 May 2014 07:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEG1SE7IzE-a for ; Fri, 30 May 2014 07:15:21 -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 4E4661A08F6 for ; Fri, 30 May 2014 07:15:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D011D2AB137; Fri, 30 May 2014 14:15:16 +0000 (UTC) Date: Fri, 30 May 2014 14:15:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140530141516.GR27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201405300616.s4U6GwBT015849@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1KayKnPKq-oeWQIjtVCRF7yS-0k Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 14:15:22 -0000 On Thu, May 29, 2014 at 11:16:58PM -0700, John Gilmore wrote: > Or, do you have an actual, substantive, technical issue with the > proposed extension of the DANE TLSA records? Turf wars aside, either the TLS extension document could document the DANE implications (including the point about when it is safe to signal "oob public key" when the client intends to use DANE auth) or a new DANE draft gets to document the TLS implications (including that same point). So some overlap is unavoidable. For example, the SMTP and OPS drafts already talk about requiring "2 X Y" trust anchor certs in server_certificate TLS messages, these are optional with PKIX. My gut feeling is that since the issue applies only to clients for which "oob" means "DANE", there should at least be a DANE WG document that covers this perhaps among other topics. Would it be a problem if this got covered consistently in multiple documents? From the perspective of an implementor it would be helpful to see this covered in which-ever document I happened to be reading when adding bare public key support. -- Viktor. From nobody Fri May 30 11:28: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 7054F1A048E for ; Fri, 30 May 2014 11:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4SCcTH1cF9h for ; Fri, 30 May 2014 11:28:38 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA761A043F for ; Fri, 30 May 2014 11:28:38 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9C010800AD for ; Fri, 30 May 2014 14:28:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401474513; bh=ar3BxCBA+u2xofHu2Zg80WpXfaOuTRpmmeQp9GOrw78=; h=Date:From:To:Subject:In-Reply-To:References; b=E7nOMIdGWdr2pqlc1qjGo//ULrWjwYbehVh+XlFNw9GIR74028Ts1a+AIs6zmwvsm +4V3rXqCdms7eILPDsWAn1oyiW6Ro4NBOIDyymbspuRd+eugd8NYVkWHSQ9/Wqcire ed/7YTJP8OTh6mmvCA2aX+bWpmnhVrHHOiNHx1lQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4UISXRm024368 for ; Fri, 30 May 2014 14:28:33 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 30 May 2014 14:28:33 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140530141516.GR27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> <20140530141516.GR27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Xp6BjLD1i80QNoEkisqdMpqw5JA Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 18:28:39 -0000 On Fri, 30 May 2014, Viktor Dukhovni wrote: > Would it be a problem if this got covered consistently in multiple > documents? From the perspective of an implementor it would be > helpful to see this covered in which-ever document I happened to > be reading when adding bare public key support. The bare public key document could refer to an ERRATA for 6698 that states an ASN.1 SPKI structure is to be considered a "PKIX certificate" in the context of TLSA certificate usage selectors? Paul From nobody Fri May 30 11:44: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 DCD061A6F7D for ; Fri, 30 May 2014 11:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZdveeJmERP3 for ; Fri, 30 May 2014 11:44:08 -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 6D05B1A6F41 for ; Fri, 30 May 2014 11:44:08 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 928E62AB137; Fri, 30 May 2014 18:44:03 +0000 (UTC) Date: Fri, 30 May 2014 18:44:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140530184403.GA27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> <20140530141516.GR27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8jqSUzRRubBbj5I-08KK7R69fJ8 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 18:44:11 -0000 On Fri, May 30, 2014 at 02:28:33PM -0400, Paul Wouters wrote: > On Fri, 30 May 2014, Viktor Dukhovni wrote: > > >Would it be a problem if this got covered consistently in multiple > >documents? From the perspective of an implementor it would be > >helpful to see this covered in which-ever document I happened to > >be reading when adding bare public key support. > > The bare public key document could refer to an ERRATA for 6698 that > states an ASN.1 SPKI structure is to be considered a "PKIX certificate" > in the context of TLSA certificate usage selectors? Two problems with that: * The ERRATUM will likely be rejected, because the restriction was intentional. * This is the obvious part of how to use "oob public key" with DANE, and need hardly be explained. The non-obvious part is the need to only signal "oob public key" support in the client when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?" records. I'll leave to the authors of that draft to decide whether that should be explained in their draft, or in a suitable separate DANE WG document. -- Viktor. From nobody Fri May 30 11:50:24 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A430E1A016D for ; Fri, 30 May 2014 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJODjhVehjfD for ; Fri, 30 May 2014 11:50:22 -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 683571A0168 for ; Fri, 30 May 2014 11:50:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 812C0800AD for ; Fri, 30 May 2014 14:50:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401475817; bh=uvliEknZ8Sw8i55E+63gzq9uPfeyCerjukpxphVr1dc=; h=Date:From:To:Subject:In-Reply-To:References; b=Hok2N1c8ZxEEMZWrt+PT5zIzRwdML9AQ4aZhwa1remh7H1J9bi58zAF5IowT+Ui+A Alismg6Vvh+nBo0yenll7HDi0rgNEVQDe0OBfEk/nHBaSpBjYBbY97ql2C8Lv7mkbF sveeZlv45peP5a7XuT8v/UMtTZuWs4wfYCYDj6Hg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s4UIoHl7025127 for ; Fri, 30 May 2014 14:50:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 30 May 2014 14:50:17 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140530184403.GA27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> <20140530141516.GR27883@mournblade.imrryr.org> <20140530184403.GA27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0Y8k6Ui4rLnx5a21i_sItQ_fYIY Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 18:50:23 -0000 On Fri, 30 May 2014, Viktor Dukhovni wrote: >> The bare public key document could refer to an ERRATA for 6698 that >> states an ASN.1 SPKI structure is to be considered a "PKIX certificate" >> in the context of TLSA certificate usage selectors? > > Two problems with that: > > * The ERRATUM will likely be rejected, because the restriction was > intentional. There is/was no restriction. It is a clarification. Note that the certificate type 3 explicitely excludes "PKIX validation" to allow for a 'certificate' containing just a SPKI, and now what normal "PKIX validation" would deem as "minimal required". > * This is the obvious part of how to use "oob public key" with > DANE, and need hardly be explained. The non-obvious part is the > need to only signal "oob public key" support in the client > when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?" > records. This is the third time you mention this and the third time I have to ask you why. It is perfectly normal to NOT HAVE TLSA RECORDS and rely on a firmware public key, and still signal and use "oob public keys". Please try and explain why you are trying to add restrictions on the set of TLSA records to support "oob public key" (which can happen on its own, along with regular full cert support, with or without DANE) Paul From nobody Fri May 30 12:03:28 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 2536C1A04A1 for ; Fri, 30 May 2014 12:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWAboqLbm1dY for ; Fri, 30 May 2014 12:03:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9B41A01B5 for ; Fri, 30 May 2014 12:03:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 321FE2AB117; Fri, 30 May 2014 19:03:20 +0000 (UTC) Date: Fri, 30 May 2014 19:03:20 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140530190319.GB27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> <20140530141516.GR27883@mournblade.imrryr.org> <20140530184403.GA27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jW3yYFat6a4N8vdHz0zcdE4bYf0 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 19:03:27 -0000 On Fri, May 30, 2014 at 02:50:17PM -0400, Paul Wouters wrote: > > * This is the obvious part of how to use "oob public key" with > > DANE, and need hardly be explained. The non-obvious part is the > > need to only signal "oob public key" support in the client > > when server's TLSA RRs contain *only* "DANE-EE(3) SPKI(1) ?" > > records. > > This is the third time you mention this and the third time I have to ask > you why. That is, the third time you've failed to understand. :-( The context as stated before, is clients for which "oob" means DANE auth, and the restriction is for that case only. > Please > try and explain why you are trying to add restrictions on the set of > TLSA records to support "oob public key" (which can happen on its own, > along with regular full cert support, with or without DANE) Clients for which DANE auth is the authentication mechanism MUST NOT exclude any "usable" TLSA RRs from the potential set of matching records by negotiating "oob public key" which is only compatible with "3 1 X". The reason, as before, is that there is no a-priori way to determine which subset of the TLSA RRs is sufficient to authenticate the server. -- Viktor. From nobody Fri May 30 12:05:49 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CC91A6FFF for ; Fri, 30 May 2014 12:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 gbPSMMejFiCK for ; Fri, 30 May 2014 12:05:44 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8DD1A7019 for ; Fri, 30 May 2014 12:05:35 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id A260E1DF8B; Fri, 30 May 2014 19:05:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401476729; bh=2yKa1yHlwBzte8jaGd38r2g9gSwDp6REx/cw+MpIjhY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=IpwTC4Nmkpd32jU0oyB08ohzDFzc0XEXhCDmonqzEdQA1Odbyw6PAHrXxor2NtaAz FaK0i3IaTWfSrhg98rq7Jk8OOaKfgJTItKK/4pALnHEo720lKx7r3RtsEgaNZKCuzw bT2f25fAQvwZWoezdciRIdMVn9CpGvDVHWkQ7CMc= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7914E6001E; Fri, 30 May 2014 19:02:22 +0000 (UTC) From: James Cloos To: In-Reply-To: <20140529180356.GL27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 29 May 2014 18:03:56 +0000") References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 30 May 2014 15:02:22 -0400 Message-ID: Lines: 27 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140530:dane@ietf.org::ZpPY6VQSCo9wY4EJ:000wUhpF Archived-At: http://mailarchive.ietf.org/arch/msg/dane/m6PPP_ibvT690teLAORDCigB7bU Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 19:05:46 -0000 Some thoughts on this: A 3 0 0 tlsa will work as well as a 3 1 x. The client can pull the spki out on its own. I find both possibilities, incorporation in the tla rfc or a new rfc from us equally accecptable methods of publication. As long as our input is reflected. It is not that *all* tlsas need to be limited just because the server supports the oob methods. Rather, *at least one* of the published tlsas must be usable (3-0-0 or 3-1-x and secure in this case) and match. Should a different kind of bare key show up, one which doesn't look like the spki blob expected by x-1-y tlsa (openssh keys would be interesting), we can publish an rfc defining matching type 2. But given: ,----< excerpt from draft-ietf-tls-oob-pubkey-11.txt > | namely, the SubjectPublicKeyInfo structure of a PKIX certificates | that carries the parameters necessary to describe the public key. `---- we do not need match 2 for this. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri May 30 12:28: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 6FFC61A6FD0 for ; Fri, 30 May 2014 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ditmPKsGr5IK for ; Fri, 30 May 2014 12:28:44 -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 D43021A0A2F for ; Fri, 30 May 2014 12:28:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 139572AB117; Fri, 30 May 2014 19:28:40 +0000 (UTC) Date: Fri, 30 May 2014 19:28:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140530192840.GC27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/c_0GfKqvAxPLEvdCBS4v5v_041U Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 19:28:46 -0000 On Fri, May 30, 2014 at 03:02:22PM -0400, James Cloos wrote: > A 3 0 0 tlsa will work as well as a 3 1 x. The client can pull the spki > out on its own. Not true. When the server presents only the SPKI (no certificate wrapped around it), the client cannot magically reconstruct the enclosing certificate. > It is not that *all* tlsas need to be limited just because the server > supports the oob methods. Rather, *at least one* of the published tlsas > must be usable (3-0-0 or 3-1-x and secure in this case) and match. Not true. If the server's "3 1 x" RRs reflect only keys that were active in the past, or only keys that will be active in the future, while the currently active certificate key matches other TLSA RRs ((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses if it negotiates "oob public key" and server only presents a leaf SPKI instead of a leaf cert. I wish folks would take a moment to think this through, it is not that hard. If you still don't see it, you've not thought about it hard enough yet. -- Viktor. From nobody Fri May 30 12:50:56 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2637A1A04AA for ; Fri, 30 May 2014 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWzIrtXvh23g for ; Fri, 30 May 2014 12:50:52 -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 738D01A0408 for ; Fri, 30 May 2014 12:50:52 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5F4632AB117; Fri, 30 May 2014 19:50:47 +0000 (UTC) Date: Fri, 30 May 2014 19:50:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140530195047.GD27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> <20140530192840.GC27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140530192840.GC27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kshMbDJtsHOqEBKVoj7HtNYXpNk Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 19:50:55 -0000 On Fri, May 30, 2014 at 07:28:40PM +0000, Viktor Dukhovni wrote: > On Fri, May 30, 2014 at 03:02:22PM -0400, James Cloos wrote: > > > A 3 0 0 tlsa will work as well as a 3 1 x. The client can pull the spki > > out on its own. > > Not true. When the server presents only the SPKI (no certificate > wrapped around it), the client cannot magically reconstruct the > enclosing certificate. Oops, sorry, yes as a special case "3 0 0" still works. I tend to block the the mtype 0 TLSA RRs from my mind. So indeed the "oob public key" compatible RRs are: 3 0 0 3 1 X -- Viktor. From nobody Fri May 30 16:05: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 EF0E41A0636 for ; Fri, 30 May 2014 16:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZhHdaL2iBPV for ; Fri, 30 May 2014 16:05:47 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 092571A0293 for ; Fri, 30 May 2014 16:05:47 -0700 (PDT) Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id 3D4552C570; Fri, 30 May 2014 16:05:39 -0700 (PDT) From: Wes Hardaker To: John Gilmore References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> Date: Fri, 30 May 2014 16:05:38 -0700 In-Reply-To: <201405300616.s4U6GwBT015849@new.toad.com> (John Gilmore's message of "Thu, 29 May 2014 23:16:58 -0700") Message-ID: <0l61kmj29p.fsf@wjh.hardakers.net> User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O-CaJ3M_6JLKdsU3lSj-y3cKlc4 Cc: Paul Hoffman , dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 23:05:49 -0000 John Gilmore writes: >> That is a horrible abuse of the RFC publication process. > ... > I am *asking* for review by the DANE WG. Another option: put a note about it in the dane-ops draft, which was discussed at the last WG meeting as potentially being more than an -ops document in the first place (extending DANE not just defining operational characteristics). We're over due for getting that out the door too. -- Wes Hardaker Parsons From nobody Fri May 30 16:47:59 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBBD1A04A9 for ; Fri, 30 May 2014 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 k603lyXC6UuN for ; Fri, 30 May 2014 16:47:55 -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 6FC2D1A0274 for ; Fri, 30 May 2014 16:47:55 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 8DD791E028; Fri, 30 May 2014 23:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401493670; bh=wikSM5wc/WDkkVTH5O4wE1Pe5CbgOFiJ++Imnp8Wo0Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F3cg39ALMYGJ0WQJbeAgxY0C1RM/CJv1mnonsxFs0WNy8F6+y5SZ4NzqpCDe4el9L Gboa8/3AZ7LvmQQFl7EumU8bgbXND0nkNQd4oHXI8LCoadWCxBnWNJAxZqsWSmeVrY 1q04ELMQHHmFgdj6OVNMyuV2yGZqLLvQ+3NtPRJU= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7AF1B6001E; Fri, 30 May 2014 23:43:06 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140530192840.GC27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 30 May 2014 19:28:40 +0000") References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> <20140530192840.GC27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 30 May 2014 19:43:06 -0400 Message-ID: Lines: 36 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140530:viktor1dane@dukhovni.org::zd+LiQmPIXD3cy3D:000000000000000000000000000000000000Hve7s X-Hashcash: 1:30:140530:dane@ietf.org::spBABZX6KlGh11fV:000IhYw2 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WQ_z4Z7eVP6tlrFfOin4se4luRQ Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 30 May 2014 23:47:57 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> On Fri, May 30, 2014 at 03:02:22PM -0400, James Cloos wrote: >> A 3 0 0 tlsa will work as well as a 3 1 x. The client can pull the spki >> out on its own. VD> Not true. When the server presents only the SPKI (no certificate VD> wrapped around it), the client cannot magically reconstruct the VD> enclosing certificate. Yes true. When the server presents the SPKI, and the tlsa has the whole cert, the client can extract the spki from the tlsa-provided cert and compare them. That is no different from the case where the server presents a whole cert but the tlsa match type is 1. Either way the client needs to know how to extract an SPKI from a cert. >> It is not that *all* tlsas need to be limited just because the server >> supports the oob methods. Rather, *at least one* of the published tlsas >> must be usable (3-0-0 or 3-1-x and secure in this case) and match. VD> Not true. If the server's "3 1 x" RRs reflect only keys that were VD> active in the past, or only keys that will be active in the future, VD> while the currently active certificate key matches other TLSA RRs VD> ((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses VD> if it negotiates "oob public key" and server only presents a leaf VD> SPKI instead of a leaf cert. That is irrelevant. Config errors like that will happen w/o oob just as much as with. And clients need to decline then, too. The fact that an oob client which expects to use tlsa to validate the spki needs a tlsa which works with that should be noted, but we (the wg) don't need to do any more than mention it. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri May 30 17:02:01 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E211A0636 for ; Fri, 30 May 2014 17:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 DrkMaIgSFd_J for ; Fri, 30 May 2014 17:01:59 -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 51AB31A04A9 for ; Fri, 30 May 2014 17:01:59 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 25A3F1DFA4; Sat, 31 May 2014 00:01:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401494515; bh=IwxaVa9OcyP4+5U2YSVVj6Jkec562Y7i+V3ihdEK5Ms=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ArEtNJjwMyfTDk9W/emG1TfXv6dv2gR9ygGYCNOPzaf6rjWssVJh7zsCSsUA8fwto S9h9Nv1k9zcC7es8zbR0ULaeIsgzEwOyJm/z0xGAl2zHraLy+VZluDz+fsQFhDlrHF bQgMbJf42aQJwr2r4inEnOhttR/owuL1TEOr6/9c= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 02A8D6001E; Fri, 30 May 2014 23:44:27 +0000 (UTC) From: James Cloos To: Wes Hardaker In-Reply-To: <0l61kmj29p.fsf@wjh.hardakers.net> (Wes Hardaker's message of "Fri, 30 May 2014 16:05:38 -0700") References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <201405300616.s4U6GwBT015849@new.toad.com> <0l61kmj29p.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 30 May 2014 19:44:27 -0400 Message-ID: Lines: 12 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140530:wjhns1@hardakers.net::S+J/dYHVhnq00vVQ:0000000000000000000000000000000000000000PWL5i X-Hashcash: 1:30:140530:gnu@toad.com::g27P6doklNoIyKWZ:0000OfjVv X-Hashcash: 1:30:140530:paul.hoffman@vpnc.org::0gDC/tmPBYrxParV:000000000000000000000000000000000000000KbvDS X-Hashcash: 1:30:140530:dane@ietf.org::e67GKaEcAIY5t2x8:000tFz9o Archived-At: http://mailarchive.ietf.org/arch/msg/dane/h3WbFZIJB-q2y8ULEzcHk-7D1gc Cc: dane@ietf.org, Paul Hoffman Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 00:02:00 -0000 >>>>> "WH" == Wes Hardaker writes: WH> Another option: put a note about it in the dane-ops draft, which was WH> discussed at the last WG meeting as potentially being more than an -ops WH> document in the first place (extending DANE not just defining WH> operational characteristics). That sounds like a valid compromise. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri May 30 18:11:07 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 964061A06DA for ; Fri, 30 May 2014 18:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UtCa0XS6E33 for ; Fri, 30 May 2014 18:10:54 -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 5C7461A043C for ; Fri, 30 May 2014 18:10:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1BE1A2AB137; Sat, 31 May 2014 01:10:48 +0000 (UTC) Date: Sat, 31 May 2014 01:10:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140531011048.GE27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> <20140530192840.GC27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Cx2ncqea7l4A8jV0fsXsBpgE7sw Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 31 May 2014 01:10:58 -0000 On Fri, May 30, 2014 at 07:43:06PM -0400, James Cloos wrote: > VD> Not true. If the server's "3 1 x" RRs reflect only keys that were > VD> active in the past, or only keys that will be active in the future, > VD> while the currently active certificate key matches other TLSA RRs > VD> ((usage, selector) != (DANE-EE(3), SPKI(1)) then the client loses > VD> if it negotiates "oob public key" and server only presents a leaf > VD> SPKI instead of a leaf cert. > > That is irrelevant. Config errors like that will happen w/o oob just as > much as with. And clients need to decline then, too. The fact that an > oob client which expects to use tlsa to validate the spki needs a tlsa > which works with that should be noted, but we (the wg) don't need to > do any more than mention it. It is not a configuration error, rather a valid transition state, that clients must support. With DANE, I don't expect clients to be statically configured for each "oob public key" destination. Rather, clients will be capable of "oob public key" support, and of DANE, and will use the two in combination when it makes sense. Thus, if a client sees only "3 1 X" or "3 0 0" TLSA RRs, and using DANE for authentication, it can go ahead and use "oob public key". If the TLSA records don't include any of the above, or are mixed, the client must not negotiate "oob public key". The idea is that clients will offer "oob public key" when possible, which might lead to wide-scale use of the extenion. Otherwise, it is just a curiousity. -- Viktor. From nobody Fri May 30 18:37: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 AAFB51A06C3 for ; Fri, 30 May 2014 18:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RyyTeg08BmPb for ; Fri, 30 May 2014 18:37:30 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53F71A02BE for ; Fri, 30 May 2014 18:37:29 -0700 (PDT) Received: from Philemon (unknown [50.38.87.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 48AC538EE8 for ; Fri, 30 May 2014 18:37:25 -0700 (PDT) From: "Jim Schaad" To: References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> In-Reply-To: <20140529141626.GH27883@mournblade.imrryr.org> Date: Fri, 30 May 2014 18:35:06 -0700 Message-ID: <047901cf7c70$973d92d0$c5b8b870$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHszl+QFE6HMjc8qxJLluNV1wqK1wOYfV3pmwJ/0HA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kBdMXvu52KU8ws7pF2rpYqZvrpo Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 01:37:31 -0000 -----Original Message----- From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Thursday, May 29, 2014 7:16 AM To: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys On Thu, May 29, 2014 at 01:05:17AM -0700, John Gilmore wrote: > In reviewing the draft, I noticed that it doesn't ever describe how > you store such a public key in a TLSA record. I think there is an obvious format, that should be spelled out explicitly in some suitable document. Namely the same format as for the SPKI of a leaf certificate with any supported matching type: ; Match SPKI of a certificate or just the bare public key _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} [JLS] That may be one obvious format. I think that an even better format would be to define a new TLSA certificate type so that the client will know that an OOB bare key is what is coming. Thus ; Match SPKI of a certificate or just the bare public key _25._tcp.mx1.example.com IN TLSA DANE-BARE-KEY(4) SPKI(1) ? {blob} This means that there is no overlap between those that are planning to do PKIX and those that are planning to do bare keys both in the filtering of the information and publishing of the data. Both could be offered, and the DANE query would allow a client to know that OOB is going to be acceptable. Jim DANE TLS clients that also support the new TLS oob public key extension can include it in their client HELLO, provided every RR in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup before client HELLO). If any of the RRs have a different usage, then a full leaf certificate may be required, and the client MUST NOT signal oob public key support (since the client would potentially be unable to match a subset of the TLSA records, which may the currently active configuration). -- Viktor. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From nobody Fri May 30 19:41: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 79BFB1A06E7 for ; Fri, 30 May 2014 19:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VChYJf75wIKM for ; Fri, 30 May 2014 19:41:41 -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 0F13C1A06E5 for ; Fri, 30 May 2014 19:41:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D15C92AB137; Sat, 31 May 2014 02:41:34 +0000 (UTC) Date: Sat, 31 May 2014 02:41:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140531024134.GF27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <047901cf7c70$973d92d0$c5b8b870$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <047901cf7c70$973d92d0$c5b8b870$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9V_ZhhDzJHUr5dphNbX3TdqqoiQ Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 31 May 2014 02:41:42 -0000 On Fri, May 30, 2014 at 06:35:06PM -0700, Jim Schaad wrote: > > I think there is an obvious format, that should be spelled out explicitly in > > some suitable document. Namely the same format as for the SPKI of a leaf > > certificate with any supported matching > > type: > > > > ; Match SPKI of a certificate or just the bare public key > > _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} > > > [JLS] That may be one obvious format. I think that an even better format > would be to define a new TLSA certificate type so that the client will know > that an OOB bare key is what is coming. Thus > > ; Match SPKI of a certificate or just the bare public key > _25._tcp.mx1.example.com IN TLSA DANE-BARE-KEY(4) SPKI(1) ? {blob} This I think adds no value over DANE-EE(3) and needlessly makes server operators publish two records where one will do. It should be possible for clients to offer the new TLS extention when it is compatible with the server's TLSA RRs and to authenticate the server either based on a full X.509 cert or a bare SPKI. -- Viktor. From nobody Sat May 31 12:05:28 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 AACB81A007B for ; Sat, 31 May 2014 12:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 PhVtaD1B64sL for ; Sat, 31 May 2014 12:05:24 -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 B29791A0079 for ; Sat, 31 May 2014 12:05:24 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 4F63E1DE9E; Sat, 31 May 2014 19:05:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401563119; bh=QAYp1z+bF6MKTL23n/dZTplVeBBHf78gTAvkgt8+Sm4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aGn+9WcVKn3kArV9yo+w5R0fpgPJN8otjR6S/RxwzR6tSb/bnHUpdlATIlRTEMje2 6RvPT8tyB7009owfoY4NpILmf6YO30OnjiSWrC24URosQ2H/pzlyznPA36PdaFdPx7 ynYtzBqYPTTlvDnxdV1rkVPbkA3pHS6NSPp9DzyE= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 4CDF26001E; Sat, 31 May 2014 18:58:08 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140531011048.GE27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sat, 31 May 2014 01:10:48 +0000") References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> <20140530192840.GC27883@mournblade.imrryr.org> <20140531011048.GE27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 31 May 2014 14:58:08 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140531:viktor1dane@dukhovni.org::0bm5clE854joFBBR:000000000000000000000000000000000000ietUX X-Hashcash: 1:30:140531:dane@ietf.org::sN8JEI/W7+pmZXRS:000kyRH3 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/rgnh6R_RF2PYHTiyr1d3Yd86eFE Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:05:26 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> If the TLSA records don't include any [3-0-0 or 3-1-x], or are VD> mixed, the client must not negotiate "oob public key". That is a valid point, but if they are mixed, the clients can try, and if the offered key doesn't match the suitable tlsas, it can drop the connection and try again without specifying the extension. When properly configured, if the server's only current cert(s) is full, then the server should not agree to the tls extension. The need to drop and restart should be rare. -JimC P.S. Sorry for replying yesterday before I read your corretion re 3-0-0. -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat May 31 12:37: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 5DF901A0087 for ; Sat, 31 May 2014 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTYbwgGpP2l3 for ; Sat, 31 May 2014 12:37:14 -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 934441A007F for ; Sat, 31 May 2014 12:37:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E69C42AB143; Sat, 31 May 2014 19:37:08 +0000 (UTC) Date: Sat, 31 May 2014 19:37:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140531193708.GI27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org> <20140529180356.GL27883@mournblade.imrryr.org> <20140530192840.GC27883@mournblade.imrryr.org> <20140531011048.GE27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ALOmNxxTu_T0nNJgNyaDaNWR1n4 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys 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, 31 May 2014 19:37:17 -0000 On Sat, May 31, 2014 at 02:58:08PM -0400, James Cloos wrote: > VD> If the TLSA records don't include any [3-0-0 or 3-1-x], or are > VD> mixed, the client must not negotiate "oob public key". > > That is a valid point, but if they are mixed, the clients can try, and > if the offered key doesn't match the suitable tlsas, it can drop the > connection and try again without specifying the extension. To what end? The server recently had, has now or soon will have TLSA records that require full certificates. The server should be able to offer a matching certificate, containing a suitable key. I am not a fan of various fallback schemes and associated downgrade attacks. > When properly configured, if the server's only current cert(s) is full, > then the server should not agree to the tls extension. The need to drop > and restart should be rare. The need for the client to not offer "oob public key" will also be rare, generally servers won't have mixtures of different C/U values across key rollover. Some sites will have only "2 0 1" records: ;; Key rollover state: ;; Current and either future or recent past associated data example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1} example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob2} while other sites will have only "3 1 1" records: ;; Key rollover state: ;; Current and either future or recent past associated data example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob1} example.com. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob2} and the mixed cases will only be seen briefly in transition between the two models. That said, transitions should not be disruptive. A client that sees: ;; Trust model rollover state: ;; Current and either future or recent past associated data example.com. IN TLSA DANE-TA(2) Cert(0) SHA2-256(1) {blob1} example.com. IN TLSA DANE-EE(3) Cert(1) SHA2-256(1) {blob2} has no idea whether the "3 1 1" record is sufficient for authentication, and should simply not offer to negotiate bare public keys (unless it it is statically configured to authenticate these by other means, and the DANE records are largely out of scope). -- Viktor.